Some time ago (more than a year ago) one of my computers failed to boot
after an update (note - not a kernel update. A @world update.) I
couldn't figure out why and installed grub2 and used UUIDs as a
temporary fix.

I got a new SSD for that machine today, so I went and moved everything
over, then (of course) it wouldn't boot any longer, and I remembered my
kludge and spent some time finally figuring out the cause.

It appears to be udev. Somewhere along in its stupid detection it
decides to process USB devices before sata ports, thusly randomly
renaming the boot drive to something else in the process.

It took me forever to figure this out, I eventually had a lightbulb
moment and used my phone to record video of it booting, then slowing it
down, as when the kernel panics you can't scroll back up to see WTF
happened.

This is an older machine, but I'm not convinced it's the motherboard
doing this. I've checked the boot order in the BIOS. I've also tried
setting and unsetting "BIOS order determines boot disk" in the kernel
config and it made no difference.

What eventually fixed it was building USB as modules. (Another kludge!)

I have no custom udev rules, the only rules I could find were in
/lib/udev/rules.d:

10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
40-gentoo.rules
50-udev-default.rules
60-block.rules
60-cdrom_id.rules
60-drm.rules
60-evdev.rules
60-persistent-alsa.rules
60-persistent-input.rules
60-persistent-storage-tape.rules
60-persistent-storage.rules
60-persistent-v4l.rules
60-serial.rules
64-btrfs.rules
69-dm-lvm-metad.rules
70-infrared.rules
70-mouse.rules
70-udev-acl.rules
75-net-description.rules
75-probe_mtd.rules
78-sound-card.rules
80-drivers.rules
80-net-setup-link.rules
80-udisks.rules
90-alsa-restore.rules
90-network.rules
95-dm-notify.rules
99-nvidia.rules

Does anyone have any explanation for this daft behaviour or know where I
should look?

I have multiple machines and it's only this one that has this problem,
which happened after a @world update long ago.

Dan

Reply via email to