Re: pkg scripts need updating

[Stefan Esser]

Am 15.05.24 um 02:21 schrieb Enji Cooper:



On May 14, 2024, at 7:19 AM, Michael Butler  wrote:

After commit aa48259f337100e79933d660fec8856371f761ed to src which removed 
security_daily_compat_var, I get these warnings daily..

aaron.protected-networks.net login failures:

aaron.protected-networks.net refused connections:
/usr/local/etc/periodic/security/405.pkg-base-audit: security_daily_compat_var: 
not found
/usr/local/etc/periodic/security/405.pkg-base-audit: security_daily_compat_var: 
not found
/usr/local/etc/periodic/security/405.pkg-base-audit: security_daily_compat_var: 
not found
/usr/local/etc/periodic/security/405.pkg-base-audit: security_daily_compat_var: 
not found
/usr/local/etc/periodic/security/405.pkg-base-audit: security_daily_compat_var: 
not found

Checking for security vulnerabilities in base (userland & kernel):
Database fetched: 2024-05-12T14:16-04:00
0 problem(s) in 0 installed package(s) found.
0 problem(s) in 0 installed package(s) found.
/usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: not 
found
/usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: not 
found
/usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: not 
found
/usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: not 
found
/usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: not 
found

Checking for packages with security vulnerabilities:
Database fetched: 2024-05-12T14:16-04:00
/usr/local/etc/periodic/security/460.pkg-checksum: security_daily_compat_var: 
not found
/usr/local/etc/periodic/security/460.pkg-checksum: security_daily_compat_var: 
not found
/usr/local/etc/periodic/security/460.pkg-checksum: security_daily_compat_var: 
not found

Checking for packages with mismatched checksums:


Have you tried emailing the issue to the committer/filing a bug report to bring 
this to their attention?
Cheers,


The messages are caused by running:

/usr/local/etc/periodic/security/405.pkg-base-audit
/usr/local/etc/periodic/security/460.pkg-checksum
/usr/local/etc/periodic/security/410.pkg-audit

These scripts have been installed by pkg-1.12.2 on my system ...

Best regards, STefan

Re: pkg scripts need updating

[Enji Cooper]

> On May 14, 2024, at 7:19 AM, Michael Butler  
> wrote:
> 
> After commit aa48259f337100e79933d660fec8856371f761ed to src which removed 
> security_daily_compat_var, I get these warnings daily..
> 
> aaron.protected-networks.net login failures:
> 
> aaron.protected-networks.net refused connections:
> /usr/local/etc/periodic/security/405.pkg-base-audit: 
> security_daily_compat_var: not found
> /usr/local/etc/periodic/security/405.pkg-base-audit: 
> security_daily_compat_var: not found
> /usr/local/etc/periodic/security/405.pkg-base-audit: 
> security_daily_compat_var: not found
> /usr/local/etc/periodic/security/405.pkg-base-audit: 
> security_daily_compat_var: not found
> /usr/local/etc/periodic/security/405.pkg-base-audit: 
> security_daily_compat_var: not found
> 
> Checking for security vulnerabilities in base (userland & kernel):
> Database fetched: 2024-05-12T14:16-04:00
> 0 problem(s) in 0 installed package(s) found.
> 0 problem(s) in 0 installed package(s) found.
> /usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: 
> not found
> /usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: 
> not found
> /usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: 
> not found
> /usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: 
> not found
> /usr/local/etc/periodic/security/410.pkg-audit: security_daily_compat_var: 
> not found
> 
> Checking for packages with security vulnerabilities:
> Database fetched: 2024-05-12T14:16-04:00
> /usr/local/etc/periodic/security/460.pkg-checksum: security_daily_compat_var: 
> not found
> /usr/local/etc/periodic/security/460.pkg-checksum: security_daily_compat_var: 
> not found
> /usr/local/etc/periodic/security/460.pkg-checksum: security_daily_compat_var: 
> not found
> 
> Checking for packages with mismatched checksums:

Have you tried emailing the issue to the committer/filing a bug report to bring 
this to their attention?
Cheers,
-Enji

signature.asc
Description: Message signed with OpenPGP

pkg scripts need updating

[Michael Butler]

After commit aa48259f337100e79933d660fec8856371f761ed to src which 
removed security_daily_compat_var, I get these warnings daily..


aaron.protected-networks.net login failures:

aaron.protected-networks.net refused connections:
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/405.pkg-base-audit: 
security_daily_compat_var: not found


Checking for security vulnerabilities in base (userland & kernel):
Database fetched: 2024-05-12T14:16-04:00
0 problem(s) in 0 installed package(s) found.
0 problem(s) in 0 installed package(s) found.
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/410.pkg-audit: 
security_daily_compat_var: not found


Checking for packages with security vulnerabilities:
Database fetched: 2024-05-12T14:16-04:00
/usr/local/etc/periodic/security/460.pkg-checksum: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/460.pkg-checksum: 
security_daily_compat_var: not found
/usr/local/etc/periodic/security/460.pkg-checksum: 
security_daily_compat_var: not found


Checking for packages with mismatched checksums:

Re: problem updating to CURRENT from source

[Robert Huff]

Gary Jennejohn asks:


Did you do a clean build?  This isn't mentioned in the "To rebuild
everything" text, but since you're building a different branch I
suspect that a clean build would be necessary.


 Define "clean build".
 The script for rebuilding world has both "make cleanworld" and 
"make cleandir"; is that sufficient?



   Respectfully,


Robert Huff

Re: problem updating to CURRENT from source

[Gary Jennejohn]

On Tue, 28 Nov 2023 12:01:47 -0500
Robert Huff  wrote:

> Hello:
>   I am trying to update a system running "14.0 CURRENT #0" to last
> night's Current using source.
>   I read the RELNOTES; I read the directions in UPDATING under "To
> rebuild everything".
>   I built world; built kernel; installed kernel; rebooted single
> user - no problem.
>   Ran "etcupdate -p", resolved some existing conflicts - check.
>
>   Ran "make installworld" and got:
>
> /bin/sh: /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue: not found
> rescue/sh check failed, installation aborted
> *** Error code 1
>
>   <"kicked in the head by a mule" look>
>   What have I done wrong?
>   More importantly: how do I fix it?
>
>

I built and installed the latest main source yesterday and I see in my
~/obj usr/src/amd64.amd64/rescue/rescue/rescue (but I was already
running FreeBSD-15).

Did you do a clean build?  This isn't mentioned in the "To rebuild
everything" text, but since you're building a different branch I
suspect that a clean build would be necessary.

--
Gary Jennejohn

problem updating to CURRENT from source

[Robert Huff]

Hello:
 I am trying to update a system running "14.0 CURRENT #0" to last 
night's Current using source.
 I read the RELNOTES; I read the directions in UPDATING under "To 
rebuild everything".
 I built world; built kernel; installed kernel; rebooted single 
user - no problem.
 Ran "etcupdate -p", resolved some existing conflicts - check. 


 Ran "make installworld" and got:

/bin/sh: /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue: not found
rescue/sh check failed, installation aborted
*** Error code 1

 <"kicked in the head by a mule" look>
 What have I done wrong?
 More importantly: how do I fix it?


Respectfully,


Robert Huff

Re: Updating motherboard BIOS without MS Windows

[Yasuhiro Kimura]

From: Nuno Teixeira 
Subject: Updating motherboard BIOS without MS Windows
Date: Sat, 11 Nov 2023 10:56:58 +

> Hello all,
> 
> Maybe not the best mailing to ask it but...
> 
> How do you update BIOS without Windows since most brands only have bios 
> software to windows?
> 
> I'm about to buy a new pc without windows license and I'm looking for brands 
> that have bios-cli that work in FreeBSD.
> 
> Thanks,

I always buy PC parts and assemble them by myself. Currently I have 3
PCs that use motherboard of different brands. And BIOS of all 3
motherbords includes the way to update itself without the help of OS
and/or utility program. Typically it works as following.

1. Enter BIOS menu.
2. Invoke the way to update BIOS.
3. Read input file from the media formatted with FAT file system.
4. Start updating BIOS.
5. After finished PC is rebooted.

On the other hand, new versions of BIOS are provided on the web site
of each brand as zip archive. So BIOS of motherboard can be updated
with following steps.

1. Download zip archive of BIOS file from web site of motherboard
   brand.
2. Extract BIOS file from the archive with `unzip`.
3. Insert USB memstick.
4. Format the memstick with `newfs_msdos`.
5. Mount the partion with `mount -t msdosfs` and copy BIOS file to it.
6. Reboot PC and enter BIOS menu.
7. Invoke the way to update BIOS.
8. Select BIOS file in the memstick as input.
9. Start update of BIOS.

Though I haven't check motherboards of eatch brand in detail, I think
it rather common for recent motherboards to provide similar
functionality.

It seems you are going to buy already assembled PC. And I'm not sure
if it's easy to know the brand and model of the motherboard used with
the PC. But if it isn't diffcult there is good chance you can select
and buy the PC that can update BIOS with similar way as above.

HTH.

---
Yasuhiro Kimura

Re: Updating motherboard BIOS without MS Windows

[Gary Jennejohn]

On Sat, 11 Nov 2023 10:56:58 +
Nuno Teixeira  wrote:

> Hello all,
>
> Maybe not the best mailing to ask it but...
>
> How do you update BIOS without Windows since most brands only have bios
> software to windows?
>
> I'm about to buy a new pc without windows license and I'm looking for
> brands that have bios-cli that work in FreeBSD.
>
> Thanks,
>

I've used a few different mainboards (Asus,  Gigabyte) and I've never
used Windows to update the BIOS.

Most BIOSes allow updating from 1) a thumb drive with DOS (FreeDOS)
installed and the BIOS image present or 2) just a BIOS image on a thumb
drive with a FAT32 file system.  I always use the second option.

You should be able to get the mainboard's manual as a PDF on-line and
then take a look at the BIOS description.  It should clearly describe
all supported options for updating the BIOS.

--
Gary Jennejohn

Re: Updating motherboard BIOS without MS Windows

[Kurt Jaeger]

Hi!

> How do you update BIOS without Windows since most brands only have bios
> software to windows?
> 
> I'm about to buy a new pc without windows license and I'm looking for
> brands that have bios-cli that work in FreeBSD.

There's

sysutils/flashrom

which allows to flash some BIOS systems. The website is here:

https://www.flashrom.org/

There's an old page which lists the hardware supported:

https://wiki.flashrom.org/Supported_hardware

-- 
p...@freebsd.org+49 171 3101372Now what ?

Re: Updating motherboard BIOS without MS Windows

[Bob Bishop]

Hi,

> On 11 Nov 2023, at 10:56, Nuno Teixeira  wrote:
> 
> Hello all,
> 
> Maybe not the best mailing to ask it but...
> 
> How do you update BIOS without Windows since most brands only have bios 
> software to windows?
> 
> I'm about to buy a new pc without windows license and I'm looking for brands 
> that have bios-cli that work in FreeBSD.

Can’t speak to specific brands but it’s becoming pretty common to be able to 
update firmware from UEFI shell.

> 
> Thanks,
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

--
Bob Bishop
r...@gid.co.uk

Re: Updating motherboard BIOS without MS Windows

[Lorenzo Salvadore]

On Saturday, November 11th, 2023 at 11:56, Nuno Teixeira  
wrote:


> Hello all,
>
> Maybe not the best mailing to ask it but...
>
> How do you update BIOS without Windows since most brands only have bios 
> software to windows?
>
> I'm about to buy a new pc without windows license and I'm looking for brands 
> that have bios-cli that work in FreeBSD.
>
> Thanks,
>

Hello,

I did such a thing about a year ago. I do not remember the details, but I
think I had downloaded a windows exe file, then I extracted the firmware from it
(I do not remember which software I used, maybe binwalk), I put it on a
usb key and finally I installed it using the utility in the motherboard,
available when powering the computer, before booting windows.

Cheers,

Lorenzo Salvadore

Re: Updating motherboard BIOS without MS Windows

[Goran Mekić]

On 11/11/23 11:56, Nuno Teixeira wrote:

Hello all,

Maybe not the best mailing to ask it but...

How do you update BIOS without Windows since most brands only have 
bios software to windows?


I'm about to buy a new pc without windows license and I'm looking for 
brands that have bios-cli that work in FreeBSD.


Thanks,

--
Nuno Teixeira
FreeBSD Committer (ports)


The board I have has one of the USB ports as "special". When you copy 
BIOS/UEFI update to it, stick it there and there's a button to update. I 
didn't try this myself, I read it from the board documentation, so I 
can't tell you the exact procedure and if it's doable from within FreeBSD.


Regards,
meka

Updating motherboard BIOS without MS Windows

[Nuno Teixeira]

Hello all,

Maybe not the best mailing to ask it but...

How do you update BIOS without Windows since most brands only have bios
software to windows?

I'm about to buy a new pc without windows license and I'm looking for
brands that have bios-cli that work in FreeBSD.

Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

[Kevin Bowling]

On Sat, Jul 22, 2023 at 1:21 AM Yasuhiro Kimura  wrote:
>
> From: Kevin Bowling 
> Subject: Re: Kernel panic after updating 14-CURRENT amd64 to 
> main-n264268-ff4633d9f89
> Date: Fri, 21 Jul 2023 21:44:13 -0700
>
> > Thanks, I have reverted for now.  Can you tell me which NIC is
> > implemented there?
>
> Output of `pciconf -lv` says as following.
>
> em0@pci0:0:3:0: class=0x02 rev=0x02 hdr=0x00 vendor=0x8086 device=0x100e 
> subvendor=0x8086 subdevice=0x001e
> vendor = 'Intel Corporation'
> device = '82540EM Gigabit Ethernet Controller'
> class  = network
> subclass   = ethernet
>
> Regards.

Thanks for the report, I've identified the errors and recommitted.

> ---
> Yasuhiro Kimura

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

[Yasuhiro Kimura]

From: Kevin Bowling 
Subject: Re: Kernel panic after updating 14-CURRENT amd64 to 
main-n264268-ff4633d9f89
Date: Fri, 21 Jul 2023 21:44:13 -0700

> Thanks, I have reverted for now.  Can you tell me which NIC is
> implemented there?

Output of `pciconf -lv` says as following.

em0@pci0:0:3:0: class=0x02 rev=0x02 hdr=0x00 vendor=0x8086 device=0x100e 
subvendor=0x8086 subdevice=0x001e
vendor = 'Intel Corporation'
device = '82540EM Gigabit Ethernet Controller'
class  = network
subclass   = ethernet

Regards.

---
Yasuhiro Kimura

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

[Kevin Bowling]

Thanks, I have reverted for now.  Can you tell me which NIC is
implemented there?

On Fri, Jul 21, 2023 at 12:45 PM Yasuhiro Kimura  wrote:
>
> From: Yasuhiro Kimura 
> Subject: Kernel panic after updating 14-CURRENT amd64 to 
> main-n264268-ff4633d9f89
> Date: Sat, 22 Jul 2023 02:50:23 +0900 (JST)
>
> > After updating my 14.0-CURRENT amd64 system from
> > main-n264162-f58378393fb to main-n264268-ff4633d9f89, kernel crashes
> > with panic as following.
> >
> > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png
>
> According to the result of bisect, kernel panic starts with following
> commit.
>
> --
> commit 95f7b36e8fac45092b9a4eea5e32732e979989f0
> Author: Kevin Bowling 
> Date:   Thu Jul 20 20:30:00 2023 -0700
>
> e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixes
>
> * em(4) obey administrative ifcaps for using hwcsum offload
> * em(4) obey administrative ifcaps for hw vlan receive tagging
> * em(4) add additional TSO6 ifcap, but disabled by default as is TSO4
> * lem(4) obey administrative ifcaps for using hwcsum offload
> * lem(4) add support for hw vlan receive tagging
> * lem(4) Add ifcaps for TSO offload experimentation, but disabled by
>   default due to errata and possibly missing txrx code.
> * lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around
>   full duplex links.  It may still be administratively enabled.
>
> Reviewed by:markj (previous version)
> MFC after:  2 weeks
> Differential Revision:  https://reviews.freebsd.org/D30072
> --
>
> Cc-ing to its committer.
>
> ---
> Yasuhiro Kimura

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

[Yasuhiro Kimura]

From: Yasuhiro Kimura 
Subject: Kernel panic after updating 14-CURRENT amd64 to 
main-n264268-ff4633d9f89
Date: Sat, 22 Jul 2023 02:50:23 +0900 (JST)

> After updating my 14.0-CURRENT amd64 system from
> main-n264162-f58378393fb to main-n264268-ff4633d9f89, kernel crashes
> with panic as following.
> 
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png

According to the result of bisect, kernel panic starts with following
commit.

--
commit 95f7b36e8fac45092b9a4eea5e32732e979989f0
Author: Kevin Bowling 
Date:   Thu Jul 20 20:30:00 2023 -0700

e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixes

* em(4) obey administrative ifcaps for using hwcsum offload
* em(4) obey administrative ifcaps for hw vlan receive tagging
* em(4) add additional TSO6 ifcap, but disabled by default as is TSO4
* lem(4) obey administrative ifcaps for using hwcsum offload
* lem(4) add support for hw vlan receive tagging
* lem(4) Add ifcaps for TSO offload experimentation, but disabled by
  default due to errata and possibly missing txrx code.
* lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around
  full duplex links.  It may still be administratively enabled.

Reviewed by:markj (previous version)
MFC after:  2 weeks
Differential Revision:  https://reviews.freebsd.org/D30072
--

Cc-ing to its committer.

---
Yasuhiro Kimura

Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

[Yasuhiro Kimura]

After updating my 14.0-CURRENT amd64 system from
main-n264162-f58378393fb to main-n264268-ff4633d9f89, kernel crashes
with panic as following.

https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png

---
Yasuhiro Kimura

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[Enji Cooper]

> On Jul 10, 2023, at 3:27 PM, Mark Millard  wrote:
> 
> On Jul 10, 2023, at 15:03, Mark Millard  > wrote:
> 
>> On Jul 10, 2023, at 11:42, The Doctor  wrote:
>> 
>>> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
 The subject line's question was prompted by
 . . ./hazmat/bindings/_openssl.abi3.so related notices
 in a kyua report:
 
 # kyua report --verbose 
 --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
  2>&1 | grep "Undefined symbol" | sort -u
 +ImportError: 
 /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
  Undefined symbol "ERR_GET_FUNC"
 ImportError: 
 /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
  Undefined symbol "ERR_GET_FUNC"
 ImportError: 
 /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
  Undefined symbol "ERR_GET_FUNC"
 
 It is possible that this is related to some oddities of my
 context for this. But I figured I'd ask the general question
 anyway.
 
>>> 
>>> No! The problem is that Python is calling an openssl 1.X function
>>> which is dropped in Opensss 3.X
>>> 
>>> Python nedds to fix that issue.
>> 
>> Well:
>> 
>> # strings 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
>>  | grep -i "3\.[0-9]*\.[0-9]"
>> OpenSSL 3.0.9 30 May 2023
>> 3.4.8
>> 
>> From what I read, 3.4.8 is too old and is known to have this issue and this
>> was fixed in a later version. I see references to "cryptography" needing to
>> be "at least 35.0.0 for OpenSSL 3.0 support" instead of "3.4.8" as one place
>> put it.
>> 
>> I've no clue of the details for python3.9 vs. python3.10 or python3.11 for
>> containing a sufficiently modern "cryptography" already in FreeBSD ports
>> (vs. not). But this may be more of a port-update issue than an up-stream
>> python issue -- or possibly just a "use python 3.? or later" issue for
>> some value for "?".
>> 
> 
> 35.0.0 of cryptography dates back to 2021-09-29.
> Current for cryptography is 41.0.1 (2023-06-01).
> It claims: "It supports Python 3.7+ and PyPy3
> 7.3.10+."
> 
> security/py-cryptography is at 3.4.8 (2021-08-24)
> for py39-cryptography and is, in-part, a FreeBSD
> ports issue as far as I can tell.
> 
> Looking, it seems it is at 3.4.8 for all @${PY_FLAVOR}
> instances. So trying python310 or python311 might
> well do no good for openssl 3.0 compatibility if they
> use security/py-cryptography .
> 
> (Note: I build my own ports via poudriere-devel .)

py-cryptography in ports doesn’t support OpenSSL 3. Please see this issue for 
more details: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853 
 .
Thanks,
-Enji


signature.asc
Description: Message signed with OpenPGP

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[Mark Millard]

On Jul 10, 2023, at 15:03, Mark Millard  wrote:

> On Jul 10, 2023, at 11:42, The Doctor  wrote:
> 
>> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
>>> The subject line's question was prompted by
>>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>>> in a kyua report:
>>> 
>>> # kyua report --verbose 
>>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>>  2>&1 | grep "Undefined symbol" | sort -u
>>> +ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> 
>>> It is possible that this is related to some oddities of my
>>> context for this. But I figured I'd ask the general question
>>> anyway.
>>> 
>> 
>> No! The problem is that Python is calling an openssl 1.X function
>> which is dropped in Opensss 3.X
>> 
>> Python nedds to fix that issue.
> 
> Well:
> 
> # strings 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
>  | grep -i "3\.[0-9]*\.[0-9]"
> OpenSSL 3.0.9 30 May 2023
> 3.4.8
> 
> From what I read, 3.4.8 is too old and is known to have this issue and this
> was fixed in a later version. I see references to "cryptography" needing to
> be "at least 35.0.0 for OpenSSL 3.0 support" instead of "3.4.8" as one place
> put it.
> 
> I've no clue of the details for python3.9 vs. python3.10 or python3.11 for
> containing a sufficiently modern "cryptography" already in FreeBSD ports
> (vs. not). But this may be more of a port-update issue than an up-stream
> python issue -- or possibly just a "use python 3.? or later" issue for
> some value for "?".
> 

35.0.0 of cryptography dates back to 2021-09-29.
Current for cryptography is 41.0.1 (2023-06-01).
It claims: "It supports Python 3.7+ and PyPy3
7.3.10+."

security/py-cryptography is at 3.4.8 (2021-08-24)
for py39-cryptography and is, in-part, a FreeBSD
ports issue as far as I can tell.

Looking, it seems it is at 3.4.8 for all @${PY_FLAVOR}
instances. So trying python310 or python311 might
well do no good for openssl 3.0 compatibility if they
use security/py-cryptography .

(Note: I build my own ports via poudriere-devel .)

===
Mark Millard
marklmi at yahoo.com

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[Mark Millard]

On Jul 10, 2023, at 11:42, The Doctor  wrote:

> On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
>> The subject line's question was prompted by
>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>> in a kyua report:
>> 
>> # kyua report --verbose 
>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>  2>&1 | grep "Undefined symbol" | sort -u
>> +ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> 
>> It is possible that this is related to some oddities of my
>> context for this. But I figured I'd ask the general question
>> anyway.
>> 
> 
> No! The problem is that Python is calling an openssl 1.X function
> which is dropped in Opensss 3.X
> 
> Python nedds to fix that issue.

Well:

# strings 
/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
 | grep -i "3\.[0-9]*\.[0-9]"
OpenSSL 3.0.9 30 May 2023
3.4.8

From what I read, 3.4.8 is too old and is known to have this issue and this
was fixed in a later version. I see references to "cryptography" needing to
be "at least 35.0.0 for OpenSSL 3.0 support" instead of "3.4.8" as one place
put it.

I've no clue of the details for python3.9 vs. python3.10 or python3.11 for
containing a sufficiently modern "cryptography" already in FreeBSD ports
(vs. not). But this may be more of a port-update issue than an up-stream
python issue -- or possibly just a "use python 3.? or later" issue for
some value for "?".


===
Mark Millard
marklmi at yahoo.com

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[The Doctor]

On Mon, Jul 10, 2023 at 08:56:22AM -0700, Mark Millard wrote:
> The subject line's question was prompted by
> . . ./hazmat/bindings/_openssl.abi3.so related notices
> in a kyua report:
> 
> # kyua report --verbose 
> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>  2>&1 | grep "Undefined symbol" | sort -u
> +ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> 
> It is possible that this is related to some oddities of my
> context for this. But I figured I'd ask the general question
> anyway.
>

No! The problem is that Python is calling an openssl 1.X function
which is dropped in Opensss 3.X

Python nedds to fix that issue.

> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

-- 
Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
"We should do good unless it inconveniences us," is not righteous thinking. 
-unknown Beware https://mindspring.com

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[Mark Millard]

On Jul 10, 2023, at 10:55, Mark Millard  wrote:

> On Jul 10, 2023, at 09:45, Mike Karels  wrote:
> 
>> On 10 Jul 2023, at 10:56, Mark Millard wrote:
>> 
>>> The subject line's question was prompted by
>>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>>> in a kyua report:
>>> 
>>> # kyua report --verbose 
>>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>>  2>&1 | grep "Undefined symbol" | sort -u
>>> +ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> ImportError: 
>>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>>  Undefined symbol "ERR_GET_FUNC"
>>> 
>>> It is possible that this is related to some oddities of my
>>> context for this. But I figured I'd ask the general question
>>> anyway.
>> 
>> I haven't seen this.  My v7 environments (chroot and /usr/lib32) have
>> only libssl.so.3, not .111, so they must be using OpenSSL 3.0.
> 
> But is the phython3 use by kyua of aarch64 code? armv7 code?
> 
> # file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, 
> ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
> /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped
> 
> So: armv7 for my lib32 testing activity.
> 
>> Which version of kyua is this running (32 or 64 bit)?
> 
> armv7 (so: 32-bit). This is using my way of causing more
> code to be armv7 instead of aarch64 processes for lib32
> testing than I expect your testing technique ends up
> with.
> 
> # file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, 
> ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
> /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped
> 
> For reference:
> 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so.30
> 
> As for the aarch4 boot environment:
> 
> /usr/lib/libssl.so
> /usr/lib/libssl.so.30

I forgot to list:

/usr/lib32/libssl.so.30
/usr/lib32/libssl.so

Sorry for the confusion.

> There are no *.111* files on the system other than some
> old log files or other archiving of old things in 2
> separate old-stuff directory trees that are not in
> use.


===
Mark Millard
marklmi at yahoo.com

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[Mark Millard]

On Jul 10, 2023, at 09:45, Mike Karels  wrote:

> On 10 Jul 2023, at 10:56, Mark Millard wrote:
> 
>> The subject line's question was prompted by
>> . . ./hazmat/bindings/_openssl.abi3.so related notices
>> in a kyua report:
>> 
>> # kyua report --verbose 
>> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>>  2>&1 | grep "Undefined symbol" | sort -u
>> +ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> ImportError: 
>> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>>  Undefined symbol "ERR_GET_FUNC"
>> 
>> It is possible that this is related to some oddities of my
>> context for this. But I figured I'd ask the general question
>> anyway.
> 
> I haven't seen this.  My v7 environments (chroot and /usr/lib32) have
> only libssl.so.3, not .111, so they must be using OpenSSL 3.0.

But is the phython3 use by kyua of aarch64 code? armv7 code?

# file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, ARM, 
EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
/libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped

So: armv7 for my lib32 testing activity.

> Which version of kyua is this running (32 or 64 bit)?

armv7 (so: 32-bit). This is using my way of causing more
code to be armv7 instead of aarch64 processes for lib32
testing than I expect your testing technique ends up
with.

# file /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua
/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua: ELF 32-bit LSB executable, ARM, 
EABI5 version 1 (FreeBSD), dynamically linked, interpreter 
/libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400092), not stripped

For reference:

/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so
/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib/libssl.so.30

As for the aarch4 boot environment:

/usr/lib/libssl.so
/usr/lib/libssl.so.30

There are no *.111* files on the system other than some
old log files or other archiving of old things in 2
separate old-stuff directory trees that are not in
use.

===
Mark Millard
marklmi at yahoo.com

Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[Mike Karels]

On 10 Jul 2023, at 10:56, Mark Millard wrote:

> The subject line's question was prompted by
> . . ./hazmat/bindings/_openssl.abi3.so related notices
> in a kyua report:
>
> # kyua report --verbose 
> --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
>  2>&1 | grep "Undefined symbol" | sort -u
> +ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
> ImportError: 
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
>  Undefined symbol "ERR_GET_FUNC"
>
> It is possible that this is related to some oddities of my
> context for this. But I figured I'd ask the general question
> anyway.

I haven't seen this.  My v7 environments (chroot and /usr/lib32) have
only libssl.so.3, not .111, so they must be using OpenSSL 3.0.

Which version of kyua is this running (32 or 64 bit)?

Mike

> ===
> Mark Millard
> marklmi at yahoo.com

Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"

[Mark Millard]

The subject line's question was prompted by
. . ./hazmat/bindings/_openssl.abi3.so related notices
in a kyua report:

# kyua report --verbose 
--results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785
 2>&1 | grep "Undefined symbol" | sort -u
+ImportError: 
/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "ERR_GET_FUNC"
ImportError: 
/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "ERR_GET_FUNC"
ImportError: 
/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "ERR_GET_FUNC"

It is possible that this is related to some oddities of my
context for this. But I figured I'd ask the general question
anyway.

===
Mark Millard
marklmi at yahoo.com

Re: Updating EFI boot loader results in boot hangup

[grarpamp]

On 8/nn/22, yet  top-posted:
> [snip]

https://www.idallen.com/topposting.html

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Yasuhiro Kimura 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Tue, 16 Aug 2022 12:01:42 +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

Today I made regular weekly update to main-n257521-97be6fced7d and now
loader.efi works fine without extra messages.

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Tomoaki AOKI]

On Wed, 17 Aug 2022 07:55:32 +0900
Tomoaki AOKI  wrote:

> 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
> 

Confirmed fixed at commit 6d645da0d49decc0352f27b8b5ff1983c611659d.
Thanks!

Sorry for the late report. I had been facing another, unrelated problem,
fixed at commit 545db925c3d5408e71e21432895770cd49fd2cf3.


-- 
Tomoaki AOKI

Re: 24.3. Updating Bootcode

[Nuno Teixeira]

@ main-n257521-97be6fced7db

Clean boot without warnings.
OK.

Thanks,

Nuno Teixeira  escreveu no dia quinta, 18/08/2022 à(s)
12:04:

> Forgot to send a screenshot
>  for
> loader.efi @ main-n257458-ef8b872301c5
> ( +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 )
>
> Someone talked about this warnings earlier:
> ---
> Attempted extraction of recovery data from stadard superblock: failed
> Attempt to find boot zone recovery data: failed
> (...)
> ---
> But it boots ok.
>
> Cheers,
>
> Nuno Teixeira  escreveu no dia quarta, 17/08/2022
> à(s) 19:18:
>
>> *** 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 (port

Re: Updating EFI boot loader results in boot hangup

[Warner Losh]

On Thu, Aug 18, 2022, 12:19 AM Simon J. Gerraty  wrote:

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

Yup. Use all that stuff. My issue was tooling (creating the bookable ZFS
images) as well as not being able to create an image that recreates the
problem. I've fixed the tooling issue, but used qemu so I could capture
stout to see if the tests pass/fail easily in a script. Bhyve, as far as I
know, can't do that without delving into separate expect scripts. And it
can't run arm binaries on x86...

I also use bhyve when I want to attach a debugger or need to test longer
running things.

But in this case it took a while to find how to reproduce... but I found
one and just pushed a fix.

Warner

>

Re: 24.3. Updating Bootcode

[Nuno Teixeira]

Forgot to send a screenshot
 for
loader.efi @ main-n257458-ef8b872301c5
( +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 )

Someone talked about this warnings earlier:
---
Attempted extraction of recovery data from stadard superblock: failed
Attempt to find boot zone recovery data: failed
(...)
---
But it boots ok.

Cheers,

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

> *** 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)
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)

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

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: 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: 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: 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
>

Re: Updating EFI boot loader results in boot hangup

[Jeffrey Bouquet]

On Wed, 17 Aug 2022 07:55:32 +0900, Tomoaki AOKI  
wrote:

> 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


Not following the thread closely, but should the CLI above be put in UPDATING 
for those, for example,
upgrading in-place from v13 to v14, with an explanation of why or what for? 

Re: Updating EFI boot loader results in boot hangup

