Manjaro only boots in initramfs-fallback: unable to mount root fs on unknown-block(0,0)

Hi there!

I have a 1TB drive that used to have only Manjaro on it. I shrank this partition to 650GB, and then installed Ubuntu on the other 350GB. Ubuntu works fine, but trying to boot into Manjaro results in an error message that says "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0).

However, I am able to boot Manjaro just fine using the fallback initramfs in the advanced options:

I was going to post a picture of the full error screen, but apparently you have to be a higher TL on this forum to do that…

How do I fix this? Can you help me understand how and what I broke so I can learn from this, and hopefully not make the same mistake in the future?

Because I’m sure I’ll be asked this, here are the outputs of various commands run from my Manjaro installation:

$ pacman -Q linux
linux54 5.4.58-1

$ uname -a        
Linux x570-mycomp 5.4.58-1-MANJARO #1 SMP PREEMPT Tue Aug 11 15:46:30 UTC 2020 x86_64 GNU/Linux

$ sudo update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.4-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.4-x86_64.img
Found initrd fallback image: /boot/initramfs-5.4-x86_64-fallback.img
Found Ubuntu 20.04.1 LTS (20.04) on /dev/nvme0n1p5
Found Windows 10 on /dev/sda1
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

Oh, and here is sudo fdisk -l:

$ sudo fdisk -l                      
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDS100T3X0C-00SJG0                      
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: 0x86dd326f

Device         Boot      Start        End    Sectors   Size Id Type
/dev/nvme0n1p1 *          2048 1269925876 1269923829 605.5G 83 Linux
/dev/nvme0n1p2      1269925888 1270976511    1050624   513M  b W95 FAT32
/dev/nvme0n1p3      1270978558 1953523711  682545154 325.5G  5 Extended
/dev/nvme0n1p5      1270978560 1953523711  682545152 325.5G 83 Linux


Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 860
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: 0x2955a4c2

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   1187839   1185792   579M  7 HPFS/NTFS/exFAT
/dev/sda2       1187840 976771071 975583232 465.2G  7 HPFS/NTFS/exFAT


Disk /dev/loop0: 155 MiB, 162533376 bytes, 317448 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


Disk /dev/loop1: 96.63 MiB, 101318656 bytes, 197888 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


Disk /dev/loop2: 144.89 MiB, 151924736 bytes, 296728 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


Disk /dev/loop3: 96.98 MiB, 101695488 bytes, 198624 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


Disk /dev/loop4: 54.96 MiB, 57626624 bytes, 112552 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


Disk /dev/loop5: 55.32 MiB, 58007552 bytes, 113296 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

Welcome to the forum. :slight_smile:

Why are you using an MS-DOS MBR partition table on a UEFI system? :astonished:

Sure, in theory it should be supported, but not all UEFI implementations do, and Manjaro officially only supports a GPT partition table on systems that boot in UEFI mode. And with an NVMe drive, you do indeed need to boot in UEFI mode, because the legacy BIOS compatibility mode does not support that.

:man_shrugging:

I have no idea how I ended up with that. What tool can I use to fix it (can I even fix it without losing my current OS installations)? Would changing that fix my initramfs issue?

It is possible to convert an MBR partition table into GPT, yes, but to be honest, I’ve been exclusively running GNU/Linux for over twenty years, and I’m not touching that topic with a ten-foot pole. It’s tricky, and you could end up losing everything.

I’m not sure, but I suspect it’s related. The only difference between the standard initramfs and the fallback is that the fallback doesn’t include the autodetect hook.

Addendum: You could try rebuilding your initramfs.

sudo mkinitcpio -G

Now you have me wondering if it’s worth it to wipe this drive and start from scratch… :sweat_smile:

Regarding your addendum:

$ sudo mkinitcpio -G
mkinitcpio: invalid option -- 'G'


$ sudo mkinitcpio --help
mkinitcpio 27
usage: mkinitcpio [options]

  Options:
   -A, --addhooks <hooks>       Add specified hooks, comma separated, to image
   -c, --config <config>        Use alternate config file. (default: /etc/mkinitcpio.conf)
   -g, --generate <path>        Generate cpio image and write to specified path
   -H, --hookhelp <hookname>    Display help for given hook and exit
   -h, --help                   Display this message and exit
   -k, --kernel <kernelver>     Use specified kernel version (default: 5.4.58-1-MANJARO)
   -L, --listhooks              List all available hooks
   -M, --automods               Display modules found via autodetection
   -n, --nocolor                Disable colorized output messages
   -p, --preset <file>          Build specified preset from /etc/mkinitcpio.d
   -P, --allpresets             Process all preset files in /etc/mkinitcpio.d
   -r, --moduleroot <dir>       Root directory for modules (default: /)
   -S, --skiphooks <hooks>      Skip specified hooks, comma-separated, during build
   -s, --save                   Save build directory. (default: no)
   -d, --generatedir <dir>      Write generated image into <dir>
   -t, --builddir <dir>         Use DIR as the temporary build directory
   -D, --hookdir <dir>          Specify where to look for hooks.
   -V, --version                Display version information and exit
   -v, --verbose                Verbose output (default: no)
   -z, --compress <program>     Use an alternate compressor on the image

$ sudo mkinitcpio -g    
mkinitcpio: option '-g' requires an argument

What is the correct path here?

My bad, it should have been lowercase “g”. :blush:

sudo mkinitcpio -g /boot/initramfs-5.4-x86_64.img

Thanks, this was a good suggestion, but ultimately did not work. The same error is displayed booting from the main initramfs :confused:. Unsurprisingly, I’m still able to boot from the fallback initramfs…just worried about a kernel update breaking that too, or something.

Here was the output of that comand, if it’s relevant:

$ sudo mkinitcpio -g /boot/initramfs-5.4-x86_64.img
==> Starting build: 5.4.58-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.4-x86_64.img
==> Image generation successful

Well, as a last-ditch effort, you could try installing a more recent kernel generation, say 5.7 or 5.8. It may fix the issue. :thinking:

I figured it out!

I installed the 5.7 kernel per your suggestion, but noticed it wasn’t showing up in the Grub menu. In an attempt to remedy this, I reinstalled Grub like so:

sudo grub-install /dev/nvme0n1
sudo update-grub

This ended up replacing the Grub installed by Ubuntu with the Manjaro Grub. Loading both Ubuntu and Manjaro with either version kernel (5.4 or 5.7) now works.

Thanks so much Aragorn!

2 Likes

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