Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, Jun 06, 2022 at 09:46:21AM +, Filippo Moretti wrote:
>  
> Is it now safe to attempt updating current with UFS?SincerelyFilippo
> 

Yes.

Kirk committed a fix:

commit bc218d89200faa021def77732f3d9fde4f4dee13
Author: Kirk McKusick 
Date:   Tue May 31 19:55:54 2022 -0700

Two bug fixes to UFS/FFS superblock integrity checks when reading a 
superblock.

Two bugs have been reported with the UFS/FFS superblock integrity
checks that were added in commit 076002f24d35.


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Filippo Moretti]

 
Is it now safe to attempt updating current with UFS?SincerelyFilippo
On Wednesday, June 1, 2022 at 01:07:20 AM GMT+2, Warner Losh 
 wrote:  
 
 

On Tue, May 31, 2022 at 3:55 PM Olivier Cochard-Labbé  
wrote:

Same problem here:- I'm building FreeBSD head on a builder machine, and NFS 
mounting its /usr/src and /usr/obj to 4 others
Results:- 2 of them, UEFI+ZFS machines works great ((Thinkpad T420 and AMD Epyc 
with Tyan motherboard)- 2 of them, BIOS+UFS machines meet this "can't find 
/boot/ua/loader.lua" (HP microserver and PC Engines APU2)
I had to boot from an USB stick, mounting the system partition and "cp 
boot/loader_4th.old boot/loader".

Kirk found that the boot loader defines MAXPHYS to be 128k, which only is for 
the BIOS loader since it's 32-bit. UEFIis 64-bits and just works because it's 
define to 1MB. So the UEFI machines with ZFS are doubly safe. Kirk has a 
changethat relaxes the check and I think we should do this
diff --git a/sys/sys/param.h b/sys/sys/param.h
index 1f720ed31142..8cd9616e872e 100644
--- a/sys/sys/param.h
+++ b/sys/sys/param.h
@@ -176,7 +176,7 @@
 #define DFLTPHYS       (64 * 1024)     /* default max raw I/O transfer size */
 #endif
 #ifndef MAXPHYS                                /* max raw I/O transfer size */
-#ifdef __ILP32__
+#if defined(__ILP32__) && !defined(_STANDALONE) /* Always 1M for loader */
 #define MAXPHYS                (128 * 1024)
 #else
 #define MAXPHYS                (1024 * 1024)

as well to ensure that the loader always assumes a larger MAXPHYS (though I'd 
kinda like the loader to notdefine it at all, but that is a longer conversation 
after reflection not a quick fix to get people back up andrunning).
Warner  

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Warner Losh]

On Tue, May 31, 2022 at 3:55 PM Olivier Cochard-Labbé 
wrote:

> Same problem here:
> - I'm building FreeBSD head on a builder machine, and NFS mounting its
> /usr/src and /usr/obj to 4 others
>
> Results:
> - 2 of them, UEFI+ZFS machines works great ((Thinkpad T420 and AMD Epyc
> with Tyan motherboard)
> - 2 of them, BIOS+UFS machines meet this "can't find /boot/ua/loader.lua"
> (HP microserver and PC Engines APU2)
>
> I had to boot from an USB stick, mounting the system partition and "cp
> boot/loader_4th.old boot/loader".
>

Kirk found that the boot loader defines MAXPHYS to be 128k, which only is
for the BIOS loader since it's 32-bit. UEFI
is 64-bits and just works because it's define to 1MB. So the UEFI machines
with ZFS are doubly safe. Kirk has a change
that relaxes the check and I think we should do this

diff --git a/sys/sys/param.h b/sys/sys/param.h
index 1f720ed31142..8cd9616e872e 100644
--- a/sys/sys/param.h
+++ b/sys/sys/param.h
@@ -176,7 +176,7 @@
 #define DFLTPHYS   (64 * 1024) /* default max raw I/O transfer
size */
 #endif
 #ifndef MAXPHYS/* max raw I/O transfer
size */
-#ifdef __ILP32__
+#if defined(__ILP32__) && !defined(_STANDALONE) /* Always 1M for loader */
 #define MAXPHYS(128 * 1024)
 #else
 #define MAXPHYS(1024 * 1024)

as well to ensure that the loader always assumes a larger MAXPHYS (though
I'd kinda like the loader to not
define it at all, but that is a longer conversation after reflection not a
quick fix to get people back up and
running).

Warner

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Olivier Cochard-Labbé]

