fsck failure and emergency shell upon booting from GRUB.

LinearView88 · 2021-03-28 22:03:29

Hi! I'm a first time Arch user, and I'mrunning into a weird error during the installation process. Specifically, I'm trying to dual boot Arch on a brand new HP Pavillion Laptop (model 14M-DW1023DX) with Windows 10 already installed. I have previously successfully set up Arch on a VM, but each of the three times I've installed it on the laptop itself I have run into the same issue. I followed the installation guide carefully, and all of the steps have had the exact results expected. Everything seems fine, and I'm able to restart and boot into Windows from GRUB. Booting Arch Linux from GRUB, however, results in the following:

Starting version 247.4-2-arch
ERROR: device 'UUID=46d641db-4c78-445c-bcb8-795a4124de4c' not found. Skipping fsck.
mount: /new_root: can't find UUID=46d641db-4c78-445c-bcb8-795a4124de4c.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off

I have searched through old forum posts and tried a number of fixes at this point, such as re-mounting, mounting, and running

mkinitcpio -p linux

, as well as completely starting the installation from scratch. No matter what I do, I get dropped into the same emergency shell.

Here's my fstab output:

# /dev/nvme0n1p5
UUID=46d641db-4c78-445c-bcb8-795a4124de4c   /   ext4   rw,relatime   0 1

# /dev/nvme0n1p1 LABEL=SYSTEM
UUID=E0CF-5933   /efi   vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro   0 2

# /dev/nvme0n1p6
UUID=59b88351-2ed6-4df5-bb22-416e17aa3044   none   swap   defaults   0 0

And my blkid output:

/dev/sda1: BLOCK_SIZE="2048" UUID="2021-03-01-14-38-40-00" LABEL="ARCH-202103" TYPE="iso9660" PARTLABEL="ISO9660" PARTUUID="31323032-3330-4130-b131-303433383430"
 /dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="ARCHISO_EFI" LABEL="ARCHISO_EFI" UUID="CEBF-205D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Appended2"  PARTUUID="31323032-3330-4130-b133-303433383430"
 /dev/sda3: PARTLABEL="Gap1" PARTUUID="31323032-3330-4130-b133-303433383430"
 /dev/loop0: TYpE="squashfs"
 /dev/nvme0n1p1: LABEL="SYSTEM" UUID="E0CF-5933" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUID="de26502e-68d3-4ce4-9cd7-7342797c0c2f"
 /dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="d67963a9-6a86-4db3-a748-351e90614137"
 /dev/nvme0n1p3: LABEL="Windows" BLOCK_SIZE="512" UUID="E62EB84C2EB8178F" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="c8a764e1-f6ed-4f15-8e41-e85f8938fb6d"
 /dev/nvme0n1p4: LABEL-"Windows RE tools" BLOCK_SIZE="512" UUID="34F6D189F6D14BAC" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="4c2ce2f5-a1eb-4ca5-ba06-b2441540c86c"
 /dev/nvme0n1p5: UUID="46d641db-4c78-445c-bcb8-795a4124de4c" BLOCK_SIZE="4096 TYPE="ext4" PARTUUID="9ba5d7f2-e798-9b47-97d4-3f208f79534d"
 /dev/nvme0n1p6: UUID="59b88351-2ed6-4df5-bb22-416e17aa3044" TYPE="swap" PARTUUID="507eb575-ae59-9040-84cb-9440d516c966"

My current hunch is that for some reason, there is something off in my grub.cfg file, since I generated it with grub-install and there's a weird redundant conditional. The relevant menu entry in my grub.cfg file is as follows:

menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-46d641db-4c78-445c-bcb8-795a4124de4c' {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod part_gpt
    insmod ext2
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root 46d641db-4c78-445c-bcb8-795a4124de4c
    else
      search --no-floppy -fs-uuid --set=root 46d641db-4c78-445c-bcb8-795a4124de4c
    fi
    echo    'Loading Linux linux ...'
    linux /boot/vmlinuz-linux root=UUID-46d641db-4c78-445c-bcb8-795a4124de4c rw loglevel=3 quiet
    echo  'Loading initial ramdisk ...'
    initrd  /boot/initramfs-linux.img
}

