Ask Your Question

Default Fedora 20 installation is not bootable

asked 2014-04-17 22:09:36 -0600

Bidski gravatar image

updated 2014-04-22 07:28:40 -0600

I recently downloaded Fedora 20 and created a Live USB which I then used to install Fedora 20 on to my hard drive.

Letting the Fedora installer choose how to partition the available free space on my hard drive (I only told it to use a standard partition rather than LVM) I am unable to boot into Fedora.

Upon restarting after the installation process I am present with a screen that says

error: no such device: <UUID>
grub rescue>

I have tried fruitlessly for many hours trying to boot into the Live USB, mount and chroot into the recently installed Fedora system on my hard drive and trying to re-install and re-configure grub2. All of this results in me still not being able to boot.

I also tried to boot manually from the grub rescue prompt. This was also met with failure as I was unable to load the boot image using the linux command and I was unable to load the linux module due to a "symbol not found: grub_net_poll_cards_idle" error.

I am running a 64-bit AMD processor with no EFI support (still running a BIOS). The hard drive that I am trying to install Fedora 20 on to also has a Windows 7 installation on it (at least I think it is still there .....)

Can anyone tell me why this is not working?

edit retag flag offensive close merge delete


Can you share the exact commands you are using to enter the chroot and reconfigure GRUB? if you need help, there are many answers to other questions with this information.

randomuser gravatar imagerandomuser ( 2014-04-19 15:27:11 -0600 )edit

If you have two hard drives installed, switch the order in which they boot from within BIOS.

fetalvivisection gravatar imagefetalvivisection ( 2014-04-20 13:11:52 -0600 )edit

If I understand correctly, grub thinks/assumes sda is the "first HDD in the boot sequence". But the point is, if you didn't change the boot order before and after installing Fedora why didn't it work before?

Anyway I am glad it's finally fixed.

Ahmad Samir gravatar imageAhmad Samir ( 2014-04-22 01:49:44 -0600 )edit

About marking as solved, either @fetalvivisection converts his comment to an answer and then you can mark it as the correct answer or you can convert your own (last comment above) to an answer and mark it the correct answer. (Please remove [solved] from the question header).

Ahmad Samir gravatar imageAhmad Samir ( 2014-04-22 06:21:52 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2014-04-17 22:36:50 -0600

updated 2014-04-18 23:39:11 -0600

It seems as though your /etc/fstab configuration file is attempting to mount your system partition by its UUID. Try booting into rescue mode, mounting your OS, and checking your /etc/fstab entries to see if you have your partitions referenced by UUID. If you do, you need to ensure that the UUID value(s) accurately match the real values. Run sudo blkid to see a list of your block devices and their Universally Unique Identifiers (once all your partitions are mounted, that is) and compare the output with the UUID value(s) in /etc/fstab. If they match as you expect, check the UUID values in the grub.conf file and ensure that they point to the disks you expect.


So I've been pondering your data here (thank you very much for providing it; the opportunity to troubleshoot a GRUB issue in the wild, so to speak, is appreciated) and it seems that the grub.cfg file is configured reasonably; it is attempting to locate your kernel files on /dev/sda3, referencing it properly by its UUID. Given the size of /dev/sda3 at 524 MB, I presume this is in fact the partition holding your /boot directory's contents. Given your description of your old motherboard and BIOS firmware, I wonder if you may have firmware capable only of accessing the first 1024 cylinders (528 MB) of a storage device. If this is the case for your system, then placing the /boot directory on a partition which begins 210 GB into the disk will prevent GRUB's MBR code from accessing its contents. Given your symptoms, this seems a likely candidate for the root cause of the problem to me.

What motherboard model and BIOS firmware revision are you using?

edit flag offensive delete link more


I assume that by "boot into rescue mode" you are referring to booting into the Live USB? I was also under the impression that /etc/fstab was not loaded until after an OS was selected from the grub boot menu? I do not get a grub boot menu.

I booted into the Live USB and mounted the system and then chrooted into it. /etc/fstab is indeed mounting by UUID and all UUIDs appear to check out. I also checked the UUIDs in grub.cfg and these also appear to be correct. To be certain I copied and pasted the relevant UUIDs from the output of blkid into both /etc/fstab and grub.cfg with no change in the result.

Bidski gravatar imageBidski ( 2014-04-17 23:27:24 -0600 )edit

From the live media, please post the output of:

parted -l

along with the contents of /boot/grub2/grub.cfg of the installation on the HDD.

Ahmad Samir gravatar imageAhmad Samir ( 2014-04-18 00:10:01 -0600 )edit

And /boot/grub2/grub.cfg? (For what it's worth, you could use a pastebin e.g. ; from the command line blkid | fpaste and for files fpaste /boot/grub2/grub.cfg).

Ahmad Samir gravatar imageAhmad Samir ( 2014-04-18 03:37:31 -0600 )edit

I'm inclined to think that the problem is going to be in the grub.cfg file after all. If you had made it to the point at which your system was attempting to mount file systems as specified in /etc/fstab, I would expect a failure to dump you into an initramfs shell, and not the GRUB rescue shell. Since you're experiencing the latter, I'm guessing GRUB is failing to locate your kernel because the grub.cfg file is referencing the disk on which the kernel is stored with an incorrect UUID value. So, as Ahmad writes, could you show the grub.cfg file contents?

bitwiseoperator gravatar imagebitwiseoperator ( 2014-04-18 09:22:24 -0600 )edit

answered 2014-04-22 00:04:23 -0600

Bidski gravatar image

updated 2014-04-22 17:53:13 -0600

Looks like this is resolved now. Switching the order of the HDD boot sequence in the BIOS fixed it. Thanks @fetalvivisection. I wonder why this never caused an issue before.

edit flag offensive delete link more

Question Tools


Asked: 2014-04-17 22:09:36 -0600

Seen: 1,589 times

Last updated: Apr 22 '14