Fedora Linux Support Community & Resources Center
  #16  
Old 24th February 2012, 07:12 PM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Thanks very much to both of you for your replies!

Quote:
The installer's log files probably contain a clue about what went wrong. I don't recall precisely what they're called, but IIRC they're in the newly-installed system's /root directory.
Yes, there are a couple log files there: install.log and install.log.syslog, Somehow I didn't think to look at them when I saw the earlier issues, and I've done another successful install since, so the contents of the logs don't look very interesting right now.

srs5694: I haven't tried your version of rEFIt yet. Hopefully I can get to that later today or tomorrow, but I wanted to give an update on the other things first...

First, my apologies for posting my ESP contents in that state. You're right that it was the result of several copying/renaming attempts, as I was fishing for some path that would entice the BIOS into biting, based on what I'd read in various places. At some point I tried other bootloaders, including an EFI shell. ATM I don't even remember what the one in that listing was. So yes, all I did was add confusion, sorry.

Starting from a clean installation, using custom partitioning and booting the install CD in EFI mode, the ESP contains just one file:

Code:
-rwx------   1 root     root       680960 Dec  9 11:38 EFI/redhat/grub.efi
Attempting to boot with that results in "No bootable device -- insert boot disk and press any key".

So I booted using the Super GRUB2 Disk (which boots in BIOS mode - but it provides a network connection, which the install CD does not, despite having gone through the host-name and "configure network" screen), mounted the F16 partitions, chroot'd into it, used yum to install grub2-efi and efibootmgr packages, and ran grub2-efi-install. After that, there were 2 files in the ESP

Code:
-rwxr-xr-x   1 root     root       147456 Feb 23 21:31 EFI/fedora/grubx64.efi
-rwxr-xr-x   1 root     root       680960 Dec  9 17:38 EFI/redhat/grub.efi
and efibootmgr (with no arguments) writes

Code:
BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux
Boot0001* fedora
which is also part of grub2-efi-install's output.

Result: "No bootable device -- insert boot disk and press any key"

Booting again from one of the CDs, I copied the fedora bootloader to the default path, giving:

Code:
-rwx------   1 root     root       147456 Feb 23 16:52 EFI/BOOT/bootx64.efi
-rwx------   1 root     root       147456 Feb 23 16:52 EFI/fedora/grubx64.efi
-rwx------   1 root     root       680960 Dec  9 11:38 EFI/redhat/grub.efi
Result: "No bootable device -- insert boot disk and press any key"

I didn't try copying in any .conf files yet, partly because there aren't any under /boot. There is one .cfg file, grub2/grub.cfg (not in grub2-efi, if that matters, although there is one in /etc), but I wasn't sure it was the same sort of thing that the bootloader might be looking for. I also figured that the "No bootable device" message was coming from the BIOS, meaning that I wasn't getting far enough yet to worry about config file issues. But I can try copying, say, /etc/grub2-efi.cfg as EFI/BOOT/bootx64.conf if you think it'd be a worthwhile experiment.

Thanks for the explanations about GPT types, and thanks for the great on-line docs! And while I'm at it, thanks for gdisk -- it makes more sense to me than parted, even aside from the missing patch issue. (I have a question or two about it, but I'll ask that somewhere else...) I wish it came with the install CD and DVD. Anyway, I'm pretty sure the types were changed on at least 2, maybe 3 partitions in addition to the 0700's on the ext4 partitions. I'll likely be doing at least one more clean install soon, so I'll try to remember to write that down next time.
Reply With Quote
  #17  
Old 24th February 2012, 08:53 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: F16 - GRUB2 EFI non-Mac

Quote:
Originally Posted by Don3 View Post
Yes, there are a couple log files there: install.log and install.log.syslog, Somehow I didn't think to look at them when I saw the earlier issues, and I've done another successful install since, so the contents of the logs don't look very interesting right now.
If your system isn't booting (as it sounds like it isn't), then I'd say your install is not successful. Still, at least the main boot loader is in place and it sounds like your firmware isn't detecting it, so you may be right that there won't be any clues in the log files. OTOH, you might see an error message related to efibootmgr or the installation of the boot loader configuration files, so it's worth perusing them.

Quote:
So I booted using the Super GRUB2 Disk (which boots in BIOS mode - but it provides a network connection, which the install CD does not, despite having gone through the host-name and "configure network" screen), mounted the F16 partitions, chroot'd into it, used yum to install grub2-efi and efibootmgr packages, and ran grub2-efi-install. After that, there were 2 files in the ESP

Code:
-rwxr-xr-x   1 root     root       147456 Feb 23 21:31 EFI/fedora/grubx64.efi
-rwxr-xr-x   1 root     root       680960 Dec  9 17:38 EFI/redhat/grub.efi
and efibootmgr (with no arguments) writes

Code:
BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux
Boot0001* fedora
If you're running this after booting from Super GRUB 2 Disk, then it suggests that you booted in EFI mode, not BIOS mode. You can check this by examining your kernel ring buffer with dmesg:

Code:
dmesg | grep EFI
An EFI boot will produce many lines, as in:

Code:
[    0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[    2.514042] efifb: probing for efifb
[    2.514823] efifb: framebuffer at 0xc0000000, mapped to 0xffffc90011a00000, using 3752k, total 32704k
[    2.514829] efifb: mode is 800x600x32, linelength=3200, pages=1
[    2.514833] efifb: scrolling: redraw
[    2.514837] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
rodsmith@seeker:/other/nessus/homepage/parted-patches$ dmesg | grep EFI
[    0.000000] Command line: BOOT_IMAGE=atapi0:\EFI\ELILO\bzImage-3.0.4 root=/dev/seeker/u1104  ro
[    0.000000] EFI v2.00 by American Megatrends
[    0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[    0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000048000) (0MB)
[    0.000000] EFI: mem01: type=7, attr=0xf, range=[0x0000000000048000-0x0000000000097000) (0MB)
...
[    0.000000] EFI: mem135: type=11, attr=0x8000000000000001, range=[0x00000000ff000000-0x0000000100000000) (16MB)
[    0.000000] Kernel command line: BOOT_IMAGE=atapi0:\EFI\ELILO\bzImage-3.0.4 root=/dev/seeker/u1104  ro
[    2.517097] fb0: EFI VGA frame buffer device
[    3.174283] EFI Variables Facility v0.08 2004-May-17
[    9.386613] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
I've trimmed many of those lines for brevity; there are "EFI: mem00" through "EFI: mem135" lines, plus the others. Details will vary, of course. On a non-EFI system, though, you're likely to get no output from this command, or perhaps just a few lines, perhaps with "EFI" matching some larger string.

Quote:
Result: "No bootable device -- insert boot disk and press any key"
Your efibootmgr output looks reasonable. I have some suggestions at this point to get EFI booting working:
  • Go into the firmware setup utility and look for options related to EFI booting and play with them. On my Intel DG43NB motherboard (which presumably has a similar UEFI implementation), there's a firmware option to enable/disable EFI-style booting under the "Boot" menu. Be sure that EFI-style booting is enabled. You can also experiment with other options on this menu, assuming your firmware is similar to mine.
  • Pressing F10 at boot time brings up a boot selector that gives you the choice of which EFI boot option to select. (For you, it should include both "Linux" and "fedora," if your efibootmgr output is accurate.)
  • Examine the first sector of your hard disk. If it contains BIOS boot loader code, it's conceivable that your firmware is detecting that, switching to BIOS mode, and failing to boot because the boot loader is incomplete. If you find this is the case, you can wipe it clean with the command "dd if=/dev/zero of=/dev/sda bs=440 count=1". Be sure to get the device filename, bs=, and count= options right, or you might wipe out the wrong disk or more than you intend!
  • Check the EFI System Partition (ESP) on the computer. Be sure it's got the right type code -- 0xEF00 in gdisk or a "boot flag" in parted. Also verify that it's FAT32. Another point: I vaguely recall hearing about a UEFI implementation that has problems if the ESP is too big, and Fedora tends to create huge ESPs (tens of gigabytes). My own recommendation is to make it 200-500 MiB in size.

Quote:
I also figured that the "No bootable device" message was coming from the BIOS, meaning that I wasn't getting far enough yet to worry about config file issues. But I can try copying, say, /etc/grub2-efi.cfg as EFI/BOOT/bootx64.conf if you think it'd be a worthwhile experiment.
This is probably a correct assessment; IIRC, GRUB Legacy and GRUB 2 both give other messages if they can't load relevant code or find their configuration files. I might be mistaken about this, though.

---------- Post added at 03:53 PM ---------- Previous post was at 03:48 PM ----------

Oh, one more thing I forgot: If booting in EFI mode proves to be too hairy, you can probably revert to BIOS mode. To do this, you'd disable EFI booting in the BIOS. You could then wipe the disk and re-install or boot in BIOS mode and install a BIOS-type boot loader. The Intel motherboard firmware is likely to have problems booting from GPT if the protective MBR's 0xEE partition is not flagged as bootable, though, so if you stick with GPT and switch to BIOS booting, you should set the boot flag using fdisk (not gdisk or parted!).
Reply With Quote
  #18  
Old 25th February 2012, 03:40 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Quote:
If your system isn't booting (as it sounds like it isn't), then I'd say your install is not successful.
I'm with you on that. What I meant in this case was that the installer seemed satisfied with what it had done ("Installation successful, please reboot to finish the installation", or some such), whereas with some of my other attempts, it failed on the BL installation or just crashed. I'm starting to understand possible reasons for that now, thanks largely to the help I've received here. Indeed the system does not boot on its own, but I've been able to boot it using the CDs I've mentioned.

Quote:
Quote:
So I booted using the Super GRUB2 Disk (which boots in BIOS mode...), mounted the F16 partitions, chroot'd into it, used yum to install grub2-efi and efibootmgr packages, and ran grub2-efi-install. After that, there were 2 files in the ESP ... and efibootmgr (with no arguments) writes ...
If you're running this after booting from Super GRUB 2 Disk, then it suggests that you booted in EFI mode, not BIOS mode.
Woops! You're quite right! Full disclosure: I wrote the previous post twice. Just as I was about to hit the submit button the first time, my browser crashed, taking the entire thing with it. On my second attempt, I skipped over some important details, sorry. Here's something closer to the complete sequence:
  • booted using the Super GRUB2 Disk
  • mounted the F16 partitions
  • chroot'd into F16 root dir
  • used yum to install grub2-efi and efibootmgr packages
  • shut down
  • booted using the F16 install CD in EFI mode
  • proceded past the network setup (not that it does any good)
  • mounted the F16 partitions
  • chroot'd into F16-land
  • ran grub2-efi-install
  • looked at the contents of /boot/efi/...

I'm pretty sure the Super Grub2 disk is booting in BIOS mode because efibootmgr fails if I try to use it when the system was booted that way, "modprobe efivars" fails, etc. But one interesting thing to me is that the BIOS seems to be capable of booting the Fedora install CD/DVD in either mode - although so far the only way I've discovered to control it is to change when I insert the disc relative to what I see on the screen. Sure would be nice if the BIOS would say what it's trying to do.

Quote:
  • Go into the firmware setup utility and look for options related to EFI booting and play with them. On my Intel DG43NB motherboard (which presumably has a similar UEFI implementation), there's a firmware option to enable/disable EFI-style booting under the "Boot" menu. Be sure that EFI-style booting is enabled. You can also experiment with other options on this menu, assuming your firmware is similar to mine.
Yes, my board has an "EFI boot" option, which is either enabled or disabled. Er, well, in my case enabled is the only choice that sticks - I can change the setting to disabled, but after saving the settings and booting again, it reverts to enabled. I've checked the so-called "CMOS" battery (3.2 volts), and I've tried disconnecting all HDDs, just to make sure the BIOS wasn't setting EFI mode based on seeing a GPT. Beyond the one enable/disable parameter, I don't see any other EFI-related options, and I don't even see any mention of EFI in Intel's BIOS "glossaries".

Quote:
  • Pressing F10 at boot time brings up a boot selector that gives you the choice of which EFI boot option to select. (For you, it should include both "Linux" and "fedora," if your efibootmgr output is accurate.)
The menu items are:
  • fedora
  • Linux
  • HP DVD Writer 640
  • P0-ST31000528AS
Selecting "fedora" clears the screen, code BA shows in the lower right for a couple seconds, then the F10 screen returns - and "fedora" is no longer in the list! Selecting "Linux" elicits a similar response, except that the code is BB. (The copy of Intel's BIOS doc I have lists POST code BA as "Detecting presence of a removable media (IDE, CD-ROM detection, etc.)", and BB is not documented. So maybe these aren't POST codes...) Selecting either of the other two remaining entries boots an optical disc, if there's on in the drive, otherwise it's my old favorite "No bootable device...".
Quote:
  • Examine the first sector of your hard disk. If it contains BIOS boot loader code, it's conceivable that your firmware is detecting that, switching to BIOS mode, and failing to boot because the boot loader is incomplete. If you find this is the case, you can wipe it clean with the command "dd if=/dev/zero of=/dev/sda bs=440 count=1". Be sure to get the device filename, bs=, and count= options right, or you might wipe out the wrong disk or more than you intend!
Excellent idea... There was indeed code in the first part of the MBR -- I saved a copy before I wiped those first 440 bytes -- and I could see the "protective" partition entry there too. I can send you hex dumps of the "before" and "after" contents if needed. However, zeroing those bytes had no effect on the behaviour.
Quote:
  • Check the EFI System Partition (ESP) on the computer. Be sure it's got the right type code -- 0xEF00 in gdisk or a "boot flag" in parted. Also verify that it's FAT32. Another point: I vaguely recall hearing about a UEFI implementation that has problems if the ESP is too big, and Fedora tends to create huge ESPs (tens of gigabytes). My own recommendation is to make it 200-500 MiB in size.
Yes, the ESP has type 0xEF00, and the size is within your recommend range. Here are the first few partitions currently set up (gdisk output):
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1              40            2047   1004.0 KiB  8301  Linux reserved
   2            2048          788479   384.0 MiB   EF00  EFI System Partition
   3          788480         1574911   384.0 MiB   8300  boot
   4         1574912        51906559   24.0 GiB    8300  root
Of course this is not the default Fedora layout. FYI, I put partition 1 there only to allow for experiments with a BIOS boot partition, back when I was thinking that might be a possibility. It's all 0x00's at the moment.

The ESP was mounted with type "vfat", and at first I wasn't sure which type of FAT it was, until I noticed this in the output of fsck.vfat (dosfsck):
Code:
First FAT starts at byte 8192 (sector 16)
         2 FATs, 16 bit entries
     98304 bytes per FAT (= 192 sectors)
This was created by the installer, AFAIK. I don't know how it's being called, but I noticed in the man page for mkdosfs that by default it chooses the FAT size based on the size of the file system, and this one isn't huge... So I made a cpio archive of the contents, unmounted it, created a new FAT32 file system, and restored the contents from the archive.

Result: "No bootable device -- insert boot disk and press any key"

Quote:
If booting in EFI mode proves to be too hairy, you can probably revert to BIOS mode. To do this, you'd disable EFI booting in the BIOS...
If only we could cure the board of its current aversion to that option. It booted that way for over 4 years, but it seems disinclined to do that now.
Reply With Quote
  #19  
Old 25th February 2012, 03:57 AM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 970
macoschrome
Re: F16 - GRUB2 EFI non-Mac

Quote:
Originally Posted by Don3 View Post
Code:
-rwx------   1 root     root       147456 Feb 23 16:52 EFI/BOOT/bootx64.efi
I don't know that it matters, but I've always found references that this should be BOOTX64.efi not bootx64.efi.

That the EFI firmware is not finding this, is confusing. I'm increasingly thinking you've got a firmware bug. AFAIK, the UEFI spec doesn't require the EFI system partition be the very first partition, so your firmware should find it based on reading the GPT, should know how to read the FAT32 variant of the EFI file system format, and always consume any file with this name in this path. That it's not...highly suspect.

Quote:
Originally Posted by Don3 View Post
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1              40            2047   1004.0 KiB  8301  Linux reserved
   2            2048          788479   384.0 MiB   EF00  EFI System Partition
   3          788480         1574911   384.0 MiB   8300  boot
   4         1574912        51906559   24.0 GiB    8300  root
a. The first partition type code should be EF02 not 8301.

b. I'm confused how this 1st partition starts at sector 40.The only tool I know that starts partitions at sector 40 is Apple's Disk Utility. Everything else starts them at either 63 or 2048. Assuming you created this manually.

c. Partition 2, EFI System should be 200MiB. 384 is overkill.

d. Partition 3, /boot is normally 500MB.

e. I personally would have the first partition start at 2048 and be the EFI System partition, followed by the BIOS Boot partition, followed by /boot and then /.
Reply With Quote
  #20  
Old 25th February 2012, 04:52 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Quote:
Quote:
Originally Posted by Don3
Code:
-rwx------   1 root     root       147456 Feb 23 16:52 EFI/BOOT/bootx64.efi
I don't know that it matters, but I've always found references that this should be BOOTX64.efi not bootx64.efi.
AFAIK it isn't case sensitive, and I think srs5694 said that earlier too. But I can give it a try like that.

Quote:
I'm increasingly thinking you've got a firmware bug.
Yeah, I've been wondering about that too. I did upgrade to the latest BIOS release, which was like 2009-ish, IIRC. Since EFI originated with Intel, I was hoping the BIOS on an Intel board might implement it fairly close to "correctly", whatever that meant at the time. Also the fact that (at least some) BIOS settings don't stick any more makes me wonder whether there's a HW problem.

Quote:
a. The first partition type code should be EF02 not 8301.
Yes, and it was EF02 until just a little while ago. I was just trying to make sure the BIOS wasn't confused by the presence of a BIOS boot partition, even though there's no file system in it, so I set the type to something else. It had no effect though.

Quote:
b. I'm confused how this 1st partition starts at sector 40.The only tool I know that starts partitions at sector 40 is Apple's Disk Utility. Everything else starts them at either 63 or 2048. Assuming you created this manually.
Indeed, I did this one manually. Earlier in the thread I was using the installer's default partitioning scheme. That didn't work either, but then I have made a few changes since then, so I suppose I should retest that. Oh, I chose to start on sector 40 because it's the first 4-KiB-aligned sector after the primary GPT.

Quote:
c. Partition 2, EFI System should be 200MiB. 384 is overkill.

d. Partition 3, /boot is normally 500MB.

e. I personally would have the first partition start at 2048 and be the EFI System partition, followed by the BIOS Boot partition, followed by /boot and then /.
The sizes I chose were more or less initial guesses, not knowing how all this was going to work out. The installer's default arrangement gave me a 35-GiB(!) ESP (see post #4), so I guess I'm more reasonable than that. Also the default configuration has no BIOS boot partition at all, and I was thinking I should have one for experimentation purposes, if nothing else. ATM there's no point in me having one, since I can't seem to boot in BIOS mode any more.
Reply With Quote
  #21  
Old 25th February 2012, 06:38 AM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 970
macoschrome
Re: F16 - GRUB2 EFI non-Mac

I would like to think a 2009 UEFI from Intel would behave pretty well. But what do I know?

Boot off anything other than the hard drive.

dd if=/dev/zero of=/dev/sda bs=1M count=1

Yank the batteries on the motherboard, and the power cable between motherboard and power supply. Let it sit overnight. Play again in the morning. Maybe something in NVRAM is fakaked, or elsewhere on that board.

Start with EFI/BIOS and seeing if you can get it to stick in EFI mode. Chances are, after restoring batteries and power, it reverts to default BIOS emulation (?). I'd also stick to just F16 DVD or LiveCD.

Do a default installation. Even odds whether it will boot or not. Again, I'm not sure if this UEFI has a boot selection menu, that would compel it to scan EFI//EFI/ for boot loaders. So you may still have to boot off a LiveCD and populate EFI//EFI/BOOT with a renamed grub.efi and grub.conf.

But at this point, in theory, you'd have started with clean NVRAM, clean first 1MB of the disk, clean GPT with default partitioning, and maybe a single modification to make EFI//EFI/BOOT/BOOTX64.efi

If that doesn't work... I think you're stuck in a rabbit hole. You could start over yet again, blow away the first 1M, reset the NVRAM, confirm you're back in BIOS emulation mode, and then do a new install. One of them's got to work, or you're right - wonky motherboard more likely than firmware.

Hey, have you tried doing a few passes of memtest86? Might be worth a go overnight.
Reply With Quote
  #22  
Old 26th February 2012, 06:56 AM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: F16 - GRUB2 EFI non-Mac

Sorry for the delay in posting. I've had my own problems -- my primary system's motherboard died suddenly on Friday evening, so I couldn't replace it until today, and the replacement (a Gigabyte board) has an EFI implementation that makes Intel's primitive one look advanced.

Anyhow, a few comments:
  • The size of the ESP is somewhat arbitrary. The key is that it be big enough to hold necessary drivers, boot loaders, and other files, but not so big that it's wasting space. Since ELILO more-or-less requires that the kernel and initial RAM disk be stored on the ESP, that makes the size requirements similar to those for a separate /boot partition if you think you might want to use ELILO. Since ELILO is, in my experience, the most reliable EFI boot loader for Linux (followed closely by GRUB Legacy), IMHO, something in the 200-500 MiB range is good for the ESP.
  • You might want to try again with the ESP as the first partition. This shouldn't make a difference, but who knows, maybe there's a bug in your firmware that makes an assumption about the partition number of the ESP. (You can use gdisk to transpose partition numbers, which might be a quick way to test at least part of this -- transpose partitions 1 and 2 to make the ESP partition #1 in the table, although it'll still come second in terms of allocated disk sectors.)
  • I agree with Chris's suggestions for trying to wipe your CMOS as clean as possible in case some setting is lingering there despite the usual cleaning-out procedures.
  • Now that I think about it, I have a vague memory that my Intel board's EFI implementation might have ignored the EFI/BOOT/BOOTX64.EFI default EFI boot loader file, too, so your results on that score may not be abnormal in terms of what's normal for Intel's boards. (The EFI spec does say that an EFI firmware must load that file as a default, IIRC, so this indicates a deviation from the spec.)
  • Have you tried booting in BIOS mode (via Super GRUB Disk or something similar) and installing GRUB Legacy or GRUB 2 in that mode? (My apologies if you've already said you've tried this. I don't recall your mentioning it, and nothing jumped out in a quick scan of earlier posts.) If you do this, wipe the ESP, and give it a new type code, that might convince the firmware to look for a BIOS-style boot loader. (Note that you may need to set the bootable flag on the 0xEE MBR protective partition or the Intel firmware may refuse to boot from the disk in BIOS mode.)
  • Could you boot the installer in EFI mode, type "efibootmgr -v", and post the results here? (After adding new EFI boot manager entries, if necessary.) Perhaps we'll spot some subtle error, like a mis-specified path to the boot loader files.
  • It should be possible to create an EFI-bootable CD that would launch GRUB, ELILO, or rEFIt. (The rEFIt CD image on its main site won't work because that uses a Mac "fat binary" that UEFI systems can't parse.) I've been meaning to do something like this with rEFIt for a while, but haven't gotten around to it yet....


---------- Post added at 01:56 AM ---------- Previous post was at 12:57 AM ----------

OK, I've made a first pass at a UEFI-capable CD-R image with rEFIt. I've posted it on my Web site here:

http://www.rodsbooks.com/efi-bootloa...efit-cd.iso.gz

If you care to try it, I'd be interested in hearing how it works. (So far I've only tested it in a VirtualBox session myself.)
Reply With Quote
  #23  
Old 27th February 2012, 05:47 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Quote:
Originally posted by chrismurphy

Boot off anything other than the hard drive.

dd if=/dev/zero of=/dev/sda bs=1M count=1

Yank the batteries on the motherboard, and the power cable between motherboard and power supply. Let it sit overnight. Play again in the morning. Maybe something in NVRAM is fakaked, or elsewhere on that board.
I don't think I mentioned it here before, but I tried this earlier -- left the battery out for over a day, shorted the battery contacts (to make sure any capacitance got discharged) wiped the whole drive, and even unplugged it. I can certainly try it again though.

Quote:
Start with EFI/BIOS and seeing if you can get it to stick in EFI mode. Chances are, after restoring batteries and power, it reverts to default BIOS emulation (?).
Getting it to stick in EFI mode is not a problem -- it only sticks in EFI mode. My previous attempt with removing the battery etc had no effect on that. But as I say, it may be worth another shot -- ya never know...

Quote:
Do a default installation. Even odds whether it will boot or not.
Previous attempts using default partitioning fared no better, I'm afraid. (I talked about one of them starting with post #4.) But I can try this again too.

Quote:
Again, I'm not sure if this UEFI has a boot selection menu, that would compel it to scan EFI//EFI/ for boot loaders.
I've learned during the course of this that it does have a menu that's displayed if F10 is pressed while on the Intel splash screen, but the menu behaves very strangely -- see post #11, 4th bullet and the 2nd bullet list in post #18.

Quote:
Hey, have you tried doing a few passes of memtest86? Might be worth a go overnight.
Very good idea -- I haven't run that since I upgraded the RAM from 4 to 8 GiB a couple months ago. So I ran it overnight last night -- it did 3 full passes with no errors. Not sure the BIOS code uses the same RAM that memtest86 tests, but definitely good to rule out any obvious issues there.

Quote:
Originally posted by srs5694
  • The size of the ESP is somewhat arbitrary. The key is that it be big enough to hold necessary drivers, boot loaders, and other files, but not so big that it's wasting space. Since ELILO more-or-less requires that the kernel and initial RAM disk be stored on the ESP, that makes the size requirements similar to those for a separate /boot partition if you think you might want to use ELILO. Since ELILO is, in my experience, the most reliable EFI boot loader for Linux (followed closely by GRUB Legacy), IMHO, something in the 200-500 MiB range is good for the ESP.
OK, good to know. That's pretty much what I had learned here and from the various docs I've read, including yours. I'd be happy to give ELILO a try (I remember using LILO for years before GRUB came along), but from what I can see at this point, the BIOS doesn't seem to recognize any EFI BL.

Quote:
  • You might want to try again with the ESP as the first partition....
Good idea. I tried that, using gdisk to transpose partitions 1 and 2, as you suggested. No change in behaviour, unfortunately.

Quote:
  • Now that I think about it, I have a vague memory that my Intel board's EFI implementation might have ignored the EFI/BOOT/BOOTX64.EFI default EFI boot loader file, too, so your results on that score may not be abnormal in terms of what's normal for Intel's boards. (The EFI spec does say that an EFI firmware must load that file as a default, IIRC, so this indicates a deviation from the spec.)
It would be great if we could dump the contents of the BIOS flash, and scan it for strings that look like paths... It'd really be ironic if a BIOS on an Intel board didn't follow the spec.

Quote:
  • Have you tried booting in BIOS mode (via Super GRUB Disk or something similar) and installing GRUB Legacy or GRUB 2 in that mode?
I think I've tried it, more or less unintentionally, with some of my attempts early on - when I didn't really understand that the install CD/DVD could itself be booted in either mode. I can try it deliberately, but it may take a while -- I'll post the results of the next item first.

Quote:
  • Could you boot the installer in EFI mode, type "efibootmgr -v", and post the results here? (After adding new EFI boot manager entries, if necessary.) Perhaps we'll spot some subtle error, like a mis-specified path to the boot loader files.
Here's the initial output I had:
Code:
BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux HD(1,800,479e000,166c2d13-514c-4921-9969-5f9e4cfaa823)File(\EFI\redhat\grub.efi)
Boot0001* fedora        HD(2,800,c0000,e3ad4b9f-b0e5-431d-9fa7-8e387fceacac)File(\EFI\fedora\grubx64.efi)
I noticed that (what I assume were) the HD partition numbers in the two entries were different, which seemed odd -- and it occurred to me that I just transposed partitions, so I ran grub2-efi-install aain. Now "efibootmgr -v" reports:
Code:
BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux HD(1,800,479e000,166c2d13-514c-4921-9969-5f9e4cfaa823)File(\EFI\redhat\grub.efi)
Boot0001* fedora        HD(1,800,c0000,e3ad4b9f-b0e5-431d-9fa7-8e387fceacac)File(\EFI\fedora\grubx64.efi)
Quote:
  • It should be possible to create an EFI-bootable CD that would launch GRUB, ELILO, or rEFIt. ... I've been meaning to do something like this with rEFIt for a while, but haven't gotten around to it yet....
OK, I've made a first pass at a UEFI-capable CD-R image with rEFIt. I've posted it on my Web site here:

http://www.rodsbooks.com/efi-bootloa...efit-cd.iso.gz
I've been curious about optical media and USB flash devices since I came to understand (during the course of this) that the F16 install CD and DVD could be booted in either BIOS or EFI modes. I tried using ISOLINUX to make a CD version of your rEFIt contents, hacking in the MBR BL contents from the F16 CD and manually providing dummy MBR partition data. I can get ISOLINUX to come up, but I assume that's starting in BIOS mode. So far Google hasn't been much help in telling me how Fedora CD/DVD images are constructed.

I burned your ISO to a CD, and it works! That is, it comes up with rEFIt's menu. I tried clicking the two big icons on top, but they don't boot anything. One seems to re-load the rEFIt bootloader, and the other one clears the screen - nothing happens until I press a key, at which time it returns to the rEFIt menu. But hey, at least the CD boots -- that's better than what I had!

I'll post back when I have results from some of the other suggestions above. I may not have much chance to work on this during the next couple days...
Reply With Quote
  #24  
Old 27th February 2012, 05:59 AM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 970
macoschrome
Re: F16 - GRUB2 EFI non-Mac

The code blocks appear identical for:
"Here's the initial output I had:"
"Now "efibootmgr -v" reports:"

In both cases it appears the boot order is asking EFI to look for the 0001 entry which is:
File(\EFI\fedora\grubx64.efi

And I don't remember seeing that in any of your EFI System Partition listings. So that would seem to be a possible explanation for boot failure. I'm not sure why it doesn't fall back to the 0000 entry which you do have. But I might not be understanding the expected behavior.
Reply With Quote
  #25  
Old 27th February 2012, 06:29 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Quote:
The code blocks appear identical for:
"Here's the initial output I had:"
"Now "efibootmgr -v" reports:"

In both cases it appears the boot order is asking EFI to look for the 0001 entry which is:
File(\EFI\fedora\grubx64.efi
The difference is in the first number in the parens, after "HD" in the "fedora" line, which I assume is the partition number.

Quote:
And I don't remember seeing that in any of your EFI System Partition listings.
Isn't that what I have in post #16?:

Code:
-rwxr-xr-x   1 root     root       147456 Feb 23 21:31 EFI/fedora/grubx64.efi
-rwxr-xr-x   1 root     root       680960 Dec  9 17:38 EFI/redhat/grub.efi
Or do you mean that the leading [back]slash is a problem? Or have my eyes gone too blurry to see the difference?
Reply With Quote
  #26  
Old 27th February 2012, 06:38 AM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 970
macoschrome
Re: F16 - GRUB2 EFI non-Mac

No, it's just that I didn't remember it and was too lazy to go looking for it in a 25 post thread.

Well...I'm kinda stumped. Seems like the nvram contains the right info, but it still won't eat the grub.efi bootloader file. Wonky.
Reply With Quote
  #27  
Old 27th February 2012, 03:33 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: F16 - GRUB2 EFI non-Mac

One thing I noticed about the efibootmgr output is that the two entries have different partition GUIDs -- 166c2d13-514c-4921-9969-5f9e4cfaa823 for the redhat entry and e3ad4b9f-b0e5-431d-9fa7-8e387fceacac for the fedora entry. This probably happened because of partition table changes. I'm not sure if your system would boot if the GUID doesn't match that of your current ESP. You can learn that GUID from gdisk's "i" command or via sgdisk:

Code:
sgdisk -i 1 /dev/sda
This assumes the disk is /dev/sda and the ESP's partition number is 1; change both as necessary. The result is on the "Partition unique GUID" line. If your current disk's ESP has a different GUID than the one for whatever boot loader you're trying to load, it's worth deleting the current entries and creating new ones using efibootmgr.

The fact that you got my rEFIt CD to boot is encouraging, even if it didn't do anything useful. I've got another version up that may provide another step toward a solution, if the GUID issue doesn't lead anywhere:

http://www.rodsbooks.com/efi-bootloa...fit-cd2.iso.gz

Here's an image of what it should look like, for reference, although the first row of icons is likely to differ for you:



To understand this, first note the text on the bottom line -- "Boot EFI\boot\bootx64.efi from" in the figure. This tells you precisely what file rEFIt will try to boot. The text changes when you move over the different icons. Note that rEFIt includes icons for both EFI-style and BIOS-style boots, although the BIOS-style boots only work on Macs, AFAIK.

The first row of icons represent EFI boot loaders or BIOS code that rEFIt thinks it can boot. The icons change depending on the type of OS that rEFIt thinks it's detected. You can move between options to see what you've got, and whether any of them match the files on your ESP. If they don't, that could be a clue -- perhaps there's filesystem damage that's preventing the firmware from reading the file, for instance.

The second row of icons represents non-bootloader actions. The new version of the rEFIt CD I've posted includes a new icon. It's the one on the far left, and the text should change to "Start EFI Shell" when you've selected it. This launches an EFI shell at which you can type commands. It's similar to a DOS prompt or Linux bash shell; you can use it to type commands ("ls", "cd", and so on) and launch programs -- EFI boot loaders. To start, try the following and see what you get:

Code:
fs0:
ls
This shows you what's on the first filesystem, which is probably the ESP. If you get an error or see some other partition's files, try "fs1:" rather than "fs0:". If you see your ESP's files, try:

Code:
cd EFI\fedora
ls
grubx64
This should show you the files in the Fedora boot loader directory and then launch that boot loader. If the files are missing, then that suggests filesystem corruption. If you see an error message, it might be helpful. You can try the same thing with the boot loader in the EFI\redhat directory, of course.

FWIW, the CD image is a stock ISO-9660 image with El Torito support. Put the contents of an ESP in the El Torito image and it's good to go -- but you'll only be able to boot from the EFI\boot\bootx64.efi file. Thus, you can experiment with this yourself, if you know how to create an El Torito image. With any luck, you'll learn something from the EFI shell that will be helpful in getting the disk to boot, but if not, it may be possible to create a bootable CD-R that starts up GRUB directly, rather than going through Super GRUB Disk.

Good luck!

Last edited by srs5694; 27th February 2012 at 03:33 PM. Reason: Fixed error in code tags
Reply With Quote
  #28  
Old 29th February 2012, 07:38 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

So, starting over...
  • Wiped the entire drive with 0x00s, disconnected it, disconnected the power supply, removed the battery, shorted the battery socket contacts with a jumper, and let it sit like that for 8 hours, maybe more.
  • Reconnected the PS, powered up, hit F2. UEFI boot is enabled from the start (which is consistent with the previous time I tried this). Disabled UEFI boot and hit F10 (save and exit), causing reboot.
  • Hit F2 again, checked UEFI boot : enabled again (also like before) -- ie, the setting did not stick.
  • Installed new 64-GB SSD instead of 1-TB HDD (for faster failures ). Verified first and last 10 MB or so of SSD were all 0x00's.
  • Installed using Fedora 16 DVD, default partitioning, local repos only (for speed). Installation successful; on reboot: "No bootable device...".
  • Reset and re-load installation DVD, update existing installation, selected re-install bootloader option. Ran successfully, but on reboot: "No bootable device...".
  • Thought I would try running grub-efi-install manually, but it wasn't present. (2 RPMs starting with "grub" were installed: grubby and grub-efi.)
  • Booted System Rescue CD, mount F16 partitions, chroot, install grub2-efi. yum reported conflicts from grub-efi, so I had to remove that first. (I don't remember having to do that with the previous installation.)
  • Booted F16 install CD and ran grub2-efi-install. Ran successfully, but on reboot: "No bootable device...".
  • Booted F16 install CD again. fsck.vfat reported that the ESP is FAT32. (Previous installation, from CD, created this as FAT16.)
  • Copied EFI/fedora/grubx64.efi to EFI/BOOT/BOOTX64.efi.
  • Used efibootmgr to change from this
    Code:
    BootCurrent: FFFF
    BootOrder: 0002,0001,0000
    Boot0000* Linux HD(1,800,479e000,166c2d13-514c-4921-9969-5f9e4cfaa823)File(\EFI\redhat\grub.efi)
    Boot0001* fedora        HD(1,800,c0000,e3ad4b9f-b0e5-431d-9fa7-8e387fceacac)File(\EFI\fedora\grubx64.efi)
    (ie, it seems 0000 might have been left over from previous installation) to this
    Code:
    BootCurrent: FFFF
    BootOrder: 0001,0002
    Boot0001* fedora        HD(1,800,48c800,20f84020-f248-41cf-8065-93bc43237b17)File(\EFI\fedora\grubx64.efi)
    Boot0002* Linux HD(1,800,48c800,20f84020-f248-41cf-8065-93bc43237b17)File(\EFI\BOOT\BOOTX64.efi)
    Also tried setting a different label for 0002, but it would not take -- immediately echo'd back as "Linux".
    Reboot: "No bootable device...".
  • Booted with Super GRUB2 Disk. It found no GRUB cfg's to boot. (This worked with the previous installation.)
  • Booted refit-cd2. Looked good, but I have only the far left and far right top-row icons (CDs, no HDDs). Clicking them gives same results as with previous version. Clicked on shell icon in bottom row. Screen cleared, after a few seconds got this [entered by hand, sorry for any mistakes]
    Code:
    ASSERT_EFI_ERROR (Status = Not Found)
    ASSERT c:\dev\edk2tip\MdeModulePkg\Library\UefiHiiServicesLib\UefiHiiServicesLib.c(88): !EFI_ERROR (Status)
    No shell prompt -- had to use HW reset from there.

Interesting that the rEFIt CD is standard ISO-9660 with El Torito. I don't have much experience with El Torito, but for my attempt (a couple posts back) I believe I followed the instructions for SYSLINUX. But then I wasn't sure whether SYSLINUX was EFI-aware. How are you adding the El Torito support?

---------- Post added at 01:38 AM ---------- Previous post was at 01:20 AM ----------

Sorry, forgot to give the new partition layout, from the default installation:
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4771839   2.3 GiB     EF00  EFI System Partition
   2         4771840         5795839   500.0 MiB   0700  
   3         5795840       125044735   56.9 GiB    8E00
So a much smaller ESP than previously, though still quite a bit larger than it needs to be.

And current file contents of ESP:
Code:
-rwxr-xr-x   1 root     root       147456 Feb 29 03:31 EFI/BOOT/BOOTX64.efi
-rwxr-xr-x   1 root     root       147456 Feb 29 03:31 EFI/fedora/grubx64.efi
-rwxr-xr-x   1 root     root           64 Feb 28 19:01 EFI/redhat/device.map
-rwxr-xr-x   1 root     root           64 Feb 28 14:48 EFI/redhat/device.map.anacbak
-rwxr-xr-x   1 root     root          771 Feb 28 19:01 EFI/redhat/grub.conf
-rwxr-xr-x   1 root     root          771 Feb 28 14:48 EFI/redhat/grub.conf.anacbak
-rwxr-xr-x   1 root     root       680960 Dec  9 17:38 EFI/redhat/grub.efi
Reply With Quote
  #29  
Old 29th February 2012, 03:37 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: F16 - GRUB2 EFI non-Mac

Comments and observations about your latest attempt:
  • Have you tried flashing a new firmware image? Even if it's the same version you're running now, that might improve matters if your firmware has become damaged in some way.
  • Going a bit further, if the board has a socketed EEPROM chip, you could replace it with a new one in case it's become physically damaged.
  • The failure to launch the shell from rEFIt suggests a very serious error. I don't recognize the error message you got, but it makes me think your firmware has become corrupted. That's a very tentative conclusion, though.
  • I've posted a new version of my rEFIt boot CD. There's now a download link at http://www.rodsbooks.com/efi-bootloaders/refit.html. It differs in a couple of ways from the version you've got, one of which might conceivably produce better boot options, although I'm not very hopeful about that.
  • See this page for information on creating EFI-bootable disks. I'm still working through the details myself, and the images I've created so far include just one image rather than the two (for BIOS and EFI modes) described on that page.
  • Since you are able to boot from the CD in EFI mode, it should be possible to create a bootable CD with a Linux boot loader (GRUB Legacy, GRUB 2, or ELILO) to get your computer booted a little more directly than is possible with Super GRUB Disk.
  • Have you tried booting a USB flash drive in EFI mode? In theory, you can set one up with GPT and an ESP and toss boot loaders on it. If it works, it'd be a little easier to experiment with than a bootable CD.


---------- Post added at 10:37 AM ---------- Previous post was at 10:21 AM ----------

Update: I was going to try preparing a proof-of-concept Linux bootloader CD image, but it might be simpler/better for you to do it yourself:
  1. Create a "scratch" directory and cd into it.
  2. Type "dd if=/dev/zero of=efi.img bs=1048576 count=5". This creates a 5 MiB blank file. Change the file size as necessary.
  3. Type "mkdosfs efi.img" to create a FAT filesystem on the efi.img file.
  4. Type "mount -o loop efi.img /mnt" as root. Change the mount point as desired; but if you do, change it in subsequent commands, too.
  5. Type "cp -R /boot/efi/* /mnt" as root.
  6. Type "umount /mnt" as root.
  7. Type 'mkisofs -U -V "testboot" -volset "testboot x86_64" -J -joliet-long -r -v -T -o ../testboot-cd.iso -eltorito-alt-boot --efi-boot efi.img -no-emul-boot ./'. This should create a bootable CD-R image file, testboot-cd.iso, in the parent directory.
  8. Burn ../testboot-cd.iso to a CD-RW and try it.

With any luck, this disc should boot your Linux installation directly; however, this assumes that the boot loader configuration in your ESP is already correct. If it's not, you'll need to make changes to the ESP, copy the files back into the image file, create a new ISO image file, and burn it again. That's a tedious way to test changes, which is why I suggested trying a USB flash drive -- it's much easier to test changes with it.
Reply With Quote
  #30  
Old 29th February 2012, 06:32 PM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Quote:
Originally posted by srs5694
  • Have you tried flashing a new firmware image? Even if it's the same version you're running now, that might improve matters if your firmware has become damaged in some way.
Good thought. I tried that when I first had problems getting EFI to work, and then noticed that I couldn't revert to BIOS mode, before I even started this thread. At that time I upgraded from the BIOS version I had been using for most of the last 4 years to the latest available for that board, from 2009. Just now I re-installed that latest version, but unfortunately it didn't help.

Quote:
  • Going a bit further, if the board has a socketed EEPROM chip, you could replace it with a new one in case it's become physically damaged.
I don't see any socketed ICs on the board, other than the CPU, of course.

Quote:
  • The failure to launch the shell from rEFIt suggests a very serious error. I don't recognize the error message you got, but it makes me think your firmware has become corrupted. That's a very tentative conclusion, though.
Even though re-flashing it didn't help, I agree it's still entirely possible that BIOS flash, or whatever RAM it uses, or its NV storage area could be faulty. It would be nice if there was a way to test any/all of those.

Quote:
  • I've posted a new version of my rEFIt boot CD. There's now a download link at http://www.rodsbooks.com/efi-bootloaders/refit.html. It differs in a couple of ways from the version you've got, one of which might conceivably produce better boot options, although I'm not very hopeful about that.
Thanks for the new version. This one works basically the same as the "cd2" version, except that there's only 1 big icon in the top row, which just seems to re-launch the rEFIt menu. Same assert error trying to launch the shell.

Quote:
  • Have you tried booting a USB flash drive in EFI mode? In theory, you can set one up with GPT and an ESP and toss boot loaders on it. If it works, it'd be a little easier to experiment with than a bootable CD.
I did try it once or twice, not only because I thought it should be a lot easier and faster to try experiments, but also because it's probably a more appealing long-term solution if I can't get normal booting from firmware to work. It's faster of course, hopefully more reliable (sometimes it takes a couple tries to get the firmware to see a CD), and I could just leave a small flash drive plugged into one of the back-panel USB ports, rather than having to fiddle with CDs. My earlier experiments didn't work -- well, I did manage to elicit some other error besides the good ol' "No bootable device" -- but I wasn't sure exactly what the firmware would be looking for on a USB drive (and there's at least one option about handling of USB storage, which also no longer sticks), so I decided not to introduce yet another variable into this mess until I understood what was going on. I'm certainly willing to try again though. I assume it should work (with sane firmware) to simply put a GPT with a single FAT32 ESP directly on the USB drive...?

Thanks very much for the info about creating bootable CDs! I will give this a try later. Which version of mkisofs are you using? I don't see the "-efi-boot" option in the man page on Fedora 14, but it's there in the F16 installation -- yet both executables claim to be the same version: genisoimage 1.1.11 (Linux). OTOH the RPM packages do have different suffixes...

---------- Post added at 12:32 PM ---------- Previous post was at 12:26 PM ----------

Oh, another question: Do we know whether either the redhat or fedora .efi bootloaders are supposed to have config files with them? It seems the GRUB Legacy and GRUB2 installers don't create any. So far it's been kind of an academic question for me since I don't seem to be getting that far, but if I try again with a USB drive, it would be good to know...
Reply With Quote
Reply

Tags
efi, f16, grub2, nonmac

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Grub2 glennzo Using Fedora 14 19th September 2012 12:39 AM
F16 and grub2 drnetsys F16 Development 1 7th October 2011 04:03 AM
[SOLVED] Help with GRUB2/MBR, Please sharp Using Fedora 0 26th July 2011 03:06 PM
Help with grub2 JamesNZ Using Fedora 1 9th November 2010 02:54 AM
Grub2 Help dhess31 Installation, Upgrades and Live Media 5 30th May 2010 05:06 PM


Current GMT-time: 08:11 (Monday, 22-09-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat