Installing a new system using a GPT partitioned disk dedicated to a single partition, ext4 formatted, extlinux (version 4.05) as bootloader, Ubuntu Core version 13.10 amd64 as rootfs, and Ubuntu linux-image-3.11.0-18-generic as kernel, and extlinux-update to generate bootloader configuration.

The result after reboot (still inside a KVM based virtual machine) is an (initramfs) prompt and these messages:

mount: can't read '/etc/fstab': No such file or directory
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
The filesystem doesn't have requested /sbin/init.
No init found. Try passing init= bootarg.

BusyBox is v1.20.2.


  • the file system has been checked with fsck.ext4

Check for root existence

(initramfs) ls -l /dev/[hs]da*
ls: /dev/[hs]da*: No such file or directory

Root boot argument

(initramfs) cat /proc/cmdline
initrd=/boot/initrd.img-3.11.0-18-generic ro quiet BOOT_IMAGE=/boot/vmlinuz-3.11.0-18-generic

Check loaded modules

(initramfs) cat /proc/modules
e1000 145368 0 - Live 0xffffffffa0000000

/boot folder content

$ sudo ls -l boot
-rw------- 1 root root 3296162 Feb 18 22:37 System.map-3.11.0-18-generic
-rw-r--r-- 1 root root 1007681 Feb 18 22:37 abi-3.11.0-18-generic
-rw-r--r-- 1 root root  163258 Feb 18 22:37 config-3.11.0-18-generic
drwxr-xr-x 2 root root    4096 Mar 17 20:13 extlinux
-rw-r--r-- 1 root root 4995000 Mar 16 23:35 initrd.img-3.11.0-18-generic
-rw------- 1 root root 5634192 Feb 18 22:37 vmlinuz-3.11.0-18-generic

How to make this system boot to the expected default bash prompt?

  • Why two init images? Can you please put this on an actual disk and try to boot it? Qemu and EFI have issues - for instance, if you do not use an EFI boot firmware image, you won't get very far at all.
    – mikeserv
    Commented Mar 22, 2014 at 5:41
  • And if all you want is a bash prompt you could always include bash in your initramfs...
    – mikeserv
    Commented Mar 22, 2014 at 5:42
  • In fact, I'm remembering looking at LARGE GPT partitions in Ubuntu and them registering as completely empty. After I held shift at reboot to get grub's selection for their live disk I was able to select the Efi option, after which I had a disk.
    – mikeserv
    Commented Mar 22, 2014 at 5:56

3 Answers 3


Modify your kernel boot parameter by setting the root=/dev/sdaX option. sdaX would be your / or root partition. Upon booting the next time, you will see that your initramfs tries to mount the partition before trying to access /etc/fstab and mounting the file systems.

See question "Does initramfs use /etc/fstab?" for more details.

  • Adding root=/dev/sdaX improves the situation, there is no longer an (initramfs) but a bash login prompt instead.
    – Pro Backup
    Commented Mar 22, 2014 at 9:28
  • 1
    Beside manually adding root=/dev/sdaX to kernel boot, I need to update /mnt/etc/default/extlinux and change EXTLINUX_ROOT="" to the suggested EXTLINUX_ROOT="/dev/sdaX" and run extlinux-update again.
    – Pro Backup
    Commented Mar 22, 2014 at 10:17
  • If your installation uses dm-crypt, you might need to use the mapper such as root=/dev/mapper/sdaX_crypt. Note that sdaX_crypt might be different if you renamed it when setting up the crypt. At the initramfs prompt (after a failed boot), you can use ls /dev and tab completion to inspect the folder structure.
    – chris
    Commented May 5, 2020 at 5:01

What you need to understand about initramfs is that it is a filesystem. Since kernel 2.6 it is, basically, the only kernel-imposed filesystem ( leaving aside VFS, which is arguably also a filesystem ) on your machine. Your initramfs image is a disk image.

Within your initramfs image will be whatever files your distribution decided were crucial enough to require before your root disk is found. Usually that's Busybox and whatever kernel modules you need to find and mount your root device. This is isn't working for you.

There's no real mystery here though, all things considered. If you can find your way around a terminal prompt you can navigate the initramfs. But first you've gotta demystify it.

First and foremost and once again - this is just /. It's Linux root doing Linux root type things. In fact, if it is in a separate file from your kernel, it's actually already your second root device. Every Linux kernel contains a basically empty / all its own which it first mounts before pulling in your initramfs.

What's more initramfs is the real root. It is where the Linux kernel initializes userspace by execing init and subsequently renouncing all responsibility for any problem you might encounter thereafter. Your init seems to be Busybox, as are many, which means controlling its actions should be as simple as editing its accompanying shell scripts.

Then why the error about not finding init? Almost definitely this is referring to a program named init which your actual init has been instructed via shell script to exec itself into.

Most striking to me is that the kernel pseudo file systems - dev sys proc - do not mount. This is either very troubling or a very good clue. You mention KVM which leads me to question kernel capabilities, but before we go down that dark and rutted road, can we first try something else?

cd /root || mkdir /root

It strikes me that the error message is repeatedly:

No such file or directory

Failing that you need to rebuild your initramfs image. Boot to a live disc to do so and run whatever tool your distribution provides to accomplish that end. Oh, and please ensure that this live disk is loaded in EFI mode.

So here's the only truly out-of-the-ordinary thing about initramfs - switchroot.

The Linux kernel provides a very special syscall intended for early userspace and handling the move from initramfs to your root disk device. It works by first mounting your root disk into a mountpoint in initramfs and then pivoting the root filesystem into it. I assume your initramfs's target mount point is root based on the way it keeps moaning about it. Why not make sure it's there?

For further investigation you're going to need to get a little gritty. Adjust your bootloader to pass ...


... as a kernel parameter.

  • ...target mount point is root... Why not make sure it's there? I haven't got to foggiest idea how to verify this.
    – Pro Backup
    Commented Mar 22, 2014 at 9:18
  • You dont need to anymore. Youve got bash which means youre past initramfs. But are you still in kvm?
    – mikeserv
    Commented Mar 22, 2014 at 17:53
  • Yes, I am still in kvm.
    – Pro Backup
    Commented Mar 22, 2014 at 20:41
  • @ProBackup If you made it there you need to give the other guy your bounty - thats what you stated was your goal, anyway. Nevermind - youve apparently already done so. Im curious to know why you need to specify two init images - why initrd and boot? What is that? I should also like to know what, if anything, you can get out of running efibootmgr at your prompt in your virtual machine.
    – mikeserv
    Commented Mar 22, 2014 at 21:35
  • I have made a new SE question for the why: unix.stackexchange.com/questions/120999/… Note: I do think that this KVM (Parallels Desktop v8) only has a BIOS (not UEFI) due to the BIOS boot message.
    – Pro Backup
    Commented Mar 23, 2014 at 10:04

I had the same problem. What Alex said is correct. First I adjusted my fstab but that didn't help. So, I checked my GRUB. If you have the possibility to access GRUB menu.

  • Select the Linux, what you want to start and which makes trouble.
  • Press 'e' and look for 'boot_image' or 'boot...root'.
  • Check the 'uuid'.
  • In my case, it was wrong. I make a picture in initramfs by typing 'blkid' and take the uuid on which partition my linux is installed.
  • Paste the correct uuid from blkid to grub -> boot_image.

That solved my problem. After reboot my Linux needed longer time to start to check the disk. But now it works again.

I hope I could help you.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .