Kernel panic: EFI variables missing

catnap · 2016-10-03 21:27:57

My Arch Linux system fails to boot, apparently because the root partition is not recognized. The process stops with the following error message:

ERROR: Unable to find rot device 'PARTUUID=8096db3c-7e6c-4ad8-a662-258817ef0646'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off

However, when I booted from the installation medium of Arch Linux, I found that
the required partition was available in the virtual console. The command blkid gives the following output:

/dev/sdb1: UUID="01d5b1bb-d522-4019-8072-d652bb5a64e0" TYPE="swap" PARTLABEL="Linux swap" PARTUUID="c45120c4-4568-4b85-9a7a-6d4f7953f173"
/dev/sdb2: UUID="fcfdeada-d0e8-493b-88df-64e225c78d25" SEC_TYPE="ext2" TYPE="ext3" PARTLABEL="Linux /home" PARTUUID="6eab7a61-daba-4deb-9596-3a6118a99633"
/dev/sda1: UUID="6A32-E379" TYPE="vfat" PARTLABEL="EFI System" PARTUUID="83c10749-badb-467c-b718-4759be9a7a2d"
/dev/sda2: UUID="34a04bf0-cd10-4115-84cb-6995aa1419c7" SEC_TYPE="ext2" TYPE="ext3" PARTLABEL="Linux filesystem" PARTUUID="8096db3c-7e6c-4ad8-a662-258817ef0646"
/dev/sr0: UUID="..." LABEL="ARCH_201605" TYPE="iso9660" PTUUID="..." PTTYPE="dos"
/dev/loop0: TYPE="squashfs"

After mounting, all the data in the partition seemed to be intact. However the folder /sys/firmware does not have
a subfolder for EFI which makes me worry that Arch Linux is not using the right method to access the partition.
I followed the guidelines of https://wiki.archlinux.org/index.php/Un … _Interface in
the section Requirements for UEFI variable support, but without success. The virtual console of the installation
medium does not give any results for

efivar -l

How to ensure that EFI is in use? Can I boot the system from the installation medium to ensure that
the problem is in the bootloader rather than in the kernel?

Last edited by catnap (2016-10-03 21:32:35)

Head_on_a_Stick · 2016-10-04 07:00:17

catnap wrote:

the folder /sys/firmware does not have a subfolder for EFI

You are not booted in UEFI mode, check your firmware ("BIOS") settings.

In respect of your problem, please detail your bootloader installation process and include all configuration files.

The output of `parted -l` is always useful

catnap · 2016-10-04 10:41:04

Here is the output from parted -l:

Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size   File system  Name              Flags
 1      1049kB  538MB  537MB  fat32        EFI System        boot, esp
 2      538MB   250GB  250GB  ext3         Linux filesystem


Model: ATA ST3000DM001-1ER1 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name         Flags
 1      1049kB  1075MB  1074MB  linux-swap(v1)  Linux swap
 2      1075MB  3001GB  3000GB  ext3            Linux /home


Model: ASUS DRW-24F1MT (scsi)                                             
Disk /dev/sr0: 770MB
Sector size (logical/physical): 2048B/2048B
Partition Table: msdos
Disk Flags: 

Number  Start  End    Size   Type     File system  Flags
 2      352kB  168MB  168MB  primary               esp

This is what I have inside /mnt/boot/loader/loader.conf

#timeout 3
#default 1a42d1a87b1349978d6f7f2aafba77d5-*

default arch
timeout 10
editor 0

#8096db3c-7e6c-4ad8-a662-258817ef0646

Here is the content of /mnt/boot/loader/entries/arch.conf

title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=PARTUUID=8096db3c-7e6c-4ad8-a662-258817ef0646 rw

It is the only entry because Arch Linux is now the only operating system that I ever use.
I hope these descriptions will give a clue about the nature of the problem.

Head_on_a_Stick · 2016-10-05 07:00:26

Did you check your firmware ("BIOS") settings?

Make sure that UEFI is enabled and that "CSM" or "Legacy" mode is disabled.

You will not be able to make new UEFI boot entries until this is done.

Have you tried changing "root=PARTUUID=8096db3c-7e6c-4ad8-a662-258817ef0646" to "root=/dev/sda2" in arch.conf?

R00KIE · 2016-10-05 14:17:06

I suppose booting with 'root=PARTUUID=' should work regardless of the bios configuration as that is something that doesn't depend on bios/fw operating mode.

catnap · 2016-10-06 13:46:01

I attempted to solve the issue with the proposed methods but with no success.
My computer uses the Asus UEFI BIOS Utility where I made the following changes.
First, I changed Launch CSM option in the Boot menu from Enabled to Disabled.
This caused the system to halt already in the boot loader menu before I even
selected Arch Linux to be loaded. Second, I changed CSM back to Enabled but
selected explicit UEFI mode for Boot Device Control, Boot Network Device, etc.
in the sub-menus. The boot loader no longer halted, but I encountered the old
error message "Unable to find root device ...".

It seems curious that the system has worked so far, given that I have not touched the
UEFI BIOS setup before or after I first installed Arch Linux, complete with hard drive
partitions and boot loaders, all of which assumed UEFI from the beginning. If the
problem is in BIOS, I should have encountered it at the first installation of Arch
Linux, but I have been using the operating system for some years now.

I also attempted the solution that replaces

root=PARTUUID=8096db3c-7e6c-4ad8-a662-258817ef0646

with

root=/dev/sda2

in arch.conf. It did not solve the problem but only
changed the error message to

Unable to find root device /dev/sda2

What does this error message mean precisely? Is it an indication of a missing
hard disk or simply an indication that the disk does not for some reason
register as a root partition? Perhaps the device is found but it's content is
in some way corrupted. Any clues about this would be welcome.

PS.

Adjusting the UEFI BIOS settings seemed to make some progress after all
because

 efivars -l

returns a long list of variables and the
EFI folder in the firmware files seems to be populated when I try

 ls /sys/firmware/efi/efivars/

Last edited by catnap (2016-10-06 16:31:29)

R00KIE · 2016-10-06 15:56:40

Have you tried with the fallback initramfs?

catnap · 2016-10-06 16:35:47

ROOKIE wrote:

Have you tried with the fallback initramfs?

I have not tried this yet. Although I have been using Arch Linux,
this is the first time that I tackle a kernel panic, so that the method
is not familiar to me. Could you point me to some documentation
about the fall-back?

catnap · 2016-10-06 17:05:17

Here is the content of my /mnt/etc/fstab file that
I accessed through the virtual console:

# 
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/sda2
UUID=34a04bf0-cd10-4115-84cb-6995aa1419c7       /               ext3            rw,relatime,data=ordered        0 1

# /dev/sdb2
UUID=fcfdeada-d0e8-493b-88df-64e225c78d25       /home           ext3            rw,relatime,data=ordered,commit=60      0 2

# /dev/sda1
UUID=6A32-E379          /boot           vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro    0 2

# /dev/sdb1
UUID=01d5b1bb-d522-4019-8072-d652bb5a64e0       none            swap            defaults        0 0

In case it helps, here is also the output of

 lsblk -l

NAME   FSTYPE   LABEL       UUID                                 MOUNTPOINT
sda                                                              
├─sda1 vfat                 6A32-E379                            /mnt/boot
└─sda2 ext3                 34a04bf0-cd10-4115-84cb-6995aa1419c7 /mnt
sdb                                                              
├─sdb1 swap                 01d5b1bb-d522-4019-8072-d652bb5a64e0 
└─sdb2 ext3                 fcfdeada-d0e8-493b-88df-64e225c78d25 /mnt/home
sr0    iso9660  ARCH_201605 2016-05-01-04-48-28-00               /run/archiso/bootmnt
loop0  squashfs                                                  /run/archiso/sfs/airootfs

Head_on_a_Stick · 2016-10-06 17:12:47

catnap wrote:

Could you point me to some documentation
about the fall-back?

https://wiki.archlinux.org/index.php/mk … activation

catnap · 2016-10-06 18:03:56

Unfortunately changing

initrd /initramfs-linux.img

into

initrd /initramfs-linux-fallback.img

in /mnt/boot/loader/entries/arch.conf had not effect.

My situation starts to seem quite desperate. Any enlightened
opinions about if it would be easier to backup everything and
install the system files and the boot loader again from scratch?
I suppose it is the fastest method. But it might leave me to worry
if a next system crash will occur at any moment.

R00KIE · 2016-10-06 20:42:19

What's the output of 'lsblk -o name,fstype,label,partlabel,parttype,uuid,partuuid,mountpoint'?

catnap · 2016-10-07 13:03:15

ROOKIE wrote:

What's the output of 'lsblk -o name,fstype,label,partlabel,parttype,uuid,partuuid,mountpoint'?

Here is the output:

NAME   FSTYPE   LABEL       PARTLABEL        PARTTYPE                             UUID                                 PARTUUID                             MOUNTPOINT
sda                                                                                                                                                         
├─sda1 vfat                 EFI System       c12a7328-f81f-11d2-ba4b-00a0c93ec93b 6A32-E379                            83c10749-babd-467c-b718-4759be9a7a2d 
└─sda2 ext3                 Linux filesystem 0fc63daf-8483-4772-8e79-3d69d8477de4 34a04bf0-cd10-4115-84cb-6995aa1419c7 8096db3c-7e6c-4ad8-a662-258817ef0646 
sdb                                                                                                                                                         
├─sdb1 swap                 Linux swap       0657fd6d-a4ab-43c4-84e5-0933c84b4f4f 01d5b1bb-d522-4019-8072-d652bb5a64e0 c45120c4-4568-4b85-9a7a-6d4f7953f173 
└─sdb2 ext3                 Linux /home      933ac7e1-2eb4-4f13-b844-0e14e2aef915 fcfdeada-d0e8-493b-88df-64e225c78d25 6eab7a61-daba-4deb-9596-3a6118a99633 
sr0    iso9660  ARCH_201605                                                       2016-05-01-04-48-28-00                                                    /run/archiso/bootmnt
loop0  squashfs                                                                                                                                             /run/archiso/sfs/airootfs

R00KIE · 2016-10-07 17:12:46

The UUIDs seems to check out, I was wondering if you might be seeing old information when using blkid but it was up-to-date.

There is another thing you can try, when you are dropped to the recovery shell, check in /dev if your disks are listed there.

Edit:
Out of curiosity, any reason why you are specifically using ext3 and not ext4?

Last edited by R00KIE (2016-10-07 17:13:27)

catnap · 2016-10-07 19:06:35

R00KIE wrote:

There is another thing you can try, when you are dropped to the recovery shell, check in /dev if your disks are listed there.

Unfortunately, this is impossible because the recovery shell does not respond.

R00KIE wrote:

Out of curiosity, any reason why you are specifically using ext3 and not ext4?

I try to keep all my important files in ext3 file systems so that I can easily use RSync for them.
The choice between ext3 and ext4 was made some time ago and it was - if I remember - largely arbitrary.

R00KIE · 2016-10-07 20:17:25

I'd say, mount / and /boot, use systemd-nspawn to "chroot" into it, do a full update, make sure you include the keyboard hook in mkinitcpio.conf, rebuild your initramfs and try using the fallback to boot, see if it boot or if you can use your keyboard in the recovery shell.

catnap · 2016-10-08 15:49:32

ROOKIE wrote:

I'd say, mount / and /boot, use systemd-nspawn to "chroot" into it, do a full update, make sure you include the keyboard hook in mkinitcpio.conf, rebuild your initramfs and try using the fallback to boot, see if it boot or if you can use your keyboard in the recovery shell.

I followed your suggestion but didn't manage to connect to the network after systemd-nspawn. Perhaps I should have persisted longer to
learn the nature of the problem in the system. But, having spent some time on the issue without much progress, I resolved to take the simple option
and reinstall the system files and the boot loader. My data was in a separate partition, so it was saved.

Last edited by catnap (2016-10-08 19:35:23)

Arch Linux

#1 2016-10-03 21:27:57

Kernel panic: EFI variables missing

#2 2016-10-04 07:00:17

Re: Kernel panic: EFI variables missing

#3 2016-10-04 10:41:04

Re: Kernel panic: EFI variables missing

#4 2016-10-05 07:00:26

Re: Kernel panic: EFI variables missing

#5 2016-10-05 14:17:06

Re: Kernel panic: EFI variables missing

#6 2016-10-06 13:46:01

Re: Kernel panic: EFI variables missing

#7 2016-10-06 15:56:40

Re: Kernel panic: EFI variables missing

#8 2016-10-06 16:35:47

Re: Kernel panic: EFI variables missing

#9 2016-10-06 17:05:17

Re: Kernel panic: EFI variables missing

#10 2016-10-06 17:12:47

Re: Kernel panic: EFI variables missing

#11 2016-10-06 18:03:56

Re: Kernel panic: EFI variables missing

#12 2016-10-06 20:42:19

Re: Kernel panic: EFI variables missing

#13 2016-10-07 13:03:15

Re: Kernel panic: EFI variables missing

#14 2016-10-07 17:12:46

Re: Kernel panic: EFI variables missing

#15 2016-10-07 19:06:35

Re: Kernel panic: EFI variables missing

#16 2016-10-07 20:17:25

Re: Kernel panic: EFI variables missing

#17 2016-10-08 15:49:32

Re: Kernel panic: EFI variables missing

Board footer