On Tue, Feb 4, 2014 at 9:52 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
