Re: boot hd0a:/bsd.sp query

On 11/30/25 5:00 AM, Avon Robertson wrote:
> My home router hangs while booting /bsd.sp at the following line:
>
> root on sd0a (cd6f434607620efd.a) swap on sd0b dump on sd0b
>
> The router does not hang while booting if:
>
>>boot hd0a:/bsd.sp -c
> and then
> disable amdgpu
> is specified in UKC followed by
> quit
>
> However; as
>
> $ cat /etc/bsd.re-config
> disable amdgpu
>
> has been as above for 10 weeks and during that time /bsd has booted
> daily without errors occurring, my question is:
>
> what am I misunderstanding in the bsd.re-config(5) description below?
>
> DESCRIPTION
> The bsd.re-config file contains kernel modification commands in
> config(8) format. If present, it is used during system startup to
> configure the kernel that will be running at the next boot. It can
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> be used to enable or disable specific devices in the kernel.
>
> The router was sysupgrade'd -s this morning to:
>
> OpenBSD 7.8-current (GENERIC.MP) #127: Sat Nov 29 10:44:59 MST 2025
> deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> OpenBSD 7.8-current (GENERIC) #126: Sat Nov 29 10:32:29 MST 2025
> deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>
> TIA for your input.
>

I do believe you understand the words a bit differently than intended.

Remember: OpenBSD relinks the kernel every boot. Sequence of events:
1) boot a kernel
2) kernel is running, multi-user, and in control of the hardware.
3) System startup takes place ... including
3a) daemons
3...)
3k) /bsd is relinked (KARL -- Kernel Address Randomization Link)
3...)
4) System is fully on-line and devoted to your tasks
5) ...time goes by, you do stuff...
6) you reboot
1) boot a kernel (relinked in step 3a above)

Now read the description again...
"If present, it is used during system startup [step 3!!] to configure the
kernel that will be running at the next boot [step 6 and later]"

So... your file impacts the NEXT /bsd that will boot...not the one
you happen to tell it to boot at the boot> prompt.
I suspect you (and I, initially) took "system startup" to mean "kernel
loading" -- no, kernel config is done during relinking, NOT during load,
and is part of the operation AFTER the system is multi-user, but not
before you can say it is finished starting.

BUT -- you aren't booting /bsd -- you override and booted /bsd.sp --
which a simple "ls -l /bsd*" will show you has NOT been modified:

$ ls -l /bsd*
-rwx------ 1 root wheel 32283298 Nov 22 01:03 /bsd*
-rwx------ 1 root wheel 32271586 Nov 21 23:42 /bsd.booted*
-rw------- 1 root wheel 4804509 Oct 13 08:07 /bsd.rd
-rwx------ 1 root wheel 32162643 Oct 13 08:07 /bsd.sp*
$ uptime
8:26PM up 8 days, 20:23, 3 users, load averages: 0.00, 0.01, 0.00


Though keep in mind, sometimes my role in life is to provide a wrong
answer so the smart people will have an opportunity to jump up and
down and point out how stupid I am, and provide the right answer. :)


As for your actual problem -- SOME video systems really don't like to
boot or run if a monitor is not attached. There are "cheater plugs"
("HDMI Dummy Plugs") made that will plug into an HDMI port and
convince the GPU a monitor is attached. Apparently, they are often
used in cryptomining, maybe AI, using GPUs as processors rather than
displays. Pretty cheap, under $10ea. I've got a few machines that
need these to do sysupdates, bsd.rd will not work without an attached
monitor, the full kernels will.

Nick.

Re: USB on SuperMicro

On 11/30/25 10:34 AM, otto.cooper wrote:
> I thought I had good news, but I doubt it now.
>
> Two identical Supermicro attached to two identical UPS from EATON, using the latest release of obsd, see the usb ups link randomly.
>
> I just disabled usb3 and xhci hand-off from their bios, leaving ehci on. One machine now detects the ups, the other one does not.
>

so...you do realize how many hundreds, maybe thousands of different
SuperMicro systems have been made over the years? (I've probably
got at least ten different SuperMicros in my life now, maybe far
more. I love 'em. I love how when Dell, EMC, or IBM needs a
good cheap computer, they rebrand a SuperMicro rather than using
one of their own proprietary piles of junk.)

And I'm sure Eaton has made precisely one UPS in its history...

But in short, obviously something isn't as identical as you think.
(right now, you are stomping your feet and saying "YES THEY ARE!"
no...they aren't, as your results are showing. And yes, I'm a
jerk at work when people say, "NOTHING CHANGED", too.)

So... start with a dmesg from both. Run the dmesg through "diff -u".
Are they as "identical" as you think? Little things like ROM
revisions matter.
If the dmesgs confirm your statement that they are the same, swap
the UPSs between machines, and the cables between machines.
Does the problem follow the computer, the cable, or the UPS?

If it follows the computer, look in the BIOS setup, screen by
screen, on both machines.

Something is different. you need to find it. Especially since
you provided no information for us to work from. :)

Nick.