Fixdisk repeatedly unable to find partition 1

prpr said:
I think I worked out where you got the numbers from for partitioning the disk too - the 2TB disk installation blog - which I guess you must have done originally, rather than letting the Humax do it. It would have saved lots of time if you'd mentioned this, but we might not have learnt as much!
Click to expand...

I mean, it's possible I used that blog - it was a long time ago - but honestly I don't remember doing so. I was wracking my brain just last night trying to remember how I formatted the disk originally, but could not recall anything. I genuinely concluded I must've just put the drive straight in the Humax and let that handle it.
 
bottletop said:
so will you consider this to be fine as long as it doesn't increase much or should OP prepare for a drive replacement?
Click to expand...
I would prepare. Whether somebody else does is up to them and how much they would miss the disk contents should it all end unhappily.
Items 187-189 may indicate things amiss, and similarly the ATA error count that the OP's original SMART report contained.
 
bottletop said:
I think you'll find SMART is fine with the drive on the first run, because the MBR was there to begin with. It failed at the beginning of the 2nd run because fix-disk corrupted the MBR at end of first run. (A bit ironic - a script called fix-disk corrupting the drive.)
This probably on occurs on a small number of users, otherwise there'll be more users suffering from this.
Click to expand...
Has fixdisk been updated since this? Is there anything one can do in terms of backup mbr to protect against a deviant fixdisk? How would one proceed ? Offer a prayer?
 
sine24 said:
Has fixdisk been updated since this? Is there anything one can do in terms of backup mbr to protect against a deviant fixdisk? How would one proceed ? Offer a prayer?
Click to expand...
I may have over stated the issue - it's not an issue for most people.
Also fix-disk makes a backup of the partition table - so after the first successful fix-disk run you should have a backup.
 
sine24 said:
Has fixdisk been updated since this? Is there anything one can do in terms of backup mbr to protect against a deviant fixdisk? How would one proceed ? Offer a prayer?
Click to expand...
Write down the parameters that would be be needed to recreate the MBR would be a simple solution.
 
The function fetch_partscheme() in the fix-disk script (0.5 is what I have here, not up-to-date with HDR CF) is called early on and calls /sbin/gdisk -l (if present) to check the partition data. There is also PARTDIR=/var/lib/humaxtv_backup/partition where the final partition data is stashed using /sbin/sfdisk -l.

Plainly it needs to work out which disk partitioning utility/ies are shipped in the CF and stick with one (HD CF has /sbin/fdisk == /bin/busybox, /sbin/gdisk and /sbin/sfdisk, but no /sbin/gdisk). Then it could also stash a safety copy of the partition data, eg generated with /sbin/sfdisk --dump, in $PARTDIR if a valid partition scheme is found in fetch_partscheme().

For extra credit it could try to re-create a saved partition scheme if no valid scheme is found on the disk, perhaps under option or are-you-sure control.
 
Whilst it is great that fix-disk saves a copy of the partition table - maybe it should do it before anything else. (As suggested earlier.)
But thinking about it further - I wonder if the save partition table should not be a separate function? Maybe during the boot process. Eg save the partition table when the unit successfully boots - only keep the last 5 or so unique tables. Also have a complimentary function to allow fix-disk (and the user?) to call it to restore the last saved (or choose?) partition table.
 
Sadly the output of the early call is not kept, but deleted; only if the whole script succeeds is the partition data saved, at least in the version I'm looking at.
 
Code: 
PARTDIR=/var/lib/humaxtv_backup/partition
mkdir -p "$PARTDIR" && /sbin/sfdisk /dev/sda --dump  >"$PARTDIR/sda.dump"
Then if the partitioning gets trashed, this should restore it:
Code: 
PARTDIR=/var/lib/humaxtv_backup/partition
/sbin/sfdisk /dev/sda <"$PARTDIR/sda.dump"
 
Last edited:
/df said:
Code: 
PARTDIR=/var/lib/humaxtv_backup/partition
mkdir -p "$PARTDIR" && /sbin/sfdisk /dev/sda --dump  >"$PARTDIR/sda.dump"
Then if the partitioning gets trashed, this should restore it:
Code: 
PARTDIR=/var/lib/humaxtv_backup/partition
/sbin/sfdisk /dev/sda <"$PARTDIR/sda.dump"
Click to expand...
Shouldn't I have information about all 3 partitions?
Code: 
cat "$PARTDIR/sda.dump"
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start=           8, size=        4088, type=83
 
MymsMan said:
Shouldn't I have information about all 3 partitions?
Click to expand...
That is because my hardrive is actually sdb
Code: 
cat "$PARTDIR/sdb.dump"
label: dos
label-id: 0x00000000
device: /dev/sdb
unit: sectors

/dev/sdb1 : start=           2, size=     2104513, type=83
/dev/sdb2 : start=     2104515, size=   953682660, type=83
/dev/sdb3 : start=   955787175, size=    20980890, type=83
 
bottletop said:
Whilst it is great that fix-disk saves a copy of the partition table - maybe it should do it before anything else. (As suggested earlier.)
But thinking about it further - I wonder if the save partition table should not be a separate function? Maybe during the boot process. Eg save the partition table when the unit successfully boots - only keep the last 5 or so unique tables. Also have a complimentary function to allow fix-disk (and the user?) to call it to restore the last saved (or choose?) partition table.
Click to expand...
I like the idea of decoupling from fix-dik and automating saving in normal start up - everyone should have the details stashed away in case of need
Normally details shouldn't change unless you are swapping disks in and out so not sure if we need a 5 limit, just save it if different from previous.
 
I use Virtual-Disk2 on my HDR.
/df said:
Code: 
PARTDIR=/var/lib/humaxtv_backup/partition
mkdir -p "$PARTDIR" && /sbin/sfdisk /dev/sda --dump  >"$PARTDIR/sda.dump"
Then if the partitioning gets trashed, this should restore it:
Code: 
PARTDIR=/var/lib/humaxtv_backup/partition
/sbin/sfdisk /dev/sda <"$PARTDIR/sda.dump"
Click to expand...
So, the above needs to be something like this for it to work on my HDR (the last device is the main hard drive on my HDR).
Code: 
PARTDIR=/var/lib/humaxtv_backup/partition
HDR_DRIVE=$(ls /sys/block |grep sd |tail -n1)
HDR_DEVICE="/dev/"$HDR_DRIVE
mkdir -p "$PARTDIR" && /sbin/sfdisk $HDR_DEVICE --dump  >"$PARTDIR/"$HDR_DRIVE".dump"
 
Sure. I expected to use the fragment in the context of fix-disk, which knows how to find the relevant disk device.

More generally, it could be run as part of the disk device discovery routine /etc/mdev/run-and-gun (which ditto, as it actually doing that), or in a specially crafted /mod/etc/init.d routine, where it would have to resolve /mod to a disk device (not as easy as it should be ...).
 
If the coreutils package is installed, you can run:
Code: 
#                      list filesystems .. mounted on path matching the real path of /mod   ..  first field without partition number
/sbin/sfdisk --dump "$(df | tail -n +2 | grep -E  "$(readlink -e /mod | sed -e 's@/mod$@@')$" | sed -r -e 's/[0-9]+[[:space:]].*$//')"
When I said "not as easy", the problem is to emulate readlink -e (recursively resolve all links in an existing path) using only tools that are in the CF.
 
Clever though it is, I prefer just sfdisk -d /dev/sda or sfdisk -d /dev/sdb, which you can actually remember, without having to copy'n'paste.
 
The problem being addressed is to know which /dev/sdx is the one to fix given that the device letter assignment depends on a boot-time race. Obviously if you are actually typing an ad hoc command, you can parse the output of df personally to confirm the device name and then use that.

If you need to use a complicated shell command regularly, you can wrap it in a shell function (my_cmd(){...;}) and save it in a file under /mod/etc/profile.
 
/df said:
If the coreutils package is installed, you can run:
Click to expand...
Cool, I got this. Which of these is the mbr?
Code: 
label: dos                                                                                                                                             
label-id: 0x00000000                                                                                                                                   
device: /dev/sdb                                                                                                                                       
unit: sectors                                                                                                                                         
                                                                                                                                                      
/dev/sdb1 : start=           8, size=     2104503, type=83                                                                                             
/dev/sdb2 : start=     2104512, size=  3883938655, type=83                                                                                             
/dev/sdb3 : start=  3886043168, size=    20980895, type=83
 
You must log in or register to reply here.
Back
Top