rEFInd cannot boot EOS after update

General system Newbie
1

EOS N00b here: Install went flawless without boot manager as I had rEFInd installed until I did a :

sudo pacman -Syu

and I get this:

2024-10-20 23_23_37-rEFInd cannot boot EOS after update - General system _ Newbie - EndeavourOS — To
2024-10-20 23_23_37-rEFInd cannot boot EOS after update - General system _ Newbie - EndeavourOS — To1863×807 203 KB

A start job is running for /dev/nvme0n1p11 (19s / no limit)

and I found this answer, which seems to be solving my problem:

but I have no clue how to do this if the system is in an unbootable state and as this is my 2nd install already, I’d rather not reinstall a 3rd time.

I have:

  • a windows partition
  • a bootable Ventoy USB with latest download of EOS:
    • Linux EndeavourOS 6.10.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 12 Sep 2024 17:21:02 +0000 x86_64 GNU/Linux
  • gParted ISO
  • CloneZilla ISO (Yes, I have a CloneZilla backup of EOS but I’d rather solve the issue than restore :cry:
  • an EFI shell
  • rEFInd (obviously)
  • access to the / partition of EOS that worked until just a few minutes ago (I changed the fstab already to use /dev/partname instead of UUID= but that doesn’t seem to make a difference except showing me that:
    • yes: edits to fstab work…

I do know:

  • my way around a command line

I do not know:

  • How to follow the instructions above
  • How dracut works
  • How to chroot in EOS + execute dracut
  • Install grub on my /efi/ partition if I cannot get rEFInd to work

How do I proceed?

2

I don’t know…I have no refind experience, but I’ll make some general recommendations that could point you in a direction.

  1. Why did you change the fstab mount points? I say this because UUID is unique BUT I have seen device names change due to kernel changes or which becomes ready first (not sure on which of those…but yes, I’ve had problems in the past with device names, which is probably why we use UUID now)
  2. Arch-chroot is probably gonna be your friend.
3
  1. Just to ensure that "Yes, I can see a difference when I change the fstab entry to a /dev/ instead of a UUID (Amended in my original question)
  2. so:
    a. Boot EOS ISO
    b. mkdir /mount/chroot
    c. mount my / to /mount/chroot
    d. arch-chroot
    Yes/no?
  3. and then what??
    :scream:
4

Are you getting to the rEFInd boot menu? The picture you posted looks like it is from after the bootloader phase.

You don’t need to create any directories, you can just use /mnt. Just mount your root partition, and then your EFI partition relative to the root partition. Here is some step-by-step guidance:

https://discovery.endeavouros.com/system-rescue/arch-chroot/

5

Yes I do have access to the rEFInd menu, yes the picture is from after choosing EOS.

Trying that out now and feeding back afterwards. Thanks for the help already.

:+1:

6

Is this your EnOS root partition?
If you don’t know (or anyway), please, post /etc/fstab contents of your EnOS installation.

7

Yes nvme0n1p11 is / and p12 is /home

P.S. Life is interfering and I will only be able to test things on the W.E.

8

I get another error, (Progress I suppose? :grin: ) so I’ll try to be more verbose this time:

To get there, I did:

  1. Boot EOS ISO from a Ventoy USB
  2. sudo mount -L EOS_Sys /mnt/ (as my original EOS / filesystem has a label and then I don’t have to remember all the partitions I have)
  3. sudo arch-chroot
  4. sudo mkdir /mnt/efi (As that didn’t exist)
  5. sudo mount -L SYSTEM /mnt/efi/
  6. sudo mount -L EOS_Home /home/
  7. Verified /efi/ contains the EFI directory and /home contains my 2 users
  8. yay --sync refind
  9. refind-install
  10. exit chroot
  11. reboot

How do I proceed?

P.S. Attaching the rdsosreport.txt is impossible as I have to hard reset the laptop (10 second power button)
P.P.S. What are the rules of the forum here? Do I need to edit my original question like on StackExchange or is what I’m doing right now expected??

9

You need to mount the EFI partition before setting the chroot.

You should not be creating a mount point for the EFI partition, you should be using the one that already exists for it. Check /etc/fstab if you are not sure what it is.

Once you mount the root partition, use the normal mount point for the EFI partition relative to that. For example, if the EFI partition is mounted at /efi in /etc/fstab, then from the live environment you can mount the root partition at /mnt, and then mount the EFI partition at /mnt/efi (using its normal mount point, which already exists in the root partition you mounted).

Log into the forum from the live environment and paste the output of this refind-install into the thread so we can see what is happening. Let’s also take a look at /boot/refind_linux.conf after it runs.

The way you are doing it is fine. :smiley:

1 Like
10

I think we found the Root Cause of my issue then, as I did not mount an EFI partition during install by taking ‘none’ in the boot loader choice as I though I didn’t need one as I have rEFInd and it worked as rEFInd detected EOS (until I updated that is…) :frowning:

Yeah: none in fstab:

#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>                             <mount point>  <type>  <options>                    <dump>  <pass>
#UUID=2de20bbf-1223-45a8-a005-b24fcdab766f   /              ext4    noatime                      0       1
/dev/nvme0n1p11                             /              ext4    defaults,noatime             0       1
#UUID=613de88b-5e74-4515-ae94-337dc4d3445d   /home          ext4    noatime                      0       2
/dev/nvme0n1p12                             /home          ext4    defaults,noatime             0       2
tmpfs                                       /tmp           tmpfs   defaults,noatime,mode=1777   0       0
UUID=403b5f8e-830f-49fd-852d-ef4524135be0   swap           swap    defaults,noatime,discard     0       0

Oiutput of sudo blkid | grep SYSTEM is:

/dev/nvme0n1p1: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="405F-2180" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="7d15ce4b-b842-4223-95ba-b645b4fdf5e9"

So again:

$sudo mount -L EOS_Sys /mnt/
$sudo mount -L SYSTEM mnt/efi/
sudo arch-chroot /mnt/

Verified /efi/ contains the EFI directory and /home contains my 2 users.

yay --sync refind
refind-install

Output of refind-install:

ShimSource is none
Installing rEFInd on Linux....
ESP was found at /efi using vfat
Found rEFInd installation in /efi/EFI/refind; upgrading it.
Installing driver for ext4 (ext4_x64.efi)
Copied rEFInd binary files

Notice: Backed up existing icons directory as icons-backup.
Existing refind.conf file found; copying sample file as refind.conf-sample
to avoid overwriting your customizations.

An existing rEFInd boot entry exists, but isn't set as the default boot
manager. The boot order is being adjusted to make rEFInd the default boot
manager. If this is NOT what you want, you should use efibootmgr to
manually adjust your EFI's boot order.
Creating new NVRAM entry
rEFInd is set as the default boot manager.
Existing //boot/refind_linux.conf found; not overwriting.

Installation has completed successfully.

output of /boot/refind_linux.conf:

"Boot with standard options"  "archisobasedir=arch archisolabel=EOS_202409 cow_spacesize=10G copytoram=n nvidia nvidia_drm.modeset=1 nouveau.modeset=0 i915.modeset=1 radeon.modeset=1 nvme_load=yes module_blacklist=pcspkr"
"Boot to single-user mode"    "archisobasedir=arch archisolabel=EOS_202409 cow_spacesize=10G copytoram=n nvidia nvidia_drm.modeset=1 nouveau.modeset=0 i915.modeset=1 radeon.modeset=1 nvme_load=yes module_blacklist=pcspkr single"
"Boot with minimal options"   "ro root=/dev/nvme0n1p11"

:bowing_man:

Posting this first and rebooting afterwards…

[edit] Same issue; adding /efi/ to fstab now:

/dev/nvme0n1p1                             /efi/          vfat    defaults                     0       0

and rebooting again…

and same issue again so back to Windows :sob: before I do too much damage… :person_shrugging:

11

It looks like the config has been populated with the kernel options of the ISO, not the chrooted system. This appears to be a known drawback of using the script from the live environment:

https://wiki.archlinux.org/title/REFInd#Installation_with_refind-install_script

Warning: When refind-install is run in chroot (e.g. in live system when installing Arch Linux) /boot/refind_linux.conf is populated with kernel options from the live system not the one on which it is installed. Edit /boot/refind_linux.conf and make sure the kernel parameters in it are correct for your system, otherwise you could get a kernel panic on your next boot. See #refind_linux.conf for an example file.

You have a couple options. Option one is to manually edit the file to use the correct kernel options. It is fairly straightforward, you just need to follow the guidance here: https://wiki.archlinux.org/title/REFInd#refind_linux.conf

You can get the PARTUUID with sudo blkid, then set it up something like this:

"Boot with standard options"   "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw [whatever kernel parameters you need]"
"Boot to single-user mode"     "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw [whatever kernel parameters you need] single"
"Boot with minimal options"    "ro root=/dev/nvme0n1p11"

The whole point of the refind-install script is to be easy and automatic, and obviously you have kind of lost that benefit if you have to manually edit the file to get it working…but I guess sometimes you eat the bear, and sometimes the bear eats you.

Your second option is to forget about the refind-install script and /boot/refind_linux.conf altogether, and write a manual boot stanza instead. Here is a step-by-step guide if you want to take a crack at it.

https://wiki.garudalinux.org/en/Writing_a_rEFInd_Boot_Stanza

It’s a more advanced setup process, but not too bad once you get the hang of it. It allows you to customize the boot menu a bit more than the automatic method does. Plus, unlike running the refind-install script you don’t actually need to install the rEFInd package if you have installed it on the EFI partition with another distro. All you need to do is edit /efi/EFI/refind/refind.conf and write your boot stanza.

One final thing:

I know you are just trying to get this thing working, but you should not get in the habit of using kernel name descriptors for block devices in /etc/fstab because they can change at each boot (which would make the system unbootable).

https://wiki.archlinux.org/title/Fstab#Kernel_name_descriptors

Warning: Kernel name descriptors for block devices are not persistent and can change each boot, they should not be used in configuration files (including /etc/fstab).

If you only have one disk, probably you’ll be fine…but a better habit to get into will be to use the file system UUID. https://wiki.archlinux.org/title/Fstab#File_system_UUIDs

12

Sorry for the late reply: life interfered… :frowning:

So I went with

write a manual boot stanza instead

and added this at the end:

menuentry "MyEOS" {
    icon /EFI/refind/icons/os_endeavouros.png
    volume "6453af08-c592-40cb-a4d5-7067124d9cd9"
    loader /boot/vmlinuz-linux-lts
    initrd /boot/initramfs-linux-lts.img
    graphics on
    options "root=UUID=2de20bbf-1223-45a8-a005-b24fcdab766f rw rootflags=text archisobasedir=arch archisolabel=EOS_202409 cow_spacesize=10G copytoram=n nvidia nvidia_drm.modeset=1 nouveau.modeset=0 i915.modeset=1 radeon.modeset=0 nvme_load=yes module_blacklist=pcspkr"
}

(using the existing file as an example) an changing by quiet splash to text and as
i don’t have a radeon card, radeon.modeset=0 but still no cigar:

IMG_20241229_230436
IMG_20241229_2304361920×1440 260 KB

I’m really out of my depth here: I’m OK with Linux once it’s booted, but the boot process itself is a mystery black magic to me… (Ex-Ubuntu; hopefully soon ex-Manjaro user here)

:scream: :exploding_head:

13

I notice you have failed to start switch root in the log which some users have experienced also and they have it resolved with a newer systemd package. Your issue may not be the same.

1 Like
14

You still need to get rid of all of these kernel options from the live ISO. I would try to get rid of all of them except for ones you know that you need.

For sure you need to get rid of these ones: