Re: EFI boot partition overwritten
> On 16. Jul 2021, at 19:38, Warner Losh wrote: > > On Fri, Jul 16, 2021 at 6:14 AM Thomas Laus wrote: > >> Group: >> >> This is an issue for more than just CURRENT. The 'usr/src/UPDATING' >> file has the instructions for updating the ZFS bootblocks but not the >> EFI partition. I recently upgraded a RELEASE-12.2 to RELEASE-13.0. The >> freebsd-update procedure did not upgrade the ZFS bootblocks. I forgot >> that this PC was UEFI only and overwrote the first partition with the >> gptzfsboot code. That made my system un-bootable. I found the recovery >> procedure on one of the FreeBSD forums and was able to reformat the EFI >> MSDOS partition, create the proper directory structure, and copy the >> loader.efi file to the correct location and filename using the Live >> Filesystem running on the installation CD. >> >> I searched the man pages and the UPDATING file for instructions but came >> up empty and had to resort to finding the answer on one of the forums. >> The filenames have changed since FreeBSD first supported EFI and some of >> the forum instructions are out of date. My problem must be fairly >> common and the recovery procedure should be in a man page with a >> footnote or man reference somewhere on the install media. >> >> Since CURRENT receives more updates to the EFI boot loader than the >> release versions, there should be instructions in the CURRENT >> 'usr/src/UPDATING' file on how to update the EFI bootcode. >> > > There should be. Yes. Last time I went hunting for a place to shoe-horn it > in, I got distracted by something else. > > The instructions are relatively straight forward. I'm writing them here for > your benefit, and also in case someone wants to send me a diff/pull request > to include them. Or better yet, put this in the handbook and we can > reference > a location from there. > > WARNING: This is a quick run-through of how to do this if you need to. > The example commands given might not be exactly right for all installations > as differing numbers of partitions will change the '-i' parameters. > > Frist, you need a partition that's of the right type. For GPT that type is > `efi` > as shown in `gpart show ` eg > # gpart show ada0 > =>40 2000409184 ada0 GPT (954G) > 401600- free - (800K) >1640 1992292792 2 freebsd-ufs (950G) > 1992294432 700 3 freebsd-swap (3.3G) > 1999294432 1114792 4 efi (544M) > > If you don't have one, you'll need to create one. In the above exmaple, > I had installed the system with a tiny partition for booting with legacy > BIOS, but then moved to booting with UEFI. I did this by turning off > swapping and doing the following: > # gpart resize -i 3 -s 700 ada0 > I then created a new efi partition: > # gpart add -t efi ada0 > and I let it autosize. > > Next, I needed a FAT32 filesystem on that device. FAT16 usually will > work and often FAT12, but there are known examples of system integrators > that omit support for these last two (more the latter than the former since > it's viewed as a floppy only thing, and who uses floppies). I just used > newfs_msdos and mounted it: > # newfs_msdos -F 32 /dev/ada0p4 > # mount -t msdos /dev/ada0p4 /boot/efi > > Next, you need to put a bootloader on the system. Unless you have > special needs, loader.efi is that loader. > # mkdir -p /boot/efi/efi/boot > # cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi > > If you are using efibootmgr to set a location to boot from, generally people > create a freebsd directory (we've registered /efi/freebsd with the proper > folks > to avoid conflicts): > # mkdir -p /boot/efi/efi/freebsd > # cp /boot/loader.efi /boot/efi/efi/freebsd > # efibootmgr -c -a -k /boot/kernel/kernel -l > /boot/efi/efi/freebsd/loader.efi -L "FreeBSD Boot" > though some vendors impose limits on how many boot envs you can create > and some do not allow any at all. > It would be cool to also update the loader.efi man page to be a bit more useful (this is what 'zpool upgrade' refers to/will refer to in the future). -m > Warner
Re: EFI boot partition overwritten
On 7/16/21 1:35 PM, Warner Losh wrote: > > There should be. Yes. Last time I went hunting for a place to shoe-horn it > in, I got distracted by something else. > > The instructions are relatively straight forward. I'm writing them here for > your benefit, and also in case someone wants to send me a diff/pull request > to include them. Or better yet, put this in the handbook and we can > reference > a location from there. > > WARNING: This is a quick run-through of how to do this if you need to. > The example commands given might not be exactly right for all installations > as differing numbers of partitions will change the '-i' parameters. > > Frist, you need a partition that's of the right type. For GPT that type is > `efi` > as shown in `gpart show ` eg > # gpart show ada0 > =>40 2000409184 ada0 GPT (954G) > 401600- free - (800K) > 1640 1992292792 2 freebsd-ufs (950G) > 1992294432 700 3 freebsd-swap (3.3G) > 1999294432 1114792 4 efi (544M) > It looks like the default layout from the install media is 200M => 40 488397088 ada0 GPT (233G) 40 409600 1 efi (200M) 409640 1024 2 freebsd-boot (512K) 410664984- free - (492K) 4116484194304 3 freebsd-swap (2.0G) 4605952 483790848 4 freebsd-zfs (231G) 488396800328- free - (164K) > If you don't have one, you'll need to create one. In the above exmaple, > I had installed the system with a tiny partition for booting with legacy > BIOS, but then moved to booting with UEFI. I did this by turning off > swapping and doing the following: > # gpart resize -i 3 -s 700 ada0 > I then created a new efi partition: > # gpart add -t efi ada0 > and I let it autosize. > > Next, I needed a FAT32 filesystem on that device. FAT16 usually will > work and often FAT12, but there are known examples of system integrators > that omit support for these last two (more the latter than the former since > it's viewed as a floppy only thing, and who uses floppies). I just used > newfs_msdos and mounted it: > # newfs_msdos -F 32 /dev/ada0p4 > # mount -t msdos /dev/ada0p4 /boot/efi > > Next, you need to put a bootloader on the system. Unless you have > special needs, loader.efi is that loader. > # mkdir -p /boot/efi/efi/boot > # cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi > All of the forums use uppercase for mountpoint/EFI/BOOT/BOOTX64.efi. Is that directory structure standard across motherboard manufacturers or is lower case allowed? > If you are using efibootmgr to set a location to boot from, generally people > create a freebsd directory (we've registered /efi/freebsd with the proper > folks > to avoid conflicts): > # mkdir -p /boot/efi/efi/freebsd > # cp /boot/loader.efi /boot/efi/efi/freebsd > # efibootmgr -c -a -k /boot/kernel/kernel -l > /boot/efi/efi/freebsd/loader.efi -L "FreeBSD Boot" > though some vendors impose limits on how many boot envs you can create > and some do not allow any at all. > Warner: Thanks for getting this effort rolling. I think that the best place for is in the Handbook since it is something that is not performed often. The /usr/src/UPDATING section can just refer to the section in the Handbook for the times the loader.efi is updated or requires re-installation. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF
Re: EFI boot partition overwritten
On Fri, Jul 16, 2021 at 6:14 AM Thomas Laus wrote: > Group: > > This is an issue for more than just CURRENT. The 'usr/src/UPDATING' > file has the instructions for updating the ZFS bootblocks but not the > EFI partition. I recently upgraded a RELEASE-12.2 to RELEASE-13.0. The > freebsd-update procedure did not upgrade the ZFS bootblocks. I forgot > that this PC was UEFI only and overwrote the first partition with the > gptzfsboot code. That made my system un-bootable. I found the recovery > procedure on one of the FreeBSD forums and was able to reformat the EFI > MSDOS partition, create the proper directory structure, and copy the > loader.efi file to the correct location and filename using the Live > Filesystem running on the installation CD. > > I searched the man pages and the UPDATING file for instructions but came > up empty and had to resort to finding the answer on one of the forums. > The filenames have changed since FreeBSD first supported EFI and some of > the forum instructions are out of date. My problem must be fairly > common and the recovery procedure should be in a man page with a > footnote or man reference somewhere on the install media. > > Since CURRENT receives more updates to the EFI boot loader than the > release versions, there should be instructions in the CURRENT > 'usr/src/UPDATING' file on how to update the EFI bootcode. > There should be. Yes. Last time I went hunting for a place to shoe-horn it in, I got distracted by something else. The instructions are relatively straight forward. I'm writing them here for your benefit, and also in case someone wants to send me a diff/pull request to include them. Or better yet, put this in the handbook and we can reference a location from there. WARNING: This is a quick run-through of how to do this if you need to. The example commands given might not be exactly right for all installations as differing numbers of partitions will change the '-i' parameters. Frist, you need a partition that's of the right type. For GPT that type is `efi` as shown in `gpart show ` eg # gpart show ada0 =>40 2000409184 ada0 GPT (954G) 401600- free - (800K) 1640 1992292792 2 freebsd-ufs (950G) 1992294432 700 3 freebsd-swap (3.3G) 1999294432 1114792 4 efi (544M) If you don't have one, you'll need to create one. In the above exmaple, I had installed the system with a tiny partition for booting with legacy BIOS, but then moved to booting with UEFI. I did this by turning off swapping and doing the following: # gpart resize -i 3 -s 700 ada0 I then created a new efi partition: # gpart add -t efi ada0 and I let it autosize. Next, I needed a FAT32 filesystem on that device. FAT16 usually will work and often FAT12, but there are known examples of system integrators that omit support for these last two (more the latter than the former since it's viewed as a floppy only thing, and who uses floppies). I just used newfs_msdos and mounted it: # newfs_msdos -F 32 /dev/ada0p4 # mount -t msdos /dev/ada0p4 /boot/efi Next, you need to put a bootloader on the system. Unless you have special needs, loader.efi is that loader. # mkdir -p /boot/efi/efi/boot # cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi If you are using efibootmgr to set a location to boot from, generally people create a freebsd directory (we've registered /efi/freebsd with the proper folks to avoid conflicts): # mkdir -p /boot/efi/efi/freebsd # cp /boot/loader.efi /boot/efi/efi/freebsd # efibootmgr -c -a -k /boot/kernel/kernel -l /boot/efi/efi/freebsd/loader.efi -L "FreeBSD Boot" though some vendors impose limits on how many boot envs you can create and some do not allow any at all. Warner
Re: PATH: /usr/local before or after /usr ?
On 16/07/2021 16:50, Cameron Katri via freebsd-current wrote: On Fri, Jul 16, 2021 at 09:01:49AM -0600, Alan Somers wrote: FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. AFAICT that convention began with SVN revision 37 "Initial import of 386BSD 0.1 othersrc/etc". Why is that? It would make sense to me that /usr/local/X should come first. That way programs installed from ports can override FreeBSD's defaults. Is there a good reason for this convention, or is it just inertia? The biggest example I can think of this being a problem is having binutils installed, it will cause any calls to elftoolchain or llvm-binutils to go to GNU binutils which is platform specific, so cross compiling, or LTO could be broken because of using GNU binutils which don't support cross compiling or LTO. FWIW: In about 20 years of using FreeBSD, my $PATH has always had /usr/local/bin before /usr/bin and I have never once encountered a problem from this. If I install something from ports that's already in the base system, it's invariably because I want to use it in preference to the base-system version. David
Re: PATH: /usr/local before or after /usr ?
On Fri, Jul 16, 2021 at 10:46 AM Ian Lepore wrote: > On Fri, 2021-07-16 at 09:01 -0600, Alan Somers wrote: > > FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. > > AFAICT that convention began with SVN revision 37 "Initial import of > 386BSD > > 0.1 othersrc/etc". Why is that? It would make sense to me that > > /usr/local/X should come first. That way programs installed from ports > can > > override FreeBSD's defaults. Is there a good reason for this convention, > > or is it just inertia? > > -Alan > > I have a hierarchy on my machines rooted at /local and /local/bin is > before /bin and /usr/bin in my PATH, so I can override system tools > when I explicitly want to without suffering any problems of an > unexpected override from installing a port or package. > > If you're using ports as a development environment to work on a new > gstat replacement, you could do something similar and put PREFIX=/local > in your port makefile while you're developing on it. > > -- Ian > Thanks for the feedback everyone. Here's what I'm going to do: * If you install it from cargo, it will go into ~/.cargo/bin/gstat, which (for cargo users) comes first in PATH * If you install it from ports, it will become /usr/local/sbin/gstat-rs, with a pkg-message advising you to setup an alias. -Alan
Re: PATH: /usr/local before or after /usr ?
On Fri, 2021-07-16 at 09:01 -0600, Alan Somers wrote: > FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. > AFAICT that convention began with SVN revision 37 "Initial import of 386BSD > 0.1 othersrc/etc". Why is that? It would make sense to me that > /usr/local/X should come first. That way programs installed from ports can > override FreeBSD's defaults. Is there a good reason for this convention, > or is it just inertia? > -Alan I have a hierarchy on my machines rooted at /local and /local/bin is before /bin and /usr/bin in my PATH, so I can override system tools when I explicitly want to without suffering any problems of an unexpected override from installing a port or package. If you're using ports as a development environment to work on a new gstat replacement, you could do something similar and put PREFIX=/local in your port makefile while you're developing on it. -- Ian
Re: PATH: /usr/local before or after /usr ?
> > > On Fri, 16 Jul 2021 09:01:49 -0600 > Alan Somers wrote: > > > FreeBSD has always placed /usr/local/X after /usr/X in the default > > PATH. AFAICT that convention began with SVN revision 37 "Initial > > import of 386BSD 0.1 othersrc/etc". Why is that? It would make > > sense to me that /usr/local/X should come first. That way programs > > installed from ports can override FreeBSD's defaults. > > I think that is exactly what you don't want to happen by default > (imagine all the ways the system could fall apart in a really hard to > support ways if individual standard tools from base are overridden - > especially as many users might not even notice, as it might be a > side-effect of installing some dependency of something they need). Michael states the exact reasoning that was used, and has been used repeatidly over history for this ordering of path. Any alteration of that ordering leads to issues with deterministic behavior is the bottom line. > > Users are always free to tweak PATH for their purposes of course, but > running the UNIX tools that came with the OS by default makes a lot > of sense to me. Others have noted use of aliases which is a good way to handle this. Global aliases can be installed in /etc/csh.cshrc or /etc/profile, other shells have similiar global config files. > > -m > > > Is there a > > good reason for this convention, or is it just inertia? Good reason(s). > > -Alan > -- > Michael Gmelin -- Rod Grimes rgri...@freebsd.org
Re: PATH: /usr/local before or after /usr ?
On Fri, Jul 16, 2021 at 10:11:41AM -0600, Alan Somers wrote: > Ugh, that's a good example. I was thinking more about interactive > programs, like say /usr/bin/vi vs editors/vim. Hypothetically how would > one solve the conflict if /usr/local/bin came before /usr/bin ? Install > binutils's binaries to /usr/local/libexec/binutils/ ? But a lot of ports > depend on binutils. That would be a ton of ports to update. > > BTW my motivation for this thread is a new replacement for gstat that I'm > working on. I would like to name it "gstat", but if /usr/sbin must come > before /usr/local/sbin, then that won't be a very helpful name. > -Alan Or, you could give it a different name, install it to ~/.local/bin or probably the best option, `alias gstat='/usr/local/sbin/gstat'`. But imo setting /usr/local/bin before /usr/bin will cause countless more problems than any issue it solves. - Cameron -- Cameron Katri Email: m...@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C signature.asc Description: PGP signature
Re: PATH: /usr/local before or after /usr ?
On Fri, Jul 16, 2021 at 9:54 AM Cameron Katri via freebsd-current < freebsd-current@freebsd.org> wrote: > On Fri, Jul 16, 2021 at 09:01:49AM -0600, Alan Somers wrote: > > FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. > > AFAICT that convention began with SVN revision 37 "Initial import of > 386BSD > > 0.1 othersrc/etc". Why is that? It would make sense to me that > > /usr/local/X should come first. That way programs installed from ports > can > > override FreeBSD's defaults. Is there a good reason for this convention, > > or is it just inertia? > > The biggest example I can think of this being a problem is having > binutils installed, it will cause any calls to elftoolchain or > llvm-binutils to go to GNU binutils which is platform specific, so cross > compiling, or LTO could be broken because of using GNU binutils which > don't support cross compiling or LTO. > > - Cameron Katri > > > -Alan > Ugh, that's a good example. I was thinking more about interactive programs, like say /usr/bin/vi vs editors/vim. Hypothetically how would one solve the conflict if /usr/local/bin came before /usr/bin ? Install binutils's binaries to /usr/local/libexec/binutils/ ? But a lot of ports depend on binutils. That would be a ton of ports to update. BTW my motivation for this thread is a new replacement for gstat that I'm working on. I would like to name it "gstat", but if /usr/sbin must come before /usr/local/sbin, then that won't be a very helpful name. -Alan
Re: PATH: /usr/local before or after /usr ?
On Fri, Jul 16, 2021 at 09:01:49AM -0600, Alan Somers wrote: > FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. > AFAICT that convention began with SVN revision 37 "Initial import of 386BSD > 0.1 othersrc/etc". Why is that? It would make sense to me that > /usr/local/X should come first. That way programs installed from ports can > override FreeBSD's defaults. Is there a good reason for this convention, > or is it just inertia? The biggest example I can think of this being a problem is having binutils installed, it will cause any calls to elftoolchain or llvm-binutils to go to GNU binutils which is platform specific, so cross compiling, or LTO could be broken because of using GNU binutils which don't support cross compiling or LTO. - Cameron Katri > -Alan -- Cameron Katri Email: m...@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C signature.asc Description: PGP signature
Re: PATH: /usr/local before or after /usr ?
On Fri, 16 Jul 2021 09:01:49 -0600 Alan Somers wrote: > FreeBSD has always placed /usr/local/X after /usr/X in the default > PATH. AFAICT that convention began with SVN revision 37 "Initial > import of 386BSD 0.1 othersrc/etc". Why is that? It would make > sense to me that /usr/local/X should come first. That way programs > installed from ports can override FreeBSD's defaults. I think that is exactly what you don't want to happen by default (imagine all the ways the system could fall apart in a really hard to support ways if individual standard tools from base are overridden - especially as many users might not even notice, as it might be a side-effect of installing some dependency of something they need). Users are always free to tweak PATH for their purposes of course, but running the UNIX tools that came with the OS by default makes a lot of sense to me. -m > Is there a > good reason for this convention, or is it just inertia? > -Alan -- Michael Gmelin
PATH: /usr/local before or after /usr ?
FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. AFAICT that convention began with SVN revision 37 "Initial import of 386BSD 0.1 othersrc/etc". Why is that? It would make sense to me that /usr/local/X should come first. That way programs installed from ports can override FreeBSD's defaults. Is there a good reason for this convention, or is it just inertia? -Alan
Re: EFI boot partition overwritten
On Fri, Jul 16, 2021 at 3:15 PM Thomas Laus wrote: > > Since CURRENT receives more updates to the EFI boot loader than the > release versions, there should be instructions in the CURRENT > 'usr/src/UPDATING' file on how to update the EFI bootcode. > Old systems have little efi part 800K or smaller and require creating new, end of disk or cut swap.
EFI boot partition overwritten
Group: This is an issue for more than just CURRENT. The 'usr/src/UPDATING' file has the instructions for updating the ZFS bootblocks but not the EFI partition. I recently upgraded a RELEASE-12.2 to RELEASE-13.0. The freebsd-update procedure did not upgrade the ZFS bootblocks. I forgot that this PC was UEFI only and overwrote the first partition with the gptzfsboot code. That made my system un-bootable. I found the recovery procedure on one of the FreeBSD forums and was able to reformat the EFI MSDOS partition, create the proper directory structure, and copy the loader.efi file to the correct location and filename using the Live Filesystem running on the installation CD. I searched the man pages and the UPDATING file for instructions but came up empty and had to resort to finding the answer on one of the forums. The filenames have changed since FreeBSD first supported EFI and some of the forum instructions are out of date. My problem must be fairly common and the recovery procedure should be in a man page with a footnote or man reference somewhere on the install media. Since CURRENT receives more updates to the EFI boot loader than the release versions, there should be instructions in the CURRENT 'usr/src/UPDATING' file on how to update the EFI bootcode. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF
