You are not logged in.

#1 2013-02-24 19:09:45

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

UEFI boot worked, then broke, now only partly fixed

My problem:

My new arch install no longer boots normally. On startup,
Megatrends bios gives the message (snipped for brevity):
'Boot crashed. Hit del to enter bios'

I enter bios, immediately exit bios, and now I get the
grub menu, and can boot successfully.

I'm not sure how to fix this.

Brief Historical Summary:

Built new pc -- UEFI Motherboard: ECS GOLDEN Z77H2-A2X
Installed arch 2013.02.01 using Beginner's Guide
Boots fine
Installed KDE4, kdm
Upgraded using 'pacman -Syu' -- now I have 3.7.9-1-ARCH
Rebooted
Boots fine
Installed audio packages following the arch Pro Audio page
Boot broken -- can not boot from initramfs
But fallback still works
Rebuilt initramfs using 'mkinitcpio -p linux'
Now initramfs works, but only after entering/exiting bios.

Further info:

I still have not wrapped my head around the ins and outs of
UEFI and the whole boot process. I followed the Guide's
instructions as carefully as possible, but in a rote way.
Something in there got garbaged, but I am not sure how to
take out the garbage. So let me list the steps I did take
during install, beginning with the 'EFISTUB' section.

  Copy the kernel and initramfs files:
    mkdir /boot/efi/EFI/arch/
    cp /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi
    cp /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img
    cp /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img
    (set up auto update using systemd)
  Set up a rEFInd bootloader
    pacman -S refind-efi efibootmgr
  Install rEFInd to the UEFISYS partition
    mkdir -p /boot/efi/EFI/refind
    cp /usr/lib/refind/refind_x64.efi /boot/efi/EFI/refind/refind_x64.efi
    cp /usr/lib/refind/config/refind.conf /boot/efi/EFI/refind/refind.conf
    cp -r /usr/share/refind/icons /boot/efi/EFI/refind/icons
  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'
  As a fallback, in case efibootmgr created boot entry does not work:
    cp -r /boot/efi/EFI/refind/* /boot/efi/EFI/boot/
    mv /boot/efi/EFI/boot/refind_x64.efi /boot/efi/EFI/boot/bootx64.efi
  Install grub
    pacman -S grub-efi-x86_64 efibootmgr
    grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck
    cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo
    efibootmgr -c -g -d /dev/sdb -p 2 -w -L "Arch Linux (GRUB)" -l '\EFI\arch_grub\grubx64.efi'
    grub-mkconfig -o /boot/grub/grub.cfg

Additional:
# lsblk -f
sda                                                     
├─sda1 ext4         8c75621e-00e8-4c1c-ad50-0a31d5dfbf08 /var
└─sda2 ext4         8b691a35-1cdd-4f70-a3d7-691fac94b8fb /home
sdb                                                     
├─sdb1 ext4         f95acdec-0899-42cb-a713-146298f5d667 /
└─sdb2 vfat         16CE-4963                            /boot/efibootmgr

/dennis

Offline

#2 2013-02-24 20:09:22

swordfish
Member
Registered: 2012-01-14
Posts: 160

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

Hm, everything seems to be okay. Only thing I wonder about is why you've installed rEFInd and grub? One of them would be enough ...

Anyway - could you please deliver the output of

$ sudo modprobe efivars
$ sudo efibootmgr -v

And are you able to get to the boot-select menu using one of the F-buttons during BIOS-POST?

Ah, and could you please use code or quote tags?!


Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)

Offline

#3 2013-02-24 21:37:22

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

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

Thanks, swordfish, for your reply.

swordfish wrote:

Hm, everything seems to be okay. Only thing I wonder about is why you've installed rEFInd and grub? One of them would be enough ...

That was not clear to me at the time.

swordfish wrote:

Anyway - could you please deliver the output of

$ sudo modprobe efivars
$ sudo efibootmgr -v

I do not yet have a non-root user configured for sudo. Meanwhile, I only use root for system-level ops.

[root@sndtux ~]# modprobe efivars
[root@sndtux ~]# efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0002,0000,0001
Boot0000* SATA  PM: ASUS    DRW-24B1ST          BIOS(10,0,00)
Boot0001* SATA  PM: WDC WD10JUCT-63J6SY0        BIOS(11,0,00)
Boot0002* rEFInd        HD(2,3200800,800000,c1d89587-9814-4b67-8862-30d45d94a4d9)File(\EFI\refind\refind_x64.efi)
Boot0003* arch_grub     HD(2,3200800,800000,c1d89587-9814-4b67-8862-30d45d94a4d9)File(\EFI\arch_grub\grubx64.efi)
swordfish wrote:

And are you able to get to the boot-select menu using one of the F-buttons during BIOS-POST?

No, the only F-key that is useful is the F2 key, which puts me into the bios. F12, for example, still results in the 'boot failed' screen.

/dennis

Offline

#4 2013-02-25 09:56:36

swordfish
Member
Registered: 2012-01-14
Posts: 160

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

Hm, the output of "efibootmgr  -v" looks pretty good and - as I already said - I can't find a failure in your first post. So, theoretically it should work just fine.

My best guess would be a BIOS problem. You could look if there is an update for your BIOS available or - if not - you could try deleting rEFInd and grub and install just one of it new. I don't know if this could solve your problem, but it might worth a try.


Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)

Offline

#5 2013-02-25 11:04:34

wombat23
Member
Registered: 2011-01-14
Posts: 46

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

ddaupert wrote:
[root@sndtux ~]# modprobe efivars
[root@sndtux ~]# efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0002,0000,0001
Boot0000* SATA  PM: ASUS    DRW-24B1ST          BIOS(10,0,00)
Boot0001* SATA  PM: WDC WD10JUCT-63J6SY0        BIOS(11,0,00)
Boot0002* rEFInd        HD(2,3200800,800000,c1d89587-9814-4b67-8862-30d45d94a4d9)File(\EFI\refind\refind_x64.efi)
Boot0003* arch_grub     HD(2,3200800,800000,c1d89587-9814-4b67-8862-30d45d94a4d9)File(\EFI\arch_grub\grubx64.efi)

you could try setting the BootCurrent from 3 (grub) to 2 (refind). it should be explained somewhere in the wiki how to do that.

i take it you followed the Beginner's Guide section 2.13.2 you should have chosen between EITHER the efistub OR the grub variant. i don't see why they should interfere with each other, though.

seems like you need to sort this out by trial and error. EFI firmware implementations are known to show weird (i.e. nonstandard) behaviour. a firmware update might be worth a try. are you sure that it is the grub menu that shows up and not a refind menu when it works?

Offline

#6 2013-02-25 11:39:20

swordfish
Member
Registered: 2012-01-14
Posts: 160

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

wombat23 wrote:

you could try setting the BootCurrent from 3 (grub) to 2 (refind). it should be explained somewhere in the wiki how to do that.

"man efibootmgr" is all you need wink

Think, it should be:

# efibootmgr -n 2

This should should change the bootorder from Grub to rEFInd just for the next boot.

It might be worth to try this, because it will tell you, if there is a problem with Grub or not.

wombat23 wrote:

are you sure that it is the grub menu that shows up and not a refind menu when it works?

This should be pretty clear. rEFInd uses per default a colorful screen with symbols of the available operating systems (if the kernels are in the right place). One can switch to a textonly screen but that has to be accomplished in refind.conf, and even in textmode rEFInd will look obviously different from Grub wink .


Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)

Offline

#7 2013-02-25 11:55:04

wombat23
Member
Registered: 2011-01-14
Posts: 46

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

swordfish wrote:

This should be pretty clear. rEFInd uses per default a colorful screen with symbols of the available operating systems (if the kernels are in the right place). One can switch to a textonly screen but that has to be accomplished in refind.conf, and even in textmode rEFInd will look obviously different from Grub wink .

i have never used rEFInd so i wasn't sure if there was a potential misunderstanding (which can often make remote troubleshooting really cumbersome), and I am not sure if OP knows the difference. but thanks for the info smile

Offline

#8 2013-02-25 14:59:26

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

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

wombat23 wrote:

are you sure that it is the grub menu that shows up and not a refind menu when it works?

Yes, 100% sure, and based on swordfish'es "colorful" explanation, I am even more sure ;-)

wombat23 wrote:

you could try setting the BootCurrent from 3 (grub) to 2 (refind). it should be explained somewhere in the wiki how to do that.

swordfish wrote:

"man efibootmgr" is all you need wink

Think, it should be:

# efibootmgr -n 2

This should should change the bootorder from Grub to rEFInd just for the next boot.

It might be worth to try this, because it will tell you, if there is a problem with Grub or not.

wombat23, that was an excellent idea. When I invoke refind, the box doesn't boot, hangs, behaves just as it did before I fixed the broken initramfs file. So it looks like the problem is on the refind side, and not on grub.

Also, I'm pretty sure there's not a problem with the BIOS, since this was all working smoothly at one point, before things hit the fan.

swordfish, I will take your suggestion and remove the refind pieces, tho now that I'm back to work from vacation, things will take longer,
maybe even a couple days :-(

I don't yet have a good understanding of the boot process where UEFI and refind comes into play, so will continue to read up. I had assumed the
system would pass to grub, since it's configured that way. But it appears there's some auto detection going on, that the system is
perhaps getting confused by (as you point out) having both refind and grub in there? And given that refind may be garbaged, that's
what's throwing it off, maybe?

Thanks, guys, I really appreciate the assist.

/dennis

I

Offline

#9 2013-02-25 15:49:35

swordfish
Member
Registered: 2012-01-14
Posts: 160

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

ddaupert wrote:

I don't yet have a good understanding of the boot process where UEFI and refind comes into play, so will continue to read up. I had assumed the
system would pass to grub, since it's configured that way. But it appears there's some auto detection going on, that the system is
perhaps getting confused by (as you point out) having both refind and grub in there? And given that refind may be garbaged, that's
what's throwing it off, maybe?

Well, normally rEFInd and Grub should peacefully coexist on an UEFI system (it's just not necessary to have both, unless for testing reasons). But, since every manufacturer installs an individual "interpretation" of UEFI, no one can say how a board behaves in certain situations.

I don't think that rEFInd is "garbaged" as you've said, because you never used it (and you've installed it in the correct way). But in your first posting you have written:

Upgraded using 'pacman -Syu' -- now I have 3.7.9-1-ARCH
Rebooted
Boots fine
Installed audio packages following the arch Pro Audio page
Boot broken -- can not boot from initramfs
But fallback still works
Rebuilt initramfs using 'mkinitcpio -p linux'
Now initramfs works, but only after entering/exiting bios.

And this is pretty unusual, because there are some folks on the forum having problems with certain 3.7* kernels and UEFI. But I can't imagine how an audio package could harm your EFISYS partition. Or did you install a new - maybe modified - kernel for the audio packages?

Last edited by swordfish (2013-02-25 15:51:35)


Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)

Offline

#10 2013-02-25 17:42:24

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

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

ddaupert wrote:

When I invoke refind, the box doesn't boot, hangs, behaves just as it did before I fixed the broken initramfs file. So it looks like the problem is on the refind side, and not on grub.

It's not clear from your description when the hang occurs when you use rEFInd, and this is critically important for diagnosing the problem. For instance, if when you try to use rEFInd, you don't see a rEFInd screen, just a blinking cursor or some such, then the problem could be with rEFInd or with an improper entry for rEFInd in the EFI's own boot manager (as shown by the efibootmgr output). If, however, rEFInd shows up and gives you various boot options, but selecting a Linux option causes the computer to hang, then it could be a bug in rEFInd, an error in the rEFInd configuration (say, improper options being passed to the kernel), or a bug in the EFI stub loader. This last seems like a very real possibility, since as others have noted, there's a big long thread on this forum in which such problems are currently being discussed -- some (but not all) recent 3.7.x kernels on Arch seem incapable of booting via their built-in EFI stub loaders on some (but not all) computers.

If you could post a clearer description of what happens when you attempt to use rEFInd, including any messages that appear on the screen, it could go a long way toward resolving your problem.

Offline

#11 2013-02-25 19:22:40

wombat23
Member
Registered: 2011-01-14
Posts: 46

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

i just realized you said you installed some audio stuff. what exactly did you isntall? a custom kernel? that could cause trouble. as srs5694 said, refind could be misconfigured so it does not start. still doesnt explain why grub only works after you entered the firmware setup...

Offline

#12 2013-02-26 01:54:11

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

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

srs5469 wrote:

It's not clear from your description when the hang occurs when you use rEFInd, and this is critically important for diagnosing the problem. For instance, if when you try to use rEFInd, you don't see a rEFInd screen, just a blinking cursor or some such, then the problem could be with rEFInd or with an improper entry for rEFInd in the EFI's own boot manager (as shown by the efibootmgr output).

I get the actual rEFInd screen, with the colors and symbols. I can move from entry to entry using the arrow keys.

srs5469 wrote:

If, however, rEFInd shows up and gives you various boot options, but selecting a Linux option causes the computer to hang, then it could be a bug in rEFInd, an error in the rEFInd configuration (say, improper options being passed to the kernel), or a bug in the EFI stub loader. This last seems like a very real possibility, since as others have noted, there's a big long thread on this forum in which such problems are currently being discussed -- some (but not all) recent 3.7.x kernels on Arch seem incapable of booting via their built-in EFI stub loaders on some (but not all) computers.

If you could post a clearer description of what happens when you attempt to use rEFInd, including any messages that appear on the screen, it could go a long way toward resolving your problem.

When I select the main kernel from within the rEFInd screen, all the pretty colors disappear, I'm at the command line, and these messages have appeared:

:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
Waiting 10 seconds for device /dev/sdb1...
ERROR: device '/dev/sdb1' not found. Skipping fsck.
ERROR: Unable to find root device '/dev/sdb1'
You are being dropped to a recovery shell
  Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[rootfs /]#

Now there's just the blinking cursor at end of last line, and no response to keyboard.

/dennis

Offline

#13 2013-02-26 02:17:47

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

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

wombat23 wrote:

i just realized you said you installed some audio stuff. what exactly did you isntall? a custom kernel? that could cause trouble. as srs5694 said, refind could be misconfigured so it does not start. still doesnt explain why grub only works after you entered the firmware setup...

Audio app installs causing this seems bizarre and improbable to me as well, but I wanted to report what all I did, as best as I can.

I also remembered just today that after installing audio apps, I invoked the 'sleep' option, and ran an errand. On return, when I tried to wake the machine up, that's when I found he wouldn't wake up, and he also wouldn't boot.

Anyways, I did not install a custom kernel. I followed a few instructions on wiki.archlinux.org/index.php/Pro_Audio:

# pacman -S jack2
# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden qsynth jsampler lmms ladspa-plugins dssi

I stopped there, did not mess with linux-rt or systemd-rtirq, and only added my login user to the audio group.

Oh, and also I installed Amarok, Juk, and VLC.

/dennis

Offline

#14 2013-02-26 03:03:12

s1ln7m4s7r
Member
Registered: 2013-02-22
Posts: 262

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

it seems it can`t find sdb1 - first partition of one of your harddrives (by the designation of the partition you have at least 2 HDD), it looks for /boot under your root partition. Have you changed anything related to your disk setup or have a USB device connected? you should change the boot line of your bootloader to search in the correct partition.

Offline

#15 2013-02-26 03:59:29

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

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

ddaupert wrote:

When I select the main kernel from within the rEFInd screen, all the pretty colors disappear, I'm at the command line, and these messages have appeared:

:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
Waiting 10 seconds for device /dev/sdb1...
ERROR: device '/dev/sdb1' not found. Skipping fsck.
ERROR: Unable to find root device '/dev/sdb1'
You are being dropped to a recovery shell
  Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[rootfs /]#

Now there's just the blinking cursor at end of last line, and no response to keyboard.

In this case, rEFInd has done what it should, at least to a first approximation. (That is, the rEFInd program is OK, but its configuration might not be.) The problem is most likely one of the following:

  • Improper options passed to the kernel from rEFInd. The most likely issue here is with the "root=" option; if your Linux root (/) device is not /dev/sdb1, you must change what's passed to the kernel from rEFInd, most likely by fixing a broken refind_linux.conf file, or perhaps by editing a manual boot entry in refind.conf.

  • A failure to include an initial RAM disk on the kernel command line. This can happen if the initrd file is missing or if you've done a manual rEFInd configuration and forgotten to specify it.

  • A broken initrd file. This can happen because of improper options when creating the initrd file. I'm not an expert on Arch's initrd-creation process, so I can't be sure what might be going wrong here or how to fix it. Broadly speaking, though, one possible problem is with missing drivers.

Other messages printed on the screen may help you diagnose this problem. Unfortunately, many of them pass by so quickly that you can't read them. Some of the most critical are the ones that rEFInd displays when you select the Linux entry -- rEFInd should show you the options it's passing to the kernel. You can read these more readily by pressing F2 or Insert twice rather than pressing Enter; this launches a line editor that you can use to examine and edit the options. (Be aware that if you've got lots of options, they'll scroll off the right side of the screen, and you'll have to move your cursor over to read them all.) You may want to start by examining these options and, if you're not 100% sure that they're correct, fixing them or at least reporting them here.

One more point: I seem to recall that GRUB 2 has a feature that enables it to detect boot failures and, if one occurs, launch a different kernel or launch a kernel in a different way. I'm foggy on the details, though, and I may actually be thinking of something else. If I'm right, though, this could explain the inconsistent behavior when booting with GRUB -- a failure might be followed by a boot using an older or recovery kernel.

Offline

#16 2013-02-26 15:30:30

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

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

s1ln7m4s7r wrote:

it seems it can`t find sdb1 - first partition of one of your harddrives (by the designation of the partition you have at least 2 HDD), it looks for /boot under your root partition. Have you changed anything related to your disk setup or have a USB device connected? you should change the boot line of your bootloader to search in the correct partition.

I wondered about that same possibility when I saw the error messages the very first time. But in fact when I do the 'enter BIOS/exit BIOS tango' the grub menu points to /dev/sdb1, and the boot process is successful. Something, some bugginess or misconfiguration, prevents the initial process from seeing the drive.

/boot is in fact on /dev/sdb. I did not change the disk set up after initially partitioning, formatting. I know usually /dev/sda is where people install /, but I wanted root on my SSD, which the system assigned as second device.

Oh, and your other question, no, there are no other USB devices.

/dennis

Offline

#17 2013-02-26 17:24:35

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

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

Note that /dev/sda and /dev/sdb can swap identities between boots. To be sure you're referring to the correct device, you should use UUIDs, not /dev/sdb1 or similar device nodes, to refer to partitions in GRUB and in /etc/fstab.

Offline

#18 2013-02-27 01:24:55

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

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

srs5694 wrote:

Note that /dev/sda and /dev/sdb can swap identities between boots. To be sure you're referring to the correct device, you should use UUIDs, not /dev/sdb1 or similar device nodes, to refer to partitions in GRUB and in /etc/fstab.

When first installing, I used the script suggested by the Beginner's Guide that writes grub's config file, rather than writing it manually. Checking just now, it does use the drive's UUIDs. /etc/fstab is configured with corresponding UUIDs as well.

But your question makes me wonder about refind's config file:


cat /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"

I wonder if there might be some HD flip-flopping going on there, ad how to use UUIDs in that file.

What makes me think flip-flopping is NOT going on there is the fact that when I access refind's menu,
he displays correct paths for the options vmlinuz-arch.efi and grub. That is, he clearly has pulled
configuration settings located on partition 1 of the sdb drive.

/dennis

Offline

#19 2013-02-27 02:04:48

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

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

srs5694 wrote:

In this case, rEFInd has done what it should, at least to a first approximation. (That is, the rEFInd program is OK, but its configuration might not be.) The problem is most likely one of the following:

  • Improper options passed to the kernel from rEFInd. The most likely issue here is with the "root=" option; if your Linux root (/) device is not /dev/sdb1, you must change what's passed to the kernel from rEFInd, most likely by fixing a broken refind_linux.conf file, or perhaps by editing a manual boot entry in refind.conf.

/dev/sdb1 is correct. Here is refind_linux.conf; I believe it is correct (although as mentioned in response to your other post, maybe it is subject to HD identity theft):

cat /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"

refind.conf has this option (I did not edit this file):

scan_all_linux_kernels

Maybe that's allowing rEFInd's menu entry to pick up a wrong kernel when I select the first menu option.

Nothing else is enabled in that file. I do see the example menu entries at the bottom of the file. When I get time, likely this weekend, I will play with those, and set 'scan_all_linux_kernels 0' and see what that does.

srs5694 wrote:
  • A failure to include an initial RAM disk on the kernel command line. This can happen if the initrd file is missing or if you've done a manual rEFInd configuration and forgotten to specify it.

I think I have this covered, except for what's mentioned above.

srs5694 wrote:
  • A broken initrd file. This can happen because of improper options when creating the initrd file. I'm not an expert on Arch's initrd-creation process, so I can't be sure what might be going wrong here or how to fix it. Broadly speaking, though, one possible problem is with missing drivers.

I will also do some research here. Since I did in fact need to rebuild the initramfs image earlier, this possibility intrigues me. I will need weekend time to do some deep digging.

srs5694 wrote:

Other messages printed on the screen may help you diagnose this problem. Unfortunately, many of them pass by so quickly that you can't read them. Some of the most critical are the ones that rEFInd displays when you select the Linux entry -- rEFInd should show you the options it's passing to the kernel. You can read these more readily by pressing F2 or Insert twice rather than pressing Enter; this launches a line editor that you can use to examine and edit the options. (Be aware that if you've got lots of options, they'll scroll off the right side of the screen, and you'll have to move your cursor over to read them all.) You may want to start by examining these options and, if you're not 100% sure that they're correct, fixing them or at least reporting them here.

more weekend research....

srs5694 wrote:

One more point: I seem to recall that GRUB 2 has a feature that enables it to detect boot failures and, if one occurs, launch a different kernel or launch a kernel in a different way. I'm foggy on the details, though, and I may actually be thinking of something else. If I'm right, though, this could explain the inconsistent behavior when booting with GRUB -- a failure might be followed by a boot using an older or recovery kernel.

Actually, the inconsistency is with refind, not grub. grub has been quite consistent, once I enter/leave the BIOS. refind's menu contains the menu entry pointing to vmlinuz-arch.efi, which gives me the hang. Also, when I invoke arch from grub's menu and query 'uname -a' he always reports the latest kernel: 3.7.9-1-ARCH

/dennis

Offline

#20 2013-02-27 12:26:02

swordfish
Member
Registered: 2012-01-14
Posts: 160

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

ddaupert wrote:
cat /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"

I wonder if there might be some HD flip-flopping going on there, ad how to use UUIDs in that file.

The entries should look like this:

"Boot to X"    "root=UUID=<your-UUID> ro rootfstype=ext4 and so on

In the wiki it is even recommended to use PARTUUID. Have a look: https://wiki.archlinux.org/index.php/UE … ing_rEFInd


Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)

Offline

#21 2013-02-27 12:43:50

swordfish
Member
Registered: 2012-01-14
Posts: 160

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

ddaupert wrote:

refind.conf has this option (I did not edit this file):

scan_all_linux_kernels

Maybe that's allowing rEFInd's menu entry to pick up a wrong kernel when I select the first menu option.

Nothing else is enabled in that file. I do see the example menu entries at the bottom of the file. When I get time, likely this weekend, I will play with those, and set 'scan_all_linux_kernels 0' and see what that does.

I don't think that this would help. The "scan_all_linux_kernels" option just gives you the opportunity to get rid of the /boot/efi/EFI/arch directory. Let me quote the wiki:

Note: As of refind-efi 0.6.5-1, refind can auto-detect kernels in /boot, if there are UEFI drivers for the filesystem used by /boot partition (or / partition if no separate /boot is used) in the ESP, and are loaded by rEFInd. To enable rEFInd to detect and load the drivers and /boot kernels you must enable the appropriate options in refind.conf (mainly mention the PATH for the drivers location in the ESP) and also copy your refind_linux.conf to /boot/refind_linux.conf .

This means: You can use the default Arch kernel that is always /boot/vmlinuz-linux. No need to copy every new kernel (and initramfs and initramfs-fallback) from boot to /boot/efi/EFI/arch (for example: "# cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi").

ddaupert wrote:

Actually, the inconsistency is with refind, not grub. grub has been quite consistent, once I enter/leave the BIOS. refind's menu contains the menu entry pointing to vmlinuz-arch.efi, which gives me the hang. Also, when I invoke arch from grub's menu and query 'uname -a' he always reports the latest kernel: 3.7.9-1-ARCH

Hm, is it possible, that you might have forgotten to copy the new kernel to the ESP (as I have explained above)?


Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)

Offline

#22 2013-02-27 15:54:54

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

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

swordfish wrote:
ddaupert wrote:

refind.conf has this option (I did not edit this file):

scan_all_linux_kernels

Maybe that's allowing rEFInd's menu entry to pick up a wrong kernel when I select the first menu option.

Nothing else is enabled in that file. I do see the example menu entries at the bottom of the file. When I get time, likely this weekend, I will play with those, and set 'scan_all_linux_kernels 0' and see what that does.

I don't think that this would help. The "scan_all_linux_kernels" option just gives you the opportunity to get rid of the /boot/efi/EFI/arch directory.

Not quite. Ordinarily, EFI boot loaders have filename extensions of ".efi", and rEFInd scans for filenames with that extension in certain directories and presents them as boot options. Most Linux distributions, though, don't give their kernels this extension by default, so they wouldn't show up in rEFInd's menu using the scanning code it inherited from rEFIt. The "scan_all_linux_kernels" option, if uncommented (as it is by default), tells rEFInd to scan not just for files with names that end in ".efi", but also for files with names that begin with "vmlinuz" or "bzImage" -- that is, Linux kernels without ".efi" extensions.

The ability to do away with copying the kernel to /boot/efi/EFI/arch has to do with what you mount at /boot and what drivers you install in rEFInd. If you mount the ESP at /boot or if you install an EFI driver for the filesystem you use for /boot, then rEFInd will be able to detect your kernels. Using normal names for the kernel, you'll also need to have "scan_all_linux_kernels" active, but you could achieve the same effect by naming your kernels with ".efi" extensions.

I agree with your recommendations on UUIDs, BTW, and I think that ddaupert should try using UUIDs in refind_linux.conf.

ddaupert wrote:

Actually, the inconsistency is with refind, not grub. grub has been quite consistent, once I enter/leave the BIOS.

This isn't the impression I was left with from your first post:

ddaupert wrote:

My new arch install no longer boots normally. On startup,
Megatrends bios gives the message (snipped for brevity):
'Boot crashed. Hit del to enter bios'

I enter bios, immediately exit bios, and now I get the
grub menu, and can boot successfully.

I read this as saying that the system behaves differently in two conditions:

  • Upon initial power-up, the boot fails with a prompt to "Hit del to enter bios". (It's unclear if this message comes from the firmware or from GRUB.)

  • After entering and exiting the firmware, the boot proceeds normally via GRUB.

This is an inconsistency involving GRUB. If GRUB is, as I vaguely recall, "remembering" failed boots and booting via a different path after a failure, that would explain this inconsistency. The trick would then be to discover what GRUB is doing differently after a failure vs. after a successful boot. If I'm right, this might be evident in different boot stanzas in grub.cfg.

I get the impression that you've never gotten rEFInd to boot successfully. That's 100% consistent behavior, albeit undesirable behavior.

Offline

#23 2013-02-28 03:37:56

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

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

swordfish wrote:

The entries should look like this:

"Boot to X"    "root=UUID=<your-UUID> ro rootfstype=ext4 and so on

In the wiki it is even recommended to use PARTUUID. Have a look: https://wiki.archlinux.org/index.php/UE … ing_rEFInd

Thanks for the references in your posts. This problem is really taking me to school. :-)

OK, I obtained the PARTUUID for my SSD (which has /):

ls -l /dev/disk/by-partuuid/
lrwxrwxrwx 1 root root 10 Feb 27 15:55 3a3cca39-c85f-451a-874e-909989d3580d -> ../../sdb1

I added the PARTUUID to refind_linux.conf.

On the next boot attempt, I tried using rEFInd's menu to launch arch, and got the hang error similar to what I had reported before, only this time it display's the PARTUUID of the device it's looking for.

:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
Waiting 10 seconds for device PARTUUID=3a3cca39-c85f-451a-874e-909989d3580d...
ERROR: device 'PARTUUID=3a3cca39-c85f-451a-874e-909989d3580d' not found. Skipping fsck.
ERROR: Unable to find root device 'PARTUUID=3a3cca39-c85f-451a-874e-909989d3580d'
You are being dropped to a recovery shell
  Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[rootfs /]# 

At least now I know this particular behavior isn't due to HD identity swap. Seems odd that the process that displays the error message claims he can't find the very device he pulled the PARTUUID from.

Since I am at least able to use grub to boot arch, and as you have clarified that I do not additionally need refind, I am planning to remove refind and see if its removal might resolve the necessity of entering BIOS in order to launch.

/dennis

Offline

#24 2013-02-28 14:32:54

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

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

srs5694 wrote:
ddaupert wrote:

Actually, the inconsistency is with refind, not grub. grub has been quite consistent, once I enter/leave the BIOS.

This isn't the impression I was left with from your first post:

To clarify, whenever I've gotten grub's menu, either after a boot failure OR by deliberately hitting del immediately after powering up to enter/leave the BIOS (thus no boot failure), I've consistently been able to boot.

When I access rEFInd's menu and select the option to boot arch, it fails. But as you point out, this failure is consistent, although not necessarily wonderful.

srs5694 wrote:

I read this as saying that the system behaves differently in two conditions:

  • Upon initial power-up, the boot fails with a prompt to "Hit del to enter bios". (It's unclear if this message comes from the firmware or from GRUB.)

I'm pretty sure that message is from the firmware; it displays directly below a good-size Megatrends icon.

srs5694 wrote:
  • After entering and exiting the firmware, the boot proceeds normally via GRUB.

This is an inconsistency involving GRUB. If GRUB is, as I vaguely recall, "remembering" failed boots and booting via a different path after a failure, that would explain this inconsistency.

If I prevent boot failure by hitting the del key right away, enter and leave BIOS, I get grub's menu.

In this case, there hasn't been an immediate boot failure for grub to remember. I actually haven't used grub2 until now, so there's a learning curve there as well. I would be surprised if grub would "remember" failures from previous boot sessions, but maybe that's the case.

srs5694 wrote:

The trick would then be to discover what GRUB is doing differently after a failure vs. after a successful boot. If I'm right, this might be evident in different boot stanzas in grub.cfg.

Yeah, I definitely will need to curl up with some grub documentation.

srs5694, swordfish, wombat23, s1ln7m4s7r, I appreciate the help tremendously. I've learned a lot so far.

I'm at a point where I think I need to simplify, take out rEFInd, try grub alone, maybe reinstall grub (or rEFInd, but separately) -- and also digest the material.

/dennis

Offline

#25 2013-02-28 16:15:55

s1ln7m4s7r
Member
Registered: 2013-02-22
Posts: 262

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

Hope you can fix your problems. I just wanted to say that you can allways use VirtualBox to some extent for testing purposes. And with its support for EFI, you can test EFI software and settings before using in real EFI systems.

Offline

Board footer

Powered by FluxBB