PR: fsateler/coredump

[Julian Andres Klode]

On Wed, Oct 07, 2015 at 01:58:38PM +0200, Michael Biebl wrote:
> Am 05.10.2015 um 04:20 schrieb Felipe Sateler:
> > Hi,
> > 
> > I have for a few weeks now used systemd-coredump as built from the
> > fsateler/coredump branch. I have made it an extra package because
> > 
> > 1. It brings an additional dependency (properly stage1 guarded)
> > 2. The kernel.core_pattern config is single-valued: only one such
> > handler can be set.
> > 2b. This means conflicts with apport, which is installed by default in ubuntu.
> > 3. This is probably unneeded in containers and other small-footprint images.
> > 
> > I'd appreciate taking a look. Having backtraces by default will be
> > very helpful in diagnosing all sorts of problems. This could be
> > achieved by a Recommends from systemd to systemd-coredump, but I do
> > not have that change in my branch.
> 
> I'm fine with splitting it off into a separate package for now.
> 
> It would be rather simple to fold it back into the systemd package later
> on should we decide to have coredump available everywhere.
> 
> If we have to go through NEW anyway, I would like to also see
> systemd-boot split off as we discussed at debconf.
> 
> Julian, did you have any chance to look into this?
> 

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

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

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

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

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.
-- 
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/20151007/8078c5cc/attachment-0002.sig>