# Kernels not booting after linux-4.4.39-gentoo [solved]

## lepgalle

Hi,

this is going to be the most silly post on this forum   :Sad: 

Some time ago (perhaps 2 years) I switched to Grub2 and moved away from MBR. The issue is that I do not know anymore what I use now instead...

My system was updating fine until a kernel version above linux-4.4.39-gentoo was pulled in. Then it stopped booting with the message 

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

The linux-4.4.39-gentoo kernel still boots all right.

My guess is that I am using EFI. Here is my partition scheme:

     Device                              Start                 End             Sectors             Size Type

    /dev/sdb1                            2048                6143                4096               2M BIOS boot             

    /dev/sdb2                            6144              268287              262144             128M EFI System

    /dev/sdb3                          268288            33822719            33554432              16G Linux swap

    /dev/sdb4                        33822720           976771119           942948400           449.6G Linux LVM

Yes, I am using LVM and root is in inside LVM. Therefore I have dracut and after each kernel upgrade I did run a sequence

of grub-mkconfig and dracut for generating new initramfs and grub entries.

All reading and googling I did so far only confused me since it appears that a quite convoluted process would be necessary to have things running properly. I do not recall having done more than a few lines  of grub-mkconfig and dracut after upgrades.

I understand that I should post more information but I do not even know how to provide the correct information. What changed for kernels above linux-4.4.39-gentoo?

Hope someone would be able to help me.

Cheers PetrikLast edited by lepgalle on Tue Sep 05, 2017 10:48 pm; edited 1 time in total

----------

## krinn

 *lepgalle wrote:*   

> I switched to Grub2 and moved away from MBR.

 

I would say, assuming you never forget your controller drivers, you might have forget to enable CONFIG_EFI_PARTITION

So that's the first thing i would check myself.

----------

## lepgalle

 *krinn wrote:*   

>  *lepgalle wrote:*   I switched to Grub2 and moved away from MBR. 
> 
> I would say, assuming you never forget your controller drivers, you might have forget to enable CONFIG_EFI_PARTITION
> 
> So that's the first thing i would check myself.

 

Thanks a lot. I guess I did not forget to set that. Here is what I have for the kernel which runs (right now). It is version 4.4.21:

# uname -a

Linux pgal 4.4.21-gentoo #1 SMP Sun Oct 16 03:03:47 CEST 2016 x86_64 Intel(R) Core(TM) i7 CPU X 940 @ 2.13GHz GenuineIntel GNU/Linux

linux # grep EFI ../linux-4.4.21-gentoo/.config

CONFIG_EFI_PARTITION=y

CONFIG_EFI=y

CONFIG_EFI_STUB=y

# CONFIG_EFI_MIXED is not set

# CONFIG_FB_EFI is not set

CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y

# EFI (Extensible Firmware Interface) Support

CONFIG_EFI_VARS=y

CONFIG_EFI_ESRT=y

# CONFIG_EFI_FAKE_MEMMAP is not set

CONFIG_EFI_RUNTIME_WRAPPERS=y

CONFIG_EFIVAR_FS=m

# CONFIG_EARLY_PRINTK_EFI is not set

# CONFIG_EFI_PGT_DUMP is not set

Because later versions do not run I tried setting most of the EFI related kernel stuff (here kernel linux-4.9.6-gentoo-r1):

linux # grep EFI  .config

CONFIG_EFI_PARTITION=y

CONFIG_EFI=y

CONFIG_EFI_STUB=y

# CONFIG_EFI_MIXED is not set

# CONFIG_FB_EFI is not set

CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y

# EFI (Extensible Firmware Interface) Support

CONFIG_EFI_VARS=y

CONFIG_EFI_ESRT=y

CONFIG_EFI_FAKE_MEMMAP=y

CONFIG_EFI_MAX_FAKE_MEM=8

CONFIG_EFI_RUNTIME_WRAPPERS=y

CONFIG_EFI_BOOTLOADER_CONTROL=y

CONFIG_EFI_CAPSULE_LOADER=y

CONFIG_EFI_TEST=y

CONFIG_EFIVAR_FS=m

# CONFIG_EARLY_PRINTK_EFI is not set

# CONFIG_EFI_PGT_DUMP is not set

So, perhaps I enabled too much.

Thanks Petrik

----------

## krinn

