I've tried alot of things and I cannot get it working for me. I have an A7N8X-E Deluxe and keep getting the 18 error from grub like others have gotten. I already had linux setup on my IDE connections but now both of the kernels for that have crapped out on boot and even the 2005.0 live CD cannot see the partitions I used to use on the IDE in an extended partition. Anyhow...

I can still use my grub that I used before and it sees my raid array as hd2, so this would be much like the booting of the floppy disk. Only problem is that it won't recognize the device command. SO, I reboot back into the array with the dmraid live cd and it just keeps giving me the 18 error no matter how I record the devices, including the NTFS partition.

This error is returned when a read is attempted at a linear block address beyond the end of the BIOS translated area. This generally happens if your disk is larger than the BIOS can handle (512MB for (E)IDE disks on older machines or larger than 8GB in general).

Why don't you place /boot BEFORE the windows partition (160GB!!!)??
You would want to have /boot small and in a place the BIOS can reach.

You might want to use a partition resize tool to fix it before trying to install grub again._________________Alle dingen moeten onzin zijn.

You'll notice using this method that you only have one apparent hard disk - that's good - the raid bios is mapping them together temporarily (this is so that e.g. windows can see it's initial startup files).

After switching from P4-System (i875, ICHR5-SATA-Raid) to my new AMD-System (sig below) i had problems booting with lilo.
I had to setup my RAID in the BIOS again, installed the system as usual + lilo 22.7.

It crashed with several errors (worked fine with the Intel system) like:

# If you are having problems booting from a hardware raid-array
# or have a unusual setup, try this:
disk=/dev/sda inaccessible # see this as the first BIOS disk
disk=/dev/sdb inaccessible # see this as the first BIOS disk
#disk=/dev/sda bios=0x81 # see this as the second BIOS disk
#disk=/dev/hda bios=0x82 # see this as the third BIOS disk

You might not consider it "bleeding edge" but it's mostly not supported and is VERY likely to get stepped on by some emerge. My lack of understanding is my biggest fear. While I might not understand a more "vanilla" install I know that it has been tested.

I get nervous when I browse config files for genkernel, udev, rc, and others that just seem waiting to break dmraid. I'd like to re-build my kernel to add somethings but looking at genkernel.conf I see it points to old versions of baselayout, device-mapper, udev, and so on... I was not able to get Gentoo to boot when I built the kernel by hand but genkernel was able to make a bootable kernel (although much much larger than the hand built one) so I must have missed something.

So I am going to fence sit for a bit more. Sooner than later I NEED to get my Treo to sync with Evolution and I seem to not have the visor mod made (although I don't see anything mentioned in the kernel config file for visor, palm or pda, either on or off....).

After reading the changelog for rc8-release of dmraid, i attempted my luck again with lilo and it worked now!

Wow. A lilo user. Used my dmraid patch?

gecko1969 wrote:

You might not consider it "bleeding edge" but it's mostly not supported and is VERY likely to get stepped on by some emerge. My lack of understanding is my biggest fear. While I might not understand a more "vanilla" install I know that it has been tested.

Nope, I see it differntly. We are the pioneers with dmraid to get it tested and get it officially supported later. If things very close related to dmraid break, I'm really sure it will be reported on this forum the same day.

Quote:

I get nervous when I browse config files for genkernel, udev, rc, and others that just seem waiting to break dmraid.

I agree, things can break, but if you understand how Gentoo works the cause to a problem can be found. If you don't, there wil be dozens of other people with the same problem who do understand what has caused the problem and can fix it or share their solution. This thread for example, is very important and usefull, I think.

Quote:

I'd like to re-build my kernel to add somethings but looking at genkernel.conf I see it points to old versions of baselayout, device-mapper, udev, and so on... I was not able to get Gentoo to boot when I built the kernel by hand but genkernel was able to make a bootable kernel (although much much larger than the hand built one) so I must have missed something.

If you want to use a custom kernel config, you can use /etc/kernels to use your own.

My personal problem is that working ebuilds existing for dmraid are still not accepted into portage. It's not that I need those ebuilds, but it's very important for gentoo to have them. No ebuilds -> No LiveCD dmraid support.

For example: I worked to solve a bug in Genkernel to have dmraid running on LiveCD's. This has been accepted into Genkernel and in the newest official Gentoo LiveCD. The 2005.0 liveCD now has broken dmraid support because it misses /usr/sbin/dmraid. This can make users confused getting the message "Activating device mapper raid(s)" but once fully booted there is no dmraid tool available. I regret dmraid support in the official LiveCD is 'broken', but please have it fully supported in the next release!_________________Alle dingen moeten onzin zijn.

I've tried alot of things and I cannot get it working for me. I have an A7N8X-E Deluxe and keep getting the 18 error from grub like others have gotten.

I have the same board and spent a long time working on this.
Even when I had a 32MB boot as /dev/mapper/sil_*1, I still got the 18 error when I tried to read the /boot/grub/menu.lst from within grub. Grub thought /boot/grub/ was a file, not a directory. When I copied menu.lst into /boot, I could run "configfile(?) menu.lst" from within grub to get a menu.
My eventual solution was to put /boot on /dev/hda (I also created a 2GB boot partition for windows, because it can't install entirely on the second disk).
I wanted the extra IDE drive anyway (I use it for my nightly backups), so it's not a bad solution for me.

I've tried alot of things and I cannot get it working for me. I have an A7N8X-E Deluxe and keep getting the 18 error from grub like others have gotten.

I have the same board and spent a long time working on this.
Even when I had a 32MB boot as /dev/mapper/sil_*1, I still got the 18 error when I tried to read the /boot/grub/menu.lst from within grub. Grub thought /boot/grub/ was a file, not a directory. When I copied menu.lst into /boot, I could run "configfile(?) menu.lst" from within grub to get a menu.
My eventual solution was to put /boot on /dev/hda (I also created a 2GB boot partition for windows, because it can't install entirely on the second disk).
I wanted the extra IDE drive anyway (I use it for my nightly backups), so it's not a bad solution for me.

Funny, I actually have my boot partition on my /dev/hda also but it's started recognizing it as an EZDrive and not recognizing it in an extended partition, like it used to work. No idea why that changed. Anyhow, I have no problem getting grub to boot, and the boot floppy didn't help at all as it didn't work, but grub won't see the SATA drives or something... And even if it does, it gives the 18 error. Man, this sucks, but I have to make this works as it will mess up all my windows stuff if I jumble around my drives, etc like I wish I could._________________--------------------------------------------------
Skid

And he got his head sent home in a freezerbag!
--Bill Murray in The Man Who Knows Too Little

kwiqsilver and SkidSoft if you could describe in details what you have done (from the beginning) what method (dmraid live CD, 2005.0 LiveCD or another way) did you use, what is your configuration (RAID controler, mobo, etc) and what is the layout of the partitions you would like to have.

I know you posted that genkernel "magically" fixed this. I had a similar problem and didn't want to run genkernel because it currently can't make an initrd with a working dmraid setup on my system. I THINK the problem on your system (it was on mine with the same symptoms) was not including the right SATA drivers, under Device Drivers -> SCSI -> Low-Level -> SATA NV (in my case) in the kernel config. Just for the record.

Hello!
I'm newbie to linux, but used gentoo on my old barracuda IV. Now i have 2 Samsungs SATAII NCQ and LanParty NFII Ultra B (Silicon 3114). I installed Windows and try to install Gen2. But while trying dmraid -ay i recive error msq:

Off the top of my head, I'd guess that you haven't created the raid partition with the bios utility yet. When using softraid, you need to use the bios utility to set up what drives are part of what raid arrays before trying to use them with any type of OS.

This is my 1 lone serious gripe about dmraid...
Why on gods earth did the author decide to write it all in userspace?

Surely the more sensible thing to do is to write a simple initiation/control interface patch for the kernel tree under device-mapper to allow the kernel to mount partitions. And any other code could be diverted to userspace. There are a lot of people who detest initrd because it feels like a nasty hack.. which it practically is.

I think it was good that someone started on bios raid workarounds for linux 2.6 (since ataraid was wasn't ported over for some reason i cannot seem to unmask). But it hasn't been implimented as well as it could have. If I wanted to use an initrd driver i would have simpily used my manufactors "open source" (heh) drivers.

I honestly can't see any disadvantage of having this in kernel space, and I can see plenty with the oposite.

This is my 1 lone serious gripe about dmraid...
Why on gods earth did the author decide to write it all in userspace?

Because this is the trend in Linux kernel development. Why has devfs been vanished out? Why is genspash using userspace helpers? Next to come is the whole partitioning thing I bet! Dmraid is just a very early bird.

Quote:

Surely the more sensible thing to do is to write a simple initiation/control interface patch for the kernel tree under device-mapper to allow the kernel to mount partitions.

Sounds not too bad. Just write it!

Quote:

And any other code could be diverted to userspace. There are a lot of people who detest initrd because it feels like a nasty hack.. which it practically is.

Monolithic kernels just need things like an initrd. Sometimes it feels like a hack, but it's the only way to make a monolithic kernel more modular.

Quote:

I think it was good that someone started on bios raid workarounds for linux 2.6 (since ataraid was wasn't ported over for some reason i cannot seem to unmask).

Ataraid was dropped because Linus only wants to support good code.

Quote:

But it hasn't been implimented as well as it could have. If I wanted to use an initrd driver i would have simpily used my manufactors "open source" (heh) drivers.

I vote for a kernel patch that allows to move partitioning back to the kernel. I would also like some ioctl's to be available for lilo compatibility.

Quote:

I honestly can't see any disadvantage of having this in kernel space, and I can see plenty with the oposite.

You can't just do everything inside the kernel. It already is a big monster and things that can be done outside, should be._________________Alle dingen moeten onzin zijn.

Because this is the trend in Linux kernel development. Why has devfs been vanished out? Why is genspash using userspace helpers? Next to come is the whole partitioning thing I bet! Dmraid is just a very early bird.

I agree with this trend in moving as much unnessecery stuff out of kernel space for stability, and maintainablity purposes, udev is a perfect example of doing it right since the kernel doesn't depend on userspace tools to mount root.

irondog wrote:

Sounds not too bad. Just write it!

Looks like I'll have to look into it, I havn't done kernel coding before, so I'll probibly have a steep learning curve heh. I have a book somewhere on 'Linux Programming' which has a section on the kernel, looks like I'll need to dust off the tombs.

irondog wrote:

Monolithic kernels just need things like an initrd. Sometimes it feels like a hack, but it's the only way to make a monolithic kernel more modular.

Yes, an unfortunate by-product of binary only distros.

irondog wrote:

Ataraid was dropped because Linus only wants to support good code.

Hmm, unfortunatly on the other side of that coin it made BIOS RAID+Dual-booting a nightmare (and practically impossible before dmraid besides mostly broken partial sources from the device manufactor).. Hopefully It will motivate people in our situation enough to do something about it. BIOS RAID chips are being used pretty commonly, its cheap and nasty, but performes admirably in RAID0/Desktop situations. 3ware is overkill for that kind of application with little performance gain.

irondog wrote:

I vote for a kernel patch that allows to move partitioning back to the kernel. I would also like some ioctl's to be available for lilo compatibility.

ioctl's would be nice, it would help if we had experienced kernel coders who know about I/O stuff.. I don't mind giving it a try and likely trash my partitions, since all my work is offloaded on a fileserver. What we would need the patch to do is i) initalise the array ii) add a device node, and nodes for any partitions iii) have some control mechanisms for userspace tools. (am i missing anything?)

irondog wrote:

You can't just do everything inside the kernel. It already is a big monster and things that can be done outside, should be.

Indeed, I agree fully.

Does anyone else think this is a good idea and worth investing time in?

P.S. My thanks to the origional poster of this HOWTO, its really helpful and gave good advice based on the tools available.

I mean 'Monolithic' as the opposite of 'Microkernels', not as the opposite of a linux kernel split into loadable modules. Whatever you do to the Linux kernel: it will stay a monolithic kernel.
Besides that it would be a real nightmare if all distributions try to compile a kernel during installation optimised for the system. (Which i think is what you were thinking of, blaming source only distro's).

irondog wrote:

What we would need the patch to do is i) initalise the array ii) add a device node, and nodes for any partitions iii) have some control mechanisms for userspace tools. (am i missing anything?)

No, I really don't agree. Early userspace will become VERY popular in the future and dmraid's functionality must not be backported to the kernel again.

Keep it the way it is, but change the behaviour a little bit:
i) dmraid tels device-mapper kernel runspace to setup a RAID (striped or mirrored)
ii) dmraid tells the device-mapper that the newly created device is somthing that contains a partition table
iii) kernel reads partition table and creates linearly mapped devices on top of the stripe/mirrored device
iv) Kernel provides ioctls for: a) re-reading the partition table b) getting info about cylinders / heads / and sectors

