17 replies to this topic

[ktp]

I am using grub4dos 4.4.4-2008-08-08.

I installed grub4dos on MBR on an external USB hard disk (500 GB). Curiously on
one machine, grldr is loaded OK and menu.lst presented. On another machine,
I got the message (hd0,0) ntfs5 grldr not found and finally it failed after trying other
partitions.

Is there an explanation? grldr and menu.lst are copied at the end, after copying almost the 500 GB
data, of the sectors/clusters must be very high on the disk. Could it be a problem? But then why
does it work on one machine and not on the other?

Of course on the root of the disk (single NTFS partition) there are grldr and menu.lst files.

[kDn]

I am using grub4dos 4.4.4-2008-08-08.
...
Is there an explanation? grldr and menu.lst are copied at the end, after copying almost the 500 GB
data, of the sectors/clusters must be very high on the disk. Could it be a problem? But then why
does it work on one machine and not on the other?
...

Seems like as LBA-48 problem
1. Try update BIOS
2. Try to use newest version grub4dos

[was_jaclaz]

more pragmatically, try testing if the position is a problem.

This should work:

Hopefully you have two files in root of the drive that you know for sure were copied to it in an early stage (i.e. that are placed in a relatively "low" address).

One of the files has to be bigger than grldr, lets call it FILE1.
One of the files has to be bigger than menu.lst, lets call it FILE2.

Create a folder and move to it grldr and menu.lst.

Create a folder and copy to it FILE1 and FILE2.

Rename FILE1 in root to grldr.
Rename FILE2 in root to menu.lst.

Copy grldr and menu.lst from the folder to root overwriting the two renamed files.

Move FILE1 and FILE2 to root.

jaclaz

[tinybit]

Classical problem, the BIOS bug, as said kDn. Your BIOS could only access upto 137G of your drive.

Try using a defrag utility or a disk file utility to arrange grldr and menu.lst so that they can be accessed by BIOS.

[ktp]

Many thanks to all for answering. What surprises me is that with all the laptops I can try, the problem did not appear
with "old" laptops, and only with very recent ones. Of course, the LBA-mode is set automatically in all BIOSes
as default (usually this option is greyed out, so no possibility to disable LBA-mode).

Laptop 1 : Acer, year 2001 Pentium M 1.3 GHz, Bios Phoenix : grldr found, USB 2.0 boot speed
Laptop 2 : HP, year 2005 Pentium M 1.7 GHz, Bios AMI : grldr found, USB 1.x boot speed
Laptop 3 : MSI, year 2007 Core 2 Duo T7500 2.0 GHz, Bios AMI : grldr NOT found, USB 1.0 boot speed
Laptop 4 : Asus, year 2008 Core 2 Duo/Centrino 2 P8600 2.4 GHz, Bios AMI : grldr NOT found, USB 2.0 boot speed

1) Could someone point to me a link to an utility that can put specific files (grldr, menu.lst) to low sector/cluster on the disk?
2) Once grldr/menu.lst is rearranged to be at low-numbered sectors on the disk, could future updates of grldr or menu.lst (many editing sessions)
change their location to the higher (> 137 GB) sectors, causing the problem again?

[tinybit]

@ktp

newer machines might have newer bugs

According to your reports, Acer and HP have less bugs than MSI and ASUS.

>> could future updates of grldr or menu.lst change their location to the higher (> 137 GB) sectors, causing the problem again?

Yes. It will appear again

Even your NTLDR and BOOTMGR must be placed low, or else your Windows will not start.

You should partition your disk and split a small one(1GB for example) at the beginning, for Boot Files such as NTLDR, GRLDR, BOOT.INI, menu.lst, vmlinuz and initrd to be accessed by BIOS.

[was_jaclaz]

You should partition your disk and split a small one(1GB for example) at the beginning, for Boot Files such as NTLDR, GRLDR, BOOT.INI, menu.lst, vmlinuz and initrd to be accessed by BIOS.

Which brings up again the good ol' (15 year old ) common sense advice:
http://www.boot-land...opic=5274&st=31

You may want to try using jkdefrag command line using one of the sorting criteria, possibly renaming a few files to numbers to easen the ordering and then renaming them back:
http://www.kessels.com/Jkdefrag/

jaclaz

[ktp]

@tinybit and @jaclaz
Thank you for your explanations and solutions.
I agree with jaclaz for the 15-year old common sense advice :-).
I will try jkdefrag but for confirmation only, since later update/editing would run into 137GB-limit again.

Another question: if I have several partitions, with one partition containing grldr beyond the first 137GB, will it works?
It will be different from having a single big partition (> 137GB), since apparently grub4dos MBR code will try
finding in each partition for grldr, and it should finally find it, isn't it?

Note: of course this partition is less than 137GB. To clarify, let's take an example:
(hd0,0) primary NTFS 200 GB
(hd0,1) primary NTFS 20 GB, containing grldr and menu.lst at its root directory.
So grub4dos should find (hd0,1)/grldr and (hd0,1)/menu.lst with this configuration, could you confirm?

[was_jaclaz]

To clarify, let's take an example:
(hd0,0) primary NTFS 200 GB
(hd0,1) primary NTFS 20 GB, containing grldr and menu.lst at its root directory.
So grub4dos should find (hd0,1)/grldr and (hd0,1)/menu.lst with this configuration, could you confirm?

I can confirm it NOT.

The drive starts at address 0.
Any address beyond 137 Gb results in "a suffusion of yellow", it doesn't matter how big is the second partition, if it starts beyond 137 Gb (or the files in it that are placed beyond 137 Gb from beginning) won't be seen/accessed properly.
Just imagine it as an electric car that only has enough battery power to run for exactly 137 Km, you simply cannot get beyond that distance (on a VERY long road ).

And please remember that as tinybit said, NTLDR has as well addressing limits.

If you copy these files at the beginning of the volume, it is VERY unlikely that they will be moved later when updating/defragging, defragging engines tend to keep files where they are, when they are in ROOT.

jaclaz

[tinybit]

@ktp

If you have a 200G followed by a 20G, then the whole 20G partition will not be accessible by BIOS.

BIOS does not know about partitioning. BIOS only knows how to access sectors on a disk. Only OSes could know about partitioning.

[ktp]

@ktp

If you have a 200G followed by a 20G, then the whole 20G partition will not be accessible by BIOS.

BIOS does not know about partitioning. BIOS only knows how to access sectors on a disk. Only OSes could know about partitioning.

You are right of course. But since I install grub4dos in MBR, grub4dos MBR code tries to find gldr in specific locations of each partition (root, /boot). This is why we see the sequence Trying (hd0,0), trying (hd0,1) etc... so grub4dos does care about partitions. I would hope that grub4dos code could handle that (since it understands NTFS4/NTFS5).

By the way I have a spare 160GB hard disk put on USB enclosure, so I did experimentations to confirm.
I create a big primary partition below/beyond 137GB, and another primary partition where I put ntldr, ntdetect.com, boot.ini, grldr.
1) The 137 GB value is probably theoric, in my experimentations, even at 130 GB the problem still alive.
2) At 100/120 GB it is OK (boot). So probably the pratical value is 128 GB ?

At > 137 GB, when I type the Tab key after "find (hd0," I got temporary hang:

grub> find (hd0,

  Possible partitions are:

	Partition num: 0, Filesystem is ntfs, partition type 0x07

	Partition num: 1, active,

Error 25: Disk read error

then blinking cursor on some lines afterwards.

The hang occurs after the Partition num:1 line, then after a relative long time (I would reboot otherwise), I got the
Error 25 error message.

Is there a way to prevent the temporary hang (detecting > 137GB situation) and issue more friendly warning?

By the way, at 120 GB test, of course no more hang, and I got:

Partition num: 0, Filesystem is ntfs, partition type 0x07

 Partition num: 1, active, Filesystem is ntfs, partition type 0x07

[was_jaclaz]

128 GiB, 137 GB :
http://www.pcguide.c...izeGB128-c.html

jaclaz

[ktp]

Oh, so a PC with 2 giga bytes of RAM (2x1024x1024x1024 bytes) must be written as 2 GiB RAM or 2 GB RAM ? Or in all current documentations, I only see 2 GB RAM mentioned.
http://en.wikipedia.org/wiki/Gigabyte
http://en.wikipedia.org/wiki/GiB

[was_jaclaz]

Put the blame on HD manufacturers, a few years ago they "tweaked" the 1024x1024x1024 to 1000x1000x1000 to make their products appear larger.

I personally refuse to comply to "standards" that are not used by anyone but those that wrote the same standards, and it is at least curious that the JEDEC

continues to recognize the definition of 1024^3 bytes solely in the context of semiconductor storage capacities

as any USB stick that you find (the most common example of semiconductor storage you can find) has on it's package, in large friendly letters, 1, 2 or 4 GB, whilst theactual capacity is in powers of 1000 and not of 1024.

jaclaz

[tinybit]

You are right of course. But since I install grub4dos in MBR, grub4dos MBR code tries to find gldr in specific locations of each partition (root, /boot). This is why we see the sequence Trying (hd0,0), trying (hd0,1) etc... so grub4dos does care about partitions. I would hope that grub4dos code could handle that (since it understands NTFS4/NTFS5).

Remember grub4dos uses BIOS to access drives. If BIOS cannot run farer than 137km, then grub4dos cannot run that far, either.

The hang occurs after the Partition num:1 line, then after a relative long time (I would reboot otherwise), I got the
Error 25 error message.

Is there a way to prevent the temporary hang (detecting > 137GB situation) and issue more friendly warning?

I am afraid No. GRUB4DOS uses bios to access disks. It is BIOS who caused the hang. It is hard to gain a solution.

[was_jaclaz]

@ktp

something to experiment with:
http://technet.micro...y/cc784391.aspx

http://technet.micro...y/cc778290.aspx

Ultradefrag has an "exclude by filename" filter:
http://www.themadfat...ag-alternative/
http://www.defragsof...ltradefrag.aspx
http://ultradefrag.sourceforge.net/


jaclaz

[ktp]

@jaclaz

Thank you for the links. In fact the problem is not to defrag (I can defrag and verify with contig.exe from Sysinternals). The problem is to put the desired files at physical start location of the hard disk

Finally I have an idea: use a partition manager like PartedMagic, Acronis Disk Director etc... to shrinh the partition at the left, then reexpand it to original size. Then copy the grldr, menu.lst etc... to the root of this disk. This should work, I will try this.

Edit: unfortunately, it does not work. Only the method of small partition at beginning of the hard disk can guarantee that it works and continues to work with future updates of the file.

[was_jaclaz]

ktp
files do not "move" by themselves.

They move either:
1) if the drive is defragged and for any reason the files are in a non-contiguous area AND there is not enough "slack space" to allow for them in one single fragment
2) if the file is overwritten by a new, LARGER version AND there is not enough "slack space" thus the file is written in two or more fragments (of which the first one stays where it was originally.

If you use directories, newly added files should not get to the first part of the hard disk.

As an example, if you create five "dummy" files, each, say, 1 Mb in size naming them:
NTLDR
NTDETECT.COM
BOOT.INI
grldr
menu.lst

and copy them in this order to the hard disk, then you copy all the other files, then you replace each "dummy" file with the "real" one, you have the possibility to later overwrite the same files with bigger versions (up to the given 1 Mb size) and they won't be moved.

Of course if you add a number of small files to ROOT of the drive or DEFRAG it, without having a way to exclude those files from defragging or without a way to place them in a given position, this "plan" is deemed to failure.

Tools from here:
http://www.partition...m/utilities.htm
can be used to verify where a file actually is, but I don't semm to remember a program capable to "place" a file at a given (CHS or LBA) address.

jaclaz