Re: MBR partitioning, and content after partition table but before first partition

2017-03-15 Thread Jonathan Dowland
On Mon, Mar 13, 2017 at 08:36:59PM -0700, David Christensen wrote:
> >and the destination ended up bigger,
> >possibly because one or more of the backups on the source had been using some
> >kind of hardlink de-dupe (I've ranted about hardlink trees being a problem in
> >various backup topics on -user, too...) and I didn't think to supply -S to
> >rsync.
> 
> -S is for sparse files.

Sorry, you are right. I did not use -S nor -H, so sparse files would be 
expanded,
and hard links re-referenced in my copy. I'm not sure which (or both) were a
problem in my case.


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature


Re: MBR partitioning, and content after partition table but before first partition

2017-03-14 Thread Andy Smith
Hello,

On Mon, Mar 13, 2017 at 08:36:59PM -0700, David Christensen wrote:
> Is anyone aware of a utility that can walk a file system and replace
> identical files with hard links?

As an alternative to doing this, you could consider using a
filesystem with block-level de-duplication support.

ZFS and btrfs can do this online, though that uses a very large
amount of memory. btrfs and recently XFS can do it offline, which
means that you trigger it at a time of your choosing.

Support in XFS only arrived in kernel version 4.9.1, and is still
marked as experimental. The kernel in jessie-backports right now is
new enough. I did a write up a while ago about experimenting with
this in XFS:

http://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: MBR partitioning, and content after partition table but before first partition

2017-03-14 Thread David Christensen

On 03/14/2017 04:52 AM, The Wanderer wrote:

On 2017-03-13 at 23:36, David Christensen wrote:


Is anyone aware of a utility that can walk a file system and replace
 identical files with hard links?


Try rdfind. It's in Debian; I don't use it myself, largely because the
(accepted upstream years ago) feature request for a "-minsize" option
(to replace or extend the "-ignoreempty" option) which I need for my use
case has not apparently been implemented yet - but finding duplicate
files is exactly what it's meant for, and one of its available "actions"
is to replace the duplicate files with hardlinks.


rdfind looks like just what I wanted.  Thanks for the tip.  :-)


David





Re: MBR partitioning, and content after partition table but before first partition

2017-03-14 Thread David Christensen

On 03/14/2017 03:34 AM, David wrote:

On 14 March 2017 at 14:36, David Christensen  wrote:


Doing a quick test, it appears that rsync copies hard linked files as if
each were a different file:

rsync -a hard-link-1/ hard-link-2


Here, 'man rsync' says:
"Note that -a does not preserve hardlinks, because finding
multiply-linked files is expensive.  You must separately specify -H."


Thanks for the tip.  :-)


So, rsync can copy hard links:

