# genkernel-next initramfs fails to resolve mdadm disk label

## triquetra

I am writing this from a laptop booted on gentoo-sources 3.11.2 with an initramfs made March 19, 2014 (with genkernel? -- I don't remember for sure)

I recently upgraded to gentoo-sources 3.18.2 and built an initramfs with genkernel-next (tried both versions 59 and 60).

My boot command line designates root as "LABEL=gentoo".  This boots fine with my old kernel and initramfs, but with the new initramfs made with genkernel-next, the computer cannot resolve "LABEL=gentoo"

I'm not sure what steps to take to find and resolve the issue.  Any ideas?Last edited by triquetra on Thu Feb 05, 2015 5:21 pm; edited 2 times in total

----------

## triquetra

initramfs with genkernel-next-59 produces a kernel panic

initramfs with genkernel-next-60 produces a prompt asking to designate the root block device, with LABEL=gentoo as the default

----------

## Roman_Gruber

hello.

please share your grub config assuming that you use grub

you need to specify in your bootloader which kernel to use, initramfs, and other parameters to get it done.

----------

## triquetra

Thank you for the reply.  I do not use grub, I use rEFInd.  Here's the relevant config from refind.conf:

```
menuentry "Gentoo 3.18.2" {

   icon EFI/refind/icons/os_gentoo.icns

   volume ESP

   loader vmlinuz-3.18.2-gentoo

   initrd initramfs-vmlinuz-x86_64-3.18.2-gentoo

   options "domdadm root=LABEL=gentoo rootfstype=ext4 init=/usr/lib/systemd/systemd real_init=/usr/lib/systemd/systemd"

    submenuentry "Gentoo 3.11.2" {

       loader vmlinuz-3.11.2-gentoo

       initrd initramfs-vmlinuz-x86_64-3.11.2-gentoo

    }

    submenuentry "Gentoo 3.10.2" {

       loader vmlinuz-3.10.2-gentoo

       initrd initramfs-vmlinuz-x86_64-3.10.2-gentoo

    }

}

```

But I'm sure this is not an issue with rEFInd since it works fine with the 3.11.2 kernel and initramfs.

----------

## Roman_Gruber

you may adjust your title and add refind.

Sorry I never used refind bootloader. Grub2 is rock solid

----------

## triquetra

The identical kernel boot command line parameters are passed to both the 3.18.2 kernel with accompanying initramfs (made with genkernel-next) and the 3.11.2 kernel with accompanying initramfs (made with genkernel).  The only difference is that the one with an initramfs made with genkernel-next (3.18.2) will not resolve the "LABEL=gentoo" drive designation.  This suggests that either there is an error in the configuration or compilation of the 3.18.2 kernel (though I don't know what it would be), or that there is an issue with the configuration, compilation, or my improper use of genkernel-next.  Additionally, refind has been working fine with many different kernels over the last 2.5 years, and I only now have trouble booting with an initramfs generated by genkernel-next.  I see no reason to conclude from this evidence that refind is at issue.  

For the record, the kernel command line parameters passed to both kernels is as follows:

```
domdadm root=LABEL=gentoo rootfstype=ext4 init=/usr/lib/systemd/systemd real_init=/usr/lib/systemd/systemd
```

It is my understanding that kernel command line parameters are specific to the kernel, not the bootloader.  So if the command line parameters are the problem (possible) then it doesn't matter whether I'm using GRUB, BURG, LILO, or refind, because the same command line parameters will be used with all of them.

----------

## triquetra

I may have narrowed down the issue some more.  I tried booting the 3.18.2 kernel with the initramfs created for the 3.11.2 kernel (with the old genkernel), and it still does not boot.  For some reason, it appears that my mdadm raid array may not be properly detected with the 3.18.2 kernel.

EDIT: scratch that.  I got the startup directives backwards.  The 3.11.2 kernel will not boot with the 3.18.2 (genkernel-next) initramfs, but the 3.18.2 kernel will boot with the 3.11.2 (old genkernel) initramfs.  I think that narrows the problem down to genkernel-next.  It still seems to be an issue with the genkernel-next initramfs recognizing my mdadm raid devices.

----------

## triquetra

Here's what I get at boot (manually transcribed from boot screen) when booting with the genkernel-next produced initramfs:

```
starting md devices

random: nonblocking pool is initialized

md: md127 stopped

sdb: unknown partition table

sda: unknown partition table

md: bind<sda>

md: bind<sdb>

mdadm: container /dev/md/imsm0 has been assembled with 2 drives

system-udevd used greatest stack depth: 12540 bytes left

initializing root device ...

unable to resolve root: LABEL=gentoo

could not find the root block device in LABEL=gentoo

please specify another value or:

-press Enter for the same

-type "shell" for a shell

-type "q" to skip ...

root block device (LABEL=gentoo):

```

While I was transcribing this from the boot screen, the following appeared:

```
root block device (LABEL=gentoo) :: kworker/dying used greatest stack depth: 11944 bytes left
```

----------

## Roman_Gruber

http://www.gossamer-threads.com/lists/gentoo/user/295108

do yuo have those settings accordingly?

and => with genkernel => http://wiki.gentoo.org/wiki/Systemd/Installing_Gnome3_from_scratch basically the same as it is systemd  with genkernel and mdadm, should be appropriate too

----------

## dobbs

This sounds very similar to the problem I'm having (my forum searches somehow missed this topic).

Does your old (working) initramfs use udev or mdev?

----------

## jburns

Have you seen the bug report sys-kernel/genkernel-next-50 Unable to resolve root on md array?  Adding to the bug report or generating a new bug may help.

----------

## triquetra

 *jburns wrote:*   

> Have you seen the bug report sys-kernel/genkernel-next-50 Unable to resolve root on md array?  Adding to the bug report or generating a new bug may help.

 

Yes, actually the last comment on that bug report is mine.  I forgot I did that 10 months ago.  This has been an unresolved issue for that long ...

----------

## Roman_Gruber

Please do not make a duplicate bug, just post a comment on this bug with the url of this post. ty.

Generating duplicate bugs do not help anyone..

----------

## dobbs

Well I hadn't seen it. :P  Will comment on the bug later, need to get to work.

----------

## triquetra

 *tw04l124 wrote:*   

> http://www.gossamer-threads.com/lists/gentoo/user/295108
> 
> do yuo have those settings accordingly?
> 
> and => with genkernel => http://wiki.gentoo.org/wiki/Systemd/Installing_Gnome3_from_scratch basically the same as it is systemd  with genkernel and mdadm, should be appropriate too

 

I did not have some of these settings, so I tried them out.  While my boot up time was decreased by about half (thanks for that), it did not help with the genkernel-next non-booting issue.  I got the same result.

----------

## triquetra

 *dobbs wrote:*   

> This sounds very similar to the problem I'm having (my forum searches somehow missed this topic).
> 
> Does your old (working) initramfs use udev or mdev?

 

Good question.  Honestly, I don't know, and I'm not sure how to tell.  I would have sworn that it uses udev, but a close examination of the old, successful initramfs boot up process revealed messages about mdev starting up!

Assuming that this may be the cause of the issue, what would you suggest as the next step?

----------

## triquetra

An examination of the successful, old (genkernel) initramfs startup output showed the following additional line not present in the failed, new (genkernel-next) initramfs startup output:

```
mdadm: started /dev/volume0_0 with 2 devices
```

There is no "mdadm: started ..." line in the failed initramfs output.  So, it looks like the genkernel-next initramfs is not starting mdadm properly ...

----------

## triquetra

 *dobbs wrote:*   

> This sounds very similar to the problem I'm having (my forum searches somehow missed this topic).
> 
> Does your old (working) initramfs use udev or mdev?

 

According to this, it appears that my working initramfs uses mdev.  Once my system is booted both mdev and udev appear to be active.

----------

