Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks
On 11/11/19 3:11 am, Arch Linux: Recent news updates: Giancarlo Razzolini wrote:
All our official kernels: linux, linux-lts, linux-zen and linux-hardened, do not install the actual kernel to /boot anymore.
I would like to report an issue I faced due to this. Not an issue for everyone but can be an issue in a certain special cases. I have a custom package (in my custom repo) which modifies grub UI / menus (cosmetic change only) by putting some files in /etc/grub.d/ and regenerates /boot/grub/grub.cfg (by calling grub-mkconfig in package's post install script). This has been working fine from 2 years or so. Recently I released an update to that custom package but at the same time, upgrades to linux as well as linux-lts packages were also available in arch repository. And after upgrade, grub.cfg lost linux and linux-lts menu entries completely. What happened is: 1. mkinitcpio hook first removed vmlinuz-linux, vmlinuz-linux-lts and initrd files from /boot 2. My package got updated along with new versions of linux and linux-lts 3. My package's post install script ran grub-mkconfig but new vmlinuz files did not exist yet in /boot. So grub entries were not created for them. 4. mkinitcpio-install post transaction hook runs and copies kernel to /boot (but its too late for my post install scripts) So effectively this created an un-bootable system requiring manual booting. This is going to happen every time my package plus linux / linux-lts package get upgraded in the same pacman run. (i.e. this will not happen always but only in certain conditions) I know my issue is not common and I will also change my script to post transaction hook. But this is to warn anyone who has a custom package with post install script which looks for / expects kernel files in /boot. (like grub-mkconfig). Those scripts are going to break with the recent changes to kernel package and it would be advisable to put them in post transaction hook and that too after mkinitcpio-install scripts run. Regards, Amish
Em novembro 13, 2019 14:30 Amish via arch-general escreveu:
I would like to report an issue I faced due to this. Not an issue for everyone but can be an issue in a certain special cases.
Even so, I would prefer if you made this bug report on bugs.archlinux.org.
1. mkinitcpio hook first removed vmlinuz-linux, vmlinuz-linux-lts and initrd files from /boot 2. My package got updated along with new versions of linux and linux-lts 3. My package's post install script ran grub-mkconfig but new vmlinuz files did not exist yet in /boot. So grub entries were not created for them. 4. mkinitcpio-install post transaction hook runs and copies kernel to /boot (but its too late for my post install scripts)
So effectively this created an un-bootable system requiring manual booting.
This is going to happen every time my package plus linux / linux-lts package get upgraded in the same pacman run. (i.e. this will not happen always but only in certain conditions)
I know my issue is not common and I will also change my script to post transaction hook.
But this is to warn anyone who has a custom package with post install script which looks for / expects kernel files in /boot. (like grub-mkconfig). Those scripts are going to break with the recent changes to kernel package and it would be advisable to put them in post transaction hook and that too after mkinitcpio-install scripts run.
I've purposefully made the mkinitcpio hook to have the same precedence number as the old hook had: 90-mkinitcpio-install.hook. Specifically so people relying on things ran after the kernel was installed could do so. Instead of relying on a install script to call grub, if you used a hook and put it after the previous linux hook/current mkinitcpio hook, it would have worked just fine. Bottom line is, this change shouldn't affect most Arch Linux installs (otherwise we'd be swamped with bug reports by now). And, as always, people doing customized things to their boot process, should always make sure it is working and, I hope, be able to fix it when it breaks. Regards, Giancarlo Razzolini
On 13/11/19 11:22 pm, Giancarlo Razzolini wrote:
Em novembro 13, 2019 14:30 Amish via arch-general escreveu:
I would like to report an issue I faced due to this. Not an issue for everyone but can be an issue in a certain special cases.
Even so, I would prefer if you made this bug report on bugs.archlinux.org.
I did not create a bug report because I was not sure if this falls under bug or not. Because this is a design change and my issue is possibly the anticipated side effect.
I know my issue is not common and I will also change my script to post transaction hook.
But this is to warn anyone who has a custom package with post install script which looks for / expects kernel files in /boot. (like grub-mkconfig). Those scripts are going to break with the recent changes to kernel package and it would be advisable to put them in post transaction hook and that too after mkinitcpio-install scripts run.
I've purposefully made the mkinitcpio hook to have the same precedence number as the old hook had: 90-mkinitcpio-install.hook. Specifically so people relying on things ran after the kernel was installed could do so.
I am not sure but I feel that install hook should now have higher priority so that kernel is copied back to /boot as early as possible instead of after most of the hooks. i.e. say after systemd hooks, may be renamed to 40-mkinitcpio-install.hook? Thanks a lot for all your replies Regards Amish.
Hello Amish,
I am not sure but I feel that install hook should now have higher priority so that kernel is copied back to /boot as early as possible instead of after most of the hooks. i.e. say after systemd hooks, may be renamed to 40-mkinitcpio-install.hook?
The order is correct. The initramfs should be created after depmod and the building of dkms modules. I don't see why the kernel should be copied earlier, anything that modifies boot entries should do it after the initramfs has been created. The order of hooks also has no impact on post-install scripts. Just don't use post-install to change the boot menu. At that time the initramfs images could still be missing even with the old packages that have the kernel in /boot. This would mess up the grub configuration as well. Regards, Andy
Hello Andy, On 14/11/19 3:05 pm, ProgAndy wrote:
Hello Amish,
I am not sure but I feel that install hook should now have higher priority so that kernel is copied back to /boot as early as possible instead of after most of the hooks. i.e. say after systemd hooks, may be renamed to 40-mkinitcpio-install.hook? The order is correct. The initramfs should be created after depmod and the building of dkms modules. I don't see why the kernel should be copied earlier, anything that modifies boot entries should do it after the initramfs has been created. While I agree with you but I still feel that 90-priority is too low. (or too late). It should run immediately after depmod and dkms hooks.
But I also understand that maintainers know much better than me.
The order of hooks also has no impact on post-install scripts. Just don't use post-install to change the boot menu. At that time the initramfs images could still be missing even with the old packages that have the kernel in /boot. This would mess up the grub configuration as well.
No earlier it did not mess up, because earlier removal hooks were PostTransaction hooks and now PreTransaction. Which means that initramfs (of old kernel) were still not deleted when post install grub script ran. So it did not mess up. But in any case, I will covert my grub based script to post transaction hook with priority of 91. Thanks again and best regards, Amish.
participants (3)
-
Amish
-
Giancarlo Razzolini
-
ProgAndy