You are not logged in.

#26 2013-02-28 18:10:39

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: UEFI boot worked, then broke, now only partly fixed

Post your grub.cfg file, or at least the "menuentry" stanzas that define how GRUB is booting Linux. Chances are you'll find some boot options there that, if you duplicate them in refind_linux.conf, will enable rEFInd to launch Linux.

Offline

#27 2013-02-28 19:46:18

ddaupert
Member
Registered: 2013-01-23
Posts: 14

Re: UEFI boot worked, then broke, now only partly fixed

srs5694 wrote:

Post your grub.cfg file, or at least the "menuentry" stanzas that define how GRUB is booting Linux. Chances are you'll find some boot options there that, if you duplicate them in refind_linux.conf, will enable rEFInd to launch Linux.

Gratitude!

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch GNU/Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-c
ore repo kernel-true-f95acdec-0899-42cb-a713-146298f5d667' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        set root='hd1,gpt1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  f95acdec-0899-42cb-a713-146298f5d667
        else
          search --no-floppy --fs-uuid --set=root f95acdec-0899-42cb-a713-146298f5d667
        fi
        echo    'Loading Linux core repo kernel ...'
        linux   /boot/vmlinuz-linux root=UUID=f95acdec-0899-42cb-a713-146298f5d667 ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initramfs-linux.img
}
menuentry 'Arch GNU/Linux, with Linux core repo kernel (Fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-fallback-f95acdec-0899-42cb-a713-146298f5d667' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        set root='hd1,gpt1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  f95acdec-0899-42cb-a713-146298f5d667
        else
          search --no-floppy --fs-uuid --set=root f95acdec-0899-42cb-a713-146298f5d667
        fi
        echo    'Loading Linux core repo kernel ...'
        linux   /boot/vmlinuz-linux root=UUID=f95acdec-0899-42cb-a713-146298f5d667 ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initramfs-linux-fallback.img
}

/dennis

Offline

#28 2013-03-01 17:15:57

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: UEFI boot worked, then broke, now only partly fixed

Try the following entries in refind_linux.conf:

"Standard boot"    "root=UUID=f95acdec-0899-42cb-a713-146298f5d667 ro quiet initrd=/boot/initramfs-linux.img"
"Fallback boot"    "root=UUID=f95acdec-0899-42cb-a713-146298f5d667 ro quiet initrd=/boot/initramfs-linux-fallback.img"

You can either add them to what's there already or replace what you've got now. If either of them works, you can then try experimenting with adding back some of the options from the refind_linux.conf you posted earlier.

Also note that you can experiment with options on a boot-by-boot basis by pressing F2 or Insert to get the options screen, selecting a specific option, and then pressing F2 or Insert again. That opens a simple line editor you can use to edit the options for a single boot.

Offline

#29 2013-03-02 05:26:17

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: UEFI boot worked, then broke, now only partly fixed

I, too, recently reinstalled the latest Arch after converting to GPT disks and UEFI boot (had to reinstall Windows anyway due to HD failure). I am using only rEFInd. After the first pacman run, the kernel was updated and I could no longer boot, arriving at the dreaded maintenance prompt. I had missed the part in the guide that said the kernel and initramfs and such would need to be recopied to the EFI partition after each kernel update (or possibly run of mkinitcpio). I had to reboot the install medium, mount all the partitions again and chroot and copy over the kernel and initramfs files and the .efi file again to reboot. After this, I read further and setup a service in systemd that monitors for the changes and copies new files to the right places when they change. I even have rEFInd booting my Ubuntu install, just by copying it's kernel and initrd over. I agree with a previous poster, it sounds like the appropriate files didn't get copied back over after a kernel update and / or a mkinitcpio run.

Offline

#30 2013-03-02 18:35:59

ddaupert
Member
Registered: 2013-01-23
Posts: 14

Re: UEFI boot worked, then broke, now only partly fixed

sidneyk wrote:

I, too, recently reinstalled the latest Arch <snip>
After the first pacman run, the kernel was updated and I could no longer boot <snip>
I read further and setup a service in systemd that monitors for the changes and copies new files to the right places when they change. <snip>
it sounds like the appropriate files didn't get copied back over after a kernel update and / or a mkinitcpio run.

Hi sidneyk, thanks for your post. In my case, I set up the systemd service to monitor and copy new kernel & initranfs files all during my initial installation. When I ran pacman to update the system, he upgraded the linux kernel et al, and the monitor/copy script worked great. I was able to boot successfully into the upgraded system. Also, once things did break and I ran the comand to rebuild the initramfs files, all the file sizes and timestamps made sense. That is, the copy from/copy to files had the same file sizes; the datestamp for /boot/vmlinuz-linux was the date of system upgrade, and all the other file datestamps coincided with the initramfs rebuild event.

Anyways, I plan to tear out some more hair today, and see what kind of trouble I can get into ;-)

/dennis

Offline

#31 2013-03-03 03:33:20

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: UEFI boot worked, then broke, now only partly fixed

ddaupert wrote:
sidneyk wrote:

I, too, recently reinstalled the latest Arch <snip>
After the first pacman run, the kernel was updated and I could no longer boot <snip>
I read further and setup a service in systemd that monitors for the changes and copies new files to the right places when they change. <snip>
it sounds like the appropriate files didn't get copied back over after a kernel update and / or a mkinitcpio run.

Hi sidneyk, thanks for your post. In my case, I set up the systemd service to monitor and copy new kernel & initranfs files all during my initial installation. When I ran pacman to update the system, he upgraded the linux kernel et al, and the monitor/copy script worked great. I was able to boot successfully into the upgraded system. Also, once things did break and I ran the comand to rebuild the initramfs files, all the file sizes and timestamps made sense. That is, the copy from/copy to files had the same file sizes; the datestamp for /boot/vmlinuz-linux was the date of system upgrade, and all the other file datestamps coincided with the initramfs rebuild event.

Anyways, I plan to tear out some more hair today, and see what kind of trouble I can get into ;-)

/dennis

Good luck. Sounds like you should have had the bases covered. I'll reread through this thread and see if anything else comes to mind. I spent a good deal of time studying all of this before taking the plunge to use my Sabertooth 990FX the way it was meant to be used. I really like the rEFInd implementation and not having to mess with grub or other boot loaders too much. So far, my board is booting great with EFISTUB and rEFInd. but I've only seen 1 or 2 kernel updates so far.

Offline

#32 2013-03-03 05:13:58

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: UEFI boot worked, then broke, now only partly fixed

I see these steps you say you took in the OP:

Create /boot/efi/EFI/arch/refind_linux.conf
    "Boot to X"        "root=/dev/sdb1 ro rootfstype=ext4 systemd.unit=graphical.target"
    "Boot to console"  "root=/dev/sdb1 ro rootfstype=ext4 systemd.unit=multi-user.target"
  Add rEFInd to UEFI boot menu using efibootmgr.
    efibootmgr -c -g -d /dev/sdb -p 2 -w -L "rEFInd" -l '\EFI\refind\refind_x64.efi'

What I don't see is where you mounted your ESP/EFI partition prior to this. So, a couple of questions, if you don't mind. I know you said that your / of the Arch install is actually /dev/sdb1 and the refind_linux.conf looks correct for that, but is your EFI (ESP) partition actually at sdb2 like the efibootmgr command above suggests. This could be so if you created your own, second EFI partition or, if not dual booting with anything else, this your only EFI partition that you created yourself. I triple boot with Win 7 and Ubuntu and Arch and created only 1 ESP / EFI partition of 300MiB for all to use at /dev/sda1, where it is recommended to be and FAT32 formatted. There is a /dev/sda2 of 128MiB which is Microsoft reserved partition and Win 7 is on /dev/sda3, all of my 120GB SSD. I believe your EFI partition should be the first partition on whatever drive you put it on, normally should be /dev/sda1 and this partition is then flagged as bootable because of it's type. Grub is probably working because it's bootloader is pulling the required kernel and ramfs from the /boot directory instead of the EFI partition. If you haven't already, you might post what your /etc/fstab looks like. I haven't installed grub2 this time and all is working fine with rEFInd and EFISTUB booting, but I'm only using 1 ESP/ EFI partition shared between 3 operating systems and at the recommended location to keep all happy.

Offline

#33 2013-03-03 20:12:24

ddaupert
Member
Registered: 2013-01-23
Posts: 14

Re: UEFI boot worked, then broke, now only partly fixed

sidneyk wrote:

a couple of questions, if you don't mind. I know you said that your / of the Arch install is actually /dev/sdb1 and the refind_linux.conf looks correct for that, but is your EFI (ESP) partition actually at sdb2 like the efibootmgr command above suggests.

Hi sidneyk. Yes it is.

sidneyk wrote:

I believe your EFI partition should be the first partition on whatever drive you put it on, normally should be /dev/sda1 and this partition is then flagged as bootable because of it's type.

I did quite a bit of reading before even attempting my arch install. I recall reading that the EFI partition could be located after the first partition, as long as it is located before (I believe) the 1Terabyte limit. I have been hunting around for that info, but can't locate it at the moment. 

sidneyk wrote:

Grub is probably working because it's bootloader is pulling the required kernel and ramfs from the /boot directory instead of the EFI partition.

I do believe you are correct. According to the UEFI_Bootloaders#GRUB_2.x page, "GRUB 2.x contains its own filesystem drivers and does not rely on the firmware to access the files. It can directly read files from /boot and does not require the kernel and initramfs files to be in the UEFISYS partition. " In the boot process, the efibootmgr hands over to grub to do the actual kernel invocation.

sidneyk wrote:

If you haven't already, you might post what your /etc/fstab looks like.

Sure.

# 
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/sdb1
UUID=f95acdec-0899-42cb-a713-146298f5d667  /          ext4      defaults,noatime,discard,data=ordered   0 1
# /dev/sdb2
UUID=16CE-4963                             /boot/efi  vfat      noatime     0 2
# /dev/sda1
UUID=8c75621e-00e8-4c1c-ad50-0a31d5dfbf08  /var       ext4      rw,relatime,data=ordered        0 2
# /dev/sda2
UUID=8b691a35-1cdd-4f70-a3d7-691fac94b8fb  /home      ext4      rw,relatime,data=ordered        0 2 

By this point, I have removed rEFInd and grub, reinstalled grub only, and rebooted the machine. It is behaving as it did before, that is, I have to enter/exit the BIOS, then KDE loads, etc. But without the BIOS enter/exit dance, I get the 'boot failed' screen.

Lots of "trials and errors." I'm going to put attempts to fix this on the shelf for now. I will look to see if there is a firmware update, but failing that, will live with the BIOS two-step for awhile. I'd like to actually use my machine and explore other nooks and crannies of arch besides this bit.

/dennis

Offline

#34 2013-03-04 00:31:42

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: UEFI boot worked, then broke, now only partly fixed

ddaupert wrote:
sidneyk wrote:

I believe your EFI partition should be the first partition on whatever drive you put it on, normally should be /dev/sda1 and this partition is then flagged as bootable because of it's type.

I did quite a bit of reading before even attempting my arch install. I recall reading that the EFI partition could be located after the first partition, as long as it is located before (I believe) the 1Terabyte limit. I have been hunting around for that info, but can't locate it at the moment.

AFAIK, there are no limits on the ESP's partition number or location on the disk. Certainly I've used systems in which the ESP is not the first partition, either in terms of its number or its on-disk location. I've never heard of a 1TiB limit on the location of the ESP, and in fact the design of EFI makes such a limit rather unlikely; however, on BIOS-based computers, it's often necessary to place the BIOS Boot Partition below the 2TiB mark. It's possible you're getting confused and mixing these up -- or maybe I've just never heard of the limit to which you refer.

Offline

#35 2013-03-05 02:44:13

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: UEFI boot worked, then broke, now only partly fixed

While, technically, there may not be hard limitations on the location of the ESP partition, the general recommendation, I believe even from the rEFInd developer, is that it should be the first partition on disk with the correct type and flagged as boot able. It doesn't look like the OP is dual booting Windows, but if he were, then I believe it would be required to be the first partition, on the first HDD, followed by a MS reserved partition. If the ESP is planned and created ahead and made big enough, it can hold all of the system's boot loaders for various OSs. The stock current kernel in Arch and other Linux's has EFISTUB support and is it's own boot loader and doesn't need grub2 or any other 3rd party boot loader to work, it just needs certain maintenance considerations to keep the updated kernel and initramfs current and in the proper location. I had a kernel update again today and with systemd automation set up it booted fine into the new kernel without any interaction from me. I'd drop grub2, if I were you, and concentrate on getting rEFInd working, because it works well and trims some unneeded complexity from the boot process.