Same problem here:
- I'm building FreeBSD head on a builder machine, and NFS mounting its
/usr/src and /usr/obj to 4 others

Results:
- 2 of them, UEFI+ZFS machines works great ((Thinkpad T420 and AMD Epyc
with Tyan motherboard)
- 2 of them, BIOS+UFS machines meet this "can't find /boot/ua/loader.lua"
(HP microserver and PC Engines APU2)

I had to boot from an USB stick, mounting the system partition and "cp
boot/loader_4th.old boot/loader".

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Alastair Hogge]

On 30 May 2022 8:38:27 pm AWST, David Wolfskill  wrote:
>On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
>> ...
>> 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
>> 
>
>I (just) checked; after switching back to the Lua loader, the currdev
>variable is set to "disk0s4a:", which is correct for my case.
>
>Trying loader's "lsdev" command shows the expected disks, slices, and
>partitions, correctly identified as FreeBSD UFS, swap, or ZFS.
>
>Trying to (e.g.) "ls disk0s4a:" fails, saying that it can't find /.

Thanks for having a look into that mate.

-- 
Sent from a device with a tiny bloody screen and no hard keyboard; please 
excuse my brevity.

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Cy Schubert]

In message 
, Warner Losh writes:
> --8495bd05e03b4d42
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, May 30, 2022 at 8:14 AM Toomas Soome  wrote:
>
> >
> >
> > On 30. May 2022, at 17:06, Warner Losh  wrote:
> >
> >
> >
> > On Mon, May 30, 2022 at 4:26 AM David Wolfskill 
> > wrote:
> >
> >> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> >> > ...
> >> > Does loader_4th have same issue?
> >> > 
> >>
> >> I don't know; I hadn't tried it.  I will do so later today & report
> >> back.
> >>
> >
> > So if it's only one system, and it's only UFS, then what does fsck of tha=
> t
> > UFS system tell you?
> > The loader can't find its UFS filesystem to read the configuration from.
> > So either its having trouble
> > finding the device (unlikely since that code hasn't changed in a long
> > time), or its having heartburn
> > with the UFS system for some reason it's being silent about (within the
> > realm of possibilities because
> > there might be an unknown edge case in Kirks recent  UFS integrity
> > changes). I suspect that the 4th
> > boot loader will have the same issue, but a different error message.
> >
> > Others have reported issues with GELI, but that's not in play here, If I'=
> m
> > reading this correctly. Right?
> >
> > Warner
> >
> >
> > Ye, thats why I was asking about loader_4th. I=E2=80=99m trying to spot t=
> he issue
> > from ufs image sample.
> >
>
> I thought it was a good suggestion. My guess on it not working wasn't to
> imply it wasn't.

Backing out 076002f24d35962f0d21f44bfddd34ee4d7f015d restored the one 
machine of mine that did have the problem. The other three were fine with 
that commit.

To summarize, things I tried:

- Reinstall all boot blocks.
- set currdev to my USB rescue disk, ls works, boots fine
- boot from my USB rescue disk, set currdev to the boot disk, boots
- boot from the USB rescue disk, copy /boot/loader* to the boot disk, works 
around the problem.
- Revert 076002f24d35962f0d21f44bfddd34ee4d7f015d resolves the problem.

Other data points:

My three AMD machines on Asus motherboards had no problem with the commit. 
My Acer laptop with Intel CPU suffered the same problem. Could it be that 
malloc() worked on the Asus/AMD machines while it failed on the Acer/Intel 
laptop?

If my hunch that this may be caused by a malloc() failure, would it be a 
good idea to print a nasty warning when malloc failures in loader occur? 
Because silently failing, resulting in weird behaviour is more of a POLA 
than a nasty message. If not this, a loader variable to enable verbose 
messages might help in debugging these kinds of problems. Again, this 
assumes my hunch that it's a malloc() failure is what actually happened.


-- 
Cheers,
Cy Schubert  or 
FreeBSD UNIX: Web:  http://www.FreeBSD.org
NTP:   Web:  https://nwtime.org

e**(i*pi)+1=0

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Warner Losh]

On Mon, May 30, 2022 at 8:14 AM Toomas Soome  wrote:

