Problem booting from CF on old PC

[jaclaz]

Thanks, got that done so I'll let you know how it goes

Stupid Win7 wouldn't let me run VDK though, even though I disabled Driver Signing AND signed vdk.sys with Driver Signature Enforcement Overrider (well I could install it but it wouldn't allow it to start) so I had to boot to my backup XP (even my Virtualbox XP wouldn't work for mkimg today!) which was a nuisance.

I don't think that there is any particular issue with VDK under Windows 7 (excapt usaul UAC and stoopid driver signing) , but MKIMG/MBRBATCH (the "standard version I wrote) won't work anyway because they use a little .COM executable (and support for .COM files have been removed, if I get that right).

You coud see if the "updated" version by Lancelot works (it should):

http://reboot.pro/5000/

http://reboot.pro/5000/#entry45422

jaclaz

[doveman]

Thanks, got that done so I'll let you know how it goes

Stupid Win7 wouldn't let me run VDK though, even though I disabled Driver Signing AND signed vdk.sys with Driver Signature Enforcement Overrider (well I could install it but it wouldn't allow it to start) so I had to boot to my backup XP (even my Virtualbox XP wouldn't work for mkimg today!) which was a nuisance.

I don't think that there is any particular issue with VDK under Windows 7 (excapt usaul UAC and stoopid driver signing) , but MKIMG/MBRBATCH (the "standard version I wrote) won't work anyway because they use a little .COM executable (and support for .COM files have been removed, if I get that right).

You coud see if the "updated" version by Lancelot works (it should):

http://reboot.pro/5000/

http://reboot.pro/5000/#entry45422

jaclaz

Thanks, I was actually trying Lancelot's version but ran into that problem with VDK, even though UAC was disabled as well as Driver Signing (and I tried signing it with DSEO which shouldn't have been necessary but was worth a try!).

I didn't get to go over today as the household is in quarantine with heavy colds but I was going to ask what I could try next, assuming that works. I'm fairly sure it will as it booted fine before, so the main thing I'll be checking for is whether the 16/63 geometry avoids windows locking up when copying files to the CF.

What would probably be good to try first is to leave the small CHS partition as is and format the remainder with a 16/63 geometry as well and then I can check that writing to that is OK too, so if you could advise what commands to use with mkimg/dfsi to do this, that'd be great. I imagine I can just create the secondary partition with mkimg and write that to the latter part of the CF with dsfi \\.\PHYSICALDRIVE0 x x test.img if I use the right numbers for x but I don't have a clue what they should be My thinstation build is about 100MB so that will fit in the small partition but my Portable-XP is 800-1000MB so I'll need to put that on the larger partition.

It might also be good to create an img for the entire CF in a 16/63 geometry and see if that works, so perhaps you could advise the right parameters to do that as well.

That will give me a few things to test when I get over there in the week, which will be more efficient than having to wait until I report back to ask how to do those things and then wait until I get over there again to test them and I'll be able to tell you if they all work or if only some of them do.

[jaclaz]

I didn't get to go over today as the household is in quarantine with heavy colds but I was going to ask what I could try next, assuming that works. I'm fairly sure it will as it booted fine before, so the main thing I'll be checking for is whether the 16/63 geometry avoids windows locking up when copying files to the CF.

What would probably be good to try first is to leave the small CHS partition as is and format the remainder with a 16/63 geometry as well and then I can check that writing to that is OK too, so if you could advise what commands to use with mkimg/dfsi to do this, that'd be great. I imagine I can just create the secondary partition with mkimg and write that to the latter part of the CF with dsfi \\.\PHYSICALDRIVE0 x x test.img if I use the right numbers for x but I don't have a clue what they should be My thinstation build is about 100MB so that will fit in the small partition but my Portable-XP is 800-1000MB so I'll need to put that on the larger partition.

It might also be good to create an img for the entire CF in a 16/63 geometry and see if that works, so perhaps you could advise the right parameters to do that as well.

That will give me a few things to test when I get over there in the week, which will be more efficient than having to wait until I report back to ask how to do those things and then wait until I get over there again to test them and I'll be able to tell you if they all work or if only some of them do.

Well, there shouldn't be any other issue.

I mean, the CHS geometry has relevance only for "booting", once this has happened (AFAIK) anything in a Windows XP or 7 is "LBA".

The idea of getting you familiar with my little spreadsheet was actually that of giving you a (valid ) tool to design yourself your experiments.

With it and a disk editor (I like and use Tiny Hexer) and possibly using my Structure viewer scripts:

http://reboot.pro/8734/

you have no actual need for MBRbatch/mkimg and you can carry your experiments directly on the CF card ...

jaclaz

[doveman]

Well, there shouldn't be any other issue.

I mean, the CHS geometry has relevance only for "booting", once this has happened (AFAIK) anything in a Windows XP or 7 is "LBA".

The idea of getting you familiar with my little spreadsheet was actually that of giving you a (valid ) tool to design yourself your experiments.

With it and a disk editor (I like and use Tiny Hexer) and possibly using my Structure viewer scripts:

http://reboot.pro/8734/

you have no actual need for MBRbatch/mkimg and you can carry your experiments directly on the CF card ...

jaclaz

I did have a look at your spreadsheet and it looks very clever but just makes my head spin I'm afraid

I'm sure it's easy to create partitions with Tiny Hexer once you know what you're doing but I don't so I'm probably better off sticking with mkimg

[jaclaz]

I did have a look at your spreadsheet and it looks very clever but just makes my head spin I'm afraid

Oww, comeon .

Get the spreadsheet.

Open the sheet PTtables.

Enter in cells F4:H4 the CHS geometry of your card:

Cylinders 16383

Heads 16

Sectors 63

Enter in cell D10 the partition ID (optional)

Enter in cell E10 the Active status (optional)

Enter in cells F10:H10 the Beginning of the partition in CHS (0/1/1)

Enter in cells I10:K10 the end of the partition in CHS (1022/15/63)

