Ubuntu fails to start after system update (displays BusyBox notice on command line)

Question

I am running Ubuntu 10.x on one of my boxes. Yesterday the SPM popped up during a session, with the choice to install the latest updates. I agreed (like I have done many times before). This time, during the installation, the system crashed, the SPM reported that a Python exception had occured during the installation (unfortunately, I don't remember on which stage of the installation the exception occured).

I rebooted the system, since I could not get rid of the SPM dialog box which was displayed greyed out and was unresponsive.

When I attempted to login again (after the reboot), I was met with a console screen with the following message (after a stack trace):

killed mount: mounting /dev on /root/dev failed: No such file or directory mount: mounting /sys on /root/sys failed: No such file or directory mount: mounting /proc on /root/proc failed: No such file or directory Target filesystem dosen't have /sbin/init No init found. Try passing init= bootarg.

BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash) Enter 'help' for a list of built-in commands

(initramfs)

I have the following questions:

1. What is the meaning of this messade?
2. Why have the mounts failed?
3. (most important) what are the steps required to I recover from this disaster?

Update

I followed Giles advice. I setup my my PC to bootup from the USB disk if all else fails. This time, I get the following message (shortened here, as I am typing it out)

 scsi 2:0:0:1: CD-ROM SanDisk U3 Cruzer Micro 8.0.2 PQ: 0 ANSI: 0 
 sd 2:0:0:0:0 Attached scsi generic sg3 type 0 
 sd 2:0:0:0:0 [sdc] 31301631 512-byte logical blocks 
 sd 2:0:0:0:0 [sdc]  Write Protect is off 
 sd 2:0:0:0:0 [sdc] Mode Sense: 45 00 00 08 
 sd 2:0:0:0:0 [sdc] Assuming drive cache: write through 
 sr1: scsi3-mmc drive: 48x48x tray sr 2:0:0:1: Attached scsi CD-ROM 
 sr1 sr 2:0:0:1: Attached scsi generic sg4 type 5 
 sd 2:0:0:0:0 [sdc] Assuming drive cache: write through
 sdc: sdc1 sd 2:0:0:0:0 [sdc] Assuming drive cache: write through 
 sd 2:0:0:0:0 [sdc] Assuming SCSI removable disk

I then hit the Enter key:

(initramfs)

At this stage, I am not sure if my USB stick is bootable or not (dosen't look like it is). I am thinking of installing a barand new OS on the stick, and starting from there - BUT, I don't know what the consequences of that will be (will I lose my existing data on my machine?).

Help!

Solution

You seem to have a damaged filesystem. When you rebooted, the root filesystem (i.e. the system partition) could not be mounted. The messages you list here are consequences of the root filesystem not being mounted and are not part of the problem. The damaged filesystem is probably either the cause of the SPM crash, or a consequence of the same root problem.

There are two reasons why the filesystem might be damaged: it could be a hardware problem (most commonly a failing disk or failing RAM), or it could be a software bug.

Before you decide on a recovery option, you need to investigate a little more. (Is it repairable? How much data have you lost? Does a hardware component need to be changed? Should you report a bug? So far there isn't enough data to answer these important questions.)

First, at the boot prompt, select “Memory test”. Let it run for a couple of cycles (this can take a few hours). If it finds problems, change your RAM, then start thinking about recovery (or move the disk to another machine if you need the data now).

The next step is to boot from a live Ubuntu CD/USB and try mounting the filesystem there. If you can mount it, look at the last entries in /var/log/kern.log (if you see suspicious entries, go back to where the problems start, sometimes there will be pages of pages of errors, while at other times the error prevented any log message from being written). If you can't even mount the filesystem, reach for your backups (recovering individual files is often possible but arduous).

From the live CD, also check your disk's health with smartctl -a /dev/sda (if you have more than one disk, including USB drives, the disk may be /dev/sdb, /dev/sdc, etc.). Disk failures are usually either abrupt (the drive just stop responding) or not that dramatic (the first damaged sectors are in the 99.99% of space not used by critical files), but you might have been unlucky (e.g. a damaged sector in the filesystem journal).

Comments

[Anuj]

@Giles: thanks foir your detailed response. regarding your statement: "at the boot prompt, select “Memory test”". I do not have a menu to select from. I tried typing "memory test" (different capitalizations) at the command line, each time I got the response "/bin/sh: memory: not found". I tried then, to install from my USB disk. I changed my CMOS settings so that the machine boots from the USB disk - however, when I do that the machine appears to simply hang when attempting to bootup (console remains black with no output). I'm at a total loss now. I am shocked all this is from a system update!

[Anuj]

@Giles: BTW, I don't think my HD is shot yet, because I enabled the POST and the disks are reported as 'OK' ...

[Gilles 'SO- stop being evil']

@Takashi: Sorry, I forgot that Ubuntu hides the boot prompt by default. When your computer boots, press the Shift key after the keyboard is initialized, and hold it until you see the Grub menu. At that menu, select “Memory test”. The system update (very very probably) didn't cause the problems, it just revealed them. BTW, BIOS disk and memory POST tests don't say anything more than “yup, there's a disk/memory there.”

[Anuj]

@Giles: thanks for the tip. I HAVE been able to run the test now (well, its still running). If the tests pass, I am tempted to try to select the start Ubuntu in recovery mode to see what happens - is that a good idea?

[Anuj]

@Giles: thanks very much. I managed to fix the problem. I couldn't tell you exactly what I did (I tried so many different things), but basically, you set me on the correct path by making me aware of the GRUB menu. Many thanks once again!