And a bit off-topic (but you started it ) what have you got against the way my 1TB HDD is partitioned?. It's a triple-boot, so that covers the first three partitions (I normally hide both of the partitions I'm not currently booted from, but I deliberately left one unhidden at the moment to transfer some files). There's actually a 3.91GB P4 which I intended to use for the Swap-file but then changed my mind and then there's P5 which is the 873GB Extended Data partition.
I like to have my
partitions "look" good
You have two partitions using for start CHS address 1023/0/1 and ending on 1023/254/63 (which is one of the two conventions to say "don't look for CHS" - the "old" one) and one that use for start CHS address 1023/254/63 and ending on 1023/254/63 (which is the other convention to say "don't look for CHS" -the "new" one).
In theory, there is no problem whatsoever.
In reality it is possible that some BIOSes or partition related tools ONLY know about the "old" convention and don't "like" the "new" one or viceversa.
Since the partitioning has evidently been made with the "old" approach of respecting cylinder boundary, it would make sense to have also partition #2 to have the "old" style 1023/0/1 as start address.
Additionally (and this greatly depends on the actual OS you are running or plan to run on that system), the "P5" is crossing the 128 Gb LBA28 boundary, and this may provoke issues if - for any reason - the BIOS or an OS you try on it doesn't fully comply with LBA48.
Finally - in my simplicity - the sheer thought of a single 873 Gb partition makes me shiver, besides some of the possible issues above listed, how looooong does it take to defrag or CHKDSK that partition?
Or, the latter seen in another way, let's analyze probabilities of a (very limited) software or hardware failure, that wipes or makes unreadable (for any reason) 200 sectors.
MBR and each single PBR, if affected by such an issue can normally be recovered in no time, using information gathered here and there from other parts of the disk.
The various $MFT's are another matter, and the amount of recoverability of data with a failed or missing $MFT depends on too many factors (BTW a complete defragging does make a difference)
Please follow me, this is just theory, but you never know.
Out of the whole disk, you have more than 90% of it's capacity "in the hands" of a single $MFT.
In total you have 5 $MFT's.
Chances that the "200 sectors" hole will happen on this particular $MFT are pretty much low, to simplify we can divide the hard disk in 100 sectors "parts" and we can say that if any of two "parts" covering the beginning of a $MFT are "hit", then you lose a $MFT, so 2*5/2,178,815,688/100=1/217,881,568.8=4,5896493471548750845968757316934e-9
If you divide the huge partition in (say) 8 smaller partitions, the probability is obviously (5-1+8=12):
this is obviously far more probable, actually 24/5=almost 5 times more probable, but only apparently so in terms of data.
IF disaster happens with your current partitioning, you have on average (rounded data):
(2,1%+1,6%+2,1%+0.3%+94%)=100 and 100/5=20%
but if (once every five disasters
) you hit the last partition, you have a peak of 94%.
With a more segmented partitioning scheme, you would have:
(2,1%+1,6%+2,1%+0.3%+11,75%+11,75%+11,75%+11,75%+11,75%+11,75%+11,75%+11,75%)=100 and 100/12=8,34%
In the worst case, you would lose only -at the most -11,75% of the data.
Which strategy would you choose?
Do you like better to have 1/5 probabilities but risk the peak or to have 5 more times the probability but risk less than 1/10 in size?
If you prefer, there are NO real issues
, BUT there are the "seeds" for a possible future disaster
Back to topic.
Both the MBR partiition table and the bootsectors look "ok" for a 16/63 geometry
The partition type is 0B that means FAT32 CHS mapped, due to a number of reasons too long to list here, it is possible that there is a conflict about this partition type.
The partition in itself is NOT accessible through CHS addressing (the boundary for CHS addressing on a 16/63 geometry being 1024*16*63*512=528,482,304 bytes).
So first thing I would try would be to change the 0B at 0x01C2 in the MBR to
(FAT 32 LBA mapped) and see what happens.
The report of the grub4dos 0.4.4 you posted clearly shows how it is "confused":
Using grldr v0.4.4: drive 0x80 (LBA): C/H/S=1024/16/63 Sector Count/Size =1032192/512
you see, 1024*16*63 is actually 1032192, but 1032192*512 is the 528,482,304 bytes, whilst we know how your disk contains at least 63+7,831,089=7,831,152*512=4,009,549,824 bytes.
The MBR CODE is the grub4dos one, so you are expecting it to load directly the grldr and have it load menu.lst, right?
This is normally allright (but I personally find it not advised with "pesky" BIOSes), using a more "tested" MBR CODE (and having it "self contained" in the MBR and not - like the grub4dos one spread over the first few sectors) would be IMHO "better", at least initially.
So, right now you have just grldr and menu.lst inside the partition, right?
Try booting "as is" and report EXACTLY what happens.
Then try changing just the 0B to
, try booting and report EXACTLY what happens (if different form the previous).
Edited by jaclaz, 01 July 2012 - 06:31 AM.