Fedora Linux Support Community & Resources Center
  #1  
Old 7th June 2012, 05:25 AM
Fewmets Offline
Registered User
 
Join Date: Sep 2011
Location: Edmonton Alberta Canada
Posts: 54
windows_7firefox
UEFI install hangs after initrd

I am trying to do a fresh install of Fedora 17 on my G73SW laptop, as there are a number of problems I had after upgrading 15 to 16 and I'm hoping a clean install of 17 will work better.

My problem is that when I load the disk in UEFI mode I get the grub window and no matter which of the options I choose (Fedora 17 or test disk and Fedora 17) it puts up text saying it's allocating a certain number of pages, says it was successful, says it loads linux-efi, and then lists the initrd load information indented and freezes. The disk continues spinning for a minute or so but I don't believe it's actually reading, just idling.

Looking around I noticed that there was a problem with install freezing with a GeForce 580 and although my computer has a 460M card I tried nouveau.noaccel=1 anyways just to be sure. It didn't help.

My understanding is that UEFI is superior to a standard install which is why I've been trying to do this (my 15 and 16 installs were non-efi because I installed F15 on my old laptop and just transferred the hard drive). I know that it uses GPT instead of MBR enabling larger drives (although I don't understand why BIOS couldn't use GPT), but I'm not really sure what other benefits it offers or even why everyone is so excited over it.

Does anyone have any ideas what might be going wrong, or can you recommend me what boot parameters might give me more detailed information about what's going wrong? Also if you don't mind can someone briefly explain how exactly EFI is beneficial over a standard BIOS firmware interface, or if it's even worth my trouble?

Thank you in advance for any help.
Reply With Quote
  #2  
Old 7th June 2012, 08:20 AM
george_toolan Offline
Registered User
 
Join Date: Dec 2006
Posts: 2,079
linuxfirefox
Re: UEFI install hangs after initrd

Because BIOS doesn't know what a GPT is ;-)

The only advantage of an UEFI/GPT install is that the boot drive can be larger than 2 TiB. Your notebook drive probably isn't that large.

Try to install in BIOS compatibility mode.
Reply With Quote
  #3  
Old 7th June 2012, 06:51 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI install hangs after initrd

I'm going to rearrange your post and that of george_toolan, to answer out of order, so as to get the theoretical/background stuff out first....

Quote:
Originally Posted by Fewmets View Post
My understanding is that UEFI is superior to a standard install which is why I've been trying to do this (my 15 and 16 installs were non-efi because I installed F15 on my old laptop and just transferred the hard drive). I know that it uses GPT instead of MBR enabling larger drives (although I don't understand why BIOS couldn't use GPT), but I'm not really sure what other benefits it offers or even why everyone is so excited over it.
BIOS is a 30-year-old technology that relies on 16-bit code and decidedly primitive ways of doing things. For instance, to boot BIOS reads the first sector of the hard disk and executes its code. This means that the computer is held hostage to whatever writes code to that location, and you need tools to do raw low-level disk access to change your boot loader.

For the most part, BIOS's limitations are unimportant, but switching to another system (such as EFI) enables speeding up the boot process, moving boot loaders into regular files rather than code splatted as binary blobs into partitions, and adding new features (mostly of interest to developers, but some of which will impact users, such as Secure Boot). I haven't seen this confirmed anywhere, but I have a sneaking suspicion that Intel is big on EFI because it will eventually enable them to remove all that old 16-bit circuitry from their chips.

As a practical matter, you're unlikely to see any huge day-to-day difference in how your computer works because of EFI, once everything is working correctly. What you will see are changes to the way boot loaders work and are configured. Some (but not all) EFI implementations include a graphical interface to the firmware, which is nice eye candy, but it's not really central to what EFI is. Such an interface could be developed for a legacy BIOS (and I hear that some have been developed in the past, but they never caught on). Secure Boot is a controversial topic, particularly in the Linux community, because it could become something that will cause significant problems for us; but OTOH, it could have some beneficial effect in controlling certain types of malware. (Note that Secure Boot is just one EFI feature, and it's a new one. Few or no shipping computers support Secure Boot, as of mid-2012.)

Quote:
Originally Posted by george_toolan
Because BIOS doesn't know what a GPT is ;-)
That's unimportant. Most BIOS-based computers can boot fine from GPT. Remember, the BIOS is 30 years old; it's old enough that it doesn't even understand MBR partitions! All the BIOS needs to do is to load the first sector of the hard disk and execute the code it contains. That code may parse the partition table in a minimal way, but even that can be put off until later with some boot loaders.

That said, there are buggy BIOSes that do try to parse the partition table and that sometimes refuse to boot GPT disks as a result. There are usually ways around this problem.

Quote:
Originally Posted by george_toolan
The only advantage of an UEFI/GPT install is that the boot drive can be larger than 2 TiB. Your notebook drive probably isn't that large.
The advantages of EFI and the advantages of GPT are largely different, and there are advantages to both other than support for >2TiB disks. In the case of EFI, these include a faster boot process, a saner boot process that uses files rather than dumping raw code in weird places on the disk, GUI firmware interfaces (which as I've said could be done with BIOS, but in practice aren't), and runtime services that provide some modest advantages to a running system (mostly of interest to programmers, such as an ability to store system crash data in NVRAM). Advantages of GPT over MBR include >2TiB disk support, CRCs to detect corruption, backups of important data to help recover from some types of partitioning errors, the elimination of the primary/extended/logical partition distinctions, and UTF-16 partition labels to help identify partitions' purposes.

Quote:
Originally Posted by george_toolan
Try to install in BIOS compatibility mode.
This is a possibility; however, before deciding on the boot mode, it's important to know how the system is currently being used. Most importantly, is Windows installed? The reason is that it's difficult to switch Windows from booting in BIOS mode to booting in EFI mode or vice-versa, so if Windows is installed, it's almost certainly easiest to install Fedora to boot in the same way (or, even if you install in the other way, to switch Linux to boot in the same way Windows does).

[quoteFewmets;1582655]My problem is that when I load the disk in UEFI mode I get the grub window and no matter which of the options I choose (Fedora 17 or test disk and Fedora 17) it puts up text saying it's allocating a certain number of pages, says it was successful, says it loads linux-efi, and then lists the initrd load information indented and freezes. The disk continues spinning for a minute or so but I don't believe it's actually reading, just idling.[/quote]

Are you seeing actual kernel messages during this process, or just pre-boot messages from GRUB? If the former, it sounds like a kernel problem; perhaps there's a bug in Fedora 17's kernel that's causing it to fail on your hardware.

If all you're seeing is the GRUB screen and GRUB messages, then switching boot loaders may help. I'm guessing that Fedora 17 ships with a kernel that includes an EFI stub loader, so you could try using it directly:
  1. Prepare your hard disk with an EFI System Partition (ESP), if it doesn't already have one.
  2. Mount the ESP somewhere convenient.
  3. Copy the kernel and initial RAM disk from the Fedora 17 install disc's images/pxeboot directory onto the root directory of the ESP, but rename the kernel file so that it has an ".efi" extension. For instance, if the ESP is mounted at /boot/efi, you'll end up with /boot/efi/vmlinuz.efi and /boot/efi/initrd.img.
  4. Check the GRUB configuration files to figure out what options it's passing to the kernel. Write them down. (On my Fedora 17 desktop CD, they're "root=live:CDLABEL=Fedora\x2017\x20x86_64", as specified in the EFI/BOOT/BOOTX64.conf file on the CD.)
  5. Download the CD version of my rEFInd boot manager. (You can forego this step if you can already get into an EFI shell.)
  6. Boot the rEFInd CD and, when rEFInd appears, launch a shell. (Alternatively, launch a shell in whatever way you can now.)
  7. Type "fs0:" to switch to the ESP. (You may need to change the filesystem number, depending on how your disk is laid out and whether your EFI gives the El Torito and/or ISO-9660 filesystems on the CD drive numbers before the hard disk's ESP.)
  8. Change to the directory in which you stored your kernel.
  9. Type "vmlinuz root=live:CDLABEL=Fedora\x2017\x20x86_64 initrd=initrd.img", changing the options if they're different from the ones I found on my disc. Note the addition of the "initrd=initrd.img" option, which identifies the initial RAM disk to the kernel.

At this point, the kernel should boot and start the installer. If you continue to have problems you can either try to find an error (such as a typo) or look for an alternative. For instance, you could try using ELILO rather than the kernel's stub loader to launch the kernel.

Note that this procedure boots the computer in EFI mode, so you should do this only if you're sure you want to do an EFI-mode install. If a BIOS-mode install is desirable, then finding a way to boot in that way is preferable. You may be able to do this by adjusting firmware options, but details vary greatly from one firmware implementation to another. It may also be possible to force the boot mode by removing the EFI boot files and remastering the CD.
Reply With Quote
  #4  
Old 7th June 2012, 07:26 PM
droidhacker Offline
Registered User
 
Join Date: Oct 2009
Posts: 827
linuxfirefox
Re: UEFI install hangs after initrd

Is that UEFI causing the boot hang then?

I experience the same problem with my brand new Acer AS5560G-SB448. The really weird thing is that it only does that hang *some* of the time... about 50%. The other 50% of the time it boots as expected.

To add insult to injury on that setup though, while trying to track down a problem where it hangs instead of powering off, I did a bios update to it, which of course reset the bios to factory defaults (deleted all the EFI data), so it won't load GRUB now.

It has got to be the most BRAINLESS concept to keep data required for booting strictly in NVRAM rather than loading it off whatever disk MBR you happen to point it at. VERY VERY inconvenient. In the very least, and I think this should easily be able to be implemented at OS level, there needs to be some mechanism to regenerate that EFI data by booting off the disk in the "normal/old" way.

I presume that a normal non-EFI install can be made by booting the install disk with kernel parameter "noefi"?
Reply With Quote
  #5  
Old 7th June 2012, 08:36 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by droidhacker View Post
Is that UEFI causing the boot hang then?
That would be an oversimplification, at best. It could be EFI implementation bugs, a buggy configuration on the boot media, or any number of other issues. They're all related to EFI in one way or another, but saying that EFI (or UEFI) caused the hang is neither precise nor accurate.

Quote:
I experience the same problem with my brand new Acer AS5560G-SB448. The really weird thing is that it only does that hang *some* of the time... about 50%. The other 50% of the time it boots as expected.
That sounds like a bug, possibly interacting with a hardware issue (a timeout on the boot device, for instance; the device spinup time is likely to vary randomly, and it might sometimes exceed the timeout period and sometimes not).

Quote:
It has got to be the most BRAINLESS concept to keep data required for booting strictly in NVRAM rather than loading it off whatever disk MBR you happen to point it at. VERY VERY inconvenient.
Using NVRAM to hold boot data has its advantages. For instance, you can easily install as many boot loaders as you like and, if the firmware's user interface is anything better than abysmal, choose which boot loader to use on a boot-by-boot basis. (Sadly, some EFI implementations have user interfaces that are abysmal and don't give this option, but most at least pass the "abysmal" quality mark.) A level or two above "abysmal," an EFI's user interface should let you select a boot loader even if the NVRAM has been wiped. Sadly, many more fail at this, but some don't.

The ire on this issue should really be directed at the EFI implementations, which tend to have been done without giving adequate thought to the user experience. Many are also quite buggy. Basically, manufacturers put off development effort for too long and are now trying to rush out products that aren't really ready. I expect it'll improve a lot in a year or two, but for the moment we're in for some pain because of this.

Another important point is that long-time PC users are so familiar with the annoyances of the BIOS booting system that they've faded into the background. We know how to fix problems caused by boot code in the MBR being overwritten, or how to chainload from one boot loader to another, or how to create a disk layout with the right mixture of primary and logical partitions to let all our OSes boot. These issues aren't as important, or don't exist at all, on EFI systems. EFI does have its problems, but it at least leaves many of the BIOS problems behind it. Overall, I think EFI will be an improvement in the long run, provided Secure Boot doesn't become too much of a problem.

Quote:
In the very least, and I think this should easily be able to be implemented at OS level, there needs to be some mechanism to regenerate that EFI data by booting off the disk in the "normal/old" way.
This comment is suggesting fitting a square peg into a round hole. There's a much better way to do it: EFI supports a default boot program, which is stored as EFI/Boot/bootx64.efi on the EFI System Partition (ESP), or variants of that name on platforms other than x86-64. If the NVRAM has no valid entries, the EFI will try to boot using that file. The Windows installer places two copies of its boot loader on the disk, one under the usual (for Windows) name of EFI/Microsoft/Boot/bootmgfw.efi and the other as EFI/Boot/bootx64.efi. This way, Windows will continue to boot even if the NVRAM has been wiped. Linux installers could do something similar. One problem with this approach is that it sets up a potential for between-OS competition over this special filename, which is similar to the competition for the MBR that exists on BIOS systems, and which EFI was supposed to correct.

Sooner or later, somebody will write utilities that will help handle recovery operations. (In fact, adding features useful for this is on my to-do list for my rEFInd boot manager; however, the necessary features will require some non-trivial additions to the program, so don't count on them appearing soon.) Remember that BIOS has been around for 30 years, so we have lots of tools to deal with its quirks, which are significant. EFI is much newer, so we have fewer tools to help handle its quirks. Just as bad, most users are unaware of the tools and techniques that do exist.

One more point: rEFInd (and its predecessor, rEFIt) comes in various forms, including a CD-R image file. You can boot from that image file and the program should detect all your EFI boot loaders, giving you the ability to boot from any of them even if the NVRAM has been wiped. (The rEFIt CD-R image file works only on Macs, but rEFInd works on UEFI-based PCs and at some, but not all, Macs.) Thus, you can use rEFInd or rEFIt as an emergency boot system for an EFI-based PC, even if you don't normally use these tools on your hard disk.

Quote:
I presume that a normal non-EFI install can be made by booting the install disk with kernel parameter "noefi"?
I'm not sure about that. The kernel's "noefi" parameter disables the EFI boot services support, but I don't know what the installer uses to detect its boot mode.
Reply With Quote
  #6  
Old 7th June 2012, 09:06 PM
droidhacker Offline
Registered User
 
Join Date: Oct 2009
Posts: 827
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by srs5694 View Post
That would be an oversimplification, at best. It could be EFI implementation bugs, a buggy configuration on the boot media, or any number of other issues. They're all related to EFI in one way or another, but saying that EFI (or UEFI) caused the hang is neither precise nor accurate.



That sounds like a bug, possibly interacting with a hardware issue (a timeout on the boot device, for instance; the device spinup time is likely to vary randomly, and it might sometimes exceed the timeout period and sometimes not).



Using NVRAM to hold boot data has its advantages. For instance, you can easily install as many boot loaders as you like and, if the firmware's user interface is anything better than abysmal, choose which boot loader to use on a boot-by-boot basis. (Sadly, some EFI implementations have user interfaces that are abysmal and don't give this option, but most at least pass the "abysmal" quality mark.) A level or two above "abysmal," an EFI's user interface should let you select a boot loader even if the NVRAM has been wiped. Sadly, many more fail at this, but some don't.

The ire on this issue should really be directed at the EFI implementations, which tend to have been done without giving adequate thought to the user experience. Many are also quite buggy. Basically, manufacturers put off development effort for too long and are now trying to rush out products that aren't really ready. I expect it'll improve a lot in a year or two, but for the moment we're in for some pain because of this.

Another important point is that long-time PC users are so familiar with the annoyances of the BIOS booting system that they've faded into the background. We know how to fix problems caused by boot code in the MBR being overwritten, or how to chainload from one boot loader to another, or how to create a disk layout with the right mixture of primary and logical partitions to let all our OSes boot. These issues aren't as important, or don't exist at all, on EFI systems. EFI does have its problems, but it at least leaves many of the BIOS problems behind it. Overall, I think EFI will be an improvement in the long run, provided Secure Boot doesn't become too much of a problem.



This comment is suggesting fitting a square peg into a round hole. There's a much better way to do it: EFI supports a default boot program, which is stored as EFI/Boot/bootx64.efi on the EFI System Partition (ESP), or variants of that name on platforms other than x86-64. If the NVRAM has no valid entries, the EFI will try to boot using that file. The Windows installer places two copies of its boot loader on the disk, one under the usual (for Windows) name of EFI/Microsoft/Boot/bootmgfw.efi and the other as EFI/Boot/bootx64.efi. This way, Windows will continue to boot even if the NVRAM has been wiped. Linux installers could do something similar. One problem with this approach is that it sets up a potential for between-OS competition over this special filename, which is similar to the competition for the MBR that exists on BIOS systems, and which EFI was supposed to correct.

Sooner or later, somebody will write utilities that will help handle recovery operations. (In fact, adding features useful for this is on my to-do list for my rEFInd boot manager; however, the necessary features will require some non-trivial additions to the program, so don't count on them appearing soon.) Remember that BIOS has been around for 30 years, so we have lots of tools to deal with its quirks, which are significant. EFI is much newer, so we have fewer tools to help handle its quirks. Just as bad, most users are unaware of the tools and techniques that do exist.

One more point: rEFInd (and its predecessor, rEFIt) comes in various forms, including a CD-R image file. You can boot from that image file and the program should detect all your EFI boot loaders, giving you the ability to boot from any of them even if the NVRAM has been wiped. (The rEFIt CD-R image file works only on Macs, but rEFInd works on UEFI-based PCs and at some, but not all, Macs.) Thus, you can use rEFInd or rEFIt as an emergency boot system for an EFI-based PC, even if you don't normally use these tools on your hard disk.



I'm not sure about that. The kernel's "noefi" parameter disables the EFI boot services support, but I don't know what the installer uses to detect its boot mode.
Aside from picking apart my somewhat simplified complaints, seems that we are on the same page. Basically.... don't trust hardware vendors not to f*** it up real badly.

I really can't trust anything that lacks a proper recovery option.

I'm going to try out the "noefi" bit when I get home, and hopefully that will get a proper working system.

Really REALLY wish that coreboot was legit and not the toy it is. There is NO reason why this stuff should be closed up and super secret as it is.
Reply With Quote
  #7  
Old 7th June 2012, 09:49 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by droidhacker View Post
Aside from picking apart my somewhat simplified complaints, seems that we are on the same page. Basically.... don't trust hardware vendors not to f*** it up real badly.
I certainly can't argue with that!

Quote:
I really can't trust anything that lacks a proper recovery option.
As I've tried to point out, there are EFI recovery options. The details of precisely what works vary from one EFI implementation to another, but even with the worst of them, there are options that will work, such as using a bootable CD or USB flash drive to get access to an EFI shell. (Some implementations provide a built-in EFI shell.) With an EFI shell, you can do a fair amount to fix boot loader problems. In fact, I'd argue that this option makes EFI better at recovery than BIOS.

Quote:
Really REALLY wish that coreboot was legit and not the toy it is. There is NO reason why this stuff should be closed up and super secret as it is.
It isn't secret! EFI is open source. AFAIK, all currently-shipping UEFI-based PCs use EFI implementations based on TianoCore, which is licensed under the BSD license. The closest thing to a "secrecy" problem is that documentation is hidden away on obscure Web sites or nonexistent. This is particularly true for implementation-specific features such as EFI user interface options, since that's an area that firmware developers like to customize. (The reference user interface in TianoCore is unusual, from a legacy BIOS perspective, and AFAIK nobody uses it on a shipping x86-64 product.)

FWIW, it's possible to use TianoCore as a payload atop CoreBoot. In this configuration, CoreBoot does the low-level hardware initialization and TianoCore UEFI handles the OS booting. That said, I've never set up a system that way. I am tempted, though; I've got a computer with Gigabyte's Hybrid EFI, which is the worst EFI implementation I've seen. I've toyed with the idea of figuring out the CoreBoot and TianoCore build processes to create a suitable replacement firmware. The problem is that I'm afraid of bricking my motherboard. It's the computer at the heart of my home network, so I don't want to risk the downtime associated with a problem.
Reply With Quote
  #8  
Old 8th June 2012, 01:20 AM
droidhacker Offline
Registered User
 
Join Date: Oct 2009
Posts: 827
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by srs5694 View Post
I certainly can't argue with that!



As I've tried to point out, there are EFI recovery options. The details of precisely what works vary from one EFI implementation to another, but even with the worst of them, there are options that will work, such as using a bootable CD or USB flash drive to get access to an EFI shell. (Some implementations provide a built-in EFI shell.) With an EFI shell, you can do a fair amount to fix boot loader problems. In fact, I'd argue that this option makes EFI better at recovery than BIOS.
The problem is that it is implementation specific. With a non-EFI install, you can grab the disk out, shove it into another machine, and flip it on with the expectation that it will boot up just fine. At the lowest level, yes, you can recover your data and probably repair your installation, but it is a general pain in the ass to do so.

Quote:
It isn't secret! EFI is open source. AFAIK, all currently-shipping UEFI-based PCs use EFI implementations based on TianoCore, which is licensed under the BSD license. The closest thing to a "secrecy" problem is that documentation is hidden away on obscure Web sites or nonexistent. This is particularly true for implementation-specific features such as EFI user interface options, since that's an area that firmware developers like to customize. (The reference user interface in TianoCore is unusual, from a legacy BIOS perspective, and AFAIK nobody uses it on a shipping x86-64 product.)

FWIW, it's possible to use TianoCore as a payload atop CoreBoot. In this configuration, CoreBoot does the low-level hardware initialization and TianoCore UEFI handles the OS booting. That said, I've never set up a system that way. I am tempted, though; I've got a computer with Gigabyte's Hybrid EFI, which is the worst EFI implementation I've seen. I've toyed with the idea of figuring out the CoreBoot and TianoCore build processes to create a suitable replacement firmware. The problem is that I'm afraid of bricking my motherboard. It's the computer at the heart of my home network, so I don't want to risk the downtime associated with a problem.
Right, bits are open source, like AOSP or MacOSX. The problem is that the parts that actually deal with the hardware remain a secret, which means that much reverse engineering is required in order to make something custom run on the hardware. So TianoCore is open source, but you can't just build TianoCore and flash it onto the bootrom and have it work. You need something to load it, like coreboot, or more likely, some proprietary buggy crap.


In any event, the "noefi" option seems to tell the installer to do a non-EFI installation. It is currently in progress here now, I'll report on whether the thing actually boots when it finishes

Gigabyte no longer doing the "dual-bios" thing?

---------- Post added at 07:19 PM ---------- Previous post was at 06:02 PM ----------

Ok then... 100% of all the problems I've been having have been due to UEFI crap.
... the unpredictable random crash on startup,
AND the FAILURE to POWER OFF.

I now have a 100% working system in all respects.

---------- Post added at 08:20 PM ---------- Previous post was at 07:19 PM ----------

My my my my... even the integrated BLUETOOTH module is working now. That didn't work either in F17+EFI ***OR EVEN WONDOZE***.
-- I needed to use the BT to update the firmware on my car's bluetooth module, the stupid thing could only be done in wondoze, had to use an external BT dongle.

Last edited by droidhacker; 7th June 2012 at 11:09 PM.
Reply With Quote
  #9  
Old 8th June 2012, 05:23 AM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by droidhacker View Post
The problem is that it is implementation specific. With a non-EFI install, you can grab the disk out, shove it into another machine, and flip it on with the expectation that it will boot up just fine.
Not necessarily; if the systems vary in hardware, there can be problems, particularly if you're running a custom kernel or if you've customized your configuration for your hardware in any way (adjusted your /etc/X11/xorg.conf file, say).

Furthermore, on an EFI system, you can swap disks as you describe and it'll work (with the same caveats as on BIOS). You might need to futz with the firmware to get the boot process started, but probably not if your system includes a default boot loader at EFI/boot/bootx64.efi on the ESP.

Quote:
At the lowest level, yes, you can recover your data and probably repair your installation, but it is a general pain in the ass to do so.
Not as much as you're making it out to be -- at least, not once you've got an EFI knowledge level that's equivalent to your BIOS knowledge level. Trust me on this; a year or two ago I found EFI to be puzzling and frustrating, too, but now that I understand it, I can see that its problems are simply different from those of BIOS, not worse than BIOS's problems. OTOH, there's a lot more variability in the quality of EFI implementations than in the quality of BIOS implementations. The worst of the EFI implementations is pretty dismal; but the best of them work much better. This will of course change in time, as firmware developers get their act together with respect to EFI and bring up the bottom to a better level of quality.

Quote:
Right, bits are open source, like AOSP or MacOSX. The problem is that the parts that actually deal with the hardware remain a secret, which means that much reverse engineering is required in order to make something custom run on the hardware.
Which is no different from BIOS.
Reply With Quote
  #10  
Old 8th June 2012, 11:56 AM
Fewmets Offline
Registered User
 
Join Date: Sep 2011
Location: Edmonton Alberta Canada
Posts: 54
windows_7firefox
Re: UEFI install hangs after initrd

Hai guys. I just got home so I'm going to try out your recommendation now and see if it works. My windows is set up as BIOS boot, but my motherboard bios/UEFI hybrid implementation allows defining both UEFI and standard boot drives in the boot list and they're on separate drives, although I think grub2 can be used to boot both as both GPT and MBR on a GPT drive if it's configured correctly anyways.

Just a point of question, you mention that EFI uses boot files rather than boot code in a specific place. Doesn't that mean that the UEFI implementation would have to understand whatever filesystem is used on the GPT partition where the file is located? Wouldn't that mean that any new filesystems that are developed or any that aren't supported by your UEFI implementation would be unusable on your system at boot? I don't understand how that would be better than raw binary data at a specific point.

Edit: Just to clarify, I know that the partition for the EFI boot files has to be FAT32 right now, but isn't FAT a old and limited file system that may become depreciated in the future?

Last edited by Fewmets; 8th June 2012 at 12:06 PM.
Reply With Quote
  #11  
Old 8th June 2012, 01:18 PM
droidhacker Offline
Registered User
 
Join Date: Oct 2009
Posts: 827
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by srs5694 View Post
Not necessarily; if the systems vary in hardware, there can be problems, particularly if you're running a custom kernel or if you've customized your configuration for your hardware in any way (adjusted your /etc/X11/xorg.conf file, say).
You can always screw with a system until it won't work on any different hardware, but lets limit this discussion to "out of the box" installations.

Quote:
Furthermore, on an EFI system, you can swap disks as you describe and it'll work (with the same caveats as on BIOS). You might need to futz with the firmware to get the boot process started, but probably not if your system includes a default boot loader at EFI/boot/bootx64.efi on the ESP.
So far, I'm at 1 for 1 CAN'T POSSIBLY do this, further, you WOULD require another EFI system to swap the disk into.

Quote:
Which is no different from BIOS.
Which is what I'm complaining about.

---------- Post added at 08:18 AM ---------- Previous post was at 08:10 AM ----------

Quote:
Originally Posted by Fewmets View Post
Hai guys. I just got home so I'm going to try out your recommendation now and see if it works. My windows is set up as BIOS boot, but my motherboard bios/UEFI hybrid implementation allows defining both UEFI and standard boot drives in the boot list and they're on separate drives, although I think grub2 can be used to boot both as both GPT and MBR on a GPT drive if it's configured correctly anyways.

Just a point of question, you mention that EFI uses boot files rather than boot code in a specific place. Doesn't that mean that the UEFI implementation would have to understand whatever filesystem is used on the GPT partition where the file is located? Wouldn't that mean that any new filesystems that are developed or any that aren't supported by your UEFI implementation would be unusable on your system at boot? I don't understand how that would be better than raw binary data at a specific point.

Edit: Just to clarify, I know that the partition for the EFI boot files has to be FAT32 right now, but isn't FAT a old and limited file system that may become depreciated in the future?
The problem is that UEFI stores data in NVRAM, which is a chip on your mainboard, rather than a disk. That data stored on your mainboard describes (among other things) where to find the next stage bootloader on the disk, which I believe is supposed to be the first partition formatted as VFAT. The old way was just to put the bootloader at the start of the disk before the partitions.

In any case, my suggestion to you, is to do a standard install and forget this uefi nonsense. There is simply far too much bugginess there, its not worth it.
Reply With Quote
  #12  
Old 8th June 2012, 05:19 PM
Fewmets Offline
Registered User
 
Join Date: Sep 2011
Location: Edmonton Alberta Canada
Posts: 54
windows_7firefox
Re: UEFI install hangs after initrd

Okay, so I tried your suggestion and it worked great. And sorry I didn't see your question, yeah it was just information about the allocation and writing of the kernel and initrd to ram in grub, not kernel messages. The problem is that now it's installed but I can't boot it up so I'll have to find a different bootloader. Oh well. It seems grub2 hates my computer. :'(

I also noticed that Fedora wrote a UEFI boot option to my MB when it installed. How did it do that? It had "Fedora" with a capital F in it when the settings won't let me put any capitals. Are there tools out there to configure EFI boot options like that?

Quote:
The problem is that UEFI stores data in NVRAM, which is a chip on your mainboard, rather than a disk. That data stored on your mainboard describes (among other things) where to find the next stage bootloader on the disk, which I believe is supposed to be the first partition formatted as VFAT. The old way was just to put the bootloader at the start of the disk before the partitions.
No offense but bios just looked at all the drives and said "pick one to boot from, if that doesn't work we'll try the next one, and the next one and so on" UEFI doesn't store any substantial information in NVRAM than BIOS didn't. Just a table of startup option named, drives and files. You simply configure your own boot options rather than having every possible drive as a boot option. That's the one thing I like about it over standard bios. And yeah, it's supposed to be a FAT file system (usually fat32) and has a special partition flag to tell your MB that it's a UEFI bootable partition. You can then use that to only list drives with bootable partitions when you go to add and then you just have to name the boot option and specify the boot file. Voila. While it may take a few more seconds then just scrolling through the list of drives hooked up to your pc, it is a persistent setting which is nice. You have to know what directory to point uefi to on a drive, but that's no different from knowing where you put that text document you were working on last night.

Last edited by Fewmets; 8th June 2012 at 06:03 PM.
Reply With Quote
  #13  
Old 8th June 2012, 07:13 PM
droidhacker Offline
Registered User
 
Join Date: Oct 2009
Posts: 827
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by Fewmets View Post
Okay, so I tried your suggestion and it worked great. And sorry I didn't see your question, yeah it was just information about the allocation and writing of the kernel and initrd to ram in grub, not kernel messages. The problem is that now it's installed but I can't boot it up so I'll have to find a different bootloader. Oh well. It seems grub2 hates my computer. :'(

I also noticed that Fedora wrote a UEFI boot option to my MB when it installed. How did it do that? It had "Fedora" with a capital F in it when the settings won't let me put any capitals. Are there tools out there to configure EFI boot options like that?



No offense but bios just looked at all the drives and said "pick one to boot from, if that doesn't work we'll try the next one, and the next one and so on" UEFI doesn't store any substantial information in NVRAM than BIOS didn't. Just a table of startup option named, drives and files. You simply configure your own boot options rather than having every possible drive as a boot option. That's the one thing I like about it over standard bios. And yeah, it's supposed to be a FAT file system (usually fat32) and has a special partition flag to tell your MB that it's a UEFI bootable partition. You can then use that to only list drives with bootable partitions when you go to add and then you just have to name the boot option and specify the boot file. Voila. While it may take a few more seconds then just scrolling through the list of drives hooked up to your pc, it is a persistent setting which is nice. You have to know what directory to point uefi to on a drive, but that's no different from knowing where you put that text document you were working on last night.
Normal bios only goes through drives you tell it to go through. You can usually remove them from the list.

EFI doesn't just go through drives you tell it to go through, it goes through NO drives, even if you DO tell it to, unless you give it very specific instructions that are FAR beyond the scope of the configuration program that they supply to you.

Whether there is an EFI boot partition or not, if it doesn't know the entry for that startup (in your case, labeled as "Fedora"), it will just puke on you.
Reply With Quote
  #14  
Old 8th June 2012, 08:17 PM
Fewmets Offline
Registered User
 
Join Date: Sep 2011
Location: Edmonton Alberta Canada
Posts: 54
windows_7firefox
Re: UEFI install hangs after initrd

You completely misinterpreted my statement about EFI going through your drives. Both my desktop and laptop have UEFI and both show you which devices have EFI system partitions and allow you to select from them when you are configuring your boot options. This leaves me with a list of all of my drives for BIOS plus my UEFI configurations on my laptop and a list of only UEFI boots on my desktop unless UEFI is disabled. My point is that a pure EFI implementation would only iterate through the options you make when trying to start instead of iterating through all of your devices in a configurable order. I've had a number of computers as well as configured quite a number of other peoples computers and the only devices I've seen possible to disable boot without disabling the bus is PXE network boot. I know how to disable, say, USB but I've never come across a bios that lets you disable individual drives for boot.

What is your point to any of this though? All of my comments back to you have been at least asides beside dealing with the main topic. You seem to be arguing for the sake of arguing. If you have a point please make it, otherwise if you're not going to contribute to the solution please do not make any further comments.


Back on topic: All my partitions are ext4 or lvm with ext4 which my EFI shell (the same one which is in your package) doesn't have drivers for so I can't load fedora directly. I don't have much experience installing an open bootloader through windows on a different drive. It seems really awkward but I'm kind of muddling through it. Do either of you have any suggestions of easy to setup bootloaders supporting EFI other than grub?

Last edited by Fewmets; 8th June 2012 at 08:19 PM.
Reply With Quote
  #15  
Old 8th June 2012, 09:15 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI install hangs after initrd

Quote:
Originally Posted by Fewmets View Post
Okay, so I tried your suggestion and it worked great.
I'm not sure to which "you" you're referring. There were at least two specific suggestions in this thread: george_toolan suggested booting in BIOS mode and I provided a procedure to boot in EFI mode using the EFI stub loader. There might have been something else that I've missed. Which approach you used is likely to be important for moving forward. Based on later comments in this thread, it sounds like you got an EFI-mode install working, though, so I'll proceed under that assumption....

Quote:
The problem is that now it's installed but I can't boot it up so I'll have to find a different bootloader. Oh well. It seems grub2 hates my computer. :'(
That happens sometimes; unfortunately, there are still far too many bugs, both in EFI implementations and in EFI boot loaders, and they often interact, so that a bug only shows up when you use certain combinations. Thus, it'll take a while for developers to track them all down. (In fact, tracking them all down is never likely to happen!)

Fortunately, there are usually workarounds or ways to get it to work by using alternative boot loaders.

Quote:
I also noticed that Fedora wrote a UEFI boot option to my MB when it installed. How did it do that? It had "Fedora" with a capital F in it when the settings won't let me put any capitals. Are there tools out there to configure EFI boot options like that?
Yes. The Linux tool for this task is called "efibootmgr". Type "man efibootmgr" to learn about its options.

Quote:
No offense but bios just looked at all the drives and said "pick one to boot from, if that doesn't work we'll try the next one, and the next one and so on" UEFI doesn't store any substantial information in NVRAM than BIOS didn't. Just a table of startup option named, drives and files.
Actually, EFI stores substantially more information on boot loaders (and other things) in NVRAM than BIOS does. The efibootmgr utility gives you access to the boot loader information, which should theoretically include data on every EFI boot loader installed on the computer and the order in which they're tried. (In practice, boot loaders can be omitted from the NVRAM data, and the NVRAM data can point to boot loaders that don't exist. This can become a problem in some cases, as droidhacker has been saying, but I doubt if it's relevant to your particular case.) It's also possible to store options that are passed to these boot loaders, which can be important if you're using the kernel's EFI stub loader directly. EFI also stores data on drivers and various other things in NVRAM. Most of these have little or no visibility to end users, but they are present. You can examine them in an EFI shell using the "dmpstore" command, if you're curious. Type "help dmpstore -b" in an EFI shell to get basic usage information on this command.

Quote:
All my partitions are ext4 or lvm with ext4 which my EFI shell (the same one which is in your package) doesn't have drivers for so I can't load fedora directly. I don't have much experience installing an open bootloader through windows on a different drive. It seems really awkward but I'm kind of muddling through it. Do either of you have any suggestions of easy to setup bootloaders supporting EFI other than grub?
I've got a Web page on the topic:

http://www.rodsbooks.com/efi-bootloaders/

For installation, pay particular attention to the "EFI Boot Loader Installation" sub-page.

In brief, you can copy the files related to whatever boot loader(s) you want to use to the ESP and then use efibootmgr to add those boot loader program filename(s) to your NVRAM. You should then be able to select them from your firmware's boot manager menu; however, some implementations provide such poor boot managers that you will instead need to install another boot manager and configure it as the default. rEFIt can do this, but the binaries provided by the author won't work on UEFI-based PCs (binaries that will work are available from other sources). My rEFInd is a fork of rEFIt with bug fixes and new features, and the binaries I provide for it work fine on UEFI-based PCs. If it was my procedure you followed earlier, you've got rEFInd on CD, so you can install from that by copying files to your ESP and then running efibootmgr with appropriate options. (The install.sh script should do this automatically; or see rEFInd's installation instructions for other options.)

In my experience, the Linux kernel's EFI stub loader is the EFI boot loader that's most reliable. If you followed my instructions from post #3 in this thread, you used the EFI stub loader to get your Fedora installer working. To use it permanently, you can either add an entry for it to your NVRAM using efibootmgr or you can install rEFInd to your hard disk (and create an NVRAM entry for it) and let rEFInd detect the kernel and launch it. Using the stub loader directly from the EFI's boot manager requires a bit more esoteric setup, and will require reconfiguration whenever you upgrade your kernel. (Fedora sends out kernel upgrades pretty frequently, so this could become a hassle.) Using rEFInd involves setup that's a bit less esoteric but that will require copying and/or editing more files. Depending on how it's done, a rEFInd/stub loader setup can enable a no-effort kernel upgrade process. The no-effort process will require you to have a separate /boot partition that uses FAT, HFS+, ext2fs, ext3fs, or ReiserFS. (Note that a typical /boot partition is tiny enough that there's no advantage to using ext4fs on it, so converting it to ext2fs, ext3fs, or ReiserFS isn't a problem.) I recommend you read the following Web pages for a fuller understanding of these options:

http://www.rodsbooks.com/efi-bootloaders/efistub.html
http://www.rodsbooks.com/refind/linux.html
http://www.rodsbooks.com/refind/drivers.html
Reply With Quote
Reply

Tags
hangs, initrd, install, uefi

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
Installation hangs after 'loading initrd.img' sanplaale Installation, Upgrades and Live Media 1 10th January 2008 08:02 AM
Dell e510, fedora install hangs after loading vmlinuz/initrd.img mrmailer Installation, Upgrades and Live Media 5 1st June 2007 09:50 AM
FC6 Hangs at initrd TheMaxx EOL (End Of Life) Versions 12 4th February 2007 11:31 PM
FC4 hangs-up after initrd oned3r3r EOL (End Of Life) Versions 1 20th November 2005 11:20 PM
AMD64 install hangs at "looks like an initrd" Daniel Crevelin Installation, Upgrades and Live Media 2 22nd July 2005 10:22 PM


Current GMT-time: 06:03 (Monday, 29-12-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
...CERES Environment Park Travel Photos - Sheilas Cork Hostel Photos on Instagram - Thames Tunnel - Corfu, Kerkira, Greece - St. Theresa's College Cebu City Photos