Description of problem: Using Fedora 16, 17, and 18 beta, I cant install because Anaconda says: you have not created a bootloader stage1 target device sda8 must have one of the following disklabel types: gpt. but my disk type is not GPT, it is msdos: [root@localhost mustafa]# parted GNU Parted 3.1 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA OCZ-VERTEX3 (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 105MB 104MB primary ntfs boot 2 105MB 21.6GB 21.5GB primary ext4 3 21.6GB 120GB 98.5GB extended 5 21.6GB 32.3GB 10.7GB logical ext4 6 32.3GB 43.1GB 10.7GB logical ext4 7 43.1GB 53.8GB 10.7GB logical ext4 8 53.8GB 120GB 66.2GB logical ext4 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Try to install on msdos disk label 2. Create root partition and try to proceed 3. Actual results: Can't proceed installing. Expected results: Installs normally Additional info: It works if I put "noefi" boot option before starting the installer, so I think the problem is determining weather the disk label is msdos or GPT.
Where are you Peter? this bug is really annoying, any info? comment?
Hi, Ran into this today. The "noefi" works around it, but I'm not sure the standard user will know how to edit the grub command line etc. I haven't played with the new f19 anaconda though. Could've been fixed there. Thanks, Ankur
Still exist in F19 beta, where are you Peter?
I am also getting this on my Lenovo X1 installed with a corporate Win 7 image that I have shrunk using gparted to make room for Fedora.
Just ran into this bug trying to install F19 RC2 over my previous F17 LV. Windows, F17, and F18 were all installed without issue in BIOS mode (not EFI), with msdos partitioning. My UEFI BIOS boot menu shows two entries for the Fedora Live key: The first non-EFI entry is unbootable for some reason (blackscreen with cursor); the second UEFI entry boots, but won't install because anaconda's expecting GPT in EFI mode. I'll give the 'noefi' workaround a shot. Hope this doesn't become a common F19 bug (not listed on the common bugs page yet).
'noefi' grub append worked. Up and running.
+1 on fresh Fedora 19 install on BIOS + msdos label Anaconda from Fedora 19 netinst Complainted about bootloader stage1 target. Note: this is a BIOS system (no UEFI at all) on and msdos label disk. noefi as a workaround worked.
Confirming with F19-final on x86_64 machine with msdos disklabel. "noefi" works like charm (if you know about it). The "F19 bugs" has a chapter on it: https://fedoraproject.org/wiki/Common_F19_bugs#UEFI_install_to_ms-dos_.28.27MBR.27.29_labelled_disk_fails_with_unclear_errors yet it scares me with the need to reformat my harddisk (not keen to lose my 250+ GB of /home on a LVM partition???) Could you, please, at least document the "noefi" option in the doc mentioned above.
If you hit this problem and 'noefi' "fixed" it, then yes, your system *does* have a UEFI firmware, and you did a UEFI native boot of the installation medium. I'm fairly sure there is no other circumstance under which noefi would "fix" this "bug". (I'm currently trying to make the "you have not created a bootloader stage1 target device" error less obtuse, but it's surprisingly difficult. Working on bootloader handling in an operating system installer should be forbidden under the Geneva convention.)
*** This bug has been marked as a duplicate of bug 978430 ***
Note for anyone winding up here: the noefi 'workaround' for doing a BIOS native install after booting the installation medium in UEFI native mode doesn't work for F20. See https://bugzilla.redhat.com/show_bug.cgi?id=1047904 for the reason, and an updates.img that fixes it.
Also note that we have now been told by the kernel folks that 'noefi' is not meant for this purpose. From F21 onwards, 'noefi' will not cause a BIOS mode installation, it will cause a UEFI native installation - or, if the disk is MBR, a failed installation. This is by design. 'noefi' disables the kernel's support for UEFI runtime services, it is not an 'override the installation mode' switch. See https://bugzilla.redhat.com/show_bug.cgi?id=1047904#c12 for the details on this. If you want a UEFI native install you must do it to a GPT disk. If you want a BIOS native install, you must boot your installation medium in BIOS native mode. We're aware it can be a struggle to navigate this maze, but it's equally a struggle for the anaconda developers, and they really don't need any more unusual codepaths to support, so we have to try and draw some clear lines. It seems there are some systems being shipped with BIOS-native installs of Windows but firmwares that default to booting removable media in UEFI mode, and that's kind of dumb, but, well - it's a dumb decision on the part of the system vendor, not something we can help. I put some tips in https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ which may help you to actually perform a BIOS-native boot of the Fedora installation media. I'm going to try and find some time soon to work on a 'UEFI and you' Fedora wiki page or installation guide section or something, to try and provide a clear central reference point for all the things to be aware of wrt UEFI firmwares and Fedora installation, which will cover these issues and more.