[Solved] UEFI + Partitioning + Bootloader = Hell

I've installed arch twice before this one, those were like a lovely stroll in the park compared to this Clockwork Orangesque torture i've been putting myself through. This time it's different because I have a system with UEFI firmware and I cannot for the life of me sort out this beginners guide to get this thing up and running.
As stated in the guide I verified through
efivar -l
that I am infact booted up through UEFI Mode.
It later goes on to recommend that I used GPT for my setup for UEFI booting.
It is recommended to always use GPT for UEFI boot, as some UEFI firmwares do not allow UEFI-MBR boot.
So I follow the instructions for creating GPT Partitions: https://wiki.archlinux.org/index.php/beginners'_guide#Using_cgdisk_to_create_GPT_partitions
Which tells me to create just two partitions: Root and Home
Later on in that same page however: https://wiki.archlinux.org/index.php/beginners'_guide#Create_filesystems
It tells me that I need to:
For UEFI, you should format the EFI System Partition (for example /dev/sdXY) with:
# mkfs.fat -F32 /dev/sdXY
With very little to elaborate on this earlier in the page. Although it does mention that:
If you have a UEFI motherboard, you will need to create an extra EFI System Partition.
But it gives no indication how large this partition needs to be.
I then find this:
https://wiki.archlinux.org/index.php/Un … _Partition
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as EF00 or ef00 type code in gdisk, or boot flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft).
(BTW, who uses mebibytes instead of megabytes?)
So... yeah... this was mostly a rant of sadness, after I get this thing up and running (After like 3 hours of beating my head against a wall and like 4 hours trying to get this to work) I really need to fix that friggan wiki... so that the next poor bastard that comes through, doesn't have to endure this PTSD enducing psychological torture...
My major issue was that I was not creating an EFI Partition for the GPT. Without which the bootloader (Gummiboot) is unable to communicate with the UEFI Firmware.
=============================================================================================
Solution - My two major mistakes were failing to create an EFI partition and using syslinux instead of gummiboot
=============================================================================================
1. Verify that your system is booting in UEFI Mode
https://wiki.archlinux.org/index.php/Be … _UEFI_mode
efivar -l
If you are in UEFI Mode, your system will output a list of UEFI Variables properly, if you are not, you will receive an error.
Continue on with the beginners guide as usual until you reach the "Using cgdisk to create GPT" portion
https://wiki.archlinux.org/index.php/Be … partitions
2. Create partions with cgboot (This was a crux for me, I didn't include the EFI Partition)
cgdisk /dev/sda
Choose New (or press N) – Enter for the first sector (2048) – type in 15G – Enter for the default hex code (8300) – Enter for a blank partition name.
Press the down arrow a couple of times to move to the larger free space area.
Choose New (or press N) – Enter for the first sector (2048) – type in 512M – Enter for the hex code for and EFI partition (ef00) – Enter for a blank partition name.
Choose New (or press N) – Enter for the first sector – Enter to use the rest of the drive (or you could type in the desired size; for example 30G) – Enter for the default hex code (8300) – Enter for a blank partition name.
here's how it will look
Part. # Size Partition Type Partition Name
1007.0 KiB free space
1 15.0 GiB Linux filesystem
2 512 MiB EFI Filesystem
3 123.45 GiB Linux filesystem
Now continue on with the Beginners guide until you reach the boot loader partition, I used Gummiboot successfully by following the simple instructions:
https://wiki.archlinux.org/index.php/Be … #Gummiboot
Last edited by cynicalpsycho (2014-11-02 04:55:35)

mrunion wrote:1) Since 1998
2) First install was in January 2007.
3) In total? 5-6 times. As a UEFI install? 2 times (including last Wednesday like I mentioned in my post).
1. Exactly, You're an arrogant, condescending snob that's been doing this for quite some time. Congrats, you can put together a linux box... well I would certainly hope so, you've been doing it for over 15 years now. But don't forget there was a point that even you had to overcome the learning curve and just because it's simple and clear to you, doesn't mean there aren't people out here that don't have 16 years of linux centric "common sense" behind them. Your current level of expertise is a cumulative evolution of 16 years of study and exposure and that is something you should take pride in, but being an arrogant twit about it just makes you look like a douche and it epitomizes exactly what gives the linux community a bad rap.
2. This Arch Wiki is (compared to most) massive, it's not streamlined, it has several passages that may or may not be used depending on the person, their equipment, preferences etc etc...  So forgive me if I didn't read the parts telling me to configure my keymap to a language I don't need to configure it too. It also links to other pages without giving full elaboration on why. It eventually leads you through several rabbit holes and isn't clear by any means to someone who doesn't do this on the regular.
3. I get that Arch isn't a COTS windows solution... it does have a level of difficulty that must be overcome, and it does require research, (which I am totally all about doing, and if you'd read my post, you would see that I never asked directly for an answer, instead I was trying to offer solutions to make the wiki itself better, because there was something omitted within an example) but there is also a great community behind it, that does (or so I thought) work hard to help its user base through forums and documentation. But your previous post, was completely nonconstructive, and served no purpose other than to stroke your own overblown ego.
Last edited by cynicalpsycho (2014-11-04 16:34:35)

