Well, IMHO the question is why is it active in your case ...
cloud-initramfs-copymods has a rather clear, cut use case:
- If booted with an external kernel/initrd make the modules from initrd
available in /lib/modules/
- If not, do nothing
That is why "usually" (tm) one has the package installed and it does nothing.
The links that were added all revolve around removing cloud-initramfs-copymods,
but IMHO as stated above why was it active when it should not?
Because if booting a "normal" local kernel/initrd it should do nothing.
A random booted server image I had has it installed and no tmpfs mount in
/lib/modules just as I'd expect. If I might ask let us try to understand why it
is active for Ernst and maybe out of that we find a condition it missed to
check to work only in the right cases.
Usually it works like:
0. detect kernel myver=$(uname -r)
0. $rootmnt is usually empty, but if not it would also change where it acts on
which isn't the case here
1. if $rootmnt/lib/modules/$myver exists do nothing
1b: only if there is a kernel commandline option copymods=force set it acts
without the above
Hence Lucas asked for the content of /proc/cmdline in that other case -
@Ernst do you have something set in there?
I wondered how this could happen ..
If one would by accident remove the kernel modules manually and then reboot it
would act.
From that moment on any later (re)install of the kernel mods will be in that
tmpfs directory, so after a reboot you'd be back to the start.
$ uname -a
Linux j 5.15.0-17-generic #17-Ubuntu SMP Thu Jan 13 16:27:23 UTC 2022 x86_64
x86_64 x86_64 GNU/Linux
$ mount | grep /lib/modules
$ sudo rm -rf /lib/modules/*
$ sudo reboot
...
$ mount | grep /lib/modules
copymods on /usr/lib/modules type tmpfs (rw,relatime,inode64)
So this caused the problem, but only due to mis-administrating the system.
And since the initrd does not contain ALL modules that could be in /lib/modules
the bug report that "some are missing" as we only get the subset of the initrd.
In this case we are actually happy that we have some modules thanks to
cloud-initramfs-copymods :-)
@Ernst:
If you have NOT set by accident or any external source the kernel commandline
copymods=force, was there by any chance such an accidential deletion of
/lib/modules ?
P.S. If that was what might have happened, the way to resolve is not to "just
reinstall the mods" but to remove the tmpfs before that. That isn't easy with
the modules open from there.
Most likely you are e.g. disconnecting your network or disk when trying to
unload all modules.
Instead use a bind-mount to trick it into the original place "behind" that
tmpfs.
# First get all modules (not just the initrd content) into the tmpfs
$ sudo apt install --reinstall linux-modules-5.15.0-17-generic
$ sudo mkdir /mnt/helper
$ sudo mount --bind /usr/lib/ /mnt/helper
# now /mnt/helper/modules/ is the real /usr/lib/modules/ on disk, so copy the
tmpfs there
$ sudo cp -a /usr/lib/modules/5.15.0-17-generic /mnt/helper/modules/
$ sudo reboot
...
$ mount | grep /lib/modules
#empty now and we have all the extended modules available
You might need to adapt that to your kernel version, but otherwise - if
you got into this by the mistake that came to my mind - it should
resolve your issue.
P.S. I see no way to differentiate in cloud-initramfs-copymods between
"having no /lib/modules/$ver" and a deletion by an admin. If there is
one we could add it to the code to avoid this.
** Changed in: cloud-initramfs-tools (Ubuntu)
Status: Triaged => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1958260
Title:
cloud-initramfs-copymods hides the full list of modules from the
system
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-initramfs-tools/+bug/1958260/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