2017-03-14 19:33:10 dpchrist@jesse ~/sandbox/rsync
$ cat hard-link
#!/bin/sh
# Test 'rsync -a' and hard links
# $Id: hard-link,v 1.3 2017/03/15 02:32:08 dpchrist Exp $
# by David Paul Christensen dpchr...@holgerdanske.com
# Public Domain
mkdir hard-link-1
mkdir hard-link-2
echo "hello, world!" > hard-link-1/hello.txt
ln hard-link-1/hello.txt hard-link-1/link-1.txt
ln hard-link-1/hello.txt hard-link-1/link-2.txt
ln hard-link-1/hello.txt hard-link-1/link-3.txt
ln hard-link-1/hello.txt hard-link-1/link-4.txt
ls -li hard-link-1/*
du -b hard-link-1/*
rsync -a -H hard-link-1/ hard-link-2
ls -li hard-link-2/*
du -b hard-link-2/*
rm -rf hard-link-1
rm -rf hard-link-2


2017-03-14 19:33:13 dpchrist@jesse ~/sandbox/rsync
$ sh hard-link
272911 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-1/hello.txt
272911 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-1/link-1.txt
272911 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-1/link-2.txt
272911 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-1/link-3.txt
272911 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-1/link-4.txt
14  hard-link-1/hello.txt
272912 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-2/hello.txt
272912 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-2/link-1.txt
272912 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-2/link-2.txt
272912 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-2/link-3.txt
272912 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 14 19:33 hard-link-2/link-4.txt
14  hard-link-2/hello.txt


On 03/14/2017 04:52 AM, The Wanderer wrote:
> (You may want to check whether the resulting files are hardlinked back
> to the ones in the original tree; I haven't tested, and from reading the
> man page it doesn't seem entirely clear.)


The test above indicates that hard links created by rsync with the -H 
option point to files within the destination tree.



David



Re: MBR partitioning, and content after partition table but before first partition

2017-03-14 Thread The Wanderer
On 2017-03-13 at 23:36, David Christensen wrote:

> On 03/13/2017 02:01 AM, Jonathan Dowland wrote:
> 
>> On Fri, Mar 10, 2017 at 10:00:45PM -0800, David Christensen wrote:

>> and the destination ended up bigger, possibly because one or more
>> of the backups on the source had been using some kind of hardlink
>> de-dupe (I've ranted about hardlink trees being a problem in 
>> various backup topics on -user, too...) and I didn't think to
>> supply -S to rsync.
> 
> -S is for sparse files.
> 
> 
> Doing a quick test, it appears that rsync copies hard linked files as
> if each were a different file:



As already mentioned, you need the '-H' option to rsync for that. My
standard rsync invocation is with '-avPH', just in case the tree being
copied has any hardlinks.

(You may want to check whether the resulting files are hardlinked back
to the ones in the original tree; I haven't tested, and from reading the
man page it doesn't seem entirely clear.)

> Is anyone aware of a utility that can walk a file system and replace
>  identical files with hard links?

Try rdfind. It's in Debian; I don't use it myself, largely because the
(accepted upstream years ago) feature request for a "-minsize" option
(to replace or extend the "-ignoreempty" option) which I need for my use
case has not apparently been implemented yet - but finding duplicate
files is exactly what it's meant for, and one of its available "actions"
is to replace the duplicate files with hardlinks.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: MBR partitioning, and content after partition table but before first partition

2017-03-14 Thread David
On 14 March 2017 at 14:36, David Christensen  wrote:
>
> Doing a quick test, it appears that rsync copies hard linked files as if
> each were a different file:
>
> rsync -a hard-link-1/ hard-link-2

Here, 'man rsync' says:
"Note that -a does not preserve hardlinks, because finding
multiply-linked files is expensive.  You must separately specify -H."



Re: MBR partitioning, and content after partition table but before first partition

2017-03-13 Thread David Christensen

On 03/13/2017 02:01 AM, Jonathan Dowland wrote:

On Fri, Mar 10, 2017 at 10:00:45PM -0800, David Christensen wrote:

I'd always put a step 0) in there: is imaging what you want to do? Consider
a file-level backup with rsync (etc etc, as discussed elsewhere in this
thread)


I do imaging for system disks.  I do backups and archives for data.


So having evangelised file-level copies a few times in this thread, I found
myself wondering if I would have been better off with imaging this very
weekend. Copying a 2.1T filesystem from an internal SATA2 disk to an external
one (my regular backup drive to my once-a-month, lives off-site one) via USB3
took nearly 48 hours via "rsync -a",


2.1 TB / 48 hr / 3600 s/hr = 12.2 MB/s

I was also disappointed by the transfer rate of external USB drives on 
Debian.  Firewire is better.  eSATA is best.



I now use 3 TB Seagate ST3000DM001 desktop drives in StarTech 
DRW115SATBK mobile docks connected to motherboard and/or HBA SATA ports. 
 With LUKS and a Pentium D 945 (no AES-NI), I see 40 MB/s.  With LUKS 
and a Core i7-2600S (AES-NI), I see 220 MB/s.




and the destination ended up bigger,
possibly because one or more of the backups on the source had been using some
kind of hardlink de-dupe (I've ranted about hardlink trees being a problem in
various backup topics on -user, too...) and I didn't think to supply -S to
rsync.


-S is for sparse files.


Doing a quick test, it appears that rsync copies hard linked files as if 
each were a different file:


2017-03-13 20:33:46 dpchrist@jesse ~/sandbox/rsync
$ cat hard-link
#!/bin/sh
# Test 'rsync -a' and hard links
# $Id: hard-link,v 1.2 2017/03/14 03:33:15 dpchrist Exp $
# by David Paul Christensen dpchr...@holgerdanske.com
# Public Domain
rm -rf hard-link-1
rm -rf hard-link-2
mkdir hard-link-1
mkdir hard-link-2
echo "hello, world!" > hard-link-1/hello.txt
ln hard-link-1/hello.txt hard-link-1/link-1.txt
ln hard-link-1/hello.txt hard-link-1/link-2.txt
ln hard-link-1/hello.txt hard-link-1/link-3.txt
ln hard-link-1/hello.txt hard-link-1/link-4.txt
ls -li hard-link-1/*
du -b hard-link-1/*
rsync -a hard-link-1/ hard-link-2
ls -li hard-link-2/*
du -b hard-link-2/*

2017-03-13 20:34:18 dpchrist@jesse ~/sandbox/rsync
$ sh hard-link
271759 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 13 20:34 hard-link-1/hello.txt
271759 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 13 20:34 hard-link-1/link-1.txt
271759 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 13 20:34 hard-link-1/link-2.txt
271759 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 13 20:34 hard-link-1/link-3.txt
271759 -rw-r--r-- 5 dpchrist dpchrist 14 Mar 13 20:34 hard-link-1/link-4.txt
14  hard-link-1/hello.txt
271760 -rw-r--r-- 1 dpchrist dpchrist 14 Mar 13 20:34 hard-link-2/hello.txt
271761 -rw-r--r-- 1 dpchrist dpchrist 14 Mar 13 20:34 hard-link-2/link-1.txt
271762 -rw-r--r-- 1 dpchrist dpchrist 14 Mar 13 20:34 hard-link-2/link-2.txt
271763 -rw-r--r-- 1 dpchrist dpchrist 14 Mar 13 20:34 hard-link-2/link-3.txt
271764 -rw-r--r-- 1 dpchrist dpchrist 14 Mar 13 20:34 hard-link-2/link-4.txt
14  hard-link-2/hello.txt
14  hard-link-2/link-1.txt
14  hard-link-2/link-2.txt
14  hard-link-2/link-3.txt
14  hard-link-2/link-4.txt


Is anyone aware of a utility that can walk a file system and replace 
identical files with hard links?




The real test will be how long an incremental catch-up will take in the future.


For new large files, the size of the files divided by 12.2 MB/s.  For 
everything else, longer.



David



Re: MBR partitioning, and content after partition table but before first partition

2017-03-13 Thread Jonathan Dowland
On Fri, Mar 10, 2017 at 10:00:45PM -0800, David Christensen wrote:
> >I'd always put a step 0) in there: is imaging what you want to do? Consider
> >a file-level backup with rsync (etc etc, as discussed elsewhere in this
> >thread)
> 
> I do imaging for system disks.  I do backups and archives for data.

So having evangelised file-level copies a few times in this thread, I found
myself wondering if I would have been better off with imaging this very
weekend. Copying a 2.1T filesystem from an internal SATA2 disk to an external
one (my regular backup drive to my once-a-month, lives off-site one) via USB3
took nearly 48 hours via "rsync -a", and the destination ended up bigger,
possibly because one or more of the backups on the source had been using some
kind of hardlink de-dupe (I've ranted about hardlink trees being a problem in
various backup topics on -user, too...) and I didn't think to supply -S to
rsync.

The real test will be how long an incremental catch-up will take in the future.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature


Re: MBR partitioning, and content after partition table but before first partition

2017-03-10 Thread David Christensen

On 03/10/2017 12:49 AM, Jonathan Dowland wrote:

On Thu, Mar 09, 2017 at 09:04:56PM -0800, David Christensen wrote:

I use LUKS swap (random key) and root (passphrase).  I think it's the piece
of the boot chain that gives me the LUKS prompt for root (before the GRUB
menu).


You get that prompt *before* GRUB?

I use LUKS everywhere and only get it after, because the prompt is (normally)
issued from my initrd.


You're right, I mis-remembered -- I get the Grub menu and then the LUKS 
passphrase prompt for root.




(although I historically put /boot outside of the
encryption. Maybe this is some newer scheme I am not familiar with).


My boot partition is also unencrypted.



So, the moral of the story appears to be:

When taking an image of a Debian system drive, be sure to copy the
blocks between the partition table and the first partition, as there
may be boot loader code there.


I'd always put a step 0) in there: is imaging what you want to do? Consider
a file-level backup with rsync (etc etc, as discussed elsewhere in this
thread)


I do imaging for system disks.  I do backups and archives for data.


David



Re: MBR partitioning, and content after partition table but before first partition

2017-03-10 Thread Jonathan Dowland
On Thu, Mar 09, 2017 at 09:04:56PM -0800, David Christensen wrote:
> I use LUKS swap (random key) and root (passphrase).  I think it's the piece
> of the boot chain that gives me the LUKS prompt for root (before the GRUB
> menu).

You get that prompt *before* GRUB?

I use LUKS everywhere and only get it after, because the prompt is (normally)
issued from my initrd. (although I historically put /boot outside of the
encryption. Maybe this is some newer scheme I am not familiar with).

> So, the moral of the story appears to be:
> 
> When taking an image of a Debian system drive, be sure to copy the
> blocks between the partition table and the first partition, as there
> may be boot loader code there.

I'd always put a step 0) in there: is imaging what you want to do? Consider
a file-level backup with rsync (etc etc, as discussed elsewhere in this 
thread)
 
> This document is dated and doesn't cover LUKS, but does indicate that blocks
> 1-62 were used for "GRUB stage 1.5":
> 
> http://www.pixelbeat.org/docs/disk/

Yes, that was what I thought.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature


Re: MBR partitioning, and content after partition table but before first partition

2017-03-09 Thread David Christensen

On 03/08/2017 10:56 PM, Felix Miata wrote:

Was that disk ever used for anything besides Jessie, not new or
wiped first?


The disk was wiped before installing Jesse.



Run strings on it or view in a sector editor and you'll probably see
grub somewhere, if it's a typical Linux installation that puts Grub
in the MBR instead of on a primary partition with its boot flag set,
along with generic code in the MBR.


2017-03-09 20:22:00 root@jesse ~
# dd if=/dev/sda skip=1 count=100 2>/dev/null | file -
/dev/stdin: data

2017-03-09 20:22:38 root@jesse ~
# dd if=/dev/sda skip=1 count=100 2>/dev/null | strings | egrep -i
'[a-z]{5,}'
loading
 Error
RBRPQR

RcVqt
YpmBs
0GXRSh
rswcGnj
#NXxVg
ihfer
zxgKNZT
LsELn
UenvkO
kxgqI&
MstUFX1
g~vqKsu8



Occasionally some of those sectors are used for RAID.


I don't use RAID with that system disk.


On 03/08/2017 11:21 PM, Thomas Schmitt wrote:

Could be GRUB program code. Do you see cleartext messages in the
first 100 blocks ?


See above.


On 03/09/2017 06:30 AM, Jonathan Dowland wrote:

I believe it's part of grub. My limited understanding of how it works
is it's split up into separate stages designed to fit within the
"holes" in a typical MBR layout, each stage having enough code to
initialise some stuff and then jump to the next stage.



I use LUKS swap (random key) and root (passphrase).  I think it's the 
piece of the boot chain that gives me the LUKS prompt for root (before 
the GRUB menu).



My Wheezy system drive also uses LUKS:

2017-03-09 20:32:04 root@cd2533 ~
# dd if=/dev/sdb count=2048 2>/dev/null | hexdump -C | tail
cd90  00 0f 7d 74 a2 57 6f 16  d8 61 5a 19 6d c0 63 f3 
|..}t.Wo..aZ.m.c.|
cda0  ed 86 77 f3 9d 2a 26 87  40 61 e3 7a 05 a7 fc b0 
|..w..*&.@a.z|
cdb0  8b 5d e1 b3 99 a4 ad 17  8e f6 dd 5f 1e 1a 06 5d 
|.]._...]|
cdc0  8f f3 e9 b6 ec f7 63 18  72 47 d4 aa 3b 5a da 56 
|..c.rG..;Z.V|
cdd0  ac 2d 95 3a c4 12 53 45  6a 5a 92 21 79 6c d6 ca 
|.-.:..SEjZ.!yl..|
cde0  93 ec ae fe 96 c3 df cb  61 ca 88 d8 a0 14 7d 53 
|a.}S|
cdf0  31 c4 53 ba 2e aa ee 35  57 46 fd 4b 81 9c 8d 9d 
|1.S5WF.K|
ce00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
0010

2017-03-09 20:34:43 root@cd2533 ~
# dd if=/dev/sdb skip=1 count=2048 2>/dev/null | file -
/dev/stdin: data

2017-03-09 20:36:49 root@cd2533 ~
# dd if=/dev/sdb skip=1 count=2048 2>/dev/null | strings | egrep -i 
'[a-z]{5,}'

loading
 Error
RBRPQR
wPdwm
piyEst
WmZFH7w
ukdmtI
kAXwU
NQapDd
wkNdR
MKEZH'
GZRCv
vNigR
VpbVk
mXDbl
l8WMhMJ
5ygCtG
PjzpIj$3
flnYG


So, the moral of the story appears to be:

When taking an image of a Debian system drive, be sure to copy the
blocks between the partition table and the first partition, as there
may be boot loader code there.


I can find plenty of "introductory" / "overview" documents, but does 
anybody know if/ where the technical details are documented?



2017-03-09 20:46:57 dpchrist@jesse ~
$ apt-get source grub-pc
...

2017-03-09 20:58:13 dpchrist@jesse ~
$ cd grub2-2.02~beta2/docs/

2017-03-09 20:58:17 dpchrist@jesse ~/grub2-2.02~beta2/docs
$ ls -w 72
Makefile.amgrub-dev.texi  stamp-1
Makefile.ingrub.cfg   stamp-vti
autoiso.cfggrub.info  texinfo.tex
fdl.texi   grub.texi  version-dev.texi
font_char_metrics.png  manversion.texi
font_char_metrics.txt  mdate-sh
grub-dev.info  osdetect.cfg


This document is dated and doesn't cover LUKS, but does indicate that 
blocks 1-62 were used for "GRUB stage 1.5":


http://www.pixelbeat.org/docs/disk/


David



Re: MBR partitioning, and content after partition table but before first partition

2017-03-09 Thread Jonathan Dowland
On Wed, Mar 08, 2017 at 09:46:32PM -0800, David Christensen wrote:
> What is in blocks 1-101?

I believe it's part of grub. My limited understanding of how it works is
it's split up into separate stages designed to fit within the "holes" in
a typical MBR layout, each stage having enough code to initialise some
stuff and then jump to the next stage.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature


Re: MBR partitioning, and content after partition table but before first partition

2017-03-08 Thread Thomas Schmitt
Hi,

David Christensen wrote:
> Examining a Windows XP disk, the first partition (C:\) starts at block 63
> (track 1):
> [...]
> Number  Start  End SizeType File system  Flags
>  1  63s156296384s  156296322s  primary  ntfs boot

That's an oldfashioned layout. Bad for disks with blocksize larger than
512 bytes, because of the odd block count.


> 01f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa

This is the end of the MBR. The first partition slot is at address
01be.


> 7c00  12 91 f2 60 90 a0 2f 19  01 00 00 00 85 00 67 68 |...`../...gh|
> 7c10  46 44 23 cc 22 52 1d ac  22 52 32 4e 6f 72 74 6f |FD#."R.."R2Norto|
> 7c20  6e 20 47 68 6f 73 74 20  32 30 30 33 00 00 00 00 |n Ghost 2003|

That's in the last block before partition 1 begins.
No idea whether it is trash or whether Norton Ghost dumped a tag there.
(In this case it belongs to GiaThnYgeia's list of occasions which change
the unclaimed disk area.)


> Examining a Jesse system drive, the first partition starts at block 2048 (1
> MB = 2**20 bytes):

That's the modern layout. I wonder how long it will last until 1 MiB are
considered too small.


> c990  b0 b3 2c fa a4 38 f1 f8  77 f0 2d dd c2 4a a4 a9 |..,..8..w.-..J..|
> What is in blocks 1-101?

Could be GRUB program code. Do you see cleartext messages in the first
100 blocks ?

With
  dd if=/dev/sda bs=512 count=100 | strings | less
i get from my system disk
  ZRr=
  `|f 
  \|f1
  GRUB 
  Geom
  Hard Disk
  Read
  Error
  loading
  Geom
and much more text salad.


Have a nice day :)

Thomas



Re: MBR partitioning, and content after partition table but before first partition

2017-03-08 Thread Felix Miata

David Christensen composed on 2017-03-08 21:46 (UTC-0800):
...

Examining a Jesse system drive, the first partition starts at block 2048
(1 MB = 2**20 bytes):



2017-03-08 21:30:04 root@jesse ~
# parted /dev/sda u s p
Model: ATA SAMSUNG SSD UM41 (scsi)
Disk /dev/sda: 31277232s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:



Number  Start EndSize   Type File system  Flags
  1  2048s 976895s974848sprimary  ext4 boot
  2  976896s   1953791s   976896sprimary
  3  1953792s  28125183s  26171392s  primary



There is content in the first 101 blocks (1 MBR plus 100 other):



2017-03-08 21:30:06 root@jesse ~
# dd if=/dev/sda count=2048 2>/dev/null | hexdump -C | tail

...


What is in blocks 1-101?


Was that disk ever used for anything besides Jessie, not new or wiped first?

Run strings on it or view in a sector editor and you'll probably see grub 
somewhere, if it's a typical Linux installation that puts Grub in the MBR 
instead of on a primary partition with its boot flag set, along with generic 
code in the MBR.


Occasionally some of those sectors are used for RAID.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/



MBR partitioning, and content after partition table but before first partition

2017-03-08 Thread David Christensen

On 03/08/2017 03:02 AM, Thomas Schmitt wrote:

David Christensen wrote:

AFAIK when using MBR partitioning, the partition table (blocks 0-62)


The MBR partition table resides in the first 512-bytes block.
It may be extended by a chain of partitions starting at the Extended
Partition of the MBR partition table.
The EBRs of the logical partitions are stored at the start of those
partitions. I.e. scattered over the storage medium.


Okay.


Examining a Windows XP disk, the first partition (C:\) starts at block 
63 (track 1):


$ cat windows-xp-parted-u-s-p.out
Model: ATA WDC WD800JB-00FM (scsi)
Disk /dev/sdb: 156301488s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End SizeType File system  Flags
 1  63s156296384s  156296322s  primary  ntfs boot


$ cat windows-xp-parted-u-chs-p.out
Model: ATA WDC WD800JB-00FM (scsi)
Disk /dev/sdb: 9729,80,62
Sector size (logical/physical): 512B/512B
BIOS cylinder,head,sector geometry: 9729,255,63.  Each cylinder is 8225kB.
Partition Table: msdos

Number  Start  End  Type File system  Flags
 1  0,1,0  9728,254,62  primary  ntfs boot


Blocks 1-62 should probably be zeros, but it appears Norton Ghost 2003 
marked this drive:


$ dd if=windows-xp-blocks-0-62.img 2>/dev/null | hexdump -C | tail -n 12
01f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa 
|..U.|
0200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
7c00  12 91 f2 60 90 a0 2f 19  01 00 00 00 85 00 67 68 
|...`../...gh|
7c10  46 44 23 cc 22 52 1d ac  22 52 32 4e 6f 72 74 6f 
|FD#."R.."R2Norto|
7c20  6e 20 47 68 6f 73 74 20  32 30 30 33 00 00 00 00  |n Ghost 
2003|
7c30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
7c90  00 00 00 00 00 00 00 04  00 94 2d d0 80 00 00 00 
|..-.|
7ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
7e00


Examining a Jesse system drive, the first partition starts at block 2048 
(1 MB = 2**20 bytes):


2017-03-08 21:30:04 root@jesse ~
# parted /dev/sda u s p
Model: ATA SAMSUNG SSD UM41 (scsi)
Disk /dev/sda: 31277232s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start EndSize   Type File system  Flags
 1  2048s 976895s974848sprimary  ext4 boot
 2  976896s   1953791s   976896sprimary
 3  1953792s  28125183s  26171392s  primary


There is content in the first 101 blocks (1 MBR plus 100 other):

2017-03-08 21:30:06 root@jesse ~
# dd if=/dev/sda count=2048 2>/dev/null | hexdump -C | tail
c990  b0 b3 2c fa a4 38 f1 f8  77 f0 2d dd c2 4a a4 a9 
|..,..8..w.-..J..|
c9a0  cd 43 15 5a b7 43 1e 6b  8b 01 ad 6f a0 b9 63 fd 
|.C.Z.C.k...o..c.|
c9b0  b8 59 4d 69 f4 33 d4 f4  0a c1 d0 61 df 84 a9 74 
|.YMi.3.a...t|
c9c0  64 44 ae 2d de bc c5 de  73 90 d8 94 ef b2 5a 7c 
|dD.-s.Z||
c9d0  fe 4c ee d8 a0 d7 ce ae  28 72 cc 5b 7e 05 23 ee 
|.L..(r.[~.#.|
c9e0  39 d0 44 7a 1c 0a 10 ab  e4 f6 3b 6f 43 d1 e6 92 
|9.Dz..;oC...|
c9f0  11 0b 3f ec c4 cf b1 ab  81 b9 5b 77 d8 be 90 c6 
|..?...[w|
ca00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
0010


What is in blocks 1-101?


David