# [SOLVED] Need help configuring gentoo kernel 4.9

## knob-creek

This is a follow up to this topic.  I seem to be unable to configure a booting 4.9 kernel.  The kernels i create are unable to mount the root FS and panic.

I realised meanwhile, that the problem is broader than in the topic above.  I have exactly the same problem on two completely different machines:

SATA SSD, MBR partitioning, ext4 root, legacy BIOS boot

NVME SSD, GDT partitioning, btrfs root, UEFI boot

Both 4.9 kernels are configured very close to the respective working 4.8 kernel.  The SSD and the partitioning scheme are recognised by the kernel,  The root FS is compiled into the kernel, which is largely monolithic.  There is an INITRAMFS compiled into the kernel containing the Intel microcode, as the update via microcode_ctl during boot seems to be deprecated.  There is no INITRAMFS containing any modules: everything required for booting is compiled into the kernel.  Almost everything, as it seems.

AFAICS, the kernel is unable to create a root device in /dev, but in fact, i have no clue, where this /dev tree should come from, as the DEVTMPFS is mounted after the root FS.

Any suggestion is very much appreciated.Last edited by knob-creek on Thu Feb 16, 2017 12:49 pm; edited 1 time in total

----------

## ct85711

If I recall correctly, when you use btrfs as your root partition, you need to use an initramfs with btrfs tools built in.  This is because the kernel it's self is not able to rebuilt the btrfs tree to (due to the kernel devs not wanting the kernel to have that ability) know what to mount.  As far as using the NVMe, I have no experience on this, so I don't know if I can help much on that part.

Now this may have changed since I last dealt with this, but from what it looked like from several guides, it hasn't.

As far as your first machine, with the ext4 partition...  Is your boot partition finding the hard drive, or unable to identify the fs type?  Depending on what the error is, the issue can be several things.

On a side note, due to the common frequency with kernel issues.  Double check to see if you are booting with the correct kernel, it is very common for people to forget to mount the boot partition before coping the kernel over to your boot partition (make install also copies the kernel over too).  Also to cover the bases, there is a difference on hitting Y or M when configuring the kernel, the later means it is built as a module.

----------

## knob-creek

As it seems, i have found the reason (and a solution) for the problem: it is the microcode cpio image included.

If i leave CONFIG_BLK_DEV_INITRD=n and omit the microcode.cpio, which contains only a kernel directory, the otherwise unchanged kernel boots fine.

I noticed, that i did not follow the Instructions for Intel microcode.

Note: the easiest way to get the microcode update is described in the last paragraph of the page.

 *ct85711 wrote:*   

> If I recall correctly, when you use btrfs as your root partition, you need to use an initramfs with btrfs tools built in.  This is because the kernel it's self is not able to rebuilt the btrfs tree to (due to the kernel devs not wanting the kernel to have that ability) know what to mount.

 

In fact, kernels since at least 4.4 are able to mount btrfs without external help (if that was ever the case at all).

----------

## sphakka

I'm pulling my hair out trying to boot my new BTRFS-based system. I must be doing something stupid with my initramfs-less kernel-4.9.10 (it's actually a Funtoo system), as, at boot, it's unable to find the root device (whatever I put as "root=" in grub cfg: dev, UUID or LABEL) and  panics with

```
VFS: Unable to mount root fs on unknown-block(0,0)
```

Apparently, it doesn't even get to *find* the right device!? Indeed, no available partition is listed. 

I double checked: BTRFS support static, early devtmpfs, partition support, ecc. The only macroscopic differences are that the disk is an M2 sata SSD (AFAIK, not an NVMe), the 2nd one in the box (so "hd1" for grub) and it's MSDOS-partitioned. The rootfs is actually a BTRFS subvolume -- the correct "rootflags=subvol=..." options is passed to grub -- but is not the *default* one (that's the BTRFS root volume on top of "/dev/sdb3"). I also tried to add "device=/dev/sdb3" to "rootflags" at no avail.

@knob-creek, could you please post your BTRFS volume structure and the relevant parts in your grub and kernel config?

----------

## knob-creek

 *sphakka wrote:*   

> 
> 
> ```
> VFS: Unable to mount root fs on unknown-block(0,0)
> ```
> ...

 

As NeddySeagoon pointed out in my original thread:

 *NeddySeagoon wrote:*   

> 
> 
> ```
> unknown block device (259,7)
> ```
> ...

 

Your kernel does not recognize the hardware.  Maybe you should enable NVME?

----------

## sphakka

Yeah, I've seen NeddySeagoon's words... Indeed, I went back to the BIOS configuration to check SATA settings and switched from "AHCI" to "Compatibility" (ATA) just to give it try and... Bingo! 

Mmh... whadda... no AHCI?? I went back to my kernel config (v4.9.10) and, darn it... had forgotten that (as it was copied over from an older machine that didn't run at all on AHCI)! Stupid me   :Embarassed: 

BTW, @knob-creek, since I'm also interested in Intel's microcode updates, did you finally managed to do that without the initramfs ("new method")?

----------

## knob-creek

 *sphakka wrote:*   

> BTW, @knob-creek, since I'm also interested in Intel's microcode updates, did you finally managed to do that without the initramfs ("new method")?

 

Yes, the intel microcode page explains how to do it in the last paragraph: include the right microcode as binary firmware image.  You don't need the monolithic image nor the cpio image.

----------

