You are not logged in.

#1 2013-06-24 18:54:31

Kongar
Member
Registered: 2013-06-24
Posts: 5

Problems with efibootmgr - noob question

Hello all.  Total noob trying my hand at arch.  I recognize there actually are stupid questions, and I hate making this post - but apparently I'm stupid because I'm stuck wink  May I ask some for some basic confirmations to make sure I'm not beating my head against the wall for nothing?

Situation: efibootmgr command at the end of the chroot section of the beginner's guide doesn't work.  I'm getting "efibootmgr no such file or directory found" error.  I've been googling and searching through these forums, and the common answer seems to be "make sure you're UEFI booted and not BIOS/legacy"  I'm pretty damn sure I am, but - well it's not working =\  /sys/firmware/efi exists when I boot off the DVD (made form the iso)  At first, it booted legacy off that DVD, and that folder didn't exist.  So I forced "UEFI only" in the bios, and that fixed that directory not existing.

Stupid question #1 - I can boot UEFI from a DVD, right?  ie I don't NEED a USB stick?  There's quite a few posts here suggesting you need a properly formatted USB stick.  But the DVD should work just fine, correct? 

I have an existing sdb MBT Win7 drive.  Installed a new drive, sda which will be the target installation drive for arch.  I want to boot sda, pick my OS from a bootloader, choices being arch or win 7 (dual boot - two drives).  Beginner's guide is slightly confusing with the language around "dual boot" but I think it's suggesting a GPT partition in my case for sda, and since I have a newer asus mobo which is UEFI - that's probably the route I should go.

Stupid questions #2
1) Does what I just typed make sense?  UEFI boot, GPT on sda?
2) This also means gummiboot should be my loader on sda right?
3) EFISTUB is just for loading arch and arch only on a GPT UEFI drive (not for my situation)?
4) Grub and syslinux are for MBT drives (not for my situation)?

Stupid questions #3 - partitioning
1) Do I have this right?
a) I made an EFI partition for the bootloader (gummiboot).  512MB.  Formatted FAT 32.  Boot option enabled.  This is sda1 in my case, and it's mounted to /mnt/boot  (mounted 3rd after I mounted root and home)
b) I made a root partition 20GB, formatted ext4, sda2, mounted to /mnt
c) I made a home partition, remainder of the drive, formatted ext4, sda3, mounted to /mnt/home (mounted 2nd after root)
d) There's 1007KiB of free space left at the beginning of the disk.  WTF is that and is this where I screwed up?  Beginner's guide suggests this is needed for a GPT partition booting in legacy mode (say using GRUB).  But that's not what I'm doing.  I can't seem to eliminate this space.  Confused...

2) Originally, I couldn't figure out how to enable the boot option for sda1 (EFI) with cgdisk, so I started over and used gparted instead.  But after doing this, my sda2 and sda3 partitions didn't say "linux filesystem" but said "windows filesystem" or something like that.  I'm positive I used ext4, and set the drive to GPT under advanced.  There was also like 400MB left over of free space at the end of the disk (it didn't use everything left available when I created the home partition).  I thought I used gparted right - but some of these things were unexpected.  So using cgdisk, I deleted sda2 and sda3, and recreated the 20GB root (sda2) and home for the remainder (sda3).  I formatted both ext4, mounted and installed - seemingly without issue.  Did I screw up sda1 by doing this?  That partition should be intact if I didn't touch it =\  Again confused with the extra space - wondering if this is where I went off course.

It's worth noting that per the efibootmgr wiki page, I DO have files in /sys/firmware/efi/vars, but I do NOT have any files in /sys/firmware/efi/efivars.  Again, all evidence points to not booting in UEFI mode - but damn - I can't imagine this being the case.  I've booted both ways and there's a visible difference.

ANYWAY - thanks for reading that novel.  Any help is appreciated.  I'll continue RTFM, and trying to figure this out in the meantime smile

Great site BTW - so much information - almost an information overload wink

Kongar

Offline

#2 2013-06-24 22:53:07

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Problems with efibootmgr - noob question

Sweet jesus this is waayy too many questions for a single thread.  I'm not saying you need to start 500 threads, but I think you need to take a deep breath and relax and try to figure this out one things at a time.

So UEFI and GPT are a lot simpler than all the docs would have you think.  Bascially you don't use the traditional boot sector of the drive.  This is the first 512 bytes which traditionally hold the boot section in the first 440 bytes and the partition table in the rest.  The partition table is used for a protective MBR when you use GPT, which is basically there so other utilities that understand MBR partitioning only do not think they can overwrite the drive.

From the MBR area to sector 2047 is where the GPT lives.  It is a much larger space, and is why you can store 128 "primary" partitions in the default GPT.  There is also a GPT at the end of the disk as well so that if the primary GPT gets corrupted, it can restore itself from the backup.  I have even tested by overwriting part of the GPT with dd, and it was able to fix it.  It works, its awesome.

The info that you found that says that the space is used for legacy booting is true. But this is only in a very special case.  You have to be using MBR partitioning (where the GPT area will be empty) and the only bootloader that does this is grub2.  This is beacuse its bloated ass won't fit in those 440 bytes mentioned above.

With UEFI, the EFI System Partition is where the bootloader(s) live(s).  So in this case those first 440 bytes are not used at all.  Instead, you have bootloaders (or boot managers) living in the ESP as efi applications.  The advantage is that you can now use as much space as you want for the boot "sector" and you can have as many bootloaders as will fit in that space (amongst a few other things).

With UEFI, the Linux kernel has an option to be its own bootloader.  This is referred to as the efistub loader.  Typically, you would need something like grub or lilo or syslinux to actually load the kernel and initramfs for you.  But in this case, the kernel can do that stuff itself.  So for this, there exist a couple of boot managers as well.  These are gummiboot and rEFInd.  They are not bootloaders because they do not load the kernel.  Instead, they simply provide a nice interface with which to select the kernel to boot, and also pass arguments to that booting kenel.

Efibootmgr is just a tool that creates entries in your firmware's boot manager.  This is the list of options that come up when you hold the special key to select the booting device.  Under bios booting, you would select a particular device because with each device there was one boot sector that existed on each, so there was no question as to what was about to be booted.  But with UEFI, you can have multiple bootloaders on the same device, so it doesn't quite make (as much) sense to simply select a device.  So you create entries that tell the firmware on which ESP to find the bootloader and the path on that particular ESP to load it.  Again, this is what efibootmgr is meant for.

You can use an efibootmgr entry to boot directly to a linux kernel.  But this has several disadvantages and very few advantages.  The advantage is that (on my HW) a direct boot will be about 14ms faster.  But the disadvantages are that you have to create a new efibootmgr entry if you want to change anything on the kernel command line.  Also when you boot, you cannot change anything on the kernel command line before booting, so if something is fucking up your ability to boot on that command line... you're kind of shit out of luck unless you have a live cd or something else to boot.

There is one thing about UEFI that can get you around not having a firmware entry though.  Originally in the spec, it was stated that there was to be a "default" spot for removable devices.  That is, if you were booting from a USB for example, you obviously are not going to have a firmware entry.  So in this case, you would again select the device (like bios booting) and it would boot anything that was located at \EFI\boot\bootx64.efi.  After a while, the HW manufacturers began including this functionality for all disks, external and internal.  So now this has become part of the standard.  So you should put something at /boot/efi/EFI/boot/bootx64.efi that you wuold like as an "if all else fails" kind of a thing.

So you actually might need to install efibootmgr, as I don't think it is actually installed as part of the base group. 

Also your first question about a UEFI usb... yes you can create a UEFI bootable usb.  But it is not as simple as just dd'ing it to a USB stick. There are instructions on the UEFI wiki page toward the bottom.

I hope this helps you.  It sure does sound like you have been doing a lot of reading about the topic, and I respect that.  I know that when I started using UEFI, it was a bit confusing at first.  But from this point forward, I hope that you can try and figure out one question at a time to ask instaed of this massive barrage of questions.  In fact, I don't even know that I answered all your questions... and honeslty, I'm not going to go back to check.  I was about to just click away from this thread because it was so damn long, but felt like you were someone that could actually be helped.

Good luck.

Oh and BTW, UEFI and bios booting can happily live on the same disk.  GPT is not required for UEFI nor is MBR required for bios booting.  So on most HW you can use GPT/bios and GPT/UEFI without one messing with the other.

Offline

#3 2013-06-25 01:45:31

Kongar
Member
Registered: 2013-06-24
Posts: 5

Re: Problems with efibootmgr - noob question

Ok, that was an epic response to my mess of a first post - and it did help tremendously.  THANK YOU.  I think I understand this confusing UEFI / GPT stuff much better now, and I think I know where I went wrong.  I just couldn't put it all together like your post did...

My issue: I skipped over the efistub section not realizing the difference between a boot loader and a boot manager.  I thought it was efistub OR gummiboot (like grub OR syslinux).  I now realize I need them both.

But now that I understand that gummiboot is a UEFI boot manager and not a loader - it's not going to help me load windows 7 on my other drive is it? smile So my only real (newbie friendly) option here is Grub2 using BIOS boot?  And if so, that means I can essentially ignore all the stuff in the beginner's guide about being in UEFI mode...?

Kongar

Offline

#4 2013-06-25 02:49:45

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Problems with efibootmgr - noob question

Well, it depends on if you are using UEFI windows or not.  Typically, it is a PITA to try to use UEFI and bios booting on the same machine, but it might not be in this case. But if it is a UEFI windows 7 installation, then it is as simple as making a configuration file in /boot/efi/loaders/entires for gummiboot and pointing it to the windows efi application on the ESP. 

So if you have a bios based windows7 installation and your machine supports booting from both UEFI and legacy bios at the same time, then it is not too bad.  For example, on my machine, I can select booting from both, at which point it gives me the option of giving the bios based booting priority or UEFI.  So basically this just means that if there is both a boot sector with something to boot in it, and also on the same disk, an ESP with something as \EFI\boot\bootx64.efi it will choose one or the other depending on which you give priority to.  By using this functionality, you should be able to let gummiboot be the default boot option Then if you want to boot windows you can hold down whatever your firmware specifies to get the firmware boot manager, and choose the disk that windows is on.

Of course, there is nothing wrong with going the bios booting way.  But beware that grub2 can be way moe complicated and confusing than it really might be worth.  I know that most new users tend to go that route because it is what is the default on most distributions.  But I feel like there are much better options out there.  If Arch Linux is going to be your only Linux installation on the machine, then you could very easily use syslinux, as it will support chain loading to the windows system partition as well (I think all the Linux bootloaders do).  I also rather like lilo as well, since it is just super simple.  The grub2 grub-mkconfig generates a configuration for you through some kind of autdetction wizardry and a configuration file at /etc/default/grub.  It doesn't always do such a good job or detect all the right things.  But it can be really stabe and workable if you make your own config file using the example /boot/grub/grub.cfg.

So basically, you just need to determine if you have a UEFI windows insatllation or a bios one.  Then proceed from there.  Keep in mind that I believe that converting your windows instalaltion to UEFI is actually possible, but I have never actually tried to do it so I am unsure or what kind of a process that involves or what kinds of risks it might bring.

Oh and I think that rEFInd actually has quasi support for "chainloading" to bios stuff from its interface.  This is beacuse it is a fork of rEFIt which was intended for Macs and its bios compatibility mode.  The switching thingy is said to be most reliable on Macs of course, but I have heard that it has worked on other machines.

Offline

#5 2014-04-12 19:44:04

larinux
Member
Registered: 2013-12-22
Posts: 1

Re: Problems with efibootmgr - noob question

Hi, guys, what is it in the end? Do those 1007KiB need to always be there?

Offline

#6 2014-04-12 19:52:01

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: Problems with efibootmgr - noob question

Please don't necrobump: https://wiki.archlinux.org/index.php/Fo … Bumping.27


You need a ESP and it must be FAT. RTW for the INF.


Closing.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

Board footer

Powered by FluxBB