View previous topic :: View next topic |
Author |
Message |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Wed Jan 28, 2015 8:55 pm Post subject: genkernel-next initramfs fails to resolve mdadm disk label |
|
|
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 |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Thu Jan 29, 2015 9:00 pm Post subject: |
|
|
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 |
|
Back to top |
|
 |
Roman_Gruber Advocate

Joined: 03 Oct 2006 Posts: 3806 Location: Austro Bavaria
|
Posted: Thu Jan 29, 2015 10:41 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Fri Jan 30, 2015 8:22 pm Post subject: |
|
|
Thank you for the reply. I do not use grub, I use rEFInd. Here's the relevant config from refind.conf:
Code: | 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. |
|
Back to top |
|
 |
Roman_Gruber Advocate

Joined: 03 Oct 2006 Posts: 3806 Location: Austro Bavaria
|
Posted: Sat Jan 31, 2015 9:44 am Post subject: |
|
|
you may adjust your title and add refind.
Sorry I never used refind bootloader. Grub2 is rock solid |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Wed Feb 04, 2015 5:00 pm Post subject: |
|
|
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:
Code: | 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. |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Thu Feb 05, 2015 4:33 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Thu Feb 05, 2015 5:20 pm Post subject: |
|
|
Here's what I get at boot (manually transcribed from boot screen) when booting with the genkernel-next produced initramfs:
Code: | 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:
Code: | root block device (LABEL=gentoo) :: kworker/dying used greatest stack depth: 11944 bytes left |
|
|
Back to top |
|
 |
Roman_Gruber Advocate

Joined: 03 Oct 2006 Posts: 3806 Location: Austro Bavaria
|
|
Back to top |
|
 |
dobbs Tux's lil' helper

Joined: 20 Aug 2005 Posts: 103 Location: Wenatchee, WA
|
Posted: Thu Feb 05, 2015 6:17 pm Post subject: |
|
|
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? |
|
Back to top |
|
 |
jburns Veteran

Joined: 18 Jan 2007 Posts: 1064 Location: Massachusetts USA
|
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Fri Feb 06, 2015 5:15 am Post subject: |
|
|
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 ... |
|
Back to top |
|
 |
Roman_Gruber Advocate

Joined: 03 Oct 2006 Posts: 3806 Location: Austro Bavaria
|
Posted: Fri Feb 06, 2015 8:31 am Post subject: |
|
|
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.. |
|
Back to top |
|
 |
dobbs Tux's lil' helper

Joined: 20 Aug 2005 Posts: 103 Location: Wenatchee, WA
|
Posted: Fri Feb 06, 2015 4:25 pm Post subject: |
|
|
Well I hadn't seen it. :P Will comment on the bug later, need to get to work. |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Fri Feb 06, 2015 4:44 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Fri Feb 06, 2015 4:52 pm Post subject: |
|
|
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? |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Fri Feb 06, 2015 5:04 pm Post subject: |
|
|
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:
Code: | 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 ... |
|
Back to top |
|
 |
triquetra Tux's lil' helper

Joined: 09 Apr 2012 Posts: 93 Location: Kansas, USA
|
Posted: Mon Feb 09, 2015 6:30 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
|