[systemd-devel] So how am I supposed to put together my Linux system?

[Lennart Poettering]

On Fri, 05.09.14 20:34, Tobias Hunger (tobias.hunger at gmail.com) wrote:

Heya,

Sorry for the late response, been travelling for a month, and then
have been more travelling, and still trying to process all the mails
that queued up since.

> On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > Yeah, we want to encourage distros to install kernels into /usr,
> > somewhere next to where the kmods already are, and then copy that over
> > where necessary into the used boot partition. We actually have sime
> > infrastructure for this in place in systemd, in the "install-kernel"
> > script, which also has a man page.
> 
> Any place that you would care to recomend? It would suck to have each
> distro put kernels somewhere else.

Hmm, dunno, I figure Kay/Harald might have an idea about this. Kay? Harald?

> I see that secure boot wants one file and that you will need to merge kernel
> and initrd into one. But you will need the meta data to link the kernel/initrd
> combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos
> also has that and stores that meta-data in non-volatile memory accessible to
> the BIOS.

My idea would be that the initrd contains that info. Each usr tree
comes with one initrd, and that initrd knows which usr tree to boot.

> > 2. If we cannot have external config files, then kernel/initrd should
> > find their stuff an empty kernel cmdline option.
> 
> Nice ideal, but I do not see how that will work in general. You could bake some
> id into the kernel (kernel version or whatever), but usually the kernel changes
> slower than the sum of the files in /usr. You do want to boot different of these
> usr-setups with one kernel.

Note that at least chromeos doesn't do this. They update the whole OS
at once, including the kernel. And never kernel and /usr independently.

> > 4. The initrds should probably use information from
> > /usr/lib/os-release (as shipped in the initrd as a copy of the OS'
> > version) to build the btrfs sub-volume name to boot from. It should
> > not allow overriding this name via the kernel cmdline, at least as
> > long as we are in a mode where secureboot is actually turned on...
> 
> That could work, provided there is something like a timestamp/version number
> in /usr/lib/os-release that actually changes every time *anything* in
> /usr changes
> (or at least when those changes are getting distributed as an image).
> 
> You still need to store that information somewhere though for the kernel to know
> what to boot.

Well, gummiboot picks a kernel with the initrd attached. the initrd
then finds the right /usr tree according to the information it contains.

> > Hope that makes some sense?
> 
> Not really. I do see how this can work to boot the newest
> installation of distroX: You just need to look for the newest
> version of the usr-subvolume and boot that.

Well, I think kernel and /usr hierarchy really belong together. If you
pick a kernel you thus implicitly also pick a /usr tree. 

(Of course, this strict we only need to be for a verified boot. For
other cases, we of course can allow passing arbitrary kernel cmdline
options, to pick different usr tree. The user should be able to
override things, unless the device is in trusted mode)

> How do I boot the version I ran before the upgrade in case the
> upgrade failed?

In general the rule should probably be to go back in version one-by-one
if a kernel/system failed to boot. THe boot loader should by default
boot the newest kernel, thus the newest /usr, too. if that for some
reason nerver finishes, on next reboot it should pick the kernel one
version older, and so on.

> I really do not see how you can get around storing meta-data somehow.
> 
> You can not change the kernel/initrd when it is signed, so you can not bake any
> information into that file. You can apparently not have a separate
> file when using
>
> secure boot. That leaves EFI vars I think. Do those integrate with
> secure boot?

Sure, we can store failure info in EFI Vars, no problem really.

Lennart

-- 
Lennart Poettering, Red Hat