Recover legacy Lacie NAS: network CD box 104815
 

Hi all,
I received a defective legacy Lacie NAS, type network CD box 104815 dated somewhere 2002. After substituting the switched power supply and the blower it ran again at his latest state when it was connected to an ethernet network. On the display it showed his own IP adress: 173.194.70.100 from a dhcp server.
Concluding it was working well, I brought it to a reboot through the menu on the front LCD display.

When I start it up now, it boots and shows on the display: "Trying hda1” followed by “boot kernel” followed by “ initialization” and than “ init waiting…”
At this state it is hanging. From my point of view it is waiting on an acknowledge from it's network card to tell ok I'm connected to the network.

My private network is of course dealing with 192.168.123.X, gateway on 192.168.123.253

Questions:

1 is someone in the possession of the regular recovery CD, likely to deliver me a copy on thinks like DROPBOX...

2 If not, do you see a procedure to mount for example the Hard disk from the NAS into another linux OS, followed by editing the network config file. I already read about the possible inside embedded linux file called RIMAGE.gz which is editable and where I should edit the IP adress, in order to make it part of my network? I hope then the initialization while complete.

3 I opened the box and disconnected the HD. When mounting the HD by a USB adapter into my Ubuntu 10.10, It simply doesn't see the disk. With fdisk -l I don't see nothing at all. The HD hides somehow while other similar connected HD show up. Does it deal with the fact that the disk contains a Uboot file, ready to start booting?

I'm so focused on repair of that legacy NAS, every valuable info is very welcome.

Hansie Tux

google '+linux +hibernate +encrypted' to see if encryption is the issue. I would drop the HD in a known pc and run badblocks -n on it. Should check out the disk.

Hi business kid,

Thanks for responding.
I made some progress though still have further questions.

Wile still missing the recovery CD, I could read the HD content: I simply removed the jumper ( for a master setting) on the HD IDE connector, now it's in "cable" mode and I can access.

The files I dumped are unreadable since compiled, what I expected.

Do you have a good idea how to decompile the boot image?


What I also try is to bring the NAS in a known networksegment by connecting it to my laptop with an ethernet cross cable between the two. Now I'm preparing Vm ware player with a debian6 vm machine, configured as dhcp server dealing with IP adressing in the same public segment of the NAS. I hope it will go further in it's boot session until up & running where I than can edit or wipe the IP adress so it can ask by ARP burst for another IP adress. That time it will be connected to my home router with dhcp capabilities within 192.168.123.XXX range.

Do you think this is a good idea?

In the meanwhile, if someone can deliver a copy of the recovery CD it would be helpfull and much easier!!

The laptop thing you laid out is an excellent idea
Encrypted, I imagine? Or is the disk format strange?
Decrypt? Decompile with a good assembler. Decrypt is the work of days or weeks of cpu time. I've heard of something called ighashgpu that uses the gpu to do it (faster apparently) but it's definitely not my territory.
The behaviour you describe is also consistent with PXE boot behaviour. In that case, it's looking for a Kernel to start up on, followed by an OS. The routine is
Q. Anyone there? I want a kernel
A. Boot this one.
Q. Can I have an OS please; The kernel is no use on it's own
A. Have this and shut up.
There's a good doc on the slackware dvds. My local mirror is
ftp://ftp.heanet.ie/mirrors/slackwar...ers/README.PXE

173.194.70.100 is registered to google, FYI. The idea of you having even encrypted files would be alarming to them, in most cases. A phone call or email to the right guy might get you something. . .

business kid, I wonder if there is no way I'm warned by mail when you drop a reply...that's why it takes so long before I look for your reaction.

I'm sure the Lacie NAS is standalone working, it only attends an IP adress, it's no PIXIE network boot.

173.194.70.100 is registered to google, FYI. The idea of you having even encrypted files would be alarming to them, in most cases. A phone call or email to the right guy might get you something. . .

Can you clarify your latest sentence, I don't understand what you mean. Are you saying the IP adress is not coming from the NAS?
I had one line in the log of my home router telling:

DOD TCP trigger from 192.168.X. X (which is my own connected PC ) to 173.194.70.100:80

Any idea how I can discover the IP adress in out of the NAS configuration file?

I simply ran 'whois 173.194.70.100 ' It's registered to google.

Access to 173.194.70.100:80 is asking for a web server on 173.194.70.100. The usual use of port 80 is http, although some people bend rules because port 80 is always open in firewalls.

I'll have a reply up within a day usually, if at all. I don't know why you don't get emails, I do.

"hda1" means deprecated ide driver (2.4 kernel or early 2.6, iirc). At least it's not windows :-). Can you try a few boot options? Tab or E on boot will get you something from lilo or grub. The kernel name might tell you what the distro is. I would try adding you just may be lucky enough to get somewhere. You're only beaten when you run out of ideas. Take it from someone who knows the feeling, but has dodged it for a living for a long time.

BTW, the quote or code tags make your post more readable.

OK, business kid, then I don't know the IP adress configured in the /etc/config of this embedded system.
Any suggestion how to force the NAS to publish his momentary configured IP adress?

The e-mail is a detail, I'll investigate my account + facilities on this board.

TAB E to edit the boot sequence or interrupt it is not possible since it's about an embedded system, with only a small 2 lines LCD screen.

Is this way of reply the fine one?



What I also try is to decompile and to edit the NAS boot image...not succesfull until yet.
Do you have any idea's about that?
It's another way to get access to the onscreen configuration of the NAS.

I would be very pleased if someone has an idea to decompile and edit the network config of the Linux kernel ARM boot executable zlmage ( little-endean). I cannot attache it here, since the format is not allowed, but if someone wants it to investigate I can publish it on a public folder.

Last possibility is finding a copy of the disaster recovery CD. It's the most effective solution, but until yet no one could deliver me a copy...

Plug the network card into a switch along with another box running tcpdump or wireshark? You'll find out what's going on that way. Even a crossover cable straight into something else might do it. Then you can find out what it wants.


Definitely don't want to investigate it. We don't even know the software license.

With the hard disk connected to a desktop or laptop IDE interface, are you able to read the partition table of the disk (fdisk -l)? If so, are you able to mount any partition? If so, are you able to identify some file structure that makes sense?
Trying to disassemble any binary data is pointless without knowing at least something about the nature of the data. If you think it is executable code, you need to at least know what CPU architecture you're dealing with. Even then, it is a huge fishing expedition. If you cannot identify the partition(s) on the disk, it is probable that the disk is either encrypted, or faulty. There is nothing to suggest that anything you observed during the boot process actually came from the disk itself. Many embedded systems boot from flash memory, and there is a very good chance that is what you are seeing, and that the system hangs when it cannot make any sensible access to the disk.
You might be able to get some verification of that by mounting a disk with a known good partition table, even if it doesn't contain any data that the system could boot from. If it contains any Linux filesystem, you might fortunate enough to see it try to proceed further into the boot process.

--- rod.