Description of problem: In order to install F16 alpha on my new stinkpad with a sandy bridge2 proc. I had to disable legacy boot. Disable the search for potential legacy boot. Not doing so results in an installed system, that hangs at boot with like a _ in the top left corner for at least 20 minutes. (This should be in the release notes or docs.) (I didnt try to set the boot options with the "quick boot selection"/F12 key menu.) Now after I got it to install, I tried reinstalling, and that wouldn't boot either. After several attempts, I figured out the boot menu in EFI was not being overwritten by the second install. Clearing the "Fedora" boot (why not Fedora 16?) in the bios/uefi menu eliminates the issue. One other thing I did notice was The graphic on the boot screen changed. When I first did an install the Fedora logo covered the entire screen, then after i merely cleared the "fedora" in EFI, the fedora logo shrank in about half and was sitting in the middle of the screen and you could see the kernel load. (which was actually kind of nice.. but that didnt happen after I changed the boot setting to reinstall F15, then reinstall F16. It didnt seem to have much affect other then just looking kind of tacky. However on the bright side, It did actually install properly. I'm just worried about a kernel upgrade or if I change a setting in the bios/EFI.
Did the kernel upgrade to the RC3. It hung at [Linux EFI setup= 0x0bf, size 0x422db0 ] (the caps lock key was blinking while I let it sit for about 10 minutes..) On the bright side, both the old and new kernels showed up in the fedora menu, and I was able to do a soft reboot using the old kernel.
I should also note it isn't getting to the Init address. The / system is on btrfs if that makes any difference.
During the update with the Rc4 kernel, I received: Installing : kernel-3.1.0-0.rc4.git0.0.fc16.x86_64 68/133 grubby fatal error: unable to find a suitable template I finally chased this down. /boot/efi/EFI/redhat/grub.conf It just this added: initrd /initramfs-3.1.0-0.rc4.git0.0.fc16.x86_64.img It boots fine now.
You do have grub installed too, right? In that case it is a duplicate of a bug 725185. (I do however not know why it isn't fixed in grubby and left to the sysadmin to decide which boot loader he wants to use.)
It looks as though it is a duplicate. However I will shed some more light on it.. I reinstalled with graphical desktop, virtualization, and development tools, ran and update last night. Before rebooting, I thought to check the /boot/efi/EFI/redhat/grub.conf file. I went to look for the exact name in /boot of the initramfs file and the file was not present there. It did appear -after- I rebooted the system and then I changed the grub.conf file to make it work. [root@oinik redhat]# rpm -qa |grep grub grub-0.97-75.fc16.x86_64 grub2-1.99-1.fc16.x86_64 grubby-8.1-1.fc16.x86_64 [root@oinik redhat]# ls /boot Am I supposed to pick between grub or grub2?
(In reply to comment #5) > Before rebooting, I thought to check the /boot/efi/EFI/redhat/grub.conf file. (A grub config file - not a grub2 config file.) > I went to look for the exact name in /boot of the initramfs file and the file > was not present there. It did appear -after- I rebooted the system and then I > changed the grub.conf file to make it work. The /boot/initramfs-something didn't exist before you rebooted but it existed after the reboot? Strange. Can you reproduce that? > [root@oinik redhat]# rpm -qa |grep grub > grub-0.97-75.fc16.x86_64 > grub2-1.99-1.fc16.x86_64 > grubby-8.1-1.fc16.x86_64 The grub2 EFI loader is found in the grub2-efi package (which for some reason will conflict with grub), so actually you are using grub "1" and have filed this issue at the wrong component. > Am I supposed to pick between grub or grub2? Yes.
My apologies for filing against the incorrect version. I didnt see a place to choose in the installer any time I installed.. The /boot/grub.cfg file is empty. But that is understandable since the grub2-efi package can't be installed.. and the grub.x86_64 1:0.97-77.fc16 update has dependency issues.. Can I copy the grub.config file to /boot/grub2/grub.cfg, install grub2-efi and have it work or do I have to do a lot of twiddling?
I don't know what the officially recommended way to do EFI boot on Fedora 16 is. grub2-efi works for me but is apparently not fully integrated and do not work out of the box, so I guess you should stick to plain grub. The new grub package do not have dependency issues. It intentionally conflicts with grub2. grub2 (the non-efi variant) has nothing to do on an EFI system anyway, so just remove it and you will be one step closer to a solution. I assume /boot/grub.cfg is a typo and you meant something else.
Thank you. i will stick with grub-efi for now. I really wanted to get to testing other things besides a bootloader.. :) the /boot/grub2/grub.cfg is currently an empty file that came with the system. I didn't add it. [so@oinik ~]$ cat /boot/grub2/grub.cfg [so@oinik ~]$
(In reply to comment #6) > The /boot/initramfs-something didn't exist before you rebooted but it existed > after the reboot? Strange. Can you reproduce that? I haven't tried to back out of the kernel package and to try yet no. But that is what I saw. it is an ext4 system, and maybe it didn't flush cache correctly or something.
(In reply to comment #9) > Thank you. i will stick with grub-efi for now. Note that there is no grub-efi - there is grub2-efi which you probably shouldn't use and the grub package that contains some efi functionality that might work for you. > the /boot/grub2/grub.cfg is currently an empty file that came with the system. Again again: That file belongs to grub2, and you shouldn't have that package installed at all.
My bad it was a typo, it is grub.efi. [root@oinik redhat]# ls -l /boot/efi/EFI/redhat/ total 256 -rwx------. 1 root root 64 Sep 5 12:10 device.map -rwx------. 1 root root 1003 Sep 6 08:42 grub.conf -rwx------. 1 root root 240647 Jun 29 10:51 grub.efi [root@oinik redhat]# -- I will remove grub2. Can I transfer this issue to the grub team? or do i have to file another problem?
https://fedoraproject.org/wiki/Features/Grub2#Things_that_still_have_to_be_tested.2Fworked_on lists "EFI mode". I don't know what else is left here.
Moved to grub since that is one of the components. not grub2 as I originally thought. :) F16 TC2 dvd isn't booting at all on this system with EFI only enabled, like I have to use to get F16alpha installed. Putting it into legacy mode, lets me install but then after installation it doesn't find a boot device. I didnt find grub-efi.. i tried booting off the dvd as a rescue disk, and efibootbgr board saying it couldnt find /procfs or sysfs. I tried removing grub2 and installed grub, and that failed with like wrong elf-type. I apologize for not digging into this harder but unfortunately, this is the only computer I have to "use" at this location. im attaching some files after the initial install with legacy support enabled since that is the only way it would install.
Created attachment 522578 [details] the dracut log from the F16 beta tc2 x86_64 dvd install
Created attachment 522579 [details] the install log from the F16 beta tc2 x86_64 dvd install
Created attachment 522580 [details] install.log.syslog log from the F16 beta tc2 x86_64 dvd install
Created attachment 522581 [details] anaconda-ks.cfg log from the F16 beta tc2 x86_64 dvd install
Created attachment 522582 [details] anaconda.yum.log log from the F16 beta tc2 x86_64 dvd install
Created attachment 522583 [details] anaconda.xlog log from the F16 beta tc2 x86_64 dvd install
Created attachment 522584 [details] anaconda.syslog log from the F16 beta tc2 x86_64 dvd install
Created attachment 522585 [details] anaconda.ifcfg.log log from the F16 beta tc2 x86_64 dvd install
Created attachment 522586 [details] anaconda.program.log log from the F16 beta tc2 x86_64 dvd install
Created attachment 522587 [details] anaconda.storage.log log from the F16 beta tc2 x86_64 dvd install
Created attachment 522588 [details] grub2-mkimage results from the F16 beta tc2 x86_64 dvd install I may not have had the syntax right but I definately wasn't expecting this error. and this is the ELF error referred to in the comments. It took me quite a while to get back to the net..
Another weird error I got was W: Possible missing firmware "nouveau/nvc0_fuc409c" for kernel module "nouveau.ko" I -think- this may have been when I ran the modprobe for EFIVENVARS or something akin to that ( it think the suggestion was from efibootmgr). I apologize for not being able to take better notes during this. I hope this helps and i didnt miss anything.
(In reply to comment #26) > Another weird error I got was > W: Possible missing firmware "nouveau/nvc0_fuc409c" for kernel module > "nouveau.ko" Not related - but annoying. See http://lists.fedoraproject.org/pipermail/kernel/2011-July/003210.html
(In reply to comment #25) > grub2-mkimage --format=x86_64-efi --directory=/boot/grub2 > grub2-mkimage: error: invalid ELF header. > > I may not have had the syntax right but I definately wasn't expecting this > error. and this is the ELF error referred to in the comments. It took me quite > a while to get back to the net.. As you can see this is a grub2 command, not a grub command. Further, there is no EFI support in the grub2 package - that is in the grub2-efi package where you have to use grub2-efi-mkimage instead. Besides that: you shouldn't use that directly but use the grub2-efi-install wrapper. I don't know what your problem with grub and efi is ... but as mentioned in my comment on bug 725185#c22 I don't understand how it was supposed to work at all.
As stated previously: F16 tc2 Beta, could only do a legacy install, because the dvd would not boot with EFI enabled. After enabling legacy mode, and installing, it did not reboot. That is a grub2 issue. Grub was not installed as the logs will show.
grub2 do intentionally not support efi. You need grub or grub2-efi for that. The issue is that grub intentionally conflicts with grub2, and grub2-efi isn't ready yet, and neither of them are thus installed.
(In reply to comment #30) > The issue is that grub intentionally conflicts with grub2, and grub2-efi isn't > ready yet, and neither of them are thus installed. - that was under the (incorrect) assumption that grub2 _is_ installed. Anaconda should however be able to install either grub or grub2 depending on which bootloader is used. (In reply to comment #29) > After enabling legacy mode, and installing, it did not > reboot. That is a grub2 issue. Ok, agreed. If the system has a legacy bios and is supported then it should work and it is a bug if it doesn't. (But then I don't understand why EFI keeps popping up.)
When I had either legacy only, or legacy+EFI support enabled, I was unable to install F16 alpha from the dvd. When I switched to EFI only, i was able to install. The F16 beta tc2 dvd I tried, I had to use legacy settings to get it to boot, but then it didnt boot after the install. Also using the F16 alpha disk, the "system rescue" boot option is not available (with EFI) which differs from the legacy install. And i suspect this isnt all a grub/grub2 issue, as grubby is tool giving errors even with the kernel updates.
grubby is just reporting the facts when it complains on initial kernel installs. There _is_ no previous kernel entry it can duplicate; anaconda will create it later. Almost the same happens on a real update: the previous kernel is invalid when grubby runs, so again there is no template. You mention several other issues that perhaps would be better suited with separate bug reports. What is the core issue here and to which component should it be assigned? I see some indications of anaconda having issues when crossing between EFI and BIOS boot.
I don't know if it would be suited to more bug reports or not. I think this summarizes the problems. The F16 alpha install, if you install with EFI you have to manually delete the Fedora entry out of EFI boot setting before you can reinstall again. F16alpha EFI -There is no rescue and restore boot option and using single as an additional flag to the grub line doesn't work. You have to boot off different media. F16alpha EFI - an kernel upgrade does not put the initramfs file properly in the grub config file. OR it is not present at the time it tries to do this. (as I noted I didn't actually noticed the file until after a reboot once, and I havent tried to reverify this because I keep forgetting to look again.) But that would explain why the initramfs file is missing from grub.conf IE whatever updates the grub.conf file in the kernel update probably verifies whether the file exists..)(adding the initrd line to the grub file did make it work.) F16 beta tc2 DVD did not boot in EFI mode at all. Installing in legacy mode, it installed but would not boot after the installation completed. Now I don't recall if there was a white cursor block in the upper left corner or not, or whether that was something else. (which may be indicative of it was trying to boot using EFI but it didnt find an EFI partition to boot from as an EFI partition wasn't created even though it was marked inside the "bios" screen to use legacy. Is that more clear?
(In reply to comment #34) > Is that more clear? My $.05: That doesn't sound like one issue, and I don't know which component it should be assigned to. Issues with the "old" alpha release are probably no longer relevant at all. Much has been changed and many bugs has been fixed. There are several other unresolved and heated issues regarding boot loaders, for example bug 737261.
we fixed up a lot of stuff with EFI for the Beta. can you please try with Beta and give us a status update? thanks. you should be able to do an EFI-native install from the DVD or netinst (not from a live image) and it should work, installing grub not grub2 as the system bootloader. both packages will be installed, and anaconda will warn you about this, but if you power through the warning it ought to work.
I will give it a try and report back asap.
Sorry this took so long.. I tried native EFI, and after selecting the packages, base/dev tools/virtualization/graphical desktop, it gave an error package grub conflicts with package grub2.x.x.x64.rpm, would you like to change your package select/exit/continue, i continued, then it completed the install, and gave a warning saying there was an error your system may not be bootable right before the restart. It would not restart. The initrd, and vmlinuz (kernel stuff) was not in /boot nor was there a grub.conf in /boot/efi/EFI/redhat This is slightly different, then kernel prior to rc6 on the alpha that did not write the initrd image line successfully to the grub.conf file in /boot/efi/EFI/redhat, and you had to manually add it to get it to work. It did remove the old "Fedora" entry in the EFI boot menu, However, it didnt replace it with anything. I dont know if you have to reboot in order for the delete to save, before adding an entry, or what the deal on that is. If I tried to boot via legacy mode, the dvd came up with the linux-EFI kernel for the first boot line, however, the initrd line didnt have the EFI tag to it (like the EFI install) and it also failed with a warning about grub/grub2 conflict, it unexpectedly (to me) added the EFI partition in default install, it gave a warning about possibly not being able to reboot. I didn't see the kernel or initrd image or the /boot/efi/EFI/redhat directories were missing. I haven't tried in mixed mode yet.. but im assuming that will not work either.
"I tried native EFI, and after selecting the packages, base/dev tools/virtualization/graphical desktop, it gave an error package grub conflicts with package grub2.x.x.x64.rpm, would you like to change your package select/exit/continue, i continued" that's normal for the Beta. "and gave a warning saying there was an error your system may not be bootable right before the restart." that's not, it means something went wrong with bootloader installation. Can you please attach anaconda.log , storage.log and program.log from the affected install? Thanks!
Yes, but there is no way to unselect grub or grub2 to make a choice. :) I will attach logs but I will have to reinstall first. I screwed around with it a bit trying to get it to boot properly. (I want to get this written first.) The "Fedora" selection in the UEFI menu was solved by running efibootmgr and deleting the current boot order, then creating and adding a boot order that included Fedora, it was defined in the efibootmgr list (not in the enabled/disabled menu in the bios menu.) that got me to the grub (.97) command prompt. It also did some tweaking the bios, I was getting a few strange occurrences of (paraphrased) "unable to save lenovo.security, 000x9" in the actual bios menus when i was trying to change the boot orders. (There were 2-3 different errors, depending on what I changed in the bios. ) This was resolved with pulling the plug and the battery and waiting 5 minutes. Then it acted mostly fine, except now the disabled boot settings aren't showing up.. and the dvd boot hung a couple of times, "probing hardware" When i tried to use grubby, and even after upgrading it to what was in updates/latest, it was still giving the no template available error, which I think it because there isnt an existing grub.cfg, or grub.conf file to add/append to. I saw something similar when I tried to bump the kernel up to the rc9 also.
Created attachment 528405 [details] anaconda.log
Created attachment 528406 [details] anaconda.storage.log
Created attachment 528407 [details] anaconda.program.log
Created attachment 528408 [details] anaconda.syslog f16 beta adding this because: 12:50:10,670 WARNING kernel:[ 1274.217760] efivars: set_variable() failed: status=8000000000000009 there is other EFI information in there too which may or may not be helpful.
"Yes, but there is no way to unselect grub or grub2 to make a choice. :)" That's fine. The Beta installs both packages. This causes yum some problems post-install, but for purposes of installation, it works okay. It's a known issue and is not causing your problem. "When i tried to use grubby, and even after upgrading it to what was in updates/latest, it was still giving the no template available error, which I think it because there isnt an existing grub.cfg, or grub.conf file to add/append to." It throws the error but still actually updates the file, if you check it. At least, that's the behaviour I've seen on other systems so far. "12:50:10,670 WARNING kernel:[ 1274.217760] efivars: set_variable() failed: status=8000000000000009" that does indeed look like the most likely culprit. from the timing - the four hour gap is some odd thing with anaconda, I think it's timezone vs. UTC stuff - that looks like the response to the 'efibootmgr' command, which could explain why it failed to add an entry. Could you retry with Final TC1 - dl.fedoraproject.org/pub/alt/stage/16.TC1 - and see how that goes?
(In reply to comment #45) > "When i tried to use grubby, and even after upgrading it to what was in > updates/latest, it was still giving the no template available error, which I > think it because there isnt an existing grub.cfg, or grub.conf file to > add/append to." > > It throws the error but still actually updates the file, if you check it. At > least, that's the behaviour I've seen on other systems so far. new-kernel-pkg will invoke grubby for all the boot loader config files it can find. It will be silent on success and give confusing error messages for invalid (and unused) boot loader configs.
I found a bios upgrade for this system. Do you want me to try and upgrade the bios or try to install Final TC1? (the first 5 attempts for the bios update failed, 2 timed completely out, and 3 gave an error unable to install). I just ran the system recovery disks, and was going to try directly from windows to do this. But I can try TC1 before doing the upgrade and rerun the restore. Am I the only one having issues with this? (excluding Mac peeps because efi is slightly different for them.) These are the bios fixes: Version 1.30 and 1.31 [Important updates] Nothing. [New functions or enhancements] - Enhanced the warning function of the ThinkPad Battery 27++ (9 cell slice). [Problem fixes] - Fixed an issue where the computer might not be booted from bootloader program. - Fixed an issue where a 1820 error might occur at power-on when the external fingerprint reader device was attached to the computer while the integrated fingerprint reader was disabled in the ThinkPad Setup. - Fixed an issue where the computer might fail to boot when connected the Smartphone with the USB port. - Fixed an issue where the ThinkPad Battery 27++ (9 cell slice) might not supply power even when the internal main battery became empty.
Okay I installed the Bios 1.31 upgrade which remarkably worked the first time without errors after running the system restore inside win7. (so much for the lenovo bootable ISO crap) I reinstalled using the F16 Beta dvd again (the Final TC1 isn't done downloading yet) It came up just fine without the error at the end. (the only error was the grub:grub2 package conflict which is expected.) Thank god..
okay, that's good. I guess one or other of your tweaks resolved some problem which the bootloader installation step was running into. shall we close this now?
I think there needs to be a warning in the docs or the installer about making sure you upgrade your firmware/bios before updating. Or at least in that final step where it says "your system may not be bootable". to say, "your system may not be bootable, one possible cause is your bios/firmware version or settings." Off the top of my head this was a pheonix bios, and it was fixed in the last two months. It isn't something a lot of people think about doing especially when they already have a previously working system. All I am saying is I don't think the Lenovo's are the only ones with this issue. (It uses a Pheonix bios, and although it was customized, I don't think it is all on lenovo. I could be wrong.). Given most people don't think about updating their bios/firmware to begin with. There maybe a lot of frustrated users that give up and say Fedora sucks, "I can't even get it to install" and of course these are the same users that probably won't read the install notes either. I was going to try a reinstall to see if it worked but I don't know when I will have time to test it now. Otherwise, I think this problem can be closed.
that'd be a separate issue, and isn't likely to be changed this late. (apart from anything, there are translation problems).