79 replies to this topic

[edborg]

So what I did "automagically" rewrote and corrected the MBR!!!

Before that Partition Magic couldn't recognize the whole disk (yellow border). Now it can, though some volumes still report "errors" as per the attached view (image taken on another PC).

As confirmed by oriensol's experience I'm not the only one to have been hit by this stupid change of rules.
Given the seriousness of the problems implied, this way of acting is absolutely unacceptable, and more unacceptable is the way Microsoft "managed" the inconsistency they created, not properly warning the users of their systems.

edborg

Attached Files

•  PMXPnew.jpg   190.45KB   6 downloads

[edborg]

REPORT on Partition Logic 0.7 pre.

First of all, I couldn't get any of the necessary tools and this is obviously my fault and possible cause of failure.

Of course, you need to have handy:

• a red horn
• a rabbit foot
• a Four-leaf clover leaf

Alternatively (and of course depending on your beliefs) a Padre Pio's holy picture may also do.

Keeping your fingers crossed may help also, but don't count too much on this only.

What I did:

• downloaded the FD image (not CD ISO), as I thought it should be the same
• wrote it to FD using RAWRITEWIN as per the site's instructions
• got a "write success" reassuring message!
• first part of boot from FD successful (loading visopsys...)
• detection of USB controller, IDE controller, PS2 mouse
• some "kernel error at fd0" and subsequent freezing
• rewrote FD as above, same result
• rewrote FD with RAWRITE (not RAWRITEWIN)
• successful boot(?!), launch of Partition Logic!
• plugged the USB disk in and rebooted
• missing kernel!!!!!!!!
• ran the FD image in qEmu
• successful boot, no HD (obviously)
• re-ran the FD image in qEmu
• missing kernel!!!!!
• noticed that the FD image had changed date!
• recovered original image from downloaded zip file
• compared the two images with HexEditor
• noticed that several bytes had been changed!
• rewrote FD from original image with RAWRITE (not RAWRITEWIN)
• made the FD read only
• rebooted successfully from FD, though PL complained (or simply stated) that fd0 was not writeable!
• rebooted successfully again
• plugged in the USB disk and did the final reboot
• successful boot, program started, but USB disk was not seen
• gave up.

This pre/beta may not be ready for use, yet.


edborg

[was_jaclaz]

• downloaded the FD image (not CD ISO), as I thought it should be the same

You do remember point #f.3 of "common sense advice" attached to Rules?

There are REASONS for it.





jaclaz

[edborg]

You do remember point #f.3 of "common sense advice" attached to Rules?

There are REASONS for it.





jaclaz

Which Rules?

NO, I COULDN'T FIND ANY ADVICE on their site stating or implying that the two versions were different, so I used the FD image that I had already downloaded, as it is smaller and easier to set up.

edborg

[was_jaclaz]

Which Rules?

OUR ones:
http://www.boot-land...?act=boardrules

Don't you think that if I had wanted you to use the FD image I would have suggested you "use the FD image", instead of "use the .iso image".


Try using the .iso image in Qemu.
Connect the hd0 of Qemu to the \\.\PhysicalDrive representing the USB device in your XP.




jaclaz

[edborg]

OUR ones:
http://www.boot-land...?act=boardrules

Don't you think that if I had wanted you to use the FD image I would have suggested you "use the FD image", instead of "use the .iso image".

I see ...
Well, I haven't said you were wrong, I wouldn't dare to do that!

I thought it was useful to report the malfunctioning of the FD image which on the author's site is presented as a valid alternative to the ISO image.
Now we know (you may have known that before ) that only the ISO image works.

