Date: Mon, 2 Apr 2018 12:43:26 -0400 From: Zaphod Beeblebrox <zbeeble@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: On UEFI dual booting. Message-ID: <CACpH0Me%2BJtqSsnNFG2mzTyoao9R4xiq7g=HeZknEvda%2BgS8Gnw@mail.gmail.com> In-Reply-To: <CANCZdfqVGcMt40y43LbNuJMjc4apJ8O%2BhRdTrp=UXQPiB10knw@mail.gmail.com> References: <CACpH0Md-XivJ=V_rtbYR5b-yPf_hwkqc0T=a06uFLHJ3Mtj59Q@mail.gmail.com> <CANCZdfqVGcMt40y43LbNuJMjc4apJ8O%2BhRdTrp=UXQPiB10knw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I suppose my subject was a bit of a misnomer. I'm not trying to get boot1.efi or loader.efi to do the dual-booting thing. I've got a tool called "refind" doing that. It presents a menu and allows you to call various other efi things. The problem is that, even if I weren't dual booting, the twin problems (graphical mode errors using boot1.efi, partition selection errors using loader) prevent even regular booting. The sole outlier is cd9660 booting --- loader.efi comes from the CD image and continues to boot by accessing /boot on the CD image. I was trying emphasize that solving the first problem might be as simple as vigorously resetting the video mode when the kernel started. Both boo1.efi and loader.efi seem to understand boot1's fallback to EFI text mode (if that is, what I understand, they are doing). This all fails when the kernel starts ... as if the screen is just in the painfully wrong mode. The second problem is solvable in two ways. One, a hack, it seems if I expand the default EFI partition to a gig (or two), I can put the contents of /boot, including the kernel, on the FAT EFI partition. loader.efi seems willing to read things there. M$ default EFI partition is only 100 meg... so not enough room for even minimal boot files, I don't think. I'll be trying this when the new disk arrives tomorrow. The second solution to the second problem is allowing command line arguments to loader to point it at a disk. refind seems to suggest that UUID and partition name (both GPT properties) are good choices. I have tried setting "currdev" and "rootdev" ... neither seem to work. currdev seems to be set on startup to the EFI disk. rootdev doesn't seem to take effect ... I know that "part7:" is the right value there ... if it would accept it. I would be willing to do some testing, BTW, and FWIW, I even have a single port KVM that could be hooked to said laptop, if required. On Sun, Apr 1, 2018 at 6:55 PM, Warner Losh <imp@bsdimp.com> wrote: > Dual boot doesn't work with UEFI. boot1.efi and loader.efi have different > sets of issues, but basically they guess what to boot, and that's > incompatible with selecting this or that. > > This is a problem I've been working on for the past 9 months. I've peeled > away many layers of this onion (and gotten side tracked by lua for a bit), > but I'm finally back to the point where I have a loader.efi that can be on > the ESP (the DOS partition) and that's setup to finish implementing the > UEFI boot manager protocol.... > > Warner > > On Sun, Apr 1, 2018 at 4:03 PM, Zaphod Beeblebrox <zbeeble@gmail.com> > wrote: > >> I've put in about 6 hours of trying to get UEFI dual booting to work. At >> this point, the "dual boot" part works fine, but the FreeBSD part fails in >> several interesting ways. >> >> In case anyone cares, the hardware is an HP zBook 15 (with no suffixes). >> It's a i7-4900 machine with a dual (Quadro 2100 and Intel) graphics >> personality. Don't worry about that bit, tho, we don't get that far. >> >> The system has two disks --- both sata. One is m.2 sata and the other is >> 2.5 inch sata. I've installed "refind" on the EFI patition that Windows >> created on the 2.5 inch drive. I'm trying to get FreeBSD to be happy on >> the m.2 drive. >> >> The FreeBSD install (so far) has a UFS, swap and ZFS GPT partitions. >> >> I can boot the 11.1 CD as UEFI. Critically, the 11.1 CD seems to use >> "loader.efi" directly. This works. The CD boots and is usable as such. >> >> The problem starts with boot1.efi. It seems to use text mode ... or >> 800x600... or something. It seems to work. Loader then runs in the same >> screen mode, but when the kernel starts, it's all over the screen... one >> pixel wide strips of white. Like the kernel is writing to the wrong >> resolution of screen. loader.efi also seems to get the size of things >> wrong. After filling 25 lines, anything you type or have displayed >> overwrites the 25th line of the screen. >> >> So... I can try starting loader.efi directly from the EFI partition. >> This, >> however, seems to completely ignore the partitions on the other disk (and >> their types). I've even tried using refinds "volume" setting and/or >> setting the command line arguments to loader.efi to tune either "currdev >> or >> rootdev" environment variables. The right partition (for the ufs pre-boot >> partition" is "part7:" in terms of loader. >> >> It would seem that I can get loader.efi to work IFF I put all of FreeBSD's >> /boot onto the DOS EFI partition. Windows only made it 500 megabytes, but >> I'm considering the hack. This may be the only way it works, but it seems >> it's not the way we "meant" it to work. >> >> So... asking the group: Is there a way for boot1.efi to support EFI >> graphical console, or, is there a way to get loader.efi smarter about >> searching for partitions to boot, or, can we get the kernel to better >> initialize the EFI console as it boots? >> >> Note, BTW, that the kernel never seems to get the console correct... even >> after booting. I can type blind, but that's it. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACpH0Me%2BJtqSsnNFG2mzTyoao9R4xiq7g=HeZknEvda%2BgS8Gnw>