On Mon, Dec 18, 2017 at 1:21 PM, Maxim Sobolev <sobomax_at_freebsd.org> wrote: > Not really specific to UEFI, but when ZFS is in use the /boot might be > partially or fully located on the drive that does not correspond to your > boot drive. We've bumped into this issue on AWS recently when our kernel > ended up on second drive after upgrade in a pool that were spanning two EBS > volumes. Now, it does not work with AWS (as boot code only has access to > the boot EBS volume apparently), but according to Alan such scenario is > totally supported on a physical hardware. So I am worried that by not > allowing loader to scan all drives in the system you'd make this scenario > fundamentally impossible. > Let's get one thing clear: nothing in what I've said would make this impossible. The first thing we do is to boot off something specific, no matter what that specific thing might be. If you want to boot a kernel off a floppy after loading /boot/loader.efi from cdrom, I don't care and won't prevent that since you can easily specify that with UEFI paths. For UFS the above scenario wouldn't automatically work, but could easily be made to work. ZFS is a bit special, since it spans multiple drives. I'm not touching the code that hunts for the zpools at all. If we can find them, and they have the right info, we'll still boot. I'm surprised the upgrade didn't work, especially with the code that's gone in to hunt for disks to present as devices in the loader itself. The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on a device other than the one the loader.efi came from. No other boot loader we have does that. No other loader outside of the tree does that to my knowledge. boot1.efi is the only one that did, and it was a bad call to do so. Warner > On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark <jakob_at_alvermark.net> > wrote: > >> On 12/17/17 20:52, Warner Losh wrote: >> >>> Greetings >>> >>> If you are booting off UEFI and have a bit of an unusual setup, I'd like >>> you to drop me a line. >>> >>> The setup that I'm looking for is any case where you load boot1.efi off >>> one >>> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that >>> drive, but on a different drive on the system. >>> >>> An example of this may be loading boot1.efi off what FreeBSD would call >>> /dev/ada0p1, but having root come from /dev/ada1p1. >>> >>> It's my belief that due to the fragility of this setup, few, if any, >>> people >>> have this setup. If you do, please take a minute to reply to this >>> message. >>> In the coming months, we're looking at dropping boot1.efi and instead >>> installing /boot/loader.efi onto the ESP (most likely as >>> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI >>> Boot Manager, we're dropping the 'search every device in the system' part >>> of the current boot1 algorithm. It will be possible to configure the >>> system >>> to continue booting (either via the new efibootmgr which will allow any >>> imaginable combination, or possibly via a fallback mechanism needed for >>> the >>> embedded EFIs that have poor UEFI Variable support at the moment), but as >>> part of an upgrade to a future FreeBSD 12, some intervention will be >>> necessary. >>> >>> Please let me know if you have an unusual setup like this. >>> >>> Warner >>> >> Hi Warner, >> >> I have what I guess is an unusual setup, not like what you describe >> above, but unusual because I tripple-boot my laptop using only the UEFI >> boot manager to select the OS to boot. >> I have FreeBSD-current, OpenBSD-current and Windows 10 on different >> partitions on one SSD. By default it boots FreeBSD. >> >> This was accomplished with bcdedit.exe in Windows, but now I realize this >> could be done with the new efibootmgr. >> I wanted to try it out, but it panics on my laptop. Sometimes just >> 'kldload efirt' just panics, sometimes it loads but panics as soon as I run >> efibootmgr or efivar. >> How can I help debugging this? >> >> Jakob >> >> _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org >> " >> >> >Received on Mon Dec 18 2017 - 19:29:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC