| View previous topic :: View next topic |
| Author |
Message |
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
 Posted: Mon May 13, 2013 8:09 pm Post subject: Booting EFI Kernel Stub |
 |
|
I wanted to use EFI and GPT formated disks when I first installed Gentoo on a new system but trying to make sense out of the tons of documentation I found, none of which seemed to compliment each other. I decided to just install using the old faithful (this method has always worked out of the box for me) BIOS and MBR style disk formating and installing GRUB. While I have a stand alone Windows 7 64 bit machine I can use when and if the situation calls for it. It would be simpler to just install Win7 on this machine for the rare times I need to use it. The requirements I ideally want are Win7 on a separate GPT formated drive, Linux on its own GPT formated drive, eliminate the need for any type of MBR style disk and being able to select the OS to boot from a UEFI BIOS based boot menu.
So after testing the process of converting MBR style drives to UFEI partitioned GPT drives without data loss or corruption and backing up the entire contents of /. I rebuilt my kernel to include the required EFI STUB options and completed the other configurations I thought may be necessary. I even tested to make sure the Kernel could load itself without any GRUB root= setting, which it could. Stuffed in the latest sysresccd and rebooted my system. To my surprise my BIOS recognized it as a UFEI bootable device and booted the computer in UFEI mode. That was the easy part. Using gdisk I converted the drive to GPT with the appropriate EF00 type on the first partition. I then chrooted into my Gentoo system to complete the process and verify my root files system was intact. I made what I thought were the appropriate directories and moved the kernel over.
| Code: |
mkdir /boot/efi
mkdri /boot/efi/boot/
cp /usr/src/linux/arch/x86/boot/bzImage /boot/efi/boot/gs357x84.efi
|
Installed efibootmgr and made the entry to the UEFI shell
| Code: |
efibootmgr -c -d /dev/sda -p 1 -L Gentoo -l '\boot\efi\boot\gs357x64.efi'
|
Checked using efibootmgr
| Code: |
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0001,0002,0005,0003
Boot0000* Gentoo
Boot0001* Hard Drive
Boot0002* CD/DVD Drive
Boot0003 USB
Boot0004* UEFI: Built-in EFI Shell
Boot0005* UEFI: HL-DT-ST DVDRAM GH24NS72
|
Properly exited chroot and rebooted. Loaded the BIOS UFEI Boot Menu and attempted to boot into Gentoo. Screen went black for a couple of seconds and returned to the UFEI Boot Menu. I could not boot Gentoo and of coarse not a single error message as to why. After spending an entire day going over all the documentation again and mucking around with different setups I finally got the Kernel Stub to boot form the UFEUI Bios Boot Menu. What worked was to modify how I chrooted into the system by
| Code: |
mkdir /efi
mount /dev/sda1 /mnt/gentoo/efi
once in
rm -rf /boot
cp /usr/src/linux/arch/x86/boot/bzImage /efi/gs357x64.efi
|
Then using efibootmgr to remove the original Gento UFEI entry and create the new entry and rebooting. Now I can boot into Gentoo using the Kernel Stub. It appears the location of the kernel.efi on my system is critical for booting.
While the BIOS can see the Gentoo entry I made and boots it fine. A couple of questions still remain. It appears my BIOS can detect what type of modes my drives can boot and boots them appropriately.
So why doesn't my UFEI BIOS see my Gentoo Drive as a UFEI bootable device? If I try to boot the Drive directly from the UFEI Boot Menu the system boots to a GRUB screen with the error "GRUB GRUB Hard Disk Error" and hangs up. It appears there is still some GRUB footprints left in the Protected MRB. Is this the case and is there a safe method to remove them.
TIA........  |
|
| Back to top |
|
 |
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
| Posted: Mon May 13, 2013 9:45 pm Post subject: |
|
|
The BIOS detects a disk as EFI bootable from the existence of an EFI boot partition (type EF on MBR, EF00 on GPT). In the absence of custom EFI boot entries, it will load /efi/boot/bootx64.efi by default. If that fails, it falls back to legacy booting.
Or so the theory. In practice, you will find all kinds of smart and not so smart heuristics. For example, whether a bootable flag is set in the MBR, or whether the operating system descriptive string matches some predefined value. |
|
| Back to top |
|
|
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
| Posted: Mon May 13, 2013 10:38 pm Post subject: |
|
|
| chithanh wrote: | The BIOS detects a disk as EFI bootable from the existence of an EFI boot partition (type EF on MBR, EF00 on GPT). In the absence of custom EFI boot entries, it will load /efi/boot/bootx64.efi by default. If that fails, it falls back to legacy booting.
Or so the theory. In practice, you will find all kinds of smart and not so smart heuristics. For example, whether a bootable flag is set in the MBR, or whether the operating system descriptive string matches some predefined value. |
Thank you for your input. It confirms some of what I had discovered from my failed attempts. However on my system at least it also confirms that using the default Gentoo handbook, when it comes to mounting the drives can't be used | Code: |
mount /dev/sda3 /mnt/gentoo
mkdir /mnt/gentoo/boot
mount /dev/sda1 /mnt/gentoo/boot |
Instead | Code: |
mount /dev/sda3 /mnt/gentoo
mkdir /mnt/gentoo/efi
mount /dev/sda1 /mnt/gentoo/efi |
Which worked darn well once everything else was configured.
I hadn't tried to boot without using a custom entry created with efibootmgr, a theory I am more than happy to test. FYI: I have an AsRock 990FX Extreme 4 Motherboard with the latest BIOS installed. I have yet to find any suitable information about the UEFI Shell from AsRock and how to make use of it.
I am still confused about the GRUB error I get when trying to boot the "UEFI BIOS MENU" HD entry directly. I expected the system to either boot the Kernel stub or dump me back to the MENU, not throw a GRUB error.
TIA.....  |
|
| Back to top |
|
|
srs5694
Guru
Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI
|
| Posted: Mon May 13, 2013 11:05 pm Post subject: Re: Booting EFI Kernel Stub |
|
|
| OldTango wrote: | | Code: |
mkdir /boot/efi
mkdri /boot/efi/boot/
cp /usr/src/linux/arch/x86/boot/bzImage /boot/efi/boot/gs357x84.efi
|
|
Conventionally, the EFI System Partition (ESP) is mounted under Linux at /boot/efi; however, some users (particularly on Arch Linux) like to mount it at /boot, and in fact there's a proposal to make that semi-standardized.
Note that simply creating the /boot and /boot/efi directories is insufficient; you must mount the ESP somewhere. Depending on where you mounted it (if you did), you copied bzImage to either efi/boot/gs357x84.efi or boot/gs357x84.efi on the ESP. Neither location is a conventional place for EFI boot loaders, which normally reside in subdirectories of a directory called "EFI", such as "EFI/gentoo". Of course, an unconventional location doesn't guarantee failure; but....
| Quote: | Installed efibootmgr and made the entry to the UEFI shell
| Code: |
efibootmgr -c -d /dev/sda -p 1 -L Gentoo -l '\boot\efi\boot\gs357x64.efi'
|
|
The "-l" option to efibootmgr takes the path to the boot loader relative to the ESP's root. You specified the location relative to the Linux root, which is not the same thing. This is almost certainly why your first attempt failed.
| Quote: | Checked using efibootmgr
| Code: |
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0001,0002,0005,0003
Boot0000* Gentoo |
|
IMHO, it's generally best to use "efibootmgr -v" when checking your boot loader entries. The reason is that "-v" includes critical information like the filename associated with each entry. The output you posted is not very useful because it's restricted to the boot number and entry name (but not the filename) for each entry.
| Quote: | What worked was to modify how I chrooted into the system by
[code]
mkdir /efi
mount /dev/sda1 /mnt/gentoo/efi |
The ESP's mount point in Linux is largely irrelevant, at least on an abstract level. It does matter for some utilities, though -- for instance, rEFInd's installer looks for the ESP at /boot or /boot/efi, and won't work if it's mounted elsewhere. You've also got to know where it's mounted yourself, of course, and adjust any commands that reference files on the ESP.
There's one special case where the ESP's mount point is very important: If you mount the ESP at /boot, then normal procedures and tools that copy your kernel to /boot will end up copying your kernel to the ESP. This may be handy if you're using the EFI stub loader or some other tool that relies on the EFI being able to read the kernel (such as ELILO). This is why mounting the ESP at /boot is popular on Arch Linux; those users favor gummiboot, rEFInd, or a direct boot of the kernel (as you're doing), so putting the kernel on the ESP simplifies configuration.
| Quote: | | It appears the location of the kernel.efi on my system is critical for booting. |
I have heard of systems where this is the case, but in your case I think you simply erred in your initial efibootmgr command.
| Quote: | | So why doesn't my UFEI BIOS see my Gentoo Drive as a UFEI bootable device? If I try to boot the Drive directly from the UFEI Boot Menu the system boots to a GRUB screen with the error "GRUB GRUB Hard Disk Error" and hangs up. |
First, despite manufacturers' abuse of the terminology, you don't have a "UEFI BIOS"; you have a "UEFI" or "UEFI firmware." A BIOS is an entirely different type of firmware, which you don't have. (Your EFI does have a BIOS compatibility layer, known also as a "CSM" or "legacy boot support." That doesn't make your EFI a BIOS any more than WINE makes Linux Windows, though.)
More importantly, under EFI, a hard disk is not bootable, at least not in the same way it is under BIOS. EFI boots using files, and the point of using efibootmgr is to tell the firmware which file(s) on the hard disk are bootable. This contrasts with BIOS, which blindly reads the first sector of a disk to boot it, making the presence or absence of boot code in that sector a meaningful shorthand for the disk being bootable or not.
That said, there is a default/fallback filename that most EFIs will attempt to boot if no other entries work: EFI/BOOT/bootx64.efi (on x86-64 systems). Thus, if you create an entry with that name on the ESP, it should boot if no other EFI boot loaders work. I can't guarantee that you'll see an entry for it in the firmware's boot manager. That detail isn't laid out in the EFI specification, AFAIK, so it varies a great deal from one implementation to another.
| Quote: | | It appears there is still some GRUB footprints left in the Protected MRB. Is this the case and is there a safe method to remove them. |
You can wipe the BIOS stage 1 boot loader as follows:
[code]
dd if=/dev/zero of=/dev/sda bs=440 count=1
[/code]
This command, typed as root, will wipe the BIOS boot code from the MBR of /dev/sda without damaging anything else; however, you must be very careful when typing that command! If you enter any value incorrectly, and particularly the "bs=" or "count=" values, you could end up trashing the disk, or at least doing considerable damage to it. Likewise, omitting either the "bs=440" or "count=1" option will end up damaging the disk. |
|
| Back to top |
|
|
srs5694
Guru
Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI
|
|
| Back to top |
|
|
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
| Posted: Tue May 14, 2013 3:16 am Post subject: Re: Booting EFI Kernel Stub |
|
|
| srs5694 wrote: |
Conventionally, the EFI System Partition (ESP) is mounted under Linux at /boot/efi; however, some users (particularly on Arch Linux) like to mount it at /boot, and in fact there's a proposal to make that semi-standardized.
Note that simply creating the /boot and /boot/efi directories is insufficient; you must mount the ESP somewhere. Depending on where you mounted it (if you did), you copied bzImage to either efi/boot/gs357x84.efi or boot/gs357x84.efi on the ESP. Neither location is a conventional place for EFI boot loaders, which normally reside in subdirectories of a directory called "EFI", such as "EFI/gentoo". Of course, an unconventional location doesn't guarantee failure; but.... |
So based on this information I should consider using a directory structure more like /boot/efi/EFI/gentoo/gs357x64.efi and pointing efibootmgr to the correct location.
| srs5694 wrote: |
| Code: |
efibootmgr -c -d /dev/sda -p 1 -L Gentoo -l '\boot\efi\boot\gs357x64.efi'
|
The "-l" option to efibootmgr takes the path to the boot loader relative to the ESP's root. You specified the location relative to the Linux root, which is not the same thing. This is almost certainly why your first attempt failed. |
This explains a lot. Had the same problem when I first started using GRUB in that it starts it's count at 0.
| srs5694 wrote: |
IMHO, it's generally best to use "efibootmgr -v" when checking your boot loader entries. The reason is that "-v" includes critical information like the filename associated with each entry. The output you posted is not very useful because it's restricted to the boot number and entry name (but not the filename) for each entry. |
Thanks for the Tip. I was more concerned about getting my system booting at the time than reading another complete manual, but rest assured it will be read in its entirety over the next couple of days.
| srs5694 wrote: |
The ESP's mount point in Linux is largely irrelevant, at least on an abstract level. It does matter for some utilities, though -- for instance, rEFInd's installer looks for the ESP at /boot or /boot/efi, and won't work if it's mounted elsewhere. You've also got to know where it's mounted yourself, of course, and adjust any commands that reference files on the ESP.
There's one special case where the ESP's mount point is very important: If you mount the ESP at /boot, then normal procedures and tools that copy your kernel to /boot will end up copying your kernel to the ESP. This may be handy if you're using the EFI stub loader or some other tool that relies on the EFI being able to read the kernel (such as ELILO). This is why mounting the ESP at /boot is popular on Arch Linux; those users favor gummiboot, rEFInd, or a direct boot of the kernel (as you're doing), so putting the kernel on the ESP simplifies configuration. |
Yes, I would like my system to boot the Kernel Stub directly by default MOST of the time except when setting up and testing a NEW KERNEL install. At that time I could use efibootmgr to set custom entries for booting the NEW KERNEL correct?
| srs5694 wrote: |
First, despite manufacturers' abuse of the terminology, you don't have a "UEFI BIOS"; you have a "UEFI" or "UEFI firmware." A BIOS is an entirely different type of firmware, which you don't have. (Your EFI does have a BIOS compatibility layer, known also as a "CSM" or "legacy boot support." That doesn't make your EFI a BIOS any more than WINE makes Linux Windows, though.)
More importantly, under EFI, a hard disk is not bootable, at least not in the same way it is under BIOS. EFI boots using files, and the point of using efibootmgr is to tell the firmware which file(s) on the hard disk are bootable. This contrasts with BIOS, which blindly reads the first sector of a disk to boot it, making the presence or absence of boot code in that sector a meaningful shorthand for the disk being bootable or not.
That said, there is a default/fallback filename that most EFIs will attempt to boot if no other entries work: EFI/BOOT/bootx64.efi (on x86-64 systems). Thus, if you create an entry with that name on the ESP, it should boot if no other EFI boot loaders work. I can't guarantee that you'll see an entry for it in the firmware's boot manager. That detail isn't laid out in the EFI specification, AFAIK, so it varies a great deal from one implementation to another. |
Thanks for clarifying this and its a shame others don't do the same in their documentation as it would greatly reduce the confusion.
| srs5694 wrote: |
You can wipe the BIOS stage 1 boot loader as follows:
| Code: |
dd if=/dev/zero of=/dev/sda bs=440 count=1
|
This command, typed as root, will wipe the BIOS boot code from the MBR of /dev/sda without damaging anything else; however, you must be very careful when typing that command! If you enter any value incorrectly, and particularly the "bs=" or "count=" values, you could end up trashing the disk, or at least doing considerable damage to it. Likewise, omitting either the "bs=440" or "count=1" option will end up damaging the disk. |
Is it safe to use on a mounted device or only on an unmounted one?
Thanks a lot for all the GREAT documentation you have made available to everyone. |
|
| Back to top |
|
|
srs5694
Guru
Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI
|
| Posted: Tue May 14, 2013 3:43 am Post subject: Re: Booting EFI Kernel Stub |
|
|
| OldTango wrote: | | So based on this information I should consider using a directory structure more like /boot/efi/EFI/gentoo/gs357x64.efi and pointing efibootmgr to the correct location. |
That would be more conventional and therefore create less risk of confusion when communicating about it or reading documentation yourself.
| Quote: | | Yes, I would like my system to boot the Kernel Stub directly by default MOST of the time except when setting up and testing a NEW KERNEL install. At that time I could use efibootmgr to set custom entries for booting the NEW KERNEL correct? |
Yes. If your firmware's boot manager is half-decent (that is, about as good as they come, as opposed to essentially useless, which some of them are), you'll be able to create entries for multiple kernels and select between them at boot time. You can then remove the old kernel once you're sure the new one works. Conceptually, this is much like managing kernels with LILO or GRUB (especially GRUB Legacy, before GRUB 2's zoo of scripts came into the picture). It's just that you'd use efibootmgr to adjust the firmware's built-in boot manager settings rather than edit an /etc/lilo.conf or /boot/grub/menu.lst file.
An extra tip: Download and prepare a USB flash drive or CD-R version of rEFInd. One weakness of EFI-mode booting is that boot settings are stored in NVRAM, and sometimes the NVRAM can get wiped. For instance, some EFIs "helpfully" delete invalid entries, which means that you'll lose all your boot manager entries if you unplug your hard disk and power on the computer. Having rEFInd on a removable medium is helpful in these cases because it auto-detects boot loaders, including Linux kernels, in conventional locations, so you'll be able to get into your computer after such an occurrence.
| Quote: | | srs5694 wrote: |
You can wipe the BIOS stage 1 boot loader as follows:
| Code: |
dd if=/dev/zero of=/dev/sda bs=440 count=1
|
|
Is it safe to use on a mounted device or only on an unmounted one? |
Either way is fine.
| Quote: | | Thanks a lot for all the GREAT documentation you have made available to everyone. |
You're welcome. |
|
| Back to top |
|
|
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
| Posted: Tue May 14, 2013 3:48 am Post subject: |
|
|
I was able to find several, but was more concerned about documentation specific to my system board board. It would appear not all implementations are equal.
| srs5694 wrote: | | OldTango wrote: | | I am still confused about the GRUB error I get when trying to boot the "UEFI BIOS MENU" HD entry directly. I expected the system to either boot the Kernel stub or dump me back to the MENU, not throw a GRUB error. |
When you converted the disk from MBR to GPT, you overwrite the GRUB 2nd-stage boot code in the sectors immediately following the MBR. Thus, the BIOS-mode GRUB can't cope, since the better part of it is missing. The best you'd get is an error message. |
I had removed GRUB knowing that I wasn't going to be using it and realizing I could always reinstall if necessary. It just didn't dawn on me until now that the removal process won't clean my system completely of GRUB. It makes sense the removal process wouldn't muck about in the MBR.
I will be working on this some more over the next couple of weeks in hope to find the optimum setup in both the kernel and the system configuration. A little unnerving though as this is my daily used workstation I am screwing with..... 
Again Thanks. |
|
| Back to top |
|
|
srs5694
Guru
Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI
|
| Posted: Tue May 14, 2013 2:34 pm Post subject: |
|
|
| OldTango wrote: |
I was able to find several, but was more concerned about documentation specific to my system board board. It would appear not all implementations are equal. |
The EFI shell doesn't really do much, if anything, that varies with the motherboard model or firmware version; the same shell run on my computer will work just like the shell on your computer, with the caveat that our disks and NVRAM contents are different.
That said, there are two major versions of the EFI shell available: version 1 and version 2. There are differences between these two versions, and the version 2 shell doesn't always run on computers with pre-2.31 EFIs. There are also multiple builds of each version available, and some features are compile-time options, so there can be significant differences between shell binaries. These differences have nothing to do with your motherboard or EFI implementation, though, unless of course a shell is built into your firmware (which is rare, but possible). Even in that case, though, you can run another shell by installing it on your computer and configuring your boot manager to launch it. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