>
>
> On 30. May 2022, at 17:06, Warner Losh  wrote:
>
>
>
> On Mon, May 30, 2022 at 4:26 AM David Wolfskill 
> wrote:
>
>> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
>> > ...
>> > Does loader_4th have same issue?
>> > 
>>
>> I don't know; I hadn't tried it.  I will do so later today & report
>> back.
>>
>
> So if it's only one system, and it's only UFS, then what does fsck of that
> UFS system tell you?
> The loader can't find its UFS filesystem to read the configuration from.
> So either its having trouble
> finding the device (unlikely since that code hasn't changed in a long
> time), or its having heartburn
> with the UFS system for some reason it's being silent about (within the
> realm of possibilities because
> there might be an unknown edge case in Kirks recent  UFS integrity
> changes). I suspect that the 4th
> boot loader will have the same issue, but a different error message.
>
> Others have reported issues with GELI, but that's not in play here, If I'm
> reading this correctly. Right?
>
> Warner
>
>
> Ye, thats why I was asking about loader_4th. I’m trying to spot the issue
> from ufs image sample.
>

I thought it was a good suggestion. My guess on it not working wasn't to
imply it wasn't.

Warner

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 08:06:32AM -0600, Warner Losh wrote:
> ...
> > On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > > ...
> > > Does loader_4th have same issue?
> > > 
> >
> > I don't know; I hadn't tried it.  I will do so later today & report
> > back.
> >
> 
> So if it's only one system, and it's only UFS, then what does fsck of that
> UFS system tell you?

fsck reports that all is well.

> The loader can't find its UFS filesystem to read the configuration from. So
> either its having trouble
> finding the device (unlikely since that code hasn't changed in a long
> time), or its having heartburn
> with the UFS system for some reason it's being silent about (within the
> realm of possibilities because
> there might be an unknown edge case in Kirks recent  UFS integrity
> changes). I suspect that the 4th
> boot loader will have the same issue, but a different error message.

Pretty much, yeah.  And loader's "lsdev" shows the devices, slices, and
partitions just fine.  But loaders's "ls" doesn't find /.

Toomas has recieved a "dd" image for the first 5 MB of the file system,
and has reproduced the issue in hist test environment, so I'm hoping he
will be able to figure out a bit more.  (It's at
https://www.catwhisker.org/~david/FreeBSD/head/loader/ada0s4a, in case
anyone else wants a peek.)

> Others have reported issues with GELI, but that's not in play here, If I'm
> reading this correctly. Right?

Right: no GELI for any file systems on this machine (only for swap).

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Toomas Soome]

> On 30. May 2022, at 17:06, Warner Losh  wrote:
> 
> 
> 
> On Mon, May 30, 2022 at 4:26 AM David Wolfskill  > wrote:
> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > ... 
> > Does loader_4th have same issue?
> > 
> 
> I don't know; I hadn't tried it.  I will do so later today & report
> back.
> 
> So if it's only one system, and it's only UFS, then what does fsck of that 
> UFS system tell you?
> The loader can't find its UFS filesystem to read the configuration from. So 
> either its having trouble
> finding the device (unlikely since that code hasn't changed in a long time), 
> or its having heartburn
> with the UFS system for some reason it's being silent about (within the realm 
> of possibilities because
> there might be an unknown edge case in Kirks recent  UFS integrity changes). 
> I suspect that the 4th
> boot loader will have the same issue, but a different error message.
> 
> Others have reported issues with GELI, but that's not in play here, If I'm 
> reading this correctly. Right?
> 
> Warner

Ye, thats why I was asking about loader_4th. I’m trying to spot the issue from 
ufs image sample. 

rgds,
toomas

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Warner Losh]

On Mon, May 30, 2022 at 4:26 AM David Wolfskill 
wrote:

> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > ...
> > Does loader_4th have same issue?
> > 
>
> I don't know; I hadn't tried it.  I will do so later today & report
> back.
>

So if it's only one system, and it's only UFS, then what does fsck of that
UFS system tell you?
The loader can't find its UFS filesystem to read the configuration from. So
either its having trouble
finding the device (unlikely since that code hasn't changed in a long
time), or its having heartburn
with the UFS system for some reason it's being silent about (within the
realm of possibilities because
there might be an unknown edge case in Kirks recent  UFS integrity
changes). I suspect that the 4th
boot loader will have the same issue, but a different error message.

Others have reported issues with GELI, but that's not in play here, If I'm
reading this correctly. Right?

Warner

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Warner Losh]

On Mon, May 30, 2022 at 4:33 AM Jeffrey Bouquet 
wrote:

>
>
> On Sun, 29 May 2022 18:26:03 -0700, David Wolfskill 
> wrote:
>
> > On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
> > > Sorry for top posting...
> > >
> > > Did you upgrade your boot blocks?
> >
> > Thanks for the reply!
> >
> > Hmmm  Well, every time I rebuild FreeBSD head, the last step
> > just after "make installworld" and before the reboot is:
> >
> > # gpart bootcode -b /boot/boot /dev/ada0s4
> >
> > So *those* get updated.
> >
> > I haven't updated from /boot/boot0 recently (and have a requirement that
> > whatever is in the MBR is able to boot stable/12, stable/13, and head).
> >
> > Is updating (from head's /boot/bot0) recommended at this point?
> > > 
> >
> > (And in case it wasn't obvious, I made a silly typo in the Subject; it
> > should have read:
> >
> > | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> > |  main-n255828-18054d0220c
> >
> > Sorry: I don't have loader messages showing up on serial console on that
> > machine at this point, so I had hand-typed it from memory and managed to
> > elide a letter.)
> >
> > Peace,
> > david
> > --
> > David H. Wolfskill  da...@catwhisker.org
> > "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> > and is leading Russia into a ditch." - Egor Polyakov & Alexandra
> Miroshnikova
> >
> > See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
>
> I've never heard of that. Why isnt it in UPDATING?


Re updating boot blocks: It's not a requirement. It's a diagnostic question
to see what code we're dealing with.
The only time it's been required was the ZFS update to OpenZFS after a
zpool upgrade because the latter
introduced new features the old boot blocks would reject as being a valid
ZFS that it recognized.

Warner

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
> ...
> 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
> 

I (just) checked; after switching back to the Lua loader, the currdev
variable is set to "disk0s4a:", which is correct for my case.

Trying loader's "lsdev" command shows the expected disks, slices, and
partitions, correctly identified as FreeBSD UFS, swap, or ZFS.

Trying to (e.g.) "ls disk0s4a:" fails, saying that it can't find /.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
> ...
> 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
> 

Thanks!  I'll take a look -- though I am not using GELI-encryption on
anything needed up to the transition to multi-user mode (except for
swap).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Alastair Hogge]

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 d...@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

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 03:26:45AM -0700, David Wolfskill wrote:
> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > ... 
> > Does loader_4th have same issue?
> > 
> 
> I don't know; I hadn't tried it.  I will do so later today & report
> back.
> 

After updating sources from main-n255867-245b056556e to
main-n255871-7468332f551, the behavior with the Lua loader was the same:
it whined that it couldn't find /boot/lua/loader.lua, claiming "No such
file or directory" and it had not loaded anything.

