Hello, I've built (with a lot of help) a couple of data acquisition units built around a PC-104 stack. The CPU board (real-time-devices) is an old 650 MHz Celeron, the "hard-drive" is a parallel ATA 64 GByte SSD.

It seems that on my "base" station receiver, the SSD has become corrupted, or is failing/failed, possibly due to heat stress?, with the high temperatures recently.

I've attached two files here which contain the output of "fdisk -l", one for the "rover" receiver (which works fine and all is in a normal state) and one for the base station receiver (on which the SSD seems to be damaged).

The receivers are supposed to boot Slackware linux with real time patch off the 64 GByte SSD, the base station won't boot up however, I just get a bunch of "9A" characters echoed to screen.

There is also a 4096 MByte flash drive on the motherboards which is not being used but does contain an old Fedora distn, which I can boot up on the base station, but can't mount the 64 GByte SSD.

On the base station receiver I also booted up TinyCore Linux kernel 2.6.33 and got the fdisk -l output for the base station that way.

I can "see" the 64 Gbyte drive with "fdisk -l" but it shows up now as a 32 GByte drive on the base station ??

There's some data on the base station receiver that I would like to recover if possible, does anyone have any ideas for how to do this without being able to mount the SSD ?

Thanks in advance for the help.base.txt

rover.txt

9A is the lilo code for no second stage loader signature.
With fdisk only reporting 62413 cylinders that would make sense it is only being "seen" as 32 GB. You can try using dd to make an image of the drive and a recovery tool to find data.

Thanks a lot for the help, I'll try using dd to make an image of the drive, I only have USB 1.0 ports so I suppose it will take many hours to put a 32 GByte image onto a pen drive, but worth a try, thanks for the LILO error message explanation, I wasn't aware of that.

Might be able to do other copies. dd may fail on errors so there are other programs that continue.

Might be possible to run testdisk on it.

A possible better software would be ddrescue.

1 members found this post helpful.

Hi, I made an image of hda3 (the user partition), I called it base.img, came out to 21.7 GBytes, I copied base.img off the pen drive and into the home directory on my Slackware box, made a directory called "recovery", and tried to mount the image using /home/dave/recovery as the mount point.

But, it didn't work, looking at dmesg, I saw

[1810.399627] EXT4-fs [loop 0]: failed to parse options in superblock: y?
[1810.399652] EXT4-fs [loop0]: bad geometry: block count 13565696 exceeds size of device (5701216 blocks)

Any ideas what I can do to try to mount this 21.7 GByte image file ?

I tried running resize2fs but it protested requesting that I run efsck first, and I'm not really sure what is the correct size to re-size too, I guess something less than 5701216 blocks ? I did try running e2fsck but that generated a whole slew of errors as well, so I didn't go too far into that.

Thanks,

David

https://technology.shipcomet.com/how...stem-in-linux/
https://www.suse.com/support/kb/doc/?id=000017759
https://chrisdown.name/2011/06/01/fs...-an-image.html

Try using ddrescue, it tries to continue to copy in case of errors. Plus a bunch of other stuff to get as much data off the drive as possible. Have used or a few times to recover data from a failing disk.

Be sure to read it in its entirety before proceeding on your drive and use the mapfile as suggested in it.

https://www.gnu.org/software/ddrescu...ue_manual.html