Possible duplicate of #372567 However, it seems that line 613 of the /usr/share/genkernel/defaults/initrd.scripts is not executing. I have an /etc/mdadm.conf in the initramfs and my arrays are not started automatically, causing boot to hang. note that it's a 2-disk RAID1 (2x 3TB- yes, I'm using UEFI and GPT) with 1.2 superblocks (i know, i know)- however, when in the ash shell in busybox environment, i issue the same command as what the script has (mdadm --assemble --scan) but it seems they are never mounted. I can provide further info on request; I'm not sure what's needed. Is there any sort of advanced debugging logger or a way I can increase the verbosity? busybox's /var/log/messages didn't seem to hold any clues. The only messages I get are that the ext2 and ext3 mount fail (it's an ext4 volume) when actually mounting the array in busybox.
sorry, some clarification to the above (was away from my lab): -"it seems that line 613 of the..." this is the function with the line included: 609 if [ "${USE_MDADM}" = '1' ] 610 then 611 if [ -e '/sbin/mdadm' ] 612 then 613 /sbin/mdadm --assemble --scan 614 else 615 bad_msg "mdadm not found: skipping mdadm raid assembly!" 616 fi 617 fi -"when in the ash shell in busybox environment, i issue the same command as what the script has (mdadm --assemble --scan) but it seems they are never mounted." i must be low on sleep. i mean that mdadm --assemble --scan, when issued *manually* from the busybox shell (ash), DOES assemble the array. however, the busybox attempt at mounting it during boot seems to fail. -"I can provide further info on request..." since i am able to manually mount the array (and then boot a live distro), i was able to grab the contents of dmesg output and /var/log/messages from the busybox environment. i will be attaching those shortly. this behaviour is repeatable, it seems, as well.
Created attachment 327160 [details] busybox dmesg output interestingly, dmesg seems to find the disks and partitions correctly, so the initramfs at least seems to recognize the GPT tables with no interaction.
Created attachment 327162 [details] /linuxrc file from initramfs image it seems it never actually calls mdadm, which i find incredibly interesting. will post my genkernel.conf to show that i have mdadm enabled. i also have ensured that "domdadm" is on my kernel command line (will post my /etc/default/grub and grub.cfg)
Created attachment 327164 [details] /var/log/messages from busybox environment You can see at Oct 22 13:56:26 in the log when I manually initialize and mount the array. however, i'm wondering why it's showing md0 as being stopped before initializing. is this supposed to happen?
Created attachment 327166 [details] kernel's .config
lspci -k output (from a systemrescuecd environment, which boots just fine and recognizes the arrays but, for obvious reasons, does not boot from them): 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) Subsystem: ASUSTeK Computer Inc. Device 84ca Kernel driver in use: agpgart-intel 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) Kernel driver in use: pcieport 00:02.0 Display controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) Subsystem: ASUSTeK Computer Inc. Device 84ca 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) Subsystem: ASUSTeK Computer Inc. Device 84ca Kernel driver in use: xhci_hcd 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: ASUSTeK Computer Inc. Device 84ca 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04) Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard Kernel driver in use: e1000e 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) Subsystem: ASUSTeK Computer Inc. Device 84ca Kernel driver in use: ehci_hcd 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc. Device 8436 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) Kernel driver in use: pcieport 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) Kernel driver in use: pcieport 00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4) Kernel driver in use: pcieport 00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4) Kernel driver in use: pcieport 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) Subsystem: ASUSTeK Computer Inc. Device 84ca Kernel driver in use: ehci_hcd 00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04) Subsystem: ASUSTeK Computer Inc. Device 84ca 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) Subsystem: ASUSTeK Computer Inc. Device 84ca Kernel driver in use: ahci 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) Subsystem: ASUSTeK Computer Inc. Device 84ca 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1) Subsystem: ASUSTeK Computer Inc. Device 8390 01:00.1 Audio device: NVIDIA Corporation GF114 HDMI Audio Controller (rev a1) Subsystem: ASUSTeK Computer Inc. Device 8390 03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller Subsystem: ASUSTeK Computer Inc. Device 8488 Kernel driver in use: xhci_hcd 04:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01) Subsystem: ASUSTeK Computer Inc. Device 84b7 Kernel driver in use: ahci 05:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01) Subsystem: ASUSTeK Computer Inc. Device 84b7 Kernel driver in use: ahci
Created attachment 327168 [details] genkernel.conf used to generate/initiate build of kernel and initramfs image as you can see, mdadm is definitely enabled and the config is specified. (/etc/mdadm.conf only contains one uncommented line: dawid ~ # grep -v \# etc/mdadm.conf ARRAY /dev/md/0 metadata=1.2 UUID=78edfe95:6ce2e1af:38065b47:0cd245e7 name=dawid:0 )
Created attachment 327170 [details] /etc/default/grub domdadm is specified.
Created attachment 327172 [details] /boot/grub2/grub.cfg generated via grub2-mkconfig -o /boot/grub2/grub.cfg
(In reply to comment #7) > Created attachment 327168 [details] > genkernel.conf used to generate/initiate build of kernel and initramfs image > > as you can see, mdadm is definitely enabled and the config is specified. > > (/etc/mdadm.conf only contains one uncommented line: > > dawid ~ # grep -v \# etc/mdadm.conf > ARRAY /dev/md/0 metadata=1.2 UUID=78edfe95:6ce2e1af:38065b47:0cd245e7 > name=dawid:0 > ) i should note that i fixed this file to match the /dev/md0 references elsewhere.
1. Can you show me your partition tables on sda+sdb? sgdisk --print /dev/sda sgdisk --print /dev/sdb 2. Can you get me the FULL kernel boot output? 3. You said line 613 (/sbin/mdadm --assemble --scan) isn't running. I see that you ran with 'debug', can you please post the full debug output so we can see what other lines ARE running?
(In reply to comment #11) > 1. Can you show me your partition tables on sda+sdb? > sgdisk --print /dev/sda > sgdisk --print /dev/sdb i changed things around, i now am running two arrays. i was thinking perhaps the 3TB was causing issues. i edited mdadm.conf and updated the initramfs after i made the change but no luck. however, dawid ~ # sgdisk --print /dev/sda;sgdisk --print /dev/sdb Disk /dev/sda: 5860533168 sectors, 2.7 TiB Logical sector size: 512 bytes Disk identifier (GUID): 45204215-B368-4C5D-A14E-071F66BB4CE9 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 5860533134 Partitions will be aligned on 2048-sector boundaries Total free space is 2925 sectors (1.4 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 2930266111 1.4 TiB FD00 / 2 2930266112 5860532223 1.4 TiB FD00 /home Disk /dev/sdb: 5860533168 sectors, 2.7 TiB Logical sector size: 512 bytes Disk identifier (GUID): 23B2940E-8E2F-402A-B0A6-C9883BEAFD2B Partition table holds up to 128 entries First usable sector is 34, last usable sector is 5860533134 Partitions will be aligned on 2048-sector boundaries Total free space is 2925 sectors (1.4 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 2930266111 1.4 TiB FD00 / 2 2930266112 5860532223 1.4 TiB FD00 /home > 2. > Can you get me the FULL kernel boot output? i'd imagine i'd have to use netconsole to do that, which genkernel doesn't support, since busybox doesn't have any functional means of including any buffer output- just the logs (which i provided). > > 3. > You said line 613 (/sbin/mdadm --assemble --scan) isn't running. > I see that you ran with 'debug', can you please post the full debug output > so we can see what other lines ARE running? the output i included (the /var/log/messages) IS the full debug output. for example, Oct 22 13:55:03 dawid syslog.info syslogd started: BusyBox v1.20.2 Oct 22 13:55:03 dawid user.debug kernel: pnp 00:0c: [mem 0x20000000-0x201fffff] Oct 22 13:55:03 dawid user.debug kernel: pnp 00:0c: [mem 0x40004000-0x40004fff] Oct 22 13:55:03 dawid user.info kernel: system 00:0c: [mem 0x20000000-0x201fffff] has been reserved Oct 22 13:55:03 dawid user.info kernel: system 00:0c: [mem 0x40004000-0x40004fff] has been reserved i keep trying multiple things but it all seems to come down to mdadm in the initramfs; it's just not assembling, and yet i can assemble it absolutely fine in all the configurations i try if i manually specify mdadm --assemble --scan within busybox. however, the system still remains unbootable because at that point it's too late in the boot process to execute switch_root since it needs to run as part of init.
Have you tried telling genkernel to *not* use your mdadm.conf? (In reply to comment #12) > > 2. > > Can you get me the FULL kernel boot output? > > i'd imagine i'd have to use netconsole to do that, which genkernel doesn't > support, since busybox doesn't have any functional means of including any > buffer output- just the logs (which i provided). > mount <dev-node-of-usb-stick-or-whatever> /mnt -o rw && dmesg > /mnt/dmesg && umount /mnt > i keep trying multiple things but it all seems to come down to mdadm in the > initramfs; it's just not assembling, and yet i can assemble it absolutely > fine in all the configurations i try if i manually specify mdadm --assemble > --scan within busybox. however, the system still remains unbootable because > at that point it's too late in the boot process to execute switch_root since > it needs to run as part of init. I guess you run in the genkernel shell? Then just set up your dev-node, then enter the command "exit" (or press Ctrl-D). You should return to the "enter a valid root device" prompt. Enter the dev-node you just setup, and press enter.
(In reply to comment #13) > Have you tried telling genkernel to *not* use your mdadm.conf? not yet; i'll give that a try, but supposedly auto-assemble does not work with metadata 1.x so i have my doubts. will provide results shortly. > > mount <dev-node-of-usb-stick-or-whatever> /mnt -o rw && dmesg > /mnt/dmesg > && umount /mnt > will provide results once sysresc comes up. > > I guess you run in the genkernel shell? > Then just set up your dev-node, then enter the command "exit" (or press > Ctrl-D). You should return to the "enter a valid root device" prompt. Enter > the dev-node you just setup, and press enter. this causes a segfault at arch/x86/kernel/smp.c (will provide photo shortly)
Created attachment 329182 [details] dmesg output as far as i'm able to tell, no new info here that wasn't in the debug /var/log/messages, just minus the timestamps.
Created attachment 329184 [details] kernel panic upon exiting busybox instead of being prompted for root device
as an update, i tried building the genkernel initramfs WITHOUT the mdadm.conf (but WITH mdadm support)- same exact behavour, the array(s) never assemble automatically.
(In reply to comment #14) > (In reply to comment #13) > > Have you tried telling genkernel to *not* use your mdadm.conf? > > not yet; i'll give that a try, but supposedly auto-assemble does not work > with metadata 1.x so i have my doubts. will provide results shortly. > Well, I have used it and never had such problems, the only time you have problems with auto-assembly and metadata >=1.xx is if you run it *without* a initramfs. > > > > mount <dev-node-of-usb-stick-or-whatever> /mnt -o rw && dmesg > /mnt/dmesg > > && umount /mnt > > > > will provide results once sysresc comes up. > Sysresc? I am interested in the information that will be placed in dmesg during the boot of genkernel. So try it from the shell you got where you could run mdadm manually. > > > > I guess you run in the genkernel shell? > > Then just set up your dev-node, then enter the command "exit" (or press > > Ctrl-D). You should return to the "enter a valid root device" prompt. Enter > > the dev-node you just setup, and press enter. > > this causes a segfault at arch/x86/kernel/smp.c (will provide photo shortly) That is not a segfault in the kernel, that is a OOOPS because you try to kill the only process in userland (init). Which creates for me the question: are you still in the genkernel initramfs? Could you provide a picture of the shell you "Ctrl-D"-out from? Have the computer asked for your root-password for system maintenance? Als, please remove "root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/md0" from your /etc/default/grub. They are leftovers in the documentation from the old linux-2.4 days and are not needed with genkernel and grub2 anymore (grub2 adds itself the correct "root"-variable, and the rest is just cruft that may make 8mb of your memory unusable but nothing more).
(In reply to comment #18) > (In reply to comment #14) > > (In reply to comment #13) > > > Have you tried telling genkernel to *not* use your mdadm.conf? > > > > not yet; i'll give that a try, but supposedly auto-assemble does not work > > with metadata 1.x so i have my doubts. will provide results shortly. > > > > Well, I have used it and never had such problems, the only time you have > problems with auto-assembly and metadata >=1.xx is if you run it *without* a > initramfs. i've used it too, but not since 2.6 and never on a 3Tb drive with GPT booted via UEFI. > > > > > > > > mount <dev-node-of-usb-stick-or-whatever> /mnt -o rw && dmesg > /mnt/dmesg > > > && umount /mnt > > > > > > > will provide results once sysresc comes up. > > > > Sysresc? I am interested in the information that will be placed in dmesg > during the boot of genkernel. > So try it from the shell you got where you could run mdadm manually. > i did; i apologize, i should have clarified. i had to boot into sysresccd to recompile the initramfs as mentioned in comment #17 > > > > > > I guess you run in the genkernel shell? > > > Then just set up your dev-node, then enter the command "exit" (or press > > > Ctrl-D). You should return to the "enter a valid root device" prompt. Enter > > > the dev-node you just setup, and press enter. > > > > this causes a segfault at arch/x86/kernel/smp.c (will provide photo shortly) > > That is not a segfault in the kernel, that is a OOOPS because you try to > kill the only process in userland (init). Which creates for me the question: > are you still in the genkernel initramfs? > Could you provide a picture of the shell you "Ctrl-D"-out from? Have the > computer asked for your root-password for system maintenance? yeah, i realized it was a panic/oops, not segfault when i actually looked at it. but as far as the "enter root password for maintenance" etc., nope, never booted that far. it just sits in busybox. never seems to initialize the actual init, i would guess? i can provide a photo in a couple hours. > > Als, please remove "root=/dev/ram0 init=/linuxrc ramdisk=8192 > real_root=/dev/md0" from your /etc/default/grub. They are leftovers in the > documentation from the old linux-2.4 days and are not needed with genkernel > and grub2 anymore (grub2 adds itself the correct "root"-variable, and the > rest is just cruft that may make 8mb of your memory unusable but nothing > more). did that a bit ago, sorry for not updating the configs. but yeah, that's out. current kernel line is: linux /boot/kernel-genkernel-x86_64-3.6.6-gentoo root=/dev/md0 ro debug domdadm rootfstype=ext4
i decided to do some more testing on this in my free time today... i am now booting successfully, HOWEVER- not with genkernel (and i'd prefer to use genkernel to maintain compatibility with some other machines i have around). it seems to all boil down to the following: genkernel continues to ignore /etc/mdadm.conf that's it. there's no way to assemble an mdadm array via genkernel with any >2Tb partitions. period. (for those curious about the temporary workaround, i'm using better-initramfs with the following kernel params, which differ from genkernel's initramfs kernel params: nomodeset nosplash softraid root=/dev/md0 debug domdadm rootfstype=ext4 )
I am having similar issues BUT not identical with an 1TB striped RAID0 (ext4 /), a 0.90 superbloc, and /etc/mdadm.conf generated with mdadm --detail --scan >> /etc/mdadm.conf. Whereas genkernel-3.4.44.2 & busybox-1.21.1 build /dev/md0 during boot only while using, --domdadm --mdadm-config=/etc/mdadm.conf evoked while executing genkernel or specifying in /etc/genkernel.conf. BUT the ARRAY does not populate the partitions, i.e. /dev/md0p1 specified with the --real-root= parameter. Now with /dev/md0 available in /dev I can drop to shell, touch the array with #/ mdadm /dev/md0 which ?assembles? ARRAY /dev/md0 and populates /dev with partitions /dev/md0p[1-4]. Now, I can exit ash, and respecify the originally specified /dev/md0p1 as /root and finish booting. I tried hacking /usr/share/genkernel/defaults/linuxrc for points after mdev initialization, simply trying to envok above command... with no luck nailing it down in the sequence. I have these versions installed. =sys-boot/grub-2.0.0_p5107-r2 =sys-apps/busybox-1.21.1 =sys-fs/mdadm-3.3-r2 *static* specified in /etc/genkernel.conf,but it was built* =sys-kernel/gentoo-sources-3.11.8 =sys-kernel/genkernel-3.4.44.2 *note* >=syskernel-genkernel-3.4.45 causes PANIC instead of offering up a prompt for /root, and I found them unusable in this scenario. It might also be relevant saying that I boot off a USB key & my raid0 does not contain a boot flag simply root contained on a partition created with fdisk.
Is this still a problem with recent genkernel versions? Especially the newest 3.5.2.0-r1 which contains a much newer mdadm.
