Fixdisk repeatedly unable to find partition 1

[thoughton]

Hi,
My Humax showed the fateful Error Code 8 yesterday. I installed the custom firmware, booted into Maintenance mode, and ran fixdisk from the menus.
The first run of fixdisk took many, many hours (had to do the long scan), seemed to repair many block I/O errors, but finished with the following:

Checking partition tables...

MBR Status: not present
GPT Status: not present

Partition table is missing/corrupt. If the disk has not been formatted by
the Humax, recovery by fix-disk may not be successful.

Searching for partitions...

Unable to find partition 1, exiting...
fix-disk: session terminated with exit status 1

Perhaps unsurprisingly the Humax still prompted me to Reformat the disk to be able to use it, although this time there was at least no Error Code 8.

I read in another discussion that it can sometimes be helpful to re-run fixdisk in these situations, so I tried that. This second run completed much more quickly, but it finished with the exact same output as the first test (see above).

Would it be fair to say that at this point the recordings on the disk are pretty much lost, and reformatting is the way to go?

Thanks!

PS. I don't have the full logs (that I know of) but I'll attach copy/patstes of the telnet output.

 

[prpr]

Would it be fair to say that at this point the recordings on the disk are pretty much lost, and reformatting is the way to go?

No, I'd say the recordings are all completely intact as they're on partition 2.
What does fdisk -lu /dev/sda print?

 

[thoughton]

Oh! That is interesting!

Ok, here is the output from fdisk:

humax# fdisk -lu /dev/sda

Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes

Disk /dev/sda doesn't contain a valid partition table

Thanks for the quick response btw.

Edit: PS. I forgot to mention I'd put a larger drive in the Humax. It was a number of years ago that I did that, and it completely slipped my mind.

 

[prpr]

You may find this thread of interest.
I would run diag igorw and wait to see what numbers it spits out. If successful, you should be able to recreate the partition table manually.
I could tell you my sector values, as I have a 2TB disk, but I'd rather not just yet.

 

[thoughton]

Brill, thanks - I shall give that a try, and I'll give that thread a read.

 

[prpr]

I'd forgotten this, but it's been nagging at me all afternoon. There may be a backup of the MBR details:
cat /var/lib/humaxtv_backup/partition/*

The problem is that it only gets created when you run a fixdisk, and in your case that may have been after the MBR got destroyed by the bad sector.
This is another good reason for running fixdisk periodically.
It's a shame that this backup is in text format, rather than as a dump (still readable text) that can easily be re-ingested if/when the need arises. I wonder why that wasn't done...

 

[thoughton]

Looks like you were right about me being a bit too late with the fixdisk to have a backup:

cat: can't open '/var/lib/humaxtv_backup/partition/*': No such file or directory

Thanks for the idea though (and this will definitely encourage me to run fixdisk more often in future).

Regarding the diag command, admittedly I haven't read that other thread in full yet, but I'm guessing the following result is not exactly ideal...?

humax# diag igorw
Running: igorw
END CHS 3907024064
Searching for partition 3...
sh: out of memory
Unable to find partition 3

 

[bottletop]

I'd forgotten this, but it's been nagging at me all afternoon. There may be a backup of the MBR details:
cat /var/lib/humaxtv_backup/partition/*

The problem is that it only gets created when you run a fixdisk, and in your case that may have been after the MBR got destroyed by the bad sector.
This is another good reason for running fixdisk periodically.
It's a shame that this backup is in text format, rather than as a dump (still readable text) that can easily be re-ingested if/when the need arises. I wonder why that wasn't done...

Isn't that going to be a chicken and egg situation? I mean if OP can't access the partition table then he can't mount the partition that holds the backups (even if they're there). Without the partition table OP might not be able to mount anything.

Edit1: I've just noticed that may not be the hard drive, so should be accessible.
In that case a partition table dump using sfdisk or sgdisk just after partitioning the drive would have been useful.

 

[prpr]

Isn't that going to be a chicken and egg situation? I mean if OP can't access the partition table then he can't mount the partition that holds the backups (even if they're there). Without the partition table OP might not be able to mount anything.

Edit1: I've just noticed that may not be the hard drive, so should be accessible.

Yes, that location is in the flash, for obvious reasons.

 

[prpr]

Regarding the diag command, admittedly I haven't read that other thread in full yet, but I'm guessing the following result is not exactly ideal...?

It's not good. That out of memory thing seems to have been unresolved from then as well.
I think you might have to go with educated guesswork from here. Maybe you can recreate partition 1 and create a swap file on it to help with recovery of 2 and 3 though.

 

[bottletop]

I thought I'd be able to give the details of my drive, because it's also 2TB but then noticed I messed around with the partitions, eg it's using GPT so it may not match yours at all! (Too risky to assume it'll match.)

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168
 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sdb1               1     2097151     1048575+ ee EFI GPT

It may be a bit hit and miss to guess the sizes etc, but something like Easeus partition manager (Windows) or Testdisk (Linux) may be able to search sequentially for the partition headers. It'll take a bit of time and you'll need to remove to hard drive, attach it to a pc (being careful not to write to the drive until you're certain the partition table is reconstructed).

 

[/df]

The diag igorw script is this:

locate_part ()
{
local sig
for sb in 0 32768; do
  for i in $(seq $1 $2); do
    sig=$((sb == 0 ? i * 512 + 1080 : i * 512 - 1024 + sb * 4096 + 1080))
    # Have to use dd here, hexdump doesn't support big offsets
    if dd if=/dev/$dev bs=1 skip=$sig count=2 2> /dev/null | hexdump -n2 2> /dev/null | grep -q ef53 ; then
      echo $i
      return 0
    fi
  done
done
return 1
}

partition_search()
{
local first start end last_start p

end=-1
end_chs=$(($(cat /sys/block/$dev/size) / 16065 * 16065 - 1))
echo "END CHS $end_chs"
for p in $(seq 3 3); do
  echo "Searching for partition $p..."
  case $p in
    1) start=$(locate_part 2 2048) ;;
    2) start=$(locate_part 2000000 2200000) ;;
    3) start=$(locate_part $((end_chs-21000000)) $end_chs) ;;
  esac
  if [ $? -ne 0 ]; then
    echo "Unable to find partition $p"
    continue
  fi
  echo "Found partition $p @ $start"
done
}

for dir in /sys/block/sd? ; do
  if [ "$dir" = "/sys/block/sd?" ]; then
    echo "Unable to find a disk"
    exit 1
  fi
  if ls -l $dir/device | grep -q /devices/pci ; then
    dev=${dir#/sys/block/}
    break
  fi
done

if [ -z "$dev" ]; then
  echo "Unable to find the internal hard disk"
  exit 1
fi

partition_search

Most likely the dd is causing the problem.

Maybe running the commands separately and not discarding stderr would make it clearer.

Maybe a small drive (USB stick, 1GB would probably do) should be attached and used to provide a swap file.

Not entirely on topic, but how do I know about the script?

# /bin/diag 
Syntax: diag [-d] <command>
        -d   View diagnostic code.
#

Also, consider getting the disk out of the box and into SATA-USB caddy so that you can use standard partition recovery tools with a Linux boot CD if needed.

 

[prpr]

for p in $(seq 3 3); do

This is obviously wrong too (which explains the odd output in post #7).
Maybe that was WiP to try and fix the out of memory error, but it shouldn't be in the copy on the server.
I would suggest the OP downloads the script and edits it to say $(seq 1 3) and then runs it, if that's within his skill bounds.

(More intriguingly, the copy I took in 2017 says $(seq 1 2), but maybe that was my edit.)

 

[thoughton]

Thanks a lot for the additional info and advice everyone.
I will give editing the script a try tomorrow.

 

[prpr]

Most likely the dd is causing the problem.

Having poked at it, it's actually seq that's the problem, because it generates (well, tries to) a huge list before it even attempts to get to dd. This is one of those places where a discrete loop/counter/test would work better.
So a quick mod. to reduce the ranges and I can get it to run to completion, but it generates the wrong start for P3 - 3886048600 instead of 3886043168 - no idea about that. And it reads the disk twice, needlessly. The whole thing is naff really and would be better written in C. A classic example of why shell script is bad for some things (IMHO).

 

[xyz321]

Here's a patch which may work (I don't have a 2TB disk to test it on).

--- igorw
+++ igorw-fast
@@ -23,12 +23,12 @@
 end=-1
 end_chs=$(($(cat /sys/block/$dev/size) / 16065 * 16065 - 1))
 echo "END CHS $end_chs"
-for p in $(seq 3 3); do
+for p in $(seq 1 3); do
   echo "Searching for partition $p..."
   case $p in
     1) start=$(locate_part 2 2048) ;;
-    2) start=$(locate_part 2000000 2200000) ;;
-    3) start=$(locate_part $((end_chs-21000000)) $end_chs) ;;
+    2) start=$(locate_part 2104510 2106558) ;;
+    3) start=$(locate_part $((end_chs-20980950)) $((end_chs-20978834))) ;;
   esac
   if [ $? -ne 0 ]; then
     echo "Unable to find partition $p"

 

[xyz321]

The diagnostic igorw was originally cribbed from fix-disk but with some additional bugs added (see above). The original code was released before disks with 4K alignment became common place. The numbers above may need tweaking to match a 4K aligned disk.

 

[Black Hole]

Just to clarify for mere mortals, is the following a reasonable summary?:

• The OPs problems start from the HDDs MBR (Master Boot Record) having gone missing, so the partitioning information which enables the operating system to physically locate the file systems on the HDD is no longer available.
  
  
• If the MBR can be reconstructed, it is possible the partitions are still intact and the file systems will be restored.
  
  
• The intention of using igorw is to search the HDD for the partition boundaries so that the MBR can be rebuilt.

 

[xyz321]

Yes to all three points.

The main problem with the fix-disk and igorw scripts is that they were originally written for the old non-4k aligned disks and part of the code still makes this assumption.
Also the code assumes a 10G size for the last partition which might not necessarily be the case if the disk has been manually partitioned.

When igorw was written was meant to scan the whole of that 10G space looking for partition 3 which, if not found near the beginning of the scan, is very slow especially using scripting and also caused the out of memory error.

A better way might be to get the size of partition 2 from its superblock and use that and its offset to estimate where to look for the start of partition 3.

 

[bottletop]

Just to clarify for mere mortals, is the following a reasonable summary?:

• The OPs problems start from the HDDs MBR (Master Boot Record) having gone missing, so the partitioning information which enables the operating system to physically locate the file systems on the HDD is no longer available.
  
  
• If the MBR can be reconstructed, it is possible the partitions are still intact and the file systems will be restored.
  
  
• The intention of using igorw is to search the HDD for the partition boundaries so that the MBR can be rebuilt.

MBR vs. GPT Guide: What's The Difference and Which One Is Better - MiniTool

MBR or GPT, which one is better, and what's their exact differences? In this post, we will explain these 2 aspects in detail.

www.minitool.com

MBR has the partition table - this is merely a summary of where partition A, B ,C and D are.
If only the MBR is erased, you can reconstruct the MBR by filling it with default values and populate the partition table data by scanning the drive to look for where A, B, C, D start and end. This may take a while as it'll scan the whole drive.

What the various hummy.tv utilities do is to try to speed up the process by working out where the boundaries should be. Unfortunately I don't have confidence in the hummy.tv utilities to find the partitions because they may not work. It'll be easier, but take noticeably longer, to scan the whole drive. It'll be quicker to perform the whole drive scan with the drive attached to a PC to leverage PC SATA 3 speed rather than HDR SATA 2 speed etc.

This assumes a normal spinning hard drive (as SSD, SD card, etc slightly behave differently) .
This also assumes the whole drive hasn't been overwritten with zeros/garbage.
This doesn't address what caused the issue in the first place - what overwrote the MBR?