Red Hat Bugzilla – Bug 1023159
anaconda fails to install to a single partition
Last modified: 2014-01-29 13:18:56 EST
Description of problem:
attempts to install fedora 20 alpha or beta tc5 on the first primary partition of the hard disk fail because anaconda is unable to find a suitable stage1 storage device.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.boot netinstall medium
2.select custom partitioning
3.select the first partition as the root of the file system (ext4)
anaconda provides a cryptic message and offers no way to go on unless you fix the mysterious error
anaconda installs the distribution on the primary partition
the first partition is 100gb in size, and is marked as bootable.
on the same system, fedora 17 x64 works just fine being installed on the other partitions (sda2,3,5,...)
so the message in the main screen is: "Error checking storage configuration."
in ctrl-alt-f3, we get things like:
- storage configuration failed: failed to find a suitable stage1 device
- you have not created a bootloader stage1 target device
- you have not created a bootable partition
And there"s no way i can get over this error. Same anaconda, was able just fine to install on 20 gb /dev/sda9 only, but on a system without UEFI.
UEFI requires a EFI System Partition containing the bootloader and UEFI application. This cannot be the same partition as the root partition. For a UEFI system you need a minimum of two partitions: a / partition formatted using a Linux filesystem (xfs, ext4, etc.) and a EFI System Partition mounted at /boot/efi.
Thank you David, this is good to know. However, it would have been nice to find this out from anaconda itself, instead of opening a ticket in bugzilla :)
on one hand, it seems the /boot/efi is not required if you do not boot in uefi mode.
on the other hand, i"ve resized partitions to create some more space and then created the following partitions:
/dev/sda1 -> 4GB , for this i've tried /boot and /boot//efi, with ext4 or EFI system partition type
/dev/sda7 and /dev/sda8 with plenty of space (> 80 GB), ext4, for /home and /
in all cases, anaconda failed with same errors as reported above
for this test i've used Beta RC4 x64 netinst, fedora 20.
another test i did: i've deleted the three target partitions, and clicked the link to have them automat6ically created for me.
the error was: "doAutoPartition failed: failed to find a suitable stage1 device"
I have used a custom single partition setup: / ext4 bootable to install to USB (8Gb) for Sugar-desktop in the past. swap is bad for USB life
cornel, did you still have trouble with the final F20 on this system? are you sure you did things right? you must create a partition of type "EFI boot partition", on a GPT-labelled disk, and mount it at /boot/efi , to make things work.
hi adam. last year, on November 7th, i've replied to bugzilla message. of course, replying to bugzilla is not good enough so the message never reached the intended recipient :)
So here it is, for real, this time:
"after _a lot_ of help from tflink, i"ve found that the first boot option was opticald drive in uefi mode. after getting rid of that and swithing to old style optical drive, anaconda is able to install to selected custom partitions. why this is not working for uefi mode, i can"t understand."
cornel: because you *have* to create an EFI system partition for a UEFI installation to boot successfully. You may find my recent blog post - https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ - helpful in explaining why. The "EFI system partition" is just UEFI's way of replacing the dumb design, in the old BIOS/MBR world, of there being some "magic space" at the start of a disk (before the first partition) where the bootloader lives. In the UEFI/GPT world, bootloaders live on a real partition just like anything else on the disk: an EFI system partition.
*** This bug has been marked as a duplicate of bug 960689 ***
Hi adam. although i do agree the anaconda error message should describe the real problem, the closing of this looks like an error to me since, as you can see from comment #5, there are more problems here, not just the error message. if, on the other hand, you know the oter problems were already fixed, we can live things as they are. thank you.
I suspect that's another known bug: https://bugzilla.redhat.com/show_bug.cgi?id=978430 .