126 replies to this topic

[doveman]

Actually 2002 was an excellent vintage for partition editors , and in any case NOTHING has been produced since 2000 or 2001 with a 16/63 geometry

Ah. I knew we had a good cucumber harvest that year but didn't realise it was a good year for partition editors too

Cannot say, but won't it be more logical to first test the image "as is" (i.e. with default 2K/XP MBR code and 2K/XP PBR code)?
If you do two things and the result is unsatisfying you will never be able to "trace" back to WHICH of the two things created the issue.

Indeed, I hadn't considered that. I'll just stick NTLDR and boot.ini on there then and see what happens. I won't be able to test it on the VL400 till at least Sunday, but I can check it's OK here I guess for now.

[doveman]

Well NTLDR >boot.ini >grldr >menu.list >Thinstation works fine here, which of course doesn't tell us anything about if it will work on the VL400, other than I haven't screwed it up completely and made an unbootable partition

[Wonko the Sane]

Well NTLDR >boot.ini >grldr >menu.list >Thinstation works fine here, which of course doesn't tell us anything about if it will work on the VL400, other than I haven't screwed it up completely and made an unbootable partition

Yes, that is a good start.
But a "good" BIOS won't consider the CHS part for a disk 4 Gb in size with a geometry of 16/63 anyway, as 1024*16*63*512=528,482,304
But we do have a confirmation that MBRBATCH/MKIMG worked as expected.
Since you are using FAT32 with an unpatched 2K/XP PBR bootsector, this could mean that everything is "kosher" but cannot say.
DO check the PBR and see if it has 16/63 data right now.
For the test on the VL400 be prepared (if needed) to patch the geometry check in the PBR, see:
http://reboot.pro/8528/
and links within.
There should be NO need for the patch, but you never know.



Wonko

[doveman]

I checked the PBR with BootICE and it shows "C/H/S: 7769/16/63. Total Sectors: 7831152. Sector Size: 512 Bytes" so that seems fine.

To patch the PBR I did (lazy way, not using commandline!):

1) BootICE - Backup PBR - 1 Sector, saved as CFPBR.BIN

2) Open CFPBR.BIN in TinyHexer and change data at offset 0xE6 from 0F824A00->90909090, save as moddedCFPBR.bin

So if I find it doesn't work straight away on the VL400, I can just use BootICE to Restore PBR from moddedCFPBR.bin, assuming that will only overwrite the 1 sector, as when using Backup PBR it defaulted to 3 sectors

[Wonko the Sane]

Well, tinyhexer can edit the sector DIRECTLY on disk allright
If you "adopt" my half-@ssed scripts for it, you may even need not a partition table editor...

Be careful when using *any* tool with something like "backup PBR" or "restore PBR" on a FAT32 partition.
The bootsector (the part that it is useful to edit/patch/whatever) is just first sector of the volume BUT the actual PBR on a FAT32 volume is 3 sectors long AND it has it's own "peculiarities".

• for DOS the boosector is first three sectors LBA 0,1,2
• for NT the bootsector is first 2 sectors LBA 0,1 + sector LBA 12
• for ReactOS (you know the good guys that since a few years completely fail to create a "clone" of a windows NT system) it's first 2 sectors LBA 0,1 + sector LBA 14

Some details in the links given here:
http://www.msfn.org/...t/page__st__100


Wonko

[doveman]

Well, tinyhexer can edit the sector DIRECTLY on disk allright

I did realise this but thought I'd create the modded PBR now so that if I need it it's ready to be written, rather than having to remember where I left my notes telling me what data to patch when I'm actually at the VL400 panicking

Be careful when using *any* tool with something like "backup PBR" or "restore PBR" on a FAT32 partition.
The bootsector (the part that it is useful to edit/patch/whatever) is just first sector of the volume BUT the actual PBR on a FAT32 volume is 3 sectors long AND it has it's own "peculiarities".

• for DOS the boosector is first three sectors LBA 0,1,2
• for NT the bootsector is first 2 sectors LBA 0,1 + sector LBA 12
• for ReactOS (you know the good guys that since a few years completely fail to create a "clone" of a windows NT system) it's first 2 sectors LBA 0,1 + sector LBA 14

I'd hope that BOOTICE would only write how ever many sectors are in the Backup, so 1 in my case, but as I don't really know I think I'll just revert to directly editing the sector with TinyHexer if need be, just in case it doesn't behave how I'd expect (or I could use dsfi to write my pre-modded PBR to ensure it only writes 512 bytes).

