Date: Mon, 30 May 2022 05:16:57 -0700 From: Alastair Hogge <agh@riseup.net> To: current@freebsd.org Cc: David Wolfskill <david@catwhisker.org> Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c Message-ID: <06ba3be54117e4feb8f250756b25c1c5@riseup.net> In-Reply-To: <YpP9fO4v%2BdE1pCgu@albert.catwhisker.org> References: <YpP9fO4v%2BdE1pCgu@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06ba3be54117e4feb8f250756b25c1c5>