Fedora Linux Support Community & Resources Center
  #1  
Old 6th February 2012, 10:02 PM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
F16 - GRUB2 EFI non-Mac

Apologies if this has been answered elsewhere, but what's the current status on GRUB2 for non-Mac x86 32 and 64-bit computers with [U]EFI boot, using latest Fedora 16 repos (ie, from network install using 64-bit minimal boot CD)? Should I be spending time trying to get this to work, or is GRUB1 (Legacy) still the way to go at this time? This is my first attempt at EFI booting, and various posts here and other Google hits seem a bit contradictory, or perhaps just out of date -- some of what I've read indicates that improvements have made during the last few months, during the F16 release and maybe later..?

A few details:
  • mainboard: Intel DP35DP, BIOS ver 0572 (2009-07-16) set for EFI and AHCI
  • CPU: Core2 Duo E4600
  • disc: Seagate ST31000528AS (1 TB SATA2)

Thanks
Don
Reply With Quote
  #2  
Old 7th February 2012, 02:57 PM
fpmurphy Offline
Registered User
 
Join Date: May 2009
Location: /dev/ph
Posts: 313
windows_7firefox
Re: F16 - GRUB2 EFI non-Mac

Short answer - it works. Longer answer - you may or may not be able to get it working; it all depends on your level of expertise. The EFI implementations on many of the older Intel motherboards is interestingly different. The workaround is to make the partition bootable.
Reply With Quote
  #3  
Old 7th February 2012, 06:18 PM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 969
macoschrome
Re: F16 - GRUB2 EFI non-Mac

AFAIK, Fedora Project / RH, are still using their GRUB Legacy EFI derivative including in Rawhide and F17. Certainly that is the case for F16.

So it's a question of whether GRUB Legacy EFI or GRUB2 EFI works better for your hardware. If equal, then it probably makes more sense to take the plunge to GRUB2 EFI since it's consistent with upstream and other distros. But for me it was a painful learning curve. There are in effect four GRUBs...and they each have their own peculiarities.
Reply With Quote
  #4  
Old 7th February 2012, 08:17 PM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfirefox
Re: F16 - GRUB2 EFI non-Mac

Thanks (to both murphys)... Right now my situation is that neither GRUB Legacy nor GRUB2 seem to be doing the trick for me with EFI. I figured I would have to dive into one of them, and as you say, I thought it might make more sense to spend (er, invest) the time on GRUB2 -- unless it's known not to work.

Initially I was trying to use a custom partition layout with multiple discs, but in order to make it easier to explain, and to reduce variables, I've unplugged all but the one HDD, wiped the entire thing with 0x00s (using dd), and used the installer's default partitioning. The installation goes fine until the end, when I get a dialog which says:

Quote:
Warning
There was an error installing the bootloader.
The system may not be bootable.
(FWIW, I haven't seen this warning when using custom partitioning.)
The only interesting thing I see on any of the virtual console screens is this:

Code:
ERR kernel:[ 8420.344447] efivars: DataSize & Atrributes must be valid!
And indeed the system is not bootable -- the BIOS displays:

Code:
No bootable device -- insert boot disk and press any key
Using gdisk on SystemRescueCD, I see ESP and boot partitions have been created (and apparently the boot partition is the wrong type):

Code:
% gdisk -l /dev/sda
. . .
Found valid GPT with protective MBR; using GPT.
. . .
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        75098111   35.8 GiB    EF00  EFI System Partition
   2        75098112        76122111   500.0 MiB   0700  
   3        76122112      1953523711   895.2 GiB   8E00
I mounted the root, boot, and EFI system partitions (chroot'd in the rescue system) and I see the ESP contains just one file:

Code:
# find /boot/efi ! -type d
/boot/efi/EFI/redhat/grub.efi
@fpmurphy: When you say "make the partition bootable", I assume you mean the ESP... From what I can see, gdisk doesn't use that terminology but parted does:

Code:
# parted -l /dev/sda
. . .
Partition Table: gpt

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  38.5GB  38.4GB  fat32        EFI System Partition  boot
 2      38.5GB  39.0GB  524MB   ext4
 3      39.0GB  1000GB  961GB                                      lvm
. . .
If you have any ideas from this, please let me know. Otherwise I'll have a closer look at GRUB2 docs and see if I can install it manually from here. I made a half-hearted attempt earlier (with the custom partitioning) which didn't work, but now that I know it "should", I might try a little harder.
Reply With Quote
  #5  
Old 7th February 2012, 08:33 PM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 969
macoschrome
Re: F16 - GRUB2 EFI non-Mac

A very sketchy area of (U)EFI implementations is how to present boot options to the user. My understanding of the UEFI spec is that there is a default bootloader that must be honored by default if present, and that's
EFI(systempartition)//EFI/BOOT/BOOTX64.efi

If not present, then it appears entirely up to your computer's UEFI implementation to decide whether to present other bootloaders or not at all, including total boot failure. This seems moronic, but it appears to be really common.

Fedora installs the grub.efi bootloader in:
EFI//EFI/redhat/grub.efi

(pretty sure that's right...close anyway, and might be different between legacy and grub2).

So in every case (on Apple hardware), I've had to create a BOOT folder, and copy/rename grub.efi to BOOTX64.efi.

Now, maybe your UEFI implementation has a key command at boot time to bring up a menu from which it will then be compelled to look in EFI//EFI/* and present options to you. Apple hardware does not have such a GUI feature, it does have a "bless" command that can be used to place a pointer in NVRAM to bootloaders in pretty much any location.

---------- Post added at 01:33 PM ---------- Previous post was at 01:25 PM ----------

So what you need to do first is see if your UEFI implementation has any user interactivity options to choose a bootloader, and see if it finds grub when you do that. If you don't have an interactivity with your UEFI implementation then you probably will need to do something like this:

start off a liveCD
mkdir /mnt/efi
mount -t vfat /dev/sda1 /mnt/efi
cd /mnt/efi/EFI/
ls -l

Then you'll see what folders you have and figure out where the grub bootloader is, create a /mnt/efi/EFI/BOOT folder and inside of that put grub.efi renamed as BOOTX64.efi.

Now another problem I've had that's confusing and I'm not totally sure I understand, is I think that BOOTX64.efi has the location of grub.cfg baked into it. So I've had problems where doing the above causes GRUB2 to be found but since it can't find /boot/grub2 where all of the GRUB2 modules and grub.cfg are located, it comes up in rescue mode.

If that happens to you post back. There are a couple of ways to skin that cat. One is to use some rescue commands to get GRUB back into normal mode, and load grub.cfg - then once you're live booted off your actual install, to have grub2-efi-install create a new grub.efi, which then should be used to replace the one that isn't working.

It's fakaked. It should not be this difficult. It pisses me off beyond belief that we get a new BIOS paradigm and it's this f'n user hostile, apparently by design.
Reply With Quote
  #6  
Old 8th February 2012, 05:51 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfirefox
Re: F16 - GRUB2 EFI non-Mac

Thanks for your suggestions!

The only mention of EFI I see in the BIOS system setup screens is one item on the "Boot" page called "UEFI boot", and that's either enabled or disabled[1]. I haven't seen any other options that seem related to a choice of things to boot. 'Course I could always be missing something obvious.

Your suggestion of copying (EFI-partition)/EFI/redhat/grub.efi to the default (EFI-partition)/EFI/BOOT/BOOTX64.efi seemed promising (and consistent with other things I've read), but unfortunately it didn't change the behavior -- it still stops with "No bootable device". It doesn't seem to be the issue you mentioned with the canned-in config file path -- I don't think it's getting that far.

I also found some interesting reading, by Rod Smith, the author of gdisk. In his opinion (as of last September), ELILO might be the easiest to get working. However, if I'm interpreting the single error message from my BIOS correctly, the BL is not even being found yet, so I'm thinking ELILO vs GRUB(1) vs GRUB2 might be kind of moot at this point.

Back on the topic of choosing bootloaders, I got kind of excited when I read about using efibootmgr to manipulate boot manager settings, but unfortunately when I run it [from the rescue CD env, which I'm using to write this; I will try again from the Fedora install CD when I'm done here], I get this

Code:
# efibootmgr
Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.
"modprobe efivars" runs without complaint but I don't see it in lsmod's output after that, and it doesn't help efibootmgr at all. (I think I remember seeing complaints from grub2-efi-install about efibootmgr failing, back when I tried that, and that was with the Fedora install env.)

I also tried looking through release notes and other Intel docs for this board for clues about what EFI release my BIOS was intended to be compliant with. No luck there either. I was thinking that perhaps 2009 BIOS vintage might be too early to expect functional/compliant EFI booting(?).

I agree -- I wouldn't have thought this would be so difficult...

----------------
[1] - In my case, UEFI boot is essentially permanently enabled now. This machine ran Fedora 8 for over 4 years with it disabled, but for the F16 installation I decided to try enabling it, which one could say got me into this mess. Since then changes to a number of BIOS settings, including this one, do not stick after rebooting. The battery voltage seems fine (3.2 V), and removing it reset the time-of-day clock but didn't help otherwise.
Reply With Quote
  #7  
Old 8th February 2012, 06:29 AM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 969
macoschrome
Re: F16 - GRUB2 EFI non-Mac

I assume you've looked at all of this:
http://www.intel.com/support/motherb...780.htm#splash

You might dig around for shellx64.efi and drop that into the root directory of the EFI System Partition and see if you get an EFI shell. There are links to various shells and how to use them here:
https://wiki.archlinux.org/index.php...Shell_Commands

I'd bet that it's UEFI 2.x compliant. I think you're just going to have to work through some things to find out what it wants and maybe you can get some Intel email support or something. It should work.

---------- Post added at 11:29 PM ---------- Previous post was at 11:28 PM ----------

And if it doesn't work, you can punt and disable UEFI support and just make it a BIOS install. It does somewhat limit the hardware's capability, but I doubt it makes it noticeably slower or anything (maybe some limited power management support, slower initial boot time, limits on disk sizes, etc).
Reply With Quote
  #8  
Old 8th February 2012, 06:42 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Ahh right, thanks, I'd forgotten about that jumper... I'll try that tomorrow if I get some time.

I had seen the EFI shell mentioned before, but hadn't figured out whether it was something built in to some EFI implementations or a separate executable. Thanks for that link too.

In the FWIW dep't...
Seems I was wrong, or something changed: I just tried running efibootmgr under the F16 minimal install CD, and it ran fine. So I tried

Code:
efibootmgr -c -l \\EFI\\redhat\\grub.efi
which added a "Boot0000*" entry [this is from memory, so may not be quite right] to the output that wasn't there before. Again I got excited that I might have stumbled into goodness, but the result is still the same: "No bootable device".

I'll update if I get anywhere with this. It may be a couple days before I can come back to it.

Last edited by Don3; 8th February 2012 at 06:48 AM. Reason: messed up EFI path
Reply With Quote
  #9  
Old 8th February 2012, 07:03 AM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 969
macoschrome
Re: F16 - GRUB2 EFI non-Mac

I'm pretty sure you don't need to interact with efibootmgr directly. I think grub2-efi-install does that for you as part of its various scripts.

---------- Post added 8th February 2012 at 12:03 AM ---------- Previous post was 7th February 2012 at 11:58 PM ----------

The gotcha is that it's less than obvious how to get it to install on a disk other than the boot disk. Whenever I tried to use the flag that points it to another disk, I get errors about /sys and /proc.

So what I did was boot from F16 DVD EFI, and by the way by virtue of booting off the DVD you must've gotten an EFI boot to work! Anyway, from the F16 boot menu find troubleshooting then choose the rescue option in the next menu. Then wait. Then go through the menus, you don't need to activate network, do let it look for installations and pretty much choose the default options each time I think. At the end get to a shell where it's already mounted everythign for you at /mnt/sysimage. Then you just do a chroot /mnt/sysimage.
Then if you do grub2-efi-install --no-floppy --recheck /dev/sda

It should work. You might still need to go find grub.efi on the EFI partition and rename and relocate it (again).
Reply With Quote
  #10  
Old 8th February 2012, 03:58 PM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Quote:
...by virtue of booting off the DVD you must've gotten an EFI boot to work
Hmm, interesting. Actually I've been using the net-install CD (not a DVD), but still interesting. That's been working all along -- er, well, it's a bit flaky (on some boots it doesn't realize the CD is in the drive, and if I'm not mistaken it sometimes gives a console text menu instead of the "prettier" one), but basically it's been working all along. I had assumed it was just because the optical drive is first in the boot order on the Boot page of the BIOS setup screen. Hadn't occurred to me EFI would be involved there too -- I guess I just took it for granted that it was still working from before, when EFI boot was disabled.

OK, I will try downloading the install DVD and give that a shot. And I still need to try the previous things -- the BIOS config jumper and trying to boot into the EFI shell. Unfortunately I may not have much time available to work on this in the next couple days, we'll see...

Thanks!
Reply With Quote
  #11  
Old 20th February 2012, 06:23 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

Well, turned out I was busy for a lot longer than I expected. I'll try to summarize the results from the things I've tried in the last week or so, going back over your suggestions. I've probably forgotten a few things by now too.
  • Following Intel's documentation, I moved the BIOS config jumper to the "configure"position, hoping there might be some extended EFI boot parameters that could be viewed and changed. It did add some some extra config parameters, but nothing to do with EFI.
  • I copied a BIOS recovery file to a USB flash drive (I assume they mean with a FAT file system on the drive), removing the BIOS config jumper and booting. No sign of activity - LED on flash drive stays off, no video output, nothing. Waited well beyond the 2-5 minutes quoted, and tried several times.
  • Replaced BIOS config jumper in "normal" position. Back to previous behaviour -- EFI boot setting still seems to be permanantly enabled, and it still finds "No bootable device".
  • Tried pressing F10 at boot time, which presents a menu of boot devices (I hadn't realized that before), outside the BIOS setup screens. Tried each one in turn, but none (except possibly the CD/DVD drive) do anything. In fact, when I tried the hard drive entry, it not only didn't boot, but it disappeared from the list.
  • Downloaded the full F16 install DVD. As with the minimal boot CD, the DVD's boot menu has only one choice, "Fedora 16", so I took that and ran through an "upgrade" installation. It seems to have recognized that there was nothing to do, but offered to install the bootloader. All looked well until the end when a dialog announced that the bootloader installation had failed and the machine might be unbootable. (I don't have the exact text, sorry - I can re-run it if it's important.) At that point I did Alt+Ctrl+F2, then chroot'ed to /mnt/sysimage as you suggested. Unfortunately grub2-efi-install is not on the search path, so I couldn't run it. (No programs starting with "grub2", in fact.) The un-chroot'd system has grub2 programs in /sbin, but not grub2-efi-install. I was hoping I could do yum install inside the chroot'd system, but the network is not set up at that point.
  • Following instructions here I copied thex86_64 UEFI Shell 1.0 onto a USB flash drive, booted, pressed F10, selected the flash drive and got "Invalid system disk".
  • I thought perhaps there might be an ISO or something available that the system could boot from CD or flash drive, by whatever mechanism it's able to boot from some CD/DVDs now, that would then boot from the HDD in EFI mode -- basically substituting for my BIOS. rEFIt sounded semi-promising for that -- I wasn't sure whether it was only for Intel Macs -- but when I wrote their "cdr" image to a CD and tried to boot, I still got "No bootable device".

FWIW, here is what I currently have in the ESP from the installation (and possibly with some fiddling from my experiments):

Code:
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/BOOT/BOOT-64.efi
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/microsoft/IA64LDR.efi
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/microsoft/boot/IA64LDR.efi
-rw-r--r--   1 root     root           64 Feb 19 22:33 EFI/redhat/device.map
-rw-r--r--   1 root     root           64 Feb 19 19:24 EFI/redhat/device.map.anacbak
-rw-r--r--   1 root     root          442 Feb 19 22:33 EFI/redhat/grub.conf
-rw-r--r--   1 root     root          442 Feb 19 19:24 EFI/redhat/grub.conf.anacbak
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/redhat/grub.efi
I thought about writing to Intel to ask what I'm missing here, but my board is past EOL.

Last edited by Don3; 20th February 2012 at 03:41 PM. Reason: Fixed shell URL; added rEFIt reference; sorted file list.
Reply With Quote
  #12  
Old 23rd February 2012, 07:19 AM
Don3 Offline
Registered User
 
Join Date: Aug 2009
Posts: 29
linuxfedorafirefox
Re: F16 - GRUB2 EFI non-Mac

So having pretty much given up on getting EFI boot to work on this board, and as it seems I can't go back to MBR boot since the necessary BIOS config settings won't stick any more, I tried one last configuration before springing for a new mainboard + CPU + RAM...

I went [back] to a custom partitioning configuration, using gdisk on SystemRecueCD to set it up. I created a BIOS boot partition and an EFI System Partition (just in case I ever got either one working again) and an ext4 /boot partition, then installed F16 using the network (minimal) CD. After finally getting through the installation successfully, the next boot-up gave me the now-familiar and expected "No bootable device", so I ran SystemRescue CD again, fixed the GUID partition types (see note below), mounted the root, boot partitions under a sub-dir of /mnt, chroot'd into the installation, ran grub2-install (although I may not have needed to do that), then booted with Super GRUB2 Disk and used that to boot the F16 installation from disc. So from here on, it'll be an ugly 2-step boot procedure -- but luckily I rarely need to boot this machine, because it normally runs 24x7.

A few other observations along the way...
  • The Fedora install CD (and I believe DVD as well) starts up in two different ways, seemingly dependent on when the BIOS discovers them. If I insert the CD before the Intel splash screen appears, or possibly when it's first up, I get a menu with a night sky background and only one entry (Fedora 16), as I mentioned in an earlier post. But if I wait to insert the CD until just after the splash screen clears, I first get an interesting menu from the BIOS (see footnote [4] here; selecting '1', I get a text-mode boot menu that has more options, including "troubleshooting", which you mentioned earlier.
  • It seems the text mode installer has an issue with existing LUKS encrypted partitions. It prompts for a passphrase but is never satisfied with the answer -- no complaints, but it just continually prompts for the passphrase on the same partition. The graphical installer works fine in this regard.
  • After carefully setting GUID partition types to what I thought they were supposed to be using gdisk, and then running the Fedora installer, I discovered that the installer had changed many of the partition types to, umm, different values. I didn't write them all down, but in one case, I had used 8300 (Linux filesystem) for the ext4 /boot partition, but the installer changed it to 0700 (Microsoft basic data).
  • Over the course of this adventure, I had tried different combinations of BIOS boot and EFI system partitions, "enabling" or "disabling" them by changing their GUID partition types (I figured changing them to a type like swap should effectively disable them), and/or selecting them or not in the GUI installer's partitioning screen. I found that the installer crashes with at least one combination (and with the BIOS set for EFI boot), but unfortunately I don't remember which one now. (My enthusiasm for careful note-taking decreased as the frustration level increased...) Having been through this, I'm thinking it would be really nice if the installer said what it was trying to do bootloader-wise, and possibly even give an "advanced" config screen. Also would be nice if the install CDs/DVDs included gdisk.

Last edited by Don3; 23rd February 2012 at 07:21 AM. Reason: missed a couple words
Reply With Quote
  #13  
Old 23rd February 2012, 06:37 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
  • Downloaded the full F16 install DVD. As with the minimal boot CD, the DVD's boot menu has only one choice, "Fedora 16", so I took that and ran through an "upgrade" installation. It seems to have recognized that there was nothing to do, but offered to install the bootloader. All looked well until the end when a dialog announced that the bootloader installation had failed and the machine might be unbootable. (I don't have the exact text, sorry - I can re-run it if it's important.) At that point I did Alt+Ctrl+F2, then chroot'ed to /mnt/sysimage as you suggested. Unfortunately grub2-efi-install is not on the search path, so I couldn't run it. (No programs starting with "grub2", in fact.) The un-chroot'd system has grub2 programs in /sbin, but not grub2-efi-install. I was hoping I could do yum install inside the chroot'd system, but the network is not set up at that point.
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. You could have a look for them....

Quote:
  • I thought perhaps there might be an ISO or something available that the system could boot from CD or flash drive, by whatever mechanism it's able to boot from some CD/DVDs now, that would then boot from the HDD in EFI mode -- basically substituting for my BIOS. rEFIt sounded semi-promising for that -- I wasn't sure whether it was only for Intel Macs -- but when I wrote their "cdr" image to a CD and tried to boot, I still got "No bootable device".
rEFIt can help cut through some problems with getting EFI boot loaders recognized, but it's a chicken-and-egg sort of problem -- rEFIt is basically just another boot loader, so you've got to get it recognized before it will help you load other boot loaders. Also, the version on the main rEFIt site you referenced won't work on UEFI PCs; that version uses a "fat" binary format (32-/64-bit) that works only on Macs. You can find a 64-bit-only version on my Web page on the topic.

Quote:
FWIW, here is what I currently have in the ESP from the installation (and possibly with some fiddling from my experiments):

Code:
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/BOOT/BOOT-64.efi
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/microsoft/IA64LDR.efi
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/microsoft/boot/IA64LDR.efi
-rw-r--r--   1 root     root           64 Feb 19 22:33 EFI/redhat/device.map
-rw-r--r--   1 root     root           64 Feb 19 19:24 EFI/redhat/device.map.anacbak
-rw-r--r--   1 root     root          442 Feb 19 22:33 EFI/redhat/grub.conf
-rw-r--r--   1 root     root          442 Feb 19 19:24 EFI/redhat/grub.conf.anacbak
-rw-r--r--   1 root     root       338312 Oct 26 22:29 EFI/redhat/grub.efi
I realize you said you started fresh in your next post, but instead of that first file, if you name a boot loader EFI/BOOT/BOOTX64.EFI (note: BOOTX64.EFI, not BOOT-64.EFI; case-insensitive), you should get something to begin booting. That's the default name for an EFI boot loader. Adding a boot loader to the EFI's list with efibootmgr should theoretically work, but in practice it sometimes doesn't.

Another point: Some boot loaders require configuration files in their main directories -- EFI/BOOT if you use the name I've just specified. For GRUB Legacy, the name is the same as the boot loader's binary file, but with a .CONF extension, so it would be BOOTX64.CONF if you use the default location and filename. Most other boot loaders use a fixed name, such as elilo.conf for ELILO, no matter what its binary is called.

EFI is supposed to make boot loader installation and maintenance easier, and in some cases it does. Unfortunately, some EFI implementations don't work the way they're supposed to work (or maybe efibootmgr is broken). Many EFI developers are stingy with boot loader options in their user interfaces, which makes it hard to get things running and harder for knowledgeable people to help others, since the options vary so much from one implementation to another.

Quote:
  • The Fedora install CD (and I believe DVD as well) starts up in two different ways, seemingly dependent on when the BIOS discovers them. If I insert the CD before the Intel splash screen appears, or possibly when it's first up, I get a menu with a night sky background and only one entry (Fedora 16), as I mentioned in an earlier post. But if I wait to insert the CD until just after the splash screen clears, I first get an interesting menu from the BIOS (see footnote [4] here; selecting '1', I get a text-mode boot menu that has more options, including "troubleshooting", which you mentioned earlier.
You're probably seeing the difference between BIOS-mode and EFI-mode booting. IIRC, In BIOS mode, the Fedora installer uses the ISOLINUX boot loader, which is a BIOS-mode boot loader for optical discs. In EFI mode, OTOH, Fedora uses GRUB Legacy to boot its installer, since GRUB Legacy works fine on optical discs in EFI mode. This results in different boot-time menus and different options.

Note that the mode in which you boot affects whether efibootmgr will work at all; if you boot in BIOS mode, it won't work. For efibootmgr to be useful, you must boot in EFI mode.

Quote:
  • After carefully setting GUID partition types to what I thought they were supposed to be using gdisk, and then running the Fedora installer, I discovered that the installer had changed many of the partition types to, umm, different values. I didn't write them all down, but in one case, I had used 8300 (Linux filesystem) for the ext4 /boot partition, but the installer changed it to 0700 (Microsoft basic data).
The gdisk 0x8300 code is a new Linux-specific type code that's not yet implemented by libparted, upon which the Fedora installer's partitioner is based. Thus, it'll get changed to what gdisk calls 0x0700, which is what Linux has traditionally used. This isn't a big deal for a Linux-only installation, since Linux ignores partition type codes for most purposes. If you're dual-booting with Windows, though, you'll want to change the type code of Linux filesystems after installing. If you don't, your Linux filesystem partition(s) will show up as unformatted disks in the Windows file manager, making it way too easy to trash your Linux installation from Windows. I've written a Web page on this topic.

FWIW, the parted developers have had a patch for months, and have said it would be incorporated into parted, but they've been inexplicably slow to do this. I've filed a bug report with Fedora, at https://bugzilla.redhat.com/show_bug.cgi?id=795206, so there's a chance that this patch will be added to the parted that ships with Fedora 17.
Reply With Quote
  #14  
Old 23rd February 2012, 06:50 PM
chrismurphy Offline
Registered User
 
Join Date: May 2010
Posts: 969
macoschrome
Re: F16 - GRUB2 EFI non-Mac

Re: comment #11 19th February 2012, 11:23 PM

I find the .efi file sizes and dates suspicious. I don't know why all of these boot loaders are the exact same size. Anyway, I agree with Rod that BOOT-64.efi isn't going to work. I'd remove that, whatever it is, and copy grub.efi and grub.conf to /EFI/BOOT/ as BOOTX64.efi and BOOTX64.conf *and* grub.conf. I've variably found one or the other to work, and now I just do both. It wouldn't surprise me if the filename is baked into grub.efi and I'm confused because of the differences in how GRUB Legacy EFI and GRUB2 EFI work.*

Note that Fedora 16/17 are using Grub Legacy EFI, whereas for BIOS installations they use GRUB2. It's almost like insufflating sriracha.
Reply With Quote
  #15  
Old 23rd February 2012, 07:28 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: F16 - GRUB2 EFI non-Mac

I hadn't noticed that the file sizes and dates are identical. That's probably the result of manual copying of files in an effort to get something to work.

FWIW, another thing I hadn't noticed on the first pass: The IA64LDR.efi filename sounds like it's for an Itanium CPU. On my UEFI Windows installation, the Windows boot loader is called BOOTMGFW.EFI. My suspicion is you copied another boot loader to this name based on some documentation that was intended for Itanium systems. If so, you should just delete the whole EFI/microsoft directory tree; it's worse than useless, since it can only result in confusion.
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: 00:50 (Thursday, 17-04-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