Linux guest additions update creates spurious initramfs copies

[JMHOGM]

With a Win7-X64 host and a CentOS7 guest, I've been seeing a problem for several months where everytime I tried to update the Guest Additions, more than a dozen old initramfs versions would get created, overflowing /boot. The Guest Additions update would only complete after I removed the earliest initramfs versions to make more room. Note that there are not old kernel versions on this system; only the 2 most recent kernels and a recovery are present.

After several attempts, I finally tracked this down to multiple old guest additions subdirectories under /opt. These were empty; apparently the old additions had been properly removed but the empty directories had been left around and this was confusing the guest additions update process. Removing these empty directories cured the problem.

[Michael Thayer]

Is this reproducible? Can you give reproduction instructions?

[Socratis]

I haven't seen this problem with initramfs (I haven't even looked), but what I have definitely seen is that when you update a VM with a newer GA version, the old directories at "/opt" are NOT removed as they should. Maybe this is a bug of its own, maybe not, but I thought that it was worth mentioning it...

Background discussion: ​https://forums.virtualbox.org/viewtopic.php?f=3&t=82053

For reference, from an older Mint installation. They're all empty, except the 5.1.16 one. And yes, I wasn't updating the VM for every VirtualBox version released:

socratis@VB-Mint ~ $ ls -al /opt
total 56
drwxr-xr-x 14 root root 4096 Mar  9 17:46 .
drwxr-xr-x 23 root root 4096 Nov 17  2014 ..
drwxr-xr-x  2 root root 4096 Nov 21  2014 VBoxGuestAdditions-4.3.18
drwxr-xr-x  2 root root 4096 Feb 13  2015 VBoxGuestAdditions-4.3.20
drwxr-xr-x  2 root root 4096 Mar 17  2015 VBoxGuestAdditions-4.3.22
drwxr-xr-x  2 root root 4096 Jul  3  2015 VBoxGuestAdditions-4.3.26
drwxr-xr-x  2 root root 4096 Aug 13  2015 VBoxGuestAdditions-4.3.28
drwxr-xr-x  2 root root 4096 Aug 14  2015 VBoxGuestAdditions-5.0.0
drwxr-xr-x  2 root root 4096 Dec 24  2015 VBoxGuestAdditions-5.0.10
drwxr-xr-x  2 root root 4096 Mar 28  2016 VBoxGuestAdditions-5.0.12
drwxr-xr-x  2 root root 4096 Sep 14 00:24 VBoxGuestAdditions-5.0.16
drwxr-xr-x  2 root root 4096 Sep 16  2015 VBoxGuestAdditions-5.0.2
drwxr-xr-x  2 root root 4096 Nov 23  2015 VBoxGuestAdditions-5.0.4
drwxr-xr-x  9 root root 4096 Mar  9 17:46 VBoxGuestAdditions-5.1.16
socratis@VB-Mint ~ $ 

[Michael Thayer]

Are these folders still created with recent Additions versions? A look in our code suggests that it was fixed in March last year, for at least 5.0.x and 5.1.x releases after that date.

[Frank Mehnert]

Right. For the moment please just do 'rmdir /opt/VBoxGuestAdditions*' and then check if /opt will pollute again.

[Socratis]

Replying to michael:

Are these folders still created with recent Additions versions?

Replying to frank:

just do 'rmdir /opt/VBoxGuestAdditions*' and then check if /opt will pollute again.

It's not that they're "created", it's that they're not removed. The "polluted again" part of course can't happen. You're not going to install the 5.1.x GAs and find yourself with 4.3.x or 5.0.x empty directories. The problem is that empty, old GAs directories are not deleted. Starting with GAs 5.1.12 already installed, I did the following tests ⁽¹⁾:

• Left all the old "/opt/VirtualBox-*" directories untouched, installed 5.1.14, 5.1.16 and 5.1.18 GAs sequentially, with a reboot in between. The directories of the running GAs were removed by the new GAs. So installing 5.1.14 over 5.1.12 removed the 5.1.12 directory, installing 5.1.16 removed 5.1.14 and installing 5.1.18 removed 5.1.16. I was still left with all the previous ones, see output at comment:2.
• Uninstalled 5.1.12 GAs (no GAs at all), deleted all "/opt/VirtualBox-*" directories. Installed 5.1.8, 5.1.12 and 5.1.18 GAs sequentially, with a reboot in between. The directories of the running GAs were removed correctly by the new GAs.

It seems there's an "rm -r /opt/VirtualBox-*" command missing in there somewhere ⁽²⁾. I do see some of the complexity in not removing by mistake the existing/running ones or the newly installed ones...

Replying to michael:

A look in our code suggests that it was fixed in March last year, for at least 5.0.x and 5.1.x releases after that date.

Given the state of my current /opt directory and that my latest empty directory is 5.0.16, I'd say you're pretty much spot on in your assessment. I definitely updated the GAs after that, just don't remember which ones, maybe there are a couple of revisions missing.

⁽¹⁾: once more, thanks for the snapshot feature ;)
⁽²⁾: truth of the matter, if you implement that "feature", I'm going to miss it its old behavior. It was an indirect "revision" history of my VM getting updated. But, on the other hand you already have done it since last March, according to michael...

[Frank Mehnert]

We intentially don't do any rm -r /opt/VBoxGuestAdditions* in our script. Not removing the top-level directory of the VBox Guest Additions when uninstalling them is a bug (there is one exception, see below) but we better don't try to fix this bug for old installations as such fixes usually cause more problems than they solve. Better save than sorry :-)

Of course /opt/VBoxGuestAdditions-X.Y.Z is not removed if it contains files which were not part of the original installation.

[Socratis]

Interesting comment by "GregB3" @ ​https://forums.virtualbox.org/viewtopic.php?f=3&t=82053&p=388612#p388611

I am on the 5.1.18 version of VirtualBox. The same thing happen 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.

[gfrear]

I can confirm the issue with /lib/modules/old-removed-kernels which create spurious initramfs still exists.