13 replies to this topic

[junksmi]

Hi all,

This is a fork from the post Grub4DOS problems with P4P800 (Error 17), specifically about the problem of booting from iso. I am trying to boot the Ubuntu mini.iso, placed on a 4 GB takeMS USB thumb drive, using GRUB4DOS 0.4.3 2008-05-07, and using the folowing lines in menu.lst:

title Start Ubuntu Mini 8.04 from ISO loaded in memory

map --mem (hd0,0)/mini.iso (hd32)

map --hook

chainloader (hd32)

When executing this entry, the system simply reboots and shows the menu.lst again. This happens both on a p4p800 stationary, and an Asus EEE 900.

• I found some references in grub4DOS docs that the image file should be contiguous, so I tested it with contig.exe:

  Processing L:\mini.iso:
  
  Scanning file...
  
  File size: 10053632 bytes
  
  L:\mini.iso is in 1 fragment
  
  ------------------------
  
  Summary:
  
  	 Number of files processed   : 1
  
  	 Average fragmentation	   : 1 frags/file

  so it looks like its contiguous...

I tried to test and boot the USB thumb drive in QEMU within Windows XP (on a third PC, though), using the following line:

D:\QStart>.\qemu\qemu.exe -L .\qemu\ -hda \\.\PhysicalDrive1 -std-vga

It boots, and as soon as the above menu.lst commands are executed, qemu fails with:

• qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a64a8
  
  
  
  EAX=00030010 EBX=00000000 ECX=00000000 EDX=000000ff
  
  ESI=00202628 EDI=00004ca4 EBP=00006b9a ESP=00000096
  
  EIP=000090a8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
  
  ES =0840 00008400 ffffffff 00cf9300
  
  CS =9d40 0009d400 0000ffff 00000000
  
  SS =0000 00000000 0000ffff 00009300
  
  DS =9d40 0009d400 ffffffff 00cf9300
  
  FS =0000 00000000 0000ffff 00009300
  
  GS =0000 00000000 0000ffff 00009300
  
  LDT=0000 00000000 0000ffff 00008000
  
  TR =0000 00000000 0000ffff 00008000
  
  GDT=	 0009f9f0 00000017
  
  IDT=	 00000000 000003ff
  
  CR0=600000fa CR2=00000000 CR3=00000000 CR4=00000000
  
  CCS=000000ff CCD=0000007f CCO=SARB
  
  FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
  
  FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
  
  FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
  
  FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
  
  FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
  
  XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
  
  XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
  
  XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
  
  XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

Finally, when I try to execute the menu.lst entry commands directly in the command line, with debugging enabled, this is what I am getting:

grub> debug on

grub> errorcheck on

grub> fstest on



grub> blocklist (hd0,0)/mini.iso

(hd0,0)4915736+19636



grub> map --mem (hd0,0)/mini.iso (hd32)

[16255,0,32][16255,32,32][16255,64,32][16255,96,32][16255,128,32]...[16255,480,32][16256,0,32][16256,32,32]...[16262,320,32][16262,352,32][4915799,0,10]



grub> map --hook

grub> chainloader (hd32)

int13/4B01(A0),err=0,drive=A0, int13/4B01(A0),err=0,drive=A0, 

Load segment: 0x0	System type: 0x0	Sector Count: 0x4

Load RBA: 0x22	Boot Type: 0 = No Emulation

Again, running 'boot' after this results with just a reboot on a PC, or the error message above if ran from QEMU.

Any ideas on what I could do to troubleshoot this?

Thanks..

[junksmi]

Ok, getting somewhere.. I had a USB spare thumb of 128 MB in size... So I tried with it, and the mini.iso boots Unfortunately, I'd like to use this method to boot the alternate Ubuntu iso, and it is some 700 mb in size

Here is a brief report - tried with formatting the key both with FAT16 and FAT32, and both cases worked..

FAT16 w/ Pe2USB - ok (grubinst_gui.exe, then copy grldr and menu lst)
FAT32 w/ diskmgmt.msc - cannot boot (here copied also grldr and menu.lst before running grubinst_gui.exe)
FAT32 w/ HP Usb Disk Storage .. - ok (grubinst_gui.exe, then copy grldr and menu lst)

Also both qemu and the real boot work.. And just for a note, even when it works, after the map command is executed, doing "hd(" + TAB in the command line will not show "hd32" as available disk

When doing the commands in grub command line, with debug, errorcheck, fstest on, only the following is different:

grub> blocklist (hd0,0)/mini.iso

(hd0,0)2386+19636

grub> map --mem (hd0,0)/mini.iso (hd32)

[2063,0,32][2063,32,32][2063,64,32][2063,96,32][2063,128,32][2063,160,32][2063,192,32][2449,0,10]

The output is map is shown in its entirety - the one in the previous post had at least 10 more entries, even if in both cases the file is contiguous as confirmed by contig.exe!!

Now, the most important differences are

• 128 MB < 4 GB, and
• 2063 < 16255 (in the map output) ...

Just a wild guess - if the error is due to 2063 < 16255; would it be possible to cheat the system, if I say first copy the mini.iso (and possibly, alternate.iso) right after formatting a 4GB drive, and then try to run WinSetupFromUSB and the like to add XP sources?

Is it possible to move files around on a disk using some application - say to push the mini.iso file from the outer sectors of a 4GB USB drive to the inner ones (even if there is only about 400 MB free left on the drive ) ?

Thanks...

[tinybit]

Thank you junksmi for your test and experience shared.

using GRUB4DOS 0.4.3 2008-05-07

This version is not ready for so many things. Use the latest one found at http://grub4dos.nufans.net/ , please.

the image file should be contiguous

if --mem is used, the image file can be non-contiguous.

doing "hd(" + TAB in the command line will not show "hd32" as available disk

Virtual CDROMs are not listed for the time being. Only floppy/hard disks and the (cd), (rd), (pd) and (nd) are listed.

---------------

Overall, use the latest build to test once more. You can turn fstest off, but post the output of the geometry command.

[junksmi]

Hi tinybit,

Thanks for your answer.

Well, I got a new takeMS 2GB key today, hoping I'd get it to work, and I couldn't do it - although sometimes it would in fact work under Qemu - which I ran under the default Xandros Linux of Asus EEE 900, with the following line:

qemu -L /usr/local/share/qemu/ -hda /dev/sdc

.

But I guess it doesn't matter, because I think I've discovered some problems even on the 128 MB key. I'm trying to execute the very same commands to boot mini.iso, and using different versions of grldr. Here are my results:

http://nufans.net/gr...-2008-05-14.zip - reboots on "boot" command
grub> geometry (hd0)
drive 0x80(LBA): C/H/S=16/255/63 Sector Count/Size=257040/512
Partition num:0, active, Filesystem type is fat, partition type 0x0C

2008-10-12 - works
http://nufans.net/gr...-2008-10-17.zip - works
http://nufans.net/gr...-2008-10-20.zip - works
http://nufans.net/gr...-2008-10-22.zip - works

http://nufans.net/gr...-2008-10-26.zip - works
grub> geometry
drive 0x80(LBA): C/H/S=15/255/63 Sector Count/Size=240975/512
Partition num:0, active, Filesystem type is fat, partition type 0x0C

http://nufans.net/gr...-2008-11-01.zip - freeze on "chainloader (hd32)" command
grub> geometry
drive 0x80(LBA): C/H/S=15/255/63 Sector Count/Size=240975/512
Partition num:0, active, Filesystem type is fat, partition type 0x0C

http://nufans.net/gr...-2008-11-02.zip - freeze on "chainloader (hd32)" command
http://nufans.net/gr...-2008-11-05.zip - freeze ...

Looks like November was unlucky month - I guess that is where the problem starts creeping in... Note also the differences reported in disk geometry between 0.4.3 and 0.4.4 ...

gparted currently reports the 128MB drive as flags: boot, lba; filesystem fat32. Now, in my previous post #2, I didn't state which Grub4DOS version I've used - apparently, it isn't 0.4.3, since 0.4.3 now also behaves the same (reboot) as described in OP (I don't think I've reformatted the 128 MB drive in the meantime, although I've reformatted the other one, so may be I have made a mistake)..

Well, I guess I better wait until the 128MB can be confirmed to boot proper with the latest version, before trying the 2GB out

Thanks & Cheers !

[was_jaclaz]

Well, I guess I better wait until the 128MB can be confirmed to boot proper with the latest version, before trying the 2GB out

Hmmm, AFAIK grub4dos reads CHS info from the partition table, thus if it read at any time 16 Cylinders, it means that at the the time the 16 was written to the partition record.

How was the stick partitioned/formatted?

Has it been re-partitioned/re-formatted?

Check this oldish page of mine, since it talks about a 128 Mb stick, it should be easy to follow and compare with yours:
http://home.graffiti...B/USBstick.html

Though some of the info in there needs updating, everything is still fundamentally valid.

jaclaz

[junksmi]

Ciao jaclaz!!

Thanks for the response!

How was the stick partitioned/formatted?
Has it been re-partitioned/re-formatted?

Last part of 'partitioning history' of the device was given in #2:

• FAT16 w/ Pe2USB - ok (grubinst_gui.exe, then copy grldr and menu lst)
  FAT32 w/ diskmgmt.msc - cannot boot (here copied also grldr and menu.lst before running grubinst_gui.exe)
  FAT32 w/ HP Usb Disk Storage .. - ok (grubinst_gui.exe, then copy grldr and menu lst)

I'd guess it's still in the FAT32 format from HP Usb Disk Storage also now..

Check this oldish page of mine, since it talks about a 128 Mb stick, it should be easy to follow and compare with yours:http://home.graffiti...B/USBstick.html Though some of the info in there needs updating, everything is still fundamentally valid.

Thanks a lot - great reading resource Following those links, I finally understood what a 'cylinder' is

Well, the only thing I understood how to do, is basically write down the information about disk/partition that the different tools give, and here they are in a table - I've formatted it as html, and put it on pastebin here http://pastebin.com/f24732161 or rather:

http://pastebin.com/...hp?dl=f24732161

The dl link will force a download of an html view, which can be then opened in a browser (I don't think there would be a way to show the file as html directly from pastebin) [btw I spent a couple of hours compiling all this for the usb flash - I think I'd love a tool that would produce that kind of a report automatically ]

For the time being, I think that basically it confirms the same thing you've experienced, noted on your 'oldish page'. Basically, different tools report different amount of sectors; in qemu on XP there are 'attempt to access beyond end of device' during boot; and eventually 'fdisk -l' on proper Ubuntu reports:

Partition 1 has different physical/logical endings:

phys=(14, 254, 63) logical=(15, 205, 62)

I'm not sure whether I'd be able to reformat with a different tool and be OK - I hope I don't have to enter anything in bootrecord ( MBR ? ), especially since I don't yet quite understand how the 'right' values entered were calculated

Well, let me know if there are any suggestions - in the meantime, I guess I'll try reformatting as FAT32 under Gparted and see if that makes any difference..

Thanks,
Cheers !

[was_jaclaz]

ALL the data you posted is correct, also the seemingly inaccurate fdisk -l one:
logical=(15, 205, 62) is actually representative of 253,889 LBA sectors

Something that is seen in Beeblebrox or PTEDITE32 as EndCHS:
14/254/63
Is actually a representation of a geometry of 15*255*63.

Now, download this simple spreadsheet:
http://www.boot-land...?showtopic=2959

And check the LBA data with it.

But you still miss some data: the actual total number of bytes/sectors accessible on the stick.

I personally use dsfo as detailed here:
http://www.boot-land...?...c=5000&st=1
you might want to use dd, as long as it can give you the same results.

Once you have the total number of bytes, play a bit with the spreadsheet until you get the actual correct END CHS address (and LBA), then FORGET about it and find the smaller CHS address (and LBA) immediately BELOW the one above that respects a Cylinder boundary.

Example, say that the result of dsfo or dd or whatever is 128,000,000 bytes:
try entering values in the eCyl eHead eSect columns of the spreadsheet in one of the two CHS->LBA lines:
the End CHS is 15/143/16 (which makes 127,967,744, which summed to the hidden 32,256 bytes makes 128,000,000)
the nearest BELOW Cylinder boundary is:
16->63 (fixed value)
143->254 (fixed value)
thus:
15 must become 14

Enter these values in the spreadsheets CHS->LBA other line.

Now use Beeblebrox or PTEDIT32 and change the data accordingly:
(06) (80) 1 1 14 254 63 63 240.912

Remove the stick, re-insert it and format it normally (I am assuming that some MBR CODE has already been written to the stick).
Add the appropriate boot files.

Now, try booting from it in Qemu.

It WON'T work.

Qemu on smallish partitions wants a CHS geometry of m*16*63 instead of the n*255*63.

Open again the stick in beeblebrox and change the filesystem (06 CHS mapped FAT16) to (0E LBA mapped FAT16) and now it should boot in Qemu.

Next try changing partition type to FAT32 types and re-formatting.


I hope that I have somewhat clarified the matter, without confusing you, if the latter is the case, just post your question and the actual size of your stick, and I'll try and help you further.

jaclaz

[junksmi]

Jaclaz, amazing - I was about to post back, and I saw you had answered in the meantime - cheers, mate

Well, let me first post back on experiences with Gparted under regular Ubuntu - good news is, it boots the latest grldr (0.4.4 2008-11-02) in Qemu/XP; it however feezes on 'chainloader (hd32)' when booting live under Asus EEE I had to manually delete partition, then apply, then make partition and format, and apply in Gparted; otherwise, it would automount during format and screw up the procedure - and additionally, it would give different amount of available bytes each time

Right, so the numbers have changed, and here is the new report:
http://pastebin.com/...hp?dl=f4cd6ab65

And check out the diff as well http://pastebin.com/...?diff=f4cd6ab65 - the colors may spare your eyesight a bit (but the html tags unfortunately won't ) - still, interesting to see what differs from last time..

Once you have the total number of bytes, play a bit with the spreadsheet until you get the actual correct END CHS address (and LBA), then FORGET about it and find the smaller CHS address (and LBA) immediately BELOW the one above that respects a Cylinder boundary.

Unfortunately, this is a bit above my league for the time being - but the example you wrote below looks very reasonable, I'll just need some time to digest it

14/254/63 Is actually a representation of a geometry of 15*255*63.

This is for instance something that gives me a bit of a headache - since both 14 < 15 and 254 < 255, I cannot see much logic in that kind of representation (apart from 0- and 1- based arrays) ..

I personally use dsfo as detailed here:
http://www.boot-land...?...c=5000&st=1

Thanks for the tip, tried it now (after the drive was reformatted in gparted) and it gives:

> dsfo \\.\PHYSICALDRIVE1 0 0 NUL

\\.\PHYSICALDRIVE1 - The drive cannot find the sector requested.

This error can probably be ignored.

OK, 130023424 bytes, 15.862s, MD5 = 4771b88b0c00162a8209f69a3f98e3e6

I'm not sure what to think of this error, but there is something else that interests me:

• Is this number of bytes shown dependent on the formatting?
• AFAIK, as older sectors die out on the flash drive, they are probably marked as bad on the controller level ( not sure about this), and then if you reformat as some sectors have died, you will get a new lesser amount of available storage. When these bytes are shown here, is that taken into account?

I hope that I have somewhat clarified the matter, without confusing you, if the latter is the case, just post your question and the actual size of your stick, and I'll try and help you further.

It definitely helped - however, I still need some sort of a model in my head for the relation between disk geometry and booting process, so I can understand the calculations used below. Well, I guess it's off to reading now

Thanks again

[was_jaclaz]

I'm not sure what to think of this error, but there is something else that interests me:

• Is this number of bytes shown dependent on the formatting?
• AFAIK, as older sectors die out on the flash drive, they are probably marked as bad on the controller level ( not sure about this), and then if you reformat as some sectors have died, you will get a new lesser amount of available storage. When these bytes are shown here, is that taken into account?

Answers:

• NO, these are whatever the controller can "give", and it's hardcoded in the controller after manufacturing. (according to the manufacturer and size of the Flash IC(s) attached to the controller)
• NO. Rest assured that USB controllers know how to make their job, do not make things over complicated.

This is for instance something that gives me a bit of a headache - since both 14 < 15 and 254 < 255, I cannot see much logic in that kind of representation (apart from 0- and 1- based arrays) ..

Correct.
Cylinders start from 0
Heads start from 0
Sectors start from 1
(God only knows how they managed to make this mess when designing hard disk and partition tables)



jaclaz

[junksmi]

Jaclaz,

• NO, these are whatever the controller can "give", and it's hardcoded in the controller after manufacturing. (according to the manufacturer and size of the Flash IC(s) attached to the controller)
• NO. Rest assured that USB controllers know how to make their job, do not make things over complicated.

Thanks, much appreciated Sorry for the complication - I just got interested; makes sense otherwise that this number should not change (and I remember now, even in XP, it always says total bytes and then bad sectors afterwards)

So - I just tried the spreadsheet, and it's actually not that bad - provided I understood how it works:

• given: the values of eHead and eSect for boundary conditions are: eHead=254, eSect=63 (what would this be dependand on? type of formatting?)
• Basically, first I obtain the total addressable amount of bytes on the usb flash from dsfo, which is totBytes = 130023424.
• Then, I need to subtract 32256 from this, to see what number I'm trying to get in the spreadsheet and so totBytesSpread = 129991168 = 130023424 - 32256
• Open the spreadsheet, and insert some values for eCyl/eHead/eSect in the first CHS->LBA row (which is row 8)
• Since you already gave a headstart with 15/143/16 for eCyl/eHead/eSect, that is the initial value I started with - and then the value of Size (Bytes) column in spreadsheet changes to 127,967,744
• Then I basically started first changing only eHead, so as to get Size (Bytes) as close to totBytesSpread = 129991168; and then I changed eSect to finetune until (Size (Bytes)==totBytesSpread) - here are my last steps:
  • ecyl/ehead/esect = 15/206/63 -> Size (Bytes) = 130,023,936 which is > 129,991,168 bytes
  • ecyl/ehead/esect = 15/205/63 -> Size (Bytes) = 129,991,680 which is > 129,991,168 bytes
  • ecyl/ehead/esect = 15/205/62 -> Size (Bytes) = 129,991,168 which is = 129,991,168 bytes
