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.
signature.asc
Description: PGP signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
