I need to completely rebuild my boot partition. The file system has sda1 250mb for boot and sda2 lvm luks encrypted with ManjaroVG-ManjaroHome, ManjaroVG-ManjaroRoot and ManjaroVG-ManjaroSwap inside of it. I have the live usb I installed from originally if that helps. Currently the kernel panics when trying to boot returning Kernel panic - not syncing: VFS : Unable to mount root fs on unkown-block(0,0). I can however chroot into it using the live usb.
- 4,732
- 10
- 33
- 41
- 2,227
- 6
- 20
- 25
-
[stop using `grub`](http://unix.stackexchange.com/a/146803/52934). rebuild initramfs. – mikeserv Dec 19 '15 at 05:35
2 Answers
This is probably caused by a recent kernel update. Try getting into the boot menu and see if you can choose a different, older version of your kernel. Boot up with that one and it should be working ok afterwards.
Please have a look over this thread: http://ubuntuforums.org/showthread.php?t=1751574&p=10780594#post10780594
If this doesn't work, you should use a LiveCD distro like SystemRescueCD, run an analysis in testdisk and see what the problem is.
- 16
- 3
-
I should have clarified the update killed my system to [this state](http://unix.stackexchange.com/questions/250243/how-do-i-fix-manjaro-error-hibernation-device-not-found-on-boot). I then used [Restore_the_GRUB_Bootloader](https://wiki.manjaro.org/index.php/Restore_the_GRUB_Bootloader) to get to this point the old kernels do not work. – user Dec 18 '15 at 22:45
I don't know if this applies to you but I had the same issue twice last week and solved (or worked around) it.
Beside Manjaro, I have installed Linux Mint 17.2 (based on Ubuntu 14.04 LTS), and Kubuntu 15.10.
In my case, I found out that actually, Mint did the damage when upgrading the kernel, because Arch boot line is more elaborate than what its ubuntu os-prober expects.
I restored the bootloader by following these instructions on Manjaro's wiki and it worked perfectly.
Another issue I had after installing another Linux was that the swap partition had been reformated. Then, my manjaro's etc/fstab refering to it
by its UUID, which had been altered, the system couldn't boot anymore.
-
oops I had overlooked your comment mentionning _`Restore_the_GRUB_Bootloader`_ and the hibernation state. But I still think it is worth checking first your last used grub.cfg and the partitions UUIDs – RockyRoad Dec 20 '15 at 13:41
-
About hibernation [this discussion](http://www.linuxquestions.org/questions/linux-general-1/how-grub-knows-there-is-a-system-in-suspend-hibernate-state-742782/) is very informative I think. – RockyRoad Dec 20 '15 at 14:09