Bug 741781 - EFI installs failing with Fedora 16 Beta on most hardware
Summary: EFI installs failing with Fedora 16 Beta on most hardware
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grub
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 738969 (view as bug list)
Depends On:
Blocks: F16Beta, F16BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2011-09-27 21:01 UTC by Adam Williamson
Modified: 2011-10-05 20:18 UTC (History)
12 users (show)

Fixed In Version: grub-0.97-79.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-03 17:57:48 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Proposed patch (1.04 KB, patch)
2011-09-27 21:03 UTC, Peter Jones
no flags Details | Diff
anaconda.log from my problematic test attempt (23.38 KB, text/plain)
2011-09-28 00:26 UTC, Adam Williamson
no flags Details
program.log from my problematic test attempt (130.12 KB, text/plain)
2011-09-28 00:27 UTC, Adam Williamson
no flags Details
storage.log from my problematic test attempt (315.36 KB, text/plain)
2011-09-28 00:27 UTC, Adam Williamson
no flags Details
anaconda.log from a f16b install which fails booting (29.34 KB, text/x-log)
2011-10-05 07:04 UTC, Fabian Deutsch
no flags Details
anaconda.program.log from a f16b install which fails booting (102.85 KB, text/x-log)
2011-10-05 07:05 UTC, Fabian Deutsch
no flags Details
anaconda.storage.log from a f16b install which fails booting (321.19 KB, text/x-log)
2011-10-05 07:05 UTC, Fabian Deutsch
no flags Details
anaconda.syslog from a f16b install which fails booting (175.85 KB, application/octet-stream)
2011-10-05 07:07 UTC, Fabian Deutsch
no flags Details

Description Adam Williamson 2011-09-27 21:01:36 UTC
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.

Comment 1 Peter Jones 2011-09-27 21:03:18 UTC
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.

Comment 2 Adam Williamson 2011-09-27 21:03:46 UTC
proposing as Beta blocker per criterion "The installer must boot and run on
systems using EFI other than Apple Macs".

Comment 3 Fedora Update System 2011-09-27 21:20:50 UTC
grub-0.97-78.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-78.fc16

Comment 4 Tim Flink 2011-09-27 21:31:16 UTC
+1 blocker since this is a pretty obvious violation of the release criteria

Comment 5 Adam Williamson 2011-09-28 00:20:43 UTC
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.

Comment 6 Adam Williamson 2011-09-28 00:26:48 UTC
Created attachment 525232 [details]
anaconda.log from my problematic test attempt

Comment 7 Adam Williamson 2011-09-28 00:27:12 UTC
Created attachment 525233 [details]
program.log from my problematic test attempt

Comment 8 Adam Williamson 2011-09-28 00:27:34 UTC
Created attachment 525234 [details]
storage.log from my problematic test attempt

Comment 9 Tim Flink 2011-09-28 00:29:18 UTC
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.

Comment 10 Adam Williamson 2011-09-28 01:57:59 UTC
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.

Comment 11 Adam Williamson 2011-09-28 03:45:56 UTC
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.

Comment 12 Adam Williamson 2011-09-28 05:44:01 UTC
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.

Comment 13 Adam Williamson 2011-09-28 05:55:10 UTC
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.

Comment 14 Jurgen Kramer 2011-09-28 13:41:37 UTC
grub-0.97-78.fc16 seems to solve my problems EFI booting a 2011 macmini (BZ# 738969)

Comment 15 Peter Jones 2011-09-28 15:24:18 UTC
*** Bug 738969 has been marked as a duplicate of this bug. ***

Comment 16 Adam Williamson 2011-09-28 16:17:04 UTC
jurgen: can you test installs on that system, or is it not possible to blow it away?

Comment 17 Fedora Update System 2011-09-28 18:54:02 UTC
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).

Comment 18 Jurgen Kramer 2011-09-28 19:32:50 UTC
@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)

Comment 19 Adam Williamson 2011-09-28 21:03:09 UTC
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.

Comment 20 Brian Lane 2011-09-28 21:07:32 UTC
Note that the bug for the anaconda fix is bug 741994

Comment 21 Adam Williamson 2011-09-28 21:55:39 UTC
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".

Comment 22 Fedora Update System 2011-09-28 23:39:46 UTC
grub-0.97-79.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-79.fc16

Comment 23 Adam Williamson 2011-09-29 07:08:20 UTC
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.

Comment 24 Bayard R. Coolidge 2011-09-29 16:12:23 UTC
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.

Comment 25 Adam Williamson 2011-10-03 16:00:30 UTC
that's not this bug. please file a new one.

Comment 26 Fedora Update System 2011-10-03 17:57:22 UTC
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.

Comment 27 Jurgen Kramer 2011-10-03 18:01:31 UTC
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.

Comment 28 Adam Williamson 2011-10-04 07:31:59 UTC
please file a new bug.

Comment 29 Fabian Deutsch 2011-10-04 14:13:44 UTC
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).

Comment 30 satellitgo 2011-10-04 14:41:11 UTC
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)

Comment 31 Jurgen Kramer 2011-10-04 15:48:46 UTC
@adam, filed under BZ #743330.

Comment 32 Adam Williamson 2011-10-04 20:52:51 UTC
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.

Comment 33 Fabian Deutsch 2011-10-04 21:06:35 UTC
:) 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.

Comment 34 Fabian Deutsch 2011-10-05 07:04:40 UTC
Created attachment 526432 [details]
anaconda.log from a f16b install which fails booting

Comment 35 Fabian Deutsch 2011-10-05 07:05:35 UTC
Created attachment 526433 [details]
anaconda.program.log from a f16b install which fails booting

Comment 36 Fabian Deutsch 2011-10-05 07:05:59 UTC
Created attachment 526434 [details]
anaconda.storage.log from a f16b install which fails booting

Comment 37 Fabian Deutsch 2011-10-05 07:07:01 UTC
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.

Comment 38 Jens Petersen 2011-10-05 07:59:40 UTC
I successfully did a EFI install of F16 Beta on a Thinkpad T420s today FWIW.

Comment 39 Jens Petersen 2011-10-05 08:00:49 UTC
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.

Comment 40 Fabian Deutsch 2011-10-05 08:31:51 UTC
(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?

Comment 41 Mads Kiilerich 2011-10-05 09:12:53 UTC
(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

Comment 42 Jens Petersen 2011-10-05 10:48:25 UTC
Thanks

(In reply to comment #40)
> What image did you use?

The x86_64 efidisk.img from F16 Beta RC4.

Comment 43 Fabian Deutsch 2011-10-05 11:07:50 UTC
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.

Comment 44 Fabian Deutsch 2011-10-05 12:02:39 UTC
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.

Comment 45 Fabian Deutsch 2011-10-05 12:17:02 UTC
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.

Comment 46 Fabian Deutsch 2011-10-05 16:17:36 UTC
Sorry for the noise. Everything seems to work now. I might have mixed up the images :-/

Comment 47 Adam Williamson 2011-10-05 20:18:57 UTC
in addition to the bugs cited by Mads:

https://bugzilla.redhat.com/show_bug.cgi?id=743381 is for anaconda.


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