dmraid looking for raid45 when kernel uses raid456

Hello nox216, what architecture are you using? I would like you to test an updated package before I submit the patch.
Time is of the essence since Feisty is only 2 weeks away.

Please test this package to see if it works. This will work on the i386 architecture. If you used x86_64 let me know.

Okay, I've got it installed. Keep in mind this is using a Feisty beta CD, but dmraid setting up devices no longer locks up and now I can list the proper RAID array using dmraid -r. This looks to be much improved, as before it would only hang on anything involving dmraid.

I still can't mount the RAID, as it complains of wrong FS or bad superblock, and there's nothing properly listed in /dev/mapper. I'm not sure if this is on my end or not, but it's an NTFS array and NTFS support is installed.

Can I please have the x86_64 version of that package?

Nox, you won't be able to get a raid5 array working with just this package. I'd love the package though because there are other problems.

to get a raid 5 array working, you also need the dm-raid4-5.ko module. Unfortunately, I can't find a patch set that allows this to be compiled with feisty's kernel.

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655

This bug explains what's needed to get a Nvidia (and other chipset) fake raid 5 arrays working.

Ah, okay, I'd found that information for 2.6.18 before, but didn't know if it'd been committed for 2.6.20 or not. Makes sense as to why it can't be mounted, then.

I'd say adding that module as a dependency of dmraid (or even as another package entirely) would make a number of folks' lives easier if they're installing or using a fakeraid, then.

Chad, you can test with this package.

thank you. Unfortunately I am not at home to celebrate the weekend with my friend Jack Daniel and some others. Hopefully i can get around to testing it this weekend, if not monday when I'm forced to go back to that computer. :)

yea I had the dm-raid4-5 module working for 2.6.19 custom compiled, but can't do it anymore. They should package the module separately and put it in multiverse.

once raid5 works easily for data, maybe other things can be patched up to allow booting!

yea i forgot, i have plenty of reasons to go back to campus this weekend. I'll test this today. just wish i had the dm-raid4-5 patch though. however, the bug has been confirmed and added to the wishlist, so here's hoping it makes it into fesity. maybe fesity +1 can have support in the installer, and be bootable, but that's really wishful thinking and not a good idea seeing how it's in alpha and all and just complicates everything.
I would personally love raid5 bootable support for myself, but don't have a computer with an array in it yet, this one is for someone else who decided to use a separate boot drive since its a lot easier and more possible. I could probably wait 2 releases though. besides, maybe by then we won't even need dmraid. maybe i would kick windows off the drives natively :)

i tried this yesterday and it broke the computer worse. If i go back to the lab today, I can try getting the computer to boot, otherwise we have a serious problem.

Ok, it's not really any more broken than before. The computer does work minus the raid of course. It still has the annoying 4 minute delay during boot though. I tried both the official and your version. I even made sure to do a complete uninstall between versions. I even updated the initramd for all my kernels. I tried my feisty kernel and my custom kernel. i tried with modules loaded and unloaded.

The only difference between your version and the official version is the official version says raid45 not found and yours says raid456 is not found.

You're probably celebrating Easter. Hope we can fix this soon though.

Hi Chad, I'm sorry to say that this most likely wont be fixed in time for Feisty's release. In order to have a proper and stable release different parts of Ubuntu have to be frozen at different times, and the kernel was frozen back on April 5th: https://wiki.ubuntu.com/FeistyReleaseSchedule

Since this bug depends on a module being in the kernel, either raid45, dm-raid45 or raid456, this means this bug wont be fixed in time for Feisty. However, don't drop interest in the bug, we have to make sure it gets into Feisty +1 due in October.

Because of this I'm unassigning myself from the bug and subscribing to both this and the one you indicated at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655

But raid456 is already in the kernel. dmraid is having some kind of other trouble. What is causing the 4 minute delay? I had everything working in Edgy just fine. I had to compile the newest dmraid, and a kernel, but it was working. now its broke in feisty.

by the time the feisty +1 is ready for testing, even alpha stage will take a few weeks to be usable, I'd have abandoned Ubuntu to see if Fedora Core works.

Chad, I'm currently at work so I can't do much work at the moment to verify or test this, but a post over at the Fedora kernel list mentions symlinking the other modules to raid456.ko <a href="http://<email address hidden>/msg00090.html">here</a> for backwards compatibility.

I no longer have a Ubuntu install available to easily test this, but thought you might want a heads up to see if workable RAID5 could really be something as easy to fix as this.

The summary amounts to this:

ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid6.ko

Something similar could be used for raid45? Unsure, just thought I'd toss this out, as raid456.ko is definitely present in that directory on my work Feisty install (no RAID here to test with, but..)

If all that is required is a linking then link use raid45.ko as the symlink and use the published dmraid package, not the one I've uploaded to this bug report.

Since ubuntu's kernel does not yet have the raid456.ko module I'm not going to commit the changes I did to the dmraid package (which was simply to change calls for the raid45 module to raid456).

Hi I've also been trying to get dmraid to work to set up a Fake-Raid 5 array on Ubuntu Feisty (64bit) alpha. I have been following this thread and tried the posted suggestions. In reply to the last posts by nox216 and Richard, creating symlinks to the raid456.ko module does not work. Though, the module raid456.ko is present in /lib/modules/2.6.20-9-generic/kernel/drivers/md and loads when I do a modprobe.
I've also tried adding an alias for the raid45 module in the /lib/modules/2.6.20-9-generic/modules.alias file but no luck.

With the symlink, if it even works, you still wont be able to boot from it because there will be no raid45 or raid456 symlink in the initramfs.
Don't do the raid456 symlink since the version of dmraid release for feisty it expecting raid45. Create that symlink instead and see if it works.

Bishen, why are you using an old kernel and do you have the patch to enable raid5?

I know we are trying to fix dmraid, but that isn't sufficient for raid5.

Richard, i made the sim link and put the module in the initrd, along with the dm-raid4-5 module and there is no longer a problem of that error.

I still get some hangs in the boot process but they are probably related to something else.

Is there hope that it will be included in gutsy? It would be a shame not to because most motherboards sold now support it and more and more people need it to be able to dual boot with windows.

I will have a new computer next week with 3 disks so I want to use raid5 and dual-boot windows. Maybe I will hold with windows until gutsy arrives.

Nope, it won't be in Gutsy. Upstream is still working on it.

Let me try to summarize what has happened so far:
- this bug has been posted more than one year ago
- Feisty has come and gone
- so has Gutsy
- Hardy is one day before release, with this problem still being unsolved

I have been using Ubuntu now for almost one year. So far, I've been pleasantly surprised. But this issue is really worrying me, since I rely on the RAID feature for my new machine.

I can only second the comment about most of today's motherboards being equipped with RAID (5) functionality.
Does anyone have a honest clue when we can except a fix?

no one in the ubuntu community seems to care. They don't aim it towards the
people who use raid5. they aim it towards the people who can't even
diagnose a compiz problem with their video driver.

There was that one guy working on the bug before. I was helping him, but i
lost access to the hardware. It wasn't my computer. He was unable to finish
working on it because the new software wasn't ready.

It sounds like all the hard work has been done, the software is ready, but
it still isn't working. it's quite hard to understand. I wish i could
help, but I don't have the hardware.

the state of this bug in ubuntu is absolutely ridiculous. Gentoo and fedora
have had this working for a long time now. I might stop using ubuntu
someday, because it bores me.

If you can afford it, you might want to get a hardware raid card. It will
be much easier to get to work, and it will be much safer. I will seriously
consider that option myself whenever i finally build a new desktop. The
problem is finding an affordable one with more than 4 ports.

On Wed, Apr 23, 2008 at 3:32 PM, Jochen Schneider <email address hidden>
wrote:

> Let me try to summarize what has happened so far:
> - this bug has been posted more than one year ago
> - Feisty has come and gone
> - so has Gutsy
> - Hardy is one day before release, with this problem still being unsolved
>
> I have been using Ubuntu now for almost one year. So far, I've been
> pleasantly surprised. But this issue is really worrying me, since I rely
> on the RAID feature for my new machine.
>
> I can only second the comment about most of today's motherboards being
> equipped with RAID (5) functionality.
> Does anyone have a honest clue when we can except a fix?
>
> --
> dmraid looking for raid45 when kernel uses raid456
> https://bugs.launchpad.net/bugs/102973
> You received this bug notification because you are a direct subscriber
> of the bug.
>

> If you can afford it, you might want to get a hardware raid card.

Also don't forget that for pure Linux boxes, Linux software raid is probably the best solution, and with almost no performance penalty.

I don't expect this to be fixed anytime soon.

Despite software fake RAID being on a majority of shipping motherboards, and despite dmraid being in a workable place with the correct kernel modifications, there just isn't any interest in adding this functionality to Ubuntu. Most responses consist of "well, use Linux software RAID." *shrug*

I'd like to meet these people who suggest to use just use linux software
raid. It has its purpose, and we would be using it if it fit the bill. The
computer with $500 worth of hard drives, the huge case and power supply
needed to run them, and all that jazz, is probably the best computer in the
house. It probably has other expensive components making it useful for
gaming, video production, modeling, or other things. That stuff usually
needs to be done in windows. most of us can not escape windows 100% of the
time. If we do need windows, we are going to want it on the best computer
in the house, the one with a raid5 array.

another issue, what if you already have your 2TB raid5 array almost full on
a windows computer. THEN you decide to install linux. what can you do
then? Do you have another 2TB of free space to backup your raid5 array to
so you can reformat it? I know I wouldn't.

your options

1) get a hardware raid card
2) use a different distro
3) never run windows natively on that computer
4) don't use raid at all

number 2 is the mostly likely for people to choose, because all the others
require great sacrifice.

There is a 5th option, but it isn't for the faint of heart. You could try
hacking raid 5 support together yourself. But this isn't the ubuntu way. If
you run a custom compiled kernel, is it really still ubuntu? But by asking
this question, it can be reasonably assumed that you are either unable or
unwilling to try this. I switched to ubuntu because i got sick of fiddling
with everything in gentoo, and nothing else i tried was impressive.

On Wed, Apr 23, 2008 at 6:09 PM, nox216 <email address hidden> wrote:

> I don't expect this to be fixed anytime soon.
>
> Despite software fake RAID being on a majority of shipping motherboards,
> and despite dmraid being in a workable place with the correct kernel
> modifications, there just isn't any interest in adding this
> functionality to Ubuntu. Most responses consist of "well, use Linux
> software RAID." *shrug*
>
> --
> dmraid looking for raid45 when kernel uses raid456
> https://bugs.launchpad.net/bugs/102973
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I feel your pain Chad... I've been looking to get this running since Feisty myself. Since it was working with Hardy beta, I decided to install it on my desktop. Imagine my surprise when I found out that it was broken again in the final release!

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220493

I finally have it running on my desktop, but had to use the beta release to do so. I'd be up for writing a how-to, but it would make life much easier for everyone if they included the fix in the current kernel.

I agree that the linux software raid implementation is better (in fact, that's what I use on my file server), but if I want to do gaming on my desktop I *have* to boot to windows. Virtual machines are great (I use them as well), but aren't up for gaming at the moment. I tried Wine and Cedega, but was pretty disappointed with the results. Dmraid is the most practical way to go as the software raid implementations for windows and linux simply aren't compatible.

This is working Hardy now.

https://bugs.launchpad.net/bugs/220493

It is actually NOT working in Hardy now. It looks like a potential fix was made but it has still not been uploaded to -updates.

It also does not appear to have made it into Intrepid either, as of linux-image-2.6.26-5-generic.

Also the issue is with the kernel package, not dmraid, and since bug 220493 appears to already deal with that, I'm marking this as a duplicate and the dmraid targets invalid.

Status changed to 'Confirmed' because the bug affects multiple users.

I'm trying to install Ubuntu 11.10 server on a Tyan GT20B7002 server using fakeraid ICH10R raid 5
dmraid says that raid45 is not in kernel but I think it would be raid456

the result is a raid volume activated but in readonly so I can't do anything with it.

any idea ?

On 12/14/2011 5:50 AM, Doudz wrote:
> I'm trying to install Ubuntu 11.10 server on a Tyan GT20B7002 server using fakeraid ICH10R raid 5
> dmraid says that raid45 is not in kernel but I think it would be raid456
>
> the result is a raid volume activated but in readonly so I can't do
> anything with it.
>
> any idea ?

Don't use fakeraid; it isn't well supported and is buggy. Use regular
software raid instead, which works much better. The only reason to use
fakeraid is if you dual boot with Windows ( since it doesn't understand
Linux software raid ).

Phillip Susi (psusi) wrote 1 hour ago:
Don't use fakeraid; it isn't well supported and is buggy. Use regular
software raid instead, which works much better. The only reason to use
fakeraid is if you dual boot with Windows ( since it doesn't understand
Linux software raid ).

So you intend that someone who want to migrate from a windows fakeraid to a "pure linux raid system" is obliged to have a second machine under *nux system, with the same (or higher) disk capacity, create mdadm and lvm volume support, and then can tranfer all datas... ?

Do you think is that the right way to solve this problem (and saying that fakeraid is buggy, i think you're a little bit shorty)...
All the Intel chips(as concurrents) have well known handling protocols, and i think that the *buntu problem came from the idea to integrate all the managing of all the chips (promise, intell and so on) in an only one module.

That is just a way of thinking (one patch for one chip can impact another).

Fakeraid is a hardware technology, and i think it is not possible to manage all chips in only one module. They have to be separated in two levels, hardware and software: hardware for the owner protocols, and a common part in the software for the user "gui" (or "ui" in console mode).

Hope it will help some developpers to go in this way, and to go in your direction, when i decidate to migrate from a fakeraid to a "pure linux raid", i build a second machine....

Sincerely yours... Roberto

On 12/14/2011 12:01 PM, bobdum wrote:
> So you intend that someone who want to migrate from a windows
> fakeraid to a "pure linux raid system" is obliged to have a second
> machine under *nux system, with the same (or higher) disk capacity,
> create mdadm and lvm volume support, and then can tranfer all
> datas... ?

If you are going to bother blowing away windows and rebuilding the
machine with Linux, then yes, I would expect you to backup your data,
rebuild the machine, and restore your data. You do have backups right?
  Raid is NOT a substitute for backups. You wouldn't want to keep your
data on an NTFS partition under a pure Linux install anyhow.

> Do you think is that the right way to solve this problem (and saying
> that fakeraid is buggy, i think you're a little bit shorty)... All
> the Intel chips(as concurrents) have well known handling protocols,
> and i think that the *buntu problem came from the idea to integrate
> all the managing of all the chips (promise, intell and so on) in an
> only one module.

I meant that it is fakeraid *support* in Linux that is buggy. Anything
beyond raid0 does not work well. mdadm also has additional capabilities
including being able to reshape the array to add/remove disks on the
fly, increasing ( or decreasing ) the capacity of the array, and true
raid10 ( not 0+1 ), so you can get both speed and redundancy with just
two or three disks.

> That is just a way of thinking (one patch for one chip can impact
> another).

It has nothing to do with chips; fakeraid is just software raid.

> Fakeraid is a hardware technology, and i think it is not possible to
> manage all chips in only one module. They have to be separated in
> two levels, hardware and software: hardware for the owner protocols,
> and a common part in the software for the user "gui" (or "ui" in
> console mode).

No, it isn't hardware technology; it is just plain old software raid
that bios vendors have built in support for, and a Windows driver that
reimplements the software raid differently from every other vendor, and
windows itself.

You can take fakeraid drives and plug them into a machine that does not
have any fakeraid support and Ubuntu will recognize and use them just
fine -- it doesn't care about the hardware.