TL;DR this can be quickly fixed by rebooting. Then the CD-ROM will work and the Guest Additions will be installable:
The "best" sequence to update the kernel on VirtualBox with Additions is:
apt-get upgrade (or apt-get dist-upgrade)
(re)install VirtualBox Additions on the new kernel that is now running
(The next-to-latest old kernel might not be auto-removed for security reasons, to allow you to "go back").
How did this happen? (previous long answer)
Exactly this kind of problem will arise if you:
- upgrade the kernel (say from .66 to .67)
apt-get autoremove and somehow remove the running kernel, or manually remove the "old" kernel, thus removing all modules from /lib/modules/kernel.66
- do not reboot, thereby keeping the "old" .66 kernel running. The loaded modules remain in memory and everything works, but no new modules can be loaded since .66 modules have been deleted.
- try to do anything that requires loading a module that was not yet loaded
And installing the VirtualBox ISO may require exactly that -- loading the ISO9660 support module.
The requested module now can no longer be autoloaded, because the running kernel (.66) does not find anything in /lib/modules/kernel.66 . The module exists, but it is in /lib/modules/kernel.67, of which the current .66 kernel knows nothing about (and it's not recommended to load a mismatching module).
Reinstalling the uname'd kernel will of course reinstall the running kernel modules, thereby making ../.66/.../isofs.ko available again and making a reboot unnecessary. This is a downgrade of the installed kernel and the update issue will remain (see below).
That is, when you run Additions CD, it will install for the running .66 kernel, not the updated .67 kernel (which still isn't running).
If you are in such a situation you can also certainly fix it by rebooting (the new .67 running kernel will find its modules), and probably by loading the module belonging to the new kernel (
isofs is pretty stable), which unless you've underwent an important kernel upgrade will still be compatible (this is still not recommended!):
# mount /dev/cdrom /mnt
mount: unknown filesystem type 'iso9660'
This above is the root error you're getting ("unknown filesystem type").
# uname -a
Linux virtual 3.13.0-66-generic ...
So we check which version of the modules is installed. It should be .66:
# ls /lib/modules
...but there's only one directory and it's .67 (the .66 directory might be there, but empty; in this case
du -sh /lib/modules/* will tell how much space is taken by the various directories, allowing to tell between empty ones and full ones).
Reinstalling the old kernel image with no re-grub will not fix the real problem
You reinstall the .66 kernel with its modules and headers. Now you have both kernels, with
grub set to load the newer .67.
The ISO CD-ROM can be mounted (because the module is now present) and the VBox modules will compile (because the headers have been installed).
It will compile modules for the running .66 kernel, and they will work... for a while.
At the first reboot, you will find yourself with a .67 kernel with no VirtualBox additions at all.
Reinstalling the old kernel image with re-grub and re-boot will also not fix the real problem
As above, you reboot and find yourself with a downgraded kernel. Very soon, Ubuntu will try to upgrade it and you'll be back where you started (see below: "downgrading kernel").
Patching in the ISO module will also not fix the real problem
Chances are we can force load the ISO9660 module all the same, since no work was done between kernels 66 and 67 and the binary is essentially unchanged, so we try:
# insmod /lib/modules/3.13.0-67-generic/kernel/fs/isofs/isofs.ko
No errors. It worked. Kernel .66 loaded module from kernel .67. Let's try again to mount the CD-ROM:
# mount /dev/cdrom /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only
This still won't help, because the CD being installed is VirtualBox Additions, which requires the running kernel headers to be installed. If the running kernel modules are no longer there, chances are that neither will the kernel headers.
Also, the newly compiled Virtualbox modules won't have anywhere to go, since the .66 modules directory has been cleaned.
But say you fix all that: you've essentially done an expensive (and partial) kernel downgrade, and the additions will be lost at next upgrade together with the rest of .66 kernel, exactly as in the case above.
Downgrading the kernel will work... for a while
If we remove the .67 kernel and reinstall the .66 kernel with modules in its stead, things will be hunky dory for a while. No reboot necessary, as in the "force ISO module" solution above.
And a reboot will not lose anything, since no Additions-challenged kernel is installed.
But this way the kernel will still be in the "to be upgraded" list, and this same problem is bound to arise sooner or later.
Granted, you can now have it arise in some more appropriate moment of your choice, which might be worth quite a lot.
Rebooting, the more recent .67 kernel will be activated and all its modules and headers are there.
So, after the reboot, Guest Additions will work, and the upgrade will "take".