Re: Installing OpenBSD on new Chromebook

[Gabriel Busch de Brito]

> All of places I'm finding with directions on how to do this are from circa
> 2015 and do not work now.
> 
> Anybody have a pointer to a more updated set of directions I can try?
I suggest that you follow the installation guide at the FAQ section of
the website.

Best,
G

Re: Installing OpenBSD on new Chromebook

[Jérôme Desquilbet]

Hi all,

I got a nice new laptop at Costco for under $200.  I did the developer 
mode to get to a linux shell and installed a bunch of programs but I'd 
rather just wipe the whole disk and install OpenBSD.


All of places I'm finding with directions on how to do this are from 
circa 2015 and do not work now.


Anybody have a pointer to a more updated set of directions I can try?

Thanks!

Jeff Ross


Hi Jeff,
To check your machine:
* 

To install and everything:
* 
  (this where to always look first)

Also, some up-to-date pages:
* 
  (more for a server, but useful anyway)
* 

Best,
Jérôme.

Installing OpenBSD on new Chromebook

[Jeff Ross]

Hi all,

I got a nice new laptop at Costco for under $200.  I did the developer 
mode to get to a linux shell and installed a bunch of programs but I'd 
rather just wipe the whole disk and install OpenBSD.


All of places I'm finding with directions on how to do this are from 
circa 2015 and do not work now.


Anybody have a pointer to a more updated set of directions I can try?

Thanks!

Jeff Ross

Re: Many video frames dropped unless sound is muted

[Richard Ulmer]

Hi again,

> As a side note: After upgrading from 7.0 to 7.1 I experienced a
> significant increase in audio stutter. Sometimes (I think when a
> "hiccup" became too big) YouTube would even pause a video on it's own or
> mpd(1) would stop playback. As a workaround I increased the buffer size
> with sndiod_flags=-b12000 in /etc/rc.conf.local, which helped a little,
> but didn't eliminate the problem.

I started playing around with the -b flag again and found, that if I
make the buffer very small, my problem goes away and video playback
works better than it ever had. I can now even watch videos at 1920x1080
with 60 FPS and barely drop any frame.

As soon as configure the buffer to contain more than ca. 1000 frames,
video playback begins to suffer. With the default (according to
sndiod(8) and FAQ 13 [1]) 7680 frames, performance is already very poor.
So for now I'm going to go with -b960 (20 ms buffer); in the brief
testing I've done, even the audio stutter seems to have disappeared.
Maybe I just went the wrong way when adjusting the audio buffer
before...

- Richard

[1] https://www.openbsd.org/faq/faq13.html

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Mike Larkin]

On Fri, Oct 28, 2022 at 12:30:11PM -0600, Theo de Raadt wrote:
> Kalabic S,  wrote:
>
> > To be more precise, I wanted to say sticking with FreeBSD means
> > sticking with whatever behavior VMware will keep consistent and
> > support in the future. For "Others" option I don't think they care and
> > is more probable to vary.
>
> I cannot tell the difference.  I think you are completely unqualified
> to know what "they will not change" fakery vmware is doing with the MSR's
> and clock related registers... it is actually possible that when they
> *know* it is one particular operating system they do something sophisticated
> to fool that one specific operating system, whereas when they don't know
> what the operating system is, they reduce the amount of trickery.
>
> You don't know.  I don't know.  None of us know.
>
> But can you please stop making claims you can't back.
>

I think it's reasonable to try and claim that whatever we are, we are the
closest to "that thing". Meaning, the OP said we should claim we are FreeBSD
64 bit or 32 bit or whatever. Fine, but let's spend some time to actually
figure out *what* we should say we are before we just pick something randomly
because "it fixed my machine". Maybe we should say we're Windows? Maybe we
should say we're Linux? My point, and I think Theo's as well, is we don't
know and just randomly taking a diff because it fixes one scenario on one
version of ESXi is shortsighted.

So I would ask the OP to:

 - try different OS choices
 - on different versions of ESX
 - on different versions of VMware fusion
 - on different versions of VMware workstation
 - on different versions of OpenBSD VMs
 - on different archs (i386/amd64) of OpenBSD VMs

... and then report back what the findings are.

-ml

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Theo de Raadt]

Kalabic S,  wrote:

> To be more precise, I wanted to say sticking with FreeBSD means
> sticking with whatever behavior VMware will keep consistent and
> support in the future. For "Others" option I don't think they care and
> is more probable to vary.

I cannot tell the difference.  I think you are completely unqualified
to know what "they will not change" fakery vmware is doing with the MSR's
and clock related registers... it is actually possible that when they
*know* it is one particular operating system they do something sophisticated
to fool that one specific operating system, whereas when they don't know
what the operating system is, they reduce the amount of trickery.

You don't know.  I don't know.  None of us know.

