Fedora Linux Support Community & Resources Center
  #16  
Old 6th November 2012, 01:45 AM
jakin Offline
Registered User
 
Join Date: Nov 2012
Location: California
Posts: 11
windows_7chrome
Re: UEFI/Hybrid EFI Issues with x86_64

Ok, running the install.sh file included with refind..... the script hangs.

No files were copied / moved / replaced (I checked the ESP for new files).

I will say that when I first tried, it did take a few seconds longer to get to the "GRUB" hang so perhaps something was kinda sorta working but not really. Yes, I copied the correct information from the grub.conf file and included it into the refind_linux.conf.

So, with failures from rEFInd, as well as failures from the normal Fedora install... I think my comments about HybridEFI with this board are right on the money. Here is a thought I have... keep in mind it is speculation. This motherboard was built for raw IO power, enough to keep 4 Tesla cards (or 4 way sli) maxed out. Maybe because of this, they stripped out some of the EFI code from the bios making it really a hybrid solution as opposed to an EFI Implementation. Again, this is just speculation.

While I am interested in getting to the bottom of this, continually running tests on a production server is not a good idea... to much downtime. Each time I tried rEFInd, it was on a fresh install of F17. This way I could be sure that everything was the way it would be from an installation of Fedora.

I will keep my eyes open for any BIOS updates that address this HybridEFI issue. Also if one needs to manually copy the kernel and initrd images to the ESP on every kernel update, that could cause separate issues if someone forgot to make that copy after running "yum update".

Tonight I will be reinstalling with the proper BIOS Boot partition to get my server back online. Any further testing will have to be done with an external USB HDD instead of SATA drives. If there is anything else that you would like me to attempt, I will be happy to do so on that external drive.

---------- Post added at 05:45 PM ---------- Previous post was at 05:33 PM ----------

Quote:
If the computer displays "GRUB" and hangs, then that means that rEFInd did not launch; GRUB did. There must be a grub.efi file somewhere on your system, and removing or renaming it might fix the problem.
First I mounted the ESP.

Second, I moved the redhat folder and all of it's contents to a different partition. At this point /boot/efi only contained the EFI subdirectory. There was no leftovers from GRUB.

Third, I attempted to install refind doing exactly what you mentioned.

Fourth, I tried to reboot.

**************************

So as you can see, no leftovers were present. Only refind with the copied and renamed kernel and initrd.
Ok before I reinstall without EFI, I am going to be doing one more test. I will download a ubuntu disc as you suggested. From booting to that disc, I should be able to get a line about EFI from " dmesg | grep efi".

That should answer a few questions. Please keep in mind that no EFI based linux installation from any distribution has worked as of yet. It has only worked with a BIOS Boot Partition. I will post the results of that dmesg as soon as they become available... have a large download (ubuntu disc) to do after all.
Reply With Quote
  #17  
Old 6th November 2012, 04:21 AM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI/Hybrid EFI Issues with x86_64

Quote:
Originally Posted by jakin View Post
I will say that when I first tried, it did take a few seconds longer to get to the "GRUB" hang so perhaps something was kinda sorta working but not really.
If it displayed "GRUB" on the screen, then the computer was launching GRUB (or perhaps some other program that displays "GRUB"). It's hard to believe that the string "GRUB" would find its way into the firmware, and rEFInd certainly doesn't display the word "GRUB" on the screen. If you could do an "ls -R" again on the ESP, that might be helpful; however, I do understand your reluctance to continue testing this matter.

It also occurs to me that you might have had a leftover BIOS-mode GRUB installation in the MBR and that the system was actually beginning to boot in BIOS mode and then failing. If so, a "dd if=/dev/zero of=/dev/sda bs=440 count=1" would clear that away and perhaps coax the computer into doing an EFI-mode boot.

Quote:
So, with failures from rEFInd, as well as failures from the normal Fedora install... I think my comments about HybridEFI with this board are right on the money.
You're certainly correct that it's a poor implementation; however, I stand by my statement that Hybrid EFI is a true (albeit poor) EFI implementation.

Quote:
Here is a thought I have... keep in mind it is speculation. This motherboard was built for raw IO power, enough to keep 4 Tesla cards (or 4 way sli) maxed out. Maybe because of this, they stripped out some of the EFI code from the bios making it really a hybrid solution as opposed to an EFI Implementation. Again, this is just speculation.
That makes little sense; EFI code takes up space in the EEPROM, but doesn't interfere with I/O throughput.

Quote:
I will keep my eyes open for any BIOS updates that address this HybridEFI issue. Also if one needs to manually copy the kernel and initrd images to the ESP on every kernel update, that could cause separate issues if someone forgot to make that copy after running "yum update".
With a proper configuration, that's not necessary; it's just easier to set up a simple test by copying the files manually. A better configuration using rEFInd would do one of two things:
  • Mount the ESP at /boot so that the kernel files go onto the ESP by default. The Fedora installer doesn't support this, but it could be reconfigured after an initial installation without too much trouble.
  • Use ReiserFS, ext2fs, or ext3fs on /boot and load a suitable EFI filesystem driver, thus enabling rEFInd to load the kernel from the /boot partition.

Either approach would require some changes to the rEFInd configuration file. The end result of either approach is that a kernel upgrade will be automatically detected by rEFInd.

Of course, this is a rEFInd design feature that's relevant for any EFI implementation. Other EFI boot loaders and boot managers have their own specific needs, and in principle a distribution could include support for any of them.
Reply With Quote
  #18  
Old 6th November 2012, 05:03 AM
jakin Offline
Registered User
 
Join Date: Nov 2012
Location: California
Posts: 11
windows_7chrome
Re: UEFI/Hybrid EFI Issues with x86_64

Quote:
It also occurs to me that you might have had a leftover BIOS-mode GRUB installation in the MBR and that the system was actually beginning to boot in BIOS mode and then failing. If so, a "dd if=/dev/zero of=/dev/sda bs=440 count=1" would clear that away and perhaps coax the computer into doing an EFI-mode boot.
I had the same or a similar thought. Perhaps something in the MBR.... The only catch to this is that when you purchase a new HDD or even a new SSD, they are completely blank. They have no partitions let alone a programmed boot sector. The Fedora installation itself is where the "GRUB" message or whatever you want to call it gets installed (yes this is with EFI enabled).

In this case cleaning out those sectors won't do a bit of good as the Fedora installer will just put it right back. This I remember going through over and over when I first setup the machine. It was a nightmare.

Quote:
That makes little sense; EFI code takes up space in the EEPROM, but doesn't interfere with I/O throughput.
Fewer lines of instructions will greatly increase the speed at which things are processed. So by reducing the number of instructions that have to be read and executed you should be able to achieve a higher I/O transfer rate. If the EFI code only sat in an EEPROM and was never executed, you are correct. Using EFI means that code has to be executed, and that takes cpu cycles, etc.... You did say that an EFI boot is slower than a BIOS/MBR based boot.
Besides, I did say that it was speculation. I have no proof either way as to what their HybridEFI code has or doesn't have in it.


I have finished the download of Ubuntu Server 12.10, their latest version. I will try the "Try before Install" option and tell you what if any results come from "dmesg | grep efi". This version should most definately support EFI so there should be something in the kernel messages.
Reply With Quote
  #19  
Old 6th November 2012, 06:18 AM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI/Hybrid EFI Issues with x86_64

Quote:
Originally Posted by jakin View Post
I had the same or a similar thought. Perhaps something in the MBR.... The only catch to this is that when you purchase a new HDD or even a new SSD, they are completely blank. They have no partitions let alone a programmed boot sector. The Fedora installation itself is where the "GRUB" message or whatever you want to call it gets installed (yes this is with EFI enabled).
I agree it seems improbable; but it's worth checking out with something like:

Code:
hexdump -C -n 440 /dev/sda
If GRUB is present it should be obvious.

Quote:
Fewer lines of instructions will greatly increase the speed at which things are processed. So by reducing the number of instructions that have to be read and executed you should be able to achieve a higher I/O transfer rate. If the EFI code only sat in an EEPROM and was never executed, you are correct. Using EFI means that code has to be executed, and that takes cpu cycles, etc....
While it's executing, yes; but for the most part the EFI code executes before the OS runs and then lies dormant. EFI does offer runtime support services, but that's pretty minor stuff. Furthermore, creating a "stripped-down" EFI that removes the runtime services would require significant amounts of additional programming effort. I'd be shocked if Gigabyte invested effort into that, particularly since it would be a dead-end project -- with the computing world moving to UEFI, any such effort would have a very short shelf life. Finally, the fact that Fedora attempted an EFI-mode install suggests that the Fedora installer booted into EFI mode and found those runtime services.

Quote:
You did say that an EFI boot is slower than a BIOS/MBR based boot.
No, I said that it could be faster than a BIOS-mode boot. This is mostly a function of quicker hardware initialization, since the BIOS code has to work around the limitations of 1980s technology (16-bit code with limited memory spaces, thunking, etc.). Once the kernel gets control there will be little or no difference between a BIOS-mode and an EFI-mode boot.
Reply With Quote
  #20  
Old 7th November 2012, 09:04 PM
jakin Offline
Registered User
 
Join Date: Nov 2012
Location: California
Posts: 11
windows_7chrome
Re: UEFI/Hybrid EFI Issues with x86_64

Ok, as an update on all of this, I was able to get EFI working by using some of your advice SRS... what led me to figure out just what was happening was the post about MBR as well as the sample configuration file for refind.

The boot sector did have some grub stuff in it. Clearing it out didn't seem to help when it did a little bit. One thing I noticed is that from your original followup reply as well as in that configuration file, is the directory "boot". In that sample configuration file, for the windows entry, it points to a Windows/boot directory. Also when you mentioned to rename the redhat directory to boot, it follows the same or similar pattern. So HybridEFI looks for a "boot" directory. Considering at this time I had no EFI shell, and that there is no redhat/boot directory... it makes sence that it could not boot. Perhaps this works with other EFI implementations though.

I left the redhat directory completely alone. In fact I created the directory /boot/efi/boot (so that the bootloader refind would be loaded first... just in case it booted the first "boot" directory it came across). After unpacking refind, and copying the refind directory to /boot/efi/boot, I renamed refind.conf-sample to refind.conf and enabled the option to see_all_kernels. As refind is forwarding to a working grub... kernel updates will not be an issue either. Though.... with refind, my boot up takes a bit longer as refind has to do it's searches.

One thing I did notice is that other linux distributions are very similar in that their efi directory does not contain a boot directory. This would explain why I was unable to install to any linux distribution that had EFI enabled. As it stands, trying to install another Linux distribution side by side with this current setup will work as long as you don't erase the ESP. Perhaps refind would be a good addition to the next Fedora release.... I agree with you now SRS, this board does have a working EFI.... Flaky I believe you called it but working.
Reply With Quote
  #21  
Old 7th November 2012, 11:52 PM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI/Hybrid EFI Issues with x86_64

Quote:
Originally Posted by jakin View Post
Ok, as an update on all of this, I was able to get EFI working by using some of your advice SRS... what led me to figure out just what was happening was the post about MBR as well as the sample configuration file for refind.
I'm glad you've made progress. Of course, as a practical matter, BIOS-mode booting is still preferable for use with this board/firmware; but if you want to use EFI, you can, and I have some further observations. If you want to revert to BIOS-mode booting, though, feel free to ignore the rest of this post....

Quote:
One thing I noticed is that from your original followup reply as well as in that configuration file, is the directory "boot". In that sample configuration file, for the windows entry, it points to a Windows/boot directory. Also when you mentioned to rename the redhat directory to boot, it follows the same or similar pattern. So HybridEFI looks for a "boot" directory. Considering at this time I had no EFI shell, and that there is no redhat/boot directory... it makes sence that it could not boot. Perhaps this works with other EFI implementations though.
I'm a little unsure of precisely what you mean by those directory names. In an EFI system, boot loaders normally reside in subdirectories of the "EFI" (or "efi"; FAT is case-insensitive) directory on the ESP, as in EFI/BOOT, EFI/redhat, and EFI/refind. Microsoft puts their boot loader in EFI/Microsoft/Boot. In Linux, these would be accessible at some mount point, which is most often /boot/efi. Thus, you'd have /boot/efi/EFI/BOOT, /boot/efi/EFI/redhat, and so on. The EFI/boot directory on the ESP holds the default boot loader (bootx64.efi). I realize this can be confusing, given the not-quite-standardized Linux mount point and, in the most common configuration, the repetition of "efi" (or "EFI") as a directory name.

Quote:
I left the redhat directory completely alone. In fact I created the directory /boot/efi/boot (so that the bootloader refind would be loaded first... just in case it booted the first "boot" directory it came across).
If /boot/efi/boot (not /boot/efi/EFI/boot) is the name of the directory in Linux, then this implies that you've mounted your ESP at /boot. This is a bit non-standard, but it can actually simplify some things if you elect to use rEFInd. To double-check your configuration, type "df -h | grep boot" to see what's being mounted where. It may be helpful to cross-reference this against the partition table as reported by parted or gdisk. On one of my systems, for instance, I get this:

Code:
# df -h | grep boot
/dev/sda2                    196M   41M  145M  22% /boot
/dev/sda1                    187M  2.0M  185M   2% /boot/efi

# parted /dev/sda print
...
Number  Start   End    Size   File system  Name                     Flags
 1      1049kB  200MB  199MB  fat32        EFI System               boot
 2      200MB   411MB  211MB  ext2         Gentoo /boot
This shows that the ESP (/dev/sda1, with a FAT32 filesystem and the "boot flag" set) is mounted at /boot/efi and /dev/sda2 is a separate /boot partition with an ext2 filesystem.

If you find that you've got your FAT32 ESP mounted at /boot, it can simplify things because Fedora will put kernels in /boot, which means that they'll go on the ESP. This in turn makes them accessible to rEFInd, which can boot them directly without the use of GRUB....

Quote:
After unpacking refind, and copying the refind directory to /boot/efi/boot, I renamed refind.conf-sample to refind.conf and enabled the option to see_all_kernels. As refind is forwarding to a working grub... kernel updates will not be an issue either. Though.... with refind, my boot up takes a bit longer as refind has to do it's searches.
If you've uncommented the scan_all_linux_kernels option and mounted the ESP at /boot in Linux, then rEFInd will automatically detect your kernels, since Fedora will put them in the root directory of the ESP, which rEFInd will scan. If you put a properly configured refind_linux.conf file there, too, then rEFInd will boot Linux directly, without the help of GRUB. You can change the icon by copying whatever icon you want from rEFInd's icons subdirectory to /boot/.VolumeIcon.icns. Set up in this way, rEFInd will automatically detect your kernel updates, with no need for any additional scripts or reconfiguration.

All of this, of course, is predicated on the assumption that you didn't omit an "efi/" when you referred to "/boot/efi/boot". If you did, and if your ESP is mounted in the more conventional /boot/efi location, so that rEFInd currently resides in /boot/efi/EFI/BOOT/, then you can get the automatic operation I've described in either of two ways:
  • Move the current contents of /boot, including any subdirectories except the "efi" subdirectory, to the ESP, and then adjust your /etc/fstab entries so that the ESP gets mounted at /boot. You can move everything quite easily by doing a "cd /boot; mv * efi" as root.
  • Unmount /boot/efi, back up and unmount your /boot partition, create a fresh ext2fs, ext3fs, or ReiserFS filesystem on your /boot partition, restore the backed-up files to /boot, re-mount /boot/efi, and install the relevant EFI driver from the rEFInd package to the /boot/efi/EFI/boot/drivers directory. (Be sure you copy only the x86-64 ("x64") driver(s), not for the IA32 architecture.) When you reboot, rEFInd will load the driver, giving it access to your /boot partition. Of course, this is easier if you plan to install using ext2fs, ext3fs, or ReiserFS on /boot, but I didn't think to mention it when you were doing full re-installations.

I've got a number of systems configured with the EFI driver and it works well with most of them, although the ext2fs/ext3fs driver is a bit sluggish on some systems. I'm starting to think that mounting the ESP at /boot is the simplest way to go, at least provided you don't want to boot multiple Linux distributions. Unfortunately, Linux installation programs tend to balk at this sort of configuration; they want a /boot partition with a Linux-native filesystem. (Some of them put symbolic links on it.)

Once again, if you want to stick with BIOS booting, that's fine, and even advisable on a Hybrid EFI motherboard. I'm only describing this in case you want to experiment a bit.

Quote:
One thing I did notice is that other linux distributions are very similar in that their efi directory does not contain a boot directory. This would explain why I was unable to install to any linux distribution that had EFI enabled.
Correct. The problem seems to be that the Hybrid EFI tends to forget its NVRAM entries. I've had mine "stick" for a reboot or two, but they inevitably get lost after a while. Using the ESP's EFI/BOOT directory to hold the boot loader is an effective workaround, but it does require manual reconfiguration after installation.

If the BIOS-mode boot code in your MBR was interfering as well, the combination would be especially hard to diagnose and overcome, as you discovered.

Quote:
As it stands, trying to install another Linux distribution side by side with this current setup will work as long as you don't erase the ESP. Perhaps refind would be a good addition to the next Fedora release.... I agree with you now SRS, this board does have a working EFI.... Flaky I believe you called it but working.
I agree that rEFInd would be a good boot loader to be included with distributions; however, it currently has one big drawback that doesn't affect your board: rEFInd doesn't support Secure Boot. This is a feature that's included on the vast majority of new Windows 8 PCs, and it's been causing quite an uproar in the Linux world. I do have plans to add some sort of Secure Boot support to rEFInd, but I need to learn more about the programming aspect of it to do so.
Reply With Quote
  #22  
Old 8th November 2012, 01:24 AM
jakin Offline
Registered User
 
Join Date: Nov 2012
Location: California
Posts: 11
windows_7chrome
Re: UEFI/Hybrid EFI Issues with x86_64

You are correct, I had the directory names wrong in my last post.

ESP mount point: /boot/efi
Directory inside mountpoint would be EFI/boot, EFI/redhat...

What I was saying is that in the Windows EFI boot, there actually is a boot dirctory inside the Windows directory. For Fedora, there is no boot directory inside redhat, just as there is no boot directory inside ubuntu.

With my system, without that boot directory, the system does not boot. Placing the boot directory outside of redhat or ubuntu... it seems the EFI code looks for the first "boot" directory it finds to execute, hence refind will always load first.

EFI/boot - first found boot directory (manually created with refind dropped in here)
EFI/Windows/boot - deeper inside the file system, will not boot first but can still boot
EFI/redhat - no boot subdirectory, cannot boot without refind (or another EFI shell)
EFI/ubuntu - no boot subdirectory, cannot boot without refind (or another EFI shell)

Sorry for the confusion there, the double EFI can be a bit confusing. Creating a boot directory inside the ESP for redhat... aka /boot/efi/EFI/redhat/boot would probably also work provided you copied your kernel and all that. The filename bootx64.efi (renamed refindx64) is also required to boot.

I chose not to do that for the reason that I have updates automated for the most part. This even included the kernel so having refind jump over to grub when needed is the best choice to keep things simple. While boot time is a bit slower, due to refind's processing, I am not going to complain. After all it is only like 25 seconds extra (for refind's processing, timeouts, etc). My normal boot in BIOS mode was about 20 to 30 seconds. With refind, it's 40 seconds to 1 minute (from a powered off state).... the benefits from using a SSD as a boot drive.

This setup allows me to make use of ext4 for /boot.... Refind simple forces grub to execute where it would not before. As for Windows 8, I never plan on using it. Mostly for the simple reason that I want full control over my PC, not Microsoft. I hear that secure boot is a major headache for anyone wanting to dual-boot... Any OS that doesn't have a MS signature basically will prevent windows from booting until the EFI entry is removed or something like that.

One benefit that I can see now from using EFI is that you can have two isolated installations of Linux. This is a benefit because if say one grub got messed up, boot to the other and fix it. With just grub, if it got messed up.. time to dig out the dvd's and work on fixing it... EFI would make things easier/faster in that aspect IMHO.

There is one RPM package that could potentially mess with EFI though... That is the LiveUSBCreator... The reason it can cause a problem is that it's dependancy is EXTLINUX... a MBR boot loader with no EFI Support. I am hesitant on installing additional bootloaders lol.

As my server has everything reinstalled, which took quite some time.... I am not going to switch back to BIOS boot unless there is some really big problem with EFI. The future is heading towards EFI, so I will leave the system the way it is for now.

Having Anaconda clear out the first 440 bytes of the drive during repartitioning would be usefull on EFI installs as it would prevent the MBR/EFI conflict I had. Also having the choice of forcing a bios boot partition would be nice as well... Some of the autodetecting of Anaconda may work against you as what happened to me. For EFI, ya you will most likely need an EFI Shell / Bootloader on top of what you have.... unless you are lucky and that's part of your BIOS (the EFI Shell).
Reply With Quote
  #23  
Old 8th November 2012, 02:04 AM
srs5694 Offline
Registered User
 
Join Date: Jan 2011
Location: Woonsocket, RI
Posts: 521
linuxfirefox
Re: UEFI/Hybrid EFI Issues with x86_64

Quote:
Originally Posted by jakin View Post
What I was saying is that in the Windows EFI boot, there actually is a boot dirctory inside the Windows directory. For Fedora, there is no boot directory inside redhat, just as there is no boot directory inside ubuntu.
I understand what you meant now, and you're quite correct.

Quote:
With my system, without that boot directory, the system does not boot. Placing the boot directory outside of redhat or ubuntu... it seems the EFI code looks for the first "boot" directory it finds to execute, hence refind will always load first.
I haven't examined the EFI code on this score, but according to the EFI spec, the specific filename EFI/BOOT/bootx64.efi is the default (fallback) boot loader. That is, the firmware searches for that particular file; it doesn't search for a directory called "boot" and load whatever it finds within it. The fact that Windows uses "boot" as part of the path to its EFI/Microsoft/Boot/bootx64.efi boot loader is coincidental. (Some EFI implementations use this as a second fallback boot loader, but many don't.)

Quote:
Creating a boot directory inside the ESP for redhat... aka /boot/efi/EFI/redhat/boot would probably also work provided you copied your kernel and all that.
I don't think it would, although I haven't tested it.

Quote:
having refind jump over to grub when needed is the best choice to keep things simple. While boot time is a bit slower, due to refind's processing, I am not going to complain. After all it is only like 25 seconds extra (for refind's processing, timeouts, etc).
rEFInd shouldn't be adding 25 seconds to the boot time, although it could be close to that if you let it time out and boot its default entry. You can adjust the timeout with the "timeout" option in refind.conf, so if you do want to simply let the boot loader timeout, you can cut it down significantly by reducing that timeout value.

Quote:
I hear that secure boot is a major headache for anyone wanting to dual-boot... Any OS that doesn't have a MS signature basically will prevent windows from booting until the EFI entry is removed or something like that.
It's more like the opposite. On a system with Secure Boot active, any OS with a boot loader that's not signed by Microsoft (or some other entity whose keys happen to be in your firmware) can't boot. Deactivating Secure Boot lets anything boot, signed or not. Fortunately, Microsoft is letting Verisign sign third-party boot loaders. Pay Verisign $99 and you, too, can get your boot loader signed with Microsoft's key. (You can actually get as many binaries signed as you like for that $99; that's not a per-signature price.) Red Hat/Fedora, SuSE, and I believe also Ubuntu are following this route, so with any luck the extra pain will be minimal for most users. There are down sides to this approach, but they've been discussed to death in other threads, so I won't dwell on the issue.

Quote:
One benefit that I can see now from using EFI is that you can have two isolated installations of Linux. This is a benefit because if say one grub got messed up, boot to the other and fix it. With just grub, if it got messed up.. time to dig out the dvd's and work on fixing it... EFI would make things easier/faster in that aspect IMHO.
It can, yes. This is largely a matter of poorly-conceived boot loader setups on BIOS, though. People have been setting up "GRUB partitions" that hold GRUB installations that aren't tied to any OS for a while. Such configurations aren't common, though. Certainly GRUB 2's design, with its emphasis on editing configuration files in /etc and then running a script to generate a fresh configuration file, encourages dependence on one OS in the boot loader. Sadly, this is carrying through to EFI, too; Ubuntu, at least, sets up GRUB on EFI systems so that it relies on a configuration file in Ubuntu's /boot/grub directory. In a default configuration, this makes the system's boot susceptible to removal of or damage to Ubuntu.

Also, EFI is dependent on the ESP, and when the system works the way it's theoretically supposed to, you've got dependencies on the state of the NVRAM. This can be a problem because a firmware upgrade or accidental NVRAM clearing can damage the boot loader setup. In this respect, installing a boot manager as EFI/BOOT/bootx64.efi is actually beneficial, since it protects you against NVRAM problems.

So the bottom line is that although EFI offers a boot path that has the potential to be more robust against certain types of damage or system changes, it's a little less rosy when you look more closely. I'm still hopeful it'll be an improvement, but we'll just have to wait and see what it looks like when the dust settles.

Quote:
There is one RPM package that could potentially mess with EFI though... That is the LiveUSBCreator... The reason it can cause a problem is that it's dependancy is EXTLINUX... a MBR boot loader with no EFI Support. I am hesitant on installing additional bootloaders lol.
That type of program certainly needs updates to handle EFI. I haven't been following that program category very closely, though, so I don't know what projects are afoot to make the required changes.
Reply With Quote
Reply

Tags
efi, issues, uefi or hybrid, x8664

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
How to make grub on F17 (uefi w/ grub 1) boot windows 7 (uefi)? premudriy Installation, Upgrades and Live Media 4 21st August 2012 06:58 PM
Updated Bios - it wiped out UEFI menu entries - how can i reinstall Fedoras UEFI menu yossarianuk Using Fedora 1 3rd July 2012 06:59 PM
How to reinstall grub/UEFI on a UEFI install ? Equivalent of chroot, grub-install ? interzoneuk Using Fedora 1 25th June 2012 08:06 PM
Help: UEFI PXEboot of x86_64 RHEL6 lidcs Using Fedora 1 6th January 2012 06:38 AM
Need help with Fedora 15 UEFI x86_64 install to Sager NP8170 laptop planar3d Installation, Upgrades and Live Media 4 5th November 2011 05:54 PM


Current GMT-time: 13:30 (Friday, 24-10-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
Zuenoula Photos on Instagram - Balta Travel Photos on Instagram - Kontich Travel Photos