Ubuntu 10.04 on virtualbox gives error: Target filesystem doesn't have /sbin/init \ No init found. Try passing init= bootarg

I'm a linux newbie and the only reason I have it installed is so I can stop having Windows incompatibility issues with Ruby on Rails. Having said that, it sure has been nice, and much faster, and I don't think I'll be doing any Winrails stuff anytime soon.

So I created a virtualmachine using virtualbox and have had ubuntu on it for the last 3 weeks. Recently ubuntu asked if it could update a few things, I clicked 'ok'.

Now it won't boot and I get this error: *mount: mounting /dev on /root/dev failed: No such file or directory mount: mounting /sys on /root/sys failed: No such file or directory ... Target filesystem doesn't have /sbin/init. No init found. Try passing init= bootarg

BusyBox v1.13.3...

(initramfs) _ *

So I cruised the forums and there are a variety of solutions, but they all have to do with booting from the live cd. (which I assume is the ISO image I used to install ubuntu in the first place). But when I boot from that CD, it just hangs on the ubuntu screen, and the little dots keep cycling white to red, but it hung there for an hour so I think it was stuck. Not sure what I can do; can I do anything from the busybox shell (or whatever that is) to fix things?

The thing is, it took about 10 hours to get everything the way I needed with all the gems and whatnot. And I didn't really write down what I tweaked, and I'm middle aged, so all that information has leaked out by now and I don't want to do it again. I'd really like to repair my existing install.

One question you might have is, is there something wrong with the ISO? I don't think so, because I made a new virtual machine and used that same iso file to install a fresh ubuntu.

Any help much appreciated.

Phil

From serverfault Philip

• Not the most elaborate, but maybe quickest approach: Add the disk image from your broken VM to the newly installed one, mount it from there, copy your $HOME, /etc and maybe something from /var/{lib,db, ...} (or at least keep a copy) and you should be back up to speed in less than an hour.

  I guess the actual problem is caused by the initial ramdisk not being able to properly discover and mount the virtual disk device. So what you could also try if you somehow manage to access the broken VM's filesystem is something along the lines of:

  mount /dev/sdbroken1 /mnt/brokendisk
  for i in dev dev/pts proc sys; do
    mount --bind /$i /mnt/brokendisk/$i
  done
  chroot /mnt/brokendisk
  update-initramfs -u -k all # regenerate initial ramdisk - look for errors
  ^D
  reboot
  

  From al

• Maybe there's something wrong with an updated kernel. Try booting the previous kernel (it should still be around). When you see the virtualbox boot screen on a blue background, press and hold Shift. After a few seconds, the bootloader menu should appear.

  • If there's an entry for a previous kernel version, try booting it.
  • Otherwise, try e​diting the normal entry. Move down to the linux line, erase the part that looks like -2.6.32-24-generic and press Tab to see what other kernels exist (/boot/vmlinuz-*). Also select a matching initrd below.
  • You could also try changing the root= setting on the linux line. With a default installation (with no other OS inside the VM), root=/dev/sda1 should work.

  If none of this works but you see interesting error messages along the way or need , post them here. Depending on what the problem is, it may help to see the output of the command ls /boot when typed at the Grub prompt.

  Philip : sigh. there were no entries for a previous kernel version. I tried to edit the entry; I tabbed at that point and it autocompleted the generic kernel. I don't think there are any more kernels.

  Philip : I tried also setting root=/dev/sda1 and that did not change anything.

  Philip : output of ls /boot is: grub/ System.map-2.6.32-24-generic abi-2.6.32-24-generic config-.6.32-24-generic memtest86+.bin vmcoreinfo-2.6.32-24-generic vmlinuz-2.6.32-24-generic initrd.img-2.6.32-24-generic but I typed all that in by hand there might one or two typos

  Gilles : @Philip: Ok, so 1. grub can read your root partition and 2. the contents of your boot directory look reasonable. What does `ls` with no argument show? When you `e`dit the normal entry, is there an `initrd` line, and what is the exact `root` line (ideally, show the whole contents)?

  Philip : output of 'ls' is: (hd0) (hd0,5) (hd0,1) and the initrd line you refer to is: initrd /boot/initrd.img-2.6.32-24-generic I'm wondering is it possible that these virtualboxes are being messed up when my windows 7 machine hibernates? surely they are not that fragile?

  Gilles : @Philip: everything looks normal on the bootloader front. So massive filesystem damage looks more and more likely. I don't see why host hibernation would trouble the VM in any way, but it looks like something did go wrong.

  Philip : @Gilles (and thanks so much for your time) the reason I'm asking is, I set up a new virtualbox, installed ubuntu 10.0.4 and all my rails stuff again on it, and was happily using it for a week...today it failed in exactly the same way. I wonder if it is related to a win7 shutting down suddenly or something.
  From Gilles

• Everything looks normal on the bootloader prompt. So I fear that the filesystem has been damaged.

  I suggest the following process:

  1. Create a new virtual machine, and make fresh Ubuntu installation.
  2. Install the etckeeper package, and run etckeeper init. This will put /etc under version control. If you have a favorite version control tool amongst Bazaar, Darcs, Git and Mercury, select it in /etc/etckeeper/etckeeper.conf before running etckeeper commit.
  3. Your changes under /etc will be automatically committed before and after package management tasks, and once per day. You can commit manually by running etckeeper commit or invoking the underlying version control tool directly.
  4. Now is the time to try to save the old VM. Shut down the new VM, then add the disk of the old VM to the new VM and boot the new VM.
  5. Try mounting /dev/sdb2. If you're prompted to run fsck, do so.
  6. Recover what you can from the old VM.
  7. Remember to include the repository for /etc, as well as anything you might do in /usr/local and /home in the VM, in your backup setup.
  From Gilles

• I have exactly the same problem; including the odd behavior with the live iso as well.

  It turns out the problem is with grub being f***ed up somehow - possibly by the host system going to sleep [i say that because Christis Bergeles describes the same problem as me with the same host (mac osx) at http://christos.bergeles.net/blog/files/tag-grub.html]

  Attach your problem virtual HD to another working ubuntu VM.

  Boot into that VM

  (the next two lines assume this VM has your problem disk at /dev/sdb)

  sudo mount /dev/sdb1 /mnt

  sudo grub-install --root-directory=/mnt/ /dev/sda

  worked for me - on two separate instances of this problem.

  Tim.

  From Tim Phillips