| From: William Park via talk <talk@gtalug.org> | I have bad experience with UEFI. You can't just move the disk to a new | motherboard, and boot. Is that the only bad experience? UEFI firmware setup screens are not standardized. Generally, all you have to tell UEFI is the path of the .efi program to boot. This is kept in the non-volatile RAM on the motherboard. efibootmgr(8) lets you see a really low-level view of these settings. You can manipulate them with efibootmgr, but the firmware setup page is surely friendlier. $ sudo efibootmgr -v BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,0003,0001,0002,0009,000A,0007,0008,000B Boot0000* Fedora HD(2,GPT,f66e4ede-1301-47fd-af96-7f45aee7bc28,0x40800,0xb4000)/File(\EFI\fedora\shimx64.efi) Boot0001* USB Floppy/CD VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0500000001)..BO Boot0002* USB Hard Drive VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0200000001)..BO Boot0003* Windows Boot Manager HD(2,GPT,f7299bd6-0e7f-49a5-a41a-3873fa9f6ee3,0x200000,0xb4000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................ Boot0007* USB Floppy/CD VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0500000000)..BO Boot0008* Hard Drive BBS(HD,,0x0)..GO..NO........o.S.T.2.0.0.0.D.M.0.0.1.-.1.C.H.1.6.4....................A...........................>..Gd-.;.A..MQ..L.1.Z.4.E.9.W.4.B. . . . . . . . . . . . ........BO..NO........o.T.O.S.H.I.B.A. .T.H.N.S.N.H.2.5.6.G.B.S.T....................A...........................>..Gd-.;.A..MQ..L. . . . . . . . .3.7.S.R.0.1.N.A.E.T.Y.8........BO Boot0009* ATAPI CD-ROM Drive VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0300000001)..BO Boot000A* CD/DVD Drive BBS(CDROM,,0x0)..GO..NO........o.h.p. . . . . . . .B.D.D.V.D.R.W. .C.H.3.0.L....................A...........................>..Gd-.;.A..MQ..L.2.3.C.0.0.F.0.0.5.8. .6. . . . . . . . ........BO Boot000B* Realtek PXE B03 D00 BBS(Network,,0x0)..BO Each boot target has a 4-digit label. Each BootNNNN line says what each of those labels means. The * means bootable (like * in fdisk output for an MBR drive). HD(2,GPT,f66e4ede-1301-47fd-af96-7f45aee7bc28,0x40800,0xb4000) designates the ESP of the SSD. \EFI\fedora\shimx64.efi is the path withing the ESP of the thing to boot to start loading Fedora. There is a similar line for Windows. But it has UTF16 noise after the path. | For UEFI, I would need 2 partitions (/ and /boot/efi) at minimum. Yes. | Some distro | adds /boot and /home. So, 4 partitions. I don't know | - if UEFI came about to support these multi partitions, or | - if distro are simply taking advantage of GPT. UEFI demands a FAT partition for ESP (/boot/efi). No self-respecting OS would want to live on FAT, so you need at least a second partition. Any partitions beyond that are up to you and the OS. Nothing to do with UEFI. GPT does make it slightly easier to have more than 4 partitions (no extended partition nonsense; any partition could be made bootable). | When disk fails, it rarely fails by partitions. It fails as whole disk. | So, partitioning isn't as useful as it sounds. My disk failures are more often actually file-system failures. Using several filesystems reduced the damage inflicted by such a failure. | All other disks are raw disks in raid1 multi-disk btrfs. So, it uses | /dev/sdc, /dev/sdd, ... as whole, not /dev/sdc1, /dev/sdd1, ... I don't really understand everything about BTRFS. I understand it can partition the storage it manages, a bit like LVM.