Enter in cells P16:Q16 the LBA start and end addresses (which you can read in cells P10:Q10

Enter in cells M22:N22 the Start sector ad the Num sectors (ehich you can read in cells M10:N10 or in cells M16:N16)

Now go to sheet PT_to_MBR and enter in the cells in row 30 the values you have tested and verified in sheet.

Now, compare the cells in the upper part of the sheet with a view of the MBR of your CF card.

I took the liberty to make the above, so please attach a file named CHS_LBA_v2_D_CF_16Gb_SFE.xls.

In case you wonder the naming convetntion is :

CHS_LBA_v2 <-name of the base file

D<- Doveman

CF_16Gb <. CF card 16 Gb

SFE <- Spoon Feed Edition

jaclaz

CHS_LBA_v2_D_CF_16Gb_SFE.zip

[doveman]

I took the liberty to make the above, so please attach a file named CHS_LBA_v2_D_CF_16Gb_SFE.xls.

In case you wonder the naming convetntion is :

CHS_LBA_v2 <-name of the base file

D<- Doveman

CF_16Gb <. CF card 16 Gb

SFE <- Spoon Feed Edition

jaclaz

Thanks, there's nothing wrong with a bit of spoon feeding from time to time. I'm far less likely to injure myself with a spoon than a fork anyway

Now that you've given an example of how to use it, it makes a lot more sense to me. I still get confused about when the heads and sects should be 0 or 1 but with a bit of trial and error I managed to get the numbers to all add up

So for the second parttition for the remaining space I ended up with:

Type		Boot		bCyl		bHead		bSect		eCyl		eHead		eSect			Start Sector		Num Sectors         Size in bytes
0C		00		1,024		0		1		16,382		15		63			1,032,192		15,481,872  	    7,926,718,464

and if I've understood correctly, I can paste the data from the PT to MBR tab to the CF, starting at offset 000001B0h? Actually I see I shouldn't paste the first 11 bytes and I'm not changing the first partition, so just the data for the 2nd Partition Table entry.

Edited July 29, 2012 by doveman

[jaclaz]

and if I've understood correctly, I can paste the data from the PT to MBR tab to the CF, starting at offset 000001B0h? Actually I see I shouldn't paste the first 11 bytes and I'm not changing the first partition, so just the data for the 2nd Partition Table entry.

Yes and no.

The partition table is made of 4 (four) entries, each 16 bytes long.

So if you do not want to change the first partition, you need to leave alone the first 16 bytes, I fail to understand the reference to 11

BUT, the PTtable is THEORETICAL ONLY in the CHS part, IF you exceed the CHS limit.

The max value that you can sencefully express in a MBR Cilynder entry is 1,023.

Since you are beyond the CHS limit:

0C/00/1,024/0/1/16,382/15/63//1,032,192/15,481,872

becomes (when you write to a MBR Patrtition Table entry:

0C/00/1,0241,023/0/1/16,3821,023/15/63//1,032,192/15,481,872

If you check the PT_Entry_#0 and PT_Entry_#1 sheets, you will easily understand WHY this happens .

Newer OS will write the above as:

0C/00/1,024/0/11,023/15/63/16,3821,023/15/63//1,032,192/15,481,872

Either should do.

In layman terms, you are writing values that mak the OS understand that the CHS addressing is m00t and that it has to use the LBA addresses only, should - for any reason - the partition ID be overlooked.

jaclaz

Edited July 30, 2012 by jaclaz

[doveman]

OK, I finally got to test and we're finally getting somewhere.

With the 500MB CHS partition and type 06, I just got the flashing cursor.

After changing it to type 0E it booted to boot.ini and from there loaded grldr fine

Then I booted into my Portable XP img (from the HDD) and tried to copy a file from my USB stick to the CF and Windows locked up completely, just like before when I hadn't formatted with a 16/63 geometry.

I then rebooted into Portable XP again, hid the HDD partitions (D & E) with Disk Management and installed the EWF Filter and rebooted, to eliminate problems with writing to either the HDD or the img (not that it should have been doing either) causing the lockup. It still locked up when I tried to copy from the USB to the CF.

I then rebooted into Thinstation (Linux) and was able to copy the files using that OK, so it seems it's just Windows that has a problem I did think this would be a problem, as at some point my brother will need to copy some files from his HDD to the CF but I guess I can just stick a small Linux distribution on the CF and he can boot into that to do the copying (unless of course you have any brilliant ideas on how to fix the problem but it's not really worth spending much time on).

Then I changed the CF MBR from NT5 to G4D and rebooted and it boots fine straight into G4D and I can boot my Thinstation ISOs or vmlinuz from there no problem

So now I want to try creating a second partition for the remaining space on the CF and try booting my Portable XP (as an IMG and as loose files) from that.

The partition table is made of 4 (four) entries, each 16 bytes long.

So if you do not want to change the first partition, you need to leave alone the first 16 bytes, I fail to understand the reference to 11

BUT, the PTtable is THEORETICAL ONLY in the CHS part, IF you exceed the CHS limit.

The max value that you can sencefully express in a MBR Cilynder entry is 1,023.

What I meant by 11 is the bytes before the first partition (it's actually 13). The figures I used in my last post for the second partition are bogus anyway, as it's a 16GB card not 8GB and I'd just calculated to fill the 8,455,200,768 set on the PTtables tab. So taking what you've said, using the PT to MBR tab I came up with:

0E		80		0		1		1		1,023		15		63			63	        1,032,129		528,450,048	Active	       BIGDOS
0C		00		1,023		0		1		1,023		15		63			1,032,192	30,195,648		15,460,171,776	Not Active     WIN9532Lba
00		00		0		0		0		0		0		0			0	        0			0     	        Not Active     unused
00		00		0		0		0		0		0		0			0	        0			0     	        Not Active     unused
																					        15,988,621,824	

which seems to add up (30,195,648 + 1,032,129 + 63 = 31227840) and which in Hex is

80 01 01 00 06 0F FF FF 3F 00 00 00 C1 BF 0F 00
00 00 C1 FF 0C 0F FF FF 00 C0 0F 00 C0 BF CC 01

so I just need to paste the second line to the appropriate sectors on the CF with TinyHexer

Edited August 9, 2012 by doveman

[jaclaz]

Which seems to add up (30,195,648 + 1,032,129 + 63 = 31227840) and which in Hex is

80 01 01 00 06 0F FF FF 3F 00 00 00 C1 BF 0F 00
00 00 C1 FF 0C 0F FF FF 00 C0 0F 00 C0 BF CC 01

so I just need to paste the second line to the appropriate sectors on the CF with TinyHexer

NO.

That is still CHS 06.

And a partition table entry is still 16 bytes, not 11, not 13 not any other value but 16, and they are not a "line", it is actually 2 bytes on one line (in the default view of a hex editor) +14 bytes on next one.

I doubt I could find a better way to represent it.

But stll you are not yet "completely out of the issues", it is "queer" that you needed the 0C partition ID, but it could well be a combination of the BIOS with that particular CF-card...

While you were playing with yours, I was fighting again a "particular" Linux distro that used GRUB 0.97 installed to MBR with an invalid partition scheme and no active partition.

That would have normally worked, but on a Thin client with the stupid Insyde Bios (that has a "special" provision to prevent GRUB from booting ) there was NO way to have it booted if not by using the NTLDR+BOOT.INI trick.

The queer thing was that once I had the CF card partitions modified, and worked perfectly on the specific machine, I tried that same CF card on another machine and it would have problems in BIOS recognizing the actual device. (and it wasn't the ususal no-name cheap one, it was a "respectable" Adata one.

Same contents dd-ed to another CF-card, this time a "Maxflash" brand, et voilà: BIOS of the other machine (a Via Epia) recognized it allright (and BTW on this other machine the "new" Cf-card worked allright even with the original image.

Sometimes it is just voodoo....

jaclaz

[doveman]

NO.

That is still CHS 06.

And a partition table entry is still 16 bytes, not 11, not 13 not any other value but 16, and they are not a "line", it is actually 2 bytes on one line (in the default view of a hex editor) +14 bytes on next one.

I doubt I could find a better way to represent it.

Yeah, my mistake, forgot to change the 06 to 0E in the spreadsheet before copy and pasting

I wasn't talking about a partition table entry when I said 11 (or 13) but about the number of bytes to be left untouched BEFORE the first partition entry. OK, it's not a "line" in the partition table but it was in my post (which is what I was referring to)

But stll you are not yet "completely out of the issues", it is "queer" that you needed the 0C partition ID, but it could well be a combination of the BIOS with that particular CF-card...

0E actually but yes, still rather "queer"

Thanks for the image. I was going by your previous post but that was for a smaller partition

While you were playing with yours, I was fighting again a "particular" Linux distro that used GRUB 0.97 installed to MBR with an invalid partition scheme and no active partition.

That would have normally worked, but on a Thin client with the stupid Insyde Bios (that has a "special" provision to prevent GRUB from booting ) there was NO way to have it booted if not by using the NTLDR+BOOT.INI trick.

At least it's not just me who has these stupid problems with CF cards then. Never mind, "we shall overcome"

[doveman]

Thanks jaclaz, I used your screenshot to create a second partition and that's working fine for the XP Portable images. Nice to be able to finally unplug the noisy old HDD.

I need to expand the img to loose files as for whatever reason, it's incredibly slow doing anything with the img running from CF (had the same problem when testing on my Gigabyte board, so it's nothing to do with the VL400). I think it must be write-related, as if I enable the EWF filter to block writing they work fine. Once all the drivers are installed my brother will be running them with the EWF filter enabled anyway, so I'll probably just get him to install the drivers and check everything's working with the img booted from his HDD and then I'll enable the EWF filter and copy the img to the CF for him.

[doveman]

Regarding the problem with XP locking up when copying files to the CF (I've been using Puppy Linux to do this now), it's peculiar as I can edit a file and save it and I defragged an 800MB IMG on the CF OK (had to use defraggler in XP for that as I couldn't find out how to defrag a file in Linux), which obviously both involve writing to the CF so I don't understand why copying files is a problem. I'm pretty sure I tried both in Portable XP (booted from the IMG as Filedisk) and a normal XP installation on the HDD but I'll have to double-check that but if it is both (which I think it is), it's obviously a general XP issue rather than something peculiar about Portable XP (which still contains all the essential parts of XP anyway).

I don't really know why copying the 800MB IMG to an almost empty 15GB partition (there was one other 700MB IMG on there) results in the file being fragmented anyway. There seems to be a somewhat dismissive attitude to defragging in the Puppy Linux forums, so maybe it's not considered an issue in Linux and so it doesn't bother to try and make the file contiguous when copying but it's necessary for booting with grub4dos so I have to take care of it somehow. It would be a lot easier if it copied the file contiguously in the first place, rather than having to boot to XP to defrag it though, particularly as it's rather slow, no doubt due to the relatively slow write speeds of the CF card.