Re: Updating EFI boot loader results in boot hangup

[Idwer Vollering]

$ sudo camcontrol devlist
  at scbus0 target 0 lun 0 (pass0,ada0)
  at scbus1 target 0 lun 0 (pass1,ada1)

$ gpart show ada0 ada1
=>40  1953525088  ada0  GPT  (932G)
  401024 1  freebsd-boot  (512K)
1064 984- free -  (492K)
2048 4194304 2  freebsd-swap  (2.0G)
 4196352  1949327360 3  freebsd-zfs  (930G)
  19535237121416- free -  (708K)

=>40  1953525088  ada1  GPT  (932G)
  401024 1  freebsd-boot  (512K)
1064 984- free -  (492K)
2048 4194304 2  freebsd-swap  (2.0G)
 4196352  1949327360 3  freebsd-zfs  (930G)
  19535237121416- free -  (708K)

Op wo 17 aug. 2022 om 00:56 schreef Tomoaki AOKI :
>
> On Mon, 15 Aug 2022 21:35:52 -0600
> Warner Losh  wrote:
>
> > On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura  wrote:
> >
> > > From: Yasuhiro Kimura 
> > > Subject: Re: Updating EFI boot loader results in boot hangup
> > > Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)
> > >
> > > > From: Yasuhiro Kimura 
> > > > Subject: Updating EFI boot loader results in boot hangup
> > > > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
> > > >
> > > >> I made regular update of my 14-CURRENT amd64 system from
> > > >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> > > >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> > > >> boot hangup as following.
> > > >>
> > > >>
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> > > >>
> > > >> If I restore previous loader file (that is, loader.efi of
> > > >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> > > >> system boots successfully.
> > > >
> > > > I submitted the problem to FreeBSD Bugzilla.
> > > >
> > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
> > > >
> > > > Best Regards.
> > >
> > > d98de744050 is committed. So I tested it with following steps.
> > >
> > > 1. Check out the commit.
> > > 2. cd /usr/src/stand
> > > 3. make
> > > 4. make install
> > > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
> > > 6. shutdown -r now
> > >
> > > And system boots successfully. But while efi loader is workding a lot
> > > of messages are displayed as following.
> > >
> > >
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png
> >
> >
> > Would you be able to share camcontrol devlist output? Privately if need be.
> > And have any of these disks ever held ufs filesystems??
> >
> > Warner
> >
> >
> > > ---
> > > Yasuhiro Kimura
>
> Just a "me too" info. I have (usually not mounted for test) UFS on ada0.
> (Now the UFS contains outdated [SVN era] root partition of main.)
>
> % camcontrol devlist
>   at scbus0 target 0 lun 0 (pass0,ada0)
>at scbus1 target 0 lun 0 (ses0,pass1)
>   at scbus2 target 0 lun 1
> (pass2,nda0)
>
> % gpart show nda0
> =>40  3907029088  nda0  GPT  (1.8T)
>   402008- free -  (1.0M)
> 2048 1126400 1  efi  (550M)
>  11284482048 2  freebsd-boot  (1.0M)
>  1130496  3770679296 3  freebsd-zfs  (1.8T)
>   3771809792   135219200 4  freebsd-swap  (64G)
>   3907028992 136- free -  (68K)
>
>
> % gpart show ada0
> =>40  3907029088  ada0  GPT  (1.8T)
>   402008- free -  (1.0M)
> 2048 1126400 1  efi  (550M)
>  11284482048 2  freebsd-boot  (1.0M)
>  1130496  3749707776 3  freebsd-zfs  (1.7T)
>   375083827220971520 4  freebsd-ufs  (10G)
>   3771809792   135219200 5  freebsd-swap  (64G)
>   3907028992 136- free -  (68K)
>
>
> --
> Tomoaki AOKI
>

Windows Subsystem for FreeBSD?

[Nuno Teixeira]

Hello to all!

Today I found a new thing that might be interesting:
Windows Subsystem for Linux or WSL (url here
)

I've didn't tried it yet but it makes me think if there are some advantages
if WS were available to FreeBSD.

Cheers,
-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: Windows Subsystem for FreeBSD?

[Patrick M. Hausen]

Hi all,

> Am 17.08.2022 um 15:48 schrieb Nuno Teixeira :
> Today I found a new thing that might be interesting:
> Windows Subsystem for Linux or WSL (url here)
> 
> I've didn't tried it yet but it makes me think if there are some advantages 
> if WS were available to FreeBSD.

You understood this means running Linux applications
unmodified on Windows, not the other way round?

Kind regards,
Patrick

Re: Updating EFI boot loader results in boot hangup

[Patrick M. Hausen]

Hi all,

> Am 17.08.2022 um 13:48 schrieb Idwer Vollering :
> 
> $ sudo camcontrol devlist
>   at scbus0 target 0 lun 0 (pass0,ada0)
>   at scbus1 target 0 lun 0 (pass1,ada1)
> 
> $ gpart show ada0 ada1
> =>40  1953525088  ada0  GPT  (932G)
>  401024 1  freebsd-boot  (512K)
>1064 984- free -  (492K)
>2048 4194304 2  freebsd-swap  (2.0G)
> 4196352  1949327360 3  freebsd-zfs  (930G)
>  19535237121416- free -  (708K)
> 
> =>40  1953525088  ada1  GPT  (932G)
>  401024 1  freebsd-boot  (512K)
>1064 984- free -  (492K)
>2048 4194304 2  freebsd-swap  (2.0G)
> 4196352  1949327360 3  freebsd-zfs  (930G)
>  19535237121416- free -  (708K)

This system uses legacy boot, not EFI.

Kind regards,
Patrick

Re: Windows Subsystem for FreeBSD?

[Miguel C]

I've used it quite a bit on Windows since the early days.

In WSL v1 it was pretty much what linuxolator is in FreeBSD, it was just
emulation and translation of syscalls from linux to windows and it was
mostly limited in the same way linux emulation is on FreeBSD in fact GUI
wise I'de say it was much more limited since i.e one could not run GUI
Linux apps on Windows or call Windows GUI apps on WSL, you couldn't even
run services that require a network layer, like nginx mysql etc.

However, it has evolved since and with WSL2 all of the above is possible,
this is because they are using an approach similar to how docker runs on
macOS, it's a lightweith Linux VM running the linux kernel, no need for
syscall translation.

I'm not sure if you mean bring this to FreeBSD as in Linux Subsystem as
implemented here to FreeBSD or have WSL also run FreeBSD not just Linux.

But the latter makes no sense, this would need to be done by Microsoft and
I'm not quite sure if there's any advantage to them.

However, if you mean to achieve the same level of linux compatibility, that
would be quite interesting, I think linux emulation was always a great
thing on FreeBSD but it was always limited in the same ways as WSL1.


One of the advantage of having something like this might be finally getting
docker on a FreeBSD host. This is after all how it works on macOS, and on
recent versions its actually using apple's lightweight hypervisor aka
"hypervisor.framework". And of course it would allow FreeBSD desktop users
to run some software that only works on Linux but without the limitations
of not being able to handle all miscalls.

Beadm can't create snapshot

[Thomas Laus]

I attempted to create a ZFS snapshot after upgrading this morning and 
received this error


# beadm create n257443
cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
#

My version info:

14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 
17 08:15:27 EDT 2022


There was not any information in UPDATING about any required ZFS 
configuration changes required nor any ZFS flags that listed 
'snapshots_changed' as something that needed a new value.  There is 
actually a new snapshot created, but 'beadm list' does not show it and 
the boot menu does not have it listed.


Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Non EFI boot issue

[Thomas Laus]

Another issue with the update today.  This update went well on all of my 
PC's that use EFI but spews a lot of disturbing messages on my only 
laptop without an EFI BIOS:


Attempted recovery for standard superblock: failed
Attempt to find boot zone recovery data: failed

It jumps to what is normally Menu item 6 and then successfully boots.

My update version information:

FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 17 08:15:27 
EDT 2022


All of my gpart utilities list, show and status have no errors.

Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: Beadm can't create snapshot

[Ryan Moeller]

On 8/17/22 10:35 AM, Thomas Laus wrote:
I attempted to create a ZFS snapshot after upgrading this morning and 
received this error


# beadm create n257443
cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
#



This looks like a bug in beadm. It must be trying to set the 
snapshots_changed property when cloning the snapshot for the BE, but the 
property is of course readonly.


-Ryan




My version info:

14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 
17 08:15:27 EDT 2022


There was not any information in UPDATING about any required ZFS 
configuration changes required nor any ZFS flags that listed 
'snapshots_changed' as something that needed a new value.  There is 
actually a new snapshot created, but 'beadm list' does not show it and 
the boot menu does not have it listed.


Tom

Re: Beadm can't create snapshot

[Patrick M. Hausen]

Hi all,

> Am 17.08.2022 um 18:05 schrieb Ryan Moeller :
> 
> 
> On 8/17/22 10:35 AM, Thomas Laus wrote:
>> I attempted to create a ZFS snapshot after upgrading this morning and 
>> received this error
>> 
>> # beadm create n257443
>> cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
>> #
> 
> 
> This looks like a bug in beadm.

Isn't beadm retired in favour of bectl?

Kind regards,
Patrick

Re: Beadm can't create snapshot

[Ryan Moeller]

On 8/17/22 12:05 PM, Ryan Moeller wrote:


On 8/17/22 10:35 AM, Thomas Laus wrote:
I attempted to create a ZFS snapshot after upgrading this morning and 
received this error


# beadm create n257443
cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
#



This looks like a bug in beadm. It must be trying to set the 
snapshots_changed property when cloning the snapshot for the BE, but 
the property is of course readonly.


-Ryan



I took a closer look at what beadm is doing and this appears to be a bug 
in the property after all. beadm filters by source "local" or "received" 
and for "snapshots_changed" the source is "local" when it should be "-" 
like other readonly properties. We'll get this fixed ASAP.


-Ryan






My version info:

14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed 
Aug 17 08:15:27 EDT 2022


There was not any information in UPDATING about any required ZFS 
configuration changes required nor any ZFS flags that listed 
'snapshots_changed' as something that needed a new value.  There is 
actually a new snapshot created, but 'beadm list' does not show it 
and the boot menu does not have it listed.


Tom

Re: 24.3. Updating Bootcode

[Nuno Teixeira]

Hi,

And it's done:
---
 Boot0007* FreeBSD-14
HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader.efi)
 nvd0p1:/efi/freebsd/loader.efi
