Guest additions install overflowing /boot

[JMHOGM]

I'm running a CentOS7 VM on a Win7-X64 host. For the past 6 months or so I have had a problem which I've been unable to track down. As expected, every time a new (Linux) kernel is released or a new version of Virtual Box comes out, I update and then have to reinstall the Guest Addition. The problem is that when I do so (typically by clicking on the VBOXAdditions icon on the desktop and selecting "Open with Run Software"), I encounter the following symptoms:

a) the installation takes much longer than it used to, typically at the 1st "Removing previous versions" step
b) eventually, I always get a warnings / errors that /boot is almost full and that dracut failed creating some (typically ancient) initramfs version.
c) at this point, if I go in and examine /boot, there will be more than a dozen initramfs versions. If I manually delete the older ones, installation will eventually complete. Thereafter, things behave more or less normally until the next time I need to update the Guest Additions.

Can anyone give me any suggestions on how to prevent creation of so many initramfs versions? (BTW, I've already run package-cleanup --oldkernels).

As an example, here's a directory listing of /boot just prior to installing Guest Addition during a recent update (to 5.1.14):

Code: Select all

onfig-3.10.0-514.6.1.el7.x86_64
config-3.10.0-514.6.2.el7.x86_64
extlinux
grub
grub2
initramfs-0-rescue-21e205dad9984fa79693cf8c53635d89.img
initramfs-3.10.0-514.2.2.el7.x86_64.img
initramfs-3.10.0-514.6.1.el7.x86_64.img
initramfs-3.10.0-514.6.2.el7.x86_64.img
initrd-plymouth.img
symvers-3.10.0-514.6.1.el7.x86_64.gz
symvers-3.10.0-514.6.2.el7.x86_64.gz
System.map-3.10.0-514.6.1.el7.x86_64
System.map-3.10.0-514.6.2.el7.x86_64
vmlinuz-0-rescue-21e205dad9984fa79693cf8c53635d89
vmlinuz-3.10.0-514.6.1.el7.x86_64
vmlinuz-3.10.0-514.6.2.el7.x86_64

And here's what you get during the Guest Additions installation once you start getting warnings / errors:

Code: Select all

config-3.10.0-514.6.1.el7.x86_64
config-3.10.0-514.6.2.el7.x86_64
extlinux
grub
grub2
initramfs-0-rescue-21e205dad9984fa79693cf8c53635d89.img
initramfs-3.10.0-229.11.1.el7.x86_64.img
initramfs-3.10.0-229.1.2.el7.x86_64.img
initramfs-3.10.0-229.14.1.el7.x86_64.img
initramfs-3.10.0-229.20.1.el7.x86_64.img
initramfs-3.10.0-229.4.2.el7.x86_64.img
initramfs-3.10.0-229.7.2.el7.x86_64.img
initramfs-3.10.0-229.el7.x86_64.img
initramfs-3.10.0-327.10.1.el7.x86_64.img
initramfs-3.10.0-327.13.1.el7.x86_64.img
initramfs-3.10.0-327.18.2.el7.x86_64.img
initramfs-3.10.0-327.22.2.el7.x86_64.img
initramfs-3.10.0-514.2.2.el7.x86_64.img
initramfs-3.10.0-514.6.1.el7.x86_64.img
initramfs-3.10.0-514.6.2.el7.x86_64.img
initrd-plymouth.img
symvers-3.10.0-514.6.1.el7.x86_64.gz
symvers-3.10.0-514.6.2.el7.x86_64.gz
System.map-3.10.0-514.6.1.el7.x86_64
System.map-3.10.0-514.6.2.el7.x86_64
vmlinuz-0-rescue-21e205dad9984fa79693cf8c53635d89
vmlinuz-3.10.0-514.6.1.el7.x86_64
vmlinuz-3.10.0-514.6.2.el7.x86_64

Thanks for any advice or suggestions!

[socratis]

I'm not quite sure that this is a VirtualBox question. In fact it looks like a CentOS problem. Have you tried the CentOS forums? Just because an OS is running in VirtualBox, does not necessarily make it a VirtualBox problem.

[Perryg]

I always get a warnings / errors that /boot is almost full

Actually this more than likely is a results of the newer guest additions because of the want/need to get away from kernel issues. VBox will create an initramfs entry for every kernel that it sees but these usually go away after install and reboot. Normally this is not an issue unless your /boot is too small. I would check on how to increase the /boot space a bit. Are you using LVM or a separate /boot partition?

[socratis]

I've already run package-cleanup --oldkernels

VBox will create an initramfs entry for every kernel that it sees but these usually go away after install and reboot.

So, would it be correct to assume that the initramfs entries were created before the kernel cleanup? If so, it makes sense to simple wipe them out, no? Besides what Perryg said about the /boot size of course...

[JMHOGM]

Hi,

Thanks for the replies so far. Let me clarify a bit.

1) It's definitely a VirtualBox issue, not a CentOs problem. CentOS updates, boots, and works fine, and never create obsolete initramfs copies. The only operation that causes any problem is updating VBox guest additions.

2) I have wiped out the obsolete initramfs copies many times. Every time you try to install guest additions, it recreates them and the runs out of disk space.

3) The boot partition is standalone, 524 MB. That's plenty. There's no reason I can see for keeping around dozens of old ramfs images.

Here's a crude guess of what I think is going on. The Guest Additions wants to remove previous versions. For some reason, it seems to think there are lots of old guest addition corresponding to old kernel versions around, and to remove each, it seems to want the corresponding initramfs, so it runs dracut to create it. Eventually, it runs out space of course, until I start deleting the oldest initramfs copies first. This is just speculation on my part, but if it's correct, the question is why the Guest Additions update process thinks so many old versions are still around when they've already been removed?

Thanks again!

[JMHOGM]

Oh, and no, it would not be correct to assume the bad initramfs copies were created before kernel cleanup.
Kernel cleanup doesn't remove them, since there is no corresponding kernel installed. If you do a sequence:

package-cleanup --oldkernels
rm initramfs<x> where <x> is a pattern which will remove all but the 3 most recent versions
install guest additions

Then the guest addition process happily (at first) goes about recreating initramfs versions going back 15 or 20 revisions.

[JMHOGM]

Hah! I found / fixed the problem. Under /opt there were lots of old guest additions subdirectories. They were empty... apparently the update procedure had removed the contents but neglected to remove the directory. Deleting these cured the problem! Installing guest additions no longer creates bogus initramfs copies and now completes in seconds instead of taking 15 minutes.

Thanks again for your suggestions.

[socratis]

That sounds like a bug to me. Have you checked the bugtracker?

[JMHOGM]

I didn't see it in the bug tracker, so I went ahead and created a new ticket.

Thanks again!

[socratis]

Can you post the bug ticket as well so that future searchers will be able to find it?

EDIT: Never mind, I found it..
#16529: Linux guest additions update creates spurious initramfs copies

[GregB3]

I am on the 5.1.18 version of VirtualBox. The same thing happened to me with Fedora 25, and Korora 25, which is based on Fedora. It took one further step to eliminate the production of bogus initramfs in these installations. In /lib/modules there were a lot of sub-folders that had what looked like old configuration files for old, invalid kernels. Only the current kernels had full contents in the /lib/modules sub-folders. Once the old, invalid sub-folders in /lib/modules were deleted the guest additions installed OK and there were no bogus initramfs in /boot.

[socratis]

This seems to be a different reason for the additional "initramfs" being created then. In the first part of the discussion it was discovered (and further analyzed in ticket #16529) that it was the old, not-removed old GAs directories in "/opt/VirtualBox*/" that were causing this.

Now you say that old, invalid, kernel configuration data, caused additional copies to be created. Interesting... Maybe you should add this comment to the ticket to let the developers know about it?

[Martin]

On my Fedora 25 installation I see 39 directories for older kernels from Fedora 20-24 since 2014.
There size together is about 55 MB, each directory contain the files "modules.alias modules.builtin.bin modules.dep.bin modules.softdep modules.symbols.bin
modules.alias.bin modules.dep modules.devname modules.symbols"
The directories for the three currently installed fc25 kernels are 50-64 MB each.

[michael]

I wonder whether that is not Fedora doing something wrong leaving those files after removing the rest of the kernel files. Perhaps you can try investigating that (i.e. finding and asking someone knowledgeable at Fedora)? If it still looks like it is our fault then please let me know whatever details you find out.