[SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

TomB17 · 2009-09-02 15:55:36

I'm having a tough time booting Arch. The system is installed out to a KDE desktop and is working great with the exception of the boot process. Right now, it won't boot without the USB flash drive that was used to install being connected. I don't have to boot from the install USB flash drive, it just has to be in place in order for Arch to boot correctly from my the installed USB flash drive.

Geometry:

/boot = 4GB Kingston USB flash drive, EXT2
/root = 5 x 1.6 TB Seagate HDD in a RAID5 array (would like to expand to 6 drives as soon as I can get the system booting properly)

"mdadm -D --scan >> /etc/mdadm.conf":

ARRAY /dev/md0 level=raid5 num-devices=5 metadata=0.90 UUID=5236b07c:a0bbe5cd:78a80cbe:7c6d4f5b
ARRAY /dev/md1 level=raid5 num-devices=5 metadata=0.90 UUID=ba690861:8b6edd5f:09d8912e:c34c29e6

"cat /proc/mdstat":

Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md1 : active raid5 sde3[4] sdd3[2] sdc3[3] sdb3[1] sda3[0]
5801777920 blocks level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]

md0 : active raid5 sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
41961472 blocks level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]

"cat mkinitcpio.conf | grep HOOKS"

# HOOKS
# This is the most important setting in this file. The HOOKS control the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# HOOKS="base"
# HOOKS="base udev autodetect pata scsi sata filesystems"
# HOOKS="base udev autodetect ide scsi sata filesystems"
# HOOKS="base udev pata scsi sata usb filesystems"
# HOOKS="base udev pata raid encrypt filesystems"
# HOOKS="base udev usb lvm2 filesystems"
HOOKS="base udev autodetect usbinput pata scsi sata usb raid filesystems"

*** This does not work. I'm scared to reboot to read the partition information on my 6th HDD because it took quite a while to get it back last time.

Guessing at the appropriate hooks:

HOOKS="base udev autodetect usb usbinput pata scsi sata mdadm filesystems"

I would really appreciate it if someone would confirm this "HOOKS" setting.

Thanks in advance for the help and thank you to the maintainers of Archlinux!

Last edited by TomB17 (2009-09-02 17:15:44)

TomB17 · 2009-09-02 16:00:19

Just for good measure...

"cat /etc/fstab":

#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0

#/dev/cdrom /media/cd auto ro,user,noauto,unhide 0 0
#/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0
#/dev/fd0 /media/fl auto user,noauto 0 0

/dev/md0 / ext3 defaults 0 1
/dev/md1 /usr/local/data ext3 defaults 0 1
/dev/sda1 swap swap defaults 0 0
/dev/sdb1 swap swap defaults 0 0
/dev/sdc1 swap swap defaults 0 0
/dev/sdd1 swap swap defaults 0 0
/dev/sde1 swap swap defaults 0 0
#/dev/sdh1 /boot ext2 defaults 0 1
UUID=fab410b7-9d31-40a7-b52b-305ace4dea04 /boot ext2 defaults 0 1

nowahn · 2009-09-02 16:37:44

First, I understand that there are 2 USB flash drives involved (correct me if I'm wrong), one with the install image on it, and another with your /boot partition on it.

Where does the boot process stop ? Which messages do you have ?
Is your /boot/grub/menu.lst correct ?
- which (hd?) is there for your boot partition ? The actual name may change when 2 external drives are plugged instead of one.
- Did you add "md=0,/dev/sda2,/dev/sdb2,...,/dev/sde2" to the kernel line ?

PS : your HOOKS line seems correct to me.

TomB17 · 2009-09-02 17:06:20

***** Solved by nowahn *****

THANK YOU, nowahn!!!!

nowahn wrote:

First, I understand that there are 2 USB flash drives involved (correct me if I'm wrong), one with the install image on it, and another with your /boot partition on it.

Yes. Installed from USB key to a /boot on a different USB key

nowahn wrote:

Where does the boot process stop ? Which messages do you have ?

Could not find /dev/md0

nowahn wrote:

Is your /boot/grub/menu.lst correct ?
- which (hd?) is there for your boot partition ? The actual name may change when 2 external drives are plugged instead of one.
- Did you add "md=0,/dev/sda2,/dev/sdb2,...,/dev/sde2" to the kernel line ?

menu.lst contaons, "root (hd0,0)". This took me quite a while to figure out as the installer kept installing it with, "root (hd0,0)". From the forums and Google, I discovered that USB drives are *always*, "root (hd0,0).

I did not have the, "md=0,/dev/sd...." in the menu.lst. I removed it after changing the HOOKS= line to include "mdadm", instead of "raid". The reason I removed it is because another poster here said it wasn't necessary when using "mdadm" like it used to be when using "raid". I was using "raid" before so I removed the "md=" business from the menu.lst when I changed to the "mdadm" hook.

The point being, adding "md=/dev...." fixed the issue. Thank you for solving this for me.

If I may be so bold, I would suggest the docs are woefully short in three areas:

- no notes as to requiring "root (hd0,0)" in menu.lst for *any* USB drive, regardless of it's order in the /dev/sd* list. Grub wants to install to USB the same as a hard disk, with the "root (hdN,0)" notation.
- mkinitcpio.conf file still contains comments documenting the "raid" HOOK. This could/should be expanded to include documentation on the "mdadm" hook to help newbies like me who trust an application's documenation in it's own config file
- requirement for "md=0,/dev/sda2,/dev/sdb2,/dev/sdc2...." in the menu.lst should be documented formally somewhere

As I am fresh from installing Arch, I will offer to update this documentation. Perhaps a brief Wiki entry on installation to USB and RAID5 would be in order. It's a great configuration, although I expect not a lot of people will use it.

nowahn wrote:

PS : your HOOKS line seems correct to me.

Thanks! It was.

Last edited by TomB17 (2009-09-02 17:17:29)

lilsirecho · 2009-09-02 18:47:04

Perhaps the use of mdadm to generate arrays can be understood best if the use of /etc/mdadm.conf to populate mkinitcpio with array data is better described.

In my use(s) of mdadm from the command line, mkinitcpio is populated following the entry :

 mdadm -D --scan >> /etc/mdadm.conf

This places all defined arrays in that file.

Running the following completes the mkinitcpio setup:

mkinitcpio -p kernel26

These are command line entries which will enter all arrays included in /etc/mdadm.conf into mkinitcpio for booting.

I note others have beat me to the punch!!!!

lilsirecho · 2009-09-03 02:31:39

Reviewing your posts suggests that when you changed the hooks to add "mdadm" you probably did not then follow that with:

mkinitcpio -p kernel26

This places the array(s) data in initramfs . This allows both raid arrays to be initiated and probably eliminates the need for adding :

md=0,/dev/sd....etc. to the kernel line.

Man mdadm gives good info on the use of mdadm.

Last edited by lilsirecho (2009-09-03 15:27:28)

Profjim · 2009-09-03 10:53:03

lilsirecho wrote:

This allows both raid arrays to be initiated and probably eliminates the need for adding :
md=0,/dev/sd....etc. to the kernel line.

s/probably//

TomB17 · 2009-09-03 16:42:26

lilsirecho wrote:

Reviewing your posts suggests that when you changed the hooks to add "mdadm" you probably did not then follow that with:
mkinitcpio -p kernel26
This places the array(s) data in initramfs . This allows both raid arrays to be initiated and probably eliminates the need for adding :
md=0,/dev/sd....etc. to the kernel line.
Man mdadm gives good info on the use of mdadm.

I did the 'mkinitcpio' step.

The "md=0,..." was needed here. I had dropped it because several people said it isn't necessary but the machine wouldn't boot without it.

Last edited by TomB17 (2009-09-03 16:43:22)

Profjim · 2009-09-03 20:19:56

I'm using the mdadm hook with no need for the md=... stuff in my kernel boot line, and if you look at the source for the mdadm hook you'll see that during the mkinitcpio phase (here /lib/initcpio/install/mdadm runs---that's the source I'm referring to) it copies over any /etc/mdadm.conf you've set up to the init ramdisk. Then during the boot phase (here /lib/initcpio/hooks/mdam runs) it will try to read that file from the ramdisk. If it can't find it then it will fall back to the md=... stuff in the kernel boot line, to _create_ such a file.

So it's just not true that the md=... stuff is needed for the correct operation of the mdadm hook. Why you weren't able to get going without it I don't know. I expect you failed to do one of the following steps:
1. get all of your raid disks assembled, and so visible to the running system
2. mdadm -D --scan >> /etc/mdadm.conf
3. add mdadm to the HOOKS array in /etc/mkinitcpio.conf
4. then run mkinitcpio -p kernel26

Are you sure that you had done 1 and 2? Take a look at /etc/mdadm.conf on the running system before running "mkinitcpio -p kernel26"---do your raid disks show up there as you expect them to?

Now, you've got everything running so I can understand if you just want to let it alone. But the docs shouldn't be changed to say that doing this properly requires the kernel boot parameters. It doesn't.

EDIT: Sorry, I didn't mean for this to sound as snarky as I think it does. It also took me a while to get the mdadm hook set up properly the first time, too, and I expect you're right that the docs probably could be better and more consistently up-to-date than they in fact are.

Last edited by Profjim (2009-09-03 20:31:09)

TomB17 · 2009-09-03 21:14:42

Thanks, Jim. :)

I believe the array was not stable when I booted it. It was in the process of reshaping but, as the process takes a couple of days on a serious array, it would be nice if it could boot in an unstable state and simply begin to reshape or do whatever it needs to. What if a disk were to go sour? The server wouldn't boot?

I appreciate the input. Don't worry about snarking. I didn't interpret it that way. You were kind enough to help and I have no doubt the information you've provided will improve my configuration.

I am going to fiddle with it and see if I can get it to boot without the "md=" bit. The array should be stable sometime before tomorrow morning. I won't willingly boot before that but tomorrow will be here soon enough. I'm working on getting to a 10 x 1.5TB disk array so I expect to have another month, or so, of rebuilding. Each disk that is added increases the reshape time significantly. I don't mind rebooting between disk additions, though.

I was offering, and it is still open, to inject some documentation into the Arch stream. I've got everything I've done written down so I could put together the required steps, buff and polish them a bit, and offer them for potential injection into the wiki, default mkinitcpio.conf, etc.

I've got another machine to build so I could easily test the docs.

Last edited by TomB17 (2009-09-03 21:15:21)

ruscook · 2009-09-03 21:26:22

I have a question about using RAID solely on USB drives. Seems to be related to this problem.

Currently my /home is a usb 1TB hard drive. When I boot the system it can appear as /dev/sdh /dev/sdd etc depending upon what other drives I have installed at the time. It is mounted ok as I'm using the UUID in /etc/fstab.

How can we use a md=0,/dev/sda1,/dev/sdb1 type syntax in GRUB when you don't know which USB devices will become /dev/sda /dev/sdb etc?

Russ

lilsirecho · 2009-09-03 21:52:23

Perhaps my experience with mdadm will give you some help.

I setup raid0 with mdadm for the existing devices having raid installed from a previous HDD install.

When setting up these devices, the following commands are used:

mdadm --assemble /md0 /dev/sd{xxxx]     ....Note: xxxx could be bcde for example

This command follows:

mdadm -D --scan >> /etc/mdadm.conf

This enters the array data in the /etc/mdadm.conf file.

Ensure that mdadm is in mkinitcpio HOOKS and then run:

mkinitcpio -p kernel26

This places the array data in initramfs.

This completes the setup.

My experience with this method is as follows:

Regardless of the port to which the raid device(s) are connected the boot sequence finds the devices and assembles them as raid0. I have interchanged the devices on my system and even changed the number of devices and the system assembles raid0 (without re-issuing mkinitcpio which indicates it looks for raid0 data in intramfs).

Perhaps this isn't as clear as mud?

I assume that USB devices will also be handled similarly to those I use which are sata adapters to CF devices. Raid arrays are purported to be "mixable", some hdd, some sata some CF..etc.

Fstab completes the mount of md0 with proper entry therein.

EDIT: My understanding of the system with mdadm (supercedes "raid") is that the entry in grub is not required since mdadm places the data in initramfs automatically.

Last edited by lilsirecho (2009-09-03 21:54:37)

TomB17 · 2009-09-03 22:16:09

ruscook wrote:

I have a question about using RAID solely on USB drives. Seems to be related to this problem.
Currently my /home is a usb 1TB hard drive. When I boot the system it can appear as /dev/sdh /dev/sdd etc depending upon what other drives I have installed at the time. It is mounted ok as I'm using the UUID in /etc/fstab.
How can we use a md=0,/dev/sda1,/dev/sdb1 type syntax in GRUB when you don't know which USB devices will become /dev/sda /dev/sdb etc?
Russ

lilsirecho covered it but I'll add my $0.02.

I think the point behind getting the "md=X,/dev/sd*..." notation out of the grub config, as Jim has shown, is that it allows physical device names to change without breaking the array. This is exactly what you're asking for.

In a RAID array, all physical components in the stripe set have the same UUID. By identifying the array by the UUID, the stripe set can be found on any physical device name.

Here are my arrays, as they are built so far (From blkid):

/dev/sda2: UUID="5236b07c-a0bb-e5cd-78a8-0cbe7c6d4f5b" TYPE="linux_raid_member"
/dev/sdc2: UUID="5236b07c-a0bb-e5cd-78a8-0cbe7c6d4f5b" TYPE="linux_raid_member"
/dev/sdd2: UUID="5236b07c-a0bb-e5cd-78a8-0cbe7c6d4f5b" TYPE="linux_raid_member"
/dev/sdb2: UUID="5236b07c-a0bb-e5cd-78a8-0cbe7c6d4f5b" TYPE="linux_raid_member"
/dev/sdf2: UUID="5236b07c-a0bb-e5cd-78a8-0cbe7c6d4f5b" TYPE="linux_raid_member"
/dev/sde2: UUID="5236b07c-a0bb-e5cd-78a8-0cbe7c6d4f5b" TYPE="linux_raid_member"
/dev/md0: UUID="d4a84503-e555-4dff-8b50-b6f427792ab5" TYPE="ext3"

/dev/sda3: UUID="ba690861-8b6e-dd5f-09d8-912ec34c29e6" TYPE="linux_raid_member"
/dev/sdc3: UUID="ba690861-8b6e-dd5f-09d8-912ec34c29e6" TYPE="linux_raid_member"
/dev/sdd3: UUID="ba690861-8b6e-dd5f-09d8-912ec34c29e6" TYPE="linux_raid_member"
/dev/sdb3: UUID="ba690861-8b6e-dd5f-09d8-912ec34c29e6" TYPE="linux_raid_member"
/dev/sdf3: UUID="ba690861-8b6e-dd5f-09d8-912ec34c29e6" TYPE="linux_raid_member"
/dev/sde3: UUID="ba690861-8b6e-dd5f-09d8-912ec34c29e6" TYPE="linux_raid_member"
/dev/md1: UUID="4b3623b6-07e9-400b-a723-76fab8babb2e" TYPE="ext3"

/dev/sdi1: UUID="fe9d0e42-5708-2602-90a4-80cd934efd68" TYPE="linux_raid_member"
/dev/sdj1: UUID="fe9d0e42-5708-2602-90a4-80cd934efd68" TYPE="linux_raid_member"
/dev/sdk1: UUID="fe9d0e42-5708-2602-90a4-80cd934efd68" TYPE="linux_raid_member"
/dev/sdl1: UUID="fe9d0e42-5708-2602-90a4-80cd934efd68" TYPE="linux_raid_member"
/dev/md2: UUID="3509e78d-eb86-4a6c-b24c-fe28beae2d57" TYPE="ext3"

You'll notice each member in an array has the same UUID (but the array itself has a different UUID).

Here are my array definitions from mdadm.conf:

ARRAY /dev/md0 level=raid5 num-devices=6 metadata=0.90 UUID=5236b07c:a0bbe5cd:78a80cbe:7c6d4f5b
ARRAY /dev/md1 level=raid5 num-devices=6 metadata=0.91 UUID=ba690861:8b6edd5f:09d8912e:c34c29e6
ARRAY /dev/md2 level=raid5 num-devices=4 metadata=0.90 UUID=fe9d0e42:57082602:90a480cd:934efd68

Last edited by TomB17 (2009-09-03 22:25:11)

lilsirecho · 2009-09-03 22:36:41

Just a side note:
Amazing what the modern systems have available.

In terms of storage, terabytes "raided".

One aspect of such system setups with terabyte raid, is the problem of retrieval. Soon, there will be pentabytes and the retrieval gets even more challenging. The speed of the system may not be satisfactory even with raid arrays. Special algorithms might do the trick.

Data management has their hands full with retrieval problems in large storage systems. I hope I don't have to face that problem!!

Good luck with the raid arrays.............

ruscook · 2009-09-03 22:53:54

Thanks for the reply guys.

ah so if I have what you're saying correct the basic steps are:

1) Build the array of working/connected USB devices
2) assemble the array
3) use mdadm -D --scan >> /etc/mdadm.conf to get raid data into a file that mkinitcpio can use
4) run mkinitcpio to get the raid data from /etc/mdadm.conf to the initramfs system so /dev/sda1,/dev/sdb1 grub line is NOT needed.

