![]() ![]() So the CD-ROM may be mounted, but the installer will fail upon launch.Īlso, even if it somehow found the headers and the compilation did not fail, the newly compiled Virtualbox modules won't have anywhere to go, since the. If the running kernel modules are no longer there, chances are that neither will the kernel headers. Yes, but this still won't be any real help, because the CD being installed is VirtualBox Additions, which requires the running kernel headers to be installed. Mount: block device /dev/sr0 is write-protected, mounting read-only Let's try again to mount the CD-ROM: # mount /dev/cdrom /mnt Patching in the ISO module will also not fix the real problemĬhances 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 and you'll be back where you started (see below: "downgrading kernel"), and need to reboot and install Virtualbox Additions again. Very soon, Ubuntu will try to upgrade it. Reinstalling the kernel will also not fix the real problem apt-get install -reinstall linux-image-$(uname -r)Īs above, at the first reboot you will find yourself with a downgraded (or better "not upgraded") kernel. ![]() 67 kernel with no VirtualBox additions at all. for a while.Īt the first reboot, you will find yourself with a. 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). Now you have both kernels, with grub set to load the newer kernel. You reinstall the running kernel with its modules and headers. Reinstalling the old kernel image with no re-grub will not fix the real problem 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). but there's only one directory and it's. So we check which version of the modules is installed. This above is the root error you're getting ("unknown filesystem type"). 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 If you are in such a situation you can also certainly fix it by rebooting (the new. That is, when you run Additions CD, it will install for the running. ![]() This is a downgrade of the installed kernel and the update issue will remain (see below). 66/./isofs.ko available again and making a reboot unnecessary. Reinstalling the uname'd kernel will of course reinstall the running kernel modules, thereby making. 66 kernel knows nothing about (and it's not recommended to load a mismatching module). The module exists, but it is in /lib/modules/kernel.67, of which the current. The requested module now can no longer be autoloaded, because the running kernel (.66) does not find anything in /lib/modules/kernel.66.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |