Not tested myself, but this is a known bug we must track for Beta. It's been reported, and bcl and pjones have confirmed, that EFI install fails on F16 Beta on most hardware, leaving you at a blank screen with a cursor. pjones has a patch for this which we will need to test.
Created attachment 525213 [details] Proposed patch It appears that on many machines, the GOP driver is not connected to PCI_IO. The fix to make some macs work better didn't take this into account, so it broke those machines. This patch falls back to the older behavior which worked on those machines.
proposing as Beta blocker per criterion "The installer must boot and run on systems using EFI other than Apple Macs".
grub-0.97-78.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/grub-0.97-78.fc16
+1 blocker since this is a pretty obvious violation of the release criteria
I'm having trouble trying to test this, sort of. Using my desktop, which has an SSD and an HDD. The HDD is 500GB, with a 300GB ext4 partition on the front, the rest can be used for test installs. Tried to test this by installing to the HDD. Procedure: write tflink's boot.iso to CD delete all the partitions after the 300GB on on the HDD, leaving 200GB of free space boot from the CD via UEFI select 'use free space', uncheck 'use LVM' and check 'review and modify layout' select the HDD as the only target disk, and check the radio button to make it the bootloader target proceed with install. at repo step, add a side repo with grub 0.97-78, and select 'minimal' package set 'ok' the 'grub conflicts with grub2' error after install complete, reboot the reboot leaves me at a blinking white cursor. If I boot back to my workaday F16 BIOS install on the SSD and mount the partitions from the HDD, I can see that /media/dc240b7f-09eb-4165-b77d-1fad6cbf5ce4/efi/ is empty and /media/dc240b7f-09eb-4165-b77d-1fad6cbf5ce4/grub contains only a splash.xpm.gz file. /media/dc240b7f-09eb-4165-b77d-1fad6cbf5ce4/grub2 contains an empty grub.cfg . Looking at the anaconda logs, I think it simply decided to skip bootloader installation between the 'parttype' and 'cleardiskssel' steps, for no reason I can figure out: 16:46:34,001 INFO anaconda: dispatch: moving (1) to step parttype 16:46:39,155 INFO anaconda: no initiator set 16:46:41,629 DEBUG anaconda: dispatch: Can not reschedule step 'bootloader' from 'skipped' to 'requested' 16:46:41,629 INFO anaconda: dispatch: leaving (1) step parttype 16:46:41,629 INFO anaconda: dispatch: moving (1) to step cleardiskssel In the 'instbootloader' step of anaconda.program.log (matched to the timestamps in anaconda.log), I can see only: 16:54:42,919 INFO program: Running... efibootmgr -v 16:54:42,955 INFO program: BootCurrent: 0004 16:54:42,956 INFO program: Timeout: 1 seconds 16:54:42,956 INFO program: BootOrder: 0002,0000,0001,0003,0004 16:54:42,956 INFO program: Boot0000* CD/DVD Drive BIOS(3,0,00) 16:54:42,956 INFO program: Boot0001* Hard Drive BIOS(2,0,00) 16:54:42,956 INFO program: Boot0002* Fedora HD(2,249f0800,80c800,ab1c4b6f-6d62-4c81-8164-5321374423fd)File(\EFI\redhat\grub.efi) 16:54:42,956 INFO program: Boot0003* UEFI: MultipleCard Reader 1.00 ACPI(a0341d0,0)PCI(1a,0)USB(1,0)USB(4,0)HD(1,89,3a9f77,00000000) 16:54:42,957 INFO program: Boot0004* UEFI: P1: TSSTcorp CDDVDW SH-222AB ACPI(a0341d0,0)PCI(1f,2)03120a000000ffff0000CD-ROM(1,10883,670) 16:54:44,187 INFO program: Running... efibootmgr 16:54:44,215 INFO program: BootCurrent: 0004 16:54:44,215 INFO program: Timeout: 1 seconds 16:54:44,215 INFO program: BootOrder: 0002,0000,0001,0003,0004 16:54:44,215 INFO program: Boot0000* CD/DVD Drive 16:54:44,215 INFO program: Boot0001* Hard Drive 16:54:44,215 INFO program: Boot0002* Fedora 16:54:44,215 INFO program: Boot0003* UEFI: MultipleCard Reader 1.00 16:54:44,215 INFO program: Boot0004* UEFI: P1: TSSTcorp CDDVDW SH-222AB 16:54:44,215 INFO program: Running... efibootmgr -b 0002 -B 16:54:44,253 INFO program: BootCurrent: 0004 16:54:44,253 INFO program: Timeout: 1 seconds 16:54:44,254 INFO program: BootOrder: 0000,0001,0003,0004 16:54:44,254 INFO program: Boot0000* CD/DVD Drive 16:54:44,254 INFO program: Boot0001* Hard Drive 16:54:44,254 INFO program: Boot0003* UEFI: MultipleCard Reader 1.00 16:54:44,254 INFO program: Boot0004* UEFI: P1: TSSTcorp CDDVDW SH-222AB 16:54:44,258 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sdb -p 2 -l \EFI\redhat\grub.efi 16:54:44,346 INFO program: BootCurrent: 0004 16:54:44,346 INFO program: Timeout: 1 seconds 16:54:44,346 INFO program: BootOrder: 0002,0000,0001,0003,0004 16:54:44,346 INFO program: Boot0000* CD/DVD Drive 16:54:44,346 INFO program: Boot0001* Hard Drive 16:54:44,346 INFO program: Boot0003* UEFI: MultipleCard Reader 1.00 16:54:44,346 INFO program: Boot0004* UEFI: P1: TSSTcorp CDDVDW SH-222AB 16:54:44,346 INFO program: Boot0002* Fedora there's no grub-install commands in there. It pokes the EFI boot manager, but does not seem to even attempt to install the grub bootloader. I'm not sure that's related to this bug, exactly, but it sure means I can't get a usable EFI install on my test setup. Note I've never done an EFI install on the system before so I have no 'baseline' to compare to. The immediate bug mentioned is fixed by the update, it seems, as the installer boots and runs successfully, but it does not leave me with a bootable system, and I can't entirely confirm this bug's fixed.
Created attachment 525232 [details] anaconda.log from my problematic test attempt
Created attachment 525233 [details] program.log from my problematic test attempt
Created attachment 525234 [details] storage.log from my problematic test attempt
I suppose that actually adding links to the boot.iso mentioned in comment 5 might help: http://tflink.fedorapeople.org/iso/20110927_newgrub.x64.boot.iso http://tflink.fedorapeople.org/iso/20110927_newgrub.x64.boot.iso.sha256 It's pretty much a beta RC3 netinstall image with grub-0.97-78.fc16.
so I figured out what's wrong with my comment #5 test setup, simple enough - the disk I used is msdos labelled, so EFI booting isn't going to work with it. Oops. went out and bought an 80GB test drive, and it still doesn't work. Install works, just as described in comment #5 (except I disconnected all other drives and told it to use the entire 80GB disk), and it definitely did write the bootloader; but it reboots to a bare grub prompt. I tried bcl's trick of copying the grub.efi from the f15 grub package over to the EFI system partition, and that causes it to reboot as soon as it hits the bootloader. either way, it ain't working. going to test f15 and f16 alpha installs to get a baseline.
f15 works, when installed exactly like in comment #10. so definitely current 16 with this 'fixed' grub is worse than 15 on my test system :/ testing 16 alpha next.
An F16 Alpha install from DVD onto the same setup as comments #10 and #11 results in a reboot loop much like what I saw when copying F15's boot.efi over the one from the F16 Beta + 'fixed' grub install. That's about as much as I can get right now. Well, I can guess I can re-install F15 and do a yum update, and see what happens. I'll give that a shot.
the anaconda logs from Alpha look essentially the same as the Beta test. So i'm theorizing that where I wind up in a reboot loop is the 'working' state for most people, as for bcl, an Alpha install works, and copying f15's grub.efi over the f16 one after a beta install also works. the reboot loop I'm hitting is some other bug that's specific to me. and the bug that bcl and I are both hitting is in grub, as anaconda's behaviour doesn't seem different, and copying over grub.efi from f15 seems to fix it.
grub-0.97-78.fc16 seems to solve my problems EFI booting a 2011 macmini (BZ# 738969)
*** Bug 738969 has been marked as a duplicate of this bug. ***
jurgen: can you test installs on that system, or is it not possible to blow it away?
Package grub-0.97-78.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing grub-0.97-78.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/grub-0.97-78.fc16 then log in and leave karma (feedback).
@adamw: yes I can test installs on the 2011 mac mini. It's my Fedora testing machine. So I another Beta RC comes along which includes the newer grub I am happy to test an install (as I've been doing with all the alpha,tc's/rc's)
So we have made some good progress with understanding this bug today. There's some complexity to it. The 0.97-78 build fixes the initial problem we identified. Our further testing identified two other problems. What anaconda should do for 'bootloader installation' when doing an EFI install is first to write a Fedora entry to the EFI boot loader, then write a grub config file to the EFI system partition (as well as installing the ancillary bits, like grub.efi itself and a splash file and so on). This grub config should contain a line like this: device (hd0,1) HD(foobar) those two stanzas are somewhat redundant: the HD() stanza contains the UUID of the Fedora boot device, the (hdX,Y) stanza refers to it by enumeration. It obtains the UUID by running efibootmgr -v, to read it from the EFI bootloader entry it should just have written. anaconda, however, currently orders this wrong. It writes the grub config file *before* it writes the EFI bootloader entry. So instead of: 1) write an EFI bootloader entry 2) read the UUID from that entry 3) write a grub config file with the discovered UUID it does: 1) try to read the UUID from the EFI boot loader 2) write a grub config file with the discovered UUID (if any) 3) write an EFI bootloader entry What result you get from this wrongly ordered process, obviously, depends on whether there was a Fedora entry in the EFI boot loader before you started installation. If there was, you get a HD() stanza which contains the UUID of the *previous* Fedora boot device. If the was not, you get no HD() stanza at all. Bearing that in mind, let's move on to the second problem. The second problem is simply that grub appears to have a bug whereby it hangs if there's an HD() stanza, whether or not it's valid. So, if we fix problem #1 such that you always get a valid HD() stanza written, but don't fix problem #2, the system will never boot. As things stand, without problem #1 fixed, the situation is a bit more fluid. If you do an install without a pre-existing efi bootloader entry for Fedora, you get a grub config that can actually potentially work, and will almost certainly work if there are no other disks attached to the system. This is essentially an accident, however. What we really want for there to happen is for there always to be a HD() stanza, for it always to refer to the correct UUID, and for grub to read it and boot correctly, not to hang. The reason to have the HD() stanza at all is to make sure things are robust. The drive enumeration can change if you attach or remove drives - USB drives, hard drives, whatever. The device Fedora needs to boot from may not be hd(0,1) any more. But the UUID should never change. So, we can't just bodge this by making anaconda not writing an HD() stanza at all, really. We have to fix both problems to make it robust. Right now, problem #2 appears to be down to over-optimization by GCC.
Note that the bug for the anaconda fix is bug 741994
Discussed at 2011-09-28 go/no-go meeting acting as a blocker review meeting, all three problems tracked in this bug are accepted as Beta blockers as they violate criterion "The installer must boot and run on systems using EFI other than Apple Macs".
grub-0.97-79.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/grub-0.97-79.fc16
for the record, there was a third problem fixed with the anaconda update. the splash file location was not being written to grub.conf. This sounds trivial, but actually, if you don't have a splash file you don't get graphical grub, and if you don't get graphical grub, the kernel might not have a console device, which it really doesn't like. so this could in fact break boot too. EFI is fun! all three problems are fixed with anaconda 16.20 and grub 0.97-79, I have verified this, as has bcl.
Attempted installation onto a 3TB Seagate USB drive with 4096 byte sectoring, and used the defaults for the spindle including LVM. It wouldn't boot... (This is the same setup that I used in https://bugzilla.redhat.com/show_bug.cgi?id=738964#c47 ). HP dv9000z laptop AMD Turion64 2GHz. dual-core, 4GB memory, NVIDIA GeForce 6150, Broadcom BCM4311. (I always have 'nomodeset' these days until the NVIDIA/nouveau issues settle out, on all my Linux installations - oS114, os121, Mageia, F15, F16, Ubuntu...) I booted the RC4 installation by copying over /boot/* to my openSUSE 11.4 installation's /boot/Seagate/Fedora16 directory and adding an appropriate stanza to its Legacy Grub's menu.lst. (Luckily, I removed the 'quiet' so that I could see that selinux was rehabilitating my new installation!...). There was a grub.cfg file that looked decent, but I moved it out of the way and got the following output from 'grub2-mkconfig -o /boot/grub2/grub.cfg' : [root@hislap grub2]# grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.1.0-0.rc8.git0.0.fc16.x86_64 Found initrd image: /boot/initramfs-3.1.0-0.rc8.git0.0.fc16.x86_64.img ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. ERROR: unsupported sector size 4096 on /dev/sdc. ERROR: unsupported sector size 4096 on /dev/dm-0. ERROR: unsupported sector size 4096 on /dev/dm-1. ERROR: unsupported sector size 4096 on /dev/dm-2. Found Windows XP Media Center Edition on /dev/sda1 Found Windows NT/2000/XP on /dev/sda2 Found Microsoft Windows XP Embedded on /dev/sda3 done Note that it did NOT spot the openSUSE 11.4 installation on /dev/sdb, either! (/dev/sda and /dev/sdb are 80GB Toshiba SATA internal drives with 512 byte sectoring). Anaconda did partition the 3TB drive correctly; as viewed by parted on openSUSE: (parted) print Model: Seagate FA GoFlex Desk (scsi) Disk /dev/sdb: 3001GB Sector size (logical/physical): 4096B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 526MB 524MB ext4 boot 3 526MB 3001GB 3000GB lvm I'm thinking that there is an issue with trying to use GRUB2 to boot through an older BIOS from a disk with 4096 byte sectoring, regardless of whether the disk is partitioned with MBR or GPT.
that's not this bug. please file a new one.
grub-0.97-79.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Hmm, I'm having odd problems with grub-0.97-79.fc16 (EFI version) on my 2011 mac mini. Getting it to boot properly (either from DVD or USB) is a real hit-and-miss. Most of the time it does not work properly. Few scenario's I've encountered: 1. Boot just fine 2. Presents black screen and hangs 3. Shows the boot menu, but when trying to edit the boot cmd it hangs 4. Stops half way painting the borders and hangs 0.97-75 work every time and boots the system just fine 0.97-78 work every time and boots the system just fine It seems -79 introduced this erratic behaviour. How to investigate what causes this problem? btw when I remove grub.conf I always get to grub prompt just fine with 0.97-79. Manually loading the kernel works every time. Loading initrd does not work every time. When initrd.img loads, it takes a long time. After giving the boot command the system hangs again.
please file a new bug.
I just tried F16b efidisk.img (provided by the DVD) and the netinst image and both images fail to install a bootable system. I did a stock install adding no extra repository. Anaconda told me about a grub conflict and that something went wrong while installing the bootloader? reopen or a new bug? (It is not #742141, I manually removed a previous entry).
Also seen here https://bugzilla.redhat.com/show_bug.cgi?id=742695 (EFI Boot in VirtualBox 4.1.2 with Beta RC4 DVD on MacPro i7 installs only 203 pkgs Boots to EFI Shell)
@adam, filed under BZ #743330.
Fabian: "Anaconda told me about a grub conflict" that's okay and shouldn't cause any trouble. "and that something went wrong while installing the bootloader" that's the problem, but we need more detail. program.log should have some messages from the bootloader installation attempt, they should shed some light on what the problem is.
:) I will upload some details in a couple of hrs. The only thing I noted, compared to my previous attempts, was a kernel error when setting an efi var. efibootmgr seemed to work fine. but we will see.
Created attachment 526432 [details] anaconda.log from a f16b install which fails booting
Created attachment 526433 [details] anaconda.program.log from a f16b install which fails booting
Created attachment 526434 [details] anaconda.storage.log from a f16b install which fails booting
Created attachment 526435 [details] anaconda.syslog from a f16b install which fails booting 14:06:03,485 WARNING kernel:[ 706.335458] efivars: set_variable() failed: status=8000000000000009 Might be an interesting line in this file.
I successfully did a EFI install of F16 Beta on a Thinkpad T420s today FWIW.
Is there a bug open for the grub vs grub2 conflict that pops up? It would be good to fix that for the final release if possible.
(In reply to comment #38) > I successfully did a EFI install of F16 Beta on a Thinkpad T420s today FWIW. What image did you use?
(In reply to comment #39) > Is there a bug open for the grub vs grub2 conflict that pops up? Bug 735023 - Fedora 16 live images are not EFI-capable: should use grub-efi package when available Bug 743376 - Split grub-efi out from grub and have it not conflict with grub2
Thanks (In reply to comment #40) > What image did you use? The x86_64 efidisk.img from F16 Beta RC4.
The installation fails for me with the image (http://dl.fedoraproject.org/pub/alt/stage/16-Beta.RC4/Fedora/x86_64/os/images/efidisk.img). Also adding adams grub repo doesn't help.
The installation works with the previous rc3 netinst iso and adams grub repo http://dl.fedoraproject.org/pub/alt/stage/16-Beta.RC3/Fedora/x86_64/iso/ Apparently a regression.
And the kernel error in comment #c37 did not appear in syslog in the netinst of rc3 w/ adam's grub repo. kernel of that installer is 3.0.0-1, the one of beta is 3.1.0-0.rc6.
Sorry for the noise. Everything seems to work now. I might have mixed up the images :-/
in addition to the bugs cited by Mads: https://bugzilla.redhat.com/show_bug.cgi?id=743381 is for anaconda.