- doesn't work w/ current kernels (multiple bugs) - no maintainer - noone w/ needed hardware volunteered apparently - according to solar, this is only useful for a couple of Dell models w/ a funky (broken) controller, the rest of people is fine w/ in-kernel stuff
(In reply to comment #0) > - doesn't work w/ current kernels (multiple bugs) > - no maintainer > - noone w/ needed hardware volunteered apparently > - according to solar, this is only useful for a couple of Dell models w/ a > funky > (broken) controller, the rest of people is fine w/ in-kernel stuff > The latest versions of this package *do* work with newer kernels (see other dmraid bugzilla reports e.g. 107826). Furthermore, AFAIK the package is required if you wish to share RAID drives between Windows/Linux under the control of several RAID chipsets: Highpoint HPT37X and HPT45X Intel Software RAID LSI Logic MegaRAID NVidia NForce RAID Promise FastTrack Silicon Image Medley VIA Software RAID The use of this package is not just for "a couple of Dell models" - see http://gentoo-wiki.com/HOWTO_Install_Gentoo_with_NVRAID_using_dmraid for an example of further uses.
(In reply to comment #1) > The latest versions of this package *do* work with newer kernels (see other > dmraid bugzilla reports e.g. 107826). Shrug. See Bug 138823 and Bug 139859, they don't.
(In reply to comment #2) > (In reply to comment #1) > > The latest versions of this package *do* work with newer kernels (see other > > dmraid bugzilla reports e.g. 107826). > > Shrug. See Bug 138823 and Bug 139859, they don't. > Bug 138823 essentially reiterates what bug 107826 is trying to address - that is dmraid versions < 1.0.0-rc11 have problems with kernel 2.6.16. As such, they (the updated dmraid package not currently in portage) do work. When an ebuild and/or genkernel is updated to use a later dmraid (http://people.redhat.com/~heinzm/sw/dmraid/) version, these problems /should/ disappear.
(In reply to comment #3) > Bug 138823 essentially reiterates what bug 107826 is trying to address - that > is dmraid versions < 1.0.0-rc11 have problems with kernel 2.6.16. > As such, they (the updated dmraid package not currently in portage) do work. No, 1.0.0_rc11 still doesn't work (see Bug 139859). > When an ebuild and/or genkernel is updated to use a later dmraid > (http://people.redhat.com/~heinzm/sw/dmraid/) version, these problems /should/ > disappear. Such as? There's no newer release than rc11. See, this is an ebuild very hard to maintain if you don't have any developer w/ a needed hardware to even test the thing.
(In reply to comment #4) > No, 1.0.0_rc11 still doesn't work (see Bug 139859). The problems witnessed in above-bug are a compile fail related to not compiling with static libs (see #14-> of 107826). On a side note (and more related to the genkernel ebuild rather than this dmraid one), there are _no problems_ with rc11 - I have modified genkernel to use the rc11 build (instead of rc10) and am now running 2.6.17 with dmraid over NVRAID. It was as easy as supplying my own updated dmraid paths in /etc/genkernel.conf: <snip> DMRAID_VER="1.0.0.rc11-pre1" DMRAID_DIR="dmraid/1.0.0.rc11" DMRAID_SRCTAR="/root/build_dir/dmraid/dmraid-${DMRAID_VER}.tar.bz2" DMRAID_BINCACHE="%%CACHE%%/dmraid-${DMRAID_VER}-%%ARCH%%.tar.bz2" </snip> Note you will need to modify the DMRAID_SRCTAR to reflect where you have manually downloaded the tarball to.
FWIW, it should also be mentioned that without DMRAID, it's not possible to share the RAID space with other operating systems. I currently quad-boot my RAID-0 array with Win2k, WinXP, FreeBSD 6.1, and Gentoo. If I were to use in-kernel RAID for my array, it would be *useless* to the other OS's, and not to mention, unbootable. DMRAID arrays are bootable and do not require a seperate boot disk/partition as in-kernel RAID-0 does. Also, I would tend to argue the point that no developer has the hardware to test this. Unwilling or unable due to other commitments, yes. But nearly all motherboards of recent vintage have one of these SATA controllers and this capability.
Solar, does the in kernel stuff work for this or is comment #6 correct?
comment #6 is correct. keeping dmraid would be useful. I just can't personally maintain it anymore on good faith.
I will defer this then.
releng do you use this?
*sigh* livecd != releng Anyway, we pull in the package on our own and compile it within genkernel... we *would* use this, if there had ever been a stable version in the tree. I personally do not use this (and being the only member of the livecd herd) so I cannot maintain it. I don't even have compatible hardware, as I'm a SCSI guy.
Users - I sent a mail to -dev on 7/17, it's been two weeks and still no volunteers. So this is slated for removal. once the ebuild is out of the tree; feel free to put it into sunrise if you are interested in keeping it up to date since it seems many of you are. Once the ebuild has been pulled from cvs the files will live on the the gentoo mirrors for ~2 weeks until the mirror-dist script removes them, so make sure you fetch anything you want before then.
Ok this is seriously screwed up, why the hell remove a package that is used by quite a few people and without it a machine is rendered useless? There are quite a few people who are willing to test this package since no devs seem to have the hardware. I am an AT and willing to test this package at any time, sys-fs/dmraid-1.0.0_rc11-r1 works fine and should have been added to the tree months ago. This is a sad sad day.
(In reply to comment #13) > Ok this is seriously screwed up, why the hell remove a package that is used by > quite a few people and without it a machine is rendered useless? There are Umm... it doesn't render a machine useless, in any way. The installation media doesn't have the dmraid tools, and it works just fine with dmraid, as we have the proper things in the initrd. If you're using genkernel, it all works just fine. If you're not, well, that's not Release Engineering's problem. ;] > quite a few people who are willing to test this package since no devs seem to > have the hardware. I am an AT and willing to test this package at any time, > sys-fs/dmraid-1.0.0_rc11-r1 works fine and should have been added to the tree > months ago. The problem isn't testing it nearly as much as maintaining it. Though, personally, I refuse to become the maintainer of anything that I cannot test, otherwise I would have grabbed it up for the "livecd" herd long ago (and I'm the only person maintaining that herd of packages). If you want to see the package stick around, find a developer willing to maintain it, even if they just proxy maintain it for you.
I cannot proxy maintain this (as the mailing list requested) because I don't have any hardware to test it with. I may get some later this year after tuition is paid for (maybe nforce) and it would be useful then.
DOn't remove dmraid. I use it! I'm using 2.6.17 on nForce4 with 1.0.0_rc11 and it does work just fine for me on my SATA RAID-0 setup. The only problem is that the latest version in portage is out of date. It just needs updated with rc11.
(In reply to comment #16) > DOn't remove dmraid. I use it! I'm using 2.6.17 on nForce4 with 1.0.0_rc11 and > it does work just fine for me on my SATA RAID-0 setup. The only problem is that > the latest version in portage is out of date. It just needs updated with rc11. > only the in-tree dmraid is going away..the dmraid driver will be in kernel from now on...
Care to pause the removal of this ebuild from portage for a few weeks till I become a dev? I'll maintain it. If you feel that you _need_ to remove from tree then feel free, but it will re-appear soon enough. Thanks, Ahmed
yes
Please dont remove the dmraid from portage, because I have a Problem, that was non mentioned so far: I have a on board ICH5 Chipset having a striped raid and a pci card with the SiI3112 chipset having a mirrored raid set with my linux on. While booting just the partitions of the SiI3112 can be found in /dev/mapper: # ls -Al /dev/mapper/ total 0 crw-rw---- 1 root root 10, 63 Aug 16 08:08 control brw------- 1 root root 253, 0 Aug 16 08:08 sil_agaedhbgdcai brw------- 1 root root 253, 1 Aug 16 08:08 sil_agaedhbgdcai1 brw------- 1 root root 253, 7 Aug 16 08:08 sil_agaedhbgdcai10 brw------- 1 root root 253, 8 Aug 16 08:08 sil_agaedhbgdcai11 brw------- 1 root root 253, 2 Aug 16 08:08 sil_agaedhbgdcai5 brw------- 1 root root 253, 3 Aug 16 08:08 sil_agaedhbgdcai6 brw------- 1 root root 253, 4 Aug 16 08:08 sil_agaedhbgdcai7 brw------- 1 root root 253, 5 Aug 16 08:08 sil_agaedhbgdcai8 brw------- 1 root root 253, 6 Aug 16 08:08 sil_agaedhbgdcai9 So I always have to activate the intel devices manually by # dmraid -ay sil_agaedhbgdcai already active sil_agaedhbgdcai1 already active sil_agaedhbgdcai5 already active sil_agaedhbgdcai6 already active sil_agaedhbgdcai7 already active sil_agaedhbgdcai8 already active sil_agaedhbgdcai9 already active sil_agaedhbgdcai10 already active sil_agaedhbgdcai11 already active After that are all partitions exist and can be mounted. # ls -Al /dev/mapper/ total 0 crw-rw---- 1 root root 10, 63 Aug 16 08:08 control brw------- 1 root root 253, 9 Aug 16 10:35 isw_cbhaddaghb_Meins brw------- 1 root root 253, 10 Aug 16 10:35 isw_cbhaddaghb_Meins1 brw------- 1 root root 253, 11 Aug 16 10:35 isw_cbhaddaghb_Meins5 brw------- 1 root root 253, 12 Aug 16 10:35 isw_cbhaddaghb_Meins6 brw------- 1 root root 253, 13 Aug 16 10:35 isw_cbhaddaghb_Meins7 brw------- 1 root root 253, 0 Aug 16 08:08 sil_agaedhbgdcai brw------- 1 root root 253, 1 Aug 16 08:08 sil_agaedhbgdcai1 brw------- 1 root root 253, 7 Aug 16 08:08 sil_agaedhbgdcai10 brw------- 1 root root 253, 8 Aug 16 08:08 sil_agaedhbgdcai11 brw------- 1 root root 253, 2 Aug 16 08:08 sil_agaedhbgdcai5 brw------- 1 root root 253, 3 Aug 16 08:08 sil_agaedhbgdcai6 brw------- 1 root root 253, 4 Aug 16 08:08 sil_agaedhbgdcai7 brw------- 1 root root 253, 5 Aug 16 08:08 sil_agaedhbgdcai8 brw------- 1 root root 253, 6 Aug 16 08:08 sil_agaedhbgdcai9 There is more that I need as the dmraid that is shipped with genkernel. I have to execute dmraid from the portage tree manually after every boot!
> There is more that I need as the dmraid that is shipped with genkernel. I have > to execute dmraid from the portage tree manually after every boot! This is the reason I need it, too. Unless there is another way that I'm not aware of....
Hey I need this dmraid I have a Sil3112 chipset and have XP already running on RAID0. In addition to those who alread said they need it and will test it, I can test it too. Please keep me in the email loop if you need someone. I've used Ubuntu and it could detect the fakeraid through dmraid.
the "mail loop" is the CC of this bug, which you can add yourself to :P
I dont think this should disappear either. Please keep it in portage! I updated bug 107826 and also got sys-fs/dmraid into the portage-review sunrise overlay (to comply with maintainer-needed status)
(In reply to comment #24) > I dont think this should disappear either. Please keep it in portage! > > I updated bug 107826 and also got sys-fs/dmraid into the portage-review sunrise > overlay (to comply with maintainer-needed status) > Enough Me Too comments! The bug is not assigned to treecleaners, this package is waiting for Ahmed Ammar to become a developer. You don't need to post your comments on how you love DMraid long time. Feel free to add yourself to the CC if you are concerned about this packages.
Isn't the package being in sunrise a violation of their "don't put junk that's in the tree" policy, or am I mistaken? Anyway, removing release@ since I'm sick of the bug spam.
(In reply to comment #26) > Isn't the package being in sunrise a violation of their "don't put junk that's > in the tree" policy, or am I mistaken? Yeah, ebuilds already in the tree are prohibited from being in Sunrise. It's maintainer-wanted only, not maintainer-needed. http://www.gentoo-sunrise.org/sunrise/wiki/SunriseFaq#Howareyouensuringthatthereisnob0rken/maliciuscodegettingintotheoverlay Ian can you get it taken back out?
(In reply to comment #27) > (In reply to comment #26) > > Isn't the package being in sunrise a violation of their "don't put junk that's > > in the tree" policy, or am I mistaken? > > Yeah, ebuilds already in the tree are prohibited from being in Sunrise. It's > maintainer-wanted only, not maintainer-needed. > > http://www.gentoo-sunrise.org/sunrise/wiki/SunriseFaq#Howareyouensuringthatthereisnob0rken/maliciuscodegettingintotheoverlay > > Ian can you get it taken back out? > Then it needs to be added to the official portage tree.
It _is_ in the tree, just package masked. Until it's fixed it can't be let loose. Maybe Alec can update the mask info so it doesn't say it's being removed, just temporarily out of service.
(In reply to comment #29) > It _is_ in the tree, just package masked. Until it's fixed it can't be let > loose. Maybe Alec can update the mask info so it doesn't say it's being > removed, just temporarily out of service. > Updated, thanks.
(In reply to comment #29) > It _is_ in the tree, just package masked. Until it's fixed it can't be let > loose. Maybe Alec can update the mask info so it doesn't say it's being > removed, just temporarily out of service. Oh, I was talking about rc11, found in bug #107826
genstef, the other fellow was close to finishing his dev stuff up...did that get delayed?
I'm just interim (i mean, im not a dev).. It shouldn't be an issue to switch this out of social workspaces once he's done?
well, I reassigned it to Ian since he took care of getting a version bump into shape and committed to portage through sunrise. If the other guy wants to take over - no problem with me :)
Back to the original issue (sorta), now that we have -rc12, and since -rc8 is no longer provided by upstream (or at least the src_uri is wrong), could someone trim the dmraid-1.0.0_rc8-r1.ebuild from the tree?
(In reply to comment #35) > Back to the original issue (sorta), now that we have -rc12, and since -rc8 is > no longer provided by upstream (or at least the src_uri is wrong), could > someone trim the dmraid-1.0.0_rc8-r1.ebuild from the tree? > Done, changelog'd metadata.xml updated (there is no maintainer-needed herd!). Genstef, if you are proxying for him I'd prefer to see you in metadata.xml as well. Do we have any policy on that? (nice to have someone within gentoo to poke ;P).
As this won't be removed, I'm closing this bug. Any new issues -> file a new bug. Thanks.
CLOSED.
(In reply to comment #36) > Done, changelog'd metadata.xml updated (there is no maintainer-needed herd!). why not, how can I create a herd? > Genstef, if you are proxying for him I'd prefer to see you in metadata.xml as > well. Do we have any policy on that? (nice to have someone within gentoo to > poke ;P). nah, I just committed it because he cared about it. If people care about stuff and I am allowed to I usually commit it :)
(In reply to comment #39) > (In reply to comment #36) > > Done, changelog'd metadata.xml updated (there is no maintainer-needed herd!). > > why not, how can I create a herd? > > > Genstef, if you are proxying for him I'd prefer to see you in metadata.xml as > > well. Do we have any policy on that? (nice to have someone within gentoo to > > poke ;P). > > nah, I just committed it because he cared about it. If people care about stuff > and I am allowed to I usually commit it :) > So...you don't have any way to test it?
Its good, that dmraid is in portage again. It works fine and im glad. I dont know, if I really still need it as you can see: Because there is no place in the net, where you can read how to get 2 chipsets by dmraid initialized at boot, and because I've seen on this page at least one Person having the same problems like me, I write how I did it (I know its not the best place for it). This is my new starting line in grub, that first says "load dmraid" (dodmraid), after that "check for devices"(dmraid=-r), after that "initialize devices"(dodmraid=-ay), and because THIS fails at me regularly I explicitly want dmraid to initialize all sil and isw based mappings. You have to change this to your device names! title=Gentoo Linux (2.6.17-gentoo-r8) root (hd0,6) kernel /kernel-genkernel-x86-2.6.17-gentoo-r8 root=/dev/ram0 init=/linuxrc real_root=/dev/mapper/sil_agaedhbgdcai6 dodmraid dodmraid=-r dodmraid=-ay dodmraid=-ay sil dodmraid=-ay isw initrd (hd0,6)/boot/initramfs-genkernel-x86-2.6.17-gentoo-r8 I already tried that before, but without success. So I really wondered that it worked today. But to get sure that it _really always_ gets loaded I wrote some lines into my /etc/bash/bashrc: #Create Device Nodes sil* using dmraid for root if [ ${EUID} == 0 ] && [[ ! -b /dev/mapper/sil_agaedhbgdcai ]]; then echo "\nInitialize /dev/mapper/sil_agaedhbgdcai" /usr/sbin/dmraid -ay sil mount -a fi #Create Device Nodes isw* using dmraid for root if [ ${EUID} == 0 ] && [[ ! -b /dev/mapper/isw_cbhaddaghb_Meins ]]; then echo "\nInitialize /dev/mapper/isw_cbhaddaghb_Meins" /usr/sbin/dmraid -ay isw mount -a fi
...so..why is this reopened again? (i can't remember and there doesn't seem to be anything in the bug's history..) ..and while i'm at it -- could the hard mask be removed or at least changed to state just this bug (since the others have been resolved)?
(In reply to comment #42) > ...so..why is this reopened again? (i can't remember and there doesn't seem to > be anything in the bug's history..) > > ..and while i'm at it -- could the hard mask be removed or at least changed to > state just this bug (since the others have been resolved)? > This needs to stay reopened till a new Live/install CD that works for us Dual-booters and needs dmraid back into the initrd with the proper versions, hard masking the working versions doesn't speed up creating a 2006.15 release. Just my thoughts as I've been beating my head for almost a week googling all over the place trying to understand why my new NF590 raid0 not initialize the arry, plus no 'dmraid' exe to run to learn how to do it manually. I found no wiki's on this, nothing. Sorry if this is a rant, but a lot of time has been wasted, thinking it was MY fault.
(In reply to comment #43) I don't think i follow.. Genkernel (and hence the livecd) has its own dmraid, which (unfortunatley imo) has nothing to do with this package (see comment #14). Also, i think removing the hard mask would make sense given what you just described. And since we've more or less decided to keep the package and leave it maintainer-needed until a dev decides to take it over (how's that coming btw??) i dont see a point in this being open anymore either (back to comment #37). The lack of documentation on dmraid issues is a problem, but thats not what this bug is supposed to be for :) Mayhaps i'll add a gentoo-wiki page this week.. So, uhh, yeah.. Alec? can i close it again? RESOLVED/WONTFIX?
*** Bug 169892 has been marked as a duplicate of this bug. ***
wont get removed because the treecleaners project is dead, I also removed the bogus package.mask
(In reply to comment #46) > wont get removed because the treecleaners project is dead, I also removed the > bogus package.mask Uhhhh, what?
