Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
Mounting and re-installing grub worked like a charm. Thanks for your post. p. –  user77185 Apr 5 '11 at 8:19
1  
@Peter, you should accept one of the answers and upvote it if it helped you. –  Daniel Lawson Apr 5 '11 at 8:29
add comment

5 Answers

I had something similar - Ubuntu 10.10 host with Ubuntu 10.10 guest.

The guest FS got corrupt and resulted in the same error as above.

This was solved by mounting the partitions from the vdi file, and running a file check on these.

sudo vdfuse -g -f /media/ssdext4/UbuntuGuest.vdi /mnt/

You should now be able to list the partitions from the vdi file with "sudo ls -l /mnt/"

Now run the FS check - with the full path. sudo fsck.ext4 /mnt/Partition1

I think vdfuse should be part of the default install. I can't see how to fix these problems unless you have vdfuse.

share|improve this answer
add comment

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.
share|improve this answer
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
    
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 Sep 16 '10 at 19:45
    
I tried also setting root=/dev/sda1 and that did not change anything. –  Philip Sep 16 '10 at 19:45
    
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 –  Philip Sep 16 '10 at 19:48
    
@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 edit the normal entry, is there an initrd line, and what is the exact root line (ideally, show the whole contents)? –  Gilles Sep 16 '10 at 23:43
    
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? –  Philip Sep 16 '10 at 23:49
show 2 more comments

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.