/boot/efi//efi/freebsd/loader.efi
+Boot0006* FreeBSD-14_old
HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader-old.efi)
 nvd0p1:/efi/freebsd/loader-old.efi
/boot/efi//efi/freebsd/loader-old.efi
 Boot0004* Windows Boot Manager
HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
   da1p1:/EFI/Microsoft/Boot/bootmgfw.efi
(null)
 Boot* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
---
and I can choose "FreeBSD-14"(/efi/freebsd/loader.efi),
"FreeBSD-14_old"(/efi/freebsd/loader-old.efi) and "EFI Hard
Drive"(legacy /efi/bootx64.efi) from BIOS.

NOTE: efibootmgr(8) example is:
---
efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
  ^^^
---
But I choosed "efi" instead of "EFI"...

Thanks all for helping me understand it!

Cheers,


Warner Losh  escreveu no dia terça, 16/08/2022 à(s) 18:19:

>
>
> On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira  wrote:
>
>> Hi Toomas,
>>
>> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page
>>> 499) is suggesting to use structure like:
>>>
>>> /efi//…
>>>
>>> And to use this suggestion, it means the UEFI Boot Manager needs to be
>>> configured (see efibootmgr(8)).
>>>
>>> Therefore, once you have set up OS specific setup, there is no use for
>>> default (/efi/boot/…) and you need to update one or another, but not
>>> both.
>>>
>>
>> FreeBSD have /efi/freebsd/... but it's not configured in efibootmgr:
>>
>
> The current default installer will do this, but older upgraded systems
> don't do this by default. Likely you are looking at an older
> system and/or one of the 'bad actors' that reset this stuff between boots.
>
>
>> efibootmgr -v:
>> ---
>> BootOrder  : 0004, , 2002, 2003, 2001
>> Boot0004* Windows Boot Manager
>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
>>da0p1:/EFI/Microsoft/Boot/bootmgfw.efi
>> (null)
>> +Boot* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>>  Boot2002* EFI DVD/CDROM
>>  Boot2003* EFI Network
>>  Boot2001* EFI USB Device
>> ---
>> so boot is definitely using /efi/boot/bootx64.efi @Boot
>>
>
> In your case, that's true. The "EFI Hard Drive" is a default entry the
> UEFI BIOS created for you.
>
>
>> I think I can create a new boot:
>> ---
>> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
>> (and make it active)
>> efibootmgr -a -b 
>> ---
>> and create other for loader.efi.old in case of problems.
>>
>
> Yes.
>
>
>> In this case I will need only update /efi/freebsd/loader.efi.
>>
>> Q: for what has been said in mailing, boot is compiled in /usr/src/stand,
>> isn't a good idea that when it install new boot it backup old boot like
>> /boot/kernel -> /boot/kernel.old?
>>
>
> Yes. In fact that's what's done, but only for the BIOS version. We should
> do the same for efi but don't seem to do so currently. But that's likely
> tied up behind issues of installing things automatically into the ESP on
> 'installworld'.
>
> Warner
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: 24.3. Updating Bootcode

