35 replies to this topic

[small1024]

Hi everyone

I have to find few tag files.
All my tag files are placed at the root of a partition.
The search instructions look like this:

echo some_file_1       %@time%
find --ignore-floppies --ignore-cd /some_file_1.tag

echo some_file_2       %@time%
find --ignore-floppies --ignore-cd /some_file_2.tag

echo some_file_3       %@time%
find --ignore-floppies --ignore-cd /some_file_3.tag

echo some_file_4       %@time%
find --ignore-floppies --ignore-cd /some_file_4.tag

echo end               %@time%

The displayed times look like this
13:07:14
13:07:47
13:08:18
13:08:50
13:09:23

2 minutes 9 secondes every time i boot is a long delay in my book.
The delay for each find instruction has a "constant" average time of 32 secondes.

The places where i expect to find the tags are on:
USB stick    8 GB
HDD        931 GB
HDD        931 GB
HDD         78 GB

To reduce this waiting/wasting time, i will make loops with
if exist (hdx,y)/some_file_z.tag
Unless someone has a better alternative

good day

p.s.
set /a grub_version = *0x8278 & 0xFF && echo gv %grub_version%
gives
gv 157

 

[steve6375]

Hi

I have seen the same problem.

I think you may find it is the USB stick that is causing the problem.

I found that this would happen on every alternate boot but never got to the bottom of why! On another occasion it happened on a fresh boot every time.

I found that an ls (hd0,0)   (where hd0,0 is the flash drive) also gave a long delay the first time and if it was then followed by a find command it did not take a long time.

 

If you reformat the USB stick, I think you will find the problem goes away.

 

I was waiting for my USB stick to get in this state again and was then going to investigate further but it hasn't done it since!

HTH

 

P.S. Here is the code I used to try to get rid of the problem (as I say, I haven't seen the problem since I put this code in).

 

echo -n Looking for /WINHELPER.USB
root (bd) > nul && echo -n .
ls (bd)/_ISO/E2B/ > nul && echo -n .
ls (hd0,0)/_ISO/E2B/ > nul && echo -n .
ls (hd0,0)/WINHELPER.USB > nul && echo -n .
ls (hd1,0)/WINHELPER.USB > nul && echo -n .
ls (hd2,0)/WINHELPER.USB > nul && echo -n .
ls (hd3,0)/WINHELPER.USB > nul && echo -n .
echo
find --devices=h --set-root /WINHELPER.USB > nul 

[Wonko the Sane]

@Steve6375
I don't get it , doesn't just the last command set root?
(I mean, does the various ls's summed to the find --devices=h summed together tale less time than just the find --devices=h)?

@small1024:
http://reboot.pro/to...e-2#entry171589

you may want to try the "if exist" on the list of available hard disk partitions.


Wonko

[steve6375]

@Steve6375
I don't get it , doesn't just the last command set root?
(I mean, does the various ls's summed to the find --devices=h summed together tale less time than just the find --devices=h)?

Wonko

 

The original problem was that sometimes the find --set-root command took several minutes.

Something strange was happening because after that delay, any further find command did not have any problems - but if I rebooted, the delay came back again.

Also, I never had this long delay problem when I used the find command later on in my E2B menu system - it only started when I put it in the first menu.lst.

So my thought was that 'something' was clearing the problem before it got to the find command.

So I started to put other commands like root and ls in front of the find command.

I found that an  ls (hd0,0)/ command also caused this 'hang' on occasion too.

The sequence that I posted is one that is in E2B now. It prints dots after each command so that if anyone complains of the same problem, I can tell by the number of dots where it had the problem.

However, since I put this sequence of commands in, I have not seen the problem again and no one has reported a similar issue!

[steve6375]

Of course, this could be a different problem and maybe there are just lots of files in the root of all the drives?

[Wonko the Sane]

Of course, this could be a different problem and maybe there are just lots of files in the root of all the drives?

Yes, this could be, of course ls or DIR even on a "full" OS does take different times depending on the amount of files/directories in ROOT, but if that is the cause, it should be easily reproducible from what you and small1024 describe it seems more like a "quirk" of some kind.

Also, a current grub4dos should have already (embedded):

 

title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst
errorcheck off
configfile /boot/grub/menu.lst
configfile /grub/menu.lst
if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff
if "%@root:~1,1%"=="f" && 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

so at least one find --set-root (unless menu.lst is in /boot/grub or /grub/ ) is executed before you get to the menu.lst anyway, wouldnt' it also slow down the booting?

 

Wonko

[tinybit]

Why?

 

Because your (hd0) of USB is not LBA-accessible. Confirm it with "geometry (hd0)".

 

Grub4dos will take a so-called geometry-tune step to gain the correct geometry, if the device has only CHS-mode disk accessibility.

 

The geometry-tune process will take some time. This causes the delay. It should happen only at the first time you try to access the CHS-only disk.

 

A CHS-only disk is a non-LBA disk.

[steve6375]

Thanks for the clue, but the flash drive was formatted in the same way as always and perfectly readable by Windows (no chkdsk errors), etc. but there was something about it g4d didn't like.

If it happens again I will look at the geometry command.

Could it be that we are using large HDDs (I had a 2TB USB drive + a flash drive) and the BIOS USB code has a 137GB limit  (which I know my test rig - an EeePC, does have)?

[Wonko the Sane]

Why?

 

Because your (hd0) of USB is not LBA-accessible. Confirm it with "geometry (hd0)".

 

Grub4dos will take a so-called geometry-tune step to gain the correct geometry, if the device has only CHS-mode disk accessibility.

 

The geometry-tune process will take some time. This causes the delay. It should happen only at the first time you try to access the CHS-only disk.

 

A CHS-only disk is a non-LBA disk.

I see , but that - as said if the menu.lst is in ROOT - should happen when the menu.lst is searched first time by the embedded menu and so later find --set-root should be all "fast".

 

The "CHS only" does not stand for anything bigger than around 8 Gb (which is the CHS limit).

The 137 Gb limit is LBA28 vs. LBA48.

 

Wonko

[tinybit]

@wonko

 

I suspect the reporter was using an old buggy grub4dos version, or the default preset-menu was altered.

[tinybit]

Could it be that we are using large HDDs (I had a 2TB USB drive + a flash drive) and the BIOS USB code has a 137GB limit  (which I know my test rig - an EeePC, does have)?

 

If you try to access sectors out-side the BIOS limit, it could

 

1. hang up the machine.

2. fail with long delay.

3. immediately fail without long delay.

 

This will happen every time you try to access the same sector(s).

 

If the long delay happens only once, then it is likely because of a geometry tune process.

 

 

I have just noticed the reporter encountered long delay for each find. So it is not related to geometry-tune.

 

Must avoid accessing sectors out-side of BIOS limit.

[small1024]

Hi everyone

I realy appreciate all you interventions. I feel HONORED.
Here is what i did since my initial post.

I have applied the suggestion of Wonko.
@small1024:
reboot.pro/to...e-2#entry171589

The list of available hard disk partitions come on real fast (less than a second).
I thought that checking my 4 tags 1 by 1 would also consume an infinitesimal time.

Nope. The best i came up was 4 similar instructions inside the loop.

if not exist var_tag_1 if exist %volume%/some_file_1.tag > nul && set var_tag_1=%volume% && goto :loop
if not exist var_tag_2...
where volume is made with dev%n%

This time i have 32 seconds of waiting time for the entire loop (4 tags checking).
Then i remenbered steve6375. He had better result on a find if he used ls instruction before.
So i changed the instructions for:

if not exist var_tag_1 ls %volume%/some_file_1.tag > nul && set var_tag_1=%volume% && goto :loop

Result. 32 seconds again for the entire loop.

This is the best i went so far. Not bad. Instead of waiting 2 min. 9 sec.
Now it is 32 seconds. Not perfect but much more acceptable.

Well geometry is another ball game.

Don't know much about it.
For the USB stick. geometry gives.

drive 0x80(LBA): C/H/S=958/255/63, Sector Count/Size=15390270/512
Partition num: 0, active, Filesystem type is fat, partition type 0x1c

And geometry --bios gives:

drive 0x80(LBA): C/H/S=957/255/63, Sector Count/Size=15374205/512
Partition num: 0, active, Filesystem type is fat, partition type 0x1c

So i went geometry --tune followed by geometry --sync with:

drive 0x80(LBA): C/H/S=958/255/63, Sector Count/Size=15390270/512
Writing MBR for drive 0x80 ... success.
Partition num: 0, active, Filesystem type is fat, partition type 0x1c

So --bios and HDD give different sound even after --sync
I suspect that if i do the same for my hard discs, results will be similar.

I followed all your suggestions the best i could.
The waiting time have been reduced significantly.

All i want to say is THANK YOU ALL !!!
If you think of something else. Be sure that i will listen.
Thanks again.

[tinybit]

@small1024:

C/H/S=XXX/255/63 and C/H/S=YYY/255/63 are considered the same. 

Grub4dos will simply ignore the "Cylinders" value and "total sectors" value.

They can be any value, no difference, no problem. So no need to do --sync for them.

It is very important your geometry gives "(LBA)".

This can preclude the possibility of long-delay by geometry-tune.

 

Then, what have caused the delay of 32 seconds?

 

I guess you might have accessed sectors exceeding your BIOS limit, somehow or other.

 

If you are interested, you may do these tests at the "grub> " prompt:

 

 

cat  --hex  (hd0)0+1
cat  --hex  (hd0)10+1
cat  --hex  (hd0)100+1
cat  --hex  (hd0)1000+1
cat  --hex  (hd0)10000+1
cat  --hex  (hd0)100000+1
cat  --hex  (hd0)200000+1
cat  --hex  (hd0)300000+1
cat  --hex  (hd0)400000+1
cat  --hex  (hd0)500000+1
cat  --hex  (hd0)600000+1
cat  --hex  (hd0)700000+1
cat  --hex  (hd0)800000+1
cat  --hex  (hd0)900000+1
cat  --hex  (hd0)1000000+1
cat  --hex  (hd0)2000000+1
cat  --hex  (hd0)3000000+1
cat  --hex  (hd0)4000000+1
cat  --hex  (hd0)5000000+1
cat  --hex  (hd0)6000000+1
cat  --hex  (hd0)7000000+1
cat  --hex  (hd0)8000000+1
cat  --hex  (hd0)9000000+1
cat  --hex  (hd0)10000000+1
cat  --hex  (hd0)20000000+1
cat  --hex  (hd0)30000000+1
cat  --hex  (hd0)40000000+1
cat  --hex  (hd0)50000000+1
cat  --hex  (hd0)60000000+1
cat  --hex  (hd0)70000000+1
cat  --hex  (hd0)80000000+1
cat  --hex  (hd0)90000000+1
cat  --hex  (hd0)100000000+1

 

See which one would cause a long delay( or even a hangup).

[Wonko the Sane]

Result. 32 seconds again for the entire loop.
 

Which is a much better result compared to the initial one, good result, but still seemingly too slow.

Can you try (same setup) with (looping through the devices found with find --devices=h ) something like:

 

 

root %volume%

ls /var_tag_1 && echo var_tag_1 found on %volume%

and:

 

 

ls %volume%/var_tag_1 && echo var_tag_1 found on %volume%

Wonko

[small1024]

Excellent suggestion Wonko. You made me play the custom border officer.

Here is my actual loop
 

!BAT
set skip=0
# No warnings nor comments in our list of partitions/volumes
debug normal
find --devices=h > (md)0x20A+6
echo debut %@time%
call :loop
echo end %@time%
pause
goto :eof

:loop
cat --locate=\x0a --number=1 --skip=%skip% (md)0x20A+6 > nul || exit

# ? Means offset to reach begin of substring. Here 0x0a (end-of-line).
set /a length=%?%-%skip%

cat --skip=%skip% --length=%length% (md)0x20A+6 | set volume=
set /a skip=%length%+%skip%+1

echo We are now servicing %volume% %@time%

parttype %volume%
rootnoverify %volume%
echo Offset =================================
read 0x82AC
read 0x82A8
echo Length =================================
read 0x82B4
read 0x82B0

# Line added because the INTRUDER GET CAUGHT
if "%volume%"=="(hd2,4)" goto :loop

if not exist var_tag_1 if exist %volume%/some_file_1.tag && set var_tag_1=%volume% && goto :loop
if not exist var_tag_2 if exist %volume%/some_file_2.tag && set var_tag_2=%volume% && goto :loop
if not exist var_tag_3 if exist %volume%/some_file_3.tag && set var_tag_3=%volume% && goto :loop
if not exist var_tag_4 if exist %volume%/some_file_4.tag && set var_tag_4=%volume% && goto :loop

goto :loop

Believe it or not. Now my boot time is instantaneous. NO WAITING TIME !

My hard disk has a size of 1 TB and is divided like this.
PrimaryPartition1 (hd2,0) + PrimaryPartition2 (hd2,1) + ExtentedPartition.
The ExtentedPartition is made of LogicalDrive1 (hd2,4) + LogicalDrive2 (hd2,5).
The first 3 offsets can be obtain from the MBR. The MBR itself has room for 4 entries. When the ExtentedPartition
starts all LogicalDrive offsets are king of daisy chained. From there, offsets must be accessed (disk activities)
then extracted. The access to LogicalDrive1 takes 32 seconds (with Grub4Dos) while access to LogicalDrive2 is less
than 1 second. Why ? I don't know. But i can CONFIRM these times because of the line.
echo We are now servicing %volume% %@time%

The first 2 primary partitions are for Windows 7 while LogicalDrive1 is for Data and LogicalDrive2 for Backups.
When i watch a video (saved in LogicalDrive1) the movement is fluid, no jerky nor irregular sequences.
I ran chkdsk /f /r /b and Windows doesn't complain about anything. So i don't feel at risk with the bypass of (hd2,4).

Thank you Wonko. I wouldn't have discovered it nor corrected it without your loop.
Thanks again.

Now can you show me how to mark this thread as *solved* plz. Or this task has to be done by a REAL officer ?

[steve6375]

Where does each partition start? Is the extended partition after 137GB and the others before that?

[Wonko the Sane]

Good.

One could divide the loop in two "subsets" one looking only for devices of the type (hdm, n) where n <=3 and ONLY if the tags are not found, then loop through devices where where n >=4.

This way in most cases the find and boot will be fast, whilst if you really-really want to look for a tag on a logical volume inside extended, you wait a few seconds.

 

Wonko

[small1024]

The lengths of partitions are (100 MB, 78 GB, 200 GB, 400 GB).

So the barrier of 137 GB appears only in the data. Nothing to boot from.
Beside i feel that i could install new OS (no need for now). After the 4th partition well above the said barrier.
My 2 cents perception is that only an access to the first logical drive is time consuming.
Access to all logical drives above the first is fast. I can be wrong. But if not, you can install as much OS you
want. Just don't install them in the first logical drive. That has to be proven/tested.

From my perception Grub4Dos can offer to boot from extended partition with no delay.
Extracting these offsets is not time consuming at least with ntfs and LBA.
On the other hand, developers do this on their personal time. They do deserve vacation like every one.

Like Wonko said. We now have a fix/patch. And the choice to wait or not. I feel happy with that.

With this last note, i want to share something with members who participate in this thread (and viewers as well).

I want to offer wallpapers. They are really slick and they will make you feel being part of the future.

Some thing like year 4000 or so. The link conduct to Window's 7 theme. You can install the theme. 

I didn't, just extracted the images with 7-zip and applied/added them to my current theme.
Here is the link from Microsoft. Happy projection.

[steve6375]

Could you try tinybits test and report back please?

We still don't know what is causing this.

[small1024]

The test of tinybit was made for a usb stick.

He didn't know at that time where the problem was.

 

I changed (hd0) to (hd2) and inserted a "clear" instruction in between each "cat". 

Otherwise it scrolls for ever.

All i had was 20 something blinking screens.

None has showed any delay.

 

[steve6375]

What do you mean by 'all I had was 20 something blinking screens' when you also say that it 'scrolls forever'?

Scrolls with what? What text is displayed to make it scroll?  tinybit meant you to type each command in individually so you could see what messages you got (or put a pause between each one so you can see any error messages).

 

So can you summarise what grub4dos commands have this long delay and on what partitions they do it on, and which commands do not have a long delay?

 

I am asking because for anyone who is trying to produce a grub4dos 'solution', we want it to work properly on all types of hardware and so we need to understand what the problem is exactly and what is causing it and if we can fix it within grub4dos (or if it is a BIOS problem), etc.

Thanks

Steve

[Wonko the Sane]

Maybe something like this would do:

 

 

 

!BAT
set /a min=1 > nul
set /a max=100000000 > nul
set /a now=%min% > nul
:loop
cat --hex (hd0)%now%+1 > nul && echo %now% %@time%
set /a now=10*%now% > nul
if %now%==%max% goto :eof
goto :loop

 

Wonko

[steve6375]

I have a strange 'timing' issue with a file too. I will start a new thread though. Maybe tinybit can look at it with me?

[small1024]

We can fight over scrolling and blinking but we will loose are energy.
We both want to make Grub4Dos a better tool if we can.

@steve6375
Let me resume the test of tinybit. Display full sectors of information.
All sectors are base on hd0. Which in my case is a usb stick of 8 GB.
The first line is to display the MBR sector.
cat --hex (hd0)0+1
While the last line is to display the sector at 47 GB
cat --hex (hd0)100000000+1
Which is pure nonsense for a usb stick of 8 GB.
Even if we display such a sector on the hard disk hd2.
47 GB is somewhere in the 2th primary partition.
The problem is simply not there.

@tinybit
You have proposed something to find the problem early in the process.
This is proactive attitude and i like it.

@Wonko
You can't resist to propose innovative solution.
I also like it.

@all
The problem is the following. If an instruction try to access
a file that doesn't exit in the first logical drive, there is a
waiting delay of 32 seconds before the next instruction.

I don't have any tag file in my "data" partition. So

if exist (hd2,4)/some_file_x.tag || echo "not found"
ls (hd2,4)/some_file_x.tag || echo "not found"
find --devices=h /some_file_x.tag || echo "not found"

Each of these instruction return only after

a delay of 32 seconds with a "not found" result.

The led for disk activity is on during those 32 seconds.

The PBR sector of (hd2,4) can be displayed with no problem no delay with.
cat --hex (hd2,4)0+1
or
cat --hex (hd2)163844096+1

[steve6375]

So how many files are in the root of (hd2,4) and is it NTFS?

 

P.S. What does  ls (hd2,4)/   do?