The mystery root VFS partition not found error on Asus mothe

[sbmagg]

All,

Long time user and admin on with Debian Linux, but admittedly this one has me stumped - the frustrating thing is that I know I am tantalizingly close.... right, the summary then:

I get the dreaded VFS: Unable to mount root fs on unknown-block(8,1) error after successfully installing the Debian OS.

I have an ASUS Z10PE D16 WS motherboard with a Samsung SSD 850 EVO and 128GB of RAM (yes, this will become a workstation). I have tried both the latest AMD64 Wheezy and Jessie DVDs. The motherboard is capable of either BIOS legacy boot and UEFI boot, but thus far I have only being using legacy boot. In both cases of the installation, everything goes smoothly, and I am able to partition and format the drive (just 1 partition, everything in one disk and no /boot or /root partitions). After booting, I get the VFS message. In the display, I don't see any partitions listed, so it seems that the kernel, despite getting found by LILO, panics and fails to boot.

In both DVD versions of Debian, I can boot to rescue mode, see the partition and mount the drive, even going so far as to successfully doing the chroot and bringing up the system manually to get the system up on its feet.

So the questions:

1) Is there a difference between what the OS install DVDs load as far as filesystem or other drivers are concerned versus what gets installed on the disk?

2) Should I be selecting targeted drivers instead of generic drivers?

3) Should I be using UEFI boot instead of legacy boot?

4) In place of the SSD disk, I switched to a 128GB hard disk, I get the same thing

5) Is this motherboard just too new for any of this?

I think I am very close to solving this, but am stuck and would appreciate any pointers please. If need be I can post URLs to pictures (or attachments) if that helps.

Thanks,

[Segfault]

In legacy mode the possible reasons for (8,1) error are:
The root partition is not on this drive, drive enumeration is messed up - do you have more than one drive?
The root partition is not the first partition on first hard drive, are you passing root =/dev/sda1 to the kernel?
Kernel has no support for partition table type used.
Kernel has no support for root filesystem type used.
The good news is kernel is accessing the drive, so it has support for your controller.

[sbmagg]

Hi Segfault

This is where it gets curious:

1) it's the only drive - and after I install and do the final reboot, I power down and also remove the USB optical drive just to be sure the kernel isn't doing somthing silly
2) According to fdisk -l, it's the first partition and only one.

At various times I also explicitly pass root=/dev/sda1, but no change to the boot process, still kernel panics.

Indeed the controller is supported....but it's as if the root fs isn't supported. It's ext4. I also tried the installation over again using ext3 for the same result.

[Segfault]

That drive, has it MBR or GPT partition table?

[sbmagg]

MBR - but going by the installer so I'm guessing it's most likely an MBR.

[Segfault]

I'd try passing root=PARTUUID=<ID here>, but the complication is Lilo considers this string illegal. Lilo can take UUID instead, but for using root filesystem UUID you need initramfs to support this feature. Kernel is able to find the partition by PARTUUID, but needs help when UUID is used.

[sbmagg]

Alright, gave the UUID/PARTUUID a shot - made things worse (this time the same VFS error turned into the more ominous (0,0) one, which means no hardware driver to me.

However, on a lark, I though about this some more: modern hardware, ext4 vs ext3, big drives. LILO is fairly ancient, so lets' try for the other extreme: Go for grub2 and see what happens.

After booting with the rescue DVD again and this time doing:

apt-get install grub2
apt-get purge lilo

And doing a reboot, voila: system boots normally. How about that?

For the recrd, grub-legacy I found not to be friendly with ext4, for that I needed to go to Grub2.

Thanks for the help!