Results:
* Better consistency, which helps partitioning programs and installing bootloaders
* all distro's can support dmraid much easier as it will look like something like a scsi disk instead of something really uncommon.

In other words:
* There is nothing wrong with raid setup in userspace and very modular kernels using initrd's (this can be scripted).
* Device-mapper stuff differs too much from normal block devices (scripting this is seems too hard for most distro's developpers).

Quote:

P.S. My thanks to the origional poster of this HOWTO, its really helpful and gave good advice based on the tools available.

This comment was regarding the nessecity of initrd to power a modular kernel on binary only distros.

I personally don't like initrd because you need to add unnessecery code to the kernel simpily to get the thing to mount root, you shouldn't need to do this.. kernel modules are fine if you only use certain things from time to time, I2C, ALSA/sound card drivers etc.. for things that you run constantly the additional overhead doesn't make any sense. I'm not saying every distro should compile during installation, its up to the user to determine if binary only makes sense to them (or don't understand the point of source installation).

Offloading code to userspace is a good idea, things like tux and administerive code in kernel space bloats the kernel and things can be done more effectively in userspace. Just so long as you don't require mounting half a complete system in an initrd just to mount root. In this case dmraid can't tell device-mapper anything unless its bundled in initrd which shouldn't be a forced nessecity. Not everyone wants their kernel sprawling with modules, i.e. genkernel is fine for newbies but counter productive for people who know what a kernel is and how to compile one that works with their hardware. my rule of thumb for compiling-in support for something is if i use it 90% (or more) of the time, that goes under the likes of Disk controllers, networking etc.., and the 10% I don't use all the time I would compile as modules, these would fall under the catagory of I2C, ALSA, etc.. initrd is used 0.009% of a machines uptime which adds unnessery size to the kernel.

Having dmraids primary initalisation functionality in kernel space wont stop distros from being able to modulate it and toss it in initrd, it just means there is a choice for people who do compile their own kernels. If anything it will cut down on initrd size because you don't need all the dmraid program in initrd to mount the root fs and thus reducing unnessery overhead to booting all round.

Technically you can do anything at all in userspace with the kernel doing practically nothing, however it isn't optimal for performance considerations, and makes booting more tedious and (user) error prone.

I have been following this thread for quite some time and had successfully installed my system with the 0.99 version of the ISO. Recently I had to reinstall my boot loader and tried this ISO. It did not work for me. I had to go back to the 0.99 ISO.

When I use the 0.99 ISO and execute:

Code:

dmraid -ay

The device files are all correctly created in

Code:

/dev/mapper

. When I use the 1.0 version of the ISO above I only get:

Code:

/dev/mapper/isw_bidjfdiibg_RAID_Volume1

None of the device files are created for the partitions. I also tried:

Code:

dmraid -ay -f isw

but this did not help. I have 11 partitions and they show up just fine with the 0.99 version of the ISO, but only the volume shows up with the 1.0 version of the ISO.

Is there anything else I can do to collect more information on why this is happeneing
And who should I send it to

I did a bit more troubleshooting and found that dmraid version 1.0.0.rc8 is not a problem.

I installed dmraid 1.0.0.rc8 and it works fine with my gentoo 2.6.11-r9, but if I use gentoo 2.6.12-r9 it fails just like with the gen2dmraid-i686gcc4-1.0.iso. So it seems to be related to some change in 2.6.12. That is what the 1.0 ISO is using.
NOTE: Both gentoo releases show the same device-mapper version 4.4.0.

I have not had a whole lot of time to work on this, but I'll see if I can now gather some more information. I would like to try to initialize the raid without using dmraid, but I'll have to first search for those instructions. I've seen them before, but cannot remember the tool/steps I need to do to do this. Maybe then I'll get a better error message about why dmraid does not create the device files for release 2.6.12.