On Fri, Jun 3, 2016 at 7:39 PM, Justin Brown <justin.br...@fandingo.org> wrote: > Here's some thoughts: > >> Assume a CD sized (680MB) /boot > > Some distros carry patches for grub that allow booting from Btrfs
Upstream GRUB has had Btrfs support for a long time. There's been no need for distros to carry separate patches for years. The exception is openSUSE, where they have a healthy set of patches for supporting the discovery of and boot of read only snapshots created by snapper. Those patches are not merged upstream, I'm not sure if they will be. >, so > no separate /boot file system is required. (Fedora does not; Ubuntu -- > and therefore probably all Debians -- does.) The problem on Fedora is that they depend on grubby to modify the grub.cfg. And grubby gets confused when the kernel/initramfs are located on a Btrfs subvolume other than the top level. And Fedora's installer only installs the system onto a subvolume (specifically, every mount point defined in the installer becomes a subvolume if you use Btrfs). So it's stuck being unable to support /boot if it's on Btrfs. > >> perhaps a 200MB (?) sized EFI partition > > Way bigger than necessary. It should only be 1-2MiB, and IIRC 2MiB > might be the max UEFI allows. You're confusing the ESP with BIOSBoot. The minimum size for 512 byte sector drives per Microsoft's technotes is 100MiB. Most OEMs use something between 100MiB and 300MiB. Apple creates a 200MB ESP even though they don't use it for booting, rather just to stage firmware updates. The UEFI spec itself doesn't say how big the ESP should be. 200MiBi is sane for 512 byte drives. It needs to be 260MiB minimum for 4Kn drives, because of the minimum number of FAT allocation units at 4096 bytes each requires a 260MiB minimum volume. > >> The additional problem is most articles reference FDE (Full Disk Encryption) >> - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having >> problems finding concise links on the topics, -FDE -"Full Disk Encryption". > > Yeah, when it comes to FDE, you either have to make your peace with > trusting the manufacturer, or you can't. If you are going to boot your > system with a traditional boot loader, an unencrypted partition is > mandatory. /boot can be encrypted, GRUB supports this, but I'm unaware of any installer that does. The ESP can't be encrypted. http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/ It's vaguely possible for the SED variety of drive to support fully encrypted everything, including the ESP. The problem is we don't have OPAL support on Linux at all anywhere. And for some inexplicable reason, the TCG hasn't commissioned a free UEFI application for managing the keys and unlocking the drive in the preboot environment. For now, it seems, such support has to already be in the firmware. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