[Nuno Teixeira]

*** and "EFI Hard Drive"(legacy /efi/boot/bootx64.efi) from BIOS.
   

Nuno Teixeira  escreveu no dia quarta, 17/08/2022 à(s)
19:14:

> Hi,
>
> And it's done:
> ---
>  Boot0007* FreeBSD-14
> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader.efi)
>  nvd0p1:/efi/freebsd/loader.efi
> /boot/efi//efi/freebsd/loader.efi
> +Boot0006* FreeBSD-14_old
> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader-old.efi)
>  nvd0p1:/efi/freebsd/loader-old.efi
> /boot/efi//efi/freebsd/loader-old.efi
>  Boot0004* Windows Boot Manager
> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
>da1p1:/EFI/Microsoft/Boot/bootmgfw.efi
> (null)
>  Boot* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
> ---
> and I can choose "FreeBSD-14"(/efi/freebsd/loader.efi),
> "FreeBSD-14_old"(/efi/freebsd/loader-old.efi) and "EFI Hard
> Drive"(legacy /efi/bootx64.efi) from BIOS.
>
> NOTE: efibootmgr(8) example is:
> ---
> efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
>   ^^^
> ---
> But I choosed "efi" instead of "EFI"...
>
> Thanks all for helping me understand it!
>
> Cheers,
>
>
> Warner Losh  escreveu no dia terça, 16/08/2022 à(s) 18:19:
>
>>
>>
>> On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira 
>> wrote:
>>
>>> Hi Toomas,
>>>
>>> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page
 499) is suggesting to use structure like:

 /efi//…

 And to use this suggestion, it means the UEFI Boot Manager needs to be
 configured (see efibootmgr(8)).

 Therefore, once you have set up OS specific setup, there is no use for
 default (/efi/boot/…) and you need to update one or another, but not
 both.

>>>
>>> FreeBSD have /efi/freebsd/... but it's not configured in efibootmgr:
>>>
>>
>> The current default installer will do this, but older upgraded systems
>> don't do this by default. Likely you are looking at an older
>> system and/or one of the 'bad actors' that reset this stuff between boots.
>>
>>
>>> efibootmgr -v:
>>> ---
>>> BootOrder  : 0004, , 2002, 2003, 2001
>>> Boot0004* Windows Boot Manager
>>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
>>>
>>>  da0p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
>>> +Boot* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>>>  Boot2002* EFI DVD/CDROM
>>>  Boot2003* EFI Network
>>>  Boot2001* EFI USB Device
>>> ---
>>> so boot is definitely using /efi/boot/bootx64.efi @Boot
>>>
>>
>> In your case, that's true. The "EFI Hard Drive" is a default entry the
>> UEFI BIOS created for you.
>>
>>
>>> I think I can create a new boot:
>>> ---
>>> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
>>> (and make it active)
>>> efibootmgr -a -b 
>>> ---
>>> and create other for loader.efi.old in case of problems.
>>>
>>
>> Yes.
>>
>>
>>> In this case I will need only update /efi/freebsd/loader.efi.
>>>
>>> Q: for what has been said in mailing, boot is compiled in
>>> /usr/src/stand, isn't a good idea that when it install new boot it backup
>>> old boot like /boot/kernel -> /boot/kernel.old?
>>>
>>
>> Yes. In fact that's what's done, but only for the BIOS version. We should
>> do the same for efi but don't seem to do so currently. But that's likely
>> tied up behind issues of installing things automatically into the ESP on
>> 'installworld'.
>>
>> Warner
>>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: Non EFI boot issue

[Warner Losh]

On Wed, Aug 17, 2022 at 9:10 AM Thomas Laus  wrote:

> Another issue with the update today.  This update went well on all of my
> PC's that use EFI but spews a lot of disturbing messages on my only
> laptop without an EFI BIOS:
>
> Attempted recovery for standard superblock: failed
> Attempt to find boot zone recovery data: failed
>

Took me a while to find a way to reproducer for this... I have have

https://reviews.freebsd.org/D36253

which should fix the issue.

Warner

It jumps to what is normally Menu item 6 and then successfully boots.
>
> My update version information:
>
> FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 17 08:15:27
> EDT 2022
>
> All of my gpart utilities list, show and status have no errors.
>
> Tom
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
>
>

Re: Updating EFI boot loader results in boot hangup

[Simon J. Gerraty]

Warner Losh  wrote:
> I think I broke it with my latest updates. I don't have a good ZFS testing 
> setup
> so I'm spending a little time enhancing the bootable image generator to have
> one that I can easily test boot with qemu.

FWIW bhyve is *excellent* for mucking about with EFI and loader in general.

I did all the UEFI support for Junos using bhyve (initially so I could
test LOADER_VERIEXEC), and I regurlarly use it to test various install
processes - pxe boot and net install, usb install, etc.

I build loader.efi from a branch off main, everyting else is from
stable/12 at present.

The combination of makefs, mkimg and bhyve - make hacking the low level
boot bits much safer.

Byhve is quick too - my Junos VM's take about 40-50s from start to login
prompt.

--sjg