Grub unknown filesystem/can't chroot after installing Windows 11

Installed Windows 11 (via official Windows Update on my dev channel machine). Went fine until the final reboot that would have taken me into Windows 11. On reboot, I got a grub error:unknown filesystem. All I could do was reboot select Windows boot loader instead of Endeavor. Install finished and Windows 11 booted with no issues. Now, I can either f12 and select Windows or edit boot order to start with Windows. If I try Endeavor, I get the grub error. I can run ls, but truthfully I can barely read it (grub is unreadable on an ultra had monitor it is so small). I booted into the Endeavor live disk. I can mount the root partition, but the efi partition cannot be mounted so no chroot/no grub repair. See output below. I really don’t want to re-image Endeavor, but I am seeing no other options at this point. Help, please! I am in the Endeavor USB at the moment and can get back into Windows whenever at least.

[liveuser@eos-2021.04.17 ~]$ sudo fdisk -l
Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: PM951 NVMe SAMSUNG 256GB                
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1E3941D5-9AFB-40E3-9023-52EF773DAD59

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048   1085439   1083392   529M Windows recovery environment
/dev/nvme0n1p2   1085440   1290239    204800   100M EFI System
/dev/nvme0n1p3   1290240   1323007     32768    16M Microsoft reserved
/dev/nvme0n1p4   1323008 383535103 382212096 182.3G Microsoft basic data
/dev/nvme0n1p5 383535104 384770047   1234944   603M Windows recovery environment
/dev/nvme0n1p6 384772096 500118158 115346063    55G Linux filesystem


Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 686C7141-7244-4A0A-9C10-7CF3334A36A2

Device          Start        End    Sectors   Size Type
/dev/sda1        2048  673998847  673996800 321.4G Microsoft basic data
/dev/sda2  1953262991 1953265038       2048     1M Microsoft LDM metadata
/dev/sda3  1953265039 1953525134     260096   127M Microsoft reserved
/dev/sda4   673998848 1953262990 1279264143   610G Linux filesystem

Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition table entries are not in disk order.


Disk /dev/sdb: 28.64 GiB, 30752000000 bytes, 60062500 sectors
Disk model: Ultra Fit       
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5d66800c

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1  *        0 3916799 3916800  1.9G  0 Empty
/dev/sdb2         180  139443  139264   68M ef EFI (FAT-12/16/32)


Disk /dev/loop0: 1.74 GiB, 1863364608 bytes, 3639384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
[liveuser@eos-2021.04.17 ~]$ sudo su
[root@archiso liveuser]# mount /dev/nvme0n1p6 /mnt
[root@archiso liveuser]# mount /dev/nvme0n1p2 /mnt/boot/efi
mount: /mnt/boot/efi: mount point does not exist.
[root@archiso liveuser]# arch-chroot /mnt
mount: /mnt/proc: mount point does not exist.
==> ERROR: failed to setup chroot /mnt
[root@archiso liveuser]#

It looks like something is failing here. The mount of the efi partition is failing because the efi directory doesn’t exist which is…bad.

After you do this step can we see the results of ls -l /mnt

[root@archiso liveuser]# ls -l /mnt
total 0
drwxr-xr-x 1 root root 130 Jun 1 13:09 @
drwxr-xr-x 1 root root 210 Jun 27 14:00 timeshift-btrfs

Try this:

umount /mnt
mount -o subvol=@ /dev/nvme0n1p6 /mnt
mount /dev/nvme0n1p2 /mnt/boot/efi
arch-chroot /mnt
3 Likes

Forgot to quote/reply.

chroot worked. f***ing genius hopefully. Should I try the grub fix at this point?

1 Like

How did you know that the /mnt was btrfs file system because of the ls -l /mnt command? So the mount command to be able to chroot would have be on a subvolume correct?

I’m guessing because of

:wink:

That’s what i meant? Because i wouldn’t have known otherwise looking the info above. I did understand it couldn’t find the mount point for /. Knowing it was Btrfs from the beginning would be helpful.

1 Like

Yes, you should be able to proceed with reinstalling grub as normal from that point.

1 Like

The command to mount the root partition succeeded, but there was no /mnt/boot/efi directory. That told me that there was two likely scenarios:

  • The root partition was broken/corrupt/erased
  • The filesystem on that device was non-standard in some way.

Then the ls showed two directories, one named @ and the other named timeshift-btrfs

That indicated pretty clearly the issue was that what had been mounted was the root of the btrfs filesystem and the actual root was on a btrfs subvolume named @

2 Likes

Dalto=Legend! I didn’t even think of BTRFS. Been since they fixed the regression a few kernels ago that I installed this box with BTRFS, and obviously hadn’t needed chroot since then.

1 Like

I wonder if there is a note needed about non-standard filesystem in the chroot Wiki…

Well you explained it in a much better way and that is what i was thinking. You are right there wasn’t a /mnt point. I’m just thinking about it as i don’t do a lot of chrooting and i have Btrfs on one system so i try to understand stuff in a logical non technical sense. Then maybe i understand it more better! :wink:

1 Like

Ah, I misunderstood your question then. Interesting stuff though…

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.