Re: Setting up /boot when it is not a separate partition

[Chris Murphy <lists colorremedies com>]

On Mon, Jul 20, 2015 at 2:39 PM, Bill Bogstad <bogstad pobox com> wrote:
> On Mon, Jul 20, 2015 at 1:56 PM, Chris Murphy <lists colorremedies com> wrote:
> > Sounds similar to this bug. I haven't tested this in over a year so
> > I'm not sure what's changed if anything. But I really think it needs
> > to work with single volume installations. For the vast majority of
> > sane booting needs, separate /boot doesn't make much sense anymore and
>
> As far as I know, the standard way to have an encrypted / filesystem
> is to use a separate unencrypted /boot partition.   Whether that is a
> "sane" booting need probably depends on what kind of environment you
> expect to encounter.  I admit that I don't know if ostree is useable
> with encrypted partitions but I'm not sure that making it harder to
> get that working would be a good thing.

It's sane. It's also completely fair to constrain the OSTree supported
use cases. Endless features mean endless bugs.

However, GRUB has supported cryptoluks for a long time, and dracut
supports key files for a while, so it's possible to do single LUKS
passphrase at GRUB to get to a login prompt. And all of this is
stable. The problem is the RH/Fedora installer doesn't support this
configuration.

This turns into a problem though, for any significant number of root
fs trees with many versions of /lib/modules which implies just as many
kernels. If those kernels can only go on a limited space separate
/boot volume, this becomes a show stopper in short order with a
platform like Fedora with frequent kernel releases. It's also a
problem on e.g. Btrfs where a reasonable snapshotting strategy would
want to make sure there's also parity between available kernels to
/lib/modules and vice versa, instead of breaking boot.

Either type of single volume boot use cases need a single volume
encryption option; or you need a more involved method of managing
kernels and /lib/modules; or you need more stable kernels so that they
aren't changing so often and don't need to accumulate; or you need to
have a much more scaled back snapshotting regimen.

So, I find separate /boot to be archaic. Users would be better off
with a self-contained recovery partition instead that's similar to a
live OS image. Getting dropped at a pre-mount dracut shell isn't
exactly helpful for mortal users, and the UX is much better if a live
OS image were booted instead, including a decent possibility for at
least wired network access and a web browser, as well as a complete
pile of troubleshooting utilities.



-- 
Chris Murphy