Quote:
Originally Posted by srs5694
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....
|
Yeah. I followed your steps for getting the EFI to work. If I didn't I just would have said I gave up because this whole thread was (supposed to) be about getting UEFI install to work, and what it's benefits are.
Quote:
Originally Posted by srs5694
Yes. The Linux tool for this task is called "efibootmgr". Type "man efibootmgr" to learn about its options.
|
Thanks. I'll check it out as soon as I get into linux. It would make more info to have a tool like that under the EFI shell though :P (if it's there I couldn't find it. I looked all over the place.)
Quote:
Originally Posted by srs5694
which should theoretically include data on every EFI boot loader installed on the computer and the order in which they're tried.
|
What I meant was that's for all intents and purposes a table with fields: option-name, option device, and option file. That's not that much data compared to the total other data stored in the NVRAM. Unless you have a ridiculous number of boot options. Although I know that's massively oversimplified. BIOS must also store some informaton about boot order in NVRAM too though as it doesn't loose your boot order on hard power off.
Quote:
Originally Posted by srs5694
(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.)
|
That's what I was saying. I like this functionality. It means I don't have a list of a bunch of EFI devices I never use like I do in all my bios computers, and my USB drive's entry doesn't disappear and move to the bottom of my boot order every time I unplug it. I much prefer to be able to make an order and not to have it change just because I unplug a device, run the machine, and then plug it back in. I hate sitting there and scrolling through all my attached devices every time I want to boot from a usb thumb drives. I'd rather have to set up the drive and then have it already set up at top so it boots first whenever it's available.
Quote:
Originally Posted by srs5694
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.
|
Bios stored a TON of diagnostic information on NVRAM in some implementations. My parents ASUS computer with quickboot was a perfect example. It stored a massive amount of data to the nvram so that it could skip most of it's startup checks.
Thank you for all the links to information on other bootloaders. In terms of jjust setting up the kernel's stub bootloader the problem is that until I got a live set up I couldn't access any of the files, since the image is on the /boot partition that A) efi can't load because it's a LVM ext4 partition, B) windows can't load because it's an LVM ext4 partition, and C) Linux can't load because I can't get into linux without access to the image. I should be able to do just that though from a linux shell on my livecd, which is one of the options I was thinking about, at least as a stopgap.
Threaded Mode