Lastly, here's the list of files in my /boot directory, just to show that I have the kernel in the correct location:

grub initramfs-linux-fallback.img initramfs-linux.img vmlinuz-linx

I would be incredibly grateful for any help in addressing this issue!

EDIT: Apologies for any formatting inconsistencies. I manually typed this all out in order to force myself to read everything closely.

Last edited by LinearView88 (2021-03-28 22:05:40)

nick_0189 · 2021-03-30 00:44:23

What command(s) did you use to install grub?

LinearView88 · 2021-03-30 02:41:11

Thank you for the response!

nick_0189 wrote:

What command(s) did you use to install grub?

I believe that I ran

grub-install --target=x86_64-efi --efi-directory=/efi/ --bootloader-id=GRUB

It's possible that I could have mistakenly passed in the wrong efi directory, although I'm not sure how I would check that at this point.

ewaller · 2021-03-30 03:00:41

Can you go back and verify the UUIDs of the volumes?

Scimmia · 2021-03-30 03:12:03

Try the fallback initramfs

nick_0189 · 2021-03-30 03:19:00

The EFI directory would be my first guess. I had a lot of trouble getting it right at first.

When you mounted your partitions, what was the name of the partition that you mounted to /efi/, the directory supplied as the argument to the "--efi-directory" flag in your grub-install command?

LinearView88 · 2021-03-30 03:19:21

Thank you very much for the suggestions!

Unfortunately, booting using the fallback initramfs (also Linux linux) failed as well, with the exact same error message and emergency shell. I have to get to work, but tomorrow I'll go back and verify the UUIDs of the volumes and post an update.

LinearView88 · 2021-03-30 03:21:42

nick_0189 wrote:

The EFI directory would be my first guess. I had a lot of trouble getting it right at first.
When you mounted your partitions, what was the name of the partition that you mounted to /efi/, the directory supplied as the argument to the "--efi-directory" flag in your grub-install command?

The partition I mounted to /efi/ was nvme0n1p1.

nick_0189 · 2021-03-30 05:01:14

That looks right so far.

What is in the /efi/ directory on your installed system?

LinearView88 · 2021-03-31 14:28:16

Sorry for the late response; work has been busy. I just booted back into my installation media.

nick_0189 wrote:

What is in the /efi/ directory on your installed system?

EFI  grub  initramfs-linux-fallback.img  initramfs-linux.img 'System Volume Information'  vmlinuz-linux

ewaller wrote:

Can you go back and verify the UUIDs of the volumes?

I wasn't sure which volumes to verify, but I ran blkid again and verified that the UUID of nvme0n1p5 is 46d641db-4c78-445c-bcb8-795a4124de4c. The UUID of nvme0n1p1 is E0CF-5933.

nick_0189 · 2021-04-01 05:18:43

Do you know why some of the same files are in /boot and /efi? Particularly the kernel and initramfs images and the grub directory?

You said you generated your grub.cfg with grub-install. Do you mean grub-mkconfig?

Are you sure that the ESP was mounted to /efi when the grub-install command was run?

The reason I ask that last question is, from what I understand in the wiki pages, /boot is the preferred directory to be used as esp and it is not necessary to make a separate /esp directory, although using a separate /esp directory should work just the same. According to the wiki, when using the /efi directory as esp, the kernel and initramfs images should be located in /boot while the ESP containing the grub and EFI directories should be mounted to the /efi partition. Because you have the kernel and initramfs images in the /efi directory and a grub directory in the /boot directory, I wanted to ask if the EFI System Partition (/dev/nvme0n1p1) mounted to /efi when the the following command was run.

grub-install --target=x86_64-efi --efi-directory=/efi /dev/sda --bootloader-id=ArchLinux

When chrooted into the system before mounting the ESP to anything, I do believe that the /efi directory should be empty, then after mounting the ESP to it you should see the grub and EFI directories, but not the kernel and initramfs images, those should be in the /boot directory, which is not a mountpoint. Does that sound like it might be the problem?

Also, I know this more of skips your problem rather than solving it, but if you're just wanting this done rather than figuring out what the problem is with the specific situation of mounting the ESP to the /efi directory rather than just using the /boot directory, then these are roughly the steps I would normally take to install grub onto a UEFI system (though I'll admit I manage to screw something up half the time anyways during these steps):
1. Boot into a live environment.
2. Change root into your installation and move /boot, /efi/ and /etc/fstab to the /root folder to back them up. (You'll need to move parts of the /efi directory back in order to boot Windows, or it might just be easier to not move the EFI directory in /efi to make sure you don't break anything. Have you made backups recently?)
3. Remake /boot and mount your EFI System Partition to it.
4. Exit chroot and regenerate /etc/fstab.
5. Chroot back into your root partition to reinstall the linux package and run mkinitcpio -P to regenerate your initramfs.
6. Reinstall Grub with the --efi-directory flag argument set to /boot, not /efi.

Relevant Wiki Pages:
https://wiki.archlinux.org/index.php/EF … unt_points
https://wiki.archlinux.org/index.php/GR … allation_2

LinearView88 · 2021-04-02 01:45:41

nick_0189 wrote:

Also, I know this more of skips your problem rather than solving it, but if you're just wanting this done rather than figuring out what the problem is with the specific situation of mounting the ESP to the /efi directory rather than just using the /boot directory, then these are roughly the steps I would normally take to install grub onto a UEFI system (though I'll admit I manage to screw something up half the time anyways during these steps):

Thanks for this. After some careful consideration and browsing of the wiki, I decided to try this. I followed the steps exactly, but unfortunately was confronted by the exact same error message and emergency shell after rebooting and selecting Arch Linux in GRUB. Booting into the fallback initramfs fails as well. I kept a backup of everything like you suggested, but I think I'll keep it as it is right now, in order to avoid problems in the future.

At this point, I'm pretty flummoxed. Everything seems like it should be right.

nick_0189 · 2021-04-02 03:31:50

That's a word I haven't heard before, "flummoxed." Nice.

I'd think it should be right as well. Maybe somebody that knows more than the people who have participated in this thread so far will come along see an obvious answer, but until then I'll continue thinking about the issue.

Assuming you did everything right with installing the bootloader, the next thing to try might be the kernel. But before trying kernel parameters, have you tried looking into the questions I asked at the beginning of my previous post?

I want to make sure those things I asked about specifically were done because dumb things like forgetting to mount the esp, installing the bootloader with the wrong efi-directory, and moving and deleting things incorrectly in an attempt to get things working were mistakes I repeatedly made when first learning this stuff. It took me a while to figure it all out.

LinearView88 · 2021-04-02 03:43:04

nick_0189 wrote:

Assuming you did everything right with installing the bootloader, the next thing to try might be the kernel. But before trying kernel parameters, have you tried looking into the questions I asked at the beginning of my previous post?

Whoops, I forgot to mention those.

nick_0189 wrote:

Do you know why some of the same files are in /boot and /efi? Particularly the kernel and initramfs images and the grub directory?

It's moot at this point, but I have no idea why the same files were in /boot and /efi. That definitely shouldn't happen.

nick_0189 wrote:

You said you generated your grub.cfg with grub-install. Do you mean grub-mkconfig?

Oops. I meant grub-mkconfig; accidentally typed the wrong thing.

nick_0189 wrote:

Are you sure that the ESP was mounted to /efi when the grub-install command was run?

Yes. I've been really careful about mounting the ESP before running grub-install.

nick_0189 · 2021-04-02 04:19:40

This is weird. I'm really interested to see what the problem actually is.

After you reinstalled, you used the installation method I listed before, so you used /boot and not /efi as your esp, correct?

And when initially chrooting into the root of your installation (not mounting your EFI System Partition to anything yet, only mounting /dev/nvme0n1p5 to /mnt and chrooting into it) what is in the /boot directory as shown by the "ls /boot" command?

LinearView88 · 2021-04-04 17:38:29

Yes. After the reinstall, I used /boot and not /efi as my esp.

When initially chrooting into the root of my installation, the /boot directory is empty. No hidden files or anything either.

cfr · 2021-04-06 01:21:52

Did you remake grub.cfg as well as reinstalling grub? Try installing grub with the -v option and post the output.

What does blkid give now? What does ls -R /boot give?

LinearView88 · 2021-04-06 18:36:54

I just reran grub-install and grub-mkconfig, as I did before. The full output is too verbose to post (plus I'm writing this from my old computer) but the last several lines of grub-install --target=x86-64-efi --efi-directory=/boot/ /dev/nvme0n1p1 --bootloader-id=GRUB -v were as follows:

grub-install: info: adding 380 padding fixup entries
grub-install: info: writing 840 bytes of a fixup block starting at 0xe000.
grub-install: info: reading /usr/lib/grub/x86_64-efi/fshelp.mod.
grub-install: info: reading /usr/lib/grub/x86_64-efi/fat.mod.
grub-install: info: reading /usr/lib/grub/x86_64-efi/part-gpt.mod.
grub-install: info: kernel_img=0x55ecf0edbf80, kernel_size=0x1a000
grub-install: info: the core size is 0x1de68.
grub-install: info: writing 0x20000 bytes.
grub-install: info: copying '/boot/grub/x86_64-efi/core.efi -> '/boot/EFI/GRUB/grubx64.efi'.
grub-install: info: Registering with EFI: distributor = 'GRUB', path = '\EFI\GRUB\grubx64.efi', ESP at hostdisk//dev/nvme0n1,gpt1
grub-install: info: executing efibootmgr --version </dev/null >/dev/null
grub-install: info: executing modprobe -q efivars.
grub-install: info: executing efibootmgr -c -d /dev/nvme0n1 -p 1 -w -L GRUB -l \EFI\GRUB\grubx64.efi
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0000,0002,0001
Boot0001* Windows Boot Manager
Boot0002* USB Drive (UEFI) - USB DISK 2.0 PMAP
Boot0000* GRUB
Installation finished. No error reported.

Prior to this, the screen was filled with an enormous amount of redundant verbose info about adding relocation entries.

Output for grub-mkconfig -o /boot/grub/grub.cfg:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Fount initrd image: /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: initramfs-linux-fallback.img
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
done

My output for blkid is the same as before, but /dev/sda3 and /dev/nvme0n1p2 have mysteriously moved to the end of the list. I checked my /boot/grub/grub.cfg and it looks identical and the UUIDs are still correct. I tried booting into Arch with grub, and I'm still being kicked into the emergency shell instead, with the exact same output

nick_0189 · 2021-04-07 22:35:25

Thanks for the GRUB output. I think we're getting pretty sure there is nothing wrong with GRUB.

Can you post the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables from the /etc/default/grub file?
Can you also post what kernel options/parameters are listed when you press the e key in grub with the default boot option for Arch Linux selected?
It should look something like what I've put below:

linux        /boot/vmlinuz-linux root=UUID=SomeUUID option1 option2...

I'm particularly interested in what the "option1 option2..." stuff is, but I think the whole line would be helpful to post.

Does your computer go directly to the rootfs shell, or does it take a few seconds/minutes before it gets there?

LinearView88 · 2021-04-07 23:37:51

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet"
GRUB_CMDLINE_LINIUX=""

I also noticed that GRUB_DISABLE_LINUX_UUID=true was commented out. Should that be the case?

Pressing the e key in grub with the default boot option for Arch Linux selected:

linux    /vmlinuz-linux root=UUID=46d641db-4c78-445c-bcb8-795a4124de4c rw  loglevel=3 quet

It takes a few seconds to get dumped into the emergency shell.

EDIT: Huh, there's no "boot" prepended to /vmlinuz-linux. That seems odd.

Last edited by LinearView88 (2021-04-07 23:38:56)

Head_on_a_Stick · 2021-04-08 06:31:04

LinearView88 wrote:

there's no "boot" prepended to /vmlinuz-linux. That seems odd.

Not really — the ESP is now mounted under /boot so the path to the kernel is relative to that.

Can we see

efibootmgr -v

See the pastebin client section of the ArchWiki "Applications" page for a way to share output without having to transcribe it manually.

LinearView88 · 2021-04-08 12:31:49

Head_on_a_Stick wrote:

See the pastebin client section of the ArchWiki "Applications" page for a way to share output without having to transcribe it manually.

Thank you so much. I wish I had thought of using curl earlier.

Running efibootmgr -v from the installation media yields the following:

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000
Boot0000* GRUB	HD(1,GPT,de26502e-68d3-4ce4-9cd7-7342797c0c2f,0x800,0x82000)/File(\EFI\GRUB\grubx64.efi)
Boot0001* USB Drive (UEFI) -  USB DISK 2.0 PMAP	PciRoot(0x0)/Pci(0x14,0x0)/USB(0,0)/HD(2,GPT,31323032-3330-4130-b132-303433383430,0x14e800,0x20800)..BO

Morn · 2021-04-08 14:20:20

You don't have to use UUIDs for partitions at all. They often cause problems in my personal experience. Just use the device name for booting:

root=/dev/nvme0n1p5 …

Head_on_a_Stick · 2021-04-08 14:50:25

^ UUIDs are recommended. The block device assignment may change from one boot to the next (although this isn't an issue for the OP) and Windows has a nasty habit of re-numbering partitions, which would also break your suggested configuration.

@OP: check the kernel image version with the 'file' command and make sure it matches the installed modules (/usr/lib/modules/).

LinearView88 · 2021-04-08 17:15:53

Head_on_a_Stick wrote:

@OP: check the kernel image version with the 'file' command and make sure it matches the installed modules (/usr/lib/modules/).

Thanks, will do. Without anything mounted, I have 5.11.2-arch1-1 in modules. When I mount everything, chroot, and run file /boot/vmlinuz-linux, I get the following output:

vmlinuz-linux: Linux kernel x86 boot executable bzImage, version 5.11.11-arch1-1 (linux@archlinux) #1 SMP PREEMPT Tue, 30 Mar 2021 14:10:17 +0000, R0-rootFS, swap_dev 0x8, Normal VGA

After mounting, I have 5.11.11-arch1-1 and 5.11.9-arch1-1 in my modules folder.

Arch Linux

#1 2021-03-28 22:03:29

fsck failure and emergency shell upon booting from GRUB.

#2 2021-03-30 00:44:23

Re: fsck failure and emergency shell upon booting from GRUB.

#3 2021-03-30 02:41:11

Re: fsck failure and emergency shell upon booting from GRUB.

#4 2021-03-30 03:00:41

Re: fsck failure and emergency shell upon booting from GRUB.

#5 2021-03-30 03:12:03

Re: fsck failure and emergency shell upon booting from GRUB.

#6 2021-03-30 03:19:00

Re: fsck failure and emergency shell upon booting from GRUB.

#7 2021-03-30 03:19:21

Re: fsck failure and emergency shell upon booting from GRUB.

#8 2021-03-30 03:21:42

Re: fsck failure and emergency shell upon booting from GRUB.

#9 2021-03-30 05:01:14

Re: fsck failure and emergency shell upon booting from GRUB.

#10 2021-03-31 14:28:16

Re: fsck failure and emergency shell upon booting from GRUB.

#11 2021-04-01 05:18:43

Re: fsck failure and emergency shell upon booting from GRUB.

#12 2021-04-02 01:45:41

Re: fsck failure and emergency shell upon booting from GRUB.

#13 2021-04-02 03:31:50

Re: fsck failure and emergency shell upon booting from GRUB.

#14 2021-04-02 03:43:04

Re: fsck failure and emergency shell upon booting from GRUB.

#15 2021-04-02 04:19:40

Re: fsck failure and emergency shell upon booting from GRUB.

#16 2021-04-04 17:38:29

Re: fsck failure and emergency shell upon booting from GRUB.

#17 2021-04-06 01:21:52

Re: fsck failure and emergency shell upon booting from GRUB.

#18 2021-04-06 18:36:54

Re: fsck failure and emergency shell upon booting from GRUB.

#19 2021-04-07 22:35:25

Re: fsck failure and emergency shell upon booting from GRUB.

#20 2021-04-07 23:37:51

Re: fsck failure and emergency shell upon booting from GRUB.

#21 2021-04-08 06:31:04

Re: fsck failure and emergency shell upon booting from GRUB.

#22 2021-04-08 12:31:49

Re: fsck failure and emergency shell upon booting from GRUB.

#23 2021-04-08 14:20:20

Re: fsck failure and emergency shell upon booting from GRUB.

#24 2021-04-08 14:50:25

Re: fsck failure and emergency shell upon booting from GRUB.

#25 2021-04-08 17:15:53

Re: fsck failure and emergency shell upon booting from GRUB.

Board footer