41 replies to this topic

[Wonko the Sane]

OT (and I mean really OT  but as always not tha t much ) it seems like some versions of grldr/grub4dos (possibly forked/modified) have an undocumented (AFAIK/AFAICU) switch:
http://www.911cd.net...ndpost&p=175857

hiddenmenu

title EaseUS Todo Backup Linux
find --ignore-cd --ignore-floppies --set-root --boot-magic=5B6AC646000000000000003F /BOOT/EASEUSBT.IDX
kernel /BOOT/EASLINUX.KNL root=/dev/ram0 rw vga=788
initrd /BOOT/EASLINUX.IRD

 

where the 5B6AC646 is the Disk Signature (reversed form what is actually written in the MBR, verified) and the 000000000000003F is (seemingly) the offset of the volume.

 

Anyone knows anything about it?

Does it exist within "normal" gruub4dos?

Anyone game for testing it?

 

Wonko

[steve6375]

root command executed as soon as you boot will tell you the boot device (assuming a normal embedded menu config file is used)

 

Though from my notes from here

Whatever device the /menu.lst file was found on, will be set to be the 'root' device and partition. So ls /  or  ls (bd)/  will always list the files on the root of the partition that contained the menu.lst that was found and loaded by grub4dos.

There are some variables here which you can get the boot drive (e.g 80h) from e.g. 

set /A BD=*0x8280&0xff
set /A CP=*0x829E&0xff

if the boot partition was hd0,2 then BD=0x80 and CP=2

 

CP will be the current partition though and will change if you change the root.

Does that help?

[DavidB]

OT (and I mean really OT  but as always not tha t much ) it seems like some versions of grldr/grub4dos (possibly forked/modified) have an undocumented (AFAIK/AFAICU) switch:
http://www.911cd.net...ndpost&p=175857

where the 5B6AC646 is the Disk Signature (reversed form what is actually written in the MBR, verified) and the 000000000000003F is (seemingly) the offset of the volume.

 

Anyone knows anything about it?

Does it exist within "normal" gruub4dos?

Anyone game for testing it?

 

Wonko

That's an interesting switch, I remember seeing it some time ago. At that time I didn't know what it does...

Unfortunately it doesn't seem to exist in the latest 0.45c/0.46a builds. I searched directly into grub4dos sources: found, for example, "--set-root" but not "--boot-magic".

[DavidB]

root command executed as soon as you boot will tell you the boot device (assuming a normal embedded menu config file is used)

 

Though from my notes from here

Whatever device the /menu.lst file was found on, will be set to be the 'root' device and partition. So ls /  or  ls (bd)/  will always list the files on the root of the partition that contained the menu.lst that was found and loaded by grub4dos.

There are some variables here which you can get the boot drive (e.g 80h) from e.g. 

set /A BD=*0x8280&0xff
set /A CP=*0x829E&0xff

if the boot partition was hd0,2 then BD=0x80 and CP=2

 

CP will be the current partition though and will change if you change the root.

Does that help?

 

Yes, it helps a little, thank you.

 

I started to use BD variable in my boot scripts. It's initialized with "(bd)" and it changes every time I use "map" command.

So when I try to read/write I use %BD%/file.

But that doesn't always work, for example when the user chooses "...Back to main menu (Grub4Dos)", previously started from the Windows 7 setup menu items (created by WinSetupFromUSB):

 

 

After this (bd) can't be accessed and "set BD=(hdn,0)" (n=0..4) isn't remembered.

[steve6375]

What if you do a 

map --status

are some drives mapped?

Why not unmap and unhook all drives first?

[DavidB]

What if you do a 

map --status

are some drives mapped?

Why not unmap and unhook all drives first?

 

Yes, 0 in 1 and 1 in 0.

You mean to do this after the user starts that menu item but before reloading the main menu?

[steve6375]

You can add it to the start of any menu

map --unhook
map --unmap=0x80:0xff

would unmap all hard disks and CDs

[steve6375]

P.S. You may need to do a  root (bd)  and unmapping can take some time (not sure why, can be 5-10 seconds in some cases)

[DavidB]

Yes, seems wise to add these at the start of each menu entry.
But there are 3 problems:

1. In some computer configurations the bd could be not 0x80;
2. Low speed;
3. It will still require a line like "find --set-root --devices=hf /usbdrive.tag | set BD=" which will slow it even more.
On the other hand I noticed "map --status" is very fast so it can be used to find if unmapping/unhooking is necessary. But it's not easy to make a simple, fast and stable code for interpreting the output result of "map --status".

 

Later edit

 

My first attempt:

!BAT

setlocal
map --status > (md)0x19100+16
cat --number=1 --locate="currently empty." (md)0x19100+16 | set EMPTY=
if exist EMPTY goto :notfound
cat --number=1 --locate="---\n" (md)0x19100+16 | set POSB=
if "%POSB%"=="" goto :notfound
set /a SKIPPED=0x%POSB%+4 > nul
cat --length=2 --skip=%SKIPPED% (md)0x19100+16 | set FNDMAPS=
set FNDMAPS=0x%FNDMAPS%
set /a SKIPPED=0x%POSB%+6 > nul
:loop
cat --skip=%SKIPPED% --number=1 --locate="\n" (md)0x19100+16 | set POSB=
if "%POSB%"=="" goto :end
set /a SKIPPED=0x%POSB%+1 > nul
cat --length=2 --skip=%SKIPPED% (md)0x19100+16 | set NEXTMAP=
if "%NEXTMAP%"=="" goto :end
set FNDMAPS=0x%NEXTMAP%:%FNDMAPS%
set /a SKIPPED=0x%POSB%+3 > nul
goto :loop
:end
map --unmap=%FNDMAPS%
map --unhook && map --rehook
:notfound
endlocal

[steve6375]

 

1. In some computer configurations the bd could be not 0x80;

 

?? the (bd) device can be obtained by reading the memory variable I already gave you

 

set BD=(hdn,0)" (n=0..4) isn't remembered."

 

 

If variables are not remembered when returning to another menu then something in the code is causing it to lose the variable.

.

setlocal may be used or maybe set *  ??

 

e.g.

setlocal
set BD=(hd0,3)
(do stuff =here)
endlocal
configfile /menu.lst

would lose the setting or if the menu.lst contains

set *

then all variables would be lost.

 

 

You can preserve specific variables and lose all others using

set * && set BD=%BD% && set CP=%CP%

or ([Edit - typo fixed - should be endlocal not setlocal!)

endlocal && set BD=%BD% && set CP=%CP%

Also beware that you only have about 60 variables to play with, so make sure you clean up any junk/temporary variables that you use when you have finished with them!

Edited by steve6375, 19 December 2014 - 11:47 AM.

[Wonko the Sane]

Still OT , and still on the same OT :

set myds=16 B4 ED 3D
cat --hex --skip=440 --length=4 (hd0)+1 | set ds=
if "%myds%"=="%ds:~10,11%" echo Disk (hd0) is the one

Wonko

[DavidB]

A little improvement:

!BAT

setlocal
map --status > (md)0x19100+16
cat --number=1 --locate="currently empty." (md)0x19100+16 | set EMPTY=
if exist EMPTY goto :notfound
cat --number=1 --locate="---\n" (md)0x19100+16 | set POSB=
if "%POSB%"=="" goto :notfound
set /a SKIPPED=0x%POSB%+4 > nul
cat --length=2 --skip=%SKIPPED% (md)0x19100+16 | set FNDMAPS=
set FNDMAPS=0x%FNDMAPS%
set /a SKIPPED=0x%POSB%+6 > nul
:loop
cat --skip=%SKIPPED% --number=1 --locate="\n" (md)0x19100+16 | set POSB=
if "%POSB%"=="" goto :end
set /a SKIPPED=0x%POSB%+1 > nul
cat --length=2 --skip=%SKIPPED% (md)0x19100+16 | set NEXTMAP=
if "%NEXTMAP%"=="" goto :end
set FNDMAPS=0x%NEXTMAP%:%FNDMAPS%
set /a SKIPPED=0x%POSB%+3 > nul
goto :loop
:end
map --unmap=%FNDMAPS%
map --unhook && map --rehook
find --devices=hf /usbdrive.tag | set BD=
:notfound
endlocal && set BD=%BD%

 AllBootFiles.7z   175.16KB   389 downloads

 

?? the (bd) device can be obtained by reading the memory variable I already gave you

 

Ok, but how can I use it to get the same result as "find --devices=hf /usbdrive.tag | set BD="? In any situation...

I ask because the memory variable is returning a number but I need a string for the path...

And I "see" too many if's....

 

Le: maybe something like (0x80,0)? Usualy I use (hd0,0), that's why I didn't think at the other one...

 

If variables are not remembered when returning to another menu then something in the code is causing it to lose the variable.

 

They are not remembered because grldr is loaded again, not because of setlocal/endlocal.

And I know about "endlocal && set BD=%BD%", I used it a year ago in my "Find & Boot script"...

But thank you.

[DavidB]

I just tried with this code:

!BAT

setlocal
map --status > (md)0x19100+16
cat --number=1 --locate="currently empty." (md)0x19100+16 | set EMPTY=
if exist EMPTY goto :notfound
cat --number=1 --locate="---\n" (md)0x19100+16 | set POSB=
if "%POSB%"=="" goto :notfound
set /a SKIPPED=0x%POSB%+4 > nul
cat --length=2 --skip=%SKIPPED% (md)0x19100+16 | set FNDMAPS=
set FNDMAPS=0x%FNDMAPS%
set /a SKIPPED=0x%POSB%+6 > nul
:loop
cat --skip=%SKIPPED% --number=1 --locate="\n" (md)0x19100+16 | set POSB=
if "%POSB%"=="" goto :end
set /a SKIPPED=0x%POSB%+1 > nul
cat --length=2 --skip=%SKIPPED% (md)0x19100+16 | set NEXTMAP=
if "%NEXTMAP%"=="" goto :end
set FNDMAPS=0x%NEXTMAP%:%FNDMAPS%
set /a SKIPPED=0x%POSB%+3 > nul
goto :loop
:end
map --unmap=%FNDMAPS%
map --unhook && map --rehook
set /A BD=*0x8280&0xff > nul
set BD=(%BD%,0)
:notfound
endlocal && set BD=%BD%

It's setting BD to (0x81,0) but it should set (0x80,0).

But with "find" works ok (although it's slow)...

[DavidB]

Sorry about "triple posting"...

 

Still OT , and still on the same OT :

set myds=16 B4 ED 3D
cat --hex --skip=440 --length=4 (hd0)+1 | set ds=
if "%myds%"=="%ds:~10,11%" echo Disk (hd0) is the one

Wonko

 

Thank you, Wonko.

Yes, it could work but the problem is it's not faster or more reliable than "find --devices=hf /usbdrive.tag | set BD="....

[Wonko the Sane]

Thank you, Wonko.

Yes, it could work but the problem is it's not faster or more reliable than "find --devices=hf /usbdrive.tag | set BD="....

Sure, but the scope is/was slightly different, this one allows to establish root to (or however *locate* or *identify*) a disk device, no matter what the contents of the filesystem(s) - if any - are, on *any* volume in the device, for all that matters as long as a disk has been "initialized" on a NT based system, it is identifiable.

If you prefer, it avoids the adding of a "usbdrive.tag" (which may - as an example - be accidentally deleted).

 

And - just for the record - the "tag file" should/could however (for advanced users) be replaced by uuid:

http://reboot.pro/to...d-in-this-code/

but it provides (just like the tag file would) the volume.

 

Hey , otherwise it would not have been an OT.

 

Wonko

[steve6375]

It's setting BD to (0x81,0) but it should set (0x80,0).

Odd?? What is *0x8280 on first boot (top of menu.lst)?

 

You say it chainloads  grldr to reload the main menu and so forgets all variables - how does it know the path to grldr? How does it find it?

Why does it need to reload grldr which then runs the embedded menu.lst which does 'find's which then loads \menu.lst - why not do your  find xx.tag anyway in that case? 

 

Why not copy the main menu into memory (md) and then reload the main menu from memory (after unmapping)?

If you ensure that the main menu starts with the  unmap commands, then it should work faster than trying to find a tag file?

 

I guess I don't understand enough about what your menu setup is really...

[DavidB]

It shows 0x80, as it should be, the problems appear after starting a few menus.

 

As I said, it's from the Windows 7 setup created with WinSetupFromUSB.
From the "mainmenu" file choose "Windows 7 SP1 setup (7)". It will load win7setup.lst.
Then choose "Windows 7 SP1 start setup". It will shift the USB drive with the internal HDD and it will load /bootmgr.
Finally, choose "Back to main menu (Grub4dos)". It will (re)load grldr.



At this point both if you try to shift the USB drive and the internal HDD to their original values with the script, the (bd) and the memory variable will both show wrong path.