Buffalo NAS-Central Forums

First of all, thanks for all the info on this site and boards - it has helped me some of the info Buffalo should be giving to it's users as well narrow down what I do and don't know.
Some background and my problem - my experience with TSs consist of full setups as well as replacing drives in everyone I've run across (5 total). Yesterday I was handed a 1.6 R5 (1.12 firmware) that as best I can tell has a motherboard/memory/flash error and as thus is completely unusable. Symptoms and problems:
*Diag LED flashes between 3-4 times a second (how the hell can you accurately count flashes that quickly?)
*HDD ACCESS LEDs all consistently flash red
*No web management access
*Windows client utility can connect but is unable to renew/flash the BIOS. Attempting to renew the BIOS to the installed version brings up a dialog box in some foreign language. Trying to upgrade ( version 2. something ) prompts for a password, that no matter what, I am unable to provide. I've tried the INIT button, safemode, every password permutation you can image, but no luck.

I do have access to a working TS and wonder if I can just move the dead machines drive caddy to the working TS and backup the data. My concern:
*Is the user/group/data SAMBA config (my assumption) all stored on the drives, or in the onboard flash, or a combo of both? My fear is that some of the mount points/config/etc. is stored in the flash and when I hook up a directory structure to a config that doesn't match EVERYTHING will go down the tubes and I'll be stuck with 2 dead, appropriately named TerrorStations.

Has anyone done this before? If this is possible, I'd much rather do it this way than to find a PC and run UFS Explorer.
Advice?

Thanks,
Eric

The blinking pattern should consist of a number of blinks followed by a pause and then the pattern repeated. The number of blinks indicates the error type (as indicated in the "Troubleshooting" section of the manual. If it is 4 blinks then that indicates a potential fan problem - so you might want to check that the fan is spinning. A flash problem is indicated by 5 blinks (although other things can also cause 5 blinks to happen).

The fact that you can get as far as seeing the TS in the client utility suggests that the flash is OK, as to get that far the system must have booted linux from the flash and have been trying to switch to running the system from the hard disks.

Config information is held in both flash and on the hard disk. The flash copy is used to preserve settings while updating firmware and the disk copy is used during normal running.

Changing the disk cage between systems is unlikely to work in this case as it sounds as if the problem is with the disk contents - not the flash.

Are these all PPC based Terastations (the instructions below assume this)? If so then as you have access to multiple terastations my suggestion would be to proceed as follows:

• remove each disk in turn and attach it via external USB box to existing terastation
• mount partition 1 of each disk
• change to the mounted partition
• do a 'rm -r *' command to recursively remove all files. Make sure you are at the right place before doing this as you do not want to remove any files from the good system.
• unmount the partition 1, and put the disk back into the TS it came from at the same position in the cage.
• When all 4 disks have been done, reboot the TS and it should come back up in EM mode.
• Reflash - it should allow this to happen in recovery mode that does not need a password. Make sure that you use firmware that is enabled for telnet+root access so that if recovery is successful you can then get in to change the (unknown) password on the admin user. You can get telnet enabled variants of firmware via the links at my web site (http://homepage.ntlworld.com/itimpi/buffalo.htm). They are available for most of the Buffalo firmware releases.

Hope that helps?


The above process only touches partition 1 of each disk, so even if it is unsuccessful you should not have touched the data on partition 3 of each disk.

I see what you mean about the blinks, but there is no pause on the DIAG LED as far as I can tell -it's a constant blinking without interruption.

Both TSs are PPC based, but does your reply assume I have a telnet enabled (modified) firmware installed? This only has a factory installed FW and due to the risk of flash upgrades, I am unable to upgrade (it's running some critical production data). Factory FW 1.12 doesn't allow shell access where I could perform Linux commands does it?

Thanks for the quick response,
Eric

I am not sure what continual blinking means - it is not one of the modes listed in the documentation. It could indicate something that is not easily recoverable. Can Buffalo support help here at all to at least tell you what that light pattern means?

My instructions did assume you had telnet enabled firmware on your good TS (doesn't everyone ). I know many people who ahve used telnet enabled firmware on production systems because of the extra control it give them. However I understand the reluctance to touch a currently working system.

I assume you can put telnet enabled firmware onto the damaged TS as part of the recovery process? You could always flash it back to standard firmware afterwards if needed. If you do not have a telnet enabled TeraStation, then you can do the same thing on a PC running linux. If you do not want to install linux on the PC hard disk use one of the "Live" CD distributions which run from CD/DVD. I use the Fedora one, but others should work just as well.

Unfortunately I can't flash the damaged TS - that's where all the screwed up error messages and password problems keep cropping up.
However, I think I understand your direction with Linux - individually mount the drives from the damaged TS on a working Linux box and wipe out the user data on partition 1, correct?

If I could only flash the firmware...

Eric

i suppose your box isn`t in EM Mode? try to boot the box with all hdds disconnected.

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!

If you read my instructions carefully, you will see that the approach I recommend allows for flashing in "recovery mode" for which you do not need to know the admin password. However at the end of the flash the 'admin' user password is restored from the value saved to flash which is why I said you would need a telnet enabled version of the firmware if you subsequently want to be able to administer the TS. That firmware sets up the 'myroot' user which has root access privileges and can thus telnet in and change the password for the 'admin' user.

itimpi:

Are you referring to using the INIT button to reset the password/enter safe mode? If so, I have attempted this quite a few times, but it is possible it might have not done it correctly.

mindbender:

I might have not tried it without the drives. Unfortunately I'm away from the unit for the next few days, but I will give that a try as soon as get a chance.

No - what I am saying is that if you have removed all the files from Partition 1 as I recommend, then when you try to flash it will do it in "Recovery Mode" which does not prompt you for a password.

When it has finished the flash it will re-apply the saved setting from flash, thus putting the password (which you do not know) back onto the admin user. However if you have used one of my telnet enabled firmware releases you can then telnet in using the 'myroot' user and change the admin password.

itimpi: would it be the best approach to flash it again after changing the password then? then the new password would be stored with the saved configuration in the flash and you will never run in that situation as long as you do not forget the password again .

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!

Possibly. You certainly do not want to get back into this error situation if at all possible.

I am not sure when the configuration information gets written to the flash. It certainly happens at the start of the flash process, but it may also happen at other times. I think there is also a Buffalo supplied command that can be run to make this happen - I must look at the scripts used by the flashing process. If so that could be run from a telnet session.

In this particular case there may be a desire to revert to standard Buffalo firmware when things have been recovered in which case the reflash would be done for that reason.

OK, I finally got back to working on my 'problem child'. I tried to start the machine minus all drives as suggested by mindbender - it was never able to get far enough access the network, so I couldn't refresh or update the flash.

While looking through the forums under Data Recovery, I did see the exact dialog box when I try to renew the flash:


The problem is that I can't get telnet enabled flash on the TS so I can't run xfs_repair -L /dev/md1 which seems to be correcting most of the problems. I noticed on the Data Recover forum that using a PPC based Mac running Ubuntu is required to run xfs_repair off the TS - has anyone found a way around this?

Does it look like I'm stuck using the Windows UFS Explorer solution? If so, will it work if I connect the four drives to the only 2 IDE connectors and make 2 of the drives slaves?

If you haven't noticed, I really don't want to lose this data!

Still does not sound as if you have used my method of removing all files from the first partition?

Also if you are trying to flash, you should use a version that has an English version of the Updater program so you can at least read the text of any dialogs displayed. That would be far more important than necessarily using the same version of the firmware as you would not want to miss any message that warned you that proceeding might lose data.

In terms of your data, it should be possible to make two of them slaves when attaching them to a PC and use the UFS Explorer way of recovering your data.

itimpi - You are 100% correct - deleting data off any drive is the last thing I want to do! Call me paranoid, but I've seen some strange things and made some boneheaded mistakes in my many years of being in this industry, and deleting all the data in a partition on 4 drives on a RAID configuration makes me more than a little squeamish.

Concerning the language on the error message: I got the files off the buffalotech website (US) under the discontinued products - 112-104 http://site2.buffalotech.com/support/do ... oduct2.php so I would assume it's the correct language.

My approach of deleting all the files from Partition 1 of each disk does not really delete any data files, it merely deletes system files written by the firmware. All the data is held on Partition 3 of each disk (and Partition 2 is used as Linux swap space). That is why I often tell people to use that approach. However if the data is important it cannot harm to be a bit paranoid as if you lose it there is no way back.

In terms of the language of the firmware updater - the one you used was obviously in Japanese because of the dialog you got. You may be better trying to get a firmware release from the Buffalo European site. Also, if you use one of my telnet enabled firmware releases, the web page tells you whether there is an English firmware updater available or just the Japanese variant (which is always available).