The Slackware Huge-Kernel config is a good place to start.

After you see how the Slackware kernel operates, you can more or less get a feel of how you can trim down the kernel, keep only the required as module components as such and other things built-into the kernel.

I've had to use a Slackware-Huge kernel config more than a few times to trim and trim and trim down everything until I had a working setup.

Well, i chrooted and built a kernel based on the slackware huge config, same result. Panic on mounting the root fs.
I'll probably start over again...

This configuration/kernel i tested with qemu (direct boot in vm without bootloader):
I don't know.

It could be a problem with qemu rather than LFS. One reason I avoid using a VM.

I'd start over, and use this formula of a setup:

- create a single partition for /(root) and one for swap
- format /(root) using ext4
- set swap at 4GB maximum (8GB if you're going to be expanding into BLFS heavily)
- Rebuild and follow the book to the letter (no deviations)
- Complete LFS as a book, and import the Rebooting chapter recommended packages and dependencies for OpenSSH, OpenSSL, Wget, Lynx, GPM, and dhclient (you may want wget's SSL certificates as well), and complete at least Chapter 3 of the BLFS book.
- Import the latest Slackware Huge Kernel config and run "make olddefconfig" against it (this will update non-set parameters to the defaults)
- Setup using Grub-2 as the bootloader from the HOST operating system. (most distributions already supply Grub2)

...and it should work.

Did you compile the correct SATA driver for your system into the kernel? If you don't know which one is correct then just include them all, you can always recompile the kernel later.

If that doesn't work or doesn't work reliably, then you may also have a device naming issue and you'll need to use an initramfs combined with UUIDs. The BLFS initramfs will do just fine.

The Huge kernel from Slackware should have all known drivers enabled.

It can't be a problem with qemu, as i said, the same panic/error happens with everything. From lilo, to grub, grub2, and even syslinux for the bootloader. I used qemu to rule out the bootloader being misconfigured.

Tried editing fstab for sd{a,b}? and all variations in bootloader settings too, so it's not reordering the device names. they shouldn't change with qemu anyway, as it uses whatever the host system sees.

And what about the SATA drivers in your kernel? Perhaps you could compare the SATA drivers in your LFS kernel config and your Slackware custom kernel config?

I ended up compiling a kernel yesterday with the slackware (huge) config as i wrote above, which resulted in the same error when trying to boot. Oddly it made no change as per the kernel panic complaining about 'VFS unable to mount root fs'.

Check your fstab.

VM was useful for me (like videos or reading) but honestly i have never been able to install lfs on it, i think it's more difficult.

Have you tried using an initramfs combined with UUIDs? As a further debugging step, assuming you use the BLFS initramfs, you could add a /bin/sh line just before the do_mount_root line near the end of the init script so you can analyse /dev and look for all the hard drive related stuff there (/dev/sdxN, /dev/disk/by-uuid/*, etc.) and see if there's anything odd about it.

If that doesn't work and the debugging doesn't show anything peculiar then I'm completely out of ideas.

For those who have difficulties with Slackware Linux 14.1's post installation on hyper-v and after the system perform the first boot and screen hangs at the following message "Kernel panic – not syncing: VFS: Unable to mout root fs on unkown-block". I made a step by step guide on how to fix this:
http://egoncalves.com.br/slackware/i...em-windows-10/

I hope I have contributed

Try grub with this:

# Begin /boot/grub/grub.cfg
set default=0
set timeout=5

insmod ext2
set root=(hd8,18)

menuentry "GNU/Linux, Linux 3.13.3-lfs-7.5" {
linux /boot/vmlinuz-3.13.3-lfs-7.5 root=/dev/sdb2 ro raid=noautodetect
}