TS Live - two drives instead of four

[weldingkat]

We use several TS Live ( HS-DHTGL/R5(ANNEI) ?) as a "configuration share", allowing other devices to mount the share, load it's configuration, and be on their merry way.

 

The problem is as the several TS Live units aged, they lost hard drives and the customer is being incredibly "cheap", and doesn't want to replace the one or two dead drives per unit.  Since they don't need anywhere near the 1.5TB sized raid arrays anyway, I can't say their decision is a bad one.

 

The idea is to retain two good drives in the units and mirror them and use that as the share.  I did this, and successfully created shares on two mirrored drives, the other devices mount and load their configurations, that's all great.

 

However, the TS Live units keep beeping and indicating drive 3 and drive 4 are missing or failed, which makes sense because they're not installed.

 

I couldn't find in the gui how to disable testing/monitoring of the missing drives, so I thought maybe there was a script or configuration file that controls this.  Used acp_commander, got a telnet prompt, searched for script or configuration file.

 

Alas, I cannot find it.

 

Long winded story for a simple question - how do I "convince" the TS Live unit to only look for two drives instead of four?  Being that it's running Linux, I can't imagine for a second it's "impossible".

 

/usr/local/bin/libbuffalo looked promising, but deleting all references to disk 3 and 4 resulted in the same.

 

Any ideas?

 

Thank you in advance,

Fred

[weldingkat]

The end result is this:

 

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          37      297171   83  Linux
/dev/sda2              38          99      498015   83  Linux
/dev/sda4             100       60801   487588815    5  Extended
/dev/sda5             100         116      136521   82  Linux swap
/dev/sda6             117       60784   487315678+  83  Linux

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          37      297171   83  Linux
/dev/sdb2              38          99      498015   83  Linux
/dev/sdb4             100       60801   487588815    5  Extended
/dev/sdb5             100         116      136521   82  Linux swap
/dev/sdb6             117       60784   487315678+  83  Linux
?

I mirrored the drives in the web interface, copied data, and it's mirrored no problem

 

However, the red LED's for disk 3 and disk 4 are still illuminated, and the error light is bright red as well.

 

I found an interesting directory, /etc/melco, which seems to contain configuration files.  One in particular, /etc/melco/diskinfo, contains array and disk information so I made a minor change:

 

disk1=array1
disk2=array1
disk3=
disk4=
?

In place of a carriage return for disk3/disk4 I also tired "off" but the Terastation Live keeps checking and then complaining disk3 and disk4 are missing.

 

The LCD, upon booting, also says "HD used 1_2_3_4" so I know there are other places the number of drives is set.

 

Is that in the scripts themselves, or in some kind of central configuration file?

 

I can sftp all the scripts over and "SED" them to replace do in 1 2 3 4 with do in 1 2 if I have to, but I was hoping to avoid lobotomizing the unit in that fashion off the stock scripts.

 

 

 

[weldingkat]

Here is what I think the problem is.... at boot time, even though /etc/melco/diskinfo states to ignore drives 3 and 4, somewhere these settings are being overwritten.  I checked in the /boot/conf_save.tgz file and the settings are saved as I have defined, so that's not it I don't think.

 

Here is the log:

 

Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Disk mode was changed
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.array1=off
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.array2=off
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.disk1=normal
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.disk2=normal
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.disk3=normal
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.disk4=normal
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.usb_disk1=
Sep 20 09:24:53 HS-DHTGL68C TeraStation PRO[6076]: [Web] Change value : diskinfo.usb_disk2=
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Disk mode was changed
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.array1=raid1
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.array2=off
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.disk1=array1
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.disk2=array1
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.disk3=normal
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.disk4=normal
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.usb_disk1=
Sep 20 09:27:09 HS-DHTGL68C TeraStation PRO[9595]: [Web] Change value : diskinfo.usb_disk2= ?

 

I realize Buffalo's official policy is not to encourage non-stock solutions, as I just found an older thread on this issue so my apologies for violating the TOS trying to understand a little better the innards of these units.

 

If someone could at least point me in the right direction, I would be most grateful.  This is for a customer of mine, who has about 45 of these units, and I'd like to keep them in service.  I myself have four TS lives for my business... they make great little servers.

 

Thank you in advance,

Fred