Similar Messages

  • [SOLVED] UEFI doesn't "see" the 'EFI System' partition

    My BIOS/UEFI stop from "see" the 'EFI System' partition, there's shellx64.efi and a gummiboot installation and when I try to launch the shell only get "Not found" message.
    Here's the GPT:
    $ sudo gdisk -l /dev/sda
    GPT fdisk (gdisk) version 0.8.10
    Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/sda: 625142448 sectors, 298.1 GiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 8700C28A-71B0-416A-971A-DDAD1961D56E
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 625142414
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 2669 sectors (1.3 MiB)
    Number Start (sector) End (sector) Size Code Name
    1 2048 1640447 800.0 MiB EF00 EFI System
    2 1640448 78815231 36.8 GiB 0700 Basic data partition
    4 111316992 251867135 67.0 GiB 8300 Linux filesystem
    5 251867136 253968383 1.0 GiB 8200
    6 253968384 625141759 177.0 GiB 0700 Microsoft basic data
    7 78815232 111316991 15.5 GiB 8300
    File list:
    $ ls /mnt/boot/efi
    bootx64.efi EFI loader shellx64.efi
    This happened after a unsuccessfully fedora's bootloader installation.
    Last edited by hotvic (2015-02-23 00:34:34)

    I finally managed out what is the problem.
    The problem is that Fedora Installer (anaconda) wrote the MBR code to disk. so the UEFI partition isn't read by BIOS (I think, not sure).
    The solution for me was erase the protective-MBR:
    # dd if=/dev/zero of=/dev/sda bs=512 count=1
    and then fix the GPT:
    # gdisk /dev/sda
    ## just type 'w' and confirm
    after that reinstalled the gummiboot and voila
    Thanks to all and sorry my very bad english.

  • [SOLVED] UEFI: can't access EFI varialbes

    Hi,
    I have followed the instalation guide, and read all about UEFI, GRUB2 with UEFI. But when I try to run grub-install
    grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck --debug
    I get,
    Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
    I have seen this post too that mentions booting up in UEFI mode, but I can't find any such options in my UEFI manager
    http://superuser.com/questions/376470/h … -grub2-efi
    The system specs:
    motherboard: M5A99X
    cpu: FX-8120
    ram: 4 * 4GB
    I have read that I should add boot flag to the UEFI partition, but I don't know how to do that in gdisk, so this is what I have so far:
    /dev/sda #~3TB
    sda1 - 1GB EF00 EFI System fat32
    sda2 - 100MB 8300 ext2
    sda3 - 3GB 8200 swap
    sda4 - 50GB 8300 ext4 #root
    sda5 - 2.7TB 8300 ext4 #home
    I have tried everything I could find on the web, please help or help me find some new ideas. Thank you
    PS: I can normally install ubuntu that uses grub2 so I know it should be possible and it doesn't even have the extra efi partition which is weird.
    Last edited by zidarsk8 (2012-09-03 18:08:00)

    the.ridikulus.rat wrote:
    zidarsk8 wrote:
    Hi,
    I have followed the instalation guide, and read all about UEFI, GRUB2 with UEFI. But when I try to run grub-install
    grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck --debug
    I get,
    Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
    I have seen this post too that mentions booting up in UEFI mode, but I can't find any such options in my UEFI manager
    That error is shown by efibootmgr. That error will go only if you "modprobe efivars" after booting in UEFI mode. To check whether you have booted correctly, check whether "/sys/firmware/efi/vars/" directory is non-empty. If that directory is empty or non existing even after loading efivars module, then you have not booted in UEFI mode.
    Hi! We are discussing the same problem here https://bbs.archlinux.org/viewtopic.php?id=148120.
    That's seems to not be true for me, since i booted in UEFI mode for sure and "modprobe efivars" doesn't give errors. I'll check "/sys/firmware/efi/vars/" to be sure but there is too many people complaining this issue to be just human error IMHO.
    EDIT: directory not empty
    EDIT 2: I did "modprobe efivars" before chrooting and fallowed this https://wiki.archlinux.org/index.php/GR … _systems_2 instead of the beginners guide and something changed, but when i try to bless from osx to allow the disk to boot it says:
    sudo bless --folder=/Volumes/efi --file=/Volumes/efi/efi/arch_grub/grubx64.efi --setBoot
    Error while getting file ID of /Volumes/efi/efi/arch_grub/grubx64.efi. Ignoring...
    sudo bless --mount=/Volumes/efi --file=/Volumes/efi/EFI/arch_grub/grubx64.efi --setBoot
    Can't statfs /Volumes/efi/EFI/arch_grub/grubx64.efi
    So there still is something wrong in grub installation I think...
    EDIT 3: so sorry for all this edit. Just a stupid error, i didn't mount the efi partition before blessing. Now grub works (i can't believe it, it's been 4 days) but it cannot find my devices, it drops me to a recovery shell, where is the error?
    EDIT 4: nevermind, i was booting via usb, i inserted the hd and GRUB is working!
    Last edited by ewaves (2012-09-02 15:23:20)

  • Uefi Partitions capture and restore with ZCM 11.2.4

    Hello Everybody,
    I'm able to capture all my partitions from a Microsoft SurfacePro2 to my ZCM 11.2.4 appliance.
    The restore however is the problem. When I boot my restored machine Windows 8.1 goes into recovery modus.
    Anybody some suggestions on how to Image and Restore UEFI partitions in general or on SurfacePro2 in particular?
    Kind regards,
    Wilco

    I have heard of issues with Surface Pros before.
    There are two possible issues......
    #1 - 8.1 Is Currently Not Supported in ZCM.
    ZCM 11.3.0, which is expected to ship shortly, will not immediately add
    8.1 support but it is expected to be added via an Add-On patch to 11.3.0
    prior to 11.3.1
    #2 - The Surface Pro's BIOS may hide some partitions, which could cause
    the restore to not work quite correctly. When looking at the Disk
    Details inside of the Imaging Environment, does it show the proper disk
    geometry and full size. If parts of the disk are "missing", this can
    cause issues during restore.
    On 2/24/2014 7:36 AM, WWWilco wrote:
    >
    > Hello Everybody,
    >
    > I'm able to capture all my partitions from a Microsoft SurfacePro2 to my
    > ZCM 11.2.4 appliance.
    >
    > The restore however is the problem. When I boot my restored machine
    > Windows 8.1 goes into recovery modus.
    >
    > Anybody some suggestions on how to Image and Restore UEFI partitions in
    > general or on SurfacePro2 in particular?
    >
    > Kind regards,
    >
    > Wilco
    >
    >
    Craig Wilson - MCNE, MCSE, CCNA
    Novell Technical Support Engineer
    Novell does not officially monitor these forums.
    Suggestions/Opinions/Statements made by me are solely my own.
    These thoughts may not be shared by either Novell or any rational human.

  • [SOLVED] - UEFI - archLinux after install not boot

    Hi! I'm new user on archLinux but not in Linux. I have a Dell XPS L421X: i5, 8GB RAM, 32 GB SSD (In Windows is used as cache), 500GB, Intel 4000. UEFI Bios.
    Before do the Install I read the Beginners' guide from Wiki and I follow step by step this guide.
    I have Installed arch on the laptop, but the laptop does not boot :S
    500GB --> sda 32GB SSD --> sdb
    /dev/sdb1 --> 500Mb FAT --> UEFI File System (ef00) -->mounted in /boot
    /dev/sdb2 --> 300Mb Ext4 --> /boot
    /dev/sdb3 -->29 GB Ext4 --> /
    /dev/sda1 --> 25GB Ext4 --> /var
    /dev/sda2 --> 400GB Ext4 --> /home
    /dev/sda3 --> 16 GB Ext4 --> Swap (I use it for hinbernate)
    Now I remeber to I need to create another partition for the /tmp...jajaja
    The bootmgr installed is grub.
    I do not know what I need to do for the Linux boot :S
    Thanks in advance!
    regards
    elrengo
    Last edited by elrengo (2014-12-03 15:13:25)

    Thanks for you replay. At first time I think like you but the beginners`guide:
    begginneers`guide wrote:In case you have a UEFI motherboard, mount the EFI System Partition to /boot. Whilst other mountpoints are viable, using /boot is recommended as explained in the EFISTUB article.
    The /boot partition is reemplace by UEFI partition?
    Thanks again

  • MacBook Pro Installation Mount UEFI Partition?

    I am following both the MacBook Guide, and the Beginners' Guide. I am at the point where the Beginners' Guide is asking me to mount my UEFI partition. Do I want to mount my Mac's EFI partition?

    mathmare wrote:I am following both the MacBook Guide, and the Beginners' Guide. I am at the point where the Beginners' Guide is asking me to mount my UEFI partition. Do I want to mount my Mac's EFI partition?
    The term "UEFI partition" is a bit imprecise. The EFI specification (version 2.3.1) uses the terms UEFI system partition and EFI system partition interchangeably. Most other authoritative sources refer to the EFI system partition (sometimes i-capped, as in EFI System Partition), and often abbreviate it as ESP. To the best of my knowledge, there's no difference between the ESP of an EFI-based computer and a UEFI-based computer. UEFI is just EFI 2.x.
    WonderWoofy wrote:It should be noted that Macs use a HFS+ Journaled EFI partition, whereas the UEFI specifications indicate that a FAT partition should be used.
    A Mac can use an HFS+ ESP, in the sense that it will work; but to the best of my knowledge, Apple ships all its Macs with FAT32 ESPs. At the very least, my own ancient 32-bit Mac Mini came with a FAT32 ESP.

  • Deleted UEFI Partitions

    product = laptop
    model = Satellite C55D-A5170
    Problem = I have found Windows 8.1 utterly useless and have been continually creating work-arounds so that  I can get work done with the laptop. This week I decided to get rid of the bundled Windows 8.1 operating system Toshiba put on the laptop.  I could find no way to do this while using the 8.1 OS so I installed the Satellite HDD into my desktop and deleted all the partitions on the Satellite HDD.
    Note: I was not aware of the UEFI and Secure Boot mechanisms prior to deleting the HDD partitions and thus did not turn off Secure Boot in the UEFI settings on the Satellite thus the Secure Boot mechanism remained in effect on the Satellite motherboard.
    I installed Windows 7 Pro on the HDD using my desktop computer then reinstalled the HDD into the Satellite which would not boot and gave me a Secure Boot message which declared a condition which prevented boot to HDD. Boot to the Windows 7 Pro installation DVD was denied also.
    How to I regain control of the computer which I purchased? I absolutely will not consider continuing use of Windows 8.1 on a of my machines and desire to install Windows 7 Pro on the Satellite but the Secure Boot mechanism is preventing that.
    In effect I am inquiring how I can turn off the Secure Boot mechanism after the HDD UEFI partitions have been deleted and the HDD has been repartitioned and formatted to Windows 7 Pro.

    Satellite C55D-A5170 (PSCFWU-029005)
    Downloads here.
    I installed Windows 7 Pro on the HDD using my desktop computer then reinstalled the HDD into the Satellite...
    That rarely works. Each installation of Windows has a HAL which is tailored to the hardware. So Windows must be installed on the hardware it will use.
    In order to boot using UEFI from the Windows 7 installation media, follow this procedure. It may be necessary to upgrade the UEFI (aka BIOS) in order to access CSM Boot.
    -Power on and press F2 while the Toshiba logo is displayed to enter the UEFI Setup Menu.
    -Go to the Security tab and set the "Secure Boot" setting to "Disabled".
    -Go to the Advanced tab, enter "System Configuration" and set the Boot Mode to "CSM Boot."
    -Press F10 to save and exit.
    Drivers and utilities to make the laptop function as designed will be your major problem. Toshiba does not supply them at the link above. Don't expect to get everything working. See this message for major drivers for computers in part-number family PSCFWU.
    -Jerry

  • [SOLVED] UEFI / Grub Partitioning

    Hi,
    first of all, I'm very sorry, that I'm asking a question of that level. Though, I've gone over the Wiki, an several attempts to google an answer... The topic seems to be very vague, and more or less I just want to have a confirmation of what I'm planning to do.
    I want to install Arch on my uefi enabled notebook; no secure boot; Grub as bootloader.
    What I already understood, is:
    - GPT Table isntead of MBR
    - Create an EFI system partition (like this: https://wiki.archlinux.org/index.php/Un … Partition)
    - Proceed as usual
    So what I'm planning these partitions:
    gdisk:
    - 1: 1024 MB EFI Partition (bigger then recommended, to be save)
    - 2: / (of any size)
    - 3 /home (of any size)
    Is that sufficient?
    Do I need that 1 megabyte EF02 disk for Grub like on MBR?
    Do I need /boot partition?
    I'm confused (Probably obious) and a bit desperate, as it seems that I'm not able to find a proper guide on that. Please help.
    Best regards
    Simon
    Last edited by smnpl (2015-05-25 12:01:19)

    smnpl wrote:1024 MB EFI Partition (bigger then recommended, to be save)
    While this is unlikely to cause any problems, I do have one laptop that will only accept an EFI system partition if it is 512MiB -- if you want to be "save" [sic], you should probably make it that size.
    smnpl wrote:Do I need that 1 megabyte EF02 disk for Grub like on MBR?
    You only need an EF02 partition if you intend to boot in non-EFI mode as well (using GRUB). Also, that partition type is not needed on MBR disks (it is only used on disks with a GUID partition table).
    smnpl wrote:Do I need /boot partition?
    Yes, you need a separate /boot partition mounted to the EFI system partition -- make sure it is FAT(32) formatted.

  • [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

    I'm trying to understand once and for all the process by which Arch can be booted from a system with UEFI firmware and an MBR partition table. Some of the information on the wiki seems conflictual / non-nonsensical at times. Apologies in advance if this has been answered time and time again, but I did search around and all I found was fixes to get Arch to boot rather than comprehensive explanations of the boot process.
    Now, the way I would imagine it works is that it's just completely identical to the way it would work with a BIOS firmware. The UEFI firmware detects an MBR partitioning scheme (or is configured to know it's an MBR partitioning scheme), activates some "legacy" mode and executes the MBR boot code, just like a BIOS firmware would.
    The wiki however, says different. From the Macbook article: "Do not install GRUB onto /dev/sda !!! Doing so is likely to lead to an unstable post-environment."?
    So what is there in the MBR boot sector? Nothing?
    How does the firmware know what to boot if there's no 0xEF BIOS boot partition and no Grub stage 1 in the MBR boot sector?
    Also, how does installing Grub stage 1 to a partition work? Does it have to be at the beginning of the partition? Wouldn't that overwrite some existing data?
    I'm especially puzzled since many guides to installing Vista on a macbook recommend simply formatting as MBR, and installing as normal, which I suppose entails having the Windows installation process write its boot code to the MBR, ie the equivalent of installing grub stage 1 to /dev/sda rather than to the /boot partition, as the Macbook article suggests.
    Any input is appreciated.
    P.S. I realize it's probably simpler, if I just want to dual boot Windows and Arch, to install Windows 7 in UEFI-GPT mode, let it create the EFI System Partition, and then install GRUB 2 to that partition, but I'm still curious about the UEFI-MBR boot process.
    Last edited by padavoine (2012-06-06 09:35:10)

    padavoine wrote:
    CSM in UEFI firmwares do the exact same job as normal BIOS firmware.
    So it's something specific to the Mac that it's able to boot from a partition's VBR while ignoring the MBR?
    The reason that warning is given is because grub-legacy modifies more than just the MBR boot code region.  It can overwrite some parts of GPT header.
    Not true, the instruction is given in the context of an MBR format, not in the context of a GPT format, so there's nothing to overwrite and Stage 1.5 should be safely embeddable in the post-MBR gap.
    In BIOS boot (normal case in non-UEFI firmwares or CSM in UEFI firmwares) does not read the partitition table (atleast it is supposed to be dumb in this regard), it simply launches whatever boot code exists in the 1st 440-byte of the MBR region.
    So again, you're saying it's specific to the Mac UEFI that it lets you choose a partition whose VBR to load, regardless of what's in the MBR?
    I haven't used Macs so I can't comment on Mac firmware behaviour. But normal BIOS firmwares (legacy and CSM) launch only the MBR boot code and not the partition boot code. We need some chainload capable boot manager in the MBR to launch the partition VBR.
    grub-legacy does not know anything about GPT. So when you install grub-legacy to /dev/sda, it install the MBR boot code (stage1) and stage 1.5 code to the (supposed) post MBR gap. Since there is no actual post MBR gap in GPT (which has been taken over by the header and partition table), grub-legacy does not check for GPT and it assumes the post MBR gap actually exists which is invalid in case of GPT. grub-legacy embeds the stage 1.5 code in GPT header and table region (which grub assumes to be unused post MBR gap) and thus corrupts it.
    0xEF is the MBR type code for UEFISYS partition. grub stage 1 (used in grub-legacy, not in grub2) is the 440-byte boot code stored in MBR for use in BIOS boot.
    That's precisely my point: with neither proper executable code in the MBR (since grub was installed to a partition, not to the MBR) nor a UEFI system partition, what does the firmware default to, and how does it know what partition to boot from?
    In that case it might fallback to UEFI Shell (if it exists)  or give an error similar to the case where BIOS does not find any bootable code in 440-byte MBR region.
    So even with bootcamp/CSM, the disk also needs to be MBR partitioned. So Macs use something called "Hybrid GPT/MBR" ( http://rodsbooks.com/gdisk/hybrid.html ) where the MBR table is synced to match the first 3 partitions in the GPT table.
    I know what Bootcamp does, and that's not what I was referring to. I was referring to standalone Vista installs. I wasn't puzzled at the fact that they were using MBR, I was puzzled at the fact that contrary to the recommendations for the standalone Arch install on the wiki (with MBR partitioning, not GPT), they didn't do anything to try and prevent Windows from writing to the MBR.
    You can't prevent Windows from overwriting the MBR region. You have to re-install the bootloader (grub2/syslinux etc.) after installing Windows. That is the reason why it is recommended to install Windows first and linux later.
    Thats not true. I actually find it is much easier to install Windows UEFI-GPT using USB rather than a DVD.
    I haven't done it since the only UEFI system I own has no DVD drive, but I was under the impression that it was simply a matter of choosing DVD UEFI boot in the firmware's boot menu.
    format the USB as FAT32 and extract the iso to it. That it.
    No, thats not it, precisely, it doesn't work out of the box with a standard Windows install USB, you need to fiddle around:
    2.3 Extract bootmgfw.efi from [WINDOWS_x86_64_ISO]/sources/install.wim => [INSTALL.WIM]/1/Windows/Boot/EFI/bootmgfw.efi (using 7-zip aka p7zip for both the files), or copy it from C:\Windows\Boot\EFI\bootmgfw.efi from a working Windows x86_64 installation.
    2.4 Copy the extracted bootmgfw.efi file to [MOUNTPOINT]/efi/microsoft/boot/bootmgfw.efi .
    Most of the Windows isos already have /EFI/BOOT/BOOTX64.EFI file, so no need to extract the bootmgfw.efi file.
    There is no difference between in BIOS booting in UEFI firmwares and BIOS booting with legacy firmware.
    There has to be a difference, at least in the Mac firmware (sorry, I keep switching), since legacy firmware, AFAIK, cannot chainload a bootloader in a partition's VBR without there being some sort of "stage1" code in the MBR.
    No idea about Mac EFI. Apple made a spagetti out of UEFI Spec. To actually understand how Mac firmwares work, read the blog posts by Matthew Garrett of Redhat, about his efforts in getting Fedora to boot in Macs.

  • [Solved] Arch + W8 dual boot, UEFI, partitioning question

    Hello,
    I'm buying new laptop with preinstalled W8 (Lenovo E430) and I'm planning to dual boot. I've read Beginner's guide, Installation guide, searched forum, etc., but I'm still unsure how to deal with creating partitions for Arch while keeping Windows.
    From the Beginners' Guide:
    If you are intending to follow the advice to create a GPT partition table then you need to choose "Advanced" and then select "gpt" from the drop-down menu. This cannot be done if you have a pre-existing Windows installation on the drive which you wish not to destroy.
    and from the Partitioning:
    To dual-boot with Windows, one must use MBR.
    A special exception to this rule: dual-booting Windows 64-bit using UEFI instead of BIOS, one must use GPT.
    My W8 will be 64bit and also is Arch.
    So, my question is. When I shrink W8 partition and create free space for Arch, do I have to choose 'gpt' option (2nd quote) or not (1st quote) for formatting? Or am I reading it totally wrong?
    I would give it a try, but that destroying thing kind of scares me.
    Last edited by centos (2013-06-18 19:24:58)

    The wiki quotes you've presented make it look like the wiki was created with an MBR/BIOS assumption and then poorly edited to incorporate GPT/EFI information. The rules, presented in a more cohesive way, are these:
    Windows ties its partition table type to the computer's firmware: under BIOS, Windows requires MBR; and under EFI, Windows requires GPT.
    Linux is more flexible: It can use either MBR or GPT under BIOS. In theory, Linux can use either MBR or GPT under EFI, although many EFIs seem to require GPT, so it's best to stick with GPT on EFI-based computers.
    When dual-booting, Windows is the limiting factor when it comes to partition table type.
    Most EFIs include a Compatibility Support Module (CSM), which enables them to boot BIOS-based OSes. The CSM can usually be enabled or disabled in the firmware setup utility, although the details of how to do this vary from one implementation to another.
    Computers that ship with Windows 8 pre-installed almost always use EFI, and therefore GPT.
    Converting from MBR to GPT or vice-versa is possible with GPT fdisk (gdisk, cgdisk, or sgdisk), but this requires re-installing the boot loader for any already-installed OS(es). If Windows is one of those OS(es), it's probably not worth the effort.
    GParted and parted can convert from MBR to GPT or vice-versa only by destroying existing partition entries, so you should use these tools to make such a change only on a blank disk or if you intend to lose all the existing partitions.
    Since you (centos) say you're installing to a computer with a pre-installed Windows 8, you've almost certainly already got an EFI/GPT setup. Under these circumstances, you won't be choosing a partition table type unless you want to completely wipe that installation and install both OSes fresh. GParted will detect the partition table type and work with it automatically; you should not select the option to create a new partition table, which your first quote (partially) describes. You should, however, be sure that you install Arch in EFI mode and that you install an EFI-mode boot manager and/or boot loader, rather than a BIOS-mode version of GRUB. Getting an EFI-mode Windows and a BIOS-mode Linux to coexist is possible, but awkward. Converting a BIOS-mode Linux installation to boot in EFI mode is also possible, if you mistakenly install in BIOS mode; but it's usually easier to install in EFI mode to begin with. There are lots of threads here on EFI-mode Arch installations, as well as information in the Arch wiki on this topic. Unfortunately, EFI is still new enough that there are still a lot of kinks to be worked out, both in specific firmware implementations (many of them are buggy) and in OS support (which is still not as mature as is BIOS support).

  • [Solved] UEFI - Do I have to remake the arch .iso?

    Hi
    I am really struggling getting Arch to install in UEFI mode.
    I have read https://wiki.archlinux.org/index.php/Un … _Interface - however I still don;t know what i'm doing....
    I have Fedora17 installed in UEFI mode already, my partition layout is
    /dev/sda1 /boot/EFI
    /dev/sda2 /boot
    /dev/sda3 Swap
    /dev/sda4  /
    What steps do I have top do to get UEFI to work for Arch?
    - Do I have to extract and re-master the arch iso to include EFI/UEFI?
    - Do I have to create another EFI partition (as I already have one for Fedora17?
    - I tried to install the install disk and it could see 2 of every partition (which suggests it wasn't working..)
    Any help will be welcomed
    Cheers
    Last edited by yossarianuk (2012-06-25 13:19:54)

    First time you broke fedora because you was using standard iso without uefi support.
    Second time with arch you installed bootloader to mbr - most certainly this wasn't uefi install.
    After this I have no idea what you have done
    Now let's start fresh - how to install arch in uefi mode:
    Make sure your disk has gpt partition table - if you went back to mbr, it very easy to format to gpt and create partitions with gparted
    live cd. Efi partition should have boot flag active.
    Download tpowas's archboot iso and just extract it to usb - using dd won't work for uefi.
    When you boot, run "ls -1 /sys/firmware/efi/vars/ls -1". If there is output, uefi boot was successful.
    At mountpoints setup step, mount efi partition at /boot/EFI.
    Everything is same as in bios mode until the install bootloader step. Make sure you choose uefi bootloader
    and x64 grub2 if you want to go with grub (for other options read wiki). Installing bootloader might fail - if it does
    exit setup and chroot (don't forget mounting efi part). Install grub2 following these instructions.
    And this shuld do it!

  • [SOLVED] UEFI installation - booting failure

    Hi All,
    Setting in BIOS: UEFI boot mode, Secure Boot Off
    Booting from USB in UEFI mode, everything is OK. Then I did this:
    gdisk /dev/sda
    create new GPT partition
    cgdisk /dev/sda
    Part. # Size Partition Type Partition Name
    1007.0 KiB free space
    1 512 Mb EFI system efi
    2 6 GiB Linux filesystem root
    3 122 GiB Linux filesystem home
    mkfs.vfat -F32 -n efi /dev/sda1
    mkfs.ext4 /dev/sda2
    mkfs.ext4 /dev/sda3
    mkdir -p /mnt/boot/efi
    mount /dev/sda1 /mnt/boot/efi
    mount /dev/sda2 /mnt
    mkdir -p /mnt/home
    mount /dev/sda3 /mnt/home
    Then I followed the installation guide. At the "Install a bootloader" section I tried both EFISTUB and GRUB:.
    At Point 5 here https://wiki.archlinux.org/index.php/Beginners'_Guide#EFISTUB I created refind_linux.conf with sdax = sda2
    # nano /boot/efi/EFI/arch/refind_linux.conf
    "Boot to X" "root=/dev/sda2 ro rootfstype=ext4 systemd.unit=graphical.target"
    "Boot to console" "root=/dev/sda2 ro rootfstype=ext4 systemd.unit=multi-user.target"
    and at Point 6 X=a, Y=1:
    # efibootmgr -c -d /dev/sda -p 1 -w -L "rEFInd" -l '\EFI\refind\refind_x64.efi'
    GRUB is quite straightforward.
    After restart I got "no bootable device" error. The strange thing is that in BIOS I can see and select "rEFInd" or "arch_grub" in booting options, but anyhow it just won't boot.
    Thank you for your help.
    Last edited by totolotto (2013-06-22 17:33:39)

    totolotto wrote:rEFInd boot manager shows 2 Arch logos:
    1) Boot EFI\arch\vmlinuz.efi from 512 MiB FAT volume
    2) Boot boot\vmlinuz-linux from 6 GiB ext4 volume
    This means that you've got your kernel (or possibly different kernels) stored on two partitions. The first looks like it's a kernel on your ESP, and the second looks like it's your root (/) Linux filesystem, accessed via the rEFInd ext4fs driver. To simplify your life, I recommend deleting the kernel from the ESP and using the kernel in your Linux /boot directory (that is, kernel #2). If you try to keep both of them, you'll have to copy new kernels from /boot to the ESP whenever you upgrade your kernel, and you'll end up with two entries in rEFInd that boot the same kernel, which is sort of pointless.
    That said, if you don't want to use rEFInd in the long term, copying your kernels to the ESP, or reconfiguring your mount point so that the ESP is mounted at /boot and therefore your kernels get stored there automatically, can make sense. Given where you are, though, the quickest path to an efficient setup is to just ditch the kernels on the ESP and boot your kernels off of your root (/) partition's /boot directory.
    totolotto wrote:With regard to "boot into Arch directly" I understand that it is possilbe with efibootmgr described here, however efrbootmgr does not work for me
    Some people do like to boot their kernels directly, without using rEFInd, gummiboot, GRUB, or anything else. Note that efibootmgr isn't involved in the boot process per se; it's just used to set up the firmware's boot manager. Thus, saying you want to "boot with efibootmgr" (or words to that effect) is confusing, even to experts -- because this makes no sense, it's not clear what you really want. This uncertainty has been cleared up in subsequent posts, but I want to point it out to help you (and perhaps others who read this) communicate more clearly in the future.
    FWIW, I tend to agree with WonderWoofy on this score -- although it's possible to configure the firmware to boot the kernel directly, the down sides to this approach more than outweigh whatever small speed benefits you get from it. In your case, totolotto, given the problems you're having with efibootmgr, it may not be a practical alternative -- at least, not unless and until you can overcome those problems.
    WonderWoofy wrote: I think a better option would be to give rEFInd a timeout of zero.  I believe there is a key (or keys?) that you can hold down to have the menu show up when the timeout is set to zero.  This is how gummiboot works anyway,
    rEFInd doesn't have a 0-timeout option. In rEFInd, setting the timeout to 0 disables the countdown timer, so it never times out. The closest you can get to a 0-timeout in rEFInd is setting it to 1 second. If you must have a true 0 timeout, use gummiboot. Unfortunately, that means you won't be able to read the kernel files from a Linux filesystem, but mounting the ESP at /boot can create something that works about as well. Doing this will require some significant reconfiguration from where totolotto is now, but it can be done if getting a 0-timeout configuration is important.

  • [Solved] UEFI Boot Failure

    So I just got a now mobo that is UEFI and I tried loading Arch using the normal method.
    i.e.( Partition, mkfs, mount, modprobe, chroot, install, reboot)
    However when I arrive to what should be the boot I get a Black Screen with cursor.
    I have read plenty of posts of the same issue, but to no avail.
    This was using the EFIstub only, when I tried gummiboot I was unable to create EFI Boot variables. (I did check if in UEFI)
    So now I am scratching my head as to what is going on.
    Partitions are standard (gpt)
    sda1 512M Fat32 ESP
    sda2 10G Swap
    sda3 100G Root
    sda4 1.7T Home
    Mobo is
    M5A99FX ASUS
    Any help is greatly appreciated.
    Last edited by Teito (2013-08-30 19:43:20)

    I think yuo might have forgotten to actually install and configure gummiboot.
    Gummiboot is really just a boot manager.  That means it does not load the kernel and initramfs as a typical bootloader would do.  Instead, it simply allows the selection of an efi application and the option to pass arguments if desired/needed.  The Linux kernel these days has CONFIG_EFISTUB, which allows the kernel to act as its own UEFI bootloader.  So in reality gummiboot is just a menu to select that real bootloader.
    So what you actually tried to do there is create a direct firmware entry.  This is also using Linux as its own bootloader (via efistub).  But instead, you simply append the kernel command line arguments to the bootloader (the kernel) directly in that firmware entry.  So I am not sure if this was actually your intended goal or not.
    I would recommend using the boot manager, and personally I like gummiboot because it is super straight forward to configure.  But you are welcome to try using the direct firmware entry as well.  Some would argue that the direct entry is faster, but the time it takes for my machine to load gummiboot is typically 14ms, so I consider that argument a bit silly.  The advantages of being able to edit the kernel command line before booting are worth far more than 14ms, which is far less than what we used to wait for grub to load from the disk's boot sector.
    In order to be absolutely sure you are getting gummiboot, you should install gummiboot (which should actually automatically install itself as /boot/EFI/gummiboot/gummiboot.efi as well as /boot/EFI/boot/bootx64.efi and attempt to make a firmware entry as "Linux Boot Manager").  But instead of trying to use the firmware entry, boot from the disk that the ESP resides on.  \EFI\boot\bootx64.efi is the "default" position, so it is what the firmware is designed to search for in the event that it is booting with UEFI and a disk has been selected (instead of an efibootmgr firmware entry).  If you have configured gummiboot properly, you will at least make it to the gummiboot menu and know that your UEFI is at least working… as long as you set a timeout >0.
    I guess you should clarify what your actualy goal/preference is here, and then we can go from there.

  • [solved]confused about bootloader to use

    I have a uuefi motherboard but in my BIOS drives some say ahci, not sure which bootloader I should use.
    Last edited by tmccaffery (2013-04-04 20:21:29)

    If you are comfortable with the old bios way of doing things, then I see no reason why you should force yourself into learning about UEFI if you don't have the desire to do so.  Most UEFI boards have a legacy bios mode, so you can continue to use that if you please.
    BTW, I use gummiboot, with rEFInd as a backup, and elilo as a backup to the backups (and just in case I have an old kernel w/o efistub).  I also have direct firmware boot manager entries for each of my kernels, as well as both version of the UEFI shell as a super duper extra backup.  That is one of the advantages of UEFI, you are not forced to use just a single bootloader, as they are stored in the EFI System Partition, which can be as big as you want it, instead of just the first 446 bytes of the disk like bios.  This makes the necessity of crazy chainloading unnecessary, which is a real treat.

  • [SOLVED] UEFI woes

    Hi everyone, this is my first post on this account on the forums - however it is not my first time installing arch.
    Having installed arch previously a few years ago successfully, a lot seems to have changed and it seems 100x more complicated than before.
    Anyway, I am having serious issues trying to install Arch on my ASUS 1215b.
    First of all I managed to boot my memory stick in uefi mode once, when I tried my first install. However there were certain things that were not done correctly, and hence I had to start over.
    I now am unable to boot Arch Linux in uefi mode from my USB stick, I have tried things all over the internet, and everything in the beginners guide. I have no clue where to go from here - hence why i'm posting.
    I think the best approach would be to start over completely with a blank drive again, which I don't mind doing. But not being able to boot in UEFI mode is an issue, because I managed to get to the step in the beginners guide involving bootloaders, but when I tried running the command:
    # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
    it couldn't find the mountpoint or something along those lines.
    Help me arch community please
    (I have been at this for 2 days now)
    TLDR; How do I reformat my memory stick to enable UEFI booting of the Arch Live CD (Note that I am running windows, and hence must format the memory stick under windows)
    Last edited by FerretBuster (2013-11-01 02:07:32)

    cfr wrote:
    FerretBuster wrote:
    Well if it's any help I actually got to the bootloader installation part of the install before, but as I said when I ran the command
    # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
    I was unable to mount efivarfs as efivars didn't exist
    The only bit you need this for is creating the menu entry. Do everything else, copy the .efi application to the default location and your computer will very likely reboot using that fallback. When you reboot, that command will work and you can create the menu entry.
    If you use e.g. gummiboot's automated install or grub-install, you'll get an error when it can't create the menu entry. That's OK. It will do everything else. In particular, the .efi application will get created and installed on the EFI partition. Just copy it to the fallback position, reboot and then deal with efivars and create the menu entry.
    Ok great I will try that now, however I don't understand what you mean by copying the .efi application to the default location. Do you mean copy a .efi file from my memory stick, to the efi partition I am meant to make?
    If so where do I find the .efi application and where is this default location?

Maybe you are looking for