[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

Re: 24.3. Updating Bootcode

[Warner Losh]

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

Re: 24.3. Updating Bootcode

[Warner Losh]

On Tue, Aug 16, 2022 at 3:49 AM Nuno Teixeira  wrote:

> Hello all,
>
> With so much discussion about updating boot, I feel confused about the
> correct procedure of doing it.
>
> Like being said there are a "24.3. Updating Bootcode" in Handbook (WIP)
> that points to some important manuals.
>
> There are 3 places where boot loader are:
>
>  ESP (EFI System Partition):
> 1 - (/boot/efi)/efi/boot/bootXXX.efi (default location)
>

Default for the boot loader, that is. By default we don't install here
anymore (though as a workaround
for broken BIOSes or those that don't properly save EFI env vars or that
change help to be helpful,
we'll park a copy here, this usually isn't updated).


> 2 - (/boot/efi)/efi/freebsd/loader.efi (FreeBSD reserved area)
>

This is what the boot usually uses on working systems.


> Operating System:
> 3 - /boot/loader.efi
>

This is only used when chain loaded from a legacy system that installed
boot1.efi, or in some cases
from a 'special needs' system that loads it from gptboot.efi.


> For what I've read we should:
>  - backup: `cp /boot/efi/efi/boot/bootXXX.efi
> /boot/efi/efi/boot/bootXXX.efi.bkp`
>

I'd recommend bootXXX-old.efi (or bootXXX-bkp.efi) since you'll be able to
run it from the EFI shell
if you are lucky enough to have one. The shell won't run the .bkp file.


>  - update: `cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`
>

Yes and no. You should likely update both this one and the one in
efi/freebsd as well since the latter
is more typically used (though your system may be one of the
sadly-too-sizable number of systems
that ignore the env vars and use the default removable media file).


> In this example we have a /boot/efi mount by the system, "/dev/XXXpN on
> /boot/efi (msdosfs, local)".
>

Yes.


> What about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is
> necessary to backup and update it too?
>

It's the primary thing that gets used most of the time. I'd certainly back
it up and update it.

Warner

Re: 24.3. Updating Bootcode

[Toomas Soome]

> On 16. Aug 2022, at 15:01, 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:
> 
> 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 <>

Yes, Boot does not specify file name, so it is using default path there.

> 
> 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.
> 
> 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?
> 

Boot loader update does not touch kernel, but when you do installkernel, that 
one will create backup copy for you. And, if you are using zfs root, you really 
should use boot environments.

rgds,
toomas

Re: 24.3. Updating Bootcode

[Nuno Teixeira]

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:

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

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.

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?

Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: 24.3. Updating Bootcode

[Toomas Soome]

> On 16. Aug 2022, at 12:49, Nuno Teixeira  wrote:
> 
> Hello all,
> 
> With so much discussion about updating boot, I feel confused about the 
> correct procedure of doing it.
> 
> Like being said there are a "24.3. Updating Bootcode" in Handbook (WIP) that 
> points to some important manuals.
> 
> There are 3 places where boot loader are:
> 
>  ESP (EFI System Partition):
> 1 - (/boot/efi)/efi/boot/bootXXX.efi (default location)
> 2 - (/boot/efi)/efi/freebsd/loader.efi (FreeBSD reserved area)
> Operating System:
> 3 - /boot/loader.efi
> 
> For what I've read we should:
>  - backup: `cp /boot/efi/efi/boot/bootXXX.efi 
> /boot/efi/efi/boot/bootXXX.efi.bkp`
>  - update: `cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`
> 
> In this example we have a /boot/efi mount by the system, "/dev/XXXpN on 
> /boot/efi (msdosfs, local)".
> 
> What about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is necessary 
> to backup and update it too?
> 

Hi!

I guess we need to expain a bit. EFI System Partition (ESP from now on,  
for mountpoint), can store both EFI boot programs and EFI applications 
(diagnostics, firmware update etc). This is the reason, the ESP size is not 
specified in UEFI specification.

EFI Boot program may be stored on default path /efi/boot/bootx64.efi 
(amd64), /efi/boot/bootia32.efi (i386 32-bit), 
/efi/boot/bootaarch64.efi for AARCH64 etc. It is default for case there is 
no UEFI Boot Manager set up for this media (like installation media on usb 
stick or cdrom, but also most systems support it with hdd).

Default path obviously does not cope with multi boot setups.

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.

hope this helps,
toomas

24.3. Updating Bootcode

[Nuno Teixeira]

Hello all,

With so much discussion about updating boot, I feel confused about the
correct procedure of doing it.

Like being said there are a "24.3. Updating Bootcode" in Handbook (WIP)
that points to some important manuals.

There are 3 places where boot loader are:

 ESP (EFI System Partition):
1 - (/boot/efi)/efi/boot/bootXXX.efi (default location)
2 - (/boot/efi)/efi/freebsd/loader.efi (FreeBSD reserved area)
Operating System:
3 - /boot/loader.efi

For what I've read we should:
 - backup: `cp /boot/efi/efi/boot/bootXXX.efi
/boot/efi/efi/boot/bootXXX.efi.bkp`
 - update: `cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`

In this example we have a /boot/efi mount by the system, "/dev/XXXpN on
/boot/efi (msdosfs, local)".

What about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is necessary
to backup and update it too?

Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Warner Losh 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Mon, 15 Aug 2022 21:35:52 -0600

> Would you be able to share camcontrol devlist output? Privately if
> need be.

root@rolling-vm-freebsd1[1001]# camcontrol devlist
at scbus0 target 0 lun 0 (pass0,ada0)
  at scbus1 target 0 lun 0 (cd0,pass1)
root@rolling-vm-freebsd1[1002]# 

> And have any of these disks ever held ufs filesystems??

No. ada0 consists of ESP, swap and ZFS.

root@rolling-vm-freebsd1[1002]# gpart show ada0
=>   40  209715120  ada0  GPT  (100G)
 40 532480 1  efi  (260M)
 532520   2008- free -  (1.0M)
 534528   67108864 2  freebsd-swap  (32G)
   67643392  142069760 3  freebsd-zfs  (68G)
  209713152   2008- free -  (1.0M)

root@rolling-vm-freebsd1[1003]#

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Warner Losh]

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
>
>

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

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

---
Yasuhiro Kimura

Re: bootx64.efi; and loader.efi in the FreeBSD reserved area (was: Updating EFI boot loader results in boot hangup)

[Warner Losh]

On Sun, Aug 14, 2022 at 7:52 AM Graham Perrin 
wrote:

> On 12/08/2022 17:54, Yasuhiro Kimura wrote:
>
> … amd64 … (/boot/efi/efi/freebsd/loader.efi) …
>
> Side note: please, why the FreeBSD reserved area?
>

When you create a boot variable using efibootmgr, it's better to specify
something that's not the default
binary. It's what Windows, Linux, etc do when they are installed and it
facilitates better multiboot when
the target OSes depend on the first stage efi boot loader (like FreeBSD and
Windows certainly do).

Warner

>
> I'm more familiar with /efi/boot/bootx64.efi for amd64.
>
> 
> 
>

Re: Updating EFI boot loader results in boot hangup

[Nuno Teixeira]

Isn't better just to mount -t msdos /dev/xxxpn /mnt and cp /boot/loader.efi
/mnt/efi/boot/bootx64.efi?

Pete Wright  escreveu no dia domingo, 14/08/2022 à(s)
22:58:

>
>
> On 8/14/22 13:26, Graham Perrin wrote:
>
> On 14/08/2022 20:26, Pete Wright wrote:
>
> … has anyone else who has been impacted by this been able to recover? …
>
> If you have multiple boot environments: do you have a non-affected BE
> (prior to c32dde3166922f55927764464d13f1bc9640f5f6)?
>
>
> So unfortunately i didn't have a recent BE, but I was able to do the
> following to get back up:
>
> 1. download latest CURRENT snapshot memdisk from ftp.freebsd.org and put
> it on a usb drive
> 2. boot via usb drive and enter live shell
> 3. load zfs kmod:
> kldload zfs
> 4. import zroot:
> zpool import -R /mnt/ zroot
> 5. mount ROOT filesystem:
> zfs mount zroot/ROOT/default
> 6. copy usb loader to zroot:
> cp /boot/loader /mnt/boot/loader
>
>
> i'd recommend just using boot environments, it's much easier and is
> specifically what they are for :)
>
> -pete
>
> --
> Pete wrightp...@nomadlogic.org
> @nomadlogicLA
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: Updating EFI boot loader results in boot hangup

[Pete Wright]

On 8/14/22 13:26, Graham Perrin wrote:

On 14/08/2022 20:26, Pete Wright wrote:

… has anyone else who has been impacted by this been able to recover? …
If you have multiple boot environments: do you have a non-affected BE 
(prior to c32dde3166922f55927764464d13f1bc9640f5f6)?


So unfortunately i didn't have a recent BE, but I was able to do the 
following to get back up:


1. download latest CURRENT snapshot memdisk from ftp.freebsd.org and put 
it on a usb drive

2. boot via usb drive and enter live shell
3. load zfs kmod:
    kldload zfs
4. import zroot:
    zpool import -R /mnt/ zroot
5. mount ROOT filesystem:
    zfs mount zroot/ROOT/default
6. copy usb loader to zroot:
    cp /boot/loader /mnt/boot/loader


i'd recommend just using boot environments, it's much easier and is 
specifically what they are for :)


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

Re: Updating EFI boot loader results in boot hangup

[Graham Perrin]

On 14/08/2022 20:26, Pete Wright wrote:

… has anyone else who has been impacted by this been able to recover? …
If you have multiple boot environments: do you have a non-affected BE 
(prior to c32dde3166922f55927764464d13f1bc9640f5f6)?

Re: Updating EFI boot loader results in boot hangup

[Warner Losh]

On Sun, Aug 14, 2022 at 1:26 PM Pete Wright  wrote:

> On Sun, Aug 14, 2022 at 10:26:32AM +0200, Stefan Esser wrote:
> > Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:
> > > Yes, Yasuhiro and I have the same error.
> >
> > Just a "me too", also on ZFS, on a Ryzen 3 based system.
> >
> > Booting the latest USB snapshot image worked, but not when I copy
> > the whole of /boot from that USB stick to my ZFS boot partition.
> >
> > The system is usable if I boot from USB and manually mount the ZFS
> > file systems over the USB boot image.
> >
>
> adding my voice to the chorus here of "me too". ryzen5/uefi/zfs setup.
>
> has anyone else who has been impacted by this been able to recover?  i
> can boot into a memstick image, and access my uefi shell via the bios -
> but i've never had to hack on btx like this before.
>
> any links or pointers would be appreciated!
>

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.

Warner

Re: Updating EFI boot loader results in boot hangup

[Pete Wright]

On Sun, Aug 14, 2022 at 10:26:32AM +0200, Stefan Esser wrote:
> Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:
> > Yes, Yasuhiro and I have the same error.
> 
> Just a "me too", also on ZFS, on a Ryzen 3 based system.
> 
> Booting the latest USB snapshot image worked, but not when I copy
> the whole of /boot from that USB stick to my ZFS boot partition.
> 
> The system is usable if I boot from USB and manually mount the ZFS
> file systems over the USB boot image.
>

adding my voice to the chorus here of "me too". ryzen5/uefi/zfs setup.

has anyone else who has been impacted by this been able to recover?  i
can boot into a memstick image, and access my uefi shell via the bios -
but i've never had to hack on btx like this before.

any links or pointers would be appreciated!

-pete

-- 
Pete Wright
p...@nomadlogic.org

bootx64.efi; and loader.efi in the FreeBSD reserved area (was: Updating EFI boot loader results in boot hangup)

[Graham Perrin]

On 12/08/2022 17:54, Yasuhiro Kimura wrote:


… amd64 … (/boot/efi/efi/freebsd/loader.efi) …


Side note: please, why the FreeBSD reserved area?

I'm more familiar with /efi/boot/bootx64.efi for amd64.

Re: Updating EFI boot loader results in boot hangup

[Toomas Soome]

ok, yes, there is something bad happening:

https://paste.ec/paste/4p6Tf7Bl#yD6QIahJs1U1SRryaKUCqOHDdf5YDUfvB-wBvwAmhV4 


second pointer is supposed to be pointer to device specific format function and 
on last visible line, it is clearly bad value there (BIOS loader code is below 
1MB line).

will see how long it will take to find the root cause:D

rgds,
toomas

