Greetings,
I've been working on a feature to add DDF container support using mdraid to Anaconda. It should be building on the work done to support IMSM containers using mdraid instead of dmraid. I've been hoping to have a patch ready already, but I'm running into some problems related to differences in how metadata for the two container formats is exposed. This is also the first time I've worked on Anaconda so am still familiarizing myself with the codebase. For IMSM, Anaconda has a udev rule that gets a value for MD_DEVICES:
ENV{ID_FS_TYPE}=="isw_raid_member", IMPORT{program}="$env{ANACBIN}/mdadm --examine --export $tempnode"
Alas, for DDF, the same rule doesn't get a value for MD_DEVICES. One can get this information for DDF by first doing "mdadm -A -e ddf --scan". Subsequently, "mdadm --detail --export /dev/md127" will give MD_DEVICES. However, it seems to me to be a poor practice to assemble any arrays in 70-anaconda.rules. Besides, while testing, Anaconda seems not to like this in there anyway:
ENV{ID_FS_TYPE}=="ddf_raid_member", RUN+="$env{ANACBIN}/mdadm -A -e ddf --scan"
KERNEL=="md[0-9]*|md_d[0-9]*|md/*", IMPORT{program}="$env{ANACBIN}/mdadm --detail --export $tempnode"
It interferes with Anaconda accessing the array with mdadm, causing Anaconda to hang indefinitely.
Might anyone with more Anaconda development experience have suggestions for where to try collecting this one piece of information?
--Jared
--
Jared Dominguez
Linux Engineering
Dell | Enterprise Product Group
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