But can you please stop making claims you can't back.

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Kalabic S,]

On 10/28/22 18:29, Theo de Raadt wrote:

Kalabic S.  wrote:


Also, OpenBSD really is part of BSD family.


That is such a load of crap.

You have absolutely no idea what vmware is doing behind the scenes based
upon that string.

Obviously, it is doing stuff.  But you want to say "oh family".  Stop it.



Yeah, me using "family" was a brain fart, no idea what is ESXi doing 
behind the scenes.


To be more precise, I wanted to say sticking with FreeBSD means sticking 
with whatever behavior VMware will keep consistent and support in the 
future. For "Others" option I don't think they care and is more probable 
to vary.

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Kalabic S,]

On 10/28/22 19:06, Mike Larkin wrote:

On Fri, Oct 28, 2022 at 06:25:11PM +0200, Kalabic S. wrote:

In my testing, this has no effect on the operation of the clock.  Only
the guest OS selected in the VM configuration does have an effect.
We should remove any suggestion that 32bit FreeBSD is the right thing
to select though, so changing the guest OS we report is still a good
idea.
Interestingly, it looks like if the guest OS is set to 'Other
(64-bit)', and vmt reports an unrecognised short guest OS name (such
as 'OpenBSD'), vcenter will display the full guest OS name, so you get >

something like 'OpenBSD 7.2 GENERIC.MP#31'.

I'm pretty sure this caused problems in the distant past, but it seems
fine now with esxi 6.7+, so I think we should change to saying we're
OpenBSD instead.


Replacing 'FreeBSD' with something ESXi doesn't support will almost
certainly have drawbacks. We can already see different 'Guest OS' options
have different effects on guest VMs.


What drawbacks? Does jmatthew@'s diff to change the name to OpenBSD fix the
problem or not? If it does, that's a more factually accurate diff. We are
not "FreeBSD 32 bit" or "FreeBSD 64 bit" and it seems that calling ourselves
"OpenBSD" doesn't cause problems anymore. So I'd like to know what "certainly
have drawbacks" means. Can you shed some light on that please?

-ml



jmatthew@'s diff to change the name to OpenBSD does not fix the problem.

Only the "Guest OS" set to "FreeBSD (64-bit)" or "Other (32-bit)" or 
"Other (64-bit)" in the VM configuration does fix the clock problem.


I said it will "certainly have drawbacks" first because just changing to 
64-bit FreeBSD from 32-bit fixes the clock issue. So, being ignorant and 
not informed about technical details happening on ESXi I see it as even 
bigger change (risk) switching to "Others" option. Only guessing here 
and giving my opinion, not trying to teach people with knowledge of the 
issue.

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Mike Larkin]

On Fri, Oct 28, 2022 at 06:25:11PM +0200, Kalabic S. wrote:
> > In my testing, this has no effect on the operation of the clock.  Only
> > the guest OS selected in the VM configuration does have an effect.
> > We should remove any suggestion that 32bit FreeBSD is the right thing
> > to select though, so changing the guest OS we report is still a good
> > idea.
> > Interestingly, it looks like if the guest OS is set to 'Other
> > (64-bit)', and vmt reports an unrecognised short guest OS name (such
> > as 'OpenBSD'), vcenter will display the full guest OS name, so you get >
> something like 'OpenBSD 7.2 GENERIC.MP#31'.
> > I'm pretty sure this caused problems in the distant past, but it seems
> > fine now with esxi 6.7+, so I think we should change to saying we're
> > OpenBSD instead.
>
> Replacing 'FreeBSD' with something ESXi doesn't support will almost
> certainly have drawbacks. We can already see different 'Guest OS' options
> have different effects on guest VMs.

What drawbacks? Does jmatthew@'s diff to change the name to OpenBSD fix the
problem or not? If it does, that's a more factually accurate diff. We are
not "FreeBSD 32 bit" or "FreeBSD 64 bit" and it seems that calling ourselves
"OpenBSD" doesn't cause problems anymore. So I'd like to know what "certainly
have drawbacks" means. Can you shed some light on that please?

-ml

>
> Also, OpenBSD really is part of BSD family.
>
> I have an OpenBSD VM running without issues as a guest with 'FreeBSD' option
> for years and serving as an Internet router for home network. IMO, it's
> pretty good chice.
>
> Only thing I would update is to make it exactly specify to hypervisor is it
> 32 or 64 bit OS. So 'FreeBSD-64' for amd64 and 'FreeBSD' for i386.
>

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Theo de Raadt]

Kalabic S.  wrote:

> I have an OpenBSD VM running without issues as a guest with 'FreeBSD'
> option for years and serving as an Internet router for home
> network. IMO, it's pretty good chice.

I want to say more.

You really have no idea what you are talking about.  The difference between
7.1 and 7.2 and future, is that all the clock hardware and a pile of MSRs
are being inspected completely differently.  But half of those are emulated
by the VMs.  The way this works is that the VM's have always emulated a
pile of this stuff based upon "we know what guest is running".

So you are welcome to keep running old OpenBSD on your VMs without making
any changes.  But that does not let you participate in the conversation
about the new code.

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Theo de Raadt]

Kalabic S.  wrote:

> Also, OpenBSD really is part of BSD family.

That is such a load of crap.

You have absolutely no idea what vmware is doing behind the scenes based
upon that string.

Obviously, it is doing stuff.  But you want to say "oh family".  Stop it.

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Kalabic S.]

> In my testing, this has no effect on the operation of the clock.  Only
> the guest OS selected in the VM configuration does have an effect.
> We should remove any suggestion that 32bit FreeBSD is the right thing
> to select though, so changing the guest OS we report is still a good
> idea.
> Interestingly, it looks like if the guest OS is set to 'Other
> (64-bit)', and vmt reports an unrecognised short guest OS name (such
> as 'OpenBSD'), vcenter will display the full guest OS name, so you 
get > something like 'OpenBSD 7.2 GENERIC.MP#31'.

> I'm pretty sure this caused problems in the distant past, but it seems
> fine now with esxi 6.7+, so I think we should change to saying we're
> OpenBSD instead.

Replacing 'FreeBSD' with something ESXi doesn't support will almost 
certainly have drawbacks. We can already see different 'Guest OS' 
options have different effects on guest VMs.


Also, OpenBSD really is part of BSD family.

I have an OpenBSD VM running without issues as a guest with 'FreeBSD' 
option for years and serving as an Internet router for home network. 
IMO, it's pretty good chice.


Only thing I would update is to make it exactly specify to hypervisor is 
it 32 or 64 bit OS. So 'FreeBSD-64' for amd64 and 'FreeBSD' for i386.

Re: Syncthing permissions question

[Jag Talon]

On Thu, 27 Oct 2022 16:43:03 -0500
ITwrx  wrote:
 
> i find midnight commander's representation of permissions [1] to be 
> helpful when first learning about them. You might check that out
> going forward.

Ah wonderful thank you for the tip!

OpenBSD-current boot stuck at efi0 entry

[Mihai Popescu]

I was trying to install OpenBSD-current from snapshots, UEFI mode boot
and GPT disk - the install went fine, but the boot after installation
remains stuck at efi0 entry listing. I have to use the switch off
button to exit from this.
The install and boot works if I use Legacy mode boot with MBR disk.
Here is the sequence i got with UEFI mode now

[ using 3299768 bytes of bsd ELF symbol table ]
OpenBSD 7.2-current (GENERIC.MP) #819: Thu Oct 27 20:41:32 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7711522816 (7354MB)
avail mem = 7460280672 (7114MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries)
bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018
bios0: Hewlett-Packard HP Compaq Pro 6305 SFF
efi0 at bios0: UEFI 2.3.1
efi0: American Megatrends rev 0x4028d
>>> boot sequence stuck here <<<

I was using this computer with boot in UEFI mode and GPT disk a few
months ago and things went fine. I don't think I have a dmesg from
then, but if I recall the efi0 was not there or was labeled as not
configured.

The dmesg from Legacy mode and MBR disk, now:

OpenBSD 7.2-current (GENERIC.MP) #819: Thu Oct 27 20:41:32 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7711543296 (7354MB)
avail mem = 7460421632 (7114MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries)
bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018
bios0: Hewlett-Packard HP Compaq Pro 6305 SFF
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT MSDM TCPA IVRS SSDT SSDT CRAT
acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) PE20(S4)
PE21(S4) PE22(S4) BNIC(S4) PE23(S4) BR12(S4) BR14(S4) OHC1(S3)
EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.15 MHz, 15-10-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu0: 16KB 64b/line 4-way D-cache, 64KB 64b/line 2-way I-cache, 2MB
64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.05 MHz, 15-10-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu1: 16KB 64b/line 4-way D-cache, 64KB 64b/line 2-way I-cache, 2MB
64b/line 16-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.05 MHz, 15-10-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu2: 16KB 64b/line 4-way D-cache, 64KB 64b/line 2-way I-cache, 2MB
64b/line 16-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 19 (application processor)
cpu3: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.05 MHz, 15-10-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu3: 16KB 64b/line 4-way D-cache, 64KB 64b/line 2-way I-cache, 2MB
64b/line 16-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (BR13)
acpiprt2 at acpi0: bus -1 (BR15)
acpiprt3 at acpi0: bus -1 (BR16)
acpiprt4 at acpi0: bus -1 (BR17)
acpiprt5 at acpi0: bus 1 (P0PC)
acpiprt6 at acpi0: bus 2 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpipr