I've been building my own kernel (4.19.37) and have no issues during build (make) or install (make install_modules + make install). Everything seems to go fine until I execute grub2-mkconfig -o /boot/grub2/grub.cfg. When executing this command, grub finds both my existing and new vmlinuz-* kernels in /boot/ as well as their corresponding initramfs-*.img. However, at that point the system hangs indefinitely (> several hours). Ctrl+C does not seem to stop it and I must reboot. I have looked into this issue and all I have found that could be a problem is the probing of removal disks for bootable OS's, which I have eliminated by both removing them and by adding GRUB_DISABLE_OS_PROBER=true to /etc/default/grub per this SE post. Neither has helped.

Upon reboot, I end up at the grub> command line, presumably because the grub2-mkconfig never finished and corrupted the grub configuration file. Here I can load both the old and new kernel without any issue, as well as initramfs, but when I execute boot I get a kernel panic:

end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

Naturally, it is my assumption that there is something wrong with my initramfs-4.19.37.img that was created by my build process. As an experiment, I tested if I could load the new kernel, but use the old initramfs (4.19.10), and indeed it does boot into emergency mode. I however cannot do the opposite, old kernel with new initramfs. So something is fishy with my new initramfs image.

Getting smarter, my last experiment was mounting the old and new initramfs image with mount. They both mount successfully with no errors, and seem to have identical file structures. I have also compared both my new and old .config files for the kernel builds, and the differences are trivial.

A few other notes/observations:

  • In the image above, you can see List of all partions: produces nothing, so I am wondering if there is an issue with the file system type? My hard drive is xfs, what is the file system for the initramfs? CPIO?
  • At the grub> command line, ls / produces what I expect to see in /boot. It contains all my vmlinuz-* and initramfs-*.img files
  • My file system is xfs
  • I've tried various other kernel versions with same results
  • I have twice had successful builds and installs, once was the existing kernel (4.19.10), it was an upgrade, and a second time with the same kernel with a low-latency pre-emption model. I can't for the life of me figure out what I did differently then.

So the final question(s) are - What's wrong with the initramfs form these builds? What else can I do to validate it's integrity? Are there any .config changes I should make when building the kernel for the xfs file system?

Disclaimer: So this actually an continuation of this question, but I've simplified the problem a bit. Some background info there might be relevant.

  • It looks like it didn’t even find any disks to iterate through for XFS partitions. How is the disk presented via virtualbox? SATA? Make sure your kernel has SATA support turned on. – jsbillings Jun 2 '19 at 15:43
  • That's what I noticed too. Ive done this on both a physical PC (intel atom 3950 with mPCIe SSD) and on virtual box with a SATA drive. Is there a kernel config parameter i should check? – DrTarr Jun 2 '19 at 17:51
  • You should at least have CONFIG_SCSI_SATA=y and enable all of the CONFIG_SCSI_SATA_* drivers. Check what the base packages kernels include. Running make menuconfig should automatically enable any requirements when you enable those drivers. – jsbillings Jun 2 '19 at 19:00
  • CONFIG_SCSI_SATA doesn't exist in 4.19, however, what I assume are the equivalent (just about all SCSI related configurations) are either set to y or m. I also verified the same for all the XFS configurations, and even forced XFS support to y instead of m and rebuilt the kernel with the same results. I think what is strange above is that my new kernel will infact boot with the old initramfs image. But maybe that's because it's loading the kernel modules that are in the old initramfs? – DrTarr Jun 3 '19 at 16:46
  • I think I'm on to something but need a little help. After No filesystem could mount root, tried: is blank. Seems most people who get this message have ext3, ext4, xfs etc. afterwards. Why wouldn't it try any file system type? – DrTarr Jun 3 '19 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.