[doveman]

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.

This post has been edited by doveman: 20 June 2012 - 11:18 AM

[doveman]

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

[jaclaz]

doveman
You are doing a lot of tests/changes (some needed, most unneeded ), and every time you introduce at least two changes, this way the probability of success (if any ) 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 .

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:

• the 4 Gb CF card
  
• the VL400
  
• the utilities/tools suggested (and NOT other ones)
  
• performing the tests suggested (and NOT other ones)

I left you on the reboot.pro thread:
http://reboot.pro/16737/
in a situation where:

• you had no access to the VL400
  
• 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?

The suggestion is to start again from scratch.

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

• What is your final goal? (like booting what OS from what media on what machine)
  
• How exactly does the VL400 see the chosen card geometry?
  
• How exactly the chosen version of grub4dos (please name it) on the VL400 see the chosen card (please specify which one you chose) geometry?
  
• 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

[doveman]

jaclaz, on 20 June 2012 - 12:18 PM, said:

[*]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):

• What is your final goal? (like booting what OS from what media on what machine)
  
• How exactly does the VL400 see the chosen card geometry?
  
• How exactly the chosen version of grub4dos (please name it) on the VL400 see the chosen card (please specify which one you chose) geometry?
  
• 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.

Attached File(s)

•  4GB CF Sectors.zip (1.07K)
  Number of downloads: 2

[jaclaz]

Try again .

The *whatever* MBR you posted is of a (badly ) 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

[doveman]

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.

Attached File(s)

•  4GB CF Sectors.zip (1.04K)
  Number of downloads: 3

[jaclaz]

doveman, on 21 June 2012 - 04:47 AM, said:

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

Quote

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

This post has been edited by jaclaz: 01 July 2012 - 06:31 AM

[doveman]

jaclaz, on 21 June 2012 - 08:43 AM, said:

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?

.........

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

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.

Quote

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

Quote

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!

[jaclaz]

doveman, on 21 June 2012 - 10:51 AM, said:

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.micro...kb/303013/en-us
and inadvertedly you decide to do some partition/disk operation (like an innocuous defrag or chkdsk) from it....
Or you decide to try a Windows 2000 wiithout SP3 integrated:
http://support.micro...kb/305098/en-us
What could happen?

doveman, on 21 June 2012 - 10:51 AM, said:

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.

doveman, on 21 June 2012 - 10:51 AM, said:

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

[doveman]

jaclaz, on 21 June 2012 - 12:02 PM, said:

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.micro...kb/303013/en-us
and inadvertedly you decide to do some partition/disk operation (like an innocuous defrag or chkdsk) from it....
Or you decide to try a Windows 2000 wiithout SP3 integrated:
http://support.micro...kb/305098/en-us
What could happen?

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

[jaclaz]

