Problem booting grub4dos from CF on old PC

I've got a 4GB CF Card in a CF-IDE adapter and it boots to grub4dos fine on my fairly recent Gigabyte MA780G-UD3H and boots XP, VHDs, etc fine from grub4dos.

When I tried it on an old HP Vectra VL400 the other day it didn't work so well though. I didn't get a chance to try and boot the CF card directly andI only tried booting grub4dos from the HDD and from there trying to boot the CF card and/or trying to load the menu.lst from the CF card, which works on my Gigabyte motherboard but didn't on the VL400. Once XP has booted, the CF can be accessed no problem.

I did think perhaps PLOP will allow it to boot, but that means I'd have to keep the HDD connected just to run PLOP, which kinda defeats the purpose of using the CF card (no noise, low power), so I'm wondering if there's some other tweak that might let me boot it directly (i.e. formatting it in a special way, it's currently FAT32)?

I've got a 4GB CF Card in a CF-IDE adapter and it boots to grub4dos fine on my fairly recent Gigabyte MA780G-UD3H and boots XP, VHDs, etc fine from grub4dos.

When I tried it on an old HP Vectra VL400 the other day it didn't work so well though. I didn't get a chance to try and boot the CF card directly andI only tried booting grub4dos from the HDD and from there trying to boot the CF card and/or trying to load the menu.lst from the CF card, which works on my Gigabyte motherboard but didn't on the VL400. Once XP has booted, the CF can be accessed no problem.

I did think perhaps PLOP will allow it to boot, but that means I'd have to keep the HDD connected just to run PLOP, which kinda defeats the purpose of using the CF card (no noise, low power), so I'm wondering if there's some other tweak that might let me boot it directly (i.e. formatting it in a special way, it's currently FAT32)?

Give some details.
"doesn't boot " is NOT a description of what happens.
As a general rule when exeriementing always try the hardware with a "standard" MBR and bootsector, like the 2K/XP one.
If the grub4dos on hard disk cannot find the card (provided that you tried to access it properly, something that again you fail to describe - the EXACT commands you gave to grub4dos) it means that that BIOS does not see it.
grub4dos uses BIOS mappings, if the BIOS doesn't map it, you won't have the device inm grub4dos.


Wonko

It's exactly what DOESN'T happen though

What happened was that it just did nothing and hung on a blank screen.

I realise that's not much information to go on, but I was rushed for time when I tested and didn't have a chance to make good notes of exactly what I did (I will next time!) I'm pretty sure I tried booting grub4dos from the HDD and from it's commandline doing:
root (hd1,0)
configfile /menu.lst

to load the menu.lst from the CF card, which just gave me the blank screen.

I may also have tried:
root (hd1,0)
chainloader /grldr

although I'm not sure about that. Testing with those commands (or similar) works fine on the Gigabyte board.

Anyway, you've given me a clue already and maybe I just needed to tinker with the BIOS to make sure the CF card was recognised properly in there first, so I'll try that next time, as well as booting direct to the CF card rather than the HDD first, and if that doesn't work try the XP MBR and bootsector as you suggest

Well, BOTH your attempts are anyway "wrong".
What works (and yes - again - "similar" is MEANINGLESS) on a motherboard not necessarily works on another one.
Just as an example a number of motherboards want to boot from "first" hard disk (disk 0x128).
When you issue the EXACT command:

root (hd1,0)

you get an EXACT feedback from grub4dos (if the device exists in BIOS).
Report the feedback message (EXACTLY).

If you have a menu.lst that worked when booting from the CF card (i.e. with the CF card as first disk) it won't probably work if used when the CF card is Second disk, and you need first thing to exchange disks:

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

Did - by any chance - the "blank screen" have in top left corner any among:

• a cursor
• a flashing cursor
• a "j" or a "g"

If you issue EXACTLY this:

root (hd1,0)

chainloader /grldr

on command line WITHOUT issuing also EXACTLY a:

boot

nothing will happen (but you would have anyway a feedback message, that you need to report EXACTLY).
The whole idea of using command line is to have feedback messages from grub4dos.....


Wonko

Wrong maybe, but different motherboards notwithstanding my tests on the Gigabyte DO show that I can load the menu.lst from the CF card after booting from the HD using configfile, so demonstrate that grub4dos can do this. Therefore the fact that it didn't work on the VL400 suggests a config/hardware problem or limitation on the machine, rather than any limitation in grub4dos or my procedure not being the "correct" one.

I think the blank screen just had a solid cursor in the top left corner, but let's wait until I've had a chance to test again and report back accurately, otherwise I'm wasting your time really. I only really started this thread before having more information to share in case there was something obvious I was overlooking, and your points about checking the device is detected in the BIOS and perhaps it only being able to boot from the first HDD are both good and worth looking at first.

Wrong maybe, but different motherboards notwithstanding my tests on the Gigabyte DO show that I can load the menu.lst from the CF card after booting from the HD using configfile, so demonstrate that grub4dos can do this. Therefore the fact that it didn't work on the VL400 suggests a config/hardware problem or limitation on the machine, rather than any limitation in grub4dos or my procedure not being the "correct" one.

Sure, UNdoubtedly grub4dos can do that, only the method/syntax/commands may be different, that's the idea.

I think the blank screen just had a solid cursor in the top left corner, but let's wait until I've had a chance to test again and report back accurately, otherwise I'm wasting your time really.

That would most probably mean a geometry related issue.

I only really started this thread before having more information to share in case there was something obvious I was overlooking, and your points about checking the device is detected in the BIOS and perhaps it only being able to boot from the first HDD are both good and worth looking at first.

Yep , but you see, I can give you a few more (more or less "obvious") points to ponder, but it is very UNlike a "proper" way to troublehoot a problem.
Let's say I have 15 more "obvious" checks (rest assured I have them all ) that may cause "not booting".
Is it smarter to try all of them at "random" (and possibly get success at the 15th try, or not getting it at all because there is a 16th that I don't know about or have forgotten, or failed to mention) or DIAGNOSE the problem and SOLVE it?


Wonko

Seeing the words "CF card", I know that all those cases of failure are not strange.

Why? Because the motherborad BIOS could have geometry-related bugs(or other bugs) on USB and CF storage devices.

Try these other ways:

1. boot using fbinst, then boot grldr secondly. (this is the highly recommended one)

2. boot MS(DOS, NTLDR, or BOOTMGR) first, then boot grub4dos secondly.

3. boot syslinux first, then boot grub4dos secondly.

4. boot GRUB2 or Burg first, then boot grub4dos secondly.

Yep , but you see, I can give you a few more (more or less "obvious") points to ponder, but it is very UNlike a "proper" way to troublehoot a problem.
Let's say I have 15 more "obvious" checks (rest assured I have them all ) that may cause "not booting".
Is it smarter to try all of them at "random" (and possibly get success at the 15th try, or not getting it at all because there is a 16th that I don't know about or have forgotten, or failed to mention) or DIAGNOSE the problem and SOLVE it?


Wonko

Heh, makes sense. I never get enough time on the machine to test anyway, so it would probably take me three weeks to try all 16 of your "obvious" checks I'll get back to you with some proper notes when I can

Seeing the words "CF card", I know that all those cases of failure are not strange.

Why? Because the motherborad BIOS could have geometry-related bugs(or other bugs) on USB and CF storage devices.

Try these other ways:

1. boot using fbinst, then boot grldr secondly. (this is the highly recommended one)

2. boot MS(DOS, NTLDR, or BOOTMGR) first, then boot grub4dos secondly.

3. boot syslinux first, then boot grub4dos secondly.

4. boot GRUB2 or Burg first, then boot grub4dos secondly.

Yeah, I don't think I've ever been able to boot a USB stick on this machine (I've never got anywhere with PLOP on any machine I've tried it on, it normally just hangs or reboots), but of course the CF in an IDE adapter is quite different to USB (may well still be a geometry issue as you and Wonko suggest though).

Thanks for the tips, I'll give them a go when I next get to the machine

Will grub4dos 0.4.5b work OK with FBinstTool 1.605?

P.S. I was just reading the PLOP readme (again) and it seems it's MEANT to reboot the PC (except when using the int19h option, which returns you to the boot manager without reloading, but with the USB as read-only). I just didn't think anything could survive a reboot! Anyway, no need to point out how dumb I am, I already know

fbinsttool 1.605 should work fine with grub4dos 0.4.5b/0.4.5c.you should use 0.4.5c, because it is more stable.

Thanks. I managed to edit the question you were replying to out of my post, whilst I was removing another question which I was about to add until I worked out how to get FBinstTool working by myself, but I've edited it again to put more or less the same question back, so it doesn't look like you're talking to yourself

The problem I had with FBinstTool was that I'd put grldr on the USB stick and it wouldn't boot but it appears I needed to install it to the reserved ud area, which I did using Tools - Update grldr and then selecting the latest 0.4.6a dated 13-04-2012 and it's booting fine now

Thanks. I managed to edit the question you were replying to out of my post, whilst I was removing another question which I was about to add until I worked out how to get FBinstTool working by myself, but I've edited it again to put more or less the same question back, so it doesn't look like you're talking to yourself

I noticed it. thanks.

it's booting fine now

If you meant all of all are ok now, I think then, this is because of the fbinst which solved the geometry issue.

Fbinst is powerful on resolving the geometry issue.

No sorry, my fault again for editing out my question. I've just been learning how to use FBinstTool with a spare 8GB USB stick I had. I probably won't get a chance to check whether it helps with the CF until later in the week (I can install it and check it works here, but I don't have any problem booting it here without FBinst, so only when I get to test on the problematic machine will I know for sure).

OK, had a chance to test some more today and this is what I found.

I could boot the normal grub4dos MBR from the CF card, but it was then unable to see any files. Grub4dos shows that it's looking for grldr and says (hd0,0) Disk Error (or something like that, forgive me for not rebooting to check as it takes ages to reboot into Windows each time) and then looks for it on (hd0,1) etc, which obviously it didn't find as I only had the CF card, with a single partition, connected.

With the HDD connected, the CF card boots the grub4dos MBR and then it finds grldr and menu.lst on the HDD and loads those.

I then formatted the CF with fbinsttool, using the force option, then installed grldr with Tools - Update grldr - ud/grldr and selected the most recent (0.4.6a), after which it shows grldr and PartitionTable.pt in ud/

Fbinst menu is:

default 0

timeout 0

menu F1 grldr "grldr"

and Grldr Menu is:

pxe detect

configfile

default 0

timeout 0

title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst

errorcheck off

configfile /boot/grub/menu.lst

configfile /grub/menu.lst

if "[email="%@root%"]%@root%"=="(ud[/email])" && calc *0x82A0=*0x82b9&0xff

if "[email="%@root:~1,1%"]%@root:~1,1%"=="f[/email]" && find --set-root --devices=f /menu.lst && configfile /menu.lst

find --set-root --ignore-floppies --ignore-cd /menu.lst && configfile /menu.lst

find --set-root --ignore-floppies --ignore-cd /boot/grub/menu.lst && configfile /boot/grub/menu.lst

find --set-root --ignore-floppies --ignore-cd /grub/menu.lst && configfile /grub/menu.lst

errorcheck on

commandline

title commandline

commandline

Trying to boot the CF after that, it just hangs on a black screen with a flashing cursor in the top-left, so it doesn't even find the MBR. Booting from the HDD and then trying to swap to the CF with:

title Boot CF Card

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

root (hd0,0)

chainloader /grldr

results in an error after "root (hd0,0)" about "can't find partiton" or "no such disk" (something like that). It's inaccessible anyway.

View MBR in fbinst shows

version: 1.6

base boot sector: 63

boot code size: 4

primary data size: 16128

extended data size: 0

debug version: no

bpb status: init

format options:

file list size: 896

file list used: 1

file list encoding: UTF-8

files:

  0	"fb.cfg" 0x3c4 18 (2012-04-22 01:40:59)

  0	"PartitionTable.pt" 0x3c5 1056 (2012-04-22 01:40:59)

  0	"grldr" 0x3c8 266524 (2012-04-22 03:00:05)

  1*   0x5d3 0x392d

primary area free space: 7464870

extended area free space: 0

and the BIOS shows the following for the CF ( (G) signifies greyed out) ):

Type - Auto

Cylinders 7769 (G)

Heads 16 (G)

Sectors 63 (G)

CHS Format Capacity 4010MB

LBA Format Capacity 4010MB

Multi-Sector Transfers - Disabled (G)

LBA Mode Control - Disabled (G)

32 Bit I/O - Enabled

Transfer Mode - [FPIO 4 / DMA 2] (G)

Ultra DMA Mode - [Mode 4] (G)

Just to update, the error given after trying to boot the CF from the HDD grub4dos menu is "Cannot mount selected partition".

There are several options in FBIntsTool format menu- chs, zip etc etc., have you tried them?

There are several options in FBIntsTool format menu- chs, zip etc etc., have you tried them?

I only had enough time to test again with chs and that didn't work any better. I didn't have time to disconnect the HDD, but with the BIOS set to boot from the CF first, it booted to the HDD menu.lst, so I'm not sure if it booted from the CF MBR first or not.

Strangely, when I went to format it with chs, the files that were in ud/ after the previous format using only force had disappeared!

I'll try zip next time I get on the machine.

You meant fbinst failed. That is very good.

Why? Because it shows at least one manufacturer is still attacking on fbinst(just IMHO), and the situation is not unexpected.

Another choice: Try a relatively new boot loader, the boot loader WEE. Hopefully the manufacturer just had no time(or was just not ready) to have prepared to attack on WEE.

If you are lucky, your CF card BIOS might support EBIOS. If this is true, you will boot WEE without failure.

Here is the source code of WEE:

http://code.google.c...n/grubutils/wee

And here you can download the weesetup command-line utility for Windows and Linux:

http://code.google.c.../downloads/list

You may try to access

(fd0,0), (fd0,1), (fd0,2), (fd0,3) ...
(hd0,0), (hd0,1), (hd0,2), (hd0,3) ...

and see which one is for your CF card Volume.

Suppose (fd0,0) is for the volume. Then you may run this under WEE:

(fd0,0)/grldr

Which will boot up the GRLDR installed previously on the CF card.

After the GRLDR successfully boot up, you should use the same device, i.e., (fd0,0), to access the volume on the CF card.

If I may this approach is the typical way NOT to troubleshoot an issue.

Carpenter's comparison:
Q. Every time I try to hammer a nail into these two planks together the nail gets bent.
A1. Try with a bigger hammer.
A2. Try with a bigger hammer and a bigger nail.
A3. Try with a sledgehammer and a bigger hardened steel nail.

Wouldn't it be more logical to inspect the planks and see if - by any chance - you left a piece of steel between them?

The info you posted (what your BIOS sees) is a CHS geometry of nx16x63.
With which geometry has the device been partitioned/formatted?
A number of BIOSes are "very strict" and won't let you boot a device that has been partitioned formatted with another geometry (probably in your case 255/63).
Can you boot for the grub4dos on hard disk and check the geometry of the device from it?
Can you try re-partition/re-format with a 16/63 geometry?


Wonko

You meant fbinst failed. That is very good.

Why? Because it shows at least one manufacturer is still attacking on fbinst(just IMHO), and the situation is not unexpected.

Another choice: Try a relatively new boot loader, the boot loader WEE. Hopefully the manufacturer just had no time(or was just not ready) to have prepared to attack on WEE.

If you are lucky, your CF card BIOS might support EBIOS. If this is true, you will boot WEE without failure.

Thanks, I'll give that a go. I noticed that fbinsttool has a "Install WEE to mbr" option, so I guess I can just use that?

I doubt fbinst even existed when HP made this Vectra VL400 though, so I doubt it's personal

If I may this approach is the typical way NOT to troubleshoot an issue.

Carpenter's comparison:
Q. Every time I try to hammer a nail into these two planks together the nail gets bent.
A1. Try with a bigger hammer.
A2. Try with a bigger hammer and a bigger nail.
A3. Try with a sledgehammer and a bigger hardened steel nail.

Wouldn't it be more logical to inspect the planks and see if - by any chance - you left a piece of steel between them?

The info you posted (what your BIOS sees) is a CHS geometry of nx16x63.
With which geometry has the device been partitioned/formatted?
A number of BIOSes are "very strict" and won't let you boot a device that has been partitioned formatted with another geometry (probably in your case 255/63).
Can you boot for the grub4dos on hard disk and check the geometry of the device from it?
Can you try re-partition/re-format with a 16/63 geometry?


Wonko

Heh, sounds like my approach to DIY certainly. I generally try and stay away from hammers and such like as it never turns out very well

I formatted the CF with fbinsttool using the force option (and the second time with the chs and force options), so it would have used whatever geometry it detaults to I guess.

How do i check the geometry of the CF from grub4dos commandline?

If necessary, how do I make fbinsttool format it with a 16/63 geometry instead?

It strikes me as a bit strange that the non-fbinst MBR booted grub4dos OK but then it was unable to see the actual partition with grldr. Would it even be able to see the MBR if the geometry was incompatible with the BIOS? After formatting with fbinst it was unable to even load the MBR, so perhaps that changed the geometry to something incompatible with the BIOS.

How do i check the geometry of the CF from grub4dos commandline?

Using the geometry command?
http://diddy.boot-la...ds.htm#geometry

If necessary, how do I make fbinsttool format it with a 16/63 geometry instead?

Actually what I am trying to induce you to do is to leave (at least temporarily) fbinst aside and use more "traditional" tools and MBR/bootsector code.
Not that fbinst is not good, it is believe me, BUT it has quite a few "unconventional" things/settings that may well - in my experience - make an anyway "pesky" BIOS like you seem to have "go beserk".

It strikes me as a bit strange that the non-fbinst MBR booted grub4dos OK but then it was unable to see the actual partition with grldr. Would it even be able to see the MBR if the geometry was incompatible with the BIOS? After formatting with fbinst it was unable to even load the MBR, so perhaps that changed the geometry to something incompatible with the BIOS.

Different partitioning/formatting and MBR code may give different results, this is perfectly normal.
Please follow my theory .
Any not-completely-demented BIOS developer/motherboard maker will test his/her BIOS - at the very least - with the most "common in the world" and "common at the moment" OS and relative MBR and bootsector and filesystem and partitioning tools included in it.
So, logically, *any* BIOS should behave with DOS 7.x/8.0 and/or Windows NT/2K/XP MBR/bootsector and partitioning tools included in them.
Issues are more likely to happen with Windows NT/2K/XP thingies because more often than not it ignores BIOS sensed geometry.
My suggestion is - depending on the results of the issuing of the geometry command in grub4dos - to try and partition/format that CF card from a "pure" DOS 7.x, such as *any* Windows 9x bootdisk may provide.
Once we (hopefully) have the thingy booting the "plainest" possible OS in the plainest possible manner, we'll probably have some basis to introduce variations and "better" tools/partitioning schemes, etc.


Wonko

Using the geometry command?

OK. I've never found a list of grub commands like that before so that'll go in my Favourites

Different partitioning/formatting and MBR code may give different results, this is perfectly normal.

Of course, but what seems strange is that the BIOS can see and boot the (grub4dos) MBR but then not see the partition. Is that perfectly normal?

Please follow my theory .
Any not-completely-demented BIOS developer/motherboard maker will test his/her BIOS - at the very least - with the most "common in the world" and "common at the moment" OS and relative MBR and bootsector and filesystem and partitioning tools included in it.
So, logically, *any* BIOS should behave with DOS 7.x/8.0 and/or Windows NT/2K/XP MBR/bootsector and partitioning tools included in them.
Issues are more likely to happen with Windows NT/2K/XP thingies because more often than not it ignores BIOS sensed geometry.
My suggestion is - depending on the results of the issuing of the geometry command in grub4dos - to try and partition/format that CF card from a "pure" DOS 7.x, such as *any* Windows 9x bootdisk may provide.
Once we (hopefully) have the thingy booting the "plainest" possible OS in the plainest possible manner, we'll probably have some basis to introduce variations and "better" tools/partitioning schemes, etc.


Wonko

OK. I'll find out what the current geometry is first and then see about formatting with DOS 7.x.

If you feel like it, I would be interested to know if RMPrepUSB would make it boot. You can install grub4dos or Wee using it (use latest Beta) very easily and use the Drive Info button to examine the MBR or PBR.