Hi, new ebuild for dmraid-1.0.0_rc9
Created attachment 69671 [details] dmraid/dmraid-1.0.0_rc9.ebuild
Why does your ebuild add libselinux as a dep?
Ahh I kinda see why you add that now. It's dumb that it hard forces linking to the lib as it would pretty much go unused. So as it stands I have no plans to add a new dmraid to the tree at this time by me as long as it depends on libselinux. Changing owner to maintainer-wanted
This package really deserves some attention. Motherboards with this capability are now a dime a dozen...
Then talk to upstream and get them to not force linking to libselinux.
Well since I most likely don't have that kind of influence, are there any other alternatives we could consider? I'm a dummy when it comes to this topic, so I don't understand the complexity related with forced linking to selinux, but obviously it's a pain. So is this a rock and a hard place?
You could always add it to a local overlay.
*** Bug 125380 has been marked as a duplicate of this bug. ***
Created attachment 84394 [details] dmraid-1.0.0_rc10.ebuild Here's an ebuild for rc10 it also needs a minor patch dmraid-1.0.0-rc10-asr-make.patch libselinux is now optional so hopefully this will make the gentoo devs happy I was hoping this would fix the partitioning problem seen with 2.6.16, (the main drive node is created but not the partition nodes at the initramfs stage) but it's still no different yet so back to 2.6.15 for the time being
Created attachment 84395 [details] dmraid-1.0.0-rc10-asr-make.patch minor patch to avoid an error during compile of rc10
Richard: thanks for the ebuild. I had been using a quick'n'dirty version that didn't deal with libselinux and --enable-shared_lib very well (only static was working). Here is the 2.6.16 and dmraid bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186842 May be OT, but I figured this info would probably be of interest to this bug...once a patch/fix is available there, we can work on getting it into the ebuilds.
thanks for the link, spotted it on a couple of other bugs related to dmraid dropping into a shell within the initramfs image dmraid -ay gives "ERROR: dos: reading /dev/mapper/nvidia_cadcdfaj[No such file or directory]" calling dmsetup directly within the initramfs with the table "echo "0 290452220 striped 2 128 8:0 0 8:16 0" | dmsetup create nvidia_cadcdfaj" gives "device-mapper: reload ioctl failed: invalid argument" looking at dmesg "device-mapper: dm-stripe: Target length not divisible by chunk size device-mapper: error adding target to table" so Yep it does look as if it's the same problem it looks as if the kernel devs have added a new restriction for 2.6.16 for the device-mapper stripe target, that the total raid volume size has to be a multiple of the chunk size (which kind of makes sense) if I reduce the total volume size to the nearest multiple of the chunk 290452220 -> 290452096 for a chunk size of 128 sectors (64K) (probably better to go under rather than over to avoid crossing into the raid metadata region) I can manually map it via dmsetup for the overall stripe "echo "0 290452096 striped 2 128 8:0 0 8:16 0" | dmsetup create nvidia_cadcdfaj" looking at the last partition on the disk under 2.6.15 / dmsetup table "nvidia_cadcdfaj6: 0 142978437 linear 253:0 147460698" 142978437 + 147460698 = 290439135 which I believe should be the last sector for the last partition, so this should easily fall within the stipe mapping so it looks as if dmraid just needs to round down the number to the nearest multiple of the chunk size when creating the stripe map
it looks as if a preliminary version of a rc11 binary was released on the bug link mentioned before extracted the binary from the rpm using rpm2targz (64bit) and swapped the static binary around with the one in the initramfs image seems to work okay (using 2.6.16 to type this at the moment) seems to work for some users but not others
Created attachment 84993 [details] hack ebuild for testing dmraid-rc11-pre1 Here is a hack-ish ebuild (based on Richard's rc10 version) to facilitate testing the new rc11_pre1 release, now that the source has also been released (see RedHat bug above). I ran into some issues - I made an rc11-compatible version of the previous patch (removes asr.c from Makefile, iirc), but this now creates breakage later on during compilation. The only way I can get rc11-pre1 to compile is with USE="static" (--enable-static_link) and without the asr patch. If people are interested, we could start a seperate bug and attempt to send some meaningful debugging info upstream (on compilation problems & 2.6.16 bug). Not sure if this version fixes the 2.6.16 bug for me (havent tested it in an initrd yet), but I figured I'd pass it along for others for testing. devs: is there a chance of getting Richard's rc10 ebuild into portage, even if its hardmask or w/o keywords? It appears to solve the initial dilemma w/forced libselinux linking.
(In reply to comment #14) > Created an attachment (id=84993) [edit] > hack ebuild for testing dmraid-rc11-pre1 This ebuild works fine, although would need a clean-up before allowing into portage. I have been testing this version for weeks and is stable.
(In reply to comment #15) > (In reply to comment #14) > > Created an attachment (id=84993) [edit] > > hack ebuild for testing dmraid-rc11-pre1 > > This ebuild works fine, although would need a clean-up before allowing into > portage. I have been testing this version for weeks and is stable. > Not for me. Same breakage during compilation as above.
> > Not for me. Same breakage during compilation as above. > USE="static -selinux"
We don't install dmraid on the release media... genkernel uses its own built-in dmraid. Removing release@ until such time as there's an actual stable version of dmraid and we actually use it.
I've tried to use a newer version of dmraid (1,0.0-rc11) with genkernel and gen2dmraid. It built just fine but doesn't work then.
(In reply to comment #19) > I've tried to use a newer version of dmraid (1,0.0-rc11) with genkernel and > gen2dmraid. It built just fine but doesn't work then. > Yeah thats what I mean and I experienced so far.
The rc11 ebuild worked fine for me. I didn't know that dmraid didn't work with kernels after 2.6.15 until just recently, so I thought I didn't know what I was doing with setting up my nvraid. But then I was informed that I needed rc11, so I looked for it here, found it, installed it and it worked just fine. No my nvraid works!!!! The ebuild needs to be clean up a bit (the SRC_URL has changed) and added to the official portage tree.
**Now my nvraid works!!! (typo)
dmraid-1.0.0-rc11 doesn't build for me. I had to hack the ebuild to get the source to download as it has now moved. SRC_URI="http://people.redhat.com/~heinzm/sw/dmraid/tst/old/dmraid-1.0.0.rc11-pre1.tar.bz2" none-the-less compiling failed with the following error: format/ataraid/asr.o: In function `register_asr': asr.c:(.text+0x2280): multiple definition of `register_asr' format/ataraid/asr.o:asr.c:(.text+0x2280): first defined here collect2: ld returned 1 exit status make[1]: *** [../lib/libdmraid.so] Error 1 make[1]: Leaving directory `/var/tmp/portage/dmraid-1.0.0_rc11/work/dmraid/1.0.0.rc11/lib' make: *** [lib] Error 2 !!! ERROR: sys-fs/dmraid-1.0.0_rc11 failed.
Ok. I can confirm it *does* compile for me also provided I use USE="static" and it works! I can see my parititions from the Promise raid card again.Thank you!
Created attachment 94941 [details] dmraid-1.0.0_rc11-asr-make.patch asr-make.patch updated for the _rc11 ebuild
Created attachment 94942 [details] dmraid-1.0.0_rc11-man-make.patch Patch to fix install locations for info/man pages (for switch from einstall to emake)
Created attachment 94944 [details] dmraid-1.0.0_rc11.ebuild (less hacked) This is an attempt to clean up the ebuild: - Files install in their stock locations - The asr-make.patch applies iff USE="-static" (and both ways compile/run fine afaict) [see attachment 94941 [details] for the patch] - Uses emake instead of einstall [see attachment 94942 [details] for patch] - Added a 'genkernel' use flag which installs the distfile to /usr/share/genkernel/pkg/ and adds comments to genkernel.conf for what to change to get genkenrel to use this package instead of its internal dmraid package (thanks to David Helstroom, 5th comment in bug 139860) Im trying to get this into sunrise, apparently the devs will allow us to maintain the package in portage through that (here's hoping).. Oh, and despite the name, this ebuild is for -rc11-pre1 as well.. I dropped -pre1 as apparently older portage versions don't work well with multiple local version specifications?
Now in the sunrise overlay: http://gentoo-sunrise.org/svn/portage-review/sys-fs/dmraid/
Messed up the 'genkernel' use flag implementation, fixed now on portage-review (revision >=1014)
version -rc12 in portage, marking resolved.
There is released new version of that package
Yep they have -- see bug #153819
dmraid is way beyond this version now -- closing bug. See bug #153819 (and future bugs) for newer versions.