Panic on first boot - VFS .. unknown block?
 

Finished following the instructions in the LFS 7.5 book last night. All went well as far as i can see, built on a slackware 14.1 machine (x86_64). I've attached a photo below of the panic screen in more detail.

I get this error:
The second line points out a piece of hardware (although it chucks out a random thing on each attempt to boot) sometimes motherboard, sometimes cpu. Not sure if that's relevant.

Here's my fstab on the LFS install:
Contents of /boot on the LFS:
And /etc/lilo.conf from my slackware install:
Running /sbin/lilo -v to update lilo appears to add the LFS entry okay.

I also installed grub2 into the MBR of the disk containing LFS, and tried booting directly from the drive through bios option, but i get the same panic. Assuming this isn't being caused by a lilo misconfiguration.

First i forgot to enable ext2 in the kernel config (i'm using it on /boot which is sdb1), thought that would fix the problem, but after rebuilding the kernel from chroot with ext2/ext3/ext4 built into the kernel (not as modules) i get the same panic.

Any ideas?

You have to build file system modules into the kernel, otherwise you'll have to use an initrd ramdisk which not covered by LFS.

Very well then.

I haven't used LILO for many years, but one thing that looks wrong to me is the image line from the Slackware lilo.conf specifying /mnt/lfs in the path to the kernel. That /mnt/lfs thing is a mount point in the Slackware system. When your LFS system is booting and the fstab file gets read, /dev/sdb1 will be mounted at /boot in the LFS system, not /mnt/lfs/boot. The separate boot partition may require a couple of other adjustments to the lilo.conf file. I don't know LILO anymore, but GRUB would require removing the /boot part of the the path to the kernel and changing 'set root' to the boot partition, for example.

Yes the image path would not be:

image = /mnt/lfs/boot/vmlinuz-3.13.3-lfs-7.5

but:

image = vmlinuz-3.13.3-lfs-7.5

The path you wrote above was done via Slackware with sdb1 mounted on /boot which is NOT advised. LILO and GRUB always see the boot partition as a single existence, and therefore the path should be only a simple file path without directories. When you run liloconfig or grub-mkconfig you should NEVER have /boot mounted.

That's what i thought at first, however /sbin/lilo will fail to run otherwise, as it cannot "see" the vmlinuz file. I checked some examples of using additional disks with lilo and they all mention to mount the drive and reference that in lilo.conf.

But having said that, when i try to boot directly from the disk (grub is on the /dev/sdb MBR also) the same error pops up . I think the image line in lilo configuration is correct.

I'm not 100% sure, but is VFS = Virtual File System? Just a wild guess, but could i be missing drivers for the actual disk? sata for example? Should it be enabled in a default kernel config?

Just rebuilt the kernel in chroot with the nouveau driver (to see better resolution of output), but there is no extra details other than the photo i attached above when it panics. Nouveau seems to load correctly.

Also changed fstab (and lilo.conf in slackware) sections to use UUID's in case of sda/sdb reordering.

Still the same issue. Which drivers related to hard disk do i need to be installed in the kernel? I think it might be a missing SATA option. Are these enabled with a default config?

Here's the disk specs if it's any use:
But then again, it seems to be able to read the kernel from the disk -- as it attempts to boot up??? If it couldn't read the disc, it wouldn't be able to panic in the first place would it?

Okay. Whatever you say. But all this is occurring during booting before any system is running and before a root filesystem has been mounted. Right? So it seems unlikely to me that anything is mounted anywhere at that time.

Okay, but it's possible, even likely, that a similar error exists in your grub.cfg file.

This kernel panic thing when booting a new first LFS system happens often. There's even a recent thread about it still on the first page of listed threads here. They always turn out to be very "un"-mysterious things in either the kernel config or the boot loader config.

During booting and before the root filesystem is mounted, everything the kernel needs to mount the root filesystem should be built into the kernel, or an initial ram filesystem is required. Most of us here build in things like SATA drivers. I recommend that you boot Slackware and study what hard drive drivers it is using (lsmod, lspci) and then recompile your LFS kernel to build those into it. Or, create an initial ram filesystem (but I don't recommend that at this time).

I do that for my BLFS systems on external hard drives which I hotplug making them more likely to be enumerated inconsistently. But booting with UUIDs or LABELs requires an initial ram filesystem (see chapter 5 of the BLFS book). I don't recommend that now because at this time it could be a potential new complication or a diversion away from the real problem. And if these drives are internal SATA drives, it's been my experience for those to be enumerated consistently and not require UUIDs and LABELS. External drives are a different matter though. Booting with UUIDs and LABELs is not a bad idea, but I recommend getting rid of the UUIDs in the config files and returning to device names for now.

Well, it may not be the correct method, but here's what I did on my Vbox install of lfs over Slackware 14 32 bit.

I copied /mnt/lfs/boot/vmlinuz-3.15.5-lfs-SVN-20140714 to
the /boot on the host OS and modified Slackware's /etc/lilo.conf to use
Seems to work. However, I have other issues so I am re-doing DEV again.

I intend to remove the slackware.vdi (sda presently) from the Virtualbox appliance and hopefully just boot the lfs.vdi (sdb presently) when I'm done.
How to do that exactly, I'm not sure. Install grub to /dev/sdb2 (lfs) and adjust /mnt/lfs/etc/fstab to point the correct /dev/disk?

Hope that helps.

damn cache. <redacted double post>

Well, so far i've had no luck experimenting with some changes to fstab (reformatted the /boot to ext4 and copied over files, to see if it made a difference)

It occured to me i can boot with qemu (much faster to test), after copying the vmlinuz file into /tmp :
I can't see how the separate /boot would be the cause of the panic. Although, what steps would i follow to remove the sdb1 from the configuration? I? imagine i just move to /boot contents into a directory named /boot and remove the sdb1 entry from fstab?

Well, /etc/fstab is inside the root filesystem which is not being mounted. So it was an unlikely candidate anyway. This problem is related to something that occurs earlier than /etc/fstab being read.

It's not. The LFS book even recommends a separate boot partition. But having one (or not) affects the syntax of the boot loader config file. A wrong boot loader config can cause your kernel panic.

Yes.

If you use a separate /boot partition, then LILO becomes this:

Note the changes of the root file system and kernel paths compared to yours here:

Because you are using a separate partition, the root file system /(root) has to be loaded as it's partition, not the boot partition's device number. The path to the kernel then has to be correct as well. If the /boot partition's file path is:

/grub
vmlinuz.3.13.3
system.map.3.13.3
config.x64.3.13.3

The the path in LILO must match that path as if that's all LILO is seeing.

If you use a single partition then yes, /boot is path of the path because the /(root) file system is on the same partition as the kernel itself, and therefore the path has to match the path of the mount where the kernel is located.

If the paths are incorrect for the /(root), kernel, and such in LILO's configuration, then you will receive a kernel panic.

LILO, GRUB, and SYSLINUX all work by using this (probably crudely done) format of execution from the configuration more or less:

After running /sbin/lilo with the LFS entry as so:
PS; i renamed the vmlinuz to a shorter filename
Results in:
Fatal: Illegal 'root=' specification: /dev/sdb2

And with this workaround:
Results in:
Fatal: open vmlinuz-3.13.3: No such file or directory

Suggesting that lilo needs the /mnt path for additional drives (other than sda). If i run the lilo config with /mnt/boot/vmlinuz-xxxx, it is successfully added. I don't think lilo actually follows "/mnt" when booting, i think the lil.conf is only used when actually installing lilo..

As when i used the previous method, it's finding the vmlinuz file, as when i compiled nouvea into the kernel, nouveau actually sets the display resolution of the console before the panic. It just doesn't seem to be able to mount the root partition on sdb2. I cannot see why it fails though.

You have to name the kernel what your kernel's exact name is. Just because I gave an example doesn't mean it has to be strictly followed.

Grub, syslinux, and LILO will always look for bzImage or vmlinuz as part of the file name.

Really? I'm beginning to get confused now. As i'm reading conflicting ideas.
I use a customized kernel on slackware, named vmlinuz-custom, where the kernel name hasn't been appended with "-custom", which boots fine. That can't be the issue..

I'm 95% sure my lilo.conf isn't the problem. And i get the same panic/error with grub2, grub, syslinux also (used from a recovery boot cd).

To me, it seems like an option in the kernel is disabled or missing. When i followed the LFS(7.5) book it reccomended to start with make defconfig, i might try to copy my slackware kernel config into the chroot and rebuild it with that. If that doesn't work, then i haven't got a clue.