Jump to content

Problem booting from CF on old PC


Recommended Posts

jaclaz has been helping me with this problem previously elsewhere, so I'm posting this information mainly in the hope he can continue to help me here, but if anyone else can help please feel free to jump in :)

The problem I'm having is trying to boot (grub4dos) from a 4GB CF on an old HP Vectra VL400.

Firstly, checking in the BIOS shows the HDD as Primary Master and the 4GB CF as Secondary Master - IDE Removable, but under the Boot submenu it shows the CF under both HDDs and Removable Devices.

The BIOS reports the following for the HDD

Cylinders 16383

Heads 16

Sectors 63

CHS Format 8455MB

LBA Format 20404MB

Multi-Sector Transfers 16 Sectors

LBA Mode Enabled

32 bit I/O Enabled

Transfer Mode FPIO 4 / DMA 2

Ultra DMA Mode Mode 4

and for the CF:

Cylinders 7769

Heads 16

Sectors 63

CHS Format 4010MB

LBA Format 4010MB

Multi-Sector Transfers Disabled

LBA Mode Disabled

32 Bit I/O Enabled

Transfer Mode FPIO 4 / DMA 2

Ultra DMA Mode Mode 2

As for G4D and geometry, booting NTLDR from the CF, which loads boot.ini and selecting G4D from there, which loads grldr (v0.4.4) and menu.lst from the HDD (as it can't see them on the CF), "geometry (hd0)" gives

drive 0x80 (LBA): C/H/S=1024/16/63 Sector Count/Size =1032192/512

and for the HDD (hd1)

drive 0x81 (LBA): C/H/S=1024/255/63 (I note this shows 255/63 whereas the BIOS shows 16/63, which probably isn't important as it boots).

I noticed the grldr on the CF was from 2011, so updated it to the latest April 2012 one I had on my USB and now when selecting G4D from the boot.ini menu (whether with the HDD connected or disconnected) I get the following error:

"I/O error accessing boot sector file multi(0)disk(0)rdisk(0)partition(1)\BOOTSECT.DOS"

which doesn't make much sense to me as it should be looking for grldr, not BOOTSECT.DOS.

I then updated the grldr on the HDD to 0.4.5c (17-01-2012) and after booting directly from the HDD, "geometry (hd1)" returns

drive 0x81(LBA): C/H/S=1943/64/63 Sector Count/Size=7834176/512

which is very different from the result with grldr 0.4.4, booted via NTLDR/boot.ini on the CF.

I also tried changing the data at offset 0xE6 on the 4GB CF to 90909090 but that just caused it to show "Disk error, press any key to restart" when booting. Changed it back again and it booted to NTLDR/boot.ini again.

Also tried installing G4D MBR with BOOTICE and updating grldr to 0.4.5b (17-01-2012) and one dated 25-04-2012, both of which gave (without HDD connected):

hd0,0: FAT32 disk error

hd0,1 - hd0,3: Invalid or null

BIOS: Drive=0x0,H=0,S=0

(fd0): invalid or null

Cannot find grldr

I'll make another post with the results from my 16GB CF to avoid this one getting too long.

Edited by doveman
Link to comment
Share on other sites


This is what I found with the 16GB CF (formatted with RMPrepUSB).

In the BIOS it shows as Secondary Master 15989MB (not IDE Removable as the 4GB CF does)

Cylinders 16383

Heads 16

Sectors 63

CHS Format 8455MB

LBA Format 15989MB

Multi-Sector Transfers Disabled

LBA Mode Enabled

32 Bit I/O Enabled

Transfer Mode FPIO 4 / DMA 2

Ultra DMA Mode Mode 2

This boots directly to grub4dos 0.4.5b (27-03-2011) and geometry (hd0) shows:

drive 0x80 (LBA): C/H/S=1024/255/63, sector count/size=31227840/512. Partion num:0, active, FAT, partition type 0x0C (compared to 0x0B for the HDD and 4GB CF).

Even though it boots to grldr, trying to copy files to the 16GB CF in XP (booted from the HDD) results in Windows totally locking up, mouse and all (this is on the VL400, on my Gigabyte system I've been able to copy files to it no problem, using Windows 7 anyway).

Looking at the 16GB CF on my Gigabyte PC with BootICE it shows:

C/H/S: 1943/255/63 Total Sectors: 31227840; Sector Size: 512 Bytes

which is different to what is shown on the VL400, either in the BIOS or from grub4dos. Maybe I should try formatting it to a 16/63 layout as I did for the 4GB card and see if that fixes the problem of it hanging when writing to it?

I'm not sure what values I should use with mkimg for this though. For the CF I used the exact size the VL400 bios sees, i.e. 4,009,549,824 bytes, which is calculated by C*H*S*512, which was fine for the 4GB which reported 4010MB both for CHS and LBA, but in the case of the 16GB CF (using the BIOS figures) gives 16383*16*63*512=8,455,200,768 which is around 8GB, not 16GB, so wouldn't this result in only 8GB being visible/usable?

Using the BootICE figures gives 1943*255*63*512=15,981,719,040 (15247.36MB) which is more like it (roughly the 14.89 GB that Windows sees), so I could do "mkimg test.img 15981719040 16/63 0C" but that's not the size the VL400 BIOS sees as calculated by C*H*S or even the "LBA Format 15989MB".

Link to comment
Share on other sites

doveman :)

You are doing a lot of tests/changes (some needed, most unneeded :w00t: ), and every time you introduce at least two changes, this way the probability of success (if any :ph34r:) are REDUCED greatly.

Usually the issue with attempting to help other peeps on the Forum is that they completely fail to provide the barely needed info, in your case it is the opposite, you are posting far more info than needed and thus you are counterproductively "polluting" the reports.

Right now I am overwhelmed by lots of info 75% (say) of which are UNNeeded :wacko: .

Your issue is with the BIOS of the VL400 and with that CF card.

There is NO NEED to do tests on the Gigabyte PC.

There is NO NEED to test another CF card.

There is NO NEED to know how *any* other BIOS sees the hard disk.

IF your problem is booting the 4 Gb CF card on the VL400, what you need is just:

  1. the 4 Gb CF card
  2. the VL400
  3. the utilities/tools suggested (and NOT other ones)
  4. performing the tests suggested (and NOT other ones)

I left you on the reboot.pro thread:

http://reboot.pro/16737/

in a situation where:

  1. you had no access to the VL400
  2. you went "astray" doing all kind of tests on other hardware, mixing versions of grub4dos, introducing RMPREPUSB and Bootice, mixing files and versions and what not

Has this changed? :unsure:

The suggestion is to start again from scratch.

  1. Choose one version of grub4dos (and only one).
  2. Choose ONLY the 4 Gb card (or the 16 Gb card).
  3. Choose ONLY the VL400.
  4. Forget ANY other tool if not explicitly suggested.

Please provide this info (and nothing else):

  1. What is your final goal? (like booting what OS from what media on what machine)
  2. How exactly does the VL400 see the chosen card geometry?
  3. How exactly the chosen version of grub4dos (please name it) on the VL400 see the chosen card (please specify which one you chose) geometry?
  4. How exactly the chosen card is currently partitioned/formatted? (under which OS with which settings, etc.)

Since I don't trust you (much ;)) on #4 above, please get HDhacker:

http://dimio.altervista.org/eng/

and use it to make a backup of the MBR (first sector of the PhysicalDrive) and of the PBR (first sector of the logical device), then zip the two resulting files togegther and attach the archive to your next post.

jaclaz

Link to comment
Share on other sites

[*]Choose one version of grub4dos (and only one).

[*]Choose ONLY the 4 Gb card (or the 16 Gb card).

[*]Choose ONLY the VL400.

[*]Forget ANY other tool if not explicitly suggested.

Please provide this info (and nothing else):

  1. What is your final goal? (like booting what OS from what media on what machine)
  2. How exactly does the VL400 see the chosen card geometry?
  3. How exactly the chosen version of grub4dos (please name it) on the VL400 see the chosen card (please specify which one you chose) geometry?
  4. How exactly the chosen card is currently partitioned/formatted? (under which OS with which settings, etc.)

Since I don't trust you (much ;)) on #4 above, please get HDhacker:

http://dimio.altervista.org/eng/

and use it to make a backup of the MBR (first sector of the PhysicalDrive) and of the PBR (first sector of the logical device), then zip the two resulting files togegther and attach the archive to your next post.

jaclaz

Fair enough. I've only been doing tests on the Gigabyte system to check that a) there's nothing wrong with the hardware and b) that what I'm trying to achieve actually works on a decent system (and also because I don't have access to the VL400 very often), but I'll refrain from now on to avoid overloading you with information.

So to answer your questions:

[*]What is your final goal? (like booting what OS from what media on what machine)

I want to boot grub4dos and from there choose either Thinstation (which I boot as an ISO at the moment, but eventually I'll boot as vmlinuz/initrd to use it's "fastboot" feature") or XP-Portable. I've encountered some problems booting this from the CF as an IMG with the winvblock driver (XP is very unresponsive/hangs), so I'll probably end up just extracting the files from the IMG to the CF and boot it normally using chainloader +1, which seems to work OK.

I actually want to do this on two machines, using the 4GB CF on one and the 16GB on the other, but they're both HP VL400s. Let's concentrate on the 4GB for now anyway.

*]How exactly does the VL400 see the chosen card geometry?

The BIOS shows the 4GB CF as Secondary Master - IDE Removable, but under the Boot submenu it shows the CF under both HDDs and Removable Devices.

Cylinders 7769

Heads 16

Sectors 63

CHS Format 4010MB

LBA Format 4010MB

Multi-Sector Transfers Disabled

LBA Mode Disabled

32 Bit I/O Enabled

Transfer Mode FPIO 4 / DMA 2

Ultra DMA Mode Mode 2

[*]How exactly the chosen version of grub4dos (please name it) on the VL400 see the chosen card (please specify which one you chose) geometry?

Using grldr v0.4.4: drive 0x80 (LBA): C/H/S=1024/16/63 Sector Count/Size =1032192/512

However, currently I have updated to 0.4.6a so I need to check how that reports the geometry on the VL400.

I'm not actually sure which version of the grub4dos MBR I have on there though (I would have installed it with the latest version of BOOTICE I have, which is 06-05-2012), nor how to update it (i've used grubinstgui in the past but unfortunately that doesn't seem to be available for recent versions and it seems to have the MBR hardcoded in the program, rather than being able to install a MBR file contained in the same directory, which would be handy). Perhaps you can suggest which MBR version I should install and a good way to do so (preferably from Windows)?

[*]How exactly the chosen card is currently partitioned/formatted? (under which OS with which settings, etc.)

After writing the img to it with mkimg, I believe I had to format it which I think I did in my XP Virtualbox. It currently has a single FAT32 partition anyway. I've attached a zip of the requested sectors.

4GB CF Sectors.zip

Link to comment
Share on other sites

Try again :whistle: .

The *whatever* MBR you posted is of a (badly :ph34r: ) multipartitioned 1 TB hard disk, with a first NTFS "hidden partition":


Entry Type Boot  bCyl  bHead bSect  eCyl  eHead eSec  StartSector   NumSectors 
#0 17 0 0 1 1 1023 254 63 63 40965687
#1 7 0 1023 0 1 1023 254 63 40965750 30716280
#2 7 80 1023 254 63 1023 254 63 71682030 40965750
#3 5 0 1023 0 1 1023 254 63 120840930 1832679135

two additional NTFS primary partition and a (huge) Extended partition.

The bootsector *seems* like it.

jaclaz

Link to comment
Share on other sites

Woops, sorry. Forgot to set the Physical Drive (MBR) in HDDHacker to Drive 2 (I guess I thought it would grab the MBR of the drive for which I'd just grabbed the Bootsector).

This should be correct.

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.

4GB CF Sectors.zip

Link to comment
Share on other sites

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? :w00t:

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):

2*12/2,178,815,688/100=24/217,881,568.8=1,1015158433171700203032501756064e-7

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 :rolleyes: ) 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 :ph34r: .

Back to topic.

Both the MBR partiition table and the bootsectors look "ok" for a 16/63 geometry :thumbup .

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 0E 0C (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 0E 0C, try booting and report EXACTLY what happens (if different form the previous).

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

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? :w00t:

.........

If you prefer, there are NO real issues :), BUT there are the "seeds" for a possible future disaster :ph34r: .

Thanks for explaining all that. I'll study it, worry a bit and then probably do nothing about it as I'm too busy and everything's working at the moment anyway ;)

I'm not sure why one partition is using the "new" convention and the rest the "old". I might change that since it should be quite easy and I don't really need a triple boot anyway, so can just boot Win7 from P2 if I mess up P3.

I boot Windows 7 (mostly) and XP (sometimes) on this system and haven't had any problems with "P5" due to it crossing the 128 Gb LBA28 boundary.

What's defrag or CHKDKS? Only kidding, but I don't use them much (I use defraggler sometimes, but mainly for defragging individual files to make them contiguous for grub4dos) and chkdsk only tends to run when the "dirty" flag has been set for some reason, when it tends to have been set for all partitions so having the space divided into smaller partitions wouldn't make chkdsk any quicker.

On my other system I do have a separate, 292GB, partition for games (followed by a 1.3TB data partition and two Primary partitions at the start for dual-boot) but I'm always running out of space and having to decide what to delete to install a new game I want to try, so really it's a pain having the space divided although there is the advantage of it being quicker to defrag. What I sometimes try to do is install the games first on a blank data partition, as then they'll be at the start of the drive and unfragmented and this won't change even if the rest of the drive is fragmented. Another idea I've used is to move all the files to another drive before copying back the most important games first, which can often be quicker than defragging the drive.

Back to topic.

Both the MBR partiition table and the bootsectors look "ok" for a 16/63 geometry :thumbup .

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 0E (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 0E, try booting and report EXACTLY what happens (if different form the previous).

OK, I'll hopefully get a chance to try that this weekend and I'll report back after that. I can already tell you what happens when booting as is with 0.4.6a grldr though (with only the CF connected):

hd0,0: FAT32 disk error

hd0,1 - hd0,3: Invalid or null

BIOS: Drive=0x0,H=0,S=0

(fd0): invalid or null

Cannot find grldr

I was led to understand that the g4d MBR I have on there might be buggy and need updating though. Can you tell from the MBR I uploaded what version is currently on there?

I did have the NTLDR MBR on there, which booted to boot.ini but then had problems loading grldr from there, which led me to install the g4d MBR as something to test whilst I had access to the VL400. Depending on what happens, I can always try putting the NTLDR MBR back on and test that again. The ntldr, ntdetect.com and boot.ini files are still on there.

As you say, grub4dos is "confused" as 0.4.4 gave: drive 0x80 (LBA): C/H/S=1024/16/63 Sector Count/Size =1032192/512

whilst 0.4.5c gave: drive 0x81(LBA): C/H/S=1943/64/63 Sector Count/Size=7834176/512 (I'd booted from the HDD for this, which is why the CF was 0x81)

so we'll see what the current 0.4.6a gives, before and after changing the partition type!

Link to comment
Share on other sites

I boot Windows 7 (mostly) and XP (sometimes) on this system and haven't had any problems with "P5" due to it crossing the 128 Gb LBA28 boundary.

Good. :)

And mind you, NOT to be the bearer of bad news, as it is a remote possibility, but let's say - only an example - that you (or your younger brother, etc.) find an old PE CD made out of XP before SP1:

http://support.microsoft.com/kb/303013/en-us

and inadvertedly you decide to do some partition/disk operation (like an innocuous defrag or chkdsk) from it.... :ph34r:

Or you decide to try a Windows 2000 wiithout SP3 integrated:

http://support.microsoft.com/kb/305098/en-us

What could happen? :unsure:

OK, I'll hopefully get a chance to try that this weekend and I'll report back after that. I can already tell you what happens when booting as is with 0.4.6a grldr though (with only the CF connected):

hd0,0: FAT32 disk error

hd0,1 - hd0,3: Invalid or null

BIOS: Drive=0x0,H=0,S=0

(fd0): invalid or null

Cannot find grldr

I was led to understand that the g4d MBR I have on there might be buggy and need updating though. Can you tell from the MBR I uploaded what version is currently on there?

No, there are several versions of it, and some only differ in "the other" sectors of it.

I did have the NTLDR MBR on there, which booted to boot.ini but then had problems loading grldr from there, which led me to install the g4d MBR as something to test whilst I had access to the VL400. Depending on what happens, I can always try putting the NTLDR MBR back on and test that again. The ntldr, ntdetect.com and boot.ini files are still on there.

Yep, a 2K/XP MBR (and FAT32 PBR) should have no problem in getting to NTLDR/NTDETECT.COM/BOOT.INI with the Partition Type set to 0B (as long as geometry in the PBP is correct, which in your case is).

Reason being (JFYI) connected to this:

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/determining-filesystem-type.html

what a BIOS or a (oldish) version of grub4dos may do is another thing.

Let's first see what happens "as is" and with the 0B set to 0E.

jaclaz

Link to comment
Share on other sites

Good. :)

