You are not logged in.

#1 2014-07-02 11:21:37

aliquis
Member
From: Stockholm, Sweden
Registered: 2014-07-02
Posts: 3

[SOLVED] UEFI boot problems after kernel upgrade, post-mortem

Most of my issues are already solved, but I have one specific question at the end of this post. First, I'll provide the background, partly because I couldn't find any information at all online that helped me track down this problem, and I want to provide that for others.

I've recently installed Arch Linux with LVM on LUKS on a UEFI laptop. I got inspiration from an installation guide. Some of the main differences between the guide and what I did are that I have an encrypted partition for suspend-to-disk and that /boot/vmlinuz-linux, /boot/initramfs-linux.img and /boot/initramfs-linux-fallback.img are symlinked into the directory /boot/efi/EFI/arch (i.e. not only copied as in the guide).

After upgrading to the kernel 3.15.2-1-ARCH (my first kernel upgrade), this is the message I got when trying to boot:

:: running early hook [udev]
Warning: /lib/modules/3.15.1-1-ARCH/modules.devname not found - ignoring
:: running early hook [lvm2]
:: running hook [udev]
:: Triggering uevents...
:: running hook [encrypt]
Waiting 10 seconds for device /dev/sda2 ...
:: running hook [resume]
Waiting 10 seconds for device /dev/mapper/system-lvswap ...
ERROR: resume: hibernation device '/dev/mapper/system-lvswap' not found
Waiting 10 seconds for device /dev/mapper/system-lvroot ...
ERROR: device '/dev/mapper/system-lvroot' not found. Skipping fsck.
ERROR: Unable to find root device '/dev/mapper/system-lvroot'.
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 /]#

The key hint here is the warning which refers to the old kernel. I turns out that the culprit is pacman, which destroys the symlink /boot/vmlinuz-linux and overwrites it with a new file. mkinitcpio doesn't notice that anything's wrong, since it by default only knows about the default location.

What I've done as a temporary solution, is to update /etc/mkinitcpio.d/linux.preset with the new paths. That way, mkinitcpio will at least complain loudly that the versions are wrong, so that I can move vmlinuz-linux manually and try again.

Am I doing anything wrong, or is this how it's supposed to be designed? If what I've read is correct, then the ESP should be mounted at /boot/efi, but how do I get pacman to accept that? Right now, I'm considering ignoring kernel updates, and deal with them manually only after a good night's sleep and with a recovery flash drive nearby, since a tiny mistake would render my system unbootable.

Last edited by aliquis (2014-07-02 19:37:42)

Offline

#2 2014-07-02 18:05:38

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: [SOLVED] UEFI boot problems after kernel upgrade, post-mortem

At the time I wrote that, gummiboot required the ESP to be mounted there. Some time later, gummiboot was updated and I was able to mount the EFI at /boot, so I made that change to avoid having the risk of this happening. That's one of the downfalls of following old documentation with Arch.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#3 2014-07-02 18:50:42

aliquis
Member
From: Stockholm, Sweden
Registered: 2014-07-02
Posts: 3

Re: [SOLVED] UEFI boot problems after kernel upgrade, post-mortem

jasonwryan, thank you for your response and the comprehensive guide. For the record, I did my best to find information on the topic before starting, and your guide was the best source of information I could find. More importantly, however, I didn't find a single source that contradicted what you wrote. In fact, ArchWiki's article on UEFI is "assuming mountpoint /boot/efi", and even the GRUB article says that the mountpoint for ESP is "usually /boot/efi". And your gist was created in 2013, which is not that long ago in my opinion. So please forgive my ignorance. smile

Your answer focuses on recent changes in the software, but doesn't recommend a specific course of action for someone who's new to this. Is this a correct interpretation of your answer? "What you're trying to do is difficult and pointless. It's safer to move the mountpoint instead."

Offline

#4 2014-07-02 18:57:34

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: [SOLVED] UEFI boot problems after kernel upgrade, post-mortem

Mounting the ESP at boot simplifies the process considerably; you don't need to rely on a service file/symlinks etc. It effectively removes a point of failure.

That has to be a good thing, right? smile


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#5 2014-07-02 20:07:53

aliquis
Member
From: Stockholm, Sweden
Registered: 2014-07-02
Posts: 3

Re: [SOLVED] UEFI boot problems after kernel upgrade, post-mortem

You're right. I was just not sure that I'd find all the config files, thus not being able to boot again.

For future reference, what I did was:

  1. Moved vmlinuz-linux and initramfs-linux* into /boot/efi.

  2. Removed symlinks from /boot and moved other files into /boot/efi (or deleted them, if they were duplicates).

  3. Changed the paths to "\vmlinuz-linux" and "\initramfs-linux.img" in /boot/efi/loader/entries/arch.conf.

  4. Changed the mountpoint to "/boot" in /etc/fstab.

  5. Reverted /etc/mkinitcpio.d/linux.preset to the default.

  6. Unmounted /boot/efi and removed efi.

  7. Rebooted.

I've tried to downgrade and upgrade the kernel. It's all working.

Offline

#6 2014-07-02 20:39:51

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: [SOLVED] UEFI boot problems after kernel upgrade, post-mortem

Nice. Welcome to Arch!


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

Board footer

Powered by FluxBB