On 11/17/2013 04:10 PM, Alan Feuerbacher wrote: > On 11/16/2013 6:10 PM, Dan McGhee wrote: > > > <snipped your answers to my questions. Thank you. They helped.
> For background on my comments below: > Motherboard: ASUS P8Z77-V LK with latest BIOS update #1104 > Intel i7-3770K > 16G Corsair DDR3 > 2 Western Digital 2TB hard drives > One drive has Fedora 19 installed on it. > The other drive has all the LFS stuff on it. > > I had a setback today. Up through this morning, I was able to execute > "Launch EFI Shell from filesystem device", and to do various things in > the EFI shell. But after making some changes to my hard drive > arrangement several times in an attempt to get the system to boot up, > this simply quit working. No matter what I name the EFI shell -- > shellx64.efi and variations of that -- and no matter which hard drive I > power up -- one or the other or both -- and no matter which SATA slot I > plug the drive(s) into, the BIOS will not launch the EFI shell. This, > even after I updated the BIOS again. So I've filed a technical request > with ASUS Support to try to get some explanation, and hopefully > documentation, on what's going on. I'm really frustrated because it's > like the ASUS BIOS changes itself without input from me. > > The really weird thing about the ASUS board is that no matter which SATA > slot I put the hard drives in, it always finds the Fedora Linux image, > but never the LFS image. This tells me that the BIOS is doing some > undocumented things. I had a similar experience but on only one hard drive. I would run an experiment and try to boot. The boot would fail and the System Boot Manager would remove my LFS entry and write one for Ubuntu. There was a time when, just trying to see what would happen, I had four entries for Ubuntu. I learned that there was at least one thing I needed to do: not use efivars but efivarfs. Once I did this, I could "keep" my LFS entries--although I still couldn't get LFS to boot. It's interesting that you're having a similar experience but with Fedora. That distro, along with Ubuntu and OpenSuse, have paid Microsoft and can use "secure boot." Since the key and the signature reside in the firmware, I'm wondering if it isn't the firmware that's giving priority to Ubuntu in my case and Fedora in yours. Microsoft can "black list" any signature it wants at any time. These revisions are installed by means of "Windows Update." Keys are OEM specific, and organizations like ASUS and HP incorporate them into their firmware. These OEM's can change their key configurations at any time. I'm guessing they do it through BIOS updates. Your story really interests me. > There is only one other option that's keeping me from booting in this > environment. It's so distasteful that I don't even want to write it. > But, at least in my firmware, it may be necessary for me to "sign" my > kernel. That's not even for "secure" boot. I hope that's not true. > What are the implications of that? Why is it so distasteful? > The introduction to the answer to your question is what I wrote above. At its worst, the situation could be, or become, that an individual must register a key with the OEM to install anything other than what came on the computer--or even use the firmware. What's worse is that an OEM could "black list" my key on my own computer. For what reason, I don't know, but it's an extension of the logic. I just don't like any person or organization telling me how to operate and what I can run on my own machines. I hope I don't sound like a "conspiracy theorist." I'm not. But look at what has happened in the "Windows World." We can't even get installation disks with our computers any more. That was a 3/4 rant. I apologize. One conclusion that emerges as a result of yours, mine and Geoff's experiences is that GRUB built from source may not be able to deal with the EFI environment in the way we're used to. I don't know how, or even if, the distros have modified GRUB in their packages. Everything I've read and all my experiements say that GRUB2 should work. Thus far, I haven't been successful--almost, but not quite. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