What does go in the grub menu.lst line?
At the moment for my non-raid system I have: kernel /vmlinuz26 root=/dev/disk/by-uuid/ded38286-190b-403c-b3ca-3815e5c8d8d0 edd=off usb-storage.delay_use=1 rootdelay=4 ro vga=775
Do I just put the uuid of the boot raid device (if md0) into menu.lst?

If so then using this one from your example Tom: /dev/md0: UUID="d4a84503-e555-4dff-8b50-b6f427792ab5" TYPE="ext3"

5) edit grub menu.lst from kernel /vmlinuz26 root=/dev/disk/by-uuid/ded38286-190b-403c-b3ca-3815e5c8d8d0 edd=off usb-storage.delay_use=1 rootdelay=4 ro vga=775
to kernel /vmlinuz26 root=/dev/disk/by-uuid/d4a84503-e555-4dff-8b50-b6f427792ab5 edd=off usb-storage.delay_use=1 rootdelay=4 ro vga=775

Have I got it right or am I still missing something?

Russ

lilsirecho · 2009-09-03 23:21:20

The menu list does not need any md reference anywhere if you have the mdadm raid data entered into initramfs per the procedure you have listed.

Good luck..............

Profjim · 2009-09-04 01:01:11

ruscook wrote:

What does go in the grub menu.lst line?
At the moment for my non-raid system I have: kernel /vmlinuz26 root=/dev/disk/by-uuid/ded38286-190b-403c-b3ca-3815e5c8d8d0 edd=off
usb-storage.delay_use=1 rootdelay=4 ro vga=775
Do I just put the uuid of the boot raid device (if md0) into menu.lst?

You can't use a raid device as a /boot partition [note]; but I think what you mean here is "root" i.e. "/" not "boot." Yes, you just need to put "root=X" into your kernel boot line, where X is some path that will refer to the root device, after your raid disks have been assembled by the mdadm hook. So X could be "/dev/md0" or it could be "/dev/disk/by-uuid/blahblahblah" if you prefer. I don't see any downside to using the /dev/md0 notation here; that's defined by your /etc/mdadm.conf file and so isn't going to get renumbered unexpectedly. But from what's reported above, it looks like you could also use the uuid notation if you prefer.

[note] If you've got raid 0, you _can_ use one of its component partitions as /boot during boot-time, and then mount them all together as the raid 0 device during normal runtime. But anyway, I think you mean to be talking about using a raid device for /.

Last edited by Profjim (2009-09-04 01:01:33)

Profjim · 2009-09-04 01:06:02

TomB17 wrote:

I believe the array was not stable when I booted it. It was in the process of reshaping but, as the process takes a couple of days on a serious array, it would be nice if it could boot in an unstable state and simply begin to reshape or do whatever it needs to. What if a disk were to go sour? The server wouldn't boot?
...
I am going to fiddle with it and see if I can get it to boot without the "md=" bit. The array should be stable sometime before tomorrow morning. I won't willingly boot before that but tomorrow will be here soon enough. I'm working on getting to a 10 x 1.5TB disk array so I expect to have another month, or so, of rebuilding.

