Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
On Tue, Mar 09, 2021 at 02:19:27PM -0700, Warner Losh wrote: > On Tue, Mar 9, 2021 at 2:15 PM Ruben van Staveren wrote: > > I think it it noteworthy to have this in the release notes somewhere. that > > is, if bootx64.efi needs updates every now and then > > > > That's a good suggestion. I'll make sure something is in the release notes. Not directly related to the need of updating the bootloader, but wouldn't it make sense to describe the creation of an ESP partition in the EXAMPLES section of gpart(8), similar to what is already there for legacy boot ? Then maybe add a few lines on how to populate it, even if it is not done with gpart subcommands. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
On Tue, Mar 9, 2021 at 2:22 PM Patrick M. Hausen wrote: > Hi Warner, > > > Am 09.03.2021 um 22:00 schrieb Warner Losh :One issue > you may run into is the size of the partition. If it is tiny, > > > you'll likely have to create a new ESP. Using /boot/boot1.efi may help > and > > can be used in the last step instead of loader.efi, but it's much less > > flexible than loader.efi. > > What precisely is the difference between boot1.efi and loader.efi? > Practically from a sysadmin point of view? I have been using boot1.efi > exclusively the last couple of years to boot EFI based systems with ZFS ... > boot1.efi is a less fully functional version of loader.efi. It doesn't let you choose something else to boot. it doesn't have the ability to do some advanced security options. It has no scripting. The project, with FreeBSD 13, will be recommending that people move to loader.efi where possible. boot1.efi is still built, but likely should only be used for legacy purposes for people that have a far-too-tiny ESP for loader.efi. It will receive limited updates in the future and may be removed in the fullness of time. Due to the ZFS move to OpenZFS, boot1.efi needs to be updated anyway (well, technically only if you migrate the zpool to the latest version), and most installations would be better served by loader.efi being installed there and/or migrating to efibootmgr to set a specific thing to boot. Though, due to quality of BIOS implementation issues, efibootmgr's functionality varies from vendor to vendor depending on how well they adhere to the standards. I'm working on some text for the release notes to make all this clear and in one place. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
Hi Warner, > Am 09.03.2021 um 22:00 schrieb Warner Losh :One issue you > may run into is the size of the partition. If it is tiny, > you'll likely have to create a new ESP. Using /boot/boot1.efi may help and > can be used in the last step instead of loader.efi, but it's much less > flexible than loader.efi. What precisely is the difference between boot1.efi and loader.efi? Practically from a sysadmin point of view? I have been using boot1.efi exclusively the last couple of years to boot EFI based systems with ZFS ... Thanks! Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein signature.asc Description: Message signed with OpenPGP
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
On Tue, Mar 9, 2021 at 2:15 PM Ruben van Staveren wrote: > > Also, I’m missing /boot/*efifat* in FreeBSD13. What is the procedure for >> updating EFI loaders? >> > > They have been removed because they are no longer needed (filesystem > images for boot blocks trouble me too). > > > Agree, but I’ve felt I’ve missed the memo > I did it long enough ago I had forgotten to make sure people upgrading from 12 knew. > > mount -t msdos /dev/da0pX /mnt > mv /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64-old.efi > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi > > The ESP on UEFI systems is just a FAT filesystem. > > > Yes. > > I think it it noteworthy to have this in the release notes somewhere. that > is, if bootx64.efi needs updates every now and then > That's a good suggestion. I'll make sure something is in the release notes. Warner > > One issue you may run into is the size of the partition. If it is tiny, > you'll likely have to create a new ESP. Using /boot/boot1.efi may help and > can be used in the last step instead of loader.efi, but it's much less > flexible than loader.efi. > > Warner > > > Thanks, > Ruben > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
> Also, I’m missing /boot/*efifat* in FreeBSD13. What is the procedure for > updating EFI loaders? > > They have been removed because they are no longer needed (filesystem images > for boot blocks trouble me too). Agree, but I’ve felt I’ve missed the memo > > mount -t msdos /dev/da0pX /mnt > mv /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64-old.efi > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi > > The ESP on UEFI systems is just a FAT filesystem. Yes. I think it it noteworthy to have this in the release notes somewhere. that is, if bootx64.efi needs updates every now and then > > One issue you may run into is the size of the partition. If it is tiny, > you'll likely have to create a new ESP. Using /boot/boot1.efi may help and > can be used in the last step instead of loader.efi, but it's much less > flexible than loader.efi. > > Warner Thanks, Ruben signature.asc Description: Message signed with OpenPGP
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
On Tue, Mar 9, 2021 at 8:56 AM Ruben van Staveren via freebsd-stable < freebsd-stable@freebsd.org> wrote: > Hi List, > > With FreeBSD 13 getting near release I was trying out a new hardware setup > for a future upgrade, in where a zfs SATA RAID-10 array would be accelated > by some NVME devices for cache, log, and special meta data. > > However, booting the setup under VMWare fusion gives me a lot of zio_read > error: 5 / ZFS: i/o error - all block copies unavailable whereas in > VirtualBox using the same VMDKs the setup boots without issue, both in UEFI > mode > > I used the guided ZFS install, GPT UEFI only, and choose RAID-10 and zero > swap as I want to use the NVME devices for that later on. > > when on the loader prompt lsdev / lszfs / ls works through latter two > throw out zio_read error: 5 but show recognisable output (zfs filesystems, > files) > > > disk0 through 4 are the SATA disks with only an EFI and ZFS GPT partition > each, disk4/5 is reserved for the special vdevs (but not in use yet) and > swap > > If I press escape and end up in VMWare’s UEFI setup screen I can boot from > any ada*p1 drive and continue as normal. > Is UEFI with OpenZFS too new, or is this an issue in VMWare? > > > > Also, I’m missing /boot/*efifat* in FreeBSD13. What is the procedure for > updating EFI loaders? > They have been removed because they are no longer needed (filesystem images for boot blocks trouble me too). mount -t msdos /dev/da0pX /mnt mv /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64-old.efi cp /boot/loader.efi /mnt/efi/boot/bootx64.efi The ESP on UEFI systems is just a FAT filesystem. One issue you may run into is the size of the partition. If it is tiny, you'll likely have to create a new ESP. Using /boot/boot1.efi may help and can be used in the last step instead of loader.efi, but it's much less flexible than loader.efi. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
Hi List, With FreeBSD 13 getting near release I was trying out a new hardware setup for a future upgrade, in where a zfs SATA RAID-10 array would be accelated by some NVME devices for cache, log, and special meta data. However, booting the setup under VMWare fusion gives me a lot of zio_read error: 5 / ZFS: i/o error - all block copies unavailable whereas in VirtualBox using the same VMDKs the setup boots without issue, both in UEFI mode I used the guided ZFS install, GPT UEFI only, and choose RAID-10 and zero swap as I want to use the NVME devices for that later on. when on the loader prompt lsdev / lszfs / ls works through latter two throw out zio_read error: 5 but show recognisable output (zfs filesystems, files) disk0 through 4 are the SATA disks with only an EFI and ZFS GPT partition each, disk4/5 is reserved for the special vdevs (but not in use yet) and swap If I press escape and end up in VMWare’s UEFI setup screen I can boot from any ada*p1 drive and continue as normal. Is UEFI with OpenZFS too new, or is this an issue in VMWare? Also, I’m missing /boot/*efifat* in FreeBSD13. What is the procedure for updating EFI loaders? signature.asc Description: Message signed with OpenPGP
Re: kldload zfs spins the system after upgrading from 12.2 to 13-BETA
On 08/03/2021 05:24, Yoshihiro Ota wrote: > On Sun, 7 Mar 2021 00:09:33 +0200 > Andriy Gapon wrote: > >> On 06/03/2021 20:09, Yoshihiro Ota wrote: >>> Hi all, >>> >>> I'm upgrading fron 12.2-RELEASE to 13-BETA/RC one by one. >>> >>> After upgrading one in VMWare, 'zfs mount -a' hangs the system. >>> I don't have boottime zfs mount on nor don't have zfsroot. >>> I just simply ran install world/kernel and mergemaster. >> >> Please use procstat -kk to capture a kernel stack trace of the hung process. > > Actually, spining was 'kldload zfs'. > Console doesn't response but ping and sshd sessions still work. > procstat output is below. > In addition, this doesn't happen to systems that I've been following > 13-CURRENT > but rather happen only wiht a system upgraded from 12.2-RELEASE to 13-RC. > > > # procstat -kk 1049 > PIDTID COMMTDNAME KSTACK > > 1049 100215 kldload - spa_init+0xc6 > zfs_kmod_init+0x1a zfs_modevent+0x34 module_register_init+0x8c > linker_load_module+0xaab kern_kldload+0xc1 sys_kldload+0x50 syscall+0x17d > g_ctx+0xe280bf29 > If you could use kgdb to find out what source code line spa_init+0xc6 corresponds to that may help to see what's going on. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Backporting if_wg to FreeBSD 12
Hello to all! As I know, if_wg support was added into freebsd head. Are there any plans for backporting if_wg support to FreeBSD 12? -- MATPOCKuH ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
