[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.

Similar Messages

[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.

Boot Windows 8.1 in MBR mode from UEFI GRUB

Hi,
i installed Windows 8.1 in BIOS/MBR mode to my second hardisk /dev/sdb.
On my first disk /dev/sda is Archlinux with GRUB 2.0 in UEFI mode.
Is it possible to boot Windows 8.1 from the UEFI GRUB?
The description in the wiki is only for MBR systems...
https://wiki.archlinux.org/index.php/Gr … S-MBR_mode
Thank you

Actually, rEFInd can switch from EFI-mode to BIOS-mode booting; however, on PCs it's usually restricted to booting the BIOS-mode boot loader in the MBR of the first disk. Thus, you might need to physically swap your disk cables to get it to work. You'll also need to uncomment the "scanfor" line in refind.conf and add "hdbios" to its boot options list.
Oh, you also need a version of rEFInd compiled with Tianocore, not GNU-EFI. My own main binaries are so compiled (I'm rEFInd's author), and I believe that Arch's are, too, but some others are built with GNU-EFI.
Last edited by srs5694 (2014-03-15 20:10:29)

[SOLVED] Chromebook: help partitioning /dev/sda7 to install GRUB

My goal is to dual boot Arch and Chrome OS on an Acer C720. I repartitioned the drive using the Chrubuntu script. Following the Wiki, I created the file system for Arch on /dev/sda7.
The next step in the Wiki reads
Following the instructions for installing GRUB on GPT, use gdisk to create a 1007kb partition and set the type to EF02.
I don't understand what to do. Do I really make another partition on sda? I've read that if you change the partitioning, it will not boot into Chrome OS.
Can someone please help me understand how to create the 1007kb partition for GRUB? Thanks!!
Last edited by Watney (2015-05-10 00:32:05)

There aren't details of what you've done, think of what we can comment here.
What says
# parted -l /dev/sdX ### could be /dev/sda
Or even better what's your actual partitioning scheme and how the partitions are laid out.
The note is clear (for me) and the link in it will show more details. The real point is to have the Post-MBR gap where GRUB will use to write its files.
If you don't have that Post-MBR gap then you need to shrink the first partition from the beginning to leave that Mb gap.

[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 + 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)

[ Solved ] Issue with Partitioning (setting the boot flag)

I've tried to install Arch a few times. I always seem to run into this issue which affects me later on.
fdisk (fdisk /dev/sda) doesn't provide me with the ability to set the boot flag on any of the partitions. Therefore I have issues when I get to the bootloader bit. (intend to use grub)
When I use cfdisk (cfdisk /dev/sda), while its help does say pressing 'b' will toggle the flag, in all images I've seen of what cfdisk should look like there has been a column marked 'Flags' - that isn't present for me. So, I have no way of knowing if it actually gets set, though I doubt it does.
Partition Table is GPT.
Though,
fdisk -l gives
Disk /dev/sda ~465.8 GiB
Disk /dev/loop0 ~278.2 MiB //Not entirely sure what loop0 and loop1 are...
Disk /dev/loop1 ~32 GiB
Disk /dev/mapper... //the live image.
I'm probably just making a simple mistake - though I have no idea what. Help?
(Ruling out other errors, using latest dual architecture image, (using 86_64 UEFI) on this system; Asus X99 Pro, Core i7 5820k, 16GB RAM, ~500GB SSD, generic video card).
Last edited by AndyWM (2015-06-10 17:21:20)

It's okay - I just decided to follow the beginner's guide again. It recommend the use of parted for GPT when using UEFI. So I just did that, I also went for gummiboot as the bootloader. Never used it before, but it seems to do the job...
Did forget to create a user though, so I'll have to log in as root and do that.
Anyway, I'll mark this as solved.

Dual boot, UEFI and partitioning

Got a new computer which I put my old disks in. After a while I got them to
boot properly but I'm going to take the time to go from my current MBR setup to
GPT.
The idea
I have three disks, 480GB SSD, 640GB HDD and 2TB HDD. The idea is to use the
SSD for root and /home and then let the data on the 2TB be as it is (for now).
I will go all LVM on the SSD and 640 HDD (except for a part which will be for
windows 8). When I invest in a new disk (2TB) I will make the current 2TB LVM
as well as that new one so that moving "partitions" (LVM volumes) easier
if/when needed.
Questions
Will I still be needing something like syslinux/grub with UEFI? For the windows
part, will that require some sort of EFI partition and should I create that or
just leave 200GB + 500MB space at the beginning of the 640GB disk (and LVM on
200.5GB-END)?
If a bootloader is needed, can I put that on my SSD and still boot windows from
the HDD in an easy fashion?
Will there be any problems with having one disk still as MBR (I don't have the
space needed for backing up those 2TB currently)?

xintron wrote:Will I still be needing something like syslinux/grub with UEFI?
Booting an OS always requires a boot loader. The details of what boot loaders are available varies from one platform and OS to another, but a boot loader is a necessity. My Web page, Managing EFI Boot Loaders for Linux, describes the options for booting Linux on an EFI-based computer. SYSLINUX and GRUB are both options, but there are others, too. My personal preference is to use the EFI stub loader with rEFInd, but as I'm rEFInd's maintainer, I'm not exactly unbiased.
For the windows part, will that require some sort of EFI partition and should I create that or just leave 200GB + 500MB space at the beginning of the 640GB disk (and LVM on 200.5GB-END)?
EFI systems require an EFI System Partition (ESP) to boot any OS. (An exception is EFI-based Macs, but they're just weird all around.) I recommend a size of 550MiB for the ESP. Many Arch Linux users like to mount the ESP at /boot, since that simplifies kernel management with certain boot configurations.
If a bootloader is needed, can I put that on my SSD and still boot windows from the HDD in an easy fashion?
Yes, at least in some sense. Boot loaders normally reside on the ESP, which is normally shared between OSes, although there are exceptions to both of these rules. The Windows C: partition is separate from the ESP. In theory, the two can reside on different disks, although in practice I'm not sure how the Windows installers and other tools would cope with that type of configuration. In theory, you can also have multiple ESPs (on the same or on different disks), although the Windows installer flakes out when there are multiple ESPs on a single disk. I'm not sure how the Windows installer copes with a system with multiple ESPs, each on its own disk.
Note that putting the boot loader on the SSD is something of a waste, since the boot loader is normally accessed only during the boot process, so there's relatively little speed gain from putting it on an SSD vs. on a regular hard disk.
Will there be any problems with having one disk still as MBR (I don't have the space needed for backing up those 2TB currently)?
You can mix MBR and GPT; however, on an EFI-based computer, Windows must boot from a GPT disk. (In a conventional setup, this means that C: must be a partition on a GPT disk.) Some EFIs also require that the ESP be on a GPT disk, although I'm not sure how common this requirement is.
It's possible to convert MBR to GPT without data loss by using gdisk, so you can easily convert your 2TB disk to GPT without doing a backup. This operation is actually safer than it might seem, since the MBR and GPT data structures are quite simple, so there's little that can go wrong compared to, say, resizing a partition. That said, there's still some risk, so if you're not booting Windows from the disk, you might want to just leave it as MBR. Also, some MBR-to-GPT conversions will require shrinking a partition, so you'd need to do that in GParted or some other tool before doing the conversion. Of course, you should always keep backups of important data.

[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] EFI grub Install problems

I know this topic has been beat to death but I cannot for the life of me figure this out.
My Config:
1 Hard Drive -- /dev/sda
/dev/sda2 is EFI Partition.
/dev/sda5 is /mnt/boot during the install
/dev/sda6 is /mnt/ during the install
PC has windows 8.1 installed and booting fine with rEFInd installed. I run through the basic arch installation and mount my /dev/sda2 to /boot/ like in the beginners guide.
I chroot and do the commands below: (from the wiki)
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars # ignore if already mounted
# pacman -S grub efibootmgr
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck
It installs fine, and then I run:
# grub-mkconfig -o /boot/grub/grub.cfg
It completes as well, and im left with a EFI/arch_grub/something.efi and then a /grub folder with the config in it on my EFI partition.
When I reboot, grub completly takes over and doesnt boot anything. Just stuck at grub2>...
I have to boot off live CD and remove the EFI/arch_grub folder and the other grub folder to be able to boot windows again.
What am I doing wrong here?
Any help is appreciated....
Last edited by skwid (2013-11-19 17:38:01)

teateawhy wrote:You mounted the boot partition on sda5 to /boot, instead of mounting the ESP on sda2 to /boot. The beginner's guide expects you to mount the ESP to /boot.
Ok, I went back and re-done the entire thing and made sure I mounted /dev/sda5 to /boot. That left me with a /boot/EFI folder which my refind and microsoft folders are in.
Ran through the installs and everything went fine. I have a /boot/EFI/arch_grub/grubx64.efi file and a /boot/efi/grub/ folder with the grub.cfg file. No errors.
Rebooted, and same thing. reFINd no longer runs first, grub does. grub is broken because there are no kernel lines or anything.
When I reboot the PC and select the boot menu in the BIOS, I get a UEFI entry for "arch_grub" and I can select it and it boots to the broken grub.
I can select rEFInd and it will run, but not automatically like it used to.
If I remove all the arch_grub and grub folder from my EFI partition, then everything works, but of course, no arch.

[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

[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: 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)

[SOLVED] UEFI Boot Troubles (ASUS UX31A-DH51)

Hello. I'm a casual linux user - I develop on linux, but I've never really explored the system itself. In an attempt to do so, I am installing Arch on my Asus UX31A-DH51. I copied the image to my external harddrive and followed the beginner's guide; Everything seemed to be going smoothly, except when I tried to boot into the system, it didn't work.
I suspect this has something to do with the bios being UEFI. However, I followed the instructions here to modify GRUB and, when going to "Launch EFI shell from filesystem device", the screen flickers and then a popup is displayed saying "Warning: Not found". I've also tried installing gummiboot, but that didn't work either. In the BIOS, the main HD isn't displayed as one of the devices that I can boot from either.
I've read this post, and I tried again from scratch using the information, but nothing helped. I didn't try archboot, though, since I don't know where to find the ISO or how to make a USB out of it.
The steps I followed are thus (pretty much all of them follow the beginner's guide):
I created a USB from the latest Arch linux iso, using these intstructions from my desktop computer (Mint 15).
I booted into said drive, and was presented with five options. I chose the one too boot into Arch. I tested UEFI support using the method at the beginning of the Beginner's guide; this succeeded.
I connected to the internet using wifi-menu.
Using cgdisk, I erased all the existing partitions on the SSD. I then created three partitions on the drive; a 1.5G EFI System Partition (sda3) - I used the code "ef00" to make it an ESP; a 15G linux partition (sda1); and a 99G linux partition (sda2).
I formatted the partitions. I formatted sda1 and sda2 to ext4, and I formatted sda3 to FAT32.
I mounted sda1 to /mnt, sda2 to /mnt/home, and sda3 to /mnt/boot/efi (I changed "/boot" to "/boot/efi" here because of the link above; here it is again).
I ran pacstrap -i /mnt base, which completed successfully; then, I generated an fstab at /mnt/etc/fstab, which I left as default.
I chrooted into /mnt, uncommented the en_US.UTF8 locale, symlinked the America/New_York timezone, updated the hardware clock, set the hostname, and ran passwd.
I skipped setting up the initial ramdisk environment.
I setup GRUB using the commands under the UEFI section in the guide; I first exited out of the chroot to run the three commands it says to run out of chroot, and then went back into chroot and followed the rest of the steps. The only thing I changed there was to change "/boot" to "/boot/efi". GRUB installed successfully, without any errors.
I ran
grub-mkconfig -o /boot/grub/grub.cfg
Finally, I rebooted, went into the bios, and chose "Launch EFI shell from filesystem device", which gave me "Warning: Not found". The main HD isn't listed as something I can boot from, though it is recognized as a SATA device. I'm kind of stumped after this. I also tried updating the BIOS, to no avail.
I'm feeling a little out of my depth here; hopefully someone can help me get this running. You'll probably need more info to diagnose the issue, but I'm not really certain how I should post those files from my laptop using just the arch shell. Anyhow, hopefully someone can help. In the meantime, I'm going to try the install from scratch again, reading more carefully.
Last edited by Chaosed0 (2013-09-27 18:48:25)

the.ridikulus.rat wrote:I think this is one of the brain-dead issues with some firmwares which expect /EFI/Microsoft/Boot/bootmgfw.efi to be present. Just copy a version of uefi shell to /EFI/Microsoft/Boot/bootmgfw.efi and then reboot into the system and recreate the entry using efibootmgr. For "Launch EFI shell from filesystem device", the shell application needs to be present at <EFISYS>/shellx64.efi (in the root of the efisys partition itself).
I copied "/EFI/grub/grubx64.efi" to "/EFI/Microsoft/Boot/bootmgfw.efi" and created an entry using the same efibootmgr command as two posts above; still no luck. The entry still gets deleted on a reboot, the disk doesn't show up in the devices, etc. I also copied grubx64.efi to /shellx64.efi, but the bios still refuses to recognize it's there.
Here's some output of efibootmgr. This is what it looks like before adding any entries:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002
Boot0001* UEFI: WD My Passport 070A2003
Boot0002* Hard Drive
Here's after adding the entry:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001,0002
Boot0000* grub
Boot0001* UEFI: WD My Passport 070A2003
Boot0002* Hard Drive
After rebooting, it goes back to exactly like it was before adding any entries.
Here's my fstab, if it helps at all:
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda1
UUID=556e2aff-a493-4ca9-a62e-175a890b0d03 / ext4 rw,relatime,data=ordered 0 1
# /dev/sda3
UUID=5B17-E429 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
# /dev/sda2
UUID=90dee4b7-caac-4d46-a9c6-4dae5bfc4cea /home ext4 rw,relatime,data=ordered 0 2
(Figured out how to set up ssh on my desktop, so feel free to ask for any more output or files.)

[SOLVED] UEFI with gummiboot: somtimes (!) just black screen

Hi,
since two days I'm trying to get UEFI work on my Lenovo T420. The problem is that there's only a black screen when activating the "Arch Linux" entry in gummiboot if I have not plugged in the installation medium (as a USB drive). If it's inserted sytemd starts booting but stops at a certain point complaining there are starting jobs running on /dev/sdc (the USB drive); then I get to the rescue shell. If it's not inserted there's just a black screen. To start the system I have to leave the USB drive plugged in and fastly remove it when systemd starts booting after selecting "Arch Linux" in gummiboot. I don't know why, but the system does boot then.
This is what I have done:
In BIOS I changed the settings that it's booting with UEFI "and" BIOS at least trying first BIOS and then UEFI. I followed the installation instructions of the Beginner's Guide (https://wiki.archlinux.org/index.php/Beginners%27_Guide) installing a system with LVM (ensuring that the install medium is booted in UEFI). I followed the recommendations of https://bbs.archlinux.org/viewtopic.php … 3#p1240883 concerning partitioning. This is the setup I have:
niklaas@len-t420-arch ~ % lsblk --output +UUID
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID
sda 8:0 0 238,5G 0 disk
├─sda1 8:1 0 100M 0 part
└─sda2 8:2 0 238,4G 0 part
sdb 8:16 0 119,2G 0 disk
├─sdb1 8:17 0 512M 0 part /boot D3F0-DA3E
├─sdb2 8:18 0 512M 0 part d66ae708-051f-43f8-bae8-b35a985cd75f
└─sdb3 8:19 0 118,2G 0 part Loovu6-pH7j-Ou8r-HiH0-yJFm-Riq7-Pbsi4s
├─VolGroup00-lvroot 254:0 0 25G 0 lvm / 349e5a88-72ca-40cb-8e44-0b67b85ffee4
├─VolGroup00-lvvar 254:1 0 15G 0 lvm /var 46980ec6-f2f3-4a08-a350-f6621a23054f
├─VolGroup00-lvswap 254:2 0 8G 0 lvm [SWAP] 156243f8-f374-4e27-86f0-d442850c6c3f
└─VolGroup00-lvhome 254:3 0 70,2G 0 lvm /home ae86bb5c-2829-4af9-9ffb-0206d10f02a4
(/dev/sda is Windows 7)
Please note that I /dev/sdb1 is the EFI System Partition and there's also another partition (/dev/sdb2) I created just in case I want to use a separate /boot partition. (Currently there's syslinux on it because I was experimenting whether I get the system to boot normaly, which means without the USB drive, by using Legacy BIOS and syslinux. But I was not successful: Screen also stays black.) This is what /boot looks like and the contents of /boot/loader/entries/arch.conf and /boot/loader/loader.conf:
niklaas@len-t420-arch ~ % tree /boot
/boot
├── EFI
│   ├── BOOT
│   │   └── BOOTX64.EFI
│   └── gummiboot
│   └── gummibootx64.efi
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── loader
│   ├── entries
│   │   └── arch.conf
│   └── loader.conf
└── vmlinuz-linux
niklaas@len-t420-arch ~ % cat /boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=UUID=349e5a88-72ca-40cb-8e44-0b67b85ffee4 rw
niklaas@len-t420-arch ~ % cat /boot/loader/loader.conf
timeout 3
default arch
Additionally to the strange USB-drive-needs-to-be-plugged-in issue there is another one: Because there's a Windows 7 installation (unfortunately I need it) on /dev/sda with Truecrypt I decided to install two bootloaders: one is on /dev/sda and the other one on /dev/sdb. So I can "manually" switch between operating systems by using the boot manager that is provided by the BIOS of the motherboard which makes it possible to change boot priority quite simply. After the installation of gummiboot there was (of course) another entry created, so there are three:
1. Linux Boot Manager
2. ~first SSD (with Windows; /dev/sda)
3. ~second SSD (with Arch Linux; /dev/sdb)
When I select the first entry, even the USB-drive-trick does not work. There just resides the black screen. This I do not understand at all because, as already described above:
If I select the third option, gummiboot gets loaded and I can select "Arch Linux". Then, as already mentioned, there are three options: (a) USB-drive is inserted > I plug it off immediately after systemd starts > system boots (b) USB-drive is inserted > I don't (!) plug it off > systemd complains about starting job running on /dev/sdc > I get the rescue shell (c) USB-drive is not (!) inserted > I just get a black screen.
I hope the issue I have is quite understandable. Otherwise, please ask and I'll try my best to clarify things. Any help is really appreciated,
Niklaas
niklaas@len-t420-arch ~ % uname -a
Linux len-t420-arch 3.10.6-2-ARCH #1 SMP PREEMPT Tue Aug 13 09:47:01 CEST 2013 x86_64 GNU/Linux
Last edited by niklaas (2013-08-18 07:02:01)

srs5694 wrote:My hunch is that you're running into the bug that's under discussion here. If so, you may be able to get it working more reliably by switching boot managers (to rEFInd or to the version of rEFInd that's built with GNU-EFI) or boot loaders (to GRUB or ELILO).
OK. I decided to use syslinux and installed it from the AUR. After installation was successfull, I copied all files as described in https://wiki.archlinux.org/index.php/UE … LINUX_6.xx to /boot/syslinux and ran command
# efibootmgr -c -d /dev/sdb -p 1 -l /EFI/syslinux/syslinux.efi -L "syslinux"
to create an entry. And I could just successfully boot without USB-drive. Thank you.
cfr wrote:I don't know why it would work at all in this case but are you sure that you can specify root= like that on the command line? Rather than e.g. root=/dev/VolGroup00/lvroot, for example?
I guess, I also tried this before having the same outcome.
But I still do not understand what's happening when I select my second SSD; because there's still gummiboot loaded and I can still boot the system with the USB-drive. Does anybody know what's happening there? I'm totally clueless why the system is somehow accessing the flash drive?!
Last edited by niklaas (2013-08-18 07:02:31)

[SOLVED] UEFI / Grub Partitioning

Similar Messages

Maybe you are looking for