And mind you, NOT to be the bearer of bad news, as it is a remote possibility, but let's say - only an example - that you (or your younger brother, etc.) find an old PE CD made out of XP before SP1:

http://support.microsoft.com/kb/303013/en-us

and inadvertedly you decide to do some partition/disk operation (like an innocuous defrag or chkdsk) from it.... :ph34r:

Or you decide to try a Windows 2000 wiithout SP3 integrated:

http://support.microsoft.com/kb/305098/en-us

What could happen? :unsure:

Thanks, that's good information to know. Luckily no-one else has access to my PCs and I'm not likely to install a pre-SP3 XP or Windows 2000, but I'll be careful to avoid using any old PE CDs ;)

Link to comment
Share on other sites

Thanks, that's good information to know. Luckily no-one else has access to my PCs and I'm not likely to install a pre-SP3 XP or Windows 2000, but I'll be careful to avoid using any old PE CDs ;)

...and just in order to make you worry a bit :w00t: (before doing nothing ;)), remember that if you create/move/resize partitions from Windows 7 and later you try to change the active status of a primary one through XP disk management, you are likely to fall into this nicely set trap :ph34r: :

http://reboot.pro/9897/

jaclaz

Link to comment
Share on other sites

...and just in order to make you worry a bit :w00t: (before doing nothing ;)), remember that if you create/move/resize partitions from Windows 7 and later you try to change the active status of a primary one through XP disk management, you are likely to fall into this nicely set trap :ph34r: :

http://reboot.pro/9897/

jaclaz

Wow, even grub4dos can change the active status of a primary partition without screwing things up :rolleyes:

I vaguely recall something about not using XP disk management (or even any tools under XP) after creating large partitions in Windows 7, so I'll be avoiding that anyway.

Maybe it would be easier to compile a how-to detailing the only SAFE ways to manage disks/partitions, as there's so many pitfalls it would probably be shorter. It seems my approach of doing nothing is probably the safest one, as I can't mess anything up if I don't try anything ;)

Link to comment
Share on other sites

Maybe it would be easier to compile a how-to detailing the only SAFE ways to manage disks/partitions, as there's so many pitfalls it would probably be shorter. It seems my approach of doing nothing is probably the safest one, as I can't mess anything up if I don't try anything ;)

Yep :thumbup:, "doing nothing" is an excellent way to keep out of troubles, but actually the "preferred" way (IMNSHO) is:

  1. plan accurately a partitioning scheme, in such a way that it is "the most compatible" or "the most suited" for the intended use of the disk
  2. partition using the "most compatible" partitioning tool
  3. leave partitions/volumes alone: do not move/resize/change active status <- i.e. do nothing after having done "the right thing" ;)
  4. if any modification is needed, think a lot about it, then use a suitable tool AND verify it's results carefully, and ONLY attempt the modifications after a complete, full, verified backup (that you should have anyway)

jaclaz

Link to comment
Share on other sites

  • 2 weeks later...
Back to topic.

Both the MBR partiition table and the bootsectors look "ok" for a 16/63 geometry :thumbup .

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 0E (FAT 32 LBA mapped) and see what happens.

Hmm, I was just looking at BootICE and according to that 0E is FAT16 LBA and 0C is FAT32 LBA so I'm not sure which you meant me to try, but as it's currently FAT32 (0B) I guess it makes sense to try FAT32 LBA (0C) first and after that I'll try FAT16 LBA (0E).

Link to comment
Share on other sites

Hmm, I was just looking at BootICE and according to that 0E is FAT16 LBA and 0C is FAT32 LBA so I'm not sure which you meant me to try, but as it's currently FAT32 (0B) I guess it makes sense to try FAT32 LBA (0C) first and after that I'll try FAT16 LBA (0E).

Yep, sorry :( , typo :blushing: , I meant 0C, you cannot have 06 or 0E, unless you make smaller partitions.

jaclaz

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...