Re: Loader needs to be updated message
On Sat, 7 Sep 2024 21:31:21 -0600 Warner Losh wrote: > On Sat, Sep 7, 2024, 9:16 PM Tomoaki AOKI wrote: > > > On Sat, 7 Sep 2024 19:38:47 -0700 > > Mark Millard wrote: > > > > > void wrote on > > > Date: Sat, 07 Sep 2024 17:27:00 UTC : > > > > > > > On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote: > > > > > > > > >I'm more interested in what is there than just what is not > > > > >there. May be show something analogous to: > > > > > > > > > ># gpart list | grep -E '(Name|type|efi|media)' > > > > >1. Name: mmcsd1s1 > > > > > efimedia: HD(1,MBR,,0x8000,0x3b68000) > > > > > rawtype: 12 > > > > > type: fat32lba > > > > >1. Name: mmcsd1 > > > > >1. Name: da0p1 > > > > > efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28,0x82000) > > > > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > > > label: BPIM3efi > > > > > type: efi > > > > >2. Name: da0p2 > > > > > efimedia: > > HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82800,0x366000) > > > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > > > type: freebsd-swap > > > > >3. Name: da0p3 > > > > > efimedia: > > HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x6861c800,0x732800) > > > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > > > type: freebsd-swap > > > > >4. Name: da0p4 > > > > > efimedia: > > HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1c800,0x67c0) > > > > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > > > > > type: freebsd-ufs > > > > >1. Name: da0 > > > > > > > > > >I'll note that on various type of systems, the (effectively) > > > > >ESP need not be specifically of "type: efi", possibly some > > > > >fat variant instead also works. (Of course, EFI need not be > > > > >the only alternative for various type of contexts.) > > > > > > > > > >I'll note the /boot/efi is normally just an empty directory > > > > >that is possibly used as a mount point. > > > > > > > > > >In some (somewhat older) configurations /boot/msdos is > > > > >similarly an empty directory and possibly used as the mount > > > > >point instead. > > > > > > > > > >> After source building to latest stable in the usual way, same error > > message 'loader needs updating'. > > > > > > > > This is on the guest > > > > > > > > # gpart list | grep -E '(Name|type|efi|media)' > > > > 1. Name: vtbd0p1 > > > > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400) > > > > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f > > > > type: freebsd-boot > > > > > > As I understand it, that "type: freebsd-boot" means that one of > > > the likes of: > > > > > > # ls -lodT /boot/gpt*boot* > > > -r--r--r-- 1 root wheel uarch 62139 Apr 7 15:55:46 2024 /boot/gptboot > > > -r-xr-xr-x 1 root wheel uarch 109568 Apr 7 15:55:46 2024 > > /boot/gptboot.efi > > > -r--r--r-- 1 root wheel uarch 176062 Apr 8 01:15:54 2024 > > /boot/gptzfsboot > > > > > > is in use inside that freebsd-boot partition (vtbd0p1). But only > > > one of those supports zfs. > > > > > > Fair warning that I never use any of those 3 --nor freebsd-boot > > > partitions. Nor have I ever used Bhyve. Do not blindly believe what I > > > report here. But hopefully it points in a useful direction to > > > initially investigate. > > > > > > Looking at: > > > > > > "man 8 gptboot.efi" indicates that "gptboot.efi works only with UFS > > > root file systems". > > > > > > "man 8 gptboot" indicates that "gptboot is used on BIOS-based > > > computers to boot from a UFS partition on a GPT-partitioned disk". > > > > > > BUT "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based > > > computers to boot from a filesystem in a ZFS pool". > > > > > > So the partitioning is not set up for supporting the combination of: > > > EFI and ZFS-for-root-filesystem: if the gptzfsboot is used then it > > > needs to be old style BIOS-and-ZFS for the context. > > > > > > So my expectation here is that the gptzfsboot content in use in > > > vtbd0p1 (i.e. -i 1 vtbd0 in some commands) is out of date and needs > > > to be updated. To my knowledge, there is no simple technique to look > > > up the vintage present in -i 1 vtbd0 . > > > > > > I have no clue which of the following should be used for your context > > > to be sure that the content ends up up to date: > > > > > > The Protective MBR variant: > > > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 > > > > > > The variant for without the Protective MBR: > > > # gpart bootcode -p /boot/gptzfsboot -i 1 vtbd0 > > > > > > Those commands are adjusted variations of what the man page's EXAMPLES > > > section shows, but not using the 2 example's ada0 notation. > > > > > > > 2. Name: vtbd0p2 > > > > efimedia: > > HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200) > > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > > type: freebsd-swap > > > > 3. Name: vtbd0p3 > > > > efimedia: > > HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000) > > > > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b > > > > type: fre
Re: Loader needs to be updated message
On Sat, Sep 07, 2024 at 09:34:27PM -0600, Warner Losh wrote: Yes. If you are getting the too old error, then there is a preupdate world booting a stable/13 after my change I think. Warner So, on the server (15.0-CURRENT #0 n270917-5dbf886104b4: Thu Jul 4 ) ls -lah /boot/gptzfsboot -r--r--r-- 1 root wheel 172K Jul 4 17:26 /boot/gptzfsboot In the VM (13.4-STABLE stable/13-n258323-e7b4f6e0c064 Sep 6) ls -lah /boot/gptzfsboot -r--r--r-- 1 root wheel 151K Sep 6 23:57 /boot/gptzfsboot to reiterate:- both these systems are root-on-zfs Do you think a source upgrade on the server would fix the issue? related: do you think i'd have avoided the issue if the guest was ufs only? --
Re: Loader needs to be updated message
On Sun, Sep 8, 2024, 7:50 AM void wrote: > On Sat, Sep 07, 2024 at 09:34:27PM -0600, Warner Losh wrote: > > > >Yes. If you are getting the too old error, then there is a preupdate world > >booting a stable/13 after my change I think. > > > >Warner > > So, on the server (15.0-CURRENT #0 n270917-5dbf886104b4: Thu Jul 4 ) > > ls -lah /boot/gptzfsboot > -r--r--r-- 1 root wheel 172K Jul 4 17:26 /boot/gptzfsboot > Gptzfsboot is not relevant. Userboot.ko would be since that's what provides the loader interfaces for bhyve. In the VM (13.4-STABLE stable/13-n258323-e7b4f6e0c064 Sep 6) > > ls -lah /boot/gptzfsboot > -r--r--r-- 1 root wheel 151K Sep 6 23:57 /boot/gptzfsboot > > to reiterate:- both these systems are root-on-zfs > > Do you think a source upgrade on the server would fix the issue? > Yes. But the warning at this time isn't super urgent for you. It is telling you of problems in the future. related: do you think i'd have avoided the issue if the guest was ufs only? > No. This is a host vs guest crossthreading that's unavoidable. Warner >
Re: Loader needs to be updated message
On Sun, Sep 08, 2024 at 09:14:50AM -0600, Warner Losh wrote: On Sun, Sep 8, 2024, 7:50 AM void wrote: Do you think a source upgrade on the server would fix the issue? Yes. But the warning at this time isn't super urgent for you. It is telling you of problems in the future. related: do you think i'd have avoided the issue if the guest was ufs only? No. This is a host vs guest crossthreading that's unavoidable. OK thanks for that. I'll try upgrading the server to August stablisation week 04262ed78d23 I look after another vm on Azure. It's at 13.2-p11 right now i'd like to update it to 13.3 It's not zfs-on-root but it does have a zfs disk for data. Do you think this type of issue might be present? my fear is an unbootable system or not being able to access the zfs part. The system is managed with freebsd-update --
Re: Loader needs to be updated message
On Sun, Sep 08, 2024 at 09:14:50AM -0600, Warner Losh wrote: On Sun, Sep 8, 2024, 7:50 AM void wrote: Do you think a source upgrade on the server would fix the issue? Yes. But the warning at this time isn't super urgent for you. It is telling you of problems in the future. Can confirm - the error message is no longer present on the guest after source upgrade on the host. TYVM :D --
Re: Loader needs to be updated message
On Sun, Sep 8, 2024, 10:51 AM void wrote: > On Sun, Sep 08, 2024 at 09:14:50AM -0600, Warner Losh wrote: > >On Sun, Sep 8, 2024, 7:50 AM void wrote: > >> > >> Do you think a source upgrade on the server would fix the issue? > >> > >Yes. But the warning at this time isn't super urgent for you. It is > telling > >you of problems in the future. > > Can confirm - the error message is no longer present on the guest > after source upgrade on the host. > Great. This warning is new so people keep things uptodate. There has been minor breakage due to really old loader.efi not updating, but i backed that silent (mostly) breakage and added the loud version thing you see now. It shouldn't be that regular an occurrence... i wanted some warning to het people to do something. Warner > TYVM :D > -- > >
How to fix a broken package ?
Dear Magic FreeBSD types : I have no idea what needs to be done in order for a broken package to get fixed. At the moment I can not build LXDE ( and other stuff ) on my shiney new poudriere pkg build server. There is a busted patch in a thing called "databases/sfcgal" where the version is wrong for 2024Q3 ports branch. The "main" branch seems to work just fine. Please see : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281317 So this seems to only happen in the 2024Q3 ports branch and there is a mysterious website called "FallOut?" that suggests it breaks in other place also : https://portsfallout.com/fallout?port=databases%2Fsfcgal%24 Is there anyone anywhere who can please make the 4 byte change in the 2024Q3 branch for that patch file? Thank you. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: Loader needs to be updated message
On Sun, Sep 08, 2024 at 11:23:46AM -0600, Warner Losh wrote: Great. This warning is new so people keep things uptodate. There has been minor breakage due to really old loader.efi not updating, but i backed that silent (mostly) breakage and added the loud version thing you see now. It shouldn't be that regular an occurrence... i wanted some warning to het people to do something. Can I suggest it might be worthwhile mentioning in src/UPDATING ? I don't think these fixes are covered there. It was counterintuative to me at the start as this was a 13-stable guest showing the error, it being hosted on a 15-current bhyve, in that what was required was for the -current system to be upgraded. Maybe also for the other fix, in the different (arm64) context on baremetal, which was to copy /boot/loader.efi to /boot/efi/efi/BOOT/bootaa64.efi (I know of no way to determine whether or not the rpi4b comes under "deficient systems that don't honor efibootmgr(8) protocols" (as per /usr/src/UPDATING)) --
Re: How to fix a broken package ?
On 9/8/24 14:42, Dennis Clarke wrote: Dear Magic FreeBSD types : I have no idea what needs to be done in order . . . https://portsfallout.com/fallout?port=databases%2Fsfcgal%24 Is there anyone anywhere who can please make the 4 byte change in the 2024Q3 branch for that patch file? Thank you. The maintainer jumped on it. Neatly. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
