Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Mon Nov 20, 2017 1:00 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Thu Sep 01, 2011 6:49 pm 
Offline
Total Newbie

Joined: Thu Sep 01, 2011 5:03 pm
Posts: 2
Allow me to preface this by saying that I am currently residing in Nowhereville, SW Asia, with filtered Internet access that is spotty at best. I also have to make do with what I have, as IT requisitioning out here is an arduous process.

I have 4 Buffalo TeraStation Duos (TS-WX2.0TL/R1, firmware ver. 1.52). My goal is to connect these to a low-traffic LAN that requires a high volume of storage. The boss would like to see these presented as one giant share accessible by both Windows and *NIX systems (specifically, Mac and Linux).

Problem 1: I need to be able to access them all from a server that has one LAN port free. I do not have any routers, switches, or hubs available at this time.

My initial solution was to daisy chain the routers by bridging LAN1 and LAN2 on each TeraStation. In theory, this should work, but I was unable to find a way to set up bridging (I found bonding) in the web administration system. I then focused on gaining SSH access to the TeraStation, which led me to this site. I wish I could use acp_commander, but alas my proxy blocks the download of binaries. I had hoped that the process described by brighton36 in The Official TS-WX1.0TL/R1 Thread would help, which brings me to…

Problem 2: I need be able to access the TeraStations via SSH, but I cannot download acp_commander.

I took out the two 1TB drives from the NAS and mounted them in two separate external USB enclosures connected to my laptop running Maverick Ubuntu. I have VirtualBox loaded, with the Live-CD’s of several distributions ready to load up on a blank VM. I tried out Scientific Linux 6 first. It had no problem identifying the drives or the RAID volumes held on each. I found that /dev/sd[ab]2 was the root (/) mount point for the firmware, and so I used the GUI to assemble the RAID 1 array. I then proceeded to mount the array and go to work enabling SSH. I changed the root password in /etc/shadow and modified the sshd_config and pam.d files as instructed by brighton36 in the aforementioned thread. I then unmounted the array and stopped it using mdadm, and then powered off each drive and returned them in their original order back into the TeraStation. When I booted the NAS, however, I was greeted by a RED error screen after about 30-45 seconds, stating “NO ARRAY INFO.”

I decided to probe deeper into the cause, so I updated the firmware (in debug mode so as to rewrite the partition table and start fresh) and found that even mounting the assembled array in read only mode (mount -o ro) would cause the “NO ARRAY INFO” error.
My best guess is that mdadm is mucking about with the disks in such a way as to disrupt a very finicky Buffalo firmware from rediscovering its RAID arrays. Maybe there is a difference between the way software and hardware RAID systems utilize/format the superblocks? This is pure conjecture, which is why I am attempting to draw upon the expertise in this forum for the answer.

There is of course the issue of making a single share, but I will consider myself home free if I can get SSH access on the Buffalos.

I apologize if the answer is hiding in plain sight somewhere, but I usually have time to go make coffee by the time this 10-20Kb/s connection downloads a Google search results page.

Edit: I realized that the above was a bit wordy, so for the TLDR crowd:

I need to be able to access SSH on my TS-WX2.0TL/R1 (fw ver 1.52) without using acp_commander, because I cannot download it. This means making modifications to the drives out of the NAS (attached via USB enclosures). Every time I mount the raid array, even in read only mode, the array becomes unreadable to the Buffalo and it reports "NO ARRAY INFO."
I have no data on the drives to worry about.

Thanks in advance for the help, and I look forward to posting HOWTOs and other information about this if they don't exist already.


Top
   
PostPosted: Fri Sep 02, 2011 8:35 pm 
Offline
Total Newbie

Joined: Thu Sep 01, 2011 5:03 pm
Posts: 2
I took out the drives from the TS and put them in two separate USB external enclosures connected to my Maverick Ubuntu laptop as sdf and sdg. I was testing to see how far I get before the array became unreadable to the TS firmware.
I then ran the following commands:

Code:
sudo mdadm -A /dev/md0 /dev/sdf2 /dev/sdg2
sudo mdadm -S /dev/md0

I put the drives back in the TS, and it booted up fine. Just assembling the RAID 1 array offline does not seem to have an effect, so I continued to test...

Next on the docket, mounting the md0 device in readonly mode.

Code:
mke2fs -n /dev/sdf2
This revealed that the block size was 4k and that there were superblock backups stored. I chose the first backup, stored at 32768, which multiplied by 4 is 131072.

Code:
sudo mdadm -A /dev/md0 /dev/sdf2 /dev/sdg2
sudo mount -o ro,loop,sb=131072,barrier=1 /dev/md0 /mnt/buffalo

The device failed to mount... dmesg reveals that the ext3 filesystem requires recovery, but it is unable to do so:

Quote:
JBD: Ignoring recovery information on journal
queit_error: 236 callbacks suppressed

Buffer I/O error on device loop0, logical block 0
lost page write due to I/O error on loop0

These last two continue errors continue for blocks 1, 309, 810, 33108, 33109, 33110, 33111, 33113, 33114. The failed mount finished with:

Quote:
JBD: recovery failed
EXT3-fs (loop0): error loading journal

My limited Linux-foo coupled with my unbearably slow connection stumped me here, so I proceded to continue mounting without the loop device.

Code:
sudo mount -o ro,barrier=1 /dev/md0 /mnt/buffalo

This worked fine, but a check of dmesg shows that JBD was "fixing" the journal behind the scenes:

Quote:
EXT3-fs (md0): recovery required on readonly filesystem
EXT3-fs (md0): write access will be enabled during recovery
kjournald starting. Commit interval 5 seconds
EXT3-fs (md0): recovery complete
EXT3-fs (md0): mounted filesystem with ordered data mode

I suspected that the array was lost to the Buffalo, but I loaded the drives in it anyways. Lo and behold, the TS balked and said "NO ARRAY INFO."

If anyone knows why the each system's journal is unreadable to the other, please let me know. I have actually solved my original issues (I will post again with my solution), so further probing into this issue is now academic.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 2 posts ] 

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited