Difference between revisions of "Moving disks"

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search
m (1 revision(s))
(Undo revision 30081 by Roderio (Talk))
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{Template:Articles|Terastation}}
 +
 
== A Word of Warning ==
 
== A Word of Warning ==
  

Latest revision as of 09:18, 7 February 2011


Contents

A Word of Warning

Moving the disks to a regular i386 PC does not work.

As far as I can tell it's not possible to recognize the RAID devices from big-endian (PowerPC) systems on little-endian (i386) systems. Much less activate them.

You will get an error like:

invalid raid superblock magic on ...

This is, of cause, not realy a problem for the RAID1 partition, used for the system partition. There the mirrored data is the same on all devices. So you can access and mount it. But you should now write to them. The data will not be mirrored, and I don't know what will happen if the Terastation reads blocks from the "old" disks. So while it will work to bypasse the RAID layer and access the disk directly, all the documentation about MD tells you to never ever do this.

For RAID5 its more problematic. There the data can not be read with out activating the RAID. To activate it the superblock magic must be correct, if you read the complete error message you can see how the data is mixed up.

On a PowerPC system, e.g. an old Mac, you can use any Linux Live CD to activate the RAID and than backup you data. I've done so with a Mac mini, an Ubuntu Live CD and 4 USB to IDE adapters. Worked splendidly.

YMMV, it's your data after all.

--Bg 17:34, 9 October 2006 (CEST)

Just the System partition

The following users have accessed the system partition bypassing the RAID/MD layer (newest first):


Scott

I apparently tossed my TS into E-M mode. Prior to figuring that out (when in E-M mode, the device has no open ports, contrary to my expectation, so I thought it was bricked), I was able to access the /dev/hda1 partition using Knoppix on my Intel-based laptop, with the Terastation's drive mounted in a USB external drive case.

In this config, the drive is /dev/uba1, and Knoppix helpfully provides a /mnt/uba1 mount point.

mount -t xfs /dev/uba1 /mnt/uba1

works splendidly. If you have an external drive case for a 3.5" drive, I highly recommend this method for accessing the Terastation's drives; it is a lot nicer than plugging into the internal IDE bus on a PC.

--Scott 22:29, 11 Sep 2005 (CEST)]

Lh1

I was able to mount a corrupted system's /dev/hda1 system partition on an Intel system after running

xfs_repair -L 

to zero out the log.

Since I was overwriting the volume (untarred a fresh system image) there wasn't any risk of corruption. After installing the files on one drive, the system synced itself back up automatically once back in the TeraStation.

That way I didn't have to touch my RAID5 data volumes which would have been riskier.

--Lhl 19:10, 8 Aug 2005 (CEST)


Yvasilev

The root file system can be mounted on little endian systems with

# mount -t xfs /dev/os_disk1 /mnt/teraroot

bypassing RAID1 setup.

--Yvasilev 17:47, 1 Aug 2005 (CEST)

My original idea

Update: 20061009, see above why this does not work. This section was written befor we knew the passwords to the update zip-files. --Bg 17:34, 9 October 2006 (CEST)

This is just an idea.

I've not tried this yet.

Unlike the kernel and the initrd, which reside in flash, the rest of the firmware is on the harddisks.

The harddisks are partitioned like this:

root@HD-HTGLxxx:/# sfdisk -l /dev/hda

Disk /dev/hda: 30515 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/hda1          0      47      48-    385528   fd  Linux raid autodetect
/dev/hda2         48      64      17     136552   82  Linux swap / Solaris
/dev/hda3         65   30377-  30313- 243481141   fd  Linux raid autodetect
/dev/hda4      30377   30514     138-   1108484   fd  Linux raid autodetect

and the same for hdc, hde, hdg.

If you use the RAID5 setup the RAID-table looks like this:

root@HD-HTGLxxx:/# cat /proc/mdstat 
Personalities : [linear] [raid1] [raid5] [multipath] 
read_ahead 1024 sectors
md0 : active raid1 hdg1[3] hde1[2] hdc1[1] hda1[0]
      385408 blocks [4/4] [UUUU]
      
md1 : active raid5 hdg3[3] hde3[2] hdc3[1] hda3[0]
      730443072 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

So the root filesystem is on md0, what is RAID1 made of 4 identical partitions: hda1, hdc1, hde1, hdg1.


If we had a linux system with 4 unused primary IDE channels, we could move the whole disk array to it and activate the complete RAID-array there. Do this if you can. Most likely you have just one IDE channel to spare. That's not a problem, as the RAID should handle the (temporary) loss of 3 mirrors. Once you reassemble the TeraStation, the RAID should reconstruct itself. I did not try it, maybe it does not. Still once you have root access, you can fix it manually.

You will need RAID support in the kernel in either case. And you need XFS support, too.

Lets assume we move just one disk (disk1, hda) to our linux system. We've removed the cd-rom first, so the disk becomed hdc.

I've not done this, it's just from memory ... well, actually imagination!

root@linux:~# mdadm -E /dev/hdc1
/dev/hdc1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : xxxxxxxx:yyyyyyyy:zzzzzzzz:aaaaaaaa
...

The partition has the proper magic and we got the UUID. Lets assembly the device

root@linux:~# mdadm -A md0 -u xxxxxxxx:yyyyyyyy:zzzzzzzz:aaaaaaaa -f /dev/hdc1 --readonly

This should create a soft-RAID device (/dev/md0) with 3 missing drives. That's what we expected and it's readonly so nothing will get messed up. Now lets mount it

root@linux~# mount -o ro -t xfs /dev/md0 /mnt/terastation

Again, read only. If you succseeded, please mail me a bzip2ed ls -laR

root@linux:~# cd /mnt/terastation
root@linux:/mnt/terastation# ls -laR > /tmp/ls-laR-terastation
root@linux:/mnt/terastation# bzip2 /tmp/ls-laR-terastation
root@linux:/mnt/terastation# # mail /tmp/ls-laR-terastation to bg

you can also check out /etc/linkstation_release but that's most likely incorrect.

root@linux:/mnt/terastation# cat etc/linkstation_release 
PRODUCTNAME=HD-HTGL(YOSHIMUNE)
VERSION=1.03
SUBVERSION=HDD 6.0 EN
PRODUCTID=0x0000xxxx
BUILDDATE=2005/02/17 20:34:08

Once you've had enough, unmount and disable the array

root@linux:~# umount /mnt/terastation
root@linux:~# mdadm -S /dev/md0

Move the disk-array back to the TeraStation, reassembly it and pretend nothing has happened.

If you feel brave you can redo the soft-RAID activation and the mounting without the read only flag and start messing with the firmware.

You could add Dropbear but don't forget the sudoers file

root@HD-HTGLxxx:~# cat /etc/sudoers 
admin  ALL = (ALL) ALL

BTW: If you do this, please make me a .tar.bz2 backup of your original TeraStation firmware. Espcially if you have a post 1.04 version. Place it to some FTP, or ask me for one. Don't mail it to me. It's about 40MB, no a size you mail.

BTW2: Once you have access to your TeraStation, be it serial console or ssh, you can find out the real version of the firmware by

root@HD-HTGLxxx:~# cat /proc/linkstation 
PRODUCTNAME=HD-HTGL(YOSHIMUNE)
VERSION=1.04
SUBVERSION=FLASH 2.0
PRODUCTID=0x00002001
BUILDDATE=2005/1/24 14:22:36