• The forum software that supports hummy.tv has been upgraded to XenForo 2.1!

    This upgrade brings a number of improvements including the ability to bookmark posts to come back to later. Please bear with us as we continue to tweak things and open a new thread for any questions, issues or suggestions in Site/Forum Issues.

Partition sda2 - Unrecognised partition type, aborting...


New Member
Hi all,

This issue first manifested itself as a delete-loop issue, box not recording and continiously showing * deleting...

When I fire up maintenance mode, disk-fix gives the following

Running /bin/fix-disk
Custom firmware version 3.00

Checking disk sda

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

Running short disk self test
No pending sectors found - skipping sector repair
Using superblock 0 on sda1
Partition sda2 - Unrecognised partition type, aborting...
OK, so what's up with this partition type?

humax# fdisk -lu /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               2     2104514     1052256+ 83 Linux
/dev/sda2         2104515   955787174   476841330  83 Linux
/dev/sda3       955787175   976768064    10490445  83 Linux
Comparing with another similar post, I see someone else has the same numbers with the single exception on the block count on sda1 showing as 1052226. The plus here aparently means 'extended partition'. Hmmm not sure what to make of that.

My suspicion is that sda1 has too many blocks allocated and is somehow splilling over into sda2 thus causing sda2 partiton to appear corrupt. Is this a reasonable analysis?

I've tried
hdparm --read-sector 1 /dev/sda
reading sector 1: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
[snip ..]
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
on all three sectors, all behaving the same way.

So, I'm a bit stumped now. Any guidance anyone can offer would be greatly appreciated.


Black Hole

May contain traces of nut
That's not nice! Have you got stuff on there you really want to keep? If not, run a Humax disk format from the menus. If you want to repair rather than go nuclear, I'll drop out in deference to the real experts...


Staff member
OK, so what's up with this partition type?
It appears to be corrupt in some way. The script isn't looking at the partition table at this point but at the data on the disk. If you run this command from the CLI you will hopefully get more details:

humax#  dumpe2fs -h /dev/sda2


New Member
humax# dumpe2fs -h /dev/sda2
dumpe2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          e7db289b-0cbe-47c0-9e17-c232400243eb
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              29860704
Block count:              119209984
Reserved block count:     5960516
Free blocks:              20899535
Free inodes:              29855758
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      995
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8208
Inode blocks per group:   513
Filesystem created:       Sat Jan  1 00:00:15 2000
Last mount time:          Mon Sep  8 20:08:17 2014
Last write time:          Mon Sep  8 21:28:19 2014
Mount count:              5875
Maximum mount count:      31
Last checked:             Sat Jan  1 00:00:15 2000
Check interval:           15552000 (6 months)
Next check after:         Thu Jun 29 01:00:15 2000
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      abd3ddda-b5bf-4264-aa77-70b385f5e649
Journal backup:           inode blocks
Journal superblock magic number invalid!
Gosh, I think I'm out of my depth now.


Staff member
That isn't something I've ever seen before - a corrupt journal.
In theory you should be able to clear the journal and then let the filesystem repair itself. Data which had not yet been committed fully to disk may be lost but that should only be a few frames of video at the tail end of a recording.

humax# debugfs -w /dev/sda2
debugfs: clri <8>
debugfs: quit
Hopefully fix-disk will then work. You'll need to enable journalling again once it's fixed though.


New Member
I've recovered the machine, it's working nicely again.

Yes, pretty nasty, but the key to it was

mke2fs -n /dev/sda2
mke2fs 1.42.10 (18-May-2014)
/dev/sda2 contains a ext3 file system
        last mounted on Mon Sep  8 20:08:17 2014
Proceed anyway? (y,n) y
Creating filesystem with 119209984 4k blocks and 29860704 inodes
Filesystem UUID: b8d52c17-d341-4259-9aa9-b9a059fdb634
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
So I chose to restore the first one

humax# e2fsck -b 32768 /dev/sda2
e2fsck 1.42.10 (18-May-2014)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***

Pass 1: Checking inodes, blocks, and sizes


   Free blocks count wrong for group #3637 (32253, counted=0).
Fix<y>? yes

[couple of thousand of these]


Recreate journal<y>? yes
Creating journal (32768 blocks):  Done.

*** journal has been re-created - filesystem is now ext3 again ***

/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 4944/29860704 files (16.1% non-contiguous), 98540908/119209984 blocks
So, I'm pleased with that, a successful outcome!