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

Michael Biebl biebl at debian.org
Wed Oct 7 13:31:19 BST 2015


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.

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

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


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

> Long term, the best option would be to look at fstab / systemd
> mount units and figure out where the ESP(s) are mounted, and
> then update gummiboot in all those ESPs and/or make gummiboot
> operate on all of those automatically.
> 
> Let me know what you think about that.
> 
> I subscribed to the mailing list now, BTW.

Ah, good to know. Dropped the CC.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20151007/d9152174/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list