> On 14. Aug 2022, at 11:26, Stefan Esser  wrote:
> 
> Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:
>> Yes, Yasuhiro and I have the same error.
> 
> Just a "me too", also on ZFS, on a Ryzen 3 based system.
> 
> Booting the latest USB snapshot image worked, but not when I copy
> the whole of /boot from that USB stick to my ZFS boot partition.
> 
> The system is usable if I boot from USB and manually mount the ZFS
> file systems over the USB boot image.
> 
> Failed boot log:
> 
>   https://people.freebsd.org/~se/ZFS-Boot-Failure.jpg
> 
> But I doubt that it adds any new information ...
> 

Re: Updating EFI boot loader results in boot hangup

[Stefan Esser]

Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:

Yes, Yasuhiro and I have the same error.


Just a "me too", also on ZFS, on a Ryzen 3 based system.

Booting the latest USB snapshot image worked, but not when I copy
the whole of /boot from that USB stick to my ZFS boot partition.

The system is usable if I boot from USB and manually mount the ZFS
file systems over the USB boot image.

Failed boot log:

https://people.freebsd.org/~se/ZFS-Boot-Failure.jpg

But I doubt that it adds any new information ...

Re: Updating EFI boot loader results in boot hangup

[Oleg Lelchuk]

Yes, Yasuhiro and I have the same error.

On Sat, Aug 13, 2022, 10:09 PM Yasuhiro Kimura  wrote:

> From: Warner Losh 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 20:01:03 -0600
>
> > UFS or ZFS?
> >
> > Warner
>
> ZFS in my case.
>
> ---
> Yasuhiro Kimura
>
>

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Warner Losh 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sat, 13 Aug 2022 20:01:03 -0600

> UFS or ZFS?
> 
> Warner

ZFS in my case.

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Warner Losh]

UFS or ZFS?

Warner

On Sat, Aug 13, 2022 at 7:31 PM Oleg Lelchuk  wrote:

> I don't understand what your command does. All I can see is that
> https://cgit.freebsd.org/src/commit/?id=ec9f3e776f39286ccec9915f38cca9729e6f9241
> causes the error that we currently see, and the commit that precedes it
> https://cgit.freebsd.org/src/commit/?id=ad759c73522efb606135e2891ac03864926b80a3
> causes a different kind of error.
>
> On Sat, Aug 13, 2022 at 8:58 PM Yasuhiro Kimura  wrote:
>
>> From: Oleg Lelchuk 
>> Subject: Re: Updating EFI boot loader results in boot hangup
>> Date: Sat, 13 Aug 2022 20:28:09 -0400
>>
>> > I can already see that commit
>> >
>> > c32dde3166922f55927764464d13f1bc9640f5f6 causes breakage, but the
>> commit that precedes it
>> >
>> > f197c0bf3e075286ccea32cd12023f3317474c5a doesn't cause breakage and the
>> system boots just fine with it. But
>> > the error that the c32dd commit causes is different from the error that
>> we see now, so maybe there is a
>> > possibility that one of the commits that follow it fixed the breakage,
>> but then yet another commit caused a
>> > different kind of breakage again.
>>
>> With the command `git bisect start --first-parent 9d16275c65b a69c0964625
>> -- stand`
>> I got just same result.
>>
>> ---
>> Yasuhiro Kimura
>>
>

Re: Updating EFI boot loader results in boot hangup

[Oleg Lelchuk]

I don't understand what your command does. All I can see is that
https://cgit.freebsd.org/src/commit/?id=ec9f3e776f39286ccec9915f38cca9729e6f9241
causes the error that we currently see, and the commit that precedes it
https://cgit.freebsd.org/src/commit/?id=ad759c73522efb606135e2891ac03864926b80a3
causes a different kind of error.

On Sat, Aug 13, 2022 at 8:58 PM Yasuhiro Kimura  wrote:

> From: Oleg Lelchuk 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 20:28:09 -0400
>
> > I can already see that commit
> >
> > c32dde3166922f55927764464d13f1bc9640f5f6 causes breakage, but the commit
> that precedes it
> >
> > f197c0bf3e075286ccea32cd12023f3317474c5a doesn't cause breakage and the
> system boots just fine with it. But
> > the error that the c32dd commit causes is different from the error that
> we see now, so maybe there is a
> > possibility that one of the commits that follow it fixed the breakage,
> but then yet another commit caused a
> > different kind of breakage again.
>
> With the command `git bisect start --first-parent 9d16275c65b a69c0964625
> -- stand`
> I got just same result.
>
> ---
> Yasuhiro Kimura
>

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Oleg Lelchuk 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sat, 13 Aug 2022 20:28:09 -0400

> I can already see that commit
> 
> c32dde3166922f55927764464d13f1bc9640f5f6 causes breakage, but the commit that 
> precedes it
> 
> f197c0bf3e075286ccea32cd12023f3317474c5a doesn't cause breakage and the 
> system boots just fine with it. But
> the error that the c32dd commit causes is different from the error that we 
> see now, so maybe there is a
> possibility that one of the commits that follow it fixed the breakage, but 
> then yet another commit caused a
> different kind of breakage again.

With the command `git bisect start --first-parent 9d16275c65b a69c0964625 -- 
stand`
I got just same result.

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Oleg Lelchuk]

I can already see that commit
c32dde3166922f55927764464d13f1bc9640f5f6
<https://cgit.freebsd.org/src/commit/?id=c32dde3166922f55927764464d13f1bc9640f5f6>
causes
breakage, but the commit that precedes it

f197c0bf3e075286ccea32cd12023f3317474c5a
<https://cgit.freebsd.org/src/commit/?id=f197c0bf3e075286ccea32cd12023f3317474c5a>
doesn't
cause breakage and the system boots just fine with it. But the error that
the c32dd commit causes is different from the error that we see now, so
maybe there is a possibility that one of the commits that follow it fixed
the breakage, but then yet another commit caused a different kind of
breakage again.

On Sat, Aug 13, 2022 at 7:41 PM Yasuhiro Kimura  wrote:

> From: Oleg Lelchuk 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 19:32:16 -0400
>
> > You can do make and make install in /usr/src/stand
>
> Thanks for letting me know. I'll try it.
>
> ---
> Yasuhiro Kimura
>
>

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Oleg Lelchuk 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sat, 13 Aug 2022 19:32:16 -0400

> You can do make and make install in /usr/src/stand

Thanks for letting me know. I'll try it.

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Oleg Lelchuk]

You can do make and make install in /usr/src/stand

On Sat, Aug 13, 2022 at 7:31 PM Yasuhiro Kimura  wrote:

> From: Warner Losh 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 16:59:55 -0600
>
> > Any chance of a bisect of which revision starts to fail?
> >
> > Warner
>
> I'll try it.
>
> Is it possbile to build only loader.efi without doing buildworld?
> I'd like to shorten the time to take for single step of bisect.
>
> ---
> Yasuhiro Kimura
>

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Warner Losh 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sat, 13 Aug 2022 16:59:55 -0600

> Any chance of a bisect of which revision starts to fail?
> 
> Warner

I'll try it.

Is it possbile to build only loader.efi without doing buildworld?
I'd like to shorten the time to take for single step of bisect.

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Warner Losh]

Any chance of a bisect of which revision starts to fail?

Warner

On Sat, Aug 13, 2022 at 4:49 PM Oleg Lelchuk  wrote:

> I experienced the same problem. I hope this bug will be fixed soon.
>
> On Sat, Aug 13, 2022 at 5:36 PM Yasuhiro Kimura  wrote:
>
>> 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.
>>
>> ---
>> Yasuhiro Kimura
>>
>>

Re: Updating EFI boot loader results in boot hangup

[Oleg Lelchuk]

I experienced the same problem. I hope this bug will be fixed soon.

On Sat, Aug 13, 2022 at 5:36 PM Yasuhiro Kimura  wrote:

> 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.
>
> ---
> Yasuhiro Kimura
>
>

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

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.

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Warner Losh]

On Sat, Aug 13, 2022 at 9:37 AM Nuno Teixeira  wrote:

> Hi Larry,
>
> boot off a memstick?
>>
> Yes, that's it.
> With it we can mount efi partition and use bkp efi file by renaming it.
>

Yup.


> I forgot that efi boot is restricted to use bootx64.efi (amd64) and my
> though was looking for a command to load bootx64.efi.old avoiding use of a
> memstick (e.g.).
>
I've tested it, and from now on I will update efi boot more often along
> with current tracking.
>

Kinda. You can create a new UEFI (not ZFS) boot environment that uses
something else. In addition, if you are fortunate enough to have EFI SHELL
in your BIOS and/or in your ESP, you can run any XXX.efi program in the
ESP, or any DOS partition...

I have a known good loader.efi that I use a special Boot variable so
that if I AFU my loader.efi in testing, it's easier to get back online,
though I also have shell.efi that I downloaded from the edk2 folks that
also helps me fix things... But I know I'm a bit of a special case

Warmer

Re: Updating EFI boot loader results in boot hangup

[Nuno Teixeira]

Hi Larry,

boot off a memstick?
>
Yes, that's it.
With it we can mount efi partition and use bkp efi file by renaming it.

I forgot that efi boot is restricted to use bootx64.efi (amd64) and my
though was looking for a command to load bootx64.efi.old avoiding use of a
memstick (e.g.).
I've tested it, and from now on I will update efi boot more often along
with current tracking.

Thanks

Re: Updating EFI boot loader results in boot hangup

[Tomoaki AOKI]

Or multiple installation in the same computer.

For me, main and stable/13 are installed in different drive.

So I can boot into healthy installation, mount problematic ESP,
and alter broken bootx64.efi with known-to-work one.

Usually, to boot into healthy installation, choose boot drive on UEFI
menu.


On Fri, 12 Aug 2022 15:26:08 -0500
Larry Rosenman  wrote:

> 
> 
> boot off a memstick?
> 
> On 08/12/2022 3:25 pm, Nuno Teixeira wrote:
> 
> > The problem is if boot is failing, how to mount and rename it?
> > 
> > I'm looking for a way, if possible, to boot directly bkp boot64x in 
> > case of failure.
> > I was hoping to find it in loader(8) or uefi(8)...
> > 
> > Larry Rosenman  escreveu no dia sexta, 12/08/2022 à(s) 
> > 21:09:
> > 
> > I would assume just rename the bootx64.old to bootx64.efi
> > 
> > and/or put it in a different directory that EFI can see
> > 
> > On 08/12/2022 3:03 pm, Nuno Teixeira wrote:
> > 
> > I'm searching without success to load a bkp loader in case of boot 
> > failure.
> > 
> > Upgrade process willl be like:
> > ---
> > mount -t msdosfs /dev/nvd0p1 /mnt
> > cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> > ---
> > 
> > I can't find the right docs to load bootx64.old.
> > Could you tell me what you did to solve your boot?
> > 
> > Thanks
> > 
> > Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 
> > à(s) 18:45: From: Nuno Teixeira 
> > Subject: Re: Updating EFI boot loader results in boot hangup
> > Date: Fri, 12 Aug 2022 18:26:11 +0100
> > 
> >> Hello Yasu,
> >> 
> >> Does it needes to update boot loader everytime that we upgrade 
> >> current?
> > 
> > No, you need not.
> > 
> >> The only time that I updated was a month ago because of zfs upgrade 
> >> and I need to practice how to boot
> >> loader bkp file :)
> > 
> > I update boot loader everytime because I'd like to do it :-).
> > And sometimes problem hits upon me like this time and I contribute to
> > debugging base system :-):-).
> > 
> > ---
> > Yasuhiro Kimura
> > 
> > --
> > 
> > Nuno Teixeira
> > FreeBSD Committer (ports)
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> 
> -- 
> 
> Nuno Teixeira
> FreeBSD Committer (ports)
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106


-- 
Tomoaki AOKI

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Nuno Teixeira 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Fri, 12 Aug 2022 21:03:02 +0100

> I'm searching without success to load a bkp loader in case of boot failure.
> 
> Upgrade process willl be like:
> ---
> mount -t msdosfs /dev/nvd0p1 /mnt
> cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> ---
> 
> I can't find the right docs to load bootx64.old.
> Could you tell me what you did to solve your boot?
> 
> Thanks

I use VirturalBox to run 14-CURRENT system. UEFI BIOS of VirtualBox
provides a way to select loader file and boot from it. So I take
following steps when updating loader file.

1. cd /boot/efi/efi/freebsd
2. mv loader.efi loader.backup.efi
3. cp -a /boot/loader.efi .

And when boot from new loader file fails, I enter UEFI BIOS, select
loader.backup.efi and boot from it.

As you can see, above way depends on the feature of VirturalBox. So
it depends on your hardware whether or not you can adopt it. As Larry
pointed out, surest way is to boot from install media such as memstick
or cdrom.

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Larry Rosenman]

boot off a memstick?

On 08/12/2022 3:25 pm, Nuno Teixeira wrote:


The problem is if boot is failing, how to mount and rename it?

I'm looking for a way, if possible, to boot directly bkp boot64x in 
case of failure.

I was hoping to find it in loader(8) or uefi(8)...

Larry Rosenman  escreveu no dia sexta, 12/08/2022 à(s) 
21:09:


I would assume just rename the bootx64.old to bootx64.efi

and/or put it in a different directory that EFI can see

On 08/12/2022 3:03 pm, Nuno Teixeira wrote:

I'm searching without success to load a bkp loader in case of boot 
failure.


Upgrade process willl be like:
---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
---

I can't find the right docs to load bootx64.old.
Could you tell me what you did to solve your boot?

Thanks

Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 
à(s) 18:45: From: Nuno Teixeira 

Subject: Re: Updating EFI boot loader results in boot hangup
Date: Fri, 12 Aug 2022 18:26:11 +0100


Hello Yasu,

Does it needes to update boot loader everytime that we upgrade 
current?


No, you need not.

The only time that I updated was a month ago because of zfs upgrade 
and I need to practice how to boot

loader bkp file :)


I update boot loader everytime because I'd like to do it :-).
And sometimes problem hits upon me like this time and I contribute to
debugging base system :-):-).

---
Yasuhiro Kimura

--

Nuno Teixeira
FreeBSD Committer (ports)


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

--

Nuno Teixeira
FreeBSD Committer (ports)

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: Updating EFI boot loader results in boot hangup

[Nuno Teixeira]

The problem is if boot is failing, how to mount and rename it?

I'm looking for a way, if possible, to boot directly bkp boot64x in case of
failure.
I was hoping to find it in loader(8) or uefi(8)...

Larry Rosenman  escreveu no dia sexta, 12/08/2022 à(s)
21:09:

> I would assume just rename the bootx64.old to bootx64.efi
>
> and/or put it in a different directory that EFI can see
>
>
> On 08/12/2022 3:03 pm, Nuno Teixeira wrote:
>
> I'm searching without success to load a bkp loader in case of boot failure.
>
> Upgrade process willl be like:
> ---
> mount -t msdosfs /dev/nvd0p1 /mnt
> cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> ---
>
> I can't find the right docs to load bootx64.old.
> Could you tell me what you did to solve your boot?
>
> Thanks
>
> Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 à(s)
> 18:45:
>
> From: Nuno Teixeira 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Fri, 12 Aug 2022 18:26:11 +0100
>
> > Hello Yasu,
> >
> > Does it needes to update boot loader everytime that we upgrade current?
>
> No, you need not.
>
> > The only time that I updated was a month ago because of zfs upgrade and
> I need to practice how to boot
> > loader bkp file :)
>
> I update boot loader everytime because I'd like to do it :-).
> And sometimes problem hits upon me like this time and I contribute to
> debugging base system :-):-).
>
> ---
> Yasuhiro Kimura
>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)

updating of prebuilt packages with pkg

[Andreas Ott]

I am not sure if this issue is more for -stable or -ports, so I start
here. The visible problem was that after 'pkg upgrade' certbot stopped
working.

I am running systems that after initial install do binary-only upgrades
for both core and ports with freebsd-update(8) and pkg(8). I do not have
the /usr/src/ or /usr/ports/ trees installed in order to save space. For 
policy reasons these use pre-built packages and I will never compile 
anything from source on these systems. This one is on 12.3-RELEASE .

Recently I encountered that the usual cadence of

pkg update
pkg upgraade
pkg autoremove
pkg clean

left me with several packages in state "?". 

$ pkg version |grep \?  
[...]
py38-acme-1.22.0,1 ?
py38-certbot-1.22.0,1  ?
[...]
ruby27-bdb-0.6.6_8 ?

which tells me that these have been superseded by something else.

Tracking this down on a system that does have /usr/ports installed I
could find in /usr/ports/UPDATING that in my example the default version
of python had been upgraded, see entry
20220626:
  AFFECTS: users of python
[...]
  For users of pre-build packages:
  # sh
  # for i in $(pkg query -g %n 'py38-*'); do pkg set -yn ${i}:py39-${i#py38-}; 
done
  # pkg upgrade
[...]

How would a user of pre-built packages find out about the need to run the
'pkg set' command? The dependency and integrity solver in pkg did not show 
any notices about it. An example would be p7zip.

I believe a similar issue exists if a port gets removed entirely, in which
case a previously installed package shows in state "?". No notification
is given by pkg about the fact that is was deprecated.

Using the instructions above I was able to get back to a working certbot.

In the case of ruby27 the pkg commands above handled this gracefully
on its own, see /usr/ports/UPDATING entry from 20220421 
"ruby: 2.7.x -> 3.0.4_2,1".


Thanks, andreas
-- 
andr...@naund.org

Re: Updating EFI boot loader results in boot hangup

[Larry Rosenman]

I would assume just rename the bootx64.old to bootx64.efi

and/or put it in a different directory that EFI can see

On 08/12/2022 3:03 pm, Nuno Teixeira wrote:

I'm searching without success to load a bkp loader in case of boot 
failure.


Upgrade process willl be like:
---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
---

I can't find the right docs to load bootx64.old.
Could you tell me what you did to solve your boot?

Thanks

Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 
à(s) 18:45:



From: Nuno Teixeira 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Fri, 12 Aug 2022 18:26:11 +0100


Hello Yasu,

Does it needes to update boot loader everytime that we upgrade 
current?


No, you need not.

The only time that I updated was a month ago because of zfs upgrade 
and I need to practice how to boot

loader bkp file :)


I update boot loader everytime because I'd like to do it :-).
And sometimes problem hits upon me like this time and I contribute to
debugging base system :-):-).

---
Yasuhiro Kimura


--

Nuno Teixeira
FreeBSD Committer (ports)


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: Updating EFI boot loader results in boot hangup

[Nuno Teixeira]

I'm searching without success to load a bkp loader in case of boot failure.

Upgrade process willl be like:
---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
---

I can't find the right docs to load bootx64.old.
Could you tell me what you did to solve your boot?

Thanks

Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 à(s)
18:45:

> From: Nuno Teixeira 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Fri, 12 Aug 2022 18:26:11 +0100
>
> > Hello Yasu,
> >
> > Does it needes to update boot loader everytime that we upgrade current?
>
> No, you need not.
>
> > The only time that I updated was a month ago because of zfs upgrade and
> I need to practice how to boot
> > loader bkp file :)
>
> I update boot loader everytime because I'd like to do it :-).
> And sometimes problem hits upon me like this time and I contribute to
> debugging base system :-):-).
>
> ---
> Yasuhiro Kimura
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

From: Nuno Teixeira 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Fri, 12 Aug 2022 18:26:11 +0100

> Hello Yasu,
> 
> Does it needes to update boot loader everytime that we upgrade current?
 
No, you need not.

> The only time that I updated was a month ago because of zfs upgrade and I 
> need to practice how to boot
> loader bkp file :)

I update boot loader everytime because I'd like to do it :-).
And sometimes problem hits upon me like this time and I contribute to
debugging base system :-):-).

---
Yasuhiro Kimura

Re: Updating EFI boot loader results in boot hangup

[Nuno Teixeira]

Hello Yasu,

Does it needes to update boot loader everytime that we upgrade current?

The only time that I updated was a month ago because of zfs upgrade and I
need to practice how to boot loader bkp file :)

Cheers,

Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 à(s)
17:56:

> Hello,
>
> 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.
>
> Best Regards.
>
> ---
> Yasuhiro Kimura
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Updating EFI boot loader results in boot hangup

[Yasuhiro Kimura]

Hello,

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.

Best Regards.

---
Yasuhiro Kimura

Re: After updating main (so: 14) Orange Pi+ 2E panicked: ucom_cons_softc "'Translation Fault (L2)' on read" while typing first command after login

[Mark Millard via freebsd-arm]

On 2021-Oct-12, at 01:43, Hans Petter Selasky  wrote:

> On 10/12/21 3:11 AM, Mark Millard via freebsd-arm wrote:
>> There is this "mixer" oddity for each boot:
>> Feeding entropy: .
>> mixer: 75:75: no such device
>> mixer: 75:75: no such device
>> mixer: 75:75: no such device
>> mixer: 25:25: no such device
>> mixer: 75:75: no such device
>> mixer: 75:75: no such device
>> mixer: =rec: no such device
>> lo0: link state changed to UP
>> (in case that matters for some reason).
> 
> Hi,
> 
> Add this script to /etc/rc.d/ and you'll be fine from now on.
> https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/mixer
> 
> Then run:
> service mixer stop && service mixer start
> 
> And the problem should go away.
> 
> See "git: 903873ce1560 - main - Implement and use new mixer(3) library for 
> FreeBSD"

Copying /usr/main-src/libexec/rc/rc.d/mixer and then doing
the stop/start sequence made the boot messages go away.
Thanks.