I think this has already been cleared up, but the raid array doesn't to my knowledge need to be settled, just assembled. That is, once you've done:

mdadm --assemble /md0 /dev/sd[abcd]

or whatever, you should then be able to right away do:

mdadm -D --scan >> /etc/mdadm.conf
<add mdadm to /etc/mkinitcpio.conf  HOOKS array>
mkinitcpio -p kernel26
<adjust kernel parameters in /boot/grub/menu.lst>
<reboot>

lilsirecho · 2009-09-04 03:41:51

One last comment on the mdadm system.

If you remove /etc/mdadm.conf (trash) before you run:

mdadm -D --scan /etc/mdadm.conf

The assembled raid array will be entered in a new /etc/mdadm.conf file with just the array data provided...the many commented out items will be gone.

TomB17 · 2009-09-04 13:00:55

The array stabalized and I was able to reboot with the following entry in my menu.lst:

# (0) Arch Linux
title Arch Linux
root (hd0,0)
kernel /vmlinuz26 root=/dev/md0 ro
initrd /kernel26.img

$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md2 : active raid5 sdi1[0] sdg1[3] sdh1[2] sdk1[1]
2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md1 : active raid5 sda3[0] sdf3[5] sde3[4] sdc3[3] sdd3[2] sdb3[1]
7252222400 blocks level 5, 64k chunk, algorithm 2 [6/6] [UUUUUU]

md0 : active raid5 sda2[0] sde2[5] sdf2[4] sdd2[3] sdc2[2] sdb2[1]
52451840 blocks level 5, 64k chunk, algorithm 2 [6/6] [UUUUUU]

Thank you very much to everyone in this thread. I really appreciate the help.

lilsirecho · 2009-09-04 17:02:38

Well done!!!

Arch Linux

#1 2009-09-02 15:55:36

[SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#2 2009-09-02 16:00:19

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#3 2009-09-02 16:37:44

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#4 2009-09-02 17:06:20

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#5 2009-09-02 18:47:04

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#6 2009-09-03 02:31:39

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#7 2009-09-03 10:53:03

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#8 2009-09-03 16:42:26

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#9 2009-09-03 20:19:56

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#10 2009-09-03 21:14:42

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#11 2009-09-03 21:26:22

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#12 2009-09-03 21:52:23

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#13 2009-09-03 22:16:09

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#14 2009-09-03 22:36:41

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#15 2009-09-03 22:53:54

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#16 2009-09-03 23:21:20

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#17 2009-09-04 01:01:11

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#18 2009-09-04 01:06:02

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#19 2009-09-04 03:41:51

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#20 2009-09-04 13:00:55

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

#21 2009-09-04 17:02:38

Re: [SOLVED] usb /boot, RAID5 /root, mkinitcpio.conf help request

Board footer