Jump to content

System Partition Offset is 64 Sectors, instead of 63 or 2048 sectors.


Recommended Posts

post-340011-0-90865200-1344804163_thumb.

Figure1: Partition layout for my Win7 machine, 1TB system HDD. Fig.1 shows the situation until a few months ago with the recovery partition (NO NAME, Hid.FAT32X [type=1C]) at the beginning of the system HDD, i.e., on the outermost tracks of the HDD. Note the offset and alignment, which is 2048 sectors (sector =512 bytes), typically for Win7. In the PartitionInfo pane the Start Sectors (Actual meaning is Sectors Before or Hidden Sectors) and Total Sectors in the recovery partition (NO NAME) and the system partition (C:\) are nicely divisible by 2048. Note also in the bottom pane the CHS geometry for the recovery partition (NO NAME): bCHS=0/32/33 and eCHS=1023/254/63 . For the C:\ partition bCHS=eCHS=1023/254/63 .

post-340011-0-35314900-1344804177_thumb.

Figure2: Shows the situation after I shifted the recovery partition to the end of the system HDD, i.e., innermost tracks, and after reinstalling Win7 on C:\. So the system partition is now the first partition on the outermost tracks. Note the offset of the system partiton, which is 64 sectors in stead of 2048 sectors. Also the Boot Sector info of the system partition clearly indicates there are 64 (and NOT 63 nor 2028) hidden sectors. I've also done the test with the old PowerQuest's Partition Table Editor (PTEDIT32.EXE) and the result is the same: offset is 64 sectors. On my WinXP machine PartitionInfo and PTEdit32 both show an offset of 63 sectors, which is correct for a WinXP partition scheme. On the other hand, the last sector of the system partition in Fig.2 seems to be correctly alligned along the Win7 convention. Again, note the CHS geometry of C:\ being bCHS=0/1/2 and eCHS=1023/254/63, and of the recovery partition bCHS=eCHS=1023/254/63 .

Has anyone seen such a 64-sector alignment in Win7 before? What could be the reason for that? An alignment of 64 sectors is OK/good for Advanced Format Drives where the physical sectors are 4096 bytes long, but so is an alignment of 2048 sectors OK for AF drives.

Another thing is the CHS geometry. In both Figures only the first partion has a bCHS which is different from eCHS, while for the second partition onwards bCHS=eCHS=1023/254/63. Furthermore, bCHS=eCHS=1023/254/63 is the more recent convention of saying don't look at CHS, while bCHS=1023/0/1 and eCHS=1023/254/63 is maybe the more older convention of saying don't look at CHS [ ]. What I can't grasp is that in Fig.1 the CHS of the C:\ partition says not to look at CHS, while in Fig.2 the "not-to-look-at-CHS" convention (the new as well as the old one) is not there anymore for the C:\ partition, which is now the first partition. Can anyonw shed some light on this issue and explain me why the "not-to-look-at-CHS" convention does not apply/appear on the first partition of the system HDD?

j

Link to comment
Share on other sites


There is nothing "wrong" in your partition table.

The first partition starts on sector 64 (which IS CHS 0/1/2) and ends beyond the CHS limit (and thus CHS is at it's max values 1023/254/63).

The second partition is entirely beyond the CHS limit ad thus it has CHS values 1023/254/63 1023/254/63).

Yes, we can debate if the second partition should be 1023/0/1-1023/254/63 instead, but it won't make any difference in 99.99% of cases.

You have clearly a "missing piece" in the puzzle :w00t: .

Any address BELOW the CHS limit (in this case of 255/63 geometry) aroung 8Gb or 1024*255*63*512= 8,422,686,720 bytes MUST be represented BOTH in CHS and LBA addressing.

As a matter of fact ANY address MUST be represented along BOTH the addressing methods, the only difference is that for partitions extending beyond the CHS limit, the CHS address resolves to "a suffusion of yellow".

How exactly did you get the 64 sectors before alignment? :blink:

Most probably just like Tripredacus did here:

though "somehow" using an "align=32" with diskpart or using one of the "disk manufacturer" Advanced Format formatting tools designed for XP :unsure:

jaclaz

Link to comment
Share on other sites

I got an ASUS laptop. Once the laptop has booted into the recovery partition, and the recovery/installation process has started, the installation process is fully automated and runs all the way until Win7HP with all the bloat- and crapware has been installed.

Yes there is ImageX that deploys onto the C:\ system partition the images from the recovery partition, starting with /sources/BOOT.WIM. But, as far as I understood ImageX just deploys images into an existing partition, and that partition is probably created by AsDeploy.exe or AsChange.exe (but I'm not sure), which are located in the root directory of the recovery partition. As far as I understood and not mistaken, ImageX itself does not create any partitions, at least not in a direct way.

I've been searching the entire recovery partition (into all files) for the string "align=32", but no hit. Using the cmd prompt I've used the commands FIND, FINDSTR, and GREP (for windows). Looking for the string "align=4" gave me a hit in a *.log file located in the root directory of the recovery partition. Could it be that the "align=32" information is stored in a compressed or encripted file somewhere?

I just wonder what application exactly in the recovery partition creates the C:\ system partition in "usual" circumstances, and what/where its batch file, *.ini file, or any script file may sit exactly in the recovery partition?

j

Link to comment
Share on other sites

I've been searching the entire recovery partition (into all files) for the string "align=32", but no hit. Using the cmd prompt I've used the commands FIND, FINDSTR, and GREP (for windows). Looking for the string "align=4" gave me a hit in a *.log file located in the root directory of the recovery partition. Could it be that the "align=32" information is stored in a compressed or encripted file somewhere?

Well, most probably "align=4" is used (instead of "align=32").

The result shoudl be the same. :w00t:

It seems like the "align=4" implies "offset=32", i.e. it actually means not "align to 4 Kb" but rather "align to 4 Kb at first multiple equal or beyond 32 Kb".

The "full syntax" is something like:

create partition primary offset=m align=n

where m=32|64|128|256|512|1024|2048 and n=2|4|8|16|32|64

Result being that:

create partition primary offset=32 align=4
create partition primary align=4 (offset=32 is assumed by default)
create partition primary align=32

all have the same result.

It is very possible that the diskpart script (IF diskpart is used) is inside a compressed archive of some kind, yes.

jaclaz

Link to comment
Share on other sites

Yes there is ImageX that deploys onto the C:\ system partition the images from the recovery partition, starting with /sources/BOOT.WIM. But, as far as I understood ImageX just deploys images into an existing partition, and that partition is probably created by AsDeploy.exe or AsChange.exe (but I'm not sure), which are located in the root directory of the recovery partition.

Really, they actually have imagex.exe in there? :ph34r:

Don't forget, they could also use an answer file to define partition data if they need to do something custom. But, for the most part even a Setup based recovery doesn't do anything with the partition... in fact I'm not even sure if they even format it. You'd have to test because a stock recovery partition backs up the entire OS volume and puts it into C:\Windows.old. If you end up having a Windows.old with the old C: drive stuff in it, its likely using one of the Setup.exe in there. If not, then it could be using a custom thing.

Basically, what I'm getting at is that the partition layout may not ever be changed by the recovery software, and may have been that way from the factory.

Link to comment
Share on other sites

Basically, what I'm getting at is that the partition layout may not ever be changed by the recovery software, and may have been that way from the factory.

Very probably the partition offset it is not changeable, and therefore fixed at 64 sectors, very fustrating it is. Now I have to find a way of fixing the offset problem and try to set it on 2048 sectors.

j

Link to comment
Share on other sites

After jaclaz's post I couldn't quite figure the interaction between the OFFSET and ALIGN commands.

So, just as an exercise, I've tested the OFFSET (DISKPART v.6.1 (Win7)) command on an old 250MB USB Flash Drive. I don't have any USB HDD for testing, so used a USB FD. In Diskpart, the command line I performed was:

DISKPART> create par prim size=110 offset=n (where n sweeps from 1 to any integer value.) ALIGN was not used at this stage. The table below shows n as a funtion of the true partition offset (KiB) of the (first) partition on the USB FD.

n Offset (KiB)

1 64

63 64

64 64

127 64

128 128

191 128

192 192

255 192

256 256

320 320

383 320

384 384

447 384

448 448

511 448

512 512

In the table the true partition offset on the USB FD snaps to the nearest lower value corresponding to 2^(whatever integer) until an offset=128KiB has been reached. From that point onwards there are intermediate downward snap values introduced which lay in the range 2^(m) and 2^(m+1) starting from m=7. It looks for m=7 the range is chopped in two, that is, 128->191 and 192->256; and for m=8 the range is chopped in four, that is 256->319, 320->383, 384->447 and 448->512. Maybe the number of choppings (2, 4, ..) obey the law 2^(m-6) for m>6 and m =integer, but I'm not sure, more investigation should be done.

Furthermore,

create par prim size=110, (so without offset) results in a true partition offset of 64KiB on the USB FD.

create par prim size=110 offset=0 results in NO action, meaning that no partition has been created.

create par prim size=110 align=0, results also in a true partition offset of 64KiB on the USB FD. So it looks like align=0 means there is no alignment specified.

Then I kept OFFSET=160 constant and swept the alignment parameter.

Create par prim size=110 offset=160 align=n, where n sweeps from 0 to a any integer value. Table below gives the partition offset (in KiB) of the (first) primary partition as given by the Diskpart command DETAIL PAR. The DETAIL PAR figures where confirmed by PTEdit.

n Offset (KiB)

0 128

1 156

2 160

3 159

4 160

5 160

6 156

7 154

8 160

9 153

10 160

11 154

Figure who can figure this! To me it is a mistery how the OFFSET and ALIGN commands interact. I've been Googling around the net but I have to say it is very difficult to find any info about DISKPART commands v6.1 (Win7). Even on the MicroSoft webpage Diskpart was the WinXP version, couldn't find the v.6.1.

j

Edited by DiracDeBroglie
Link to comment
Share on other sites

Figure who can figure this! To me it is a trully a mistery how the OFFSET and ALIGN commands interact. I've been Googling around the net but I have to say it is very difficult to find any info about DISKPART commands v6.1 (Win7). Even on the MicroSoft webpage Diskpart was the WinXP version, couldn't find the v.6.1.

I don't get it.

It seems like a nice experiment, though it makes to me little sense :w00t: (both in the actual contents and in the way the results are presented :ph34r: ).

I used a (totally arbitrary ;)) standard that sets m as the variable for the offset command and n as the variable for the align command and you used n for BOTH?

The allowed values m for the offset command are seemingly:

m=32|64|128|256|512|1024|2048

What you have found is that if you use any other value it will be rounded up or down to the next allowed value BUT that there are a few allowed values not listed in the above :thumbup .

Here are in green the above "known allowed values" and in red the "additional ones you found":

32

64

128

192

256

320

384

448

512

1024

2048

Most probably there are more such values in the range beyond 512 (that you have seemingly not explored).

Why have you not tested m=32 ?

Why have you not tested the three lines I posted? (just to see if theory and practice are the same - by pure chance)

  1. create partition primary offset=32 align=4
  2. create partition primary align=4
  3. create partition primary align=32

I am pretty sure about the "create partition primary align=32" :

http://www.msexchange.org/tutorials/disk-geometry.html

resulting in a partition starting on sector 64, the other two are the ones to check.

The allowed values n for the aligncommand are seemingly:

n=2|4|8|16|32|64

What you have found is that there are a few allowed values not listed in the above :thumbup .

But you started with a "not allowed" value of m=160 (which probably results in a 128 :unsure:), so I don't think that your results are - if not for the "allowed" values - following a "logic", it is more likely that they are a "side effect" of using such non-standard values (if you prefer a "bug" in the parsing mechanism).

jaclaz

Link to comment
Share on other sites

I did use m=32 for the offset. However,

DISKPART> create partition primary offset=32

snaps the partition offset to 64KiB on the USB FD, and definitely not to 32KiB. That was the reason why I didn't mention it in my previouse post, where only offset=m values were given showing how the real partition offset on the USB FD snapt to particular pivotal values. And as OFFSET=31|32|33 all snapt to a partition offset of 64KiB, I did not mention OFFSET=32.

Furthermore,

create partition primary offset=32 align=4 ,

create partition primary align=4 ,

create partition primary align=32

all resulted in a partition offset of 32KiB on the USB FD.

However,

create partition primary offset=32 align=0 ,

resulted in a partition offset of 64KiB on the USB FD.

The reason for doing the test was that I got puzzled by the notion of "allowed" values (like in: "the allowed values n for the align command are seemingly: n=2|4|8|16|32|64" ). When something is "allowed", then there must be something that is "not allowed", and something that is "not allowed" should give you a warning or error message. But I didn't get any warning or error message when I just happen to try m and n values outside the "allowed" series (except for DISKPART> create par prim size=110 offset=0).

So I started scanning the values m and n and bumped into what I posted in my previous post.

This is not really in the scope of my original problem, and I will not spend any more time in it --- I just wanted to mention that awkward thing.

I'll still have to try out a few other tests and see if I can get the system partition aligned to 2048 sectors. If that does not work, I'll have to use diskpart from the repair disk, create a new correctly aligned NTFS partition and install a clean Win7 (from Digital River) into the new partition.

It would be nice if someone could reproduce the same offset-tests on a USB FD, and also on a (USB) HDD, just to see if DISKPART v6.1 treats a removable media device the same way as a non-removable media device.

j

PS: BTW, thanks for the link

Link to comment
Share on other sites

Furthermore,

create partition primary offset=32 align=4 ,

create partition primary align=4 ,

create partition primary align=32

all resulted in a partition offset of 32KiB on the USB FD.

Good, that was the expected result. :thumbup

Which should mean that what is actually used (and that is confirmed by the log) is the align=4.

Now the difficult part is to find where it is (inside .exe/compressed/whatever) :ph34r:

However,

create partition primary offset=32 align=0 ,

resulted in a partition offset of 64KiB on the USB FD.

I have no way (since as you have find out the documentation is "flaky at best") to confirm what I posted, (re: allowed values) but 0 is NOT among the ones presumably allowed for the align=n, it is very possible that the thingy, finding 0, assumes 64 and "overrides" the offset=m value of 32.

The reason for doing the test was that I got puzzled by the notion of "allowed" values (like in: "the allowed values n for the align command are seemingly: n=2|4|8|16|32|64" ). When something is "allowed", then there must be something that is "not allowed", and something that is "not allowed" should give you a warning or error message. But I didn't get any warning or error message when I just happen to try m and n values outside the "allowed" series (except for DISKPART> create par prim size=110 offset=0).

Sure, it all depends from the character of the programmer :w00t:, if I had written that executable, when you would input a non-allowed values a little hand would come out of the screen and slap you hard in the face, and in the meantime the loudspeaker would tell you how you are a moron for not having RTFM!.

The usual character of MS programmers (of course there are exception and a lot of nice guys among them) is based on an assumption (actually three of them):

  1. we are waaay smarter than you
  2. we know better than you
  3. whenever you use something that is not documented properly (please read as *anything*) the program will do what is better for you, WITHOUT telling you (otherwise you may learn something)

jaclaz

Link to comment
Share on other sites

  • 2 weeks later...

I got the problem of my system partition (C:\) with its 64-sector offset finally solved. There is clearly something wrong with the ASUS installer environment, meaning the 20GB recovery/installer partition on my system drive. At first the recovery partition was located at the very beginning of the system drive, with an offset of 2048 sectors. All partitions installed (including C:\) from the recovery partition, had their first sector located at an integer multiple of 2048 sectors (1MiB).

Once I shifted the recovery partition to the back of the system drive, the first partition (which was then the system partition; C:\) created by the recovery started at 64 sectors from the very beginning of the drive (with MBR on sector 0). Strangely enough the size of the system partition was an exact integer multiple of 2048 sectors, while the partition following the system partition (2nd par) started at an exact multiple of 2048 sectors. In other words, there was a gap of 2048 - 64 = 1984 sectors between the system partition and the beginning of the 2nd partition (which was an extended data partition).

My concern was to get the 64-sector offset shifted/moved to 2048 sectors or an integer multiple of it. Next is an explanation of the steps I followed to solve the problem.

Step 1: The size of system partition was 390GB, so that needed to be shrunk quite a bit. I got rid of the hiber.sys file (12GB) by switching off hibernation mode in the cmd prompt using the command >powercfg -h OFF Also the pagefile.sys (16GB) was removed by turning off the virtual memory.

Step 2: Is about shifting all the files to the outermost tracks in the system partition, including the so-called "unmovable" system files. I used the defraggers UltraDefrag and Disk Defrag from Auslogics.com. Auslogics Defrag did a good job by not only defragging but also shifting the files to the beginning of the partition INCLUDING the unmovable system files. I had to alternately use UltraDefrag and Auslogics Defrag several times (and reboot in between) before Aulogics then finally moved the system files too, putting them at the beginning of the system partition; so Auslogics didn't move the system files so easily. I also tried out Defraggle from Piriform but that one did not move the system files to the beginning of the system partition. So Auslogics Defrag does not only defrag but seems to compact also all the files, including system files, to the beginning of the system partition and that is exactly what I needed.

Step 3: Shrinking the system partition. I did that in Win7 Disk Management (DM); the system partition shrunk from 390GB to less then 40GB, thanks to Auslogics Defrag which cleared the end of the partition of any unmovable system files. Using DM keeps the size of the shrunk system partition at a multiple of 2048 sectors (1MiB), and that is very important. Some time ago I used GPartEd liveCD v0.12.02 but GPartEd puts the end of the (any) partition at a multiple of 2048 sectors (1MiB) resulting in a partition size which is not a multiple of 2048 sectors, and that causes some other annoying side effects (as far as I can recall). Hence that this shrinking should be done with DM, not any other tool, unless the other tool keeps the partition size at a multiple of 1MiB. After shrinking there was 350GB unallocated area following the system partition.

Step 4: Move the system partition to the very end of the unallocated area. That was done by GPartEd. The first sector as well as the system partition size were at a multiple of 2048 sectors (verified with Tiny Hexer and PTEdit.exe). I had to use the Win7 Repair Disk, though, to fix a boot problem but after the fix I could swiftly boot into the relocated system partition. The partition move/shift took somethink like 10 minutes, thanks to fact that the partition got shrunk first to only 40GB.

Step5: Using GPartEd I shifted the system partition back to the very beginning of the unallocated area part. GPartEd did put the partition automatically at an offset of 1MiB (2048 sec) from the very beginning of the drive. After restart, the computer booted immediately into the system partition, no need to use the Win7 Repair Disk. The reward for all that hassle is that booting is now a lot faster then before.

Concluding, my system partition is now correctly aligned at 2048 sectors and its size remains a multiple of 2048 sectors too.

------

Some remarks, though:

When recovering from the ASUS recovery partition (hold down F9 when booting) there are 3 options:

1-Recover Windows to first partition only.

2-Recover Windows to entire HD.

3-Recover Windows to entire HD with 2 partition.

Options 2 and 3 work fine, except that they put the system partition at an offset of 64 sectors from the beginning of the system drive. Options 2 and 3 do not overwrite the 20GB recovery partition, which is now located at the end of my system drive (inner tracks).

Option 1, however, ignores the already existing system partition (what ever the offset; 64 or 2048 sectors) and starts installing Windows 7 into the recovery partition thereby overwriting and destroying the recovery partition, resulting in a crash with the word ERROR in big letters on the screen, WWWAAAAAAAAWWWWW. But, ... no problem, I re-imaged the recov partition from my backup drive using GPartEd and off I went again.

Some folks at ASUS clearly made a mess when composing the recovery partition.

------

In the mean time I've moved the system partition again further into unallocated area (inner tracks), creating space for a new system partition on the outermost tracks holding a Win7 Clean Installation from http://www.mydigitallife.info/official-windows-7-sp1-iso-from-digital-river/ . Now I got two Win7 installations from which I can choose at boot time. The Win7 Clean Installation will become the final version but still needs tuning, the ASUS Win7 (with all its bloatware) will go out at some stage.

j.

Edited by DiracDeBroglie
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...