>>>>> "CM" == Chris Murphy <lists@xxxxxxxxxxxxxxxxx> writes: CM> A few releases ago, Anaconda now defaults to a 1GiB boot partition CM> which should prevent the problem you're describing for anyone using CM> the default 3 retained kernels, as well as the extra kdump initramfs CM> if you're using kdump (not enabled by default on Fedora). That is not true; the issue is not about free space in /boot. The kernel package is properly constructed to preserve 20MB in boot and RPM itself will not allow the transaction to proceed if that space isn't available. (I would argue that 20MB is cutting it a bit close, but in the specific case I had (with a 19MB initramfs file) it was sufficient. The specific issue that caused the initramfs to fail to generate was the lack free space in /var/tmp for dracut's temporary files. CM> I think it's in new-kernel-pkg where grubby ends up being called CM> twice, and why you see this. OK, so 20-grub.install will call new-kernel-package. But the problem remains the same: initramfs creation fails, but grub is still updated. So maybe the issue isn't in the ordering of the kernel-install scripts but in new-kernel-package. CM> And modifying grub.cfg is going away. It was supposed to happen for CM> Fedora 29, but is being pushed to Fedora 30. OK, that's good. It will still be important that whatever configuration file actually sets up the bootloader for the new kernel is not enabled until after the initramfs has been generated. CM> So you could just give up and focus on the new thing being made CM> robust if you want. Seems unfortunate to just ignore the problem. Maybe it's simply rare enough, but to be fair I have seen an unpleasant number of desktops I manage not able to reboot without human intervention due to missing initramfs files. I would wager that they're down to the same base issue (bootloader config done regardless of whether the initramfs was generated) but they aren't all due to lack of free space in /var/tmp. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