doveman, on 22 June 2012 - 07:34 AM, said:

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 (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 :
http://reboot.pro/9897/

jaclaz

[doveman]

jaclaz, on 22 June 2012 - 08:14 AM, said:

...and just in order to make you worry a bit (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 :
http://reboot.pro/9897/

jaclaz

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

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

[jaclaz]

doveman, on 22 June 2012 - 08:39 AM, said:

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 :, "doing nothing" is an excellent way to keep out of troubles, but actually the "preferred" way (IMNSHO) is:

• 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
  
• partition using the "most compatible" partitioning tool
  
• leave partitions/volumes alone: do not move/resize/change active status <- i.e. do nothing after having done "the right thing"
  
• 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

[doveman]

jaclaz, on 21 June 2012 - 08:43 AM, said:

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

[jaclaz]

doveman, on 01 July 2012 - 05:32 AM, said:

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 , I meant 0C, you cannot have 06 or 0E, unless you make smaller partitions.

jaclaz

[doveman]

jaclaz, on 01 July 2012 - 06:29 AM, said:

doveman, on 01 July 2012 - 05:32 AM, said:

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 , I meant 0C, you cannot have 06 or 0E, unless you make smaller partitions.

jaclaz

No worries, thanks for the quick reply. I'll get a chance to try that later hopefully

[doveman]

OK, sorry for the delay, only just got a chance to try it.

With the CF only connected and the g4d MBR and type 0C I get the same as before:

Try (hd0,0): FAT32: disk error
(hd0,1) -> (hd0,3): invalid or null
BIOS: Drive=0x0, H=0, S=0
Try (fd0): invalid or null
Cannot find grldr

Then when I press a key to boot the previous MBR, the XP boot menu appears, but is hung showing:
I/O error accessing boot sector file multi(0)disk(0)rdisk(0)partition(1)\Bootsect.dos

That file is on the CF but I don't know why it's looking for it anyway, as the XP boot menu defaults to grldr.

With the HDD connected it loads g4d (0.4.5c) from that and geometry (hd0) shows:
drive 0x80(LBA): C/H/S=1943/64/63 Sector Count/Size = 7834176/512, Fat, type 0C

I then changed the MBR to NT 5.x with BootICE and booting the CF after that it loads the XP Boot Menu but as before, when selecting the grldr entry it shows:
I/O error accessing boot sector file multi(0)disk(0)rdisk(0)partition(1)\Bootsect.dos

which as I say I don't understand why it's trying to load that. Selecting the XP entry gives an error about a missing file (hal I think) which isn't surprising as there isn't an actual XP installation on the CF.

[jaclaz]

You do understand that you never posted the contents of the BOOT.INI?

Now, be nice, please FORGET whatever you have done and let's start again from fresh, OK?

Remove the grub4dos MBR+hidden sectors, replacing it with the "standard" 2K/XP MBR.
Make sure that the FAT32 filesystem has the standard 2K/XP bootsector invoking NTLDR.
Copy to the filesystem only NTLDR, BOOT.INI and grldr.
Make sure that the BOOT.INI contents are as follows:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
C:\grldr="Grub4Dos"

In other words, you want to have this way to load grub4dos (and NOT any other way):
http://diddy.boot-la...ws.htm#windows1

In a "perfect" world, you would use the MBRbatch command to create a proper disk image and then dd it to the card.

Once you are ready, INDPENDENTLY from whether it is booting to the BOOT.INI choices or not, extract the MBR and bootsector eith hdhacker and post them, together with a description of what exactly happens when you try to boot.

jaclaz

[doveman]

Well I did use the standard XP MBR for the last test and it also had the XP bootsector. NTLDR, grldr and boot.ini were on there and the boot.ini contents were:

[boot loader]
Timeout=5
Default=c:\grldr
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Image" /noexecute=optin /fastdetect
c:\grldr="Grub4DOS"

and I did make a disk image with the proper geometry and transfer it to the card a while ago if you recall. You've already checked the MBR and bootsector in post #6 and the only thing that I've changed is the partition type to 0C.

[jaclaz]

doveman, on 14 July 2012 - 06:55 AM, said:

Well I did use the standard XP MBR for the last test and it also had the XP bootsector. NTLDR, grldr and boot.ini were on there and the boot.ini contents were:

It is already difficult enough to try following you mixing two CF cards on two different systems, with a report once a week or so, at each test you seem like changing two things together (or doing more than one test per report, or report something else from what I need, I am really confused, see previous post #3)

This makes NO sense (or it is completely irrelevant):

Quote

With the HDD connected it loads g4d (0.4.5c) from that and geometry (hd0) shows:
drive 0x80(LBA): C/H/S=1943/64/63 Sector Count/Size = 7834176/512, Fat, type 0C

When compared with:

doveman, on 20 June 2012 - 03:18 PM, said:

Quote

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

Quote

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

Again, you are "mixing" things and/or posting confusing info.
If you start again from scratch, maybe it will be possible to do (hopefully) some step forward.

You were almost there here:
http://reboot.pro/16..._50#entry155690
before you started doing all changes and variations you could think of (and one more) .

General suggestions:

• You should NOT EVEN THINK of using grub4dos 0.4.6a, that is a test version.
  
• You should use ONLY 0.4.4 - 2009-10-16 (and NOT any other 0.4.4 version) unless told to use another version.
  
• You should NOT install the grub4dos MBR.
  
• You should try, WITHOUT making ANY modifications, of ANY kind unless told so, with a "plain" XP MBR, an XP bootsector, NTLDR, BOOT.INI and grldr
  
• Read the generic advice given in FAQ#10 here:
  http://jaclaz.alterv...SB/USBfaqs.html

Now, it is almost clear that - for *any* reason - that that particular BIOS/CF card combo:

• sees the 4 Gb card as having a geometry of 16/63
  
• does not "like" LBA mapped partitions AND/OR it doesn't "like" partitions bigger than 512 Mb (1024*16*63*512=528482304)

So the next step would be to create a smaller partition, with a 16/63 geometry, FAT 16 CHS formatted, with the standard XP MBR and bootsector, NTLDR, BOOT.INI and grldr (0.4.4 - 2009-10-16).
With mkimg:

Quote

C:\Testimages\>mkimg
Please enter target file name: 264Mb.img
Image size, in bytes or suffixed by K, M or G for Kilo Mega or Giga
Please enter target image size: 264273408
Please type desired geometry [255/63 128/63 64/63 16/63 64/32]: 16/63
Available partition types for this image, 264273408 bytes:
06 FAT 16 CHS Mapped
07 NTFS
0B FAT 32 CHS Mapped
0C FAT 32 LBA Mapped
0E FAT 16 LBA Mapped
Please type desired Partition Type [06 07 0B 0C 0E]: 06
Please type /fsz to use fsz.exe or [ENTER] to use mksparse.exe:

Creating a MBR from C:\WINDOWS\System32\dmadmin.exe with dsfo.exe:
OK, 512 bytes, 0.000s, MD5 = 61a174a7d3cbe41d9996de0f124b7ebf

Image will be mounted as 06h:FAT16

Can you simply do EXACTLY the above, transfer the image to the CF card and report?
Please verify that once the image has been transferred to the CF card and the VL400 has been booted at least once with the card connected the MBR signature is non-zero.
To do so, use MBRFIX (and NOT any other tool):
http://www.sysint.no...ting/mbrfix.htm

MbrFix /drive <num> readsignature

If it is 00000000 change it with:

MbrFix /drive <num> writesignature 01020304

A meaningful (to me) report follows this scheme (let's number them so it will be easier):

• Machine used: the VL400
  
• CF card used: the 4Gb one
  
• Partitioning scheme used: the one made with mkimg 264273408-16/63-06
  
• Files in the device: NTLDR; BOOT.INI with contents as per post #18, glrldr from grub4dos 0.4.4 - 2009-10-16
  
• Description of what happens when booting (if not any of the following)
  
• Description of what happens when booting when choosing the "Windows XP" entry (if it gets to the BOOT.INI choices)
  
• Description of what happens when booting when choosing the "grub4dos" entry (if it gets to the BOOT.INI choices)
  
• Result of grub4dos commands (if it gets to the grub> command prompt) for these commands:
  
  • root
    
  • geometry (hd0)
    
  • geometry (hd1)

Once you have posted this info, you are kindly requested to NOT do any change to anything until I suggest you WHICH changes to try.

I know that I sound like an old, grumpy bastard, mainly because I am an old, grumpy bastard , but also because this thingy is getting on my nerves, it should have taken NO time to find a solution or a workaround for your issue, but it is going on for what? 3 MONTHS?
Maybe this way we can get rid of it quickly .

jaclaz

This post has been edited by jaclaz: 14 July 2012 - 10:27 AM