systemd-boot (Re: PR: fsateler/coredump)

[Julian Andres Klode]

On Wed, Oct 07, 2015 at 02:31:19PM +0200, Michael Biebl wrote:
> Am 07.10.2015 um 14:13 schrieb Julian Andres Klode:
> > I thought about this a bit. What we need is basically two things:
> > 
> 
> > (1) a package installing the bootloader tools and updating the
> >     bootloader in the ESP
> > (2) a package setting up the bootloader, and installing it to
> >     the ESP (this could have d-i support).
> > 
> > Those should probably be separate, so you can just install
> > systemd-boot without having it start managing your boot
> > process (grub is split up like this).
> 
> Ok, I have to admit I don't understand the finer details / implications
> here yet.

So, people might want to just have the bootloader binaries
available, but do not want automatic setup. grub split the
binaries into grub-efi-amd64-bin, and the automatic setup
in grub-efi-amd64.

This way you could use systemd-boot on a USB stick for
example (I do that).


> 
> > Now, (2) is actually independent of systemd, the bootloader
> > spec can be implemented by multiple bootloaders (not sure
> > which do yet, I think some ARM bootloaders do already). So
> > it might make sense to provide this a generic mechanism. That
> > can be inside systemd or outside of it (something like
> > bootloader-configuration, or kernel-install-advanced
> > [or extending kernel-install upstream with requested
> > features - multiple ESPs for example]).
> 
> Would you build this package from src:systemd or use a
> different/independent source package?

If we can get kernel-install extended to cover the needs
of our users, we could build a kernel-install package from
src:systemd. WRT user needs, one is listed in Bug#755978
and the other options my gummiboot package has are:

<< EOF
# The EFI boot partition
GUMMIBOOT_EFI="/boot/efi"

# Set the root device. If not specified, this is read from /proc/cmdline
GUMMIBOOT_ROOT=""

# Set the options to pass to the kernel command line
GUMMIBOOT_OPTIONS="ro quiet systemd.show_status=1 libahci.ignore_sss=1"

# Set to install to install default bootloader, or update to only update
# existing systemd-boot installations, but not make it the default.
BOOTCTL_COMMAND="install"

EOF

Whereas kernel-install only supports setting command-line options,
including the root device, reading /etc/kernel/cmdline if available
and falling back to /proc/cmdline.

Also, the initramfs needs to be copied by adequate hooks (note that
dracut currently does not have such hooks, or did not last time
I checked :().

> 
> > For (1), splitting systemd-boot out is an option, but I'm
> > not sure if the overhead is worth it, it's basically bootctl
> > + the systemd-boot binary,
> 
> Afaics, that's about 200K. So yeah, I could live with having those
> shipped in the systemd package.
> 
>  and bootctl is useful on its
> > own, even for people not using systemd-boot (it shows the
> > boot configuration).
> 
> > You could keep that in the systemd package itself, and still
> > run bootctl update in systemd's postinst script, as that does
> > no harm, it only updates existing bootloader copies in the
> > ESP (unfortunately, only one, with a fixed path, instead of
> > supporting all non-removable ESPs).
> 
> I mentioned splitting of systemd-boot since that is what I recalled when
> we spoke about that at debconf. You mentioned some additional scripts
> you wrote for gummiboot and that those should not be shipped in the
> systemd binary package.

Yeah, I was mostly thinking about splitting out because of the
scripts, but if we keep systemd-boot in the main package, and just
have a scripts package like kernel-install, that would probably be
better.

systemd can just run bootctl update for the ESP on any upgrade,
ignoring failures (or checking whether /boot/efi is the ESP
first), that won't hurt at all, as it won't take over the boot
process, just update existing copies placed there by other
distributions [which is intended, and one reason never to
patch the bootloader itself in a way that changes behavior].

> 
> 
> > There's also the question of patching the default paths to
> > /boot/efi instead of /boot. The patch I provided a long time
> > ago did this everywhere, even in docs, but that's probably
> > to hard to maintain, so just patching the default value in
> > the code seems like a good idea (We could also re-enable the
> > ESP auto mount unit then).
> 
> Would it make sense to get input from Colin/our grub maintainers on this
> topic?

I don't think there's much to discuss here with (only) grub
maintainers.

(1) enabling the auto mount unit, after changing it to boot-efi
    seems entirely safe

(2) We need to have the ESP in /boot/efi currently (or not in /boot),
because the kernel installs there (and initramfs is generated
there).

Upstream plan was to install the kernel to /lib, and copy it
to the ESP into an <ID>/<KERNELVER>/ directory, and to directly
generate the initramfs in there (ID being the value from 
os-release).

As an example of the layout, my ESP has:

b522d57c4e1e042e05a41e94522adf30/4.2.0-1-amd64/initrd
b522d57c4e1e042e05a41e94522adf30/4.2.0-1-amd64/linux
b522d57c4e1e042e05a41e94522adf30/4.2.0-trunk-amd64/initrd
b522d57c4e1e042e05a41e94522adf30/4.2.0-trunk-amd64/linux

The reason for this being that multiple installations need to
co-exist on the same ESP partition.

But those kernel to /lib and initramfs target path changes
are not even implemented by Fedora yet. 

[Small note:
 Oh, on non-EFI systems where /boot and /lib are on the same file
 system, you could even link the kernel from /lib to /boot/<ID>/<KERNELVER>
]

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
    - If you don't I might ignore you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20151008/3f6952a4/attachment-0002.sig>