mintupdate runs 'update-grub' which regenerates the grub.cfg file after every kernel it removes. This is very slow if there are multiple kernels to be removed (i.e. the /boot partition is running out of space) especially since it also runs OS-Prober and so on.
If multiple kernels are queued for removal, then mintupdate should only re-run update-grub at the end of the job queue.
Describe alternatives you've considered
Perhaps mintupdate can do an 'sed' on the grub.cfg file and just remove the menuitems for the kernel that it deleted without regenerating the whole file every time.
I assume the current mode of operation is a 'fail-safe' so that if the kernel removal process is interrupted in the middle the grub.cfg file will always reflect the actual kernels still installed, and thus not have menu items for kernels that are no longer present. I am not sure how to alleviate this risk, but it seems like a very low risk situation.
mintupdate runs 'update-grub' which regenerates the grub.cfg file after every kernel it removes. This is very slow if there are multiple kernels to be removed (i.e. the /boot partition is running out of space) especially since it also runs OS-Prober and so on.
If multiple kernels are queued for removal, then mintupdate should only re-run update-grub at the end of the job queue.
Describe alternatives you've considered Perhaps mintupdate can do an 'sed' on the grub.cfg file and just remove the menuitems for the kernel that it deleted without regenerating the whole file every time.
I assume the current mode of operation is a 'fail-safe' so that if the kernel removal process is interrupted in the middle the grub.cfg file will always reflect the actual kernels still installed, and thus not have menu items for kernels that are no longer present. I am not sure how to alleviate this risk, but it seems like a very low risk situation.