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