(I've never done anything explicit with mixer or such. The
default installation must have involved it, despite this file
not being put in place by the update.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Re: After updating main (so: 14) Orange Pi+ 2E panicked: ucom_cons_softc "'Translation Fault (L2)' on read" while typing first command after login

[Hans Petter Selasky]

On 10/12/21 3:11 AM, Mark Millard via freebsd-arm wrote:

There is this "mixer" oddity for each boot:

Feeding entropy: .
mixer: 75:75: no such device
mixer: 75:75: no such device
mixer: 75:75: no such device
mixer: 25:25: no such device
mixer: 75:75: no such device
mixer: 75:75: no such device
mixer: =rec: no such device
lo0: link state changed to UP

(in case that matters for some reason).


Hi,

Add this script to /etc/rc.d/ and you'll be fine from now on.
https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/mixer

Then run:
service mixer stop && service mixer start

And the problem should go away.

See "git: 903873ce1560 - main - Implement and use new mixer(3) library 
for FreeBSD"


--HPS

After updating main (so: 14) Orange Pi+ 2E panicked: ucom_cons_softc "'Translation Fault (L2)' on read" while typing first command after login

[Mark Millard via freebsd-arm]

I did not even get a chance to finish typing a command after
login for the fist boot after updating:

Fatal kernel mode data abort: 'Translation Fault (L2)' on read
trapframe: 0xe18d6998
FSR=0007, FAR=fff4, spsr=a013
r0 =0001, r1 =, r2 =, r3 =
r4 =d8ce7100, r5 =07d0, r6 =90001010, r7 =
r8 =c08dfc10, r9 =0001, r10=c08dfc1c, r11=e18d6aa8
r12=e18d69e0, ssp=e18d6a28, slr=e18d6a28, pc =e18d6a4c

panic: Fatal abort
cpuid = 0
time = 1633999791
KDB: stack backtrace:
db_trace_self() at db_trace_self
 pc = 0xc062ef7c  lr = 0xc007eb58 (db_trace_self_wrapper+0x30)
 sp = 0xe18d6770  fp = 0xe18d6888
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
 pc = 0xc007eb58  lr = 0xc030ee04 (vpanic+0x17c)
 sp = 0xe18d6890  fp = 0xe18d68b0
 r4 = 0x0100  r5 = 0x
 r6 = 0xc07cac38  r7 = 0xc0941d68
vpanic() at vpanic+0x17c
 pc = 0xc030ee04  lr = 0xc030ec88 (vpanic)
 sp = 0xe18d68b8  fp = 0xe18d68bc
 r4 = 0xe18d6998  r5 = 0x0013
 r6 = 0xfff4  r7 = 0x0007
 r8 = 0x0007  r9 = 0xda5e9000
r10 = 0xfff4
vpanic() at vpanic
 pc = 0xc030ec88  lr = 0xc0652f68 (abort_align)
 sp = 0xe18d68c4  fp = 0xe18d68f0
 r4 = 0x0007  r5 = 0x0007
 r6 = 0xda5e9000  r7 = 0xfff4
 r8 = 0xe18d68bc  r9 = 0xc030ec88
r10 = 0xe18d68c4
abort_align() at abort_align
 pc = 0xc0652f68  lr = 0xc0652a90 (abort_handler+0x2a8)
 sp = 0xe18d68f8  fp = 0xe18d6990
 r4 = 0x0013  r5 = 0xfff4
abort_handler() at abort_handler+0x2a8
 pc = 0xc0652a90  lr = 0xc063191c (exception_exit)
 sp = 0xe18d6998  fp = 0xe18d6aa8
 r4 = 0xd8ce7100  r5 = 0x07d0
 r6 = 0x90001010  r7 = 0x
 r8 = 0xc08dfc10  r9 = 0x0001
r10 = 0xc08dfc1c
exception_exit() at exception_exit
 pc = 0xc063191c  lr = 0xe18d6a28 (0xe18d6a28)
 sp = 0xe18d6a28  fp = 0xe18d6aa8
 r0 = 0x0001  r1 = 0x
 r2 = 0x  r3 = 0x
 r4 = 0xd8ce7100  r5 = 0x07d0
 r6 = 0x90001010  r7 = 0x
 r8 = 0xc08dfc10  r9 = 0x0001
r10 = 0xc08dfc1c r12 = 0xe18d69e0
ucom_cons_softc() at 0xe18d6a4c
 pc = 0xe18d6a4c  lr = 0xe18d6a28 (0xe18d6a28)
 sp = 0xe18d6a28  fp = 0xe18d6aa8
KDB: enter: panic
[ thread pid 894 tid 100135 ]
Stopped at  kdb_enter+0x58: ldrbr15, [r15, r15, ror r15]!
db>

It is not reliably repeatable. Unsure if I can get a repeat at
all.

There is this "mixer" oddity for each boot:

Feeding entropy: .
mixer: 75:75: no such device
mixer: 75:75: no such device
mixer: 75:75: no such device
mixer: 25:25: no such device
mixer: 75:75: no such device
mixer: 75:75: no such device
mixer: =rec: no such device
lo0: link state changed to UP

(in case that matters for some reason).

For reference:

# uname -apKU
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT #10 
main-n249978-032448cd2c52-dirty: Sat Oct  9 02:11:35 PDT 2021 
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.armv7/sys/GENERIC-NODBG-CA7
  arm armv7 1400036 1400036





===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Thomas Mueller]

> In both cases, the entry is INcorrect. Juraj is correct. The swap entry is
> missing sw
> IOW the line MUST read as:

> /dev/gpt/Sea1-18noneswapsw  0   0

> or

> /dev/gpt/Sea1-18noneswapsw,trimonce 0   0

> as appropriate for the media referenced.

>-Chris

As my last message stated, I found the missing field in /etc/fstab and 
corrected it.

Then "mount -u /" worked smoothly.

Perhaps one field too few makes the system look to the next line, so the whole 
/etc/fstab is misinterpreted.

I also pointed out that, from previous messages on this list, that etcupdate 
was replacing mergemaster.

But UPDATING at the top of the src tree still specifies mergemaster, so that 
would need to be updated.

There needs to be better documentation on the newer etcupdate.

Parameters for etcupdate are somewhat different in FreeBSD than in NetBSD, so 
the documentation needs to be updated.

I don't want to mess up by doing the wrong thing in NetBSD or FreeBSD.

Tom

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Chris]

On 2021-06-06 23:49, Graham Perrin wrote:

On 07/06/2021 07:10, Juraj Lutter wrote:

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0


Very well spotted, Juraj, but maybe a typo in your correction.

A clearer view of the original  where the device 
given to swap is:


/dev/gpt/Sea1-08

In both cases, the entry is INcorrect. Juraj is correct. The swap entry is
missing sw
IOW the line MUST read as:

/dev/gpt/Sea1-18noneswapsw  0   0

or

/dev/gpt/Sea1-18noneswapsw,trimonce 0   0

as appropriate for the media referenced.

--Chris

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Graham Perrin]

On 07/06/2021 07:10, Juraj Lutter wrote:

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0


Very well spotted, Juraj, but maybe a typo in your correction.

A clearer view of the original  where the 
device given to swap is:


/dev/gpt/Sea1-08

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Juraj Lutter]

> On 7 Jun 2021, at 02:15, Thomas Mueller  wrote:
> 
> I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took 
> 11:15 (hours:minutes), buildkernel was also successful, I even appeared to be 
> successful with "dhclient re0".
> 
> UPDATING file says to boot single-user after buildkernel and installkernel, 
> but then mount -u / or mount -uw / does not work as it did in previous times.
> 
> Results were
> 
> mount -uw / or mount -u / produces 
> fstab: /etc/fstab:2: Inappropriate file type or format
> fstab: /etc/fstab:2: Inappropriate file type or format

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0

otis

—
Juraj Lutter
o...@freebsd.org

Re: Updating to FreeBSD-current, can't mount -uw /

[Warner Losh]

On Sun, Jun 6, 2021 at 5:24 AM Thomas Mueller  wrote:

> I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld
> took 11:15 (hours:minutes), buildkernel was also successful, I even
> appeared to be successful with "dhclient re0".
>
> UPDATING file says to boot single-user after buildkernel and
> installkernel, but then mount -u / or mount -uw / does not work as it did
> in previous times.
>
> Results were
>
> mount -uw / or mount -u / produces
> fstab: /etc/fstab:2: Inappropriate file type or format
> fstab: /etc/fstab:2: Inappropriate file type or format
>
> /etc/fstab
> # DeviceMountpoint  FStype  Options DumpPass#
> /dev/gpt/Sea1-08  none swap 0   0
> /dev/gpt/Sea1-18  / ufs rw  1   1
> #/dev/gpt/Sea1-06 /home   ufs  rw 1  1
>
> fsck -p produces
>
> fstab: /etc/fstab:2: Inappropriate file type or format
> /dev/gpt/Sea1-18: NO WRITE ACCESS
> /dev/gpt/Sea1-18: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>
> I tried fsck /dev/gpt/Sea1-18 and fsck / but did no better.
>
> Now what do I do?  I also ran fsck_ffs instead of just fsck.
>
> Do I need to boot NetBSD and run fsck_ffs or fsck_ffs -f from there?
>

fsck /dev/gpt/Seae1-18

doesn't work? You can also fsck on the underlying disk, but since there's
many choices
that are hard to know w/o a dmesg.

Warner

Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Thomas Mueller]

I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took 
11:15 (hours:minutes), buildkernel was also successful, I even appeared to be 
successful with "dhclient re0".

UPDATING file says to boot single-user after buildkernel and installkernel, but 
then mount -u / or mount -uw / does not work as it did in previous times.

Results were

mount -uw / or mount -u / produces 
fstab: /etc/fstab:2: Inappropriate file type or format
fstab: /etc/fstab:2: Inappropriate file type or format

/etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/Sea1-08  none swap 0   0
/dev/gpt/Sea1-18  / ufs rw  1   1
#/dev/gpt/Sea1-06 /home   ufs  rw 1  1

fsck -p produces

fstab: /etc/fstab:2: Inappropriate file type or format
/dev/gpt/Sea1-18: NO WRITE ACCESS
/dev/gpt/Sea1-18: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

I tried fsck /dev/gpt/Sea1-18 and fsck / but did no better.

Now what do I do?  I also ran fsck_ffs instead of just fsck.

Do I need to boot NetBSD and run fsck_ffs or fsck_ffs -f from there?

Now I seem to have solved the problem.  Either rebooting or fixing /etc/fstab 
did it.

I may have had one too few fields on the /dev/gpt/Sea1-08 line, maybe that 
caused the system to misinterpret the next line.

I added sw between swap and 0, thus the corrected fstab is

# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/Sea1-08  none swap sw  0   0
/dev/gpt/Sea1-18  / ufs rw  1   1
#/dev/gpt/Sea1-06 /home   ufs  rw 1  1

Now I see from the emailing lists that etcupdate is replacing mergemaster, but 
UPDATING file still says to use mergemaster without mentioning etcupdate.

Developers, please update!

There are differences between NetBSD's etcupdate and FreeBSD's etcupdate.  I 
don't want to do the wrong thing in FreeBSD. 

Tom

Updating to FreeBSD-current, can't mount -uw /

[Thomas Mueller]

I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took 
11:15 (hours:minutes), buildkernel was also successful, I even appeared to be 
successful with "dhclient re0".

UPDATING file says to boot single-user after buildkernel and installkernel, but 
then mount -u / or mount -uw / does not work as it did in previous times.

Results were

mount -uw / or mount -u / produces 
fstab: /etc/fstab:2: Inappropriate file type or format
fstab: /etc/fstab:2: Inappropriate file type or format

/etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/Sea1-08  none swap 0   0
/dev/gpt/Sea1-18  / ufs rw  1   1
#/dev/gpt/Sea1-06 /home   ufs  rw 1  1

fsck -p produces

fstab: /etc/fstab:2: Inappropriate file type or format
/dev/gpt/Sea1-18: NO WRITE ACCESS
/dev/gpt/Sea1-18: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

