Originally Posted by
MAFoElffen
I think the keyword there would be
With Grub2, If you get the Grub Menu, the MBR is good, has booted and has read the filesystem of /boot/grub/grub.cfg successfully... So reinstalling and configuring is not going to get this OP anywhere.
Yes, you are probably right. There is not usually need to reinstall grub to the mbr. But the fsck command run from Rescatux might move the hard disk position of grub2 needed files, and that could lead to "Grub2 not finding its own files" error. To solve this problem you need to run the Restore Grub to the MBR option from Rescatux.
But his problem (I forgot to mention this little detail ) is:
Code:
VFS: Cannot open root device "sda2" or unknown-block (0,0)
Please append a correct "root=" boot option: here are all the available partitions:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block (0,0)
Pid: 1 comm: swapper Not tainted 3.0.0.12-generic #20 Ubuntu
which usually means that either the grub.cfg is incorrect, which sometimes happens when you upgrade or that actually the system cannot mount the root fs.
If the system cannot mount the root fs I doubt that you can get to recovery screen but you might after all.
In the case that cannot mount the root fs you can fix that with the Rescatux fsck option I have mentioned. Might it be that the Ubuntu fsck option that you mentioned, the one that it is found on the recovery screen, has forced fix... but I am not quite sure about that. If it had the forced fix then you could use that instead of Rescatux fsck option.
If the problem is an incorrect grub then running the update-grub command is the way to go. From Rescatux is using the Update grub configuration option.
There could be a third possibility about drivers. I mean... Maybe the last system could mount read that hard disk ok but the current one (due to some faulty drivers) cannot read the same hard disk ok.
adrian15
Bookmarks