[arch-dev-public] New kernel packages and mkinitcpio hooks

Tue Nov 12 21:12:46 UTC 2019

On 11/12/19 1:24 PM, Sébastien Luttringer wrote:
> On Mon, 2019-11-11 at 15:41 -0500, Eli Schwartz via arch-dev-public wrote:
>> On 11/10/19 9:54 PM, Sébastien Luttringer via arch-dev-public wrote:
>> As I said above, the documentation for kernel-install is pretty clear on
>> its expected usage. It's a one-stop shop, it executes mkinitcpio or
>> whatever other plugin you've installed for generating an initramfs, and
>> it's totally 100% independent of the mkinitcpio hook.
> 
> Hi Eli,
> 
> Let me first agree on the clarity of kernel-install documentation. Its goal is
> well summed in the man page NAME section: "Add and remove kernel and initramfs
> images to and from /boot.
> 
>> ...
>>
>> Also, yes, kernel-install mandates the use of systemd-boot. 
> No, kernel-install doesn't mandate use of systemd-boot.
> It's a modular framework to make your machine bootable.
> The default plugin, install kernel for systemd-boot which is different.

The script /usr/bin/kernel-install mandates systemd-boot, because it
detects the directory to install the kernel to by looking for a
systemd-boot config. I guess if you have both then it will still work.

If /boot/efi is your EFI partition mountpoint, but it is a 2mb partition
(it is on my system, because it contains exactly one file, that being
grubx64.efi), then this will be detected as the root install location of
your kernels. My kernels are installed to a btrfs partition that does
not conform to systemd-boot's logic. This is supported by both grub and
rEFInd.

> Since 2014, I use kernel-install[1] to manage kernel upgrades on over than 300
> Arch servers. There is regular Arch kernels, custom versioned kernels, some are
> booted with grub (uefi or not) others with systemd-boot.
> 
>> Meanwhile, mkinitcpio's presets and the kernel file which was
>> historically installed by the linux package install directly to:
>>
>> /boot/vmlinuz-linux
>> /boot/initramfs-linux.img
> An Arch plugin of few lines could easily put the files in our historical
> location. This are just examples [2][3].
> 
>> Under no circumstances can we unilaterally remove mkinitcpio presets and
>> switch to kernel-install without a mandatory manual intervention for all
>> (or most) archlinux users. 
> We can easily switch to kernel-install, without user intervention, as it was
> done with pacman hooks. Switching from mkinitcpio is another topic.

The kernel-install hook you linked to seems to create two copies of each
installed kernel, in a filesystem that is very commonly quite small in
size. This is fine if you opt into it, but I don't consider this to be
"no manual intervention" grade quality.

It also runs mkinitcpio manually, without respecting mkinitcpio.d
presets, so if anyone relies on something configured into those presets,
then automatically switching from using mkinitcpio via the current
pacman hook (which thus far has only moved from one package to another,
but still does the same thing once you've migrated to the latest
mkinitcpio package), to using mkinitcpio via kernel-install, represents
a *behavior change*.

Having kernel-install do the potential upgrade path of:
- move over the kernel
- execute the mkinitcpio preset
- copy /boot/initramfs-linux.img to its special directory
- run grub-mkconfig to configure a one-to-one copy of the non
  kernel-install initramfs/kernel for booting, when the originals still
  work flawlessly despite not having been cp'ed into a kernel-install
  specific directory

means that you're moving lots of stuff into kernel-install, then not
actually using it. It means using kernel-install for the sake of using
kernel-install, rather than because it fundamentally handles performing
a single 'cp' command better than a custom hook. It's a lot of effort to
go to if you're not actually going to buy into kernel-install's intended
use case, which is "we hardcode systemd-boot into the non-configurable
part of the tool".

It also depends on running grub-mkconfig. I will not install or update
to any version of any package that automatically modifies my grub.cfg
without my consent, as it absolutely will break my boot. I never used
grub-mkconfig, because I consider it conceptually broken by design (it
tries to be way too clever for its own good, doesn't handle corner cases
properly, and is a nightmare to debug), haven't configured its obtuse
configuration file to work with my system, etc. I've written quite a bit
of wiki documentation for using grub, from scratch, because none of the
current documentation is any good, and all of it tells you to use
grub-mkconfig (which as you may have noticed at this point, I have very
biased and emotional feelings about):
https://wiki.archlinux.org/index.php/User:Eschwartz/Grub#Configuration

Moving beyond grub. Should we also provide kernel-install plugins for
refind, syslinux, clover... do we want to support bootloaders that might
need to be generated differently on

Redesigning the boot stage of archlinux to regularly autogenerate boot
configs is something best left to user choice, for example, people
choosing to use something like your kernel-install hooks. :) This gives
people the option to choose the kernel-autoinstaller provider that
integrates with their chosen setup.

Just because it's been proven to work in one place that it was set up to
work with, doesn't mean it is 100% guaranteed to work absolutely
everywhere without any configuration at all, across many different
bootloaders and the multiple different "standard" efi directories and
infinite number of arbitrary efi directories that people have chosen
"just because I can".

> kernel-install runs a collection of scripts (hooks), with the systemd
> overriding logic. There is no huge difference with the pacman hooks, except the
> logic is cross distro, provided by systemd, and not tied to pacman.
> Improvements can be shared. What it makes me prefer systemd kernel-install than
> pacman hooks logic.

The pacman version works today, and
/usr/share/libalpm/scripts/mkinitcpio-install is just as cross distro
and not tied to pacman as kernel-install is. The pacman-specific part is
/usr/share/libalpm/hooks/90-mkinitcpio-install.hook, which simply ties
to pacman in order to execute mkinitcpio-install and give it a list of
kernel files on stdin. There's nothing stopping people from using it
anywhere they want.

It's a dead-simple system, which lots of people have historically used
and been happy with. There's no reason it cannot coexist with
kernel-install, and there's no reason people cannot continue to work on
it, if they like the way it works.

...

tl;dr

I think it's perfectly reasonable to consider kernel-install to be an
alternative to the traditional generic method, and warmly encourage
people who like kernel-install to finally write documentation and wiki
guides for using it, rather than proposing to declare it the sole
supported boot method.

It looks like you have a lot of great ideas for doing that! Maybe you
could help get us there? Do you think your kernel-install plugins would
make for a good package to add to the official repos in order to
implement your example boot configuration? This could help us get ready
for a day in the future when Giancarlo's suggestion "We can have a
single hook in the future that reads from a configuration file which
method the user wants" can be implemented.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191112/7bc88018/attachment.sig>