04.06.2016 04:39, Justin Brown пишет: > Here's some thoughts: > >> Assume a CD sized (680MB) /boot > > Some distros carry patches for grub that allow booting from Btrfs, > so no separate /boot file system is required. (Fedora does not; > Ubuntu -- and therefore probably all Debians -- does.) >
Which grub (or which Fedora) do you mean? btrfs support is upstream since 2010. There are restrictions, in particular RAID levels support (RAID5/6 are not implemented). >> 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 may want to review recent discussion on systemd regarding systemd boot (a.k.a. gummiboot) which wants to have ESP mounted as /boot. UEFI mandates support for FAT32 on ESP so max size should be whatever max size FAT32 has. ... > >> 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. No, it is not with grub2 that supports LUKS (and geli in *BSD world). Of course initial grub image must be written outside of encrypted area and readable by firmware. > That being said, we live in a world with UEFI Secure > Boot. While your EFI parition must be unencrypted vfat, you can sign > the kernels (or shims), and the UEFI can be configured to only boot > signed executables, including only those signed by your own key. Some > distros already provide this feature, including using keys probably > already trusted by the default keystore. > UEFI Secure Boot is rather orthogonal to the question of disk encryption. -- 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