if kernel "see" the partitions, it should provide the list of founded partitions, so the question is "does kernel output the partitions"? (it should list them after the unable to mount root)

also it point you to block(0,0) and it's a good clue you either pass wrong disk/partition to use, or probably better, it cannot see it because the controller drivers are not loaded (recheck your initram)

----------

## lepgalle

 *krinn wrote:*   

> if kernel "see" the partitions, it should provide the list of founded partitions, so the question is "does kernel output the partitions"? (it should list them after the unable to mount root)
> 
> also it point you to block(0,0) and it's a good clue you either pass wrong disk/partition to use, or probably better, it cannot see it because the controller drivers are not loaded (recheck your initram)

 

Hi,

I took a movie today. The boot sequence detects the CPU (smpboot) and the correct number of cores.

Than it finds sda (with its correct partitions) attached to ata1.

Next if finds the DVD drive on ata2.

Third it finds sdb (with its correct partitions) attached to ata3.

It (correctly) founds that nothing is attached to ata4 and ata5.

Than it very briefly flashes something like '[unreadable] device "mapper/vg1-root" or unknown-block(0[unreadable]'  

vg1-root would be the correct root device.

Next the screen is occupied by the backtrace.

Again kernel 4.4.21-gentoo is working, so I am not sure what driver would be missing for later kernels (or better what would I need to do to recheck the initram)

Thank you very much

Petrik

----------

## NeddySeagoon

lepgalle,

When you get the backtrace, the initrd should offer to give you a shell.

Go into the shell and check that your devices are there.

```
ls /dev/sd*
```

should list all of your hard drives and partitions.

I suspect that will be OK.

```
ls /dev/mapper/*
```

should list your logical volumes. I suspect that will fail.

This indicates that the lvchange command is either not being run or is failing for some reason.

The command you need to run by hand, in the rescue shell is 

```
lvchange -ay
```

Exactly how you do that depends on what is in your initrd.

You may have /sbin/lvchange or only lvm, in which case run

```
/sbin/lvm lvchange -ay
```

and look for your logical volumes again.

----------

## lepgalle

Thank you NeddySeagoon,

```
when you get the backtrace, the initrd should offer to give you a shell.
```

In order to have the shell I re-emerged dracut with the debug use flag set. However, in doing so while using the latest  kernel (4.9.16) it turns out all is back to normal.    

Not sure where to go from here. I could go back to older kernel sources but since the problem is gone I am not too dedicated to do this. I assume that I did something wrong repeatedly when creating the initramfs and updating grub.

Thank you very much

Petrik

----------

## lepgalle

Hi, just to report what the cause was for this error. 

Updating from 4.9.34 to 4.12.5 bought back the error. The reason is simple:

```
 grub-mkconfig -o /boot/grub/grub.cfg 
```

does not detect the second (new) initramfs:

```

Generating grub configuration file ...

Found linux image: /boot/vmlinuz-4.12.5-gentoo

Found initrd image: /boot/early_ucode.cpio

Found linux image: /boot/vmlinuz-4.9.34-gentoo

Found initrd image: /boot/early_ucode.cpio /initramfs-4.9.34-gentoo.img

done

```

I should have picked this up much earlier but I did only see: "kernel", "initramfs" and "early_ucode.cpio", so should be fine. I did not notice the version number mismatch. So, the question is now why this is the case but that is perhaps a different thread.

Thank you very much

Petrik

----------

## eccerr0r

Grub2 matches initramfs and kernels by version numbers, if a initramfs-* file doesn't exist with the same version number in the filename of the kernel, it will assume it's not necessary and skip it.

In this case you'd need to name it initramfs-4.12.5-gentoo .  The initramfs is generated by another tool so you'll need to use that tool to generate the initramfs.  I'm not familiar with dracut or how to use it.

I have a custom built initramfs that is version agnostic, and ended up symlinking a whole bunch of names to the same image to trick grub-mkconfig to think that they're custom for each kernel.

----------

## lepgalle

Thank you very much, eccerr0r,

You are entirely correct. In fact it was a stupid typo when passing on the kernel version to Dracut. This is what Dracut expects:

 *Quote:*   

>  dracut --kver 4.12.5-gentoo 

 

But I had a typo in the kernel version, so the initramfs did not have the correct name (as you guessed) and grub ignored it subsequently.

So, as most of the time a tiny mistake back in the chain causing me a lot of trouble later on. Glad it is solved.

----------

