UbuntuThis forum is for the discussion of Ubuntu Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
The error that caused the problem is listed somewhere before the part you posted, where the kernel tells you that it's missing the drive that contains your root file system. (The drive is usually identified by a UUID=.... line in /etc/fstab, so you may have some error there.)
Since you can boot from your second drive it should be fairly easy for you to mount the root partition of the first drive and correct the problem.
You could just try running grub-mkconfig on the second drive. That should give you a grub.cfg file that will let you start Ubuntu from either drive.
"[ 9.562270] init: failsafe main process (769) killed by TERM signal" is strange, but what generated the SIGTERM is not too clear from that extract. I notice, however, that this is from an attempted fail-safe boot. The first message file from which you posted the kernel panic message reported the panic after 1.33 seconds, while this last one lasted 9.6 seconds.
Look at the creation dates of the various dmesg.n.gz files to see if one of them might be a compressed, saved version of the messages generated
by the boot that crashed.
Is there some reason why you can't post the whole dmesg file?
Last edited by PTrenholme; 09-11-2012 at 06:13 PM.
OK if you're getting that far into the boot, I withdraw the remark about not finding the root drive. So, something is crashing init. I see a Nvidia module and vesafb, and I predict that one will end in tears, but otherwise you haven't shown us an error.
As you can get in to the system, try adding the word 'debug' to the kernel boot line (manually if you like) to get more explicit messages, and try this command
ldd /sbin/init |grep found
to which the output should be nothing - nada. If it mentions anything, it's missing.
The debug option suggested by business_kid, above, might be helpful.
To add that option, boot your working system and, from a terminal window issue the command sudo gedit /media/85.../boot/grub/grub.cfg. Then page down in the file (or search for) the first line that starts with " linux /boot/vmlinuz..." and add " debug" at the end of the line and save the file.
Then reboot and try to boot the failing installation. After it fails, you should have some information in /var/log/syslog.
When I tested this procedure, I could display the interesting part of that file using the command grep 'Sep 12 12:' /var/log/syslog (The 'Sep 12 12:' selects the lines generated today (Sep 12) between noon and 13:00, which is when I rebooted my virtual Ubuntu system. Your date and time will, of course, be different. Do a tail /media/85.../var/log/syslog to see what you need to put in the search part of the grep command.)
[ 9.125973] nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 9.125982] nvidia 0000:01:00.0: setting latency timer to 64
[ 9.125988] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=nonewns=io+mem
[ 9.126126] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 295.40 Thu Apr 5 21:37:00 PDT 2012 [ 9.562270] init: failsafe main process (769) killed by TERM signal
[ 9.596784] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
[ 9.596786] vesafb: scrolling: redraw
[ 9.596789] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 9.601601] vesafb: framebuffer at 0xe1000000, mapped to 0xffffc90009d80000, using 5120k, total 5120k
[ 9.602583] Console: switching to colour frame buffer device 160x64
[ 9.602609] fb0: VESA VGA frame buffer device
This seems to be it. It seems to be throwing out the Nvidia driver for some reason. Try a reinstall of that, as a first move. But there are/were issues with Nvidia drivers and newer kernels - and nvidia were not playing ball, last I heard. I'm using AMD/ATI myself.