Last edited by sidneyk (2013-03-05 02:45:20)

Offline

#36 2013-03-05 16:53:45

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: UEFI boot worked, then broke, now only partly fixed

sidneyk wrote:

While, technically, there may not be hard limitations on the location of the ESP partition, the general recommendation, I believe even from the rEFInd developer, is that it should be the first partition on disk with the correct type and flagged as boot able.

I am rEFInd's developer. Using /dev/sda1 as the ESP is slightly preferable to using other locations, but that's mainly just because the defaults in efibootmgr are for that partition. Thus, using /dev/sda1 means you need fewer options to efibootmgr to get it to work. OTOH, there are a lot of systems appearing with Windows pre-installed in which the ESP is not /dev/sda1, so  it's really not safe to make the assumption that the ESP is on /dev/sda1 in any public discussion, in scripts, and so on.

Unfortunately, the phrase "flagged as bootable" is rather ambiguous with respect to GPT. There are two features to which that phrase might refer:

  • The ESP partition type code -- Unfortunately, the libparted developers chose to identify the ESP type code (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) with the same "boot flag" user interface notation that's used to identify the boot flag on MBR disks. The two concepts are only vaguely similar, so using one user interface element for both concepts is confusing.

  • Setting the "legacy BIOS bootable" attribute flag -- This flag is used by SYSLINUX and perhaps other boot loaders to denote a partition that's bootable in BIOS; it's effectively the GPT analog of the MBR "boot flag." Unfortunately, since the libparted developers chose to use the "boot flag" to identify the ESP, they need to use a different flag for this one: "legacy_boot".

In the context of your comment, when using a libparted-based tool (such as parted or GParted), you'd set the "boot flag" on the ESP to identify it as such. Setting this flag is the same thing as setting the ESP type code on the partition. Technically, it's not an ESP if it doesn't have that type code. Not all tools use this terminology, though. Most notably in Linux, the GPT fdisk family (gdisk, sgdisk, and cgdisk) use two-byte type codes based on MBR type codes, so the ESP is identified as having a type code of EF00. In these tools, it's possible to set the "legacy BIOS bootable" attribute by using the "a" option on the experts' menu, but this is not required on the ESP.

It doesn't look like the OP is dual booting Windows, but if he were, then I believe it would be required to be the first partition, on the first HDD, followed by a MS reserved partition.

Microsoft has a Web page that covers this, in the Windows GPT Required Partitions section. The language is a little ambiguous; the site says "the ESP should be first on the disk. While there is no architectural requirement, there are numerous reasons why it is beneficial to place the ESP first." This boils down to putting the ESP first reducing the risk of subsequent complications with partition moves and resizing. As a practical matter, several OEMs are shipping Windows 8 PCs on which the ESP is not the first partition on the disk, so some OEMs are ignoring Microsoft's recommendations on this score. Certainly it's not a requirement in the sense of something that will prevent Windows from installing if the ESP is not the first partition on the disk.

Offline

#37 2013-03-06 05:13:48

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: UEFI boot worked, then broke, now only partly fixed

@srs5694 - Sorry, I didn't catch til later that you were the rEFInd dev. Most of what I'm learning about EFI booting is coming from you and Arch wiki. I haven't had the chance to look at any pre-installed Win 8 computers and probably won't make the move on my own PC. I just had an Asus board with UEFI and wanted to see if there were noticeable differences between MBR compatible boot and UEFI boot. I just went with what seemed to be a consensus recommendation between Windows and Linux and made a larger ESP and kept everything on the first drive which happens to be my SSD drive. For me and with rEFInd, all is working great with that setup and, while I liked and used grub2 for quite awhile, I'm happy to not have to anymore. The simplicity of just copying kernels and initrd to the appropriate places and having it boot is good with me. Thanks for your clarifications from being deeper in the weeds in this stuff than I. My main point was to just keep things as simple as possible, particularly with boot processes. No need for complications that don't need to exist. I'm off to do a reinstall of Arch now, just to practice what I've learned and to insure I have all just as I want it.

Offline

Board footer

Powered by FluxBB