update-grub (grub-mkconfig) includes all kernels in boot, regardless whether version is in /lib/modules

[Peter Passchier]

All kernels/initrds in /boot are included, also if they would never work. Below is a patch that fixes this.

1. Ubuntu 16.04.1 LTS (but it has always been like this)
2. grub-common 2.02~beta2-36ubuntu3.2
3. Only the kernels/initrds that have a version that is installed are listed on grub-mkconfig
4. All kernels/initrds in /boot are enumerated

--- 10_linux 2016-08-14 11:19:24.037604092 +0700
+++ /etc/grub.d/10_linux 2016-08-14 18:13:53.714595280 +0700
@@ -289,6 +289,12 @@
   rel_dirname=`make_system_path_relative_to_its_root $dirname`
   version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
   alt_version=`echo $version | sed -e "s,\.old$,,g"`
+ ## Only if version is in /lib/modules
+ if [ "x$(echo /lib/modules/* |grep $version)" = "x" ]
+ then
+ list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
+ continue
+ fi
   linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"

   initrd=

[Phillip Susi (psusi)]

It is entirely possible to build a kernel without modules and it will run just fine without anything in /lib/modules, so this change is not appropriate.

[Peter Passchier (peter-passchier)]

OK, I see your point. Maybe I've been looking at the wrong marker (although all installs of Ubuntu that I know of would have modules). But there must be some other marker that a particular kernel was never installed in this system??

Or are you saying that any random kernel from some other system/distribution will run fine with any other system?? If that is the case, this fix is totally unnecessary, but is that true?

[Phillip Susi (psusi)]

Any kernel will likely work, including one you compile yourself.

[Peter Passchier (peter-passchier)]

I understand you can build your own kernel and include all the necessary drivers and modules into the image. If you don't include everything in the kernel image, making an initramfs with update-initramfs is not going to work, it first issues a warning about the missing /lib/modules for that home-built version of the kernel, and then depmod gives an error that it can't open that directory, which is fatal. So there is no way to use update-initramfs using that kernel.

Now update-grub doesn't care, it will use the initrd it can find with the matching version if present.

[Phillip Susi (psusi)]

It sounds like you forgot to make modules_install.

[Peter Passchier (peter-passchier)]

I'm not building any kernels here. I am sharing the boot partition with various sorts of LUKS encrypted root partitions.

I understand now why it is totally fine to run your system with all kinds of kernels & initrds. It just works.

I also have a patch for 30_os-prober that fixes things. (It has more problems, sometimes it has the wrong root-partition, and os-prober has various ways of collecting information about the systems to include for booting with grub (including parsing grub.cfg itself, which doesn't work so well when all these different root systems actually share the same grub.cfg). The way that works well for me is also enumerating the kernels based on the presence of the matching version in /lib/modules. But again, you could boot any root partition from any kernel, as I learned.

In am not sure anymore why I wouldn't want to..?! It is sometimes handy to have the modules there, especially if you use dkms build systems or do other building.

[Phillip Susi (psusi)]

You said that update-initramfs would fail on a custom kernel because you don't have /lib/modules populated. That would only happen if you forgot to make modules_install.

[Peter Passchier (peter-passchier)]

Or if like you said in comment #1, if you build a kernel without modules which will run just fine without anything in /lib/modules.

And in #3 you said, you can run any kernel (of the right architecture) from anywhere, and it seems you are right. But you can't customize or update the initrd for it of course.