Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 891104 - Can't install (on msdos disk label, not GPT) without adding "noefi" to the boot command, it says "you have not created a bootloader stage1 target device"
Summary: Can't install (on msdos disk label, not GPT) without adding "noefi" to the bo...
Keywords:
Status: CLOSED DUPLICATE of bug 978430
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-01 18:02 UTC by Mustafa Muhammad
Modified: 2014-01-30 21:37 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-27 23:24:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mustafa Muhammad 2013-01-01 18:02:15 UTC
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.

Comment 1 Mustafa Muhammad 2013-03-10 19:02:35 UTC
Where are you Peter? this bug is really annoying, any info? comment?

Comment 2 Ankur Sinha (FranciscoD) 2013-04-02 23:37:35 UTC
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

Comment 3 Mustafa Muhammad 2013-06-12 10:46:19 UTC
Still exist in F19 beta, where are you Peter?

Comment 4 birger 2013-06-18 11:53:27 UTC
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.

Comment 5 Jason Farrell 2013-06-27 04:21:51 UTC
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).

Comment 6 Jason Farrell 2013-06-27 04:43:31 UTC
'noefi' grub append worked. Up and running.

Comment 7 Richard Chan 2013-07-04 07:56:59 UTC
+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.

Comment 8 Piotr Golonka 2013-07-19 14:01:25 UTC
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.

Comment 9 Adam Williamson 2014-01-27 07:08:27 UTC
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.)

Comment 10 Adam Williamson 2014-01-27 23:24:13 UTC

*** This bug has been marked as a duplicate of bug 978430 ***

Comment 11 Adam Williamson 2014-01-28 04:32:56 UTC
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.

Comment 12 Adam Williamson 2014-01-30 21:37:07 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.