Sorry for using my brain (apparently it's dangerous) in addition to my fingers.

Thanks for your continuing help, anyway!


edborg

[was_jaclaz]

Sorry for using my brain (apparently it's dangerous) in addition to my fingers.

You shouldn't be sorry for that :

once the suggested steps have been tried and gave no result, your ideas are welcome, in other words we try to troubleshoot in a "logical" way, as in the famous Sherlock Holmes saying "when you have excluded the impossible, whatever remains, however improbable, must be the truth", but we like beforehand to exclude the possible, the common, the probable, and this approach solves problems in a MUCH faster way in a large amount of cases.

You simply connected it a bit too early.


@wimb
Sorry , I wrote "formattted" but I really meant "partitioned".


For the record:
if you try using FIPS (also included in UBCD) on a "strange" disk (like the fake one i made to test the behaviour of the partitioning edborg reported, you get a message like:

FIPS has detected that the 'physical' start or end sector (head/cylinder/sector) do not match with the 'logical' start/end sector. This is not an error since the 'physical' values are redundant and not used anyway. There are many configurations where the value differ. This message is only meant to inform you that FIPS has adapted the 'physical' values according to the current drive geometry. So don't be alarmed by an unexpected cylinder range.

which seems to me fair enough.
In a perfect world, once a partition type has been declared as "LBA", like 0C (FAT32 LBA) 0E (FAT16 LBA) or 07 (NTFS) the WHOLE CHS datra should become "a suffusion of yellow" and ONLY LBA data should be used.
Also the known (but not re-known ) problem with the MS bootsector of FAT32 and NTFS wanting to check ANYWAY the H/S geometry :
http://www.911cd.net...o...1702&st=129
http://www.boot-land...?...=8528&st=21

Seems like a big hiccup from the MS guys, the whole point is not about the mistakes they make (which is only human ) it is about the complete lack of information about them. (and the providing of adequate fixes).



jaclaz

[oriensol]

Adding a picture of the Vista Disk Management with four primary and one extended partition :

[edborg]

I've solved otherwise so I don't need it anymore, but just for the record and in case of future need, what was/is the problem with Partition Logic Pre FD vs the ISO version?

edborg

[was_jaclaz]

I've solved otherwise so I don't need it anymore, but just for the record and in case of future need, what was/is the problem with Partition Logic Pre FD vs the ISO version?

edborg

That's your problem.

I tested the .iso and reported it to be working.

You did not follow my instructions and used the FD, introducing a variation , and it did not work for you.

Names: jaclaz - edborg

Binary:   1   -   0

No need to whine, sometimes variations work, sometimes they don't, in this case it didn't and it was you that introduced it.

For future use: use the .iso



jaclaz

[wimb]

I did some tests with a 19,5 GB Harddisk partitioned in Windows 7 as

9000 MB Primary | 3000 MB Primary | 3000 MB Primary | Extended about 4500 MB

Then I made 3 Logical drives in Extended - 2000 MB | 1000 MB | 1500 MB

Note that in Windows 7 the Extended Partition is created automatically
and ONLY after 3 Primary Partitions have been defined.

After reboot with XP I made some Screenshots before and after setting Active the second partition.

All of a sudden the second and third Logical drive of the Extended Partition disappeared.

It turned out that the daisychain of EPBR's was broken,
because Set Active of XP disk Management wiped in EPBR1 the entry indicating the location of EPBR2

Note that all partitions end nicely at cylinder boundary (H=254 S=63)

The problem only occurs for second and higher Logical Drives created with Vista or Windows 7,
which disappear when XP Disk Management is used to Change the Active Setting of the Primary partitions.

MBR and all EPBR's and all partition Ends are well aligned at Cylinder boundary,
but it seems that XP has a bug in computing which Logical drives are valid for the EPBR daisychain.
The number of hidden sectors (2048 for Window 7 and 63 for XP) is may be not taken properly into account.

Simply using TinyHexer to restore EPBR1 from Backup created previously with MBR_Backup.cmd
did solve the problem. On Reboot the missing Logical drives reappeared.

To create a valid daisychain which is insensitive to using Set Active,
it is needed to remove the first Logical Drive with XP Disk Management and
then to recreate new Logical drives having 63 hidden sectors.

EDIT:
P.S. Changing in EPBR1-3 the partition start from C/H/S = 1023/254/63 into 255/32/33 or in 1023/32/33
did NOT solve the problem.

It must be concluded that the value of 2048 for hidden sectors is not taken properly into account by XP
in the check for a valid daisychain of EPBR's.

The problem of loosing Logical drives on using Set Active in XP disk Management can be avoided by
making with Vista or Windows 7 Disk Management NOT more than 4 partitions.

=

=
AFTER Set Active

=

=

=
After Set Active

=

This all confirms observations done earlier by edborg

[was_jaclaz]

This all confirms observations done earlier by edborg

Yep , but 0/32/33 is NOT a valid partiton start Cylynder boundary AND 2048 LBA is of course not.

The Windows 7 creates 1023/254/63 as START of the subsequent partitions, which is NOT a Cylinder boundary for "start", a Cylinder starts at Head 0, Sector 1 and ENDS at Head 254, Sector 63.

My tests and edborg's one show that XP uses 1023/0/1 (unlike your previous report).

As said, I suspect that this is at least part of the reason.

I have no explanations for why your XP, as you reported previously, creates partitions with 1023/254/63 and it would be interesting if you could repeat the tests starting from scratch on XP.

Or, the other way round, can you from within Windows 7 manually change the START CHS for all partitions but the first one (and also ALL Logical volumes inside Extended) to 1023/0/1 instead of 1023/254/63 and try the thingy on Windows XP to see if the behaviour is the same?

But the tests should be made with a 7 with the "registry fix", so to have an "old style" alignment.



jaclaz

P.S.: attached the result of following your steps on a XP (actually ERD50) virtual machine:

Attached Files

•  Edborg_MBR.html   7.32KB   4 downloads

[wimb]

P.S.: attached the result of following your steps on a XP (actually ERD50) virtual machine:

Starting from scratch using XP Disk Management for partitioning gives:

=

=

Beyond CHS limit then partition start reads as C/H/S = 1023 / 254 /63
correspondig in partition table to FE FF FF for H/S/C as reported previously.

Apparently ERD50 is NOT the same as regular XP.

[edborg]

I did some tests with a 19,5 GB Harddisk partitioned in Windows 7
......

Simply using TinyHexer to restore EPBR1 from Backup created previously with MBR_Backup.cmd did solve the problem. On Reboot the missing Logical drives reappeared.

Goot to know!

The problem of loosing Logical drives on using Set Active in XP disk Management can be avoided by making with Vista or Windows 7 Disk Management NOT more than 4 partitions.

Or, as you already suggested, by always using XP to create partitions to work in both OSes.

Thanks for the clarifying tests!

edborg

[was_jaclaz]

Apparently ERD50 is NOT the same as regular XP.

Definitely.

But then, why edborg reported 1023/0/1 as well?

Is it possible that different versions of disk management/diskpart in XP produce different results?

Why are your LBA values slightly different from mine?

I followed exactly the steps you listed:
Primary:
9000 MB
3000 MB
3000 MB
Extended:
Rest of disk <-this ONLY may of course be slightly different
Logical:
2000 Mb
1000 Mb
Rest of disk <-this ONLY may of course be slightly different

"my" 18442557 mean END CHS 1147 ->1148*255*63-63=18442557*512=9442589184/1024=9221278,5/1024=9005,15 ( I swear I put 9000 in the box) 9005,15/1024=8.794 Gb (as shown in the drive list)
"your" 18426492 mean END CHS 1146 ->1147*255*63-63=18426492*512=9434363904/1024=9213246/1024=8997,31 8997,31/1024=8,786 Gb

Right now I have no way to install an XP in a Vm to test.
But I will and let you know, so that we can try again.

Maybe we could "switch" to diskpart, this way we will have a "same" script and there cannot be differences.

I will create a virtual disk exactly 2491*255*63 in size, like yours is seen in beeblebrox i.e. with size 2491*255*63*512=20,489,172,480 and see if it makes any difference.



jaclaz

[was_jaclaz]

OT, but not much , and just to keep everything as "together" as possible, a previous mishap by the good MS guys:
http://www.allensmit...t/OS/XOSL/I.htm

Microsoft Operating Systems MS-DOS through Windows 98 or even Windows ME have a bug where, if the last logical partition in the extended partition is not a recognized file system type, and multiple visible FAT primary partitions exist, it will use the last logical partition as a FAT one in place of the next primary partition. But it will think the size of the partition is that of the primary partition. Data coruption can occur!

jaclaz

[wimb]

For comparison I have tried to partition with GParted and using Linux as operating system.
For this purpose BOOT_IMG.exe was used to install pmagic-4.6.iso as boot option in GRUB4DOS menu.

After booting with Parted Magic my test USB-Harddisk was partitioned from scratch with GParted:

=

=

The result is similar as obtained earlier using XP Disk Management.
The first Primary partition and all Logigical drives have the usual 63 as number of hidden sectors.
In this case there is no problem with Setting Active e.g. the second Primary partition.
All Logical drives remain visible after using Set Active in XP Disk Management.

Beyond CHS limit then partition start reads as C/H/S = 1023 / 254 /63
correspondig in partition table to FE FF FF for H/S/C as reported previously.

Interesting to note is the difference in the partition BootSector.
GParted in Linux OS does NOT make NTLDR-type BootSector.

Instead one obtains with GParted for NTFS format a BOOTMGR-type bootsector and
for FAT and FAT32 the BootSector code is missing at all resulting in non-bootable drives.

[Wonko the Sane]

Just to keep things as together as possible, something possibly unrelated, but where some additional related ideas/infos are thrown on the table:
http://www.boot-land...showtopic=10200



Wonko

[Wonko the Sane]

A small confirmation:
http://support.micro...kb/931854/en-us
http://www.dcr.net/~...gPartitions.htm

Obviously MS doesn't mention that only changing the Active status may create the problem.


Wonko

[Zoso]

A small confirmation:
http://support.micro...kb/931854/en-us
http://www.dcr.net/~...gPartitions.htm

Obviously MS doesn't mention that only changing the Active status may create the problem.


Wonko

bumping old thread to ask related question and BTW i can confirm that changing only the active status from one primary partition to another erases all logical ones.

Wonko, is it better to stick with XP for partitioning drives that will only be readjusted later with XP or would it still be better to use vista or later for partitioning even for XP based multiboot systems?

also, does XPx86 or XPx64 make any difference?


thanks

[Wonko the Sane]

The basic message is:

NEVER use Windows XP disk management to set a partition active/change status of active partition, and I mean NEVER.

There are tens or hundreds of tools capable of doing that (if needed) and anyway it is a simple disk edit which can be done with a hex editor in case, or -say - with grub4dos.

 

Your question is maybe more revolving instead around the opportunity of having cylinder/head alignment or Mb alignment, and a line must be drawn somewhere (actually several lines are needed):

1. on normal 512 bytes sector hard disks there won't be that much of a difference (unnoticeable in practice)
2. on USB sticks (still 512 bytes sector) the difference on having the filesystem(s) aligned is noticeable, the aligned ones are faster, this probably will be less noticeable on USB 3.0 sticks
3. on USB 3.0 sticks, one might want to consider that the stick may be both of the "traditional" type and of the "faster" ones that are actually a USB to SATA converter+SSD, the difference with the first will likely be trivial, the difference with the second will be noticeable
4. on AF disks (disks that have 4096 bytes sectors internally but expose  512 bytes sector externally) the MB alignment is advised
5. on SSD the MB alignement is advised

A specific device might however have some internal provisions to deal with non Mb aligned partitions, so the above not necessarily applies (in the sense that there won't again be any noticeable speed difference when compared to a Cylinder aligned partitioning scheme).

 

No idea  if the bug in Disk Manager was fixed in XP64 (please read as "dumbed down Server 2003 x64").

 

Wonko

[Zoso]

im setting up a new usb hdd for multi booting, multi partitions, with multi XPs, some in extended partitions so i will be manually editing the sector info with PTedit, in the past ive always used the 63 sector diff. isnt this the allignment we are talking about? the starting sector offset or no?

this is where XP and W7 partitioning differ i think, starting offsets, right?


I will test XPx64 to see if it has the bug before I start again since I plan to zero out everything on the usb hdd first. is there anything else you can think of that i can test with XPx64 about this while I have the blank space so not to worry about loosing any data?

hopefully XPx64 dont have the bug! i will report back after i test it.

thanks

edit: XPx64 does NOT have this bug! i tested it twice with a lexar USB flash with removable bit flipper so it appears as fixed disk in W7 where i partitioned it with 7 partitions, 3 primary ones and 4 in extended. went to XPx64 and changed the active partition and all is well (twice) next i went to XP x86 and changed the active partition and sure enough, all partitions in the extended area except the first in the extended (fourth partition) were instantly gone! did this twice also.

maybe i should check starting offsets from a disk partitioned in XPx64 to see if that is different, anything else i should check while im at it?

2nd edit: interesting.. I zeroed the disk and then did the same partition layout except instead of using W7, i used XPx64 then tested changing the active partition in XP x86 and then again in W7 (several times each) and everything worked as you would expect with no problems. now to fire up pttedit and have a look at it.

[Wonko the Sane]

Yes, the cylinder/head boundary (sector 63 on a 63 sectors per head device) was the "standard" up to XP.

Vista introduced the 1 Mb alignment (senselessly because what is actually *needed* is the 4096 bytes one).

Any partitioning tool developed up to Vista will make a logical volume with an extended partition "wasting" 62 sectors (like there are 62 "wasted sectors" right after the MBR on 63 sectors devices).

Vista (and later) will have the 1 Mb (2047 wasted sectors) after the MBR and - by the same token - the same amount after each EMBR before the logical volume.

 

The XP Disk Manager bug is seemingly because this 63 is *somehow* "fixed", but in itself it won't be a bug, the real bug is that the thingy decides to re-calculate the whole partition table in the MBR and various EMBR wen you ask it to set a partition active (which makes NO SENSE whatsoever since all was asked to it was to change one or two bytes in the MBR), a clear example of (badly implemented) over-engineering.

If that happened when a new partition was created (as the KB states) it would be all in all  "normal", the really perplexing part is that it happens even if you just change the active partition.

 

Since XP 64 is actually Server 2003, it is very possible (and you just confirmed that) its Disk Management is not affected by the issue, most probably its code is more recent than the XP one, still from what you report, it still uses the "old standard" (and thus the XP x86 is happy with that).

 

Wonko

[Zoso]

I have a POSReady2009 system too, its basically XP x86 but still supported. I will test this on that one too when I get a chance.

until then, if I stick with XPx64 diskmanager exclusively for all windows i should be good to go then unless its on an SSD drive, if so then use W7 diskmananger, right? and what about SDCards.. are they considered as SSD? i assume so, but worth asking since I use them in USB adapters often.

[Wonko the Sane]

SDcards are not SSD's, but since you use them in USB adapters, they belong anyway to the "USB sticks", since all in all your adapter+SD card=USB stick.

 

For different reasons from the SSD's they will benefit anyway from having the partitions aligned to 4096 bytes (if NTFS), if you use FAT32 on them you will need to align the filesystem, see:
http://www.msfn.org/...n-its-clusters/

http://3gfp.com/wp/2...d-and-lifetime/

http://reboot.pro/to...-memory-drives/

 

AND you should have been already aware of this:
http://reboot.pro/to...-a-sdsdhc-card/

 

 

Wonko