[cAos-devel] Cinch partition_scan (was Re: System Imager)

[Nick R]

Hi.

After a bit of Research here's the useful stuff for NTFS partitions and
confirms the reasons behind the problems partitioning my NTFS drives.

In Windows, when you format an NTFS volume, the format program allocates the
first 16 sectors for the boot sector (MBR) and the bootstrap code.

The MBR (Master Boot Record) contains the Partition Table for the disk and a
small amount of executable code for the boot start. The location is always
the first sector on the disk.

The information about primary partitions and extended partition is contained
in the Partition Table, a 64-byte data structure, located in the same sector
as the Master Boot Record (cylinder 0, head 0, sector 1).

The first 446 (0x1BE) bytes are MBR itself, the next 64 bytes are the
Partition Table, the last two bytes in the sector are a signature word for
the sector and are always 0x55AA.

"The Win 2000/XP OSs make a "backup" of each NTFS volume's Boot Record
which they store in the very last sector of its partition!
[ Note: I said "partition" not volume. This is why an NTFS partition's Total
Sectors count in the MBR/EBR's Partition Table is always 1 sector more than
the "Total Sectors (in Volume)" count found in its Boot Record.
Although thewords partition and volume are often thought
of as being synonymous (we may even use them as such here!), they are
definitely not the same thing. ]"

http://www.geocities.com/thestarman3/asm/mbr/NTFSBR.htm

Nick.

On 28/02/07, Martyn <martyn at theendofhistether.org.uk> wrote:
>
>  Greg Kurtzer wrote:
>
> Dang, I wrote that code eons ago!
>
>  I know that feeling!
>
> I think what happened was that I was originally also grabbing the
> partition type which you can't get from /proc/partitions. Then I
> removed that logic for something else and didn't rewrite the function
>
> to use /proc/partitions.
>
>  That's not really what it looks like, here's what I think it's doing :
>
> scan_partitions seems to read /proc/partitions, then to check that thepartition is really accessible you run fdisk on
> the *partition* and if it outputs an error, assume it's a valid
> partition.  Unfortunately, there appear to be a few situations (partition
> used to be an extended, is now a primary is common) where fdisk will output
> a partition table /from inside/ a partition.
>
>   I know I had a hard time getting this info through to Michael on irc
> (too many opportunities for misunderstanding), so I'll repeat and rephrase :
> scan_partitions looks at /proc/partitions and sees for example hda1-4, so
> you run fdisk /dev/hda1 and check for error to see if it's a valid
> partition; rinse and repeat.  If for example hda4 used to be an extended
> partition, there's no error output, so cinch ignores it.  That seems to be
> the same for some XP NTFS partitions too as fdisk somehow interprets some
> data at the start of the partition (I'd assume a backup of the partition
> table within the fs, but not certain).
>
> As I say, the workround is to obliterate the start of all the valid
> partitions, then cinch will get an error from them, but I don't think that's
> a "solution" by any means.
>
> Hopefully I've explained well enough, but ask for more clarification and
> I'll try and explain differently.  If you think there's a possibility of
> the kernel not catching up with the partitions or something, I'd suggest
> using dd to verify we can read from the partition instead of fdisk (If
> that's why it's doing it!).
>
> So if I am understanding correctly you are saying that /proc/
> partitions is more accurate then fdisk output? I am pretty sure that
> fdisk reads /proc/partitions, but maybe in changing how it is
> represented something gets messed up....?
>
>
> Greg
>
> On Feb 27, 2007, at 3:46 AM, Martyn wrote:
>
>    Michael Jennings wrote:
>
>  I have ISO's which have done successful installs under qemu, but I'm
> holding off on calling them "2.3" until I can put the 2.6.20.x kernel
> on there.
>
>        And let's try and get some clarification on why greg doesn't trust
> /proc/partitions.
>
> Greg: in scan_partitions of cinch, you're using fdisk to clarify if a
> partition is real by looking for "no valid".... unfortunately if there
>
> has been an extended partition at the block where the partition
> starts,
> there is a valid partition table.   Also on some winXP installs, there
> seems to be a backup of the partition table in the first block of the
>
> NTFS partition, so to install on these, I have had to dd if=/dev/zero
> of=/dev/hda1....
>
> That's not really a sensible way to get cinch to see the partitions to
> install to.  Also, my preference is not to create extended partitions
>
> unless they're needed, so for the base 4-partition scheme for
> cAos-2, I
> would prefer to see hda1-4 not hda1-3 and 5!
>
>  I guess I could post them as pre-release ISO's if folks want to test
> them, though...
>
>        Well, I'm not so desperate, but maybe others are :-)
>
>  Michael
>
>        --
> Martyn (Joran)
>
>
> _______________________________________________
> cAos-devel mailing list
>
> cAos-devel at caoslinux.orghttp://lists.caosity.org/mailman/listinfo/caos-devel
>
>  --
> Greg Kurtzer
>
>     I believe the world would be a better place if people didn't
> believe in their beliefs. -- gmk
>
>
> _______________________________________________
> cAos-devel mailing list
>
> cAos-devel at caoslinux.orghttp://lists.caosity.org/mailman/listinfo/caos-devel
>
>
>
> _______________________________________________
> cAos-devel mailing list
> cAos-devel at caoslinux.org
> http://lists.caosity.org/mailman/listinfo/caos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.caosity.org/pipermail/caos-devel/attachments/20070228/5a0c4927/attachment-0001.html