• Then, in the row below, I'm supposed to enter nearest lower values that lie on a boundary. This I understand like rounding - or rather finding the lower integer bound of a floating number (basically, floor(2.3)=2) - except the lowest "digits" here are not 0 for each "digit position", but instead 254 for eHead, and 64 for eSect (and plus ecyl needs to be "rounded" too). So we have:
  • Lowest eSect on a boundary from our eSect=62 is 63 - so new neSect=63
  • Lowest eHead on a boundary from our eHead=205 is 254 - so new neHead=254
  • since the lowest neSect and neHead appear bigger than eSect and eHead, we need to lower eCyl=15 by one (so we don't adress more than possible for the controller) and so new neCyl=14
• So, our newfound values are nEcyl/nEhead/nEsect = 14/254/63 (the same ones jaclaz derived in his example as well) - although, for value of 64, eSect in the spreadsheet turns red; and it goes back to normal if it is set to 63 [which implies nEcyl/nEhead/nEsect = 14/254/63]

Now, a funny thing is that Beeblebrox reports exactly this geometry (14/254/63) after the stick was formatted in gParted - except it's for FAT32 (pType=0c ?)

Entry	Ptype	Boot	bCyl	bHead	bSect	eCyl	eHead	eSect	SectBefore	TotSectors

0		0C		80		0		1		1	14	254		63		63		240912

(which of course jaclaz noticed immediately - but it took me a while )

Now as I understand this - even if the current format is like this, I should nonetheless go back to changing the filesystem first to (06 CHS mapped FAT16) then reformat, then to (0E LBA mapped FAT16) and reformat - and finally back to FAT32 (0c) and reformat? PS: And which tool should I use for formatting - should I stick to gParted?

Thanks...

[was_jaclaz]

Some further small clarifications. (hopefully )

There are several "common" geometries for mass storage devices.
See my MBRBATCH for them:
http://www.boot-land...?showtopic=3191
http://www.boot-land...?showtopic=5000

The most common nowadays is n*255*63, which is also "forced" by 2K/XP/2003 and Vista.
NT 4.00 "forced" m*64*32.
The l*128*63 is very rarely used (and only by a few BIOSes manufactured in a short period of time when CHS/ECHS translation was used)
The i*16*63 is still used by some BIOSes (and most notably by Qemu ones) on smallish volumes.

A stick that has 130,023,424 bytes has 130,023,424/512=253,952 sectors

Assuming a geometry of n*255*63:
253,952/63=4030.9841->4030 heads
(sectors are 63, numbered from 1 to 63)
4030/255=15.804->15
(heads are 255, numbered 0 to 254)
Thus the stick will be viewed by Beeblebrox or similar utility as having n=15
(cylinders will be 15, numbered from 0 to 14)
So the last accessible sector via CHS, mantaining the convention that Partitions must end on a cylinder boundary will be:
(14+1)*(254+1)*63=240,975
But since the partition must, by the same convention, start at a cylinder boundary, before partitionable space we need to hide some sectors, up to first available cylinder boundary, which is obviously:
(0+1)*(0+1)*63=63
Thus partitionable space is 240,975-63=240,912 sectors
End cylinder CHS address will be 14/254/63.

Some notes (in no particular order of importance):

Then, I need to subtract 32256 from this, to see what number I'm trying to get in the spreadsheet and so totBytesSpread = 129991168 = 130023424 - 32256

32256 is not a magic value, it is 63*512, if you want to calculate with a different geometry you need to change the data in top left of the spreadsheet (Disk Geometry) and change accordingly the number of hidden sectors.

So, our newfound values are nEcyl/nEhead/nEsect = 14/254/63 (the same ones jaclaz derived in his example as well) - although, for value of 64, eSect in the spreadsheet turns red;

Sure, there is a simple check whether each value in the bCyl, bHead, bSect, eCyl, eHead, eSect column exceeds the Disk Geometry data in cells Cyl, Head, Sect, respectively.

Now as I understand this - even if the current format is like this, I should nonetheless go back to changing the filesystem first to (06 CHS mapped FAT16) then reformat, then to (0E LBA mapped FAT16) and reformat - and finally back to FAT32 (0c) and reformat? PS: And which tool should I use for formatting - should I stick to gParted?

Actually no, it is not "needed", it is simply the path to take in order of maximum known compatibility, see FAQ #10:
http://home.graffiti...SB/USBfaqs.html

The whole point of the "exercise" is to have correctly "balanced" data both in the CHS and LBA parts of the address, thus, once you have formatted the stick partition as 06 (and it boots), you should be able to use beeblebrox to only change the partition type from 06 to 0E and the stick should behave exactly the same (on a "good" BIOS).
As well, once you have it formatted as 0B (and it boots), you can simply change the 0B to 0C.

You can use any tool you like to fdisk/format the stick.

The only thing that you might want to do is to start from a "blanked" stick, I always recommend wiping the first 100 sectors - actually needed are 63+bootsector(s) - which correspond to:
63+1=64 if stick was only formatted as FAT16
63+6=69 if stick was formatted as FAT32
63+16=79 if stick was formatttted as NTFS
The 100 comes from simplicity, 51200 is easier to remember than 79*512=40448
http://www.boot-land...?...=4015&st=21

Zeroing out first sectors prevents any "strange" fdisking/partitioning/formatting utility to find and possibly misinterpreter (or leave back after it's usage) anything that was there before, that may cause somehow problems in booting, see this:
http://www.boot-land...?showtopic=6110

This said, different BIOSes and different OSes may implement more or less strictly the said "convention" about cylinder boundary, so in a number of cases having partition data unbalanced and partition not starting and ending on a cylinder boundary (thus allowing for the "Full" use of the available space on disk) may work nonetheless.



jaclaz

[junksmi]

First of all Jaclaz - thanks so much for your in-depth explanation, I am learning a lot

Well, anyways - I did some reading, but then I tried some experimenting on my own, and there are some good news I think - it seems this is an issue mostly w/ the Asus EEE PC 900, and additionally, it seems there is a single grub4dos version that actually works, both for 128MB and 2GB usb stick - which is 0.4.4-2008-10-17.

Ok, from the start - first I started retesting this 128 MB drive. First, I tried a Pe2USb reformat of 128MB stick to FAT16 (0B). Now, in Beeblebrox there was only one difference as opposed to the previous format (via gparted/Ubuntu) and that is that now TotSectors=253889, as opposed to the previous 240912 - which we otherwise have learned is the correct "lowest common denominator" so far. Since during the gparted format, the "round to cylinders" during new partition was activated, I would guess that:

The algorithm that Jaclaz explained, is in fact more-less what is executed, when "round to cylinders" is chosen during gparted formatting (or creation of a new partition, rather)

My guess is that none of the other Windows tools, like Pe2USB, or the HP formatting tool, do that. Changing the number of total bytes in Beeblebrox didn't make a difference to the problem (which is/was: the hanging on the 'chainloader (hd32)' command, while booting from an iso via map).

The strange thing is that testing in QEMU in fact worked - both on EEE pc/Xandros, on nc6000 laptop/XP and on p4p800/Ubuntu (note that in ubuntu I had to do 'SUDO /usr/local/bin/qemu -L ...' as opposed to just 'qemu -L ...' in eee xandros, that took certainly couple of hours to figure out )

Also real boot from nc6000 worked - but for some reason, p4p800 wouldn't even recognize that the stick was bootable: "This is not a bootable disk. Please insert a bootable floppy.." Which is why I'd like to raise this again:

BIOS (and DOS) do not care about the state of the "Removable bit", Windows (NT based ones) do.

For some reason, the p4p800 bios recognizes the 128MB stick as a 'removable', and tucks it together as a boot priority choice along with the floppy, regardless of FAT16 or FAT32 format (the same p4p800 declares the 2GB takeMS stick as a hard-drive, and puts it together with the hard disk for boot priority choice - finally in the bios you choose if you want the removable device or the hard disk device to go first). The Asus EEE bios, on the other hand, shows either of the keys in the choice menu for hard disk devices - although in the final boot menu there is an entry for an additional 'removable' device ... Could this discrimination by the p4p800 bios have anything to do with this removable bit? (although I think I've tried using a utility before to change that bit on takeMS sticks, and the p4p800 didn't care, it still treated them as hard-drives...)

After some pointless meddling with the 128MB, I decided to ditch it and go back to the 2GB. Formatted in gparted/ubuntu as fat32 + boot flag and rounded cylinders and latest grub4dos; the tests said: nc6000/qemu/XP ok, nc6000/real ok, EEE/real freeze on chainload, EEE/qemu/Xandros ok, p4p800/QEMU/Ubuntu ok, p4p800 real ok (note that with w/ FAT16, it also froze on nc6000/real boot, but I cannot remember how it got formatted there).

This points to me that there most likely is nothing wrong with the format of the drive, or grub4dos - but instead with the Asus eee 900, and here I suspect the BIOS.

SO... I decide to flash the BIOS, the one I have is ASUS 900 ACPI BIOS revision 0802, however the latest seems to be http://update.eeepc....0-ASUS-0906.zip .. I try that one (Here it turns out Asus EEE will not recognize the 2GB stick, when doing Alt+F2 bios flashing- the 128MB stick worked, though) No improvements whatsoever with the new BIOS, and I decide to flash back to 0802, and re-try the working 128MB format described previously.

Bad surprise - now none of the working grldrs described in #4 seem to work on the 128MB stick Possibly the bios flashing disrupted something in the EEE, who would know. I get tired of copying and renaming grldrs for testing, and I decide to "chainload" different versions of grldr , and to try to boot the iso in a slightly easier way, and at least confirm that nothing works. Here is the menu.lst:
http://pastebin.com/f6d05b3cb

Simply, one grldr is used, and then from each grub4dos version, the grub.exe's are extracted, renamed according to version, and placed in the root (well, it's not really "chainloading" I guess, they are called throuh 'kernel grub*.exe' command, but still - effect to me is the same ) And then, since the same menu.lst is used for all of them, first you choose a grub4dos version you want, and then the entry for booting the iso. (might be a good idea for grub4DOS developers to maintain a zip package of all grub.exe's renamed according to version, and a corresponding menu.lst, to assist in debugging problems like the one I have )

Although kind of a desperate move, I tried this first on the 2GB stick, to confirm each grub4dos version noted in #4 would not be working on the 2GB stick. And imagine the surprise when Grub4DOS 0.4.4-2008-10-17 worked

The 2GB stick is gparted/Ubuntu formatted FAT32, boot flag only (the main grldr on it is 0.4.4-2008-10-26). None of other versions listed in #4 (before or after 0.4.4-2008-10-17) work. Tried the same also with the 128 MB - now it's the same thing - only 0.4.4-2008-10-17 works, which contradicts my first report in #4 ( although I can almost guarantee it was like that, since I was taking notes as I was testing each version across PCs ) Best thing of all, was when it showed that it can boot also the alternate Ubuntu CD some 700 MB in size from the 2Gb stick

Well, basically this solves me problem, I'd hope - although it would definitely be nice to be able to use the latest grub4DOS on the asus EEE as well And I might get back again re: Jaclazes last post

Thanks for the help I think I had enough of USB sticks today I guess I need some rest now ...

[was_jaclaz]

I can get maybe 30% of your report.
...but the main thing is that you found a working way.

However:
A number of BIOSes are "racists" (or "classists") they think that smallish sticks are "removable" or "super-floppies" and that "bigger" sticks "must be" hard disks, regardless of the "flippable bit".

Instead of using the kernel syntax, you may prepare yourself a floppy image (can also be gzip compressed) with the "right" grub4dos and a a menu.lst chainloading the .iso.
Then you simply chainload the floppy image.

So it should be the bolded entry that creates this incompatibility:

2008-11-11(r61) added --ignore-cd option for the find command.
2008-11-08 read the boot file to determin the pxe block size. avoid running pxe_detect for non-pxe booting.
2008-11-02 added a new option --mbr-no-bpb for bootlace.com.
2008-11-01 changed PXE_MIN_BLKSIZE and PXE_MAX_BLKSIZE. allowed FAT cluster size larger than 32K.
2008-10-26 fixed pxe block size issue.
2008-10-21 fixed cylinder issue in int13/ah=8. Fixed stack conflict in bootlace.

All the others seems like not related.

jaclaz

[steve6375]

Just been reading this post. 'Online' made a discovery that if a USB drive has two partitions, it is more likely to be bootable by a wider variety of BIOSes. I have tested this and found it to be true. If a UFD has a small extra hidden partition (see my Windows utility RMPrepUSB from Source Forge - or wimb's tools) then the BIOS is more likely to recognise it as a hard disk rather than a large floppy disk.

I had a PC that would not boot to WinPE v2 as it treated USB sticks as a large floppy drive, if I used RMPRepUSB to put on an extra hidden partition it booted correctly as a USB hard disk.

So I would recommend you always use one of these tools to partition you UFDs.

P.S. I also managed to get a PC to boot to WinPE v2 that ALWAYS treated ANY UFD as a floppy disk using a menu.lst like this:

find --set-root /winpe.iso
map --mem /winpe.iso (fd0)
map --hook
chainloader (fd0)/BOOTMGR
rootnoverify (fd0)

hope this helps
Steve