Author |
Message |
Efvin
|
Posted: Mon Dec 21, 2009 9:01 pm |
|
Joined: Fri Dec 01, 2006 9:14 pm
Posts: 28
Location:
Hiding behind a shrubbery
|
All,
Got a bit of a transition issue here. Have an old Highpoint 1820A that I was find with just running through and compiling before on r5.5 but r6 isn't being so nice. I see the transition over to Pacman has occurred and for the life of me I can't get the system to compile any further.
make -C /lib/modules/2.6.28-LinHES/build SUBDIRS=`pwd` modules
make[1]: Entering directory `/usr/src/linux-2.6.28-LinHES'
CC [M] /root/downloads/hpt.o
In file included from /root/downloads/hpt.c:310:
/root/downloads/gui_lib.c: In function âget_bdevâ:
/root/downloads/gui_lib.c:101: error: too many arguments to function âblkdev_getâ
/root/downloads/gui_lib.c:105: error: too few arguments to function âblkdev_putâ
/root/downloads/gui_lib.c: In function âsd_inuseâ:
/root/downloads/gui_lib.c:118: error: too few arguments to function âblkdev_putâ
/root/downloads/gui_lib.c: In function âget_sd_nameâ:
/root/downloads/gui_lib.c:2630: error: too few arguments to function âblkdev_putâ
make[2]: *** [/root/downloads/hpt.o] Error 1
make[1]: *** [_module_/root/downloads] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.28-LinHES'
make: *** [hptmv.ko] Error 2
I do hope there is someone a bit more knowledgeable than I that can help. I'd rather not lose the array and have to start using mdadm to create a new array. I have had too many issue with mdadm in the past to care to find myself resorting back.
|
|
Top |
|
|
Efvin
|
Posted: Fri Dec 25, 2009 12:17 am |
|
Joined: Fri Dec 01, 2006 9:14 pm
Posts: 28
Location:
Hiding behind a shrubbery
|
Ok, looks like I found the issue and I am betting I will not be the first to have this take place. What it looks like happened was that the original raid array was created using /dev/sd[abcd]1. With the switch to Arch Linux my existing IDE drive is now listed as /dev/sda as opposed to /dev/hda. This is causing MDADM upon rebuild and examine as showing /dev/root, /dev/sdb, /dev/sdc, /dev/sdd. The system is still looking for /dev/sda as the '0' device in the raid.
Would anyone have any suggestions on trying to recover this array? I am aware that this is not exactly an issue that pertains directly to LinHES but if anyone has any ideas it would be greatly appreciated.
|
|
Top |
|
|
mudguts
|
Posted: Thu Dec 31, 2009 3:04 pm |
|
Joined: Wed Feb 08, 2006 8:31 pm
Posts: 20
Location:
Canberra Australia
|
There would be a file, possibly mdadm.conf in /etc, which would contain the list of drives which are used for the raid device. You could possibly try to edit it to address the new drive names.
Another thing to try is reassemble the raid device by using "mdadm --assemble /dev/md0 /dev/sd[2,3,4,5]". I'd probably try this first.
Good luck.
_________________ BE - GA-K8NSC-939 M/B, AMD Dual 3800 CPU, 1Gb RAM, 1 x WD3000JB, 1 x WD3200JB in LVM, 3 x Dvico Lite/Home tuners, 6200 256Mb video card, old server box
FE - MB TBA, AMD 3300 Sempron CPU, 1Gb RAM, Seagate 80 Gb HD, 6200 256Mb video card
|
|
Top |
|
|
Efvin
|
Posted: Thu Dec 31, 2009 6:03 pm |
|
Joined: Fri Dec 01, 2006 9:14 pm
Posts: 28
Location:
Hiding behind a shrubbery
|
Yeah, tried and failed. I migrated all the data to an external and re-initiated the array. 'mdadm.conf' will not work with the system to define the array correctly. The block devices are not properly recognized as when the initial raid is created if it is not done so using UUID mdadm expects the devlabel system to be in use. What was taking place is that the master drive in the array was reporting to the OS as /dev/sda which conflicted with the new /dev/sda. This is a problem with reliance on the dev labeling system.
Anyone that migrates to r6 that is using anything similar to my setup should look into relabeling the drives prior to upgrade so that they fall in line with the new system. I do not know if that will break anything but ... then again I should have used UUID when creating the array and not the devlabel.
|
|
Top |
|
|