Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
- Reply: David Wolfskill : "Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c"
- Reply: David Wolfskill : "Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c"
- In reply to: David Wolfskill : "Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 30 May 2022 12:16:57 UTC
On 2022-05-30 07:10, David Wolfskill wrote: > -- but only on one machine (of the 3 that I use for daily tracking head > (and stable/12 & stable/13) -- the build machine ("freebeast"). > > Each is amd64, using ... venerable ... BIOS/MBR & UFS -- stuff that has > generally been functionally stable for the last couple of decades. > > So for yesterday and today, I've moved the new loader aside and copied > the one from Friday, which works just fine. > > The build machine ("freebeast") uses a GENERIC kernel; the other 2 are > laptops, and use a kernel that includes GENERIC, then tweaks things a > bit (e.g., dropping support for tape drives; adding IPFIREWALL and > explicitly NOT setting IPFIREWALL_DEFAULT_TO_ACCEPT; adding sound stuff). > > Info on the update history & copies of stuff like most recent > (verbosely-booted) dmesg.boot should be available at > https://www.catwhisker.org/~david/FreeBSD/history/ (and if you can't get > through, please send a note to dhw@freebsd.org and I'll do what I can to > fix it). > > (Of the 2 laptops, I only have the one that I actuaqlly use in > day-to-day work represented.) > > (I note that to recover, I boot from one the stable/* slices, move the > "head" slice's files around, then reboot from the "head" slice.) > > AFAICT, there were no changes to stand/* since main-n255828-18054d0220c, > though yesterday (main-n255828-18054d0220c -> main-n255840-9cb70cb4769), > there were some changes to sys/ufs/ffs/ffs_subr.c (from > main-n255835-076002f24d35: Hey David, I have not been able to use a new /boot/loader.efi (following -CURRENT) since mid to late 2021, and your symptoms look the same; fortunately, I found bug report 264282[0] last night, which I think is related. Yamagi has already done the investigation, and found a possible cause. For the time being, in the case of a GELI backed UFS mount, after GELI decrypts the mount, one has to manually set currdev back to the correct disk. 0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282 -- To health and anarchy. Alastair