Hi, When booting my nForce raid5'd system from the 2007.0 livecd, I am unable to mount my raid volume. The issue appears to be an incompatibility between the kernel module the dmraid binary expects to find (raid45.ko) and the module actually present to handle raid5 (raid456.ko). The key error experienced is: # dmraid -ay ERROR: device-mapper target type "raid45" not in kernel These Ubuntu topics contain reports essentially identical to my experience: http://ubuntuforums.org/archive/index.php/t-401295.html https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655 Reproducible: Always Steps to Reproduce: 1. Create a raid5 nvraid volume using BIOS or Windows raid management 2. Boot 2007.0 livecd with the "dodmraid" parameter Actual Results: ERROR: device-mapper target type "raid45" not in kernel Expected Results: The raid volume should appear as a block device in /dev/mapper/ (ie, nvidia_foo) which can be fdisked/partitioned/mounted
I believe this has been fixed in SVN.
*** Bug 217196 has been marked as a duplicate of this bug. ***
Can someone verify if this is still an issue with 2008.0_beta2?
(In reply to comment #3) > Can someone verify if this is still an issue with 2008.0_beta2? Verified. This is still an issue. With "dodmraid" added to the kernel options, the same error in the original report is seen. The error also occurs after the GUI is loaded, so this isn't just a initramfs issue. My previous diagnosis relating to raid456.ko was incorrect, also. raid456.ko is part of mdraid, not dmraid. The two are incompatible (at present). There has been a device-mapper version of raid45.ko out there somewhere for some time now, but I'm not sure what it's status is. Redhat's dmraid pages seem stagnant. Regards, Sam
Shoot, sorry. I just realized I downloaded and burned beta1. Let me find beta2. My apologies. Regards, Sam
Um. I have no idea how to get beta2 happening here. I'll wait until it hits the mirrors and/or BT. Sorry again. Regards, Sam
That *should* have said Beta 1, but Beta 2 should be hitting the mirrors in the next couple days. Please try that, when you get the chance. It's the same module, I think. The raid456 module *used* to be called raid45, but the name was switched in recent kernels. I bet that is what is causing this issue.
Hi, 2008.0 Beta2 does not resolve the issue. There appears to be a patch that needs to be applied to the kernel: http://people.redhat.com/heinzm/sw/dm/dm-raid45/dm-raid45-2.6.25-rc2_20080221.patch.bz2 Regards, Sam
Can confirm that I also ran into this with 2008.0 beta 2.
I guess this needs more work, then. I'm rather baffled that we need a kernel patch to support something that worked before. It seems to me that it would make more sense to fix the dmraid package, but that's just me.
Ubuntu has similar regression, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220493/comments/16 is link that I used to install Gentoo via Ubuntu livecd. Anyway, problem stems from a) raid45.ko suddenly renamed raid4-5.ko b) dmraid still wanting raid45.ko c) raid45 or 4-5 not included in kernel in the first place (?) Anyway, for compiling the gentoo kernel itself I basically downloaded the patch from http://people.redhat.com/heinzm/sw/dm/dm-raid45/ and did a find/replace to turn the raid4-5 BACK to raid45 until dmraid actually wants the new name (so yeah, bound to break my system in some future update if I touch initrd at least.). Not sure how this might help :)
*** Bug 231960 has been marked as a duplicate of this bug. ***
Surely this same error is causing problems in installed systems if they have updated their kernel now that the module is renamed. Is there anyway to add a patch to the dmraid ebuild (and live cd/dvd build) that will allow dmraid to use the new kernel module and if not there (for legacy kernels) fall back to the original. Shouldnt be that difficult right?
Sure we could. Go ahead and write said patch. Please attach it to this bug and send upstream. Thanks :)
(In reply to comment #14) > Sure we could. Go ahead and write said patch. Please attach it to this bug and > send upstream. Thanks :) > I would, but unfortunately, I am no great shakes at C/C++ programming as yet. Give me a VB or C# or even *shiver* that evil thing known as Java and I possibly could. Sorry :(
Bug still present on 2008.0-r1 livecd
(In reply to comment #16) > Bug still present on 2008.0-r1 livecd > Indeed it is.
Reading bug report 411172 [1] in debian, i see that there is a patch that "renames" raid45 to raid456. You could find it there http://patches.ubuntu.com/by-release/extracted/debian/d/dmraid/1.0.0.rc14-2/ 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411172
(In reply to comment #18) > Reading bug report 411172 [1] in debian, i see that there is a patch that > "renames" raid45 to raid456. i try to use it, but after a fast session of RTFM, i find that raid456 is for md (software raid).. so is there a way to use my brand new motherboard with raid5? I read that someone use a kernel-patch that enable a dmraid-45 module [1], but it's safe? 1: http://people.redhat.com/~heinzm/sw/dm/dm-raid45/
(In reply to comment #19) > 1: http://people.redhat.com/~heinzm/sw/dm/dm-raid45/ I've been using that. I'm also now running 2.6.26 and using a repatch from here http://tmb.kkc.fi/Kernels/Cooker/patches/ (Originally URL appeared on ataraid mailing list). Only thing is that with both patches, I had to use find/replace to change all references from raid4-5 to raid45. I guess if I'd be running device-mappers CVS version raid4-5 would work.
This one, we pretty much need to fix, or all of those people with on-board fake-raid will continue to suffer.
(In reply to comment #21) > This one, we pretty much need to fix, or all of those people with on-board > fake-raid will continue to suffer. > I have to agree here. Without this getting fixed, I cannot installed Gentoo on my computer. I only have it available to me as a VM through VirtualBox on my Windows install. Please, any help here would be great, even if it was put in as, say, a fake-raid USE flag on the kernel (since the patch involved seems to be a kernel patch).
I get the same error Andrew did from 2007-10-14. This afternoon, I did a fresh gentoo install from current (autobuild), stable x86 (dmraid: 1.0.0_rc14), with a genkernel (2.6.9-gentoo-r5), and succeeded (I am not installing to RAID5) but I cannot access my Intel ICH10-R RAID5 (but the RAID0 is peachy). I tried dmraid rc15 but got weird errors so switched back. I don't know if I understand the problem, but over 1.5 years later, I would think that a simple naming error that stops intel RAID5 partitions from working would be fixed?! Applying this patch to the kernel sources seemed to fix the problem for me: http://people.redhat.com/~heinzm/sw/dm/dm-raid45/dm-raid45_2.6.29.1_20090424.patch.bz2
Kernel, Any qualms with adding the above referenced patch to gentoo-sources?
(In reply to comment #24) > Kernel, > > Any qualms with adding the above referenced patch to gentoo-sources? > Now that the ISW issues are getting mostly fixed, could this patch FINALLY be added at least for the live-cd? Bug has been open for two years! I'd rather avoid having to use Ubuntu LiveCDs to rescue/reinstall Gentoo.
(In reply to comment #0) > Hi, > > When booting my nForce raid5'd system from the 2007.0 livecd, I am unable to > mount my raid volume. The issue appears to be an incompatibility between the > kernel module the dmraid binary expects to find (raid45.ko) and the module > actually present to handle raid5 (raid456.ko). > > The key error experienced is: > > # dmraid -ay > ERROR: device-mapper target type "raid45" not in kernel > > These Ubuntu topics contain reports essentially identical to my experience: > > http://ubuntuforums.org/archive/index.php/t-401295.html > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655 > > Reproducible: Always > > Steps to Reproduce: > 1. Create a raid5 nvraid volume using BIOS or Windows raid management > 2. Boot 2007.0 livecd with the "dodmraid" parameter > > Actual Results: > ERROR: device-mapper target type "raid45" not in kernel > > Expected Results: > The raid volume should appear as a block device in /dev/mapper/ (ie, > nvidia_foo) which can be fdisked/partitioned/mounted > (In reply to comment #25) > (In reply to comment #24) > > Kernel, > > > > Any qualms with adding the above referenced patch to gentoo-sources? > > > > Now that the ISW issues are getting mostly fixed, could this patch FINALLY be > added at least for the live-cd? Bug has been open for two years! > > I'd rather avoid having to use Ubuntu LiveCDs to rescue/reinstall Gentoo. > I also have this issue. I know fakeraid users are not high on any priority list, but this bug being open for several years now is just lame, seriously.
dm-raid45 is not part of the kernel, until it gets there I don't see why it would be included on any livecd's. Perhaps this bug needs to be re-assigned to the gentoo kernel herd to request that dm-raid45 be added to the gentoo-sources patch list?
I have this same issue with my brand new cyber-system i17 laptop. So I can not install on a raid5 partition because of a patch that has not been applied for almost 3 years while the request is there. And there has not been posted a work around either. Can some one help me with a minimal bootcd with patch or a simple work around?
work around: disable bios raid and use mdraid instead of dmraid. It is a opensource software raid solution. I read in 2nd hand sources that in most cases it even performs better than dmraid.
(In reply to comment #29) > work around: disable bios raid and use mdraid instead of dmraid. It is a > opensource software raid solution. I read in 2nd hand sources that in most > cases it even performs better than dmraid. Does not work if you intend to dual-boot to Windows...
(In reply to comment #30) > Does not work if you intend to dual-boot to Windows... Indeed I came across this bug yet again today when I upgraded my dual boot windows OS to Windows7 and needed a working LiveCD to re-install grub. All I needed was that elusive working Gentoo disc that I created all those years ago off the back of this bug that had a custom patched kernel inserted into a custom re-authored Gentoo LiveCD. So yes I'm also really disappointed to see that the bug has made zero progress in that time. Last time I tried Ubuntu's LiveCD they too were bitten by this bug, but then again that was a few years ago. I'll try Ubuntu again and report back, thanks for your effort anyway.
Ubuntu CD works fine!
sping: can you look at this before the Christmas release?
As of 3/14/11 this is still an issue. I'm unfortunately going to have to use something like Fedora Core or Ubuntu for this machine instead.
Why is this assigned to genkernel? As far as I can see this is more an issue of missing kernel feature then missing genkernel feature, or am I missing something? Also, is this patch roughly the same as what upstream 2.6.38 contains[1]? If so, is a backport possible? [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9d09e663d5502c46f2d9481c04c1087e1c2da698
After some more poking around, it seems mdadm is the way to go to setup the raid using the raid456 driver and not to use dmraid. Hopefully this helps someone else.
@Xake: For kernels greater than 2.6.36 you need to upgrade dmraid (userspace) to 1.0.0-r16. Not sure what is it that changed, but failing to do so gives an identical error message of cannot find raid45 module even when you have patched it in. @Mike D: Yeah, that's the theory. Sadly in reality, dmraid (the userspace tool) has to get upgraded to use that wonderful kernel module, and it hasn't yet. For the time being I'm maintaining some patches at http://code.google.com/p/dmraid-patches/source/browse/ . Would be nice to see these applied to sys-kernel/gentoo-sources.
should this bug not be closed? 2007 5 years old now.
(In reply to C.J. Wijtmans from comment #38) > should this bug not be closed? 2007 5 years old now. I am going to demote this to CONFIRMED until someone finds time to do more analysis. With that said, it might be prudent for anyone affected by this to consider alternative forms of RAID. dmraid is the absolute worst form of RAID possible from both a performance and a reliability standpoint. In particular, you have no guarantee of recovery should your motherboard die due to the use of non-standard RAID headers. I suggest that people interested in RAID 5 should consider either MD RAID 5 or ZFS raidz. There is a quick install guide for Gentoo on LVM on MD RAID that might be useful for this: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml Similarly, I have some notes on how to install Gentoo on ZFS: https://github.com/ryao/zfs-overlay/blob/master/zfs-install Unfortunately, they are not that great for doing an install on raidz, but anyone determined to do it would need to make the appropriate changes (fairly trivial) for raidz and then write his own grub.cfg (because grub2-mkconfig is broken on raidz). Also, people considering RAID 5 might want to consider RAID 6 instead. The following article argues that RAID 5 is no longer effective at withstanding disk failures: http://queue.acm.org/detail.cfm?id=1670144
I think we should call this OBSOLETE unless someone can tell us it's still an issue.
