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