Re: New UEFI guide on the wiki
On Feb 6, 2014, at 12:39 AM, Dariusz J. Garbowski thufo...@yahoo.co.uk wrote: On 05/02/14 05:46 PM, Przemek Klosowski wrote: On 02/04/2014 06:18 PM, Chris Murphy wrote: And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? At times in the past there was a race between BIOS support for large disks and hard disk size, and BIOS boot code could not reach the far sectors of the disk. This even leaked into Linux sometimes, Right but BIOS only ever expected to have to read LBA 0, so it stands to reason someone's not testing whether it can jump beyond LBA 28-bit addressing if it's an ancient BIOS implementation; or beyond the MBR 32-bit address limit. But since the UEFI spec is predicated on LBA 48-bit addressing, I think my diplomatic language would be WTF vendor if UEFI firmware face planted on an ESP at the end of a 5TB drive. I should test it. Oh hey, it works with whatever UEFI VirtualBox uses. This is the layout. Firmware finds shim.efi way out well beyond 3TB, and GRUB is finding its grub.cfg way out there as well and boots the system fine. Disk /dev/sda: 1024000 sectors, 4.8 TiB […] Number Start (sector)End (sector) Size Code Name 1 10238871552 1023966 551.0 MiB EF00 EFI System 22048 1026047 500.0 MiB 0700 3 1026048 10238871551 4.8 TiB 0700 It still happens: I just had a case of this on Dell R620 (Ivy Bridge Xeon) with over 3TB disk space and RHEL 6.5... Grub couldn't reach it's files to boot OS. RHEL 6.5 uses ancient GRUB 0.97 so the problem could be with the boot loader, or the firmware. However, without having this computer physical present, how can you tell it uses UEFI and not BIOS? I certainly can't. Dell's spec sheet for it says in part From bezel to BIOS to packaging which seems like just a tagline, not a spec per se. But then the support page explicitly refers to it as BIOS: Dell Server BIOS PowerEdge R620 Version 2.1.3 http://www.dell.com/support/drivers/us/en/04/DriverDetails/Product/poweredge-r620?driverId=T2RVCosCode=WS8R2fileId=3329675946languageCode=encategoryId=BI In general, finding out whether a system's firmware is BIOS or UEFI is not easy. Either they don't say, as if it isn't a selling point, yet telling me it uses the, e.g. Intel C600 chipset isn't too obscure. HP pretty much universally refers to the UEFI firmware updates as BIOS updates. Idiotic. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Wed, 2014-02-05 at 01:41 -0500, David wrote: On 2/5/2014 12:52 AM, Adam Williamson wrote: On Tue, 2014-02-04 at 21:47 -0500, David wrote: On 2/4/2014 5:41 PM, Adam Williamson wrote: On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) I always enjoy these UEFI threads. Not. EfI has been a replacement-in-progress for the old BIOS for a long time. U(universal)EFI has been around a while as an upgrade for EFI. Someday, perhaps soon, BIOS will die. Which means? If Linux can not play nice with UEFI then Linux will die with BIOS. Er. What's your point? This whole thread started from a rather extensive guide to installing Fedora on UEFI which I wrote. We're now discussing rather pie-in-the-sky stuff that doesn't have much to do with what you posted. Sure it does. In a way. Whenever UEFI is mentioned there is a panic in the ranks. Windows!! Windows!! Microsoft!! Microsoft!! Which is crap. There is no real problem. You need to fix the conspiracy crap. Fix it? Or live/die with it. What? I didn't say anything about Microsoft. I opined that firmware vendors couldn't find their rear ends with two hands and a map, which isn't a particularly controversial opinion among anyone who's had to deal with their work. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:18:27PM -0700, Chris Murphy wrote: Does anyone know why the convention is to create the ESP as the first partition? Because that's the only configuration anyone's likely to have tested. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 02:45:29PM -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 2:41 PM, Adam Williamson awill...@redhat.com wrote: You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) Not really -- I figure that either the firmware is only parsing the protective MBR (in which case the existence of an ESP won't even be detectable) or that the firmware actually supports UEFI, in which case I'd be fairly impressed if it matters. You're missing the not uncommon case of UEFI firmware with CSM forcibly enabled and no UEFI boot option which was much of the market between 2009 and 2011. These implementations will frequently understand GPT well enough to decide that a disk isn't BIOS bootable, but won't let you perform a UEFI boot instead. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Wed, Feb 5, 2014 at 4:44 AM, Florian Weimer fwei...@redhat.com wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? Fedora doesn't support 32-bit UEFI (at the moment). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 02/05/2014 01:09 PM, Josh Boyer wrote: On Wed, Feb 5, 2014 at 4:44 AM, Florian Weimer fwei...@redhat.com wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? Fedora doesn't support 32-bit UEFI (at the moment). Okay. What would be a good spot to add this to in the document? After the list in the Do I have a UEFI firmware? section? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:56:02PM +, Matthew Garrett wrote: Yeah it's really a mistake for us to be using the linux/initrd commands under any circumstances. I have created the following bug report https://bugzilla.redhat.com/show_bug.cgi?id=1055157 which was reverted because the maintain wrote the EFI boot is the prefered method for booting Fedora Linu on an MacBook Pro. I'm wondering why RHEL 7 Beta - which I have instelld in a VM (Parallels) - uses linux16/initrd16 in the grub.cfg file. This may have a reason. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Wed, 2014-02-05 at 10:44 +0100, Florian Weimer wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? It's not officially supported. I have such a system sitting right here (one of those annoying Bay Trail tablets) and it's fairly trivial to generate an image that boots on it, and even do an installation to it (I helped one of the guys at Intel do that, and it worked). If we ever get the hardware support for the first-gen Bay Trail devices in a usable state I'll probably release an unofficial F20-based image that's 32-bit UEFI capable, but we're unlikely to support 32-bit UEFI officially: the next generation of Bay Trail-based devices will use 64-bit firmwares, it's only the first gen and the first gen of x86 Apples (which are not pretty much obsolete) that used 32-bit UEFI firmwares in the wild. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Wed, 2014-02-05 at 13:30 +0100, Florian Weimer wrote: On 02/05/2014 01:09 PM, Josh Boyer wrote: On Wed, Feb 5, 2014 at 4:44 AM, Florian Weimer fwei...@redhat.com wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? Fedora doesn't support 32-bit UEFI (at the moment). Okay. What would be a good spot to add this to in the document? After the list in the Do I have a UEFI firmware? section? Sounds about right, yep. We can make the note very specific - I'd say the Bay Trail devices are the only ones we really have to care about. Hell, there's few enough that we can just list them by name. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 02/04/2014 06:18 PM, Chris Murphy wrote: And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? At times in the past there was a race between BIOS support for large disks and hard disk size, and BIOS boot code could not reach the far sectors of the disk. This even leaked into Linux sometimes, IIRC: LILO would use BIOS calls to load the kernel, and it would work on the original install because kernel was dropped on disk early on and end up in the low sectors, but would fail on kernel upgrade when the kernel blocks would end up in the filesystem areas beyond the BIOS reach. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 05/02/14 05:46 PM, Przemek Klosowski wrote: On 02/04/2014 06:18 PM, Chris Murphy wrote: And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? At times in the past there was a race between BIOS support for large disks and hard disk size, and BIOS boot code could not reach the far sectors of the disk. This even leaked into Linux sometimes, It still happens: I just had a case of this on Dell R620 (Ivy Bridge Xeon) with over 3TB disk space and RHEL 6.5... Grub couldn't reach it's files to boot OS. Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Mon, Feb 03, 2014 at 08:14:06PM -0800, Andrew Lutomirski wrote: (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) If your hard disc is GPT partition the movement from BIOS to UEFI boot shoot be very easy. You have to install grub2-efi and create the configuration file on /boot/efi/EFI/fedora/grub.cfg. Thy other wy may be harder, because you need 1.) A special BIOS Boot partition (type EF02) with a size of 1 MB. This is required because grub2 can't write the bootstrapping code behind the partition table of a GPT. 2.) A hybrid partition table created with gdisk. The MBR must contains the BIOS Boot partiition as an primary bootable partition. This may affect the usability of other OSs installed on the same disc depeneding of the creation of protected MBR partitions. You may use gptsync to create a hybrid partition table. This is only recommented, if you disk has no more the four partitions 3.) On my MacBoot Pro (late 2013) I required the usage of the linux16/initrd16 commands instead of linux/initrd commands for the BIOS-mode boot. You may see, that I can't advise the installation of a BIOS-mode boot system on a GPT partioned disc, because there are severals pitfalls which you have to considered. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Mon, 3 Feb 2014 20:14:06 -0800 Andrew Lutomirski l...@mit.edu wrote: that in the wiki. (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) Have tried this in the past as an experiment, after 4 or five different flavored change attempts. None were really successful. As AdamW typed, backup and reinstall for bios? if that's what works for you. It'll be quicker and cleaner. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:42:23PM +0100, Jochen Schmitt wrote: On Mon, Feb 03, 2014 at 08:14:06PM -0800, Andrew Lutomirski wrote: (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) If your hard disc is GPT partition the movement from BIOS to UEFI boot shoot be very easy. You have to install grub2-efi and create the configuration file on /boot/efi/EFI/fedora/grub.cfg. …and configure the UEFI boot options, which you can't do because you're not running under UEFI and so have no access to UEFI runtime services. The workarounds required for this will tend to be vendor specific, although ensuring that you have the fallback loader supplied by shim may work in many cases. 3.) On my MacBoot Pro (late 2013) I required the usage of the linux16/initrd16 commands instead of linux/initrd commands for the BIOS-mode boot. Yeah it's really a mistake for us to be using the linux/initrd commands under any circumstances. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: …and configure the UEFI boot options, which you can't do because you're not running under UEFI and so have no access to UEFI runtime services. That's probably the biggest flaw in the whole UEFI setup - you can't access it unless you boot using it, and you can't boot from it unless you access it to configure it. It makes switching to UEFI (or the old-time common practice of installing to a drive in one machine and then moving it to another) difficult (at best). I have a friend that worked for a BIOS vendor and now for a CPU vendor that I think helped write some of the UEFI spec - I need to bug him on that one. :) -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 9:15 AM, Chris Adams li...@cmadams.net wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: …and configure the UEFI boot options, which you can't do because you're not running under UEFI and so have no access to UEFI runtime services. That's probably the biggest flaw in the whole UEFI setup - you can't access it unless you boot using it, and you can't boot from it unless you access it to configure it. It makes switching to UEFI (or the old-time common practice of installing to a drive in one machine and then moving it to another) difficult (at best). There are at least two ways to hack around this. You can boot from a live UEFI image, chroot in, and do the magic incantation to get GRUB to install itself, or you can call your bootloader bootx64.efi (IIRC) and try to convince your firmware to load it. I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) I have a friend that worked for a BIOS vendor and now for a CPU vendor that I think helped write some of the UEFI spec - I need to bug him on that one. :) -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
I've done conversions in both directions a few times although not very recently. But having done it, I'd say f it, just reinstall. Or f it, get drunk and sent to the hospital is even a better experience than converting. BIOS-UEFI - BIOS install won't have an EFI System partition, so you have to shrink something. Easiest is pilfering some from the 500MB /boot. Or alternatively from the LVM partition, which is a non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. Yay LVM by default - so this step is easier, by a lot, without LVM. - If there's a spare MBR entry (primary) available, then the ESP type code 0xEF is used. The UEFI spec says firmware should support this configuration but I don't know how well tested it is. - If converting MBR to GPT, the last partition file system needs resizing because otherwise it overlaps with the backup GPT. If the last partition is LVM (which is the default location for default installations, again yay LVM by default) you have to do the non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. UEFI-BIOS - The 200MB FAT ESP can be blown away in favor of a 1+MB BIOS Boot quite easily. Both directions require updating fstab to varying degrees. And both require booting alternate media, such that the system is booting in the mode you are converting to, assembling the file system (easiest with anaconda rescue option at boot time from non-live install media), chrooting the mount point, reinstalling grub, creating a new grub.cfg, and rebuilding the initramfs. However, the reinstalling grub procedure is not the same between the two directions and of course the grub.cfgs go in two different locations *sigh*. For UEFI-BIOS: it's possible to just do grub2-install dev, and grub2-mkconfig -o /boot/grub2/grub.cfg. For BIOS-UEFI I'm pretty sure you're best off resinstalling the grub2-efi package (and installing/reinstalling the shim packages) so that you get the nice shim fallback behavior, the prebaked-signed grub, and therefore instructions work for either Secure Boot on or off. And then grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. Summary: UEFI to BIOS conversion is either very slightly easier if you don't use LVM and don't need conversion to GPT. Otherwise it's a lot easier. Unrelated to conversion, two unfortunates exposed: the difference in grub.cfg locations; the ESP, using one of the most fragile file systems still in use, being persistently mounted rw, and too often being modified due to the grub.cfg on the ESP. Instead the ESP grub.cfg should point via configfile to the maintained grub.cfg at /boot/grub2. Then there'd be no reason at all for /boot/efi being persistently mounted. Note that neither OS X nor Windows keep their ESPs mounted. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 9:52 AM, Chris Murphy li...@colorremedies.com wrote: I've done conversions in both directions a few times although not very recently. But having done it, I'd say f it, just reinstall. Or f it, get drunk and sent to the hospital is even a better experience than converting. BIOS-UEFI - BIOS install won't have an EFI System partition, so you have to shrink something. Easiest is pilfering some from the 500MB /boot. Or alternatively from the LVM partition, which is a non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. Yay LVM by default - so this step is easier, by a lot, without LVM. - If there's a spare MBR entry (primary) available, then the ESP type code 0xEF is used. The UEFI spec says firmware should support this configuration but I don't know how well tested it is. - If converting MBR to GPT, the last partition file system needs resizing because otherwise it overlaps with the backup GPT. If the last partition is LVM (which is the default location for default installations, again yay LVM by default) you have to do the non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. UEFI-BIOS - The 200MB FAT ESP can be blown away in favor of a 1+MB BIOS Boot quite easily. Both directions require updating fstab to varying degrees. And both require booting alternate media, such that the system is booting in the mode you are converting to, assembling the file system (easiest with anaconda rescue option at boot time from non-live install media), chrooting the mount point, reinstalling grub, creating a new grub.cfg, and rebuilding the initramfs. However, the reinstalling grub procedure is not the same between the two directions and of course the grub.cfgs go in two different locations *sigh*. For UEFI-BIOS: it's possible to just do grub2-install dev, and grub2-mkconfig -o /boot/grub2/grub.cfg. For BIOS-UEFI I'm pretty sure you're best off resinstalling the grub2-efi package (and installing/reinstalling the shim packages) so that you get the nice shim fallback behavior, the prebaked-signed grub, and therefore instructions work for either Secure Boot on or off. And then grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. Summary: UEFI to BIOS conversion is either very slightly easier if you don't use LVM and don't need conversion to GPT. Otherwise it's a lot easier. Unrelated to conversion, two unfortunates exposed: the difference in grub.cfg locations; the ESP, using one of the most fragile file systems still in use, being persistently mounted rw, and too often being modified due to the grub.cfg on the ESP. Instead the ESP grub.cfg should point via configfile to the maintained grub.cfg at /boot/grub2. Then there'd be no reason at all for /boot/efi being persistently mounted. Note that neither OS X nor Windows keep their ESPs mounted. This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? /boot is useful regardless of how you boot. The ESP doesn't need to be very large and doesn't cause any harm if booted via BIOS. The BIOS Boot partition only needs to be ~64kB IIRC, and UEFI boot will happily ignore it. You don't even need to have any contents in there. IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. Everyone wins. Especially people who install via UEFI, upgrade their BIOS, and go oh sh*t when the BIOS upgrade conveniently erases their boot entry. (Yes, that's happened to me. I think it's happened several times. The fact that I have two boxes at work, *both* of which have interestingly experimental firmwares [1], is a contributing factor.) [1] One of these interesting firmwares required me to boot, repeatedly, using UEFI, GRUB2 under BIOS, and syslinux to diagnose a bug.The bug turned out to be in GRUB2. At some point I will probably write some more upstreamable drivers for this box, and they'll have to be tested separately under UEFI and BIOS. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. Multiboot, you get to deal with either your firmware's boot manager, or learn a 3rd party replacement (including GRUB, gummiboot, or rEFInd). TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. Care to be more specific? The UX should be basically identical to grub on BIOS. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) It's a continuum. The less interaction the less customizable but the more pleasant. Automatic is great, when it just works. That usually means constraining the options. For gummiboot it means it's presently not supporting boot from anything but FAT32 which I find untenable. Way too much writing is happening on a FAT32 volume in that paradigm for my comfort level. So yes, when it decides what it wants to be when it grows up, then it could be a viable alternative. And like I mentioned in another thread [1], bootloaderspec has regressive boot capabilities also, it effectively says no to snapshotting $BOOT. Since the kernel goes on $BOOT, it means $BOOT contents can be so new they can't boot older snapshots which contain older /lib/modules. So if rootfs is being snapshot, then /boot needs to be snapshot with it. Chris Murphy [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/193857.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. How does firmware find shim.efi? Is it installed as bootx64.efi? IIRC that approach used to be frowned upon. Multiboot, you get to deal with either your firmware's boot manager, or learn a 3rd party replacement (including GRUB, gummiboot, or rEFInd). TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. Care to be more specific? The UX should be basically identical to grub on BIOS. Exactly. The GRUB2 UX is special. :) Somehow anaconda does the right thing. Since I haven't the faintest clue what the right thing is, I can't replicate it. To be fair, UEFI is slightly worse. Disk numbers seem to change on occasion if they're in a bad mood, at least on my box. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) It's a continuum. The less interaction the less customizable but the more pleasant. Automatic is great, when it just works. That usually means constraining the options. For gummiboot it means it's presently not supporting boot from anything but FAT32 which I find untenable. Way too much writing is happening on a FAT32 volume in that paradigm for my comfort level. So yes, when it decides what it wants to be when it grows up, then it could be a viable alternative. And like I mentioned in another thread [1], bootloaderspec has regressive boot capabilities also, it effectively says no to snapshotting $BOOT. Since the kernel goes on $BOOT, it means $BOOT contents can be so new they can't boot older snapshots which contain older /lib/modules. So if rootfs is being snapshot, then /boot needs to be snapshot with it. Fair enough. Some day this will all work well. In the mean time, I actually preferred GRUB 1, the lack of maintenance notwithstanding. --Andy Chris Murphy [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/193857.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? RFE: always create required bootloader partitions in custom partitioning https://bugzilla.redhat.com/show_bug.cgi?id=1022316 I'm not opposed to both ESP and BIOSboot created for every selected disk at install time. But I am opposed to the current behavior of not creating that which is mandatory for operation, while the installer then proceeds to chew me out for not having created it. It knows enough to squawk at me, but it doesn't know enough to just do the thing that needs to be done? Grrr that's not OK. And in fact it's worse in that presently I can't create an ESP per disk because the installer is mountpoint centric not partition centric. So I can only create one ESP on one disk because I can have only one /boot/efi. https://bugzilla.redhat.com/show_bug.cgi?id=1060576 /boot is useful regardless of how you boot. The ESP doesn't need to be very large and doesn't cause any harm if booted via BIOS. The BIOS Boot partition only needs to be ~64kB IIRC, and UEFI boot will happily ignore it. You don't even need to have any contents in there. GRUB devs want 1MB for BIOS Boot. And then it also maintains 1MB alignment. Nevertheless one Kleenex is more valuable than 1MB of drive space, even on an SSD. IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. I'm not opposed to the layout, but I'm personally totally disinterested in the ensuing clusterf|ck experiences I've already had with UEFI+BIOS dual boot OS's. If I could only experience food poisoning instead, my disposition would be no worse for the wear. My opinion: anything that requires BIOS to boot is old, or it's broken. And if it's old, it should be put into a VM. And if it's broken it should be fixed if it isn't a bad idea from the outset. Everyone wins. Especially people who install via UEFI, upgrade their BIOS, and go oh sh*t when the BIOS upgrade conveniently erases their boot entry. Let's agree to not equate UEFI and BIOS. There is nothing basic about UEFI. In any case, this is what BOOT/BOOTarch.EFI is for. Sorry to say but Apple had this exact scenario figured out some 30 years ago, having had so much experience with CMOS/NVRAM corruptions that there is a keyboard shortcut for every Mac since the dawn of time, that clears it. And yet it has a fallback mechanism to still boot the OS via a, probably unnecessarily clever, hint in the file system volume header. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 11:30 AM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. How does firmware find shim.efi? Is it installed as bootx64.efi? BOOT/BOOTarch.EFI IIRC that approach used to be frowned upon. UEFI spec This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost. Seems correct to me. Multiboot, you get to deal with either your firmware's boot manager, or learn a 3rd party replacement (including GRUB, gummiboot, or rEFInd). TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. Care to be more specific? The UX should be basically identical to grub on BIOS. Exactly. The GRUB2 UX is special. :) Somehow anaconda does the right thing. Since I haven't the faintest clue what the right thing is, I can't replicate it. To be fair, UEFI is slightly worse. Disk numbers seem to change on occasion if they're in a bad mood, at least on my box. You mean a disk can flip between /dev/sda and /dev/sdb between boots? That's been happening on BIOS also for years, it's not guaranteed assignment which is why UUID is better. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) It's a continuum. The less interaction the less customizable but the more pleasant. Automatic is great, when it just works. That usually means constraining the options. For gummiboot it means it's presently not supporting boot from anything but FAT32 which I find untenable. Way too much writing is happening on a FAT32 volume in that paradigm for my comfort level. So yes, when it decides what it wants to be when it grows up, then it could be a viable alternative. And like I mentioned in another thread [1], bootloaderspec has regressive boot capabilities also, it effectively says no to snapshotting $BOOT. Since the kernel goes on $BOOT, it means $BOOT contents can be so new they can't boot older snapshots which contain older /lib/modules. So if rootfs is being snapshot, then /boot needs to be snapshot with it. Fair enough. Some day this will all work well. In the mean time, I actually preferred GRUB 1, the lack of maintenance notwithstanding. That's a long ago sailed, and long lost or sunken ship. It's a choice between two week old left overs in the fridge, will I get food poisoned? Versus a new bottle of Burns Going In and Coming Out Hot Sauce™? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 10:49 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: /boot is useful regardless of how you boot. The ESP doesn't need to be very large and doesn't cause any harm if booted via BIOS. The BIOS Boot partition only needs to be ~64kB IIRC, and UEFI boot will happily ignore it. You don't even need to have any contents in there. GRUB devs want 1MB for BIOS Boot. And then it also maintains 1MB alignment. Nevertheless one Kleenex is more valuable than 1MB of drive space, even on an SSD. IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. I'm not opposed to the layout, but I'm personally totally disinterested in the ensuing clusterf|ck experiences I've already had with UEFI+BIOS dual boot OS's. If I could only experience food poisoning instead, my disposition would be no worse for the wear. That's okay. I can deal with the clusterfsck all on my own, as long as other things don't get in the way unnecessarily. :) My opinion: anything that requires BIOS to boot is old, or it's broken. And if it's old, it should be put into a VM. And if it's broken it should be fixed if it isn't a bad idea from the outset. Everyone wins. Especially people who install via UEFI, upgrade their BIOS, and go oh sh*t when the BIOS upgrade conveniently erases their boot entry. Let's agree to not equate UEFI and BIOS. There is nothing basic about UEFI. Touché! --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: And in fact it's worse in that presently I can't create an ESP per disk because the installer is mountpoint centric not partition centric. So I can only create one ESP on one disk because I can have only one /boot/efi. https://bugzilla.redhat.com/show_bug.cgi?id=1060576 You can create as many ESPs as you like, you just can't mount more than one of them in the same location. I don't see how anaconda can somehow magically fix this. If there is a 'problem' here it's the one you mentioned in another mail, that Fedora's approach to dealing with UEFI is too centred around a magic mount point, but I _really_ am not feeling that supporting fricking RAID-1 boot (which has always been more of a pain in the arse than it's worth, in my opinion) is the most pressing problem we have to deal with when it comes to UEFI. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? RFE: always create required bootloader partitions in custom partitioning https://bugzilla.redhat.com/show_bug.cgi?id=1022316 I'm not opposed to both ESP and BIOSboot created for every selected disk at install time. But I am opposed to the current behavior of not creating that which is mandatory for operation, while the installer then proceeds to chew me out for not having created it. It knows enough to squawk at me, but it doesn't know enough to just do the thing that needs to be done? Grrr that's not OK. One's a lot harder than the other. If you have multiple disks, how do we know which one you want the ESP on? If the layout you created filled the whole disk, what do we shrink to fit the ESP in? You of all people know the consequences of adding more complexity to the installer's partitioning codepaths. ;) I think the improvements for F21 - better error messages, and displaying the errors before you leave custom partitioning - should do the job fine. I think it was the bad error message and the Where's Waldo routine to find it that most confused people/pissed them off in F20 and earlier. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? I'm guessing that userspace improvements since then have mostly fixed this. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (tm). Also, isn't this already sort of necessary on large disks? (I maintain at least ten machines like this, running Fedora and various Ubuntus, some installed graphically and some installed by untarring a system image. I haven't had any problem at all.) --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 11:49 -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? The major thing was we found quite a lot of systems that just don't boot this way. Large numbers of Thinkpads appear to have firmwares that can't boot BIOS-native installs from GPT disks, for instance. We didn't auto-create a BIOS boot partition in custom partitioning, and people were often stumped by the requirement. People hit the same problem with UEFI installs and the ESP, of course, but we're stuck with that: we *have* to support UEFI. We don't have to cause ourselves the pain with BIOS-native installs. Also, people are more likely to accept that things will be different with a completely new firmware standard than they are with the idea that we just arbitrarily changed our default disk format and required them to learn about this 'BIOS boot partition' thing. Your proposal like cmurf's involves us auto-creating the BIOS boot partition, so it doesn't have *that* problem, but it has another problem, the one I pointed out to cmurf - it's not actually all that easy to have custom part just magically do stuff for you, and it certainly makes the code paths more fragile, and we really don't need any more fragility in partitioning. I'm guessing that userspace improvements since then have mostly fixed this. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (tm). You might want to go look back at the F16 release validation process and the anaconda bug list from that period. It was anything but Just Working. :) Also, isn't this already sort of necessary on large disks? Yeah. MBR disks top out at 2.2TB or something like that - you can format a bigger disk with an MBR partition table, but the space beyond whatever the limit is won't be available. These are already special-cased in the installer, if we're reformatting a disk that's above that size, we format it to GPT not MBR (and the BIOS boot partition requirement kicks in). (I maintain at least ten machines like this, running Fedora and various Ubuntus, some installed graphically and some installed by untarring a system image. I haven't had any problem at all.) Ten machines is nice and all, but we have, you know, 10,000 times that many or whatever it is to worry about for a Fedora release :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:02 PM, Andrew Lutomirski l...@mit.edu wrote: IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. I'm not opposed to the layout, but I'm personally totally disinterested in the ensuing clusterf|ck experiences I've already had with UEFI+BIOS dual boot OS's. If I could only experience food poisoning instead, my disposition would be no worse for the wear. That's okay. I can deal with the clusterfsck all on my own, as long as other things don't get in the way unnecessarily. :) So the problems with this idea you have: https://bugzilla.redhat.com/show_bug.cgi?id=1022316#c3 1. I'm not certain it's simpler code: if EFI, then GPT with ESP and BIOSBoot; if BIOS, then MBR when destination 2TB else GPT with ESP and BIOSBoot. If it is simpler for the anaconda team, fine then I'm neutral. 2. But for users, it's a total edge case to think of switching between BIOS and UEFI without reinstalling, let alone actually doing it. 3. Realize there's no way for anaconda to know if the computer is UEFI booted with the CSM. So a.) it can't use GPT for all BIOS computers, because we know from a circa Fedora 15 release that this causes problems for some BIOS firmware; and b.) using MBR there is no such thing as BIOSBoot, and blivet has no code for creating ESP's with 0xEF on MBR disks which also uses a valuable primary partition in the process, therefore the request only makes it easier to convert EFI to BIOS. It does nothing for BIOS to EFI ease of conversion. And as I argued before, needing to convert from EFI to BIOS implies something is broken and needs to be fixed, not fuck it up worse by converting the install to BIOS. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:34 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: And in fact it's worse in that presently I can't create an ESP per disk because the installer is mountpoint centric not partition centric. So I can only create one ESP on one disk because I can have only one /boot/efi. https://bugzilla.redhat.com/show_bug.cgi?id=1060576 You can create as many ESPs as you like, you just can't mount more than one of them in the same location. Yep you're right. If I had thought of creating bogus mount points first, then I can in fact tediously create ESP's per disk. Then post install I have to fix the f'd up fstab. And then copy boot files from the first ESP to all of the other ESPs. So I'd say it's not really creating ESPs when it's like that compared to the behavior on BIOS/MBR. I don't see how anaconda can somehow magically fix this. Create an ESP for every chosen disk, copy the boot files to each ESP. Just do it automatically, don't tell me, don't complain, don't show me. It's no different than BIOS/MBR. I don't understand how just because the firmware has changed we suddenly need to see required partitions. If there is a 'problem' here it's the one you mentioned in another mail, that Fedora's approach to dealing with UEFI is too centred around a magic mount point, but I _really_ am not feeling that supporting fricking RAID-1 boot (which has always been more of a pain in the arse than it's worth, in my opinion) is the most pressing problem we have to deal with when it comes to UEFI. I didn't say it was most pressing. It is a regression compared to BIOS/MBR: each chosen disk had a boot loader location created, and each boot loader location had a boot loader installed. The user had to do nothing in the installer to make that happen. I don't think I've yet to have /boot on raid1 fail to install or boot, even degraded, in any version of Fedora. So I don't know what's a PITA about it. You check a box for raid1, you put /boot on it. Done. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 12:26 -0800, Adam Williamson wrote: Your proposal like cmurf's involves us auto-creating the BIOS boot partition, so it doesn't have *that* problem, but it has another problem, the one I pointed out to cmurf - it's not actually all that easy to have custom part just magically do stuff for you, and it certainly makes the code paths more fragile, and we really don't need any more fragility in partitioning. Thinking about this a bit more, it probably wouldn't be *too* hard / complex / dangerous to at least pre-populate custom part with the appropriate 'special' partitions for your disk: i.e. run a restricted version of autopart automatically when entering the custom part spoke, which doesn't create the /boot and swap and / partitions, but just any partitions required for booting or other special circumstances. I'll add a comment to cmurf's bug... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:30 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? RFE: always create required bootloader partitions in custom partitioning https://bugzilla.redhat.com/show_bug.cgi?id=1022316 I'm not opposed to both ESP and BIOSboot created for every selected disk at install time. But I am opposed to the current behavior of not creating that which is mandatory for operation, while the installer then proceeds to chew me out for not having created it. It knows enough to squawk at me, but it doesn't know enough to just do the thing that needs to be done? Grrr that's not OK. One's a lot harder than the other. If you have multiple disks, how do we know which one you want the ESP on? All of them should. But at a minimum, each bootable disk needs one or it isn't a bootable disk, is it? So wherever /boot exists and ESP is needed. Two disk /boot on raid1? Both disk. Three disk /boot on raid5? All three disks. Otherwise why even let the user create such a thing when it can't boot upon single disk failure? Honestly… why put in the effort to build the bridge to 90% completion and then let the cars just drop one after another into the abyss? If it's offered it should work. If it's not going to work, don't offer it. If the layout you created filled the whole disk, what do we shrink to fit the ESP in? It's easier if the ESP size is withheld from Available Space for every selected disk, and every selected disk gets an ESP. But if worry warts don't want ESPs on certain drives well then that's more code that I won't oppose but I'll think is totally unnecessary. You of all people know the consequences of adding more complexity to the installer's partitioning codepaths. ;) Yeah what's complex is error checking whether an ESP is needed, and whether it's present, and the not present gripe code, translating into (how many languages are we supporting these days?) and testing all of that. For no good reason. Windows and OS X? It's one size fits all. Your boot disks get an ESP. No options. On OS X actually, all GPT disks get an ESP whether they're intended for booting or not. There is no option, no visible indication at all that the disk has or will get one and no way to specify the ESP size. No complexity and and there are no complaints in millions of users! Do we want an ESP bigger than 200MB? Fine have that conversation if you want. Maybe it ought to be 550MB so that mkdosfs will make our ESP's conform to the UEFI spec by formatting them FAT32 instead of FAT16. And then it'd also be big enough for the fans of the ESP as $BOOT for gummiboot/bootloaderspec. I'm not opposed to it being bigger. But it is precisely this type of hysterically unnecessary customization creep that has made Custom Partitioning the event horizon for QA testing. We will never ever test most let alone all combinations in Custom Partitioning because of shit just like this. I think the improvements for F21 - better error messages, and displaying the errors before you leave custom partitioning - should do the job fine. I think it was the bad error message and the Where's Waldo routine to find it that most confused people/pissed them off in F20 and earlier. *sigh* yes Adam, it's better in that a flower has sprung up from the pile. Somehow I still prefer getting rid of the turds instead of polishing them approach. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 10:30:58AM -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. How does firmware find shim.efi? Is it installed as bootx64.efi? IIRC that approach used to be frowned upon. It installs a fallback loader as bootx64.efi which then creates new boot entries for any installed operating systems it can find. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:49 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? Firmware face planted. For many it was the lack of an MBR entry with an active bit set, so there is now this PMBRboot flag where the 0xEE has an active bit set. And that pisses off other firmware. So it's no win. I'm guessing that userspace improvements since then have mostly fixed this. It wasn't a user space problem. It was a firmware problem. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (™). None are Lenova computers are they? Also, isn't this already sort of necessary on large disks? Yes but long ago Microsoft's edict was basically GTFO and buy a new computer with UEFI if you want to boot from 2+TB drives. The Windows installer requires MBR for boot disks on BIOS computers. And it requires GPT for boot disks on UEFI computers. Since most firmware testing involves seeing if Windows installs and boots successfully, it essentially means there's a lot of BIOS hardware out there that simply will not support 2+TB drives for booting, ever. (I maintain at least ten machines like this, running Fedora and various Ubuntus, some installed graphically and some installed by untarring a system image. I haven't had any problem at all.) Karma. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 11:49:06AM -0800, Andrew Lutomirski wrote: What failed? I'm guessing that userspace improvements since then have mostly fixed this. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (tm). Some firmware sees a GPT label and refuses to even attempt a BIOS boot. We tried this back in F16, tried further by violating the spec as it stood at the time and marking the protective MBR bootable and discovered that there are still systems where this just doesn't work. Also, isn't this already sort of necessary on large disks? There's not really anything else we can do in that case, so we make a best effort and if it doesn't work then, well. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 14:45 -0700, Chris Murphy wrote: You of all people know the consequences of adding more complexity to the installer's partitioning codepaths. ;) Yeah what's complex is error checking whether an ESP is needed, and whether it's present, and the not present gripe code, translating into (how many languages are we supporting these days?) and testing all of that. For no good reason. That code isn't particularly complex, actually, and we've had it for years - that's why the error message used to be so crappy, because it's generic code. There's a generic framework for requirements for stage1 bootloader targets depending on the platform. When creating a new platform you basically fill out a checklist for its requirements for a bootloader stage1 target device. For the BIOS platform that's an MBR or GPT disk. For UEFI platform it's an EFI system partition on a GPT disk. For uboot-y ARM it's a U-Boot partition. Etc etc. All using a solid mechanism that's been in anaconda for years. What you're suggesting is something different and, I think, completely new - I'm not the foremost expert on blivet or anything, but I don't think it has capabilities anything like what you're suggesting at present. Functionally speaking your description makes sense - this is just the place where the bootloader goes and we used to just take care of it for you and now we don't. But that's really not how it looks to the installer or the installer UI. The old bootloader location was not a disk partition, the user interacting with the installer could barely 'see' or 'touch' it at all. It had very limited configurability. None of this is true of the ESP (or similar designs). Windows and OS X? It's one size fits all. Your boot disks get an ESP. No options. On OS X actually, all GPT disks get an ESP whether they're intended for booting or not. There is no option, no visible indication at all that the disk has or will get one and no way to specify the ESP size. No complexity and and there are no complaints in millions of users! Millions of users don't install Windows or OS X; they get it installed for them. And have you looked at what *other* partitioning options Windows gives you? just about zip. zero. none. If we could get away with an installer that simple, we could do a lot more magical whizzy stuff, yes. But it seems fairly clear that we can't (though I'd be all in favour of it - anything for a quiet life). But it is precisely this type of hysterically unnecessary customization creep that has made Custom Partitioning the event horizon for QA testing. We will never ever test most let alone all combinations in Custom Partitioning because of shit just like this. It's not really customization creep: newUI gives you slightly less space than oldUI did. For entirely selfish reasons I'm all for an installer that's a grey box with a green GO button, but I don't think that'd exactly fly with the established Fedora/RHEL user base (remember anaconda is a shared component). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 1:52 PM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 12:49 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? Firmware face planted. For many it was the lack of an MBR entry with an active bit set, so there is now this PMBRboot flag where the 0xEE has an active bit set. And that pisses off other firmware. So it's no win. I'm guessing that userspace improvements since then have mostly fixed this. It wasn't a user space problem. It was a firmware problem. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (™). None are Lenova computers are they? Nope. In fact my only computer that I haven't done this to is Lenovo (and that's only because it has a Windows-on-TrueCrypt dual boot setup, and last time I checked that was fundamentally incompatible with UEFI. Anyway, point taken. My revised RFE is at: https://bugzilla.redhat.com/show_bug.cgi?id=1061478 and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 2:41 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) Not really -- I figure that either the firmware is only parsing the protective MBR (in which case the existence of an ESP won't even be detectable) or that the firmware actually supports UEFI, in which case I'd be fairly impressed if it matters. I suppose I could be wrong. Sigh. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 2:45 PM, Chris Murphy li...@colorremedies.com wrote: If the layout you created filled the whole disk, what do we shrink to fit the ESP in? It's easier if the ESP size is withheld from Available Space for every selected disk, and every selected disk gets an ESP. And put the ESP at the end of the disk as the last partition. Then they're on the slowest part of spinning disks. And they can be easily removed and space absorbed by the preceding file system if desired. And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 2/4/2014 5:41 PM, Adam Williamson wrote: On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) I always enjoy these UEFI threads. Not. EfI has been a replacement-in-progress for the old BIOS for a long time. U(universal)EFI has been around a while as an upgrade for EFI. Someday, perhaps soon, BIOS will die. Which means? If Linux can not play nice with UEFI then Linux will die with BIOS. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 21:47 -0500, David wrote: On 2/4/2014 5:41 PM, Adam Williamson wrote: On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) I always enjoy these UEFI threads. Not. EfI has been a replacement-in-progress for the old BIOS for a long time. U(universal)EFI has been around a while as an upgrade for EFI. Someday, perhaps soon, BIOS will die. Which means? If Linux can not play nice with UEFI then Linux will die with BIOS. Er. What's your point? This whole thread started from a rather extensive guide to installing Fedora on UEFI which I wrote. We're now discussing rather pie-in-the-sky stuff that doesn't have much to do with what you posted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 2/5/2014 12:52 AM, Adam Williamson wrote: On Tue, 2014-02-04 at 21:47 -0500, David wrote: On 2/4/2014 5:41 PM, Adam Williamson wrote: On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) I always enjoy these UEFI threads. Not. EfI has been a replacement-in-progress for the old BIOS for a long time. U(universal)EFI has been around a while as an upgrade for EFI. Someday, perhaps soon, BIOS will die. Which means? If Linux can not play nice with UEFI then Linux will die with BIOS. Er. What's your point? This whole thread started from a rather extensive guide to installing Fedora on UEFI which I wrote. We're now discussing rather pie-in-the-sky stuff that doesn't have much to do with what you posted. Sure it does. In a way. Whenever UEFI is mentioned there is a panic in the ranks. Windows!! Windows!! Microsoft!! Microsoft!! Which is crap. There is no real problem. You need to fix the conspiracy crap. Fix it? Or live/die with it. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Mon, Feb 3, 2014 at 8:09 PM, Adam Williamson awill...@redhat.com wrote: So, look what I wrote today: https://fedoraproject.org/wiki/Unified_Extensible_Firmware_Interface (just plain https://fedoraproject.org/wiki/UEFI redirects to that page, too). It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. That'll be very useful. Thanks! If you happen to know the magic incantations to turn an installed UEFI OS into a BIOS-bootable OS or vice versa, it would be great to have that in the wiki. (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) --Andy Corrections welcome, and hopefully this will be a useful resource for some... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Mon, 2014-02-03 at 20:14 -0800, Andrew Lutomirski wrote: On Mon, Feb 3, 2014 at 8:09 PM, Adam Williamson awill...@redhat.com wrote: So, look what I wrote today: https://fedoraproject.org/wiki/Unified_Extensible_Firmware_Interface (just plain https://fedoraproject.org/wiki/UEFI redirects to that page, too). It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. That'll be very useful. Thanks! If you happen to know the magic incantations to turn an installed UEFI OS into a BIOS-bootable OS or vice versa, it would be great to have that in the wiki. (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) Erf. I haven't done that myself in anger, so I'd have to give it a shot to give reliable instructions. My usual advice would be 'just reinstall it', honestly... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 3, 2014 9:31 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2014-02-03 at 20:14 -0800, Andrew Lutomirski wrote: On Mon, Feb 3, 2014 at 8:09 PM, Adam Williamson awill...@redhat.com wrote: So, look what I wrote today: https://fedoraproject.org/wiki/Unified_Extensible_Firmware_Interface (just plain https://fedoraproject.org/wiki/UEFI redirects to that page, too). It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. That'll be very useful. Thanks! If you happen to know the magic incantations to turn an installed UEFI OS into a BIOS-bootable OS or vice versa, it would be great to have that in the wiki. (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) Erf. I haven't done that myself in anger, so I'd have to give it a shot to give reliable instructions. My usual advice would be 'just reinstall it', honestly... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net I've done it, and it was indeed an angry and detailed process, so I decided it probably wasn't something I wanted to advise people to do. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
