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

[Tobias Hunger]

Hi Lennart,

On Wed, Oct 22, 2014 at 7:03 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

No problem at all:-)

>> On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering
>> 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.

That implies that each installation snapshot must come with an initrd,
even if the only change to earlier versions is the snapshot name. That
sounds suboptimal to me.

But then I am playing with atomic upgrades for a while now and in
practice each snapshots comes with its own initrd anyway.

>> > 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.

I am following Arch and create new snapshots daily. For me the kernel
updates way less often than the rest. The initrd does change for each
snapshot though. I need to investigate what is causing that. I would
have expected the initrd to change more often than the kernel, but
definitely not for each update. Maybe mkinitcpio bakes in some
timestamp or something.

>> > 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.

I agree that this should work for secure boot and a classic
distribution upgrade.

For my non-secure boot use case with incremental/daily upgrades the
necessary changes to the systemd-fstab-generator were already merged
(Thanks!), so I am waiting impatiently for the next systemd release to
hit the arch repos.

Those were the last bits I needed for my grand atomic upgrade scheme
to work without me having to patch stuff locally:-) Now I can proceed
to move more of my systems over to actually use it.

PS: Your scheme was significantly simpler to get up and running than
the ostree-approach I tried before. But maybe that was just because I
started out with a working ostree setup:-)

Best Regards,
Tobias