[Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

Nevu · 2020-11-15 11:01:21

Hey, very new Arch user here having an insanely difficult time with installing. Everything went alright until I had to set up my boot loader. I chose rEFInd, and it's simply not booting Arch properly for me. I looked at various wiki pages and forum threads about this but none of them helped.

When I turn on my PC, rEFInd works no problem, but when I select my Arch installation, I get this

 [     0.027457] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x52 (or later)
: : running early hook [udev]
Starting version 246.6-1-arch
: : running hook [udev]
: : Triggering uevents...
ERROR: device ' ' not found. Skipping fsck.
: : mounting ' ' on real root
mount: /new_root: no filesystem specified.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ]#

Obviously, I'm told I need to update the microcode, so after installing intel-ucode, I change my refind_linux.conf like this

"Boot with standard options"  "archisobasedir=arch archisolabel=ARCH_202011 initrd=\intel-ucode.img"
"Boot to single-user mode"    "archisobasedir=arch archisolabel=ARCH_202011 single initrd=\intel-ucode.img"
"Boot with minimal options"   "ro root=UUID=bf2ddd06-db9c-4ee2-869e-b287543134bf initrd=\intel-ucode.img"

After doing those changes, I boot my Arch again through rEFInd and get this

Starting vmlinuz-linux
Using load options 'archisobasedir=arch archisolabel=ARCH_202011 initrd=\intel-ucode.img
EFI stub: ERROR: Failed to open file: intel-ucode.img
EFI stub: ERROR: Failed to load initrd!
EFI stub: ERROR: efi_main failed!
Error: Not Found returned from vmlinuz-linux

* Hit any key to continue *

After changing

initrd=\intel-ucode.img

to

initrd=boot\intel-ucode.img

(afaik my /boot is a seperate partition..? sdb1 is EFI partition and sdb2 is root) and booting Arch again, this happens

Starting vmlinuz-linux
Using load options 'archisobasedir=arch archisolabel=ARCH_202011 initrd=boot\intel-ucode.img

In this case, Arch just completely freezes on these 2 lines and doesn't respond to any input, meaning I have to reboot my PC.

I did try and actually configure rEFInd according to the wiki, so here's my refind.conf extra

extra_kernel_version_strings linux-hardened,linux-zen,linux-lts,linux

I also noticed something very weird about the rEFInd directories. They keep randomly disappearing in live USB and I always need to type out refind-install in chroot to get them to reappear again. The directory in question is

/boot/efi/EFI/refind

, also where the refind.conf is in. Very weird behavior.

At this point I'm pretty much at a loss, literally nothing is working with this problem. Should I just ditch rEFInd and go with GRUB instead?

Last edited by Nevu (2020-11-15 17:58:34)

Morn · 2020-11-15 12:24:22

Shouldn't your refind_linux.conf simply say

"Boot with default options"   "root=/dev/sdb2 rw"

I don't think missing microcode is the problem here.

Nevu · 2020-11-15 13:06:09

Morn wrote:

Shouldn't your refind_linux.conf simply say
"Boot with default options"   "root=/dev/sdb2 rw"
I don't think missing microcode is the problem here.

Changed my refind_linux.conf default options to just that with nothing else and retried. Rebooted, and this time Arch went through the systemd check process like normal (scrolling text with [ OK ]). After that, I get this

Arch Linux 5.9.8-arch1-1 (tty1)

myhostname login:  [     3.477283] nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
[     3.477314] ucsi_ccg 0-0008: i2c_transfer failed -110
[     3.477341] ucsi_ccg 0-0008: ucsi_ccg_init failed - -110

It does say something about Nvidia GPU, so perhaps drivers are the issue here..? If it helps, I have a GTX 1660ti GPU

Last edited by Nevu (2020-11-15 13:08:38)

d_fajardo · 2020-11-15 13:17:48

"archisobasedir=arch archisolabel=ARCH_202011

Your refind_linux.conf is still pointing to the Arch ISO that you used for installation. You should update that file.
First thing to do is find the disk UUID of your root partition. You can run:

ls -l /dev/disk/by-uuid

And update your refind file to point to that:

"Boot with standard options"  "root=PARTUUID={ the output of uuid } rw ... initrd=\intel-ucode.img"

Another note is the new version of rEFInd there's a note regarding path separators. As an example, this is the first line of my refind_linux.conf:

"Boot with standard options"  "root=PARTUUID=272ce274-3770-0147-8292-c330bc4f8538 rw add_efi_memmap quiet splash loglevel=3 rd.udev.log_priority=3 vt.global_cursor_default=0 nvidia-drm.modeset=1 apparmor=1 lsm=lockdown,yama,apparmor initrd=intel-ucode.img initrd=initramfs-linux.img"

