[SOLVED] UEFI installation - booting failure

Question

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)

Answer 1

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.