I rebooted from one of the stabe/* slices and removed "loader"
and "zfsloader," then made them (hard) links to loader_4th.

On reboot, the (Forth) loader whined that it couldn't load "kernel" --
and as was the case with the Lua loader, it had not loaded anything.

So while the messages were a little different, the aspect of the
behavior that the loader was unable to load anything -- apparently
because it was unable to find anything to load -- remains quite similar,
AFAICT.

I had (as mentioned yesterday) run a manual "fsck" on the head / and
/usr file systems.  fsck asked me if I wanted to "ADD SUPERBLOCK
CHECK-HASH PROTECTION"; after a bit of dithering on my part, I told it
"yes."

I should also mention that the file systems are UFS+SU -- and not
(e.g.), UFS+SUJ.

Finally, I remind folks that I am not seeing this at all on the laptops
-- they Just Work (as usual).

Thanks again for spending time on this!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Jeffrey Bouquet]

On Sun, 29 May 2022 18:26:03 -0700, David Wolfskill  
wrote:

> On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
> > Sorry for top posting...
> > 
> > Did you upgrade your boot blocks?
> 
> Thanks for the reply!
> 
> Hmmm  Well, every time I rebuild FreeBSD head, the last step
> just after "make installworld" and before the reboot is:
> 
> # gpart bootcode -b /boot/boot /dev/ada0s4
> 
> So *those* get updated.
> 
> I haven't updated from /boot/boot0 recently (and have a requirement that
> whatever is in the MBR is able to boot stable/12, stable/13, and head).
> 
> Is updating (from head's /boot/bot0) recommended at this point?
> > 
> 
> (And in case it wasn't obvious, I made a silly typo in the Subject; it
> should have read:
> 
> | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> |  main-n255828-18054d0220c
> 
> Sorry: I don't have loader messages showing up on serial console on that
> machine at this point, so I had hand-typed it from memory and managed to
> elide a letter.)
> 
> Peace,
> david
> -- 
> David H. Wolfskill  da...@catwhisker.org
> "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova
> 
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.


I've never heard of that. Why isnt it in UPDATING? 

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> ... 
> Does loader_4th have same issue?
> 

I don't know; I hadn't tried it.  I will do so later today & report
back.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Filippo Moretti]

 
I have the same issue after installing my custom kernel and I did not run 
gpart bootcode -bIt was never needed before.FilippoIs there a way to recover 
the system?
On Monday, May 30, 2022 at 07:41:50 AM GMT+2, Toomas Soome  
wrote:  
 
 
> On 30. May 2022, at 04:26, David Wolfskill  wrote:
> 
> On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
>> Sorry for top posting...
>> 
>> Did you upgrade your boot blocks?
> 
> Thanks for the reply!
> 
> Hmmm  Well, every time I rebuild FreeBSD head, the last step
> just after "make installworld" and before the reboot is:
> 
> # gpart bootcode -b /boot/boot /dev/ada0s4
> 
> So *those* get updated.
> 
> I haven't updated from /boot/boot0 recently (and have a requirement that
> whatever is in the MBR is able to boot stable/12, stable/13, and head).
> 
> Is updating (from head's /boot/bot0) recommended at this point?
>> 
> 
> (And in case it wasn't obvious, I made a silly typo in the Subject; it
> should have read:
> 
> | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> |  main-n255828-18054d0220c
> 
> Sorry: I don't have loader messages showing up on serial console on that
> machine at this point, so I had hand-typed it from memory and managed to
> elide a letter.)
> 

Does loader_4th have same issue?

Rgds,
Toomas 

> Peace,
> david
> -- 
> David H. Wolfskill                              da...@catwhisker.org
> "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova
> 
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
  

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Toomas Soome]

> On 30. May 2022, at 04:26, David Wolfskill  wrote:
> 
> On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
>> Sorry for top posting...
>> 
>> Did you upgrade your boot blocks?
> 
> Thanks for the reply!
> 
> Hmmm  Well, every time I rebuild FreeBSD head, the last step
> just after "make installworld" and before the reboot is:
> 
> # gpart bootcode -b /boot/boot /dev/ada0s4
> 
> So *those* get updated.
> 
> I haven't updated from /boot/boot0 recently (and have a requirement that
> whatever is in the MBR is able to boot stable/12, stable/13, and head).
> 
> Is updating (from head's /boot/bot0) recommended at this point?
>> 
> 
> (And in case it wasn't obvious, I made a silly typo in the Subject; it
> should have read:
> 
> | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> |  main-n255828-18054d0220c
> 
> Sorry: I don't have loader messages showing up on serial console on that
> machine at this point, so I had hand-typed it from memory and managed to
> elide a letter.)
> 

Does loader_4th have same issue?

Rgds,
Toomas 

> Peace,
> david
> -- 
> David H. Wolfskill  da...@catwhisker.org
> "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova
> 
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: Binary data

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[David Wolfskill]

On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
> Sorry for top posting...
> 
> Did you upgrade your boot blocks?

Thanks for the reply!

Hmmm  Well, every time I rebuild FreeBSD head, the last step
just after "make installworld" and before the reboot is:

# gpart bootcode -b /boot/boot /dev/ada0s4

So *those* get updated.

I haven't updated from /boot/boot0 recently (and have a requirement that
whatever is in the MBR is able to boot stable/12, stable/13, and head).

Is updating (from head's /boot/bot0) recommended at this point?
> 

(And in case it wasn't obvious, I made a silly typo in the Subject; it
should have read:

| Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
|  main-n255828-18054d0220c

Sorry: I don't have loader messages showing up on serial console on that
machine at this point, so I had hand-typed it from memory and managed to
elide a letter.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c

[Warner Losh]

Sorry for top posting...

Did you upgrade your boot blocks?

Warner

On Sun, May 29, 2022, 5:11 PM 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 d...@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:
>
> commit 076002f24d35962f0d21f44bfddd34ee4d7f015d
> Author: Kirk McKusick 
> Date:   Fri May 27 12:21:11 2022 -0700
>
> Do comprehensive UFS/FFS superblock integrity checks when reading a
> superblock.
>
> Historically only minimal checks were made of a superblock when it
> was read in as it was assumed that fsck would have been run to...
>
> -- which doesn't seem a likely culprit to me).
>
> That said, I am powering freebeast up, and plan to run a manual
> full fsck on the "head" slice's root file system  Maybe a few
> others, while I'm here. :-}
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra
> Miroshnikova
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>