[tinybit]

Older BOOTICE had a bug failed copy BPB of the first FAT partition to the MBR, on installing grub4dos to MBR.

Use the latest one(released this month as May 2012).

I suggest you choose "copy BPB" or the similar option if you want to install grub4dos to MBR.

And try WEE as mentioned several days ago.

[doveman]

Older BOOTICE had a bug failed copy BPB of the first FAT partition to the MBR, on installing grub4dos to MBR.

Use the latest one(released this month as May 2012).

I suggest you choose "copy BPB" or the similar option if you want to install grub4dos to MBR.

And try WEE as mentioned several days ago.

Thanks for the warning. Have you got a link, I can only find 2011 versions?

I've got a second CF card (16GB) which I'm going to try RMPrepUSB/Wee with so that I don't mess up the 4GB one, which I'm strictly following Wonko's instructions with, well more or less

[tinybit]

In this Chinese page:

http://bbs.wuyou.com...a=page=1&page=1

Download link for BOOTICE_20120506.rar :

http://bbs.wuyou.com....php?aid=142362

[doveman]

Nice one, thanks

[doveman]

Just a bit of a progress report. Unfortunately I keep finding myself occupied sorting out other things (like getting Thinstation to work) on the PC whenever I get access and only end up testing the CF in the last few minutes before I'm thrown out so I don't have very good notes, but thought I'd let you know that I'm still testing and what I've found so far.

The 4GB CF boots to the WIndows boot menu on the VL400, but when I select grldr from there it is then unable to boot from hd0,0 (the error message was something like "FAT32 error" and it then checks other possible locations (including fd0 I think) and fails (I need to check whether I have the latest grldr on there and update to 0.4.6a if not though). If I leave the HDD connected, it finds and boots glrdr and menu.lst from there and I've double-checked the CF boots without any HDD on my Gigabyte system still, just in case the files had got corrupted or something. I haven't had a chance to test editing the PBR yet, which I will do unless you tell me that the fact that it boots to the Windows boot menu means that's unnecessary.

I also briefly tested a 16GB CF formatted with RMPrepUSB a couple of weeks ago and that booted grldr directly fine as I recall (I think I'd disconnected the HDD but I can't be sure). However, when booted into XP from the HDD I was copying some files to the CF and Windows locked up

It's a bit of a pain copying largish (XP-Portable.img 600-800MB) files to the CF anyway, as despite defragging beforehand and the majority of the card being continuous free space, it still fragments the file when copying it, meaning I have to then spend ages defragging it with defraggler or WinContig so that I can boot the img with grub4dos.

[Wonko the Sane]

The 4GB CF boots to the WIndows boot menu on the VL400

Good.

but when I select grldr from there it is then unable to boot from hd0,0 (the error message was something like "FAT32 error"

And AGAIN, once you have that machine handy you need to run a few grub4dos command on command line to verify how grub4dos "sees" the geometry and report.


Wonko

[doveman]

And AGAIN, once you have that machine handy you need to run a few grub4dos command on command line to verify how grub4dos "sees" the geometry and report.

Yep, thanks for the reminder. I'll put it at the top of my to-do list for when I'm next there, so I don't get distracted/forget

[doveman]

Right, finally got some decent info to report.

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

[doveman]

As a comparison, I checked 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, as before trying to copy files to the 16GB CF in XP 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).

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

[doveman]

If it's going to be too hard/impossible to get the 4GB CF working, perhaps we can try and sort out the problem with the 16GB CF, which boots but hangs the PC when copying to it (in Windows booted from the HDD)?

EDIT: 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 completely 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.

EDIT2: Hmm, looking back I note you advised me "Remember that you want to use the EXACT size the VL400 bios sees, i.e. 4,009,549,824 bytes or a smaller multiple of 16*63*512=516,096 bytes.". The size was 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 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. Even taking the reported "LBA Format 15989MB" gives 15989*1024*1024=16,765,681,664 but that's roughly 15.61 GB so I'm not sure if that would work either.

[doveman]

Anyone seen Wonko lately? Is he on holiday (well deserved no doubt)?

[wimb]

http://reboot.pro/16...508#entry155508

Wonko will return in September ...
But in the mean time you can find him at MSFN or 911cd forum ....

[doveman]

Thanks wimb. I'll try and locate him on the other forums, as I'd like to get this working before my brother's birthday on 5 September (although it's not that critical, I can still send him his main present and sort this out later, I'd at least like to work out what will be possible so that I can plan).

[0scar]

Wonko aka jaclaz.

[doveman]

Wonko aka jaclaz.

I think I should've known that but forgot so thanks, as I probably wouldn't have been able to track him down otherwise

[roytam1]

If it's going to be too hard/impossible to get the 4GB CF working, perhaps we can try and sort out the problem with the 16GB CF, which boots but hangs the PC when copying to it (in Windows booted from the HDD)?

EDIT: 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 completely 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.

EDIT2: Hmm, looking back I note you advised me "Remember that you want to use the EXACT size the VL400 bios sees, i.e. 4,009,549,824 bytes or a smaller multiple of 16*63*512=516,096 bytes.". The size was 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 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. Even taking the reported "LBA Format 15989MB" gives 15989*1024*1024=16,765,681,664 but that's roughly 15.61 GB so I'm not sure if that would work either.

You may always trying UltraISO USB-ZIP+ MBR and changing PBR to GRUB4DOS, and put latest GRUB4DOS 0.4.5c in it.

[tinybit]

Try (hd0,0): FAT32: disk error
........
Cannot find grldr

Even though it boots to grldr, as before trying to copy files to the 16GB CF in XP 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).