@Morn It is important to use the persistent naming of the device. Using root=/dev/sdb2 could change in subsequent boot or in addition of another device.

Last edited by d_fajardo (2020-11-15 13:22:30)

Morn · 2020-11-15 13:25:35

Nevu wrote:

It does say something about Nvidia GPU, so perhaps drivers are the issue here..? If it helps, I have a GTX 1660ti GPU

Then mark this thread as solved and open a new one about the Nvidia issue if it is a problem (but maybe you can safely just ignore those I2C errors?). I have an AMD card, so I can't help you there. :-)

Nevu · 2020-11-15 13:53:47

d_fajardo wrote:

"archisobasedir=arch archisolabel=ARCH_202011 
Your refind_linux.conf is still pointing to the Arch ISO that you used for installation. You should update that file.
First thing to do is find the disk UUID of your root partition. You can run:
ls -l /dev/disk/by-uuid
And update your refind file to point to that:
"Boot with standard options"  "root=PARTUUID={ the output of uuid } rw ... initrd=\intel-ucode.img" 
Another note is the new version of rEFInd there's a note regarding path separators. As an example, this is the first line of my refind_linux.conf:
"Boot with standard options"  "root=PARTUUID=272ce274-3770-0147-8292-c330bc4f8538 rw add_efi_memmap quiet splash loglevel=3 rd.udev.log_priority=3 vt.global_cursor_default=0 nvidia-drm.modeset=1 apparmor=1 lsm=lockdown,yama,apparmor initrd=intel-ucode.img initrd=initramfs-linux.img"
@Morn It is important to use the persistent naming of the device. Using root=/dev/sdb2 could change in subsequent boot or in addition of another device.

Tried this yet the same exact issue persists. My refind_linux.conf is currently like this

"Boot with standard options" "root=PARTUUID=bf2ddd06-db9c-4ee2-869e-b287543134bf rw initrd=boot\intel-ucode.img"
"Boot to single-user mode" "root=PARTUUID=bf2ddd06-db9c-4ee2-869e-b287543134bf single initrd=boot\intel-ucode.img"
"Boot with minimal options" "ro root=PARTUUID=bf2ddd06-db9c-4ee2-869e-b287543134bf initrd=boot\intel-ucode.img"

As for the separators, if I just type

initrd=intel-ucode.img

it simply says that same "failed to open file" error shown in my first post after booting Arch. Same with using

initrd=\intel-ucode.img

and

initrd=boot\intel-ucode.img

still has the same issue of freezing my entire Arch on Starting vmlinuz-linux. Not having the intel-ucode.img at all in refind_linux.conf brings back the microcode problem again after boot.

loqs · 2020-11-15 14:24:46

What version of intel-ucode is installed on the system?

Nevu · 2020-11-15 14:35:55

loqs wrote:

What version of intel-ucode is installed on the system?

No idea if I have this right, but it seems to be intel-ucode-20201112-1.

loqs · 2020-11-15 14:42:29

If you downgrade to intel-ucode-20200616-1-any.pkg.tar.zst which should be the version used on the 2020.11.01 ISO that worked for you, then see if you can reproduce the freeze.

Nevu · 2020-11-15 15:14:30

loqs wrote:

If you downgrade to intel-ucode-20200616-1-any.pkg.tar.zst which should be the version used on the 2020.11.01 ISO that worked for you, then see if you can reproduce the freeze.

Was able to reproduce.

Starting vmlinuz-linux
Using load options 'root=PARTUUID=bf2ddd06-db9c-4ee2-869e-b287543134bf rw initrd=boot\intel-ucode.img'

Just shows this and nothing else. Can't type anything at all, completely frozen

mcloaked · 2020-11-15 15:47:31

One thing worth checking is that the filesystem id for the root partition is correctly assigned in the partitions - so if you boot the install iso, and post the output of the command, executed as root, for blkid, it should give the list of both UUID and PARTUUID and then make sure that the correct filesystem is defined in the refind_linux.conf file so that the lines with root=PARTUUID... are using the PARTUUID and not UUID. You could also check that the root partition is the one listed with the df -h command. Also make sure that the refind driver for the filesystem for the root partition is in the right place in the /boot/efi/EFI/refind/ directory or the files can't be read by refind in the root partition. Once that is checked if no errors are found you can do other checks to move forward.

Nevu · 2020-11-15 16:14:41

mcloaked wrote:

One thing worth checking is that the filesystem id for the root partition is correctly assigned in the partitions - so if you boot the install iso, and post the output of the command, executed as root, for blkid, it should give the list of both UUID and PARTUUID and then make sure that the correct filesystem is defined in the refind_linux.conf file so that the lines with root=PARTUUID... are using the PARTUUID and not UUID. You could also check that the root partition is the one listed with the df -h command. Also make sure that the refind driver for the filesystem for the root partition is in the right place in the /boot/efi/EFI/refind/ directory or the files can't be read by refind in the root partition. Once that is checked if no errors are found you can do other checks to move forward.

Everything checks out except that /boot/efi/EFI/refind thing. Like I stated in my previous post, /boot/efi/EFI/refind says "no such file or directory", so I have to do refind-install all over again to actually access the directory. Perhaps it's part of the problem? Nevermind, I wasn't paying attention and the in fact the UUID is being used instead of the PARTUUID. Will correct it and edit this post to inform how it goes.

EDIT: Nope, nothing. Still same old same. initrd=intel-ucode.img and initrd=/intel-ucode.img gives failed to open and initrd=boot/intel-ucode.img freezes.

EDIT 2: In my first line in refind_linux.conf, I deleted everything except the root PARTUUID option. This time it seemed to boot properly to login, but it still showed me that Firmware Bug Errata error for a second, but shortly went to login after. No idea if that's something I should be concerned about.

Last edited by Nevu (2020-11-15 16:38:08)

mcloaked · 2020-11-15 17:34:13

Nevu wrote:

mcloaked wrote:
One thing worth checking is that the filesystem id for the root partition is correctly assigned in the partitions - so if you boot the install iso, and post the output of the command, executed as root, for blkid, it should give the list of both UUID and PARTUUID and then make sure that the correct filesystem is defined in the refind_linux.conf file so that the lines with root=PARTUUID... are using the PARTUUID and not UUID. You could also check that the root partition is the one listed with the df -h command. Also make sure that the refind driver for the filesystem for the root partition is in the right place in the /boot/efi/EFI/refind/ directory or the files can't be read by refind in the root partition. Once that is checked if no errors are found you can do other checks to move forward.
Everything checks out except that /boot/efi/EFI/refind thing. Like I stated in my previous post, /boot/efi/EFI/refind says "no such file or directory", so I have to do refind-install all over again to actually access the directory. Perhaps it's part of the problem? Nevermind, I wasn't paying attention and the in fact the UUID is being used instead of the PARTUUID. Will correct it and edit this post to inform how it goes.
EDIT: Nope, nothing. Still same old same. initrd=intel-ucode.img and initrd=/intel-ucode.img gives failed to open and initrd=boot/intel-ucode.img freezes.
EDIT 2: In my first line in refind_linux.conf, I deleted everything except the root PARTUUID option. This time it seemed to boot properly to login, but it still showed me that Firmware Bug Errata error for a second, but shortly went to login after. No idea if that's something I should be concerned about.

OK - now that you have the correct refind_linux.conf and you are booting the system - you can check that the microcode img file is in place as well as having the definition of how the boot should deal with it by checking the following. First make sure that the microcode file is in the right place by seeing if is it equivalent to mine:

$ ls /boot/
efi   initramfs-linux-fallback.img  intel-ucode.img  initramfs-linux.img refind_linux.conf  vmlinuz-linux

$ ls /boot/efi/EFI/refind/
drivers_x64  icons   refind.conf fonts  images  refind_x64.efi    tools_x64

and make sure that in refind_linux.conf the ordering of the file definitions is the same as in mine as per:

$ cat /boot/refind_linux.conf
## This file should be present in the same directory as the EFISTUB kernel and initramfs files
## More info at http://www.rodsbooks.com/refind/linux.html , http://www.rodsbooks.com/efi-bootloaders/efistub.html
"Boot with defaults" "root=PARTUUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx rw rootfstype=ext4 initrd=boot\intel-ucode.img initrd=boot\initramfs-linux.img systemd.unit=graphical.target radeon.runpm=0 quiet"
"Boot to console" "root=PARTUUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx rw rootfstype=ext4 initrd=boot\intel-ucode.img initrd=boot\initramfs-linux.img systemd.unit=multi-user.target radeon.runpm=0"
"Boot Fallback to console" "root=PARTUUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx rw rootfstype=ext4 initrd=boot\intel-ucode.img initrd=boot\initramfs-linux-fallback.img systemd.unit=multi-user.target radeon.runpm=0"

As far as I understand it the ucode img file HAS to be before the initramfs file otherwise it won't load. (you may not have the radeon.runpm in yours, depending on your graphics card.

Also do you load the early KMS by having the appropriate 'hook' in mkinitcpio.conf (if Intel then it is i915) - mostly early KMS is important for graphics to work well.

Also you can check if once the ucode img file is in the right place then you can check if the system is loading the new and later microcode by checking the journal once you are booted by running as root or using sudo as per:

$ sudo journalctl -b | grep microcode
Nov 12 21:50:21 archlinux kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-27
Nov 12 21:50:21 archlinux kernel: microcode: sig=0x806e9, pf=0x40, revision=0xde

Once you have the main issue resolved don't forget to mark this thread as [SOLVED]

Nevu · 2020-11-15 17:57:07

mcloaked wrote:

Nevu wrote:
mcloaked wrote:
One thing worth checking is that the filesystem id for the root partition is correctly assigned in the partitions - so if you boot the install iso, and post the output of the command, executed as root, for blkid, it should give the list of both UUID and PARTUUID and then make sure that the correct filesystem is defined in the refind_linux.conf file so that the lines with root=PARTUUID... are using the PARTUUID and not UUID. You could also check that the root partition is the one listed with the df -h command. Also make sure that the refind driver for the filesystem for the root partition is in the right place in the /boot/efi/EFI/refind/ directory or the files can't be read by refind in the root partition. Once that is checked if no errors are found you can do other checks to move forward.
Everything checks out except that /boot/efi/EFI/refind thing. Like I stated in my previous post, /boot/efi/EFI/refind says "no such file or directory", so I have to do refind-install all over again to actually access the directory. Perhaps it's part of the problem? Nevermind, I wasn't paying attention and the in fact the UUID is being used instead of the PARTUUID. Will correct it and edit this post to inform how it goes.
EDIT: Nope, nothing. Still same old same. initrd=intel-ucode.img and initrd=/intel-ucode.img gives failed to open and initrd=boot/intel-ucode.img freezes.
EDIT 2: In my first line in refind_linux.conf, I deleted everything except the root PARTUUID option. This time it seemed to boot properly to login, but it still showed me that Firmware Bug Errata error for a second, but shortly went to login after. No idea if that's something I should be concerned about.
OK - now that you have the correct refind_linux.conf and you are booting the system - you can check that the microcode img file is in place as well as having the definition of how the boot should deal with it by checking the following. First make sure that the microcode file is in the right place by seeing if is it equivalent to mine:
$ ls /boot/
efi   initramfs-linux-fallback.img  intel-ucode.img  initramfs-linux.img refind_linux.conf  vmlinuz-linux

$ ls /boot/efi/EFI/refind/
drivers_x64  icons   refind.conf fonts  images  refind_x64.efi    tools_x64
and make sure that in refind_linux.conf the ordering of the file definitions is the same as in mine as per:
$ cat /boot/refind_linux.conf
## This file should be present in the same directory as the EFISTUB kernel and initramfs files
## More info at http://www.rodsbooks.com/refind/linux.html , http://www.rodsbooks.com/efi-bootloaders/efistub.html
"Boot with defaults" "root=PARTUUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx rw rootfstype=ext4 initrd=boot\intel-ucode.img initrd=boot\initramfs-linux.img systemd.unit=graphical.target radeon.runpm=0 quiet"
"Boot to console" "root=PARTUUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx rw rootfstype=ext4 initrd=boot\intel-ucode.img initrd=boot\initramfs-linux.img systemd.unit=multi-user.target radeon.runpm=0"
"Boot Fallback to console" "root=PARTUUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx rw rootfstype=ext4 initrd=boot\intel-ucode.img initrd=boot\initramfs-linux-fallback.img systemd.unit=multi-user.target radeon.runpm=0"
As far as I understand it the ucode img file HAS to be before the initramfs file otherwise it won't load. (you may not have the radeon.runpm in yours, depending on your graphics card.
Also do you load the early KMS by having the appropriate 'hook' in mkinitcpio.conf (if Intel then it is i915) - mostly early KMS is important for graphics to work well.
Also you can check if once the ucode img file is in the right place then you can check if the system is loading the new and later microcode by checking the journal once you are booted by running as root or using sudo as per:
$ sudo journalctl -b | grep microcode
Nov 12 21:50:21 archlinux kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-27
Nov 12 21:50:21 archlinux kernel: microcode: sig=0x806e9, pf=0x40, revision=0xde
Once you have the main issue resolved don't forget to mark this thread as [SOLVED]

Yup, thanks. I'll see what I can do, everything seems fine from here

Arch Linux

#1 2020-11-15 11:01:21

[Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#2 2020-11-15 12:24:22

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#3 2020-11-15 13:06:09

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#4 2020-11-15 13:17:48

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#5 2020-11-15 13:25:35

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#6 2020-11-15 13:53:47

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#7 2020-11-15 14:24:46

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#8 2020-11-15 14:35:55

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#9 2020-11-15 14:42:29

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#10 2020-11-15 15:14:30

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#11 2020-11-15 15:47:31

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#12 2020-11-15 16:14:41

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#13 2020-11-15 17:34:13

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

#14 2020-11-15 17:57:07

Re: [Solved] rEFInd doesn't boot my Arch Linux, having issues with Intel..

Board footer