[SOLVED] New Install Successful - Can't boot

charchdo · 2013-10-28 09:37:46

[SOLUTION: Use the same program to create the partition table and the partitions]

So I did a fresh install of Fedora 19 to see if that might fix my battery problem. It didn't. I thought about sticking with Fedora but I preferred pacman' over 'yum' amongst other things.

EDIT: I should point out I am using the latest iso - Current Release: 2013.10.01 - Included Kernel: 3.11.2

So I decided to put Arch back on. I went through all the beginners guide and everything appeared to go smoothly but then the machine wouldn't boot. After I turn it on the InsydeH20 bios doesn't find the boot loader. I think I need to change the path of my boot files. This is the current setup:

[I am writing this from another computer so can't copy and paste the code]

/dev/sda1 is my EFI System Partition. [Type: ef00 and formatted to vfat -F32]

/dev/sda2 is my root partition with /home and everything else. [Type is 8300 formatted to ext4]

I did this when it came time to load gummiboot as my boot manager:

# mount /dev/sda2 /mnt
# mkdir -p /mnt/boot
# mount /dev/sda1 /mnt/boot
# arch-chroot /mnt
sh-4.2# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
sh-4.2# pacman -S gummiboot
.
.
.
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/gummiboot/gummibootx64.efi
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/Boot/BOOTX64.efi
Created EFI boot entry "Linux Boot Manager".
sh-4.2# efibootmgr
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0007, 0005, 0000
Boot0000* Linux Boot Manager
Boot0005* Sony Original
Boot0007* UEFI: SanDisk USB
sh-4.2#

The last coule of times I've intalled the 'Linux Boot Manager' has been the first in the BootOrder but still the computer didn't boot.

/dev/sda1 has as its first level /EFI. Does it need to be /boot/EFI or /efi/EFI? I seem to recall having /efi/EFI on my last Arch install. I tried to make /efi/EFI/:

# mkdir /mnt/boot/efi

after I have mounted /dev/sda1 but it says the directory already exists i.e /EFI/ . I thought Linux was case sensitive??

Can anyone offer some insight?

Last edited by charchdo (2013-10-31 12:27:06)

alezost · 2013-10-28 10:59:33

charchdo wrote:

I went through all the beginners guide and everything appeared to go smoothly but then the machine wouldn't boot. After I turn it on the InsydeH20 bios doesn't find the boot loader.
...
The last coule of times I've intalled the 'Linux Boot Manager' has been the first in the BootOrder but still the computer didn't boot.

So do you have 'Linux Boot Manager' option (and it won't boot) or there are no boot options in your firmware now?
Do you get any error message?

charchdo wrote:

I tried to make /efi/EFI/:
# mkdir /mnt/boot/efi
after I have mounted /dev/sda1 but it says the directory already exists i.e /EFI/ . I thought Linux was case sensitive??

AFAIK FAT filesystem is case insensitive.

charchdo · 2013-10-28 11:31:18

So do you have 'Linux Boot Manager' option (and it won't boot) or there are no boot options in your firmware now?
Do you get any error message?

I can't even get that far. It goes straight to the BIOS interface to troubleshoot. I also tried legacy boot but the error I got was 'no operating system found'. I think I need to point the bios to the right location but not too sure how to do that.

AFAIK FAT filesystem is case insensitive.

That would make perfect sense then.

Also i just ran the following:

# efibootmgr -v
Boot 0000* Linux Boot Manager HD(1,800,200000,cee20f93...)File(/EFI/gummiboot/gummibootx64.efi)
Boot 0005* Sony Original Vendor
****error in 'efibootmgr': free(): invalid pointer: 0x0007fff72c55788***
=======backtrace=========
/user/lib/libc.so.6 (....)
.
.
.
.
7fff72c3600-7fff72c5700 rw-p 00000000 00:00      [stack]     #the invalid pointer is in this section! I think. I don't know what this means though

[signing off for the night back tomorrow]

Last edited by charchdo (2013-10-28 11:52:28)

alezost · 2013-10-28 14:20:56

charchdo wrote:

So do you have 'Linux Boot Manager' option (and it won't boot) or there are no boot options in your firmware now?
Do you get any error message?
I can't even get that far. It goes straight to the BIOS interface to troubleshoot. I also tried legacy boot but the error I got was 'no operating system found'. I think I need to point the bios to the right location but not too sure how to do that.

Ok, so you don't have boot options. Not so long ago i got the similar behaviour when i decided to install some GNU/Linux distribution on a recently bought laptop. It was the first time i met UEFI system, but by habit i downloaded a 32-bit image (it was Alt Linux). I made new partitions with GParted from this image and installed the distro. After that i was thrown to the firmware interface (i'm not sure if it should be called "BIOS") without any boot option. So i had to load a kernel by booting grub (btw i have never used gummiboot) from USB stick and manually writing "linux", "initrd", "boot" commands there. Then i modified grub.cfg on USB for booting a kernel from my HDD.

I didn't know what was wrong, happily after a couple of days i made another partition for Arch Linux (it was a 64-bit system this time) and after installing it i found that my HDD is recognized as a boot device again.

So i'm absolutely not sure what happened, but i think partitioning with parted under 32-bit OS modified partition table so, that it wasn't recognized by BIOS anymore. And partitioning (i used parted again) under 64-bit OS returned it to the norm.

Perhaps you did something similar. Did you install 64-bit Arch Linux? Did you modify your partitions for this installation?

WonderWoofy · 2013-10-28 14:40:21

Did you actually configure gummiboot? It requires a small directory structure of config files in the ESP. Namely, you need to have \loader\loader.conf to even get to a boot menu, and you will also need to have \loader\entries\*.conf files for the configurations.
http://freedesktop.org/wiki/Software/gummiboot

I'm going to remove all my config files and see what happens... I'll let you know.

Edit: Well I still ended up with a minimal menu, but I'm not sure if that is because I have the UEFI Shell v2 in the root of my ESP, which is automgacially detected and listed... I think this might actually be a bios quirk, which is the hardest thing to get around. In the short term, you might want to simply install with the bios compatibility mode and just to get things up and running. Then set things up from a familiar environment.

Last edited by WonderWoofy (2013-10-28 14:46:20)

charchdo · 2013-10-29 02:44:34

@alezost - I might try that when I get home - getting to gummiboot on USB and point to /dev/sda1 to boot from. I'll let you know how that goes.

@wonderwoofy - yes to having installed the configuration files, both arch.conf and loader.conf.

Just wondering with arch.conf...:

# cat arch.conf
title            Arch Linux    
linux          /vmlinuz-linux
initrd         /initramfs-linux.img
options      root=/dev/sda1 rw

...should you use 'tab' or 'spaces' to separate 'title/linux/initrd/options' from their values?

I changed from UEFI to BIOS Legacy and that didn't work (no operating system found), if that's what you mean by BIOS compatibility mode?? Is your ESP path /EFI/Boot/BOOTX64.efi ?

WonderWoofy · 2013-10-29 02:52:57

charchdo wrote:

...should you use 'tab' or 'spaces' to separate 'title/linux/initrd/options' from their values?

White space is white space. It doesn't matter what you choose. I have vim set to expant tabs to four spaces, but that is just personal preference.

I changed from UEFI to BIOS Legacy and that didn't work (no operating system found), if that's what you mean by BIOS compatibility mode?? Is your ESP path /EFI/Boot/BOOTX64.efi ?

Yeah, bios compatibility mode means the same thing as legacy bios. It is just different terminology that seems to simply depend on whatever your hardware's vendor deems preferrable.

I don't know what you are asking with the second question. The path to the default efi application (also referred to as the fallback loader) is \EFI\boot\bootx64.efi. vfat is case insensitive, so what you have in the quote is the same thing. Its not really relevant to your issue, but I mount my ESP at /boot/efi because I am a btrfs user and I like the have the kernel and modules in /usr/lib/modules in the same snapshot (if that is what this question was about).

charchdo · 2013-10-29 06:03:21

Thanks wonder woofy. I was never sure about the white space.

And yes that answers my question and then some about the default efi application path.

I'll try out a few things tonight and post back on my progress.

I wonder if I need to reset my BIOS or CMOS...we'll see.

charchdo · 2013-10-29 09:21:49

Thanks to both of you for your advice and feedback and to wonder woofy for trying a boot without your config files.

At this stage I will attempt a BIOS compatibility install this weekend when I generally have more time than after work and report back.

@alezost - for this install I completely wiped the SSD to start afresh. I used fdisk to create a new GPT and cgdisk to create the partitions since I couldn't see where on fdisk to make them ef00 and 8300 which was odd since I thought I wrote a new table and created partitions and type in fdisk the first install I did.

Also I tried without success to use the USB to boot the initramfs-linux.img from /dev/sda1. Dang. For that I changed the boot line to initrd=\EFI\initramfs-linux.img but that was wrong. I might try install grub and see if that can trigger anything for me. I read somewhere that after someone did this they were able to boot successfully even though they weren't using grub.

teateawhy · 2013-10-29 09:54:02

charchdo wrote:

I used fdisk to create a new GPT and cgdisk to create the partitions since I couldn't see where on fdisk to make them ef00 and 8300 which was odd since I thought I wrote a new table and created partitions and type in fdisk the first install I did.

There are multiple issues with this, at first fdisk can not create GPT partition tables. If you run cgdisk afterwards, any changes fdisk has made are overwritten. Secondly fdisk uses different partition type codes than gdisk. Also it is not a good idea to use MBR partition table (created with fdisk) for UEFI booting.

initrd=\EFI\initramfs-linux.img

UEFI uses backward slash \ as path separator, however this is a commandline option passed to the linux kernel.

alezost · 2013-10-29 10:51:19

teateawhy wrote:

charchdo wrote:
I used fdisk to create a new GPT and cgdisk to create the partitions since I couldn't see where on fdisk to make them ef00 and 8300 which was odd since I thought I wrote a new table and created partitions and type in fdisk the first install I did.
There are multiple issues with this, at first fdisk can not create GPT partition tables. If you run cgdisk afterwards, any changes fdisk has made are overwritten. Secondly fdisk uses different partition type codes than gdisk. Also it is not a good idea to use MBR partition table (created with fdisk) for UEFI booting.

charchdo, i think this broke your partition table. As teateawhy pointed the original fdisk doesn't like GPT. Perhaps you will have to repartition a disk with gdisk or parted (gparted worked for me at least).
Also read https://wiki.archlinux.org/index.php/GPT if you have not read it yet.

charchdo · 2013-10-29 22:57:20

teateawhy wrote:

There are multiple issues with this, at first fdisk can not create GPT partition tables. If you run cgdisk afterwards, any changes fdisk has made are overwritten. Secondly fdisk uses different partition type codes than gdisk. Also it is not a good idea to use MBR partition table (created with fdisk) for UEFI booting.

Thanks teateawhy.I used fdisk for my first install and did create a GPT not MBR. I read that fdisk had been re-written to be able to write GPT but there was a warning that it was a new feature so to use with caution. Since I used it for my first install I used again but also used cgdisk for the partitions. I should have known better than to use different programs for this kind of stuff.

It's a learning process.

teateawhy wrote:

initrd=\EFI\initramfs-linux.img
UEFI uses backward slash \ as path separator, however this is a commandline option passed to the linux kernel.

Noted.

alezost wrote:

charchdo, i think this broke your partition table. As teateawhy pointed the original fdisk doesn't like GPT. Perhaps you will have to repartition a disk with gdisk or parted (gparted worked for me at least).
Also read https://wiki.archlinux.org/index.php/GPT if you have not read it yet.

I will do as you suggest and use the one program to write the GPT and the same program to create the partitions. I will post back to let you know how that goes. Thanks for all the feedback and advice. And I will read that GPT on the wiki. The boot process is a bit of a vortex of confusion for me and is something I really want to get my head around.

the.ridikulus.rat · 2013-10-30 08:22:49

teateawhy wrote:

initrd=\EFI\initramfs-linux.img
UEFI uses backward slash \ as path separator, however this is a commandline option passed to the linux kernel.

Recent kernels (I think from kernel 3.10) support using unix-style forward slash / as path separator.

initrd=/EFI/initramfs-linux.img

the.ridikulus.rat · 2013-10-30 08:25:16

charchdo wrote:

Thanks teateawhy.I used fdisk for my first install and did create a GPT not MBR. I read that fdisk had been re-written to be able to write GPT but there was a warning that it was a new feature so to use with caution. Since I used it for my first install I used again but also used cgdisk for the partitions. I should have known better than to use different programs for this kind of stuff.

util-linux fdisk supports GPT but its siblings sfdisk and cfdisk do not. And fdisk does not contain all the features supported by gdisk (including MBR to GPT conversion) as it is still new.

charchdo · 2013-10-31 12:30:11

Well a big thanks to all involved and for asking the right questions.

I used gdisk to create the GPT and also the EFI boot partition and / partition. The install went well and upon 'reboot' the gummiboot menu came up.

I actually think that it was gdisk that I used for my first install a couple of months ago and not fdisk.

Last edited by charchdo (2013-10-31 12:31:56)

Arch Linux

#1 2013-10-28 09:37:46

[SOLVED] New Install Successful - Can't boot

#2 2013-10-28 10:59:33

Re: [SOLVED] New Install Successful - Can't boot

#3 2013-10-28 11:31:18

Re: [SOLVED] New Install Successful - Can't boot

#4 2013-10-28 14:20:56

Re: [SOLVED] New Install Successful - Can't boot

#5 2013-10-28 14:40:21

Re: [SOLVED] New Install Successful - Can't boot

#6 2013-10-29 02:44:34

Re: [SOLVED] New Install Successful - Can't boot

#7 2013-10-29 02:52:57

Re: [SOLVED] New Install Successful - Can't boot

#8 2013-10-29 06:03:21

Re: [SOLVED] New Install Successful - Can't boot

#9 2013-10-29 09:21:49

Re: [SOLVED] New Install Successful - Can't boot

#10 2013-10-29 09:54:02

Re: [SOLVED] New Install Successful - Can't boot

#11 2013-10-29 10:51:19

Re: [SOLVED] New Install Successful - Can't boot

#12 2013-10-29 22:57:20

Re: [SOLVED] New Install Successful - Can't boot

#13 2013-10-30 08:22:49

Re: [SOLVED] New Install Successful - Can't boot

#14 2013-10-30 08:25:16

Re: [SOLVED] New Install Successful - Can't boot

#15 2013-10-31 12:30:11

Re: [SOLVED] New Install Successful - Can't boot

Board footer