Removing old kernel-core leaves modules.builtin.alias.bin under /lib/modules

[Jeffrey Walton]

After I remove old kernels, I see there are artifacts left over in /lib/modules. Below, I should have only two folders - one for the latest 5.4 kernel, and one for the latest 5.15 kernel.

$ ls /lib/modules
5.15.0-41-generic 5.15.0-46-generic 5.4.0-126-generic
5.15.0-43-generic 5.15.0-48-generic

$ ls /lib/modules/5.15.0-41-generic/
misc modules.builtin.alias.bin modules.dep.bin modules.symbols
modules.alias modules.builtin.bin modules.devname modules.symbols.bin
modules.alias.bin modules.dep modules.softdep

This appears to be a rehash of Red Hat Issue 2016630 - Removing old kernel-core leaves modules.builtin.alias.bin under /lib/modules, https://bugzilla.redhat.com/show_bug.cgi?id=2016630 .

[Nick Rosbrook (enr0n)]

Are you invoking kernel-install to remove kernels? Or what action did you perform exactly? It appears there is a lot more than modules.builtin.alias.bin leftover in your /lib/modules/5.15.0-41-generic/.

[Jeffrey Walton (noloader)]

> Are you invoking kernel-install to remove kernels? Or what action did you perform exactly?

Good question, Nick.

I am not using kernel-install. Instead, I use a command like:

   # For the case of 5.15.0-41-generic kernel
   $ sudo apt-get remove --purge '*5.15.0-41*'

In fact, I ran the command manually when I noticed the accumulation of old kernel parts in /lib/modules. Apt said there was nothing to do.

I knew about the 2016630 bug from Red Hat because I first experienced the issue on Fedora 35. Now I am seeing it on Ubuntu, too.

----------

Here is the actual script I am running. It looks at the current kernel, and makes a list of all kernels. It removes the current kernel from the list of all kernels, and then removes all the old kernels.

    # Get a list mostly removed kernels. The kernel and package have been
    # removed, but the configuration files and directory remains.
    old_kernels=($(dpkg -l | grep linux-image | grep '^rc' | tr -s " " | \
        cut -f 2 -d ' ' | sort | uniq))

    if [ "${#old_kernels[@]}" -ne 0 ]; then
        apt-get remove -y --purge "${old_kernels[@]}" 1>/dev/null
    fi

    # Get the current kernel
    current_kernel=$(uname -r)
    version_only=$(get_version ${current_kernel})

    echo "Current kernel:"
    echo " ${current_kernel} (${version_only})"

    # Get a list of installed kernels. The `grep -v` removes the
    # current kernel from the list, which should be the latest kernel.
    old_kernels=($(dpkg -l | grep linux-image | grep '^ii' | tr -s " " | \
        cut -f 2 -d ' ' | sort -V | uniq | grep -v "${current_kernel}"))

    temp_list=()
    for k in "${old_kernels[@]}"
    do
        # Skip the metapackage linux-image-generic
        if [[ "${k}" == linux-image-generic* ]]; then
            continue
        fi
        temp_list+=("${k}")
    done

    # Swap-in the new list
    old_kernels=("${temp_list[@]}")

    if [ "${#old_kernels[@]}" -eq 0 ]; then
        echo "No old kernels found"
        exit 0
    fi

    echo "Old kernels to remove:"
    for k in "${old_kernels[@]}"
    do
        version_only=$(get_version ${k})
        echo " ${k} (${version_only})"
    done

    for k in "${old_kernels[@]}"
    do
        version_only=$(get_version ${k})
        if ! apt-get remove -y --purge "*${version_only}*"; then
            echo "Failed to remove ${k}"
            some_error=1
        fi

    done

    apt-get install -y --reinstall linux-image-generic linux-headers-generic

Fedora is a lot easier to remove old kernels. On Fedora I use:

    old_kernels=($(dnf repoquery --installonly --latest-limit=-1 -q))
    if [ "${#old_kernels[@]}" -eq 0 ]; then
        echo "No old kernels found"
        exit 0
    fi

    if ! dnf -y remove "${old_kernels[@]}"; then
        echo "Failed to remove old kernels"
        exit 1
    fi

[Nick Rosbrook (enr0n)]

Okay, thanks for the additional info. So, you are correct that the red hat bug does currently apply to 22.04, because we do not have this upstream commit [1]. However, that bug pertains only to kernel-install, which is not called in your script. It is also not invoked by apt or the linux package's maintainer scripts AFAICT.

[1] https://github.com/systemd/systemd/commit/06006691b5c56b6123044179d934b3ed81c237ca

[Nick Rosbrook (enr0n)]

Also, I believe a simple workaround for this is to add a drop-in to /etc/kernel/install.d that fixes what is missing from /usr/lib/kernel/install.d/50-depmod.install. See [1] for more details.

[1] https://man7.org/linux/man-pages/man8/kernel-install.8.html

[Jeffrey Walton (noloader)]

Thanks Nick.

Would you happen to know which component the issue should be assigned to? (I picked Systemd because of the Red Hat bug).

And I should have provided this in the report. Sorry about that:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal

[Nick Rosbrook (enr0n)]

You could try opening a bug for the linux package (https://launchpad.net/ubuntu/+source/linux), but I'm not sure it is a bug exactly. Other tools like depmod may add files to /lib/modules/$version, which causes apt to not remove the /lib/modules/$version directory so that it does not accidentally delete data the user did want deleted.