Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Hi,

new ebuild for dmraid-1.0.0_rc9

Created an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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] [details]
> 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] [details]
> > 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 an attachment (id=94941) [details]
dmraid-1.0.0_rc11-asr-make.patch

asr-make.patch updated for the _rc11 ebuild

Created an attachment (id=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 an attachment (id=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.