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

[Eli Schwartz]

On 11/11/19 12:00 PM, Damjan Georgievski via arch-general wrote:
>> This has been discussed a bit on the dracut thread, as well on some other threads over time.
>> I *personally* don't like the complexity of kernel-install that much.
> 
> I've now read this twice on Arch mail lists, so I have to ask, without
> any presumptions on my side, what are the arguments against
> kernel-install?
> 
> I must say, I don't see much complexity in it. It's only a 184 line
> bash script[1].

A one line bash command in the PKGBUILD is 184x less complex, then.
That's a pretty major difference.

(One line of bash in the PKGBUILD, plus running mkinitcpio -p linux, vs.
kernel-install plus still running mkinitcpio -k "${uname_r}" -g
/boot/$MACHINE_ID/${uname_r}/initrd -- mkinitcpio is a static constant
here, unless you switch to dracut.)

But if you want my $0.02 why I personally think it is too complex, the
answer is I've read the script and internalized what it does, and
irrespective of the "line count" I consider the actions which it
undertakes to do, to be too many complex moving parts to make me
comfortable relying on it on my own laptop.

> And as added feature, it decouples the kernel install from the kernel
> package install (and pacman),
> also defines couple of easy-to-use config locations like /etc/kernel/cmdline
> 
> But I guess I might be missing something.

For a really simple setup, it is totally unnecessary and I would prefer
my kernel to be tracked by pacman. It needs no modifications in order
for me to use it in my bootloader (I use grub, which is capable of
booting with a 3-line grub.cfg, 4 lines if your kernel is stored on a
luks-encrypted partition), so why not simply use it from pacman's own
installation location?

Why is it explicitly a feature to "decouple the kernel from the package"?

Why is it a feature to store the kernel cmdline in a location divorced
from your bootloader?

That being said, there is literally nothing whatsoever stopping people
from using kernel-install if they want to.

Aside: kernel-install surely does not care whether it uses the 'cp'
command to copy files from /boot, or whether it uses the 'cp' command to
copy them from /lib/modules. So it was fully usable 5 years ago, as far
as I can tell. It was even fully usable during the short transition
period when /lib/modules/${uname_r}/vmlinuz was a symbolic link pointing
to /boot/vmlinuz-linux, because the POSIX definition of 'cp' mandates
that it copy over the file contents of the regular file which the
symbolic link points to (unless the script overrides this by using the
-P, --no-dereference option). It works and worked with dracut too, since
dracut's uefi executable generation also reads file contents after doing
symlink traversal, via objcopy.

The entire history of Arch Linux has been completely one hundred percent
supportive of people's desire to use kernel-install. If no one is doing
it, I can only presume no one actually wanted to do it.

...

Now, if the discussion is about making the kernel-install workflow a
hard requirement of using mkinitcpio, I do not understand the logic
here. mkinitcpio is one of the programs executed by kernel-install, as
implemented via /usr/lib/kernel/install.d/50-mkinitcpio.install

As such, it would make zero sense for mkinitcpio's own alpm-hook to
execute kernel-install before running mkinitcpio, only for
kernel-install to then run mkinitcpio again, in addition to a bunch of
other kernel-install specific stuff that isn't mkinitcpio's
responsibility. kernel-install is NOT a program to copy over the kernel
to the bootloader's final destination! It is a one-stop-shop that wants
to do everything from beginning to end, including take charge of
mkinitcpio itself. If you want to use kernel-install, then delete and
mask the alpm-hooks

/usr/share/libalpm/hooks/60-mkinitcpio-remove.hook
/usr/share/libalpm/hooks/90-mkinitcpio-install.hook

and write your own, which trigger on the same package updates but
instead run kernel-install according to the documented kernel-install API.

Also, please write wiki documentation for it. As far as I can tell, no
Arch Linux user has ever gone to the effort of writing up guidance on
using the officially supported kernel-install program which Arch Linux
has always installed and has provided mkinitcpio plugins for since
September 2013.

It would be wonderful if Arch Linux would, in the spirit of user choice
to which we aspire, provide guidance on opting into the use of a
technology that a significant percentage of our active community says
they would like to use.

-- 
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-general/attachments/20191111/e130459c/attachment.sig>