There is something wrong with the VL400 motherboard. Even Windows cannot operate on it smoothly in protected mode. Consider to upgrade the BIOS.

As for G4D and geometry, booting NTLDR from the CF, which loads boot.ini and selecting G4D from there, which loads grldr (0.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

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

Both showed (LBA). So there should be no problem for most of the boot loaders. Especially WEE should run without any problem.


EDIT: Since it "cannot find GRLDR" or "cannot find menu.lst", it might have its limit for accessing large sector numbers. So you may try to work around it by fdisking a small partition located near the very beginning of the CF card, and only access this small partition on the boot-loader stage.

EDIT 2: You can find out the limit by hand:

cat   --hex   (hd0)8000000+1

cat   --hex   (hd0)4000000+1

cat   --hex   (hd0)2000000+1

cat   --hex   (hd0)1000000+1

cat   --hex   (hd0)500000+1

cat   --hex   (hd0)200000+1

cat   --hex   (hd0)100000+1

cat   --hex   (hd0)50000+1

cat   --hex   (hd0)20000+1

cat   --hex   (hd0)10000+1

cat   --hex   (hd0)5000+1

cat   --hex   (hd0)2000+1

cat   --hex   (hd0)1000+1

cat   --hex   (hd0)500+1

cat   --hex   (hd0)200+1

cat   --hex   (hd0)100+1

cat   --hex   (hd0)50+1

cat   --hex   (hd0)20+1

cat   --hex   (hd0)10+1

In this way you can find out the maximum of N such that the "cat --hex (hd0)N+1" command succeeds. And this N shows the capability(i.e., the limit) of your BIOS.

Warning! Use the latest build of 0.4.5c for testing. Earlier versions cannot be reliably used for this testing.

[doveman]

You may always trying UltraISO USB-ZIP+ MBR and changing PBR to GRUB4DOS, and put latest GRUB4DOS 0.4.5c in it.

Thanks, I've got 0.4.6a on it now and I'll try booting that either via grub4dos MBR or NTLDR MBR again after changing the partition type from 0B (FAT32 CHS mapped) to 0E (FAT 32 LBA mapped).

[doveman]

There is something wrong with the VL400 motherboard. Even Windows cannot operate on it smoothly in protected mode. Consider to upgrade the BIOS.

Windows does operate OK when booted from HDD. It's just accessing the CF that seems to cause problems.

Both showed (LBA). So there should be no problem for most of the boot loaders. Especially WEE should run without any problem.

I haven't tried WEE yet and will give that a try if the other things I'm trying don't work. It's a bit wierd that 0.4.5c shows it as having 64/63 geometry, as it's definitely 16/63, but we'll see what 0.4.6a says!

EDIT: Since it "cannot find GRLDR" or "cannot find menu.lst", it might have its limit for accessing large sector numbers. So you may try to work around it by fdisking a small partition located near the very beginning of the CF card, and only access this small partition on the boot-loader stage.

Thanks, that's a good idea which I'll try if necessary.