As udev fires up before virtually anything else, mdadm's rules comes to play and are trying to assemble raids (which is not wanted behavior in many cases). For example, sometimes I end up with: tazik ~ # cat /proc/mdstat Personalities : [raid1] [raid10] md126 : inactive sdc4[2](S) sdd4[3](S) 3820837040 blocks super 1.2 md127 : inactive sdb4[1](S) sda4[0](S) 3820837040 blocks super 1.2 instead of md4 raid10 assembled from all of 4 disks. When I remove this rules file, mdraid actually comes to play and does job properly every time. Suggested fix - add udev use flag to mdadm, leave it enabled by default to not affect any users relaying on these rules.
pretty sure the current udev rule structure allows you to add your own stuff to /etc/udev/rules.d/ that'd cause the system ones to get ignored. i don't see that being any more/less work than a udev USE flag.
Correct. Make sure you have not removed any rules files, then touch a file in /etc/udev/rules.d with the same name as the rules file you want to ignore. Once you have done this, please report back to the bug and let us know if the rules are ignored.
Yes, can ignore etc. But if you want always install these rules, you can safely remove mdraid script - it's not beeing used at all.
the mdraid init.d script might be largely unused in the udev/kernel hotplugging setup, but it still can be used by non-udev setups, or people who disable the udev rules because they don't like them
udev rule file name is 64-md-something. I'm 101% sure that this name will be changed in future to e.g. 65-md-something, so blacklisting it in /etc isn't really good idea. Please don't resolve with worksforme unless you can add any single cons for +udev flag.
sorry, but no. the unlikely chance of a rename isn't sufficient for adding a USE flag. if you're overly paranoid, then use per-package env and INSTALL_MASK.
Again, you did not show me single possible issue which can be caused by this change. You are too lazy to make changes to ebuild? I can do them. And it is bug - it doesn't work in the current state. Creating override in etc and praying rules file name will not change isn't way to go for any sane user. You are telling me mdraid init script will be used on udevless systems. OK. But why they need udev rules on this udevless system?
Gentoo has already agreed to avoid USE flags that only control optional config files. i guess you never noticed that things like xinetd/logrotate/bash-completion files always get installed even though you never use those. if you think the udev rules are broken for everyone, then feel free to report it to upstream. i'd also highlight the comment from the rules file itself: # remember you can limit what gets auto/incrementally assembled by # mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
It's not config file, it's script which goes to /lib. Where did you found those comments? -----------------------------------> tazik ~ # cat 64-md-raid.rules # do not edit this file, it will be overwritten on update SUBSYSTEM!="block", GOTO="md_end" # handle potential components of arrays ENV{ID_FS_TYPE}=="linux_raid_member", ACTION=="remove", RUN+="/sbin/mdadm -If $name" ENV{ID_FS_TYPE}=="linux_raid_member", ACTION=="add", RUN+="/sbin/mdadm --incremental $env{DEVNAME}" # handle md arrays ACTION!="add|change", GOTO="md_end" KERNEL!="md*", GOTO="md_end" # partitions have no md/{array_state,metadata_version}, but should not # for that reason be ignored. ENV{DEVTYPE}=="partition", GOTO="md_ignore_state" # container devices have a metadata version of e.g. 'external:ddf' and # never leave state 'inactive' ATTR{md/metadata_version}=="external:[A-Za-z]*", ATTR{md/array_state}=="inactive", GOTO="md_ignore_state" TEST!="md/array_state", GOTO="md_end" ATTR{md/array_state}=="|clear|inactive", GOTO="md_end" LABEL="md_ignore_state" IMPORT{program}="/sbin/mdadm --detail --export $tempnode" ENV{DEVTYPE}=="disk", ENV{MD_NAME}=="?*", SYMLINK+="disk/by-id/md-name-$env{MD_NAME}", OPTIONS+="string_escape=replace" ENV{DEVTYPE}=="disk", ENV{MD_UUID}=="?*", SYMLINK+="disk/by-id/md-uuid-$env{MD_UUID}" ENV{DEVTYPE}=="disk", ENV{MD_DEVNAME}=="?*", SYMLINK+="md/$env{MD_DEVNAME}" ENV{DEVTYPE}=="partition", ENV{MD_NAME}=="?*", SYMLINK+="disk/by-id/md-name-$env{MD_NAME}-part%n", OPTIONS+="string_escape=replace" ENV{DEVTYPE}=="partition", ENV{MD_UUID}=="?*", SYMLINK+="disk/by-id/md-uuid-$env{MD_UUID}-part%n" ENV{DEVTYPE}=="partition", ENV{MD_DEVNAME}=="*[^0-9]", SYMLINK+="md/$env{MD_DEVNAME}%n" ENV{DEVTYPE}=="partition", ENV{MD_DEVNAME}=="*[0-9]", SYMLINK+="md/$env{MD_DEVNAME}p%n" IMPORT{program}="/sbin/blkid -o udev -p $tempnode" OPTIONS+="link_priority=100" OPTIONS+="watch" ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}" ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*", SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}" LABEL="md_end" <----------------------------------- OK. You do not want to fix this. In this case: -----------------------------------> pkg_postinst() { elog "If using baselayout-2 and not relying on kernel auto-detect" elog "of your RAID devices, you need to add 'mdraid' to your 'boot'" elog "runlevel. Run the following command:" elog "rc-update add mdraid boot" } <----------------------------------- from mdadm ebuild lies. It "forgets" to mention that if you are running udev (and most system are), you do not need to add mdraid as it'll have no effect at all.
(In reply to comment #9) > It's not config file, it's script which goes to /lib. It is a config file and the way it works you put the overriding rules to /etc/udev/rules.d instead of altering the ones in /lib.
my quote is from the rules from mdadm-3.2.3 which is now in ~arch we're done here
It's udev script which (in this case) alters system behavior significantly. Installing bash-completion extension which will not be used is one thing, installing udev rule set (bad one, I might add) which will be used and render other parts of the same package unusable (mdraid init script e.g.) is another.
again, we've listened to your request, and provided *many* ways to accomplish what you want to do. if you have improvement suggestions for the udev rules, then send an e-mail to the mdadm maintainer. but we're not adding a USE flag to control the installation of this file. stop re-opening the bug w/out new information.
We are not done here. What I see is developer who doesn't want to improve quality of distro. Also, on synced second ago portage: ----> tazik ~ # cat /var/portage/tree/sys-fs/mdadm/mdadm-3.2.3.ebuild | grep KEYWORDS #KEYWORDS="~alpha ~amd64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sparc ~x86" <----
I see problem, I see no reasons not to fix it. I do not want workaround while it can be fixed properly, thank you.
userrel: you requested i cc you in the future rather than just trying to shut down the bug. can you take care of this please ?
Also, I checked mdadm-3.2.3 tarball and can't find these comments there as well. It's either I'm blind or...?
(In reply to comment #15) > I see problem, I see no reasons not to fix it. I do not want workaround while > it can be fixed properly, thank you. Andrew, your bug report was read and your opinion noted. Several developers have presented alternatives to you and explained why the udev rule file is installed. You may not like nor agree with the final decision, but the final decision is up to the package maintainers. Please use one of the alternatives listed here. PS - If you have any further questions or comments about this issue, please email us to userrel@g.o and not to this bug report.