I tried fsck /dev/gpt/Sea1-18 and fsck / but did no better.

Now what do I do?  I also ran fsck_ffs instead of just fsck.

Do I need to boot NetBSD and run fsck_ffs or fsck_ffs -f from there?

Tom

Re: Build fail updating from n246398-388c0cde1029 -> n246413-c78ad207baed

[Mark Millard via freebsd-current]

https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/003953.html

reports for main's commit just after c78ad207baed :

The branch main has been updated by andrew:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=f1957db43d28dbae1f82905304bab5be51942342


commit f1957db43d28dbae1f82905304bab5be51942342
Author: Andrew Turner 
AuthorDate: 2021-05-01 11:10:03 +
Commit: Andrew Turner 
CommitDate: 2021-05-01 11:10:03 +

Fix building sysctl(8) after c78ad20

In sysctl we parse an efi header on amd64. Fix this after changing the
virtual memory type from a void * to a uint64_t in c78ad20.
---
 sbin/sysctl/sysctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sbin/sysctl/sysctl.c b/sbin/sysctl/sysctl.c
index 30d6d94723fa..8d658dc2debe 100644
--- a/sbin/sysctl/sysctl.c
+++ b/sbin/sysctl/sysctl.c
@@ -794,8 +794,8 @@ S_efi_map(size_t l2, void *p)
type = types[map->md_type];
if (type == NULL)
type = "";
-   printf("\n%23s %012jx %12p %08jx ", type,
-   (uintmax_t)map->md_phys, map->md_virt,
+   printf("\n%23s %012jx %012jx %08jx ", type,
+   (uintmax_t)map->md_phys, (uintmax_t)map->md_virt,
(uintmax_t)map->md_pages);
if (map->md_attr & EFI_MD_ATTR_UC)
printf("UC ");

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build fail updating from n246398-388c0cde1029 -> n246413-c78ad207baed

[David Wolfskill]

Per the ERROR_META_FILE:

# Meta data file /common/S4/obj/usr/src/amd64.amd64/sbin/sysctl/sysctl.o.meta
CMD cc -target x86_64-unknown-freebsd14.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   -fPIE 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/sbin/sysctl/sysctl.c -o sysctl.o
CMD 
CWD /common/S4/obj/usr/src/amd64.amd64/sbin/sysctl
TARGET sysctl.o
-- command output --
/usr/src/sbin/sysctl/sysctl.c:798:32: error: format specifies type 'void *' but 
the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
(uintmax_t)map->md_phys, map->md_virt,
 ^~~~
1 error generated.

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 94559
# Start 1619869639.590308
V 5
E 94581 /bin/sh
R 94581 /etc/libmap.conf
R 94581 /var/run/ld-elf.so.hints
R 94581 /lib/libedit.so.8
R 94581 /lib/libc.so.7
R 94581 /lib/libncursesw.so.9
R 94581 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 94581 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 94581 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 94581 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 94581 /usr/share/locale/en_US.UTF-8/LC_TIME
R 94581 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 94581 94587
E 94587 /usr/bin/cc
R 94587 /etc/libmap.conf
R 94587 /var/run/ld-elf.so.hints
R 94587 /lib/libz.so.6
R 94587 /usr/lib/libexecinfo.so.1
R 94587 /lib/libncursesw.so.9
R 94587 /lib/libthr.so.3
R 94587 /usr/lib/libc++.so.1
R 94587 /lib/libcxxrt.so.1
R 94587 /lib/libm.so.5
R 94587 /lib/libc.so.7
R 94587 /lib/libelf.so.2
R 94587 /lib/libgcc_s.so.1
R 94587 /usr/src/sbin/sysctl/sysctl.c
R 94587 sysctl-a47e0ae5.o.tmp
W 94587 sysctl-a47e0ae5.o.tmp
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/cdefs.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/param.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_null.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/endian.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/endian.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_types.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_limits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_limits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_endian.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_pthreadtypes.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_stdint.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/select.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_sigset.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_timeval.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/timespec.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_timespec.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/syslimits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/signal.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/signal.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/signal.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/param.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_align.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_align.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/limits.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/time.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/time.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/xlocale/_time.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/resource.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/stat.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/sysctl.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/vmmeter.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/dev/evdev/input.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ioccom.h
R 94587 
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/dev/evdev/input-event-codes.h
R 94587 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/s

Re: (D29934) Reorder commented steps in UPDATING following sequential order. (was: etcupdate -p vs. root on zfs (and bectl use and such): no /usr/src/etc/master.passwd (for example))

[Mark Millard via freebsd-current]

On 2021-Apr-25, at 08:14, Graham Perrin  wrote:

> On 23/04/2021 08:39, Mark Millard via freebsd-current wrote:
> 
>>   [3]
> 
> 
> With regard to mounting ZFS file systems in single user mode
> 
> What's currently footnote 3 will probably become footnote 4, please see:
> 
> <https://reviews.freebsd.org/D29934#inline-186101>
> 
> … and so on.

If it were me, I'd probably do something to make the
mounting of file systems and such have an explicit
reminder as its own step, something like:


[4]
mergemaster -Fp [5]

I just do not think of such as part of :
it is already rebooted in single user at that point in my
view.

Sorry that I missed what was there in UPDATING.

However, /usr/src/Makefile has:

#  1.  `cd /usr/src'   (or to the directory containing your source tree).
#  2.  `make buildworld'
#  3.  `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
#  4.  `make installkernel KERNCONF=YOUR_KERNEL_HERE'   (default is GENERIC).
#   [steps 3. & 4. can be combined by using the "kernel" target]
#  5.  `reboot'(in single user mode: boot -s from the loader prompt).
#  6.  `mergemaster -p'
#  7.  `make installworld'
#  8.  `mergemaster'(you may wish to use -i, along with -U or -F).
#  9.  `make delete-old'
# 10.  `reboot'
# 11.  `make delete-old-libs' (in case no 3rd party program uses them anymore)

without such material, even in footnotes.


Side notes:

"From the bootblocks, boot -s, and then do":
"From the boot loader, boot -s, and then do"?

etcupdate vs. mergemaster and the $FreeBSD$ issue?
Is mergemaster going to stay as the recommented
command to use? If so, with which command line
options?

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

(D29934) Reorder commented steps in UPDATING following sequential order. (was: etcupdate -p vs. root on zfs (and bectl use and such): no /usr/src/etc/master.passwd (for example))

[Graham Perrin]

On 23/04/2021 08:39, Mark Millard via freebsd-current wrote:


   [3]



With regard to mounting ZFS file systems in single user mode

What's currently footnote 3 will probably become footnote 4, please see:



… and so on.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

[John Baldwin]

On 4/17/21 12:52 PM, Graham Perrin wrote:

2)

 line 2274

etcupdate -p

I get:

  > No previous tree to compare against, a sane comparison is not possible.


Hmm, how did you initially install this machine?  Release images should
generally include a pre-populated /var/db/etcupdate so that etcupdate
works.  If you don't have one of those, you will have to perform an
initial bootstrap of etcupdate (only once) by running 'etcupdate extract'.
If you do this before you update /usr/src then 'etcupdate' will later
work fine.  If you are doing this after you have already updated
/usr/src, you will need to run 'etcupdate diff' after 'etcupdate extract'
and fix any unexpected local differences in the generated patch, e.g.
by copying files from /var/db/etcupdate/current/etc to /etc.  Once
you have done this, 'etcupdate' will work fine on the next upgrade.

However, I'm curious how you didn't get the etcupdate bootstrap when
you initially installed.

--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

[John Baldwin]

On 4/18/21 1:48 AM, driesm.michi...@gmail.com wrote:

If etcupdate -p fails before make installworld, then should the subsequent
etcupdate be with or without option -B ?


-p and -B are not related.

-p deals with changes needed for a correct run of installworld (see above).

-B uses a freshly built world to speed up the tree comparison; although no
flags work fine here as well, so -B is not necessarily required.


Technically -B speeds up generating the tree to compare against as it assumes
/usr/obj is up to date and uses that instead of rebuilding some files
generated by buildworld normally.  The actual tree comparison isn't affected.

--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

[Graham Perrin]

On 18/04/2021 09:48, driesm.michi...@gmail.com wrote:


1)

  lines 2273 and
2275

With ZFS in the mix, /usr/src is present but empty (the file system is not
mounted).

See [3] a bit lower in the file at 2341. … comes down to "service zfs start"



Thank you!

I commented on the disorder but hadn't paid attention to the _content_ 
of footnotes. My bad.


I habitually `mount -uw /`.

Never thought to run service in single user mode, I'll know for next time.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

[driesm.michiels]

> -Original Message-
> From: owner-freebsd-curr...@freebsd.org  curr...@freebsd.org> On Behalf Of Graham Perrin
> Sent: Saturday, 17 April 2021 21:52
> To: freebsd-current 
> Subject: Review D28062 of /usr/src/UPDATING with regard to upgrading
> FreeBSD and inconsistency with the FreeBSD Handbook
> 
> 1)
> 
> <https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> lines 2273 and
> 2275
> 
> With ZFS in the mix, /usr/src is present but empty (the file system is not
> mounted).

See [3] a bit lower in the file at 2341. (cherry picked)
- mount -u /, to mount the root as rw so that you can installworld on it.
- sh /etc/rc.d/zfs start to mount all other datasets such as /usr/src, comes
down to "service zfs start"

> If single user mode is recommended, then why is this not in the FreeBSD
> Handbook?
> <https://cgit.freebsd.org/doc/tree/documentation/content/en/books/handbo
> ok/cutting-
> edge/_index.adoc?id=84d56d3868a699c64c51d7453cedab0f3468ba03#n620>

Speaking of my own experience, I have not had any trouble doing source
installs on the fly (not in single user mode)
Altough, these mostly deal with STABLE/CURRENT branches and I can't comment
on why it is recommended (probably just the safer route for .so bumps).

> 2)
>
> <https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> line 2274
> 
> etcupdate -p
> 
> I get:
> 
>  > No previous tree to compare against, a sane comparison is not possible.
> 
> <https://photos.app.goo.gl/3a64FfsNkGUTPj1XA>
> 
> In the past I simply ran etcupdate after make installworld.

Thats fine as long as there are no changes that could impact the
installworld process, like an extra user that might be added (ntpd most
recent), these are scarce though and you will typically notice pretty
quickly as the installworld process will fail in some sort of way.
I'm uncertain why it cannot compare to a previous tree, for me it gives no
output which means its fine.
Do you get normal output from "etcupdate diff"?

> 
> If etcupdate -p fails before make installworld, then should the subsequent
> etcupdate be with or without option -B ?

-p and -B are not related.

-p deals with changes needed for a correct run of installworld (see above).

-B uses a freshly built world to speed up the tree comparison; although no
flags work fine here as well, so -B is not necessarily required.

> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

[Graham Perrin]

1)

 lines 2273 and 2275

With ZFS in the mix, /usr/src is present but empty (the file system is 
not mounted).


If single user mode is recommended, then why is this not in the FreeBSD 
Handbook? 



2)

 line 2274

etcupdate -p

I get:

> No previous tree to compare against, a sane comparison is not possible.



In the past I simply ran etcupdate after make installworld.

If etcupdate -p fails before make installworld, then should the 
subsequent etcupdate be with or without option -B ?


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"