Summary: | sys-kernel/genkernel-3.4.10.907 mdadm in genkernel does not compatible with sys-fs/mdadm-3.1.4, unbootable system | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Artem V. Ryabov <avryabov> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | alexander |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Artem V. Ryabov
2011-06-22 11:09:17 UTC
Do you run into the same problem with genkernel 3.4.16, too? With genkernel 3.4.16 my system is boot. But not clean. mdadm assemble my arrays with another numbers then my default: /dev/md126 and /dev/md127 (my /dev/md1 and /dev/md2) vg on /dev/md127 was found, system is boot successful. But /boot not mounted becose in fstab: /dev/md1 /boot ext2 noatime 1 2 I think, in other cases, when real root will be on /dev/mdxx, not on vg, system will be unbootable. (In reply to comment #2) > With genkernel 3.4.16 my system is boot. > > But not clean. > mdadm assemble my arrays with another numbers then my default: > /dev/md126 and /dev/md127 > (my /dev/md1 and /dev/md2) > vg on /dev/md127 was found, system is boot successful. > > But > /boot not mounted > becose in fstab: > /dev/md1 /boot ext2 noatime 1 2 > > I think, in other cases, when real root will be on /dev/mdxx, not on vg, system > will be unbootable. This is somewhat expected with newer versions of mdadm. I would advice you to hack your mdadm.conf to create the expected devnodes (or use the ones in /dev/md/ which are supposed to be consistive and the "new" /dev/md*), use label or use uuid for mounting... Genkernel parameter --mdadm-config= could be of use to this. Would it not be better to include the "--mdadm-config=/etc/mdadm.conf" as default when using "genkernel --mdadm" ? This would avoid future problems when user forget to use the "--mdadm-config=/etc/mdadm.conf". (In reply to comment #5) > Would it not be better to include the "--mdadm-config=/etc/mdadm.conf" as > default when using "genkernel --mdadm" ? > This would avoid future problems when user forget to use the > "--mdadm-config=/etc/mdadm.conf". No, a broken/empty /etc/mdadm.conf would kill that boot, and there are a number of reasons why we want autodetect as default. Also, autodetect *should* create sane defaults. The problem here is that upstream has gone from having a somewhat persistant /dev/md* to a somewhat persistant /dev/md/* instead. And they really urge people to use /dev/md/<name>, LABEL or UUID when addressing or mounting a raid, as a dynamic /dev has to much troubles with everything else. Do you use devtmpfs? Which version of the nodes does it create? (In reply to comment #0) > New version mdadm create /etc/mdadm.conf in incompatible format: > ARRAY /dev/md/1 metadata=0.90 UUID=60f4438a:3a7387cc:cb201669:f728008a > ARRAY /dev/md/2 metadata=0.90 UUID=bb0fb0ee:41a37b79:cb201669:f728008a I think this is an effect of use an old udev with devfs-compat enabled, and not an mdadm issue. Am I right? No response from user in 3+ years. |