2

I recently finally finished my build of LinuxFromScratch version 7.9-SYSTEMD. There is one change I had to make from the book. I needed to aquire a patch for the package inettools that caused PATH_PROCNET_DEV to be undefined. Besdides that, my LFS build is on a second hard drive and will be booting independently from the host system. I am running Ubuntu 16.06 in VMWare and the LFS target machine is also ion VMWare. After the kernel starts to load it goes into a panic state saying:

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

I have already check whether or not the fs type and hard disk type are enabled in the kernel, rebuilt, and still to no avail. Is there anything I have missed in trying to fix this?

EDIT: Changing the hard disk type from SCSI to SATA did not work, nor did changing it to IDE

EDIT: This is my current grub.cfg file:

set default=0 set timeout=5 insmod ext2 set root=(hd0,gpt2) menuentry "LinuxFromScratch-7.9-SYSTEMD" { linux /boot/vmlinuz-current-lfs-7.9-systemd root=/dev/sda2 ro } 

EDIT: Running update-grub on the host successfully found the installation, but it still fails to boot with the same Kernel Panic error. I will try rebuilding my kernel to see if there's something I missed in its copnfiguration

10
  • Is your root filesystem on partition or it occupies the whole second hard disk? I.e. is it sda or sda1 ? Commented Jun 8, 2016 at 14:22
  • No, I have a 1M partition at the front for the bootloader to hook into (fs type ef02) Commented Jun 8, 2016 at 14:23
  • What's your kernel command line? Can you post bootloader configuration? Commented Jun 8, 2016 at 14:24
  • That's the grub.cfg file, correct? Commented Jun 8, 2016 at 14:25
  • I think yes. edit your question and include it. Commented Jun 8, 2016 at 14:25

1 Answer 1

0

I know it's been awhile, but in recently rebuilding the LFS project, it is, by default, incompatible with VM booting. The LFS has to be booted as the host lb a physical machine. If anyone can prove me wrong, please do.

3
  • It has now been a while more, but I have been able to pinpoint the cause by trial and error: it is the initramfs. For testing, in my QEMU guest I built a custom kernel and initramfs for LFS, and had Artix Linux installed separately. LFS kernel + LFS initramfs fails, also Artix kernel + LFS initramfs, but LFS kernel + Artix initramfs boots normally. Commented Jun 19, 2022 at 20:21
  • To clarify, I boot using syslinux, and LFS boots normally when I specify root=/dev/sdXN, but root=UUID=... and similar forms don't work with LFS initramfs. Commented Jun 19, 2022 at 20:23
  • It seems that LFS initramfs errorneously has the init script as /sbin/init (from within the initramfs), instead of the expected /init. Moving the file with mv sbin/init . from with the initramfs source directory and regenerating initramfs fixes the error for me. Commented Jun 20, 2022 at 12:56

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.