Possible Corrupt File Issue

[Black Hole]

It works on single-line commands that do not require further input, but one can tell by getting a double humax# prompt after every command (including a null command).

 

[xyz321]

Anyway. I am a step closer, responded to the Y, this time it went away for a few seconds and came back with "unrecognised partition type, aborting." Doh!

There is a bug in the current version of fix-disk. It does a series of checks, one of which can fail with some forms of disk corruption. See this post for a workaround.

 

[ardent]

Followed the link. struggling to get sda2 unmounted. Always coming back busy. Kept at and by luck or otherwise finally arrived at all unmounted. Copied and pasted the modified sed command from the above link. And came back with the following.
-------------------------------------------------
humax# fix-disk
Unrecognised partition type, aborting...
humax# umount /dev/sda2
humax# umount /dev/sda1
humax# umount /dev/sda3
umount: can't umount /dev/sda3: Invalid argument
humax# fix-disk
Unrecognised partition type, aborting...
------------------------------------------------------
humax# sed -e '86,91s/^/#/' /bin/fix-disk > /tmp/fix-disk
humax# chmod 755 /tmp/fix-disk
humax# /tmp/fix-disk
Checking disk sda

Partition /dev/sda1 is already unmounted
Partition /dev/sda2 is already unmounted
Partition /dev/sda3 is already unmounted

Checking partition /dev/sda1...
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 15/65808 files (6.7% non-contiguous), 13787/263064 blocks

Checking partition /dev/sda3...
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda3
Could this be a zero-length partition?
Aborting...
humax#
---------------------------------------------------
Further than I have got previously so more progress made. Just I hope I can repeat it.
Jason

 

[ardent]

Update. ran e2fsck /dev/sda2 manually and got the following.

humax# e2fsck /dev/sda2
e2fsck 1.41.14 (22-Dec-2010)
/dev/sda2 has been mounted 1690 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create<y>? yes

e2fsck: Memory allocation failed while retrying to read bitmaps for /dev/sda2
e2fsck: aborted
humax#

Jason

 

[ardent]

further update. Ran again, this time N at create? gave the following.

humax# e2fsck /dev/sda2
e2fsck 1.41.14 (22-Dec-2010)
/dev/sda2 has been mounted 1690 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create<y>? no

Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sda2: ********** WARNING: Filesystem still has errors **********

/dev/sda2: 5041/60334080 files (4.5% non-contiguous), 110403645/241304332 blocks
humax#

Jason

 

[xyz321]

The memory allocation failure on /dev/sda2 is to be expected because the check on /dev/sda3 failed. It would therefore not be able to setup the swap space. If you still have problems with sda3 I would suggest reformatting that partition using:

mkfs.ext3 /dev/sda3

There is very little data saved on that partition, just 'streamer_down_file', 'cookie.txt' and 'ext3grep'.

 

[ardent]

Ran.
expected result?
humax# mkfs.ext3 /dev/sda3
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
655776 inodes, 2622611 blocks
131130 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2688548864
81 block groups
32768 blocks per group, 32768 fragments per group
8096 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Warning: could not read block 0: Attempt to read block from filesystem resulted in short read
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

 

[xyz321]

I think you may have a faulty disk. Try:

e2fsck -cc -f /dev/sda3

 

[ardent]

Ran
humax# umount /dev/sda3
humax# e2fsck -cc -f /dev/sda3
e2fsck 1.41.14 (22-Dec-2010)
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done
/dev/sda3: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: 11/655776 files (0.0% non-contiguous), 79733/2622611 blocks
humax#

Jason

 

[ardent]

UPDATE!
xyz321. What ever "e2fsck -cc -f /dev/sda3" means or does, I have my recordings back!
Been at this for days now, but very satisfying to see them all back. Big thanks to all the usual suspects xyz321, blackhole, ezra pound and af123 on this thread and other related threads. Really learnt a lot through the process. Thanks folks. Just hope everything is all well come the next time I fire it up.
Thanks again, looking forward to playing with more of the custom firmware.
Jason

 

[Black Hole]

It was probably the mkfs that did it. The credit should go to xyz321 - I wouldn't dare suggest those commands, a little knowledge is a dangerous thing.

WARNING TO ANYONE ELSE READING THIS TOPIC FOR A SOLUTION

This is a one-off fix for this particular case. Please do not "just try it" if you are having disk problems, you risk losing your disk contents and forcing a complete reformat. Get advice first.

 

[ardent]

I was somewhat apprehensive having realised after all my efforts there was an auto update overnight. All is well. Phew!

Thanks once again, for all the help.
Jason

 

[Black Hole]

There was not an auto-update overnight, other than the usual daily OTA search at 0430. I think you mean the automatic retune during the day today.

 

[ardent]

Agreed. Having been without the box for a while and non the wiser as to why it went skitty in the first place, I just did not anything to upset it again having just got it back.

Jason