Jump to content











Photo
- - - - -

Finding current drive for partnew


Best Answer steve6375 , 10 July 2021 - 07:10 AM

If you don't mind the risk of changing the MBR partition table of any drive in the system, then after the find --set-root  command you can %@root% to find the drive that the file was found on

assuming no more than 10 drives in the system and assuming root was set to hd1 by the find command...

 

set rd=%@root:~1,3%

will give you  rd=hd1

or

set rd=%@root:~3,1%

will give you rd=1

 

bear in mind that if the new partition at (hdx,3) is given a partition type number by the partnew command (not 0), the whole disk will no longer be UEFI-bootable because the partitions will be out-of-order!

 

P.S. you could use this in case more than 10 drives

set rd=%@root:~3,1%

if "%@root:~5,1%"=="," set rd=%@root:~3,2%

Go to the full post


  • Please log in to reply
16 replies to this topic

#1 Al Gorithm

Al Gorithm

    Member

  • Members
  • 32 posts
  •  
    Canada

Posted 09 July 2021 - 11:59 PM

On one system, GRUB4DOS is installed on the second logical partition of the second hard drive (hd1,5).  Given a menu entry such as this:

 

title SystemRescueCD
set ISO=/iso/systemrescue-8.03-amd64.iso
find --set-root %ISO%
parttype (hd0,3) | set check=
set check=%check:~-5,4%
if %check%==0x00 partnew (hd0,3) 0x00 %ISO%
if not %check%==0x00 echo ERROR: Partition Table entry 4 already exists! && pause --wait=3 && configfile /grub/menu.lst
map %ISO% (0xff)
map --hook
root (0xff)
chainloader (0xff)

when the menu entry uses:

parttype (hd0,3) | set check=

and
partnew (hd0,3) 0x00 filename

the error message is that the file must be on the same drive.

 

Using:

parttype (hd1,3) | set check=

and
partnew (hd1,3) 0x00 filename

succeeds.

 

The question is:  rather than hard-coding the drive number, how can G4D determine the current drive and use it in those two commands, so that the same menu entry can succeed when booted from different drive numbers (eg. on one system, G4D is on hd0, on another system G4D is on hd1, on another system it may booted from a USB which may be hd2, etc.)?

 



#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 10 July 2021 - 07:10 AM   Best Answer

If you don't mind the risk of changing the MBR partition table of any drive in the system, then after the find --set-root  command you can %@root% to find the drive that the file was found on

assuming no more than 10 drives in the system and assuming root was set to hd1 by the find command...

 

set rd=%@root:~1,3%

will give you  rd=hd1

or

set rd=%@root:~3,1%

will give you rd=1

 

bear in mind that if the new partition at (hdx,3) is given a partition type number by the partnew command (not 0), the whole disk will no longer be UEFI-bootable because the partitions will be out-of-order!

 

P.S. you could use this in case more than 10 drives

set rd=%@root:~3,1%

if "%@root:~5,1%"=="," set rd=%@root:~3,2%



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 July 2021 - 07:29 AM

In the first part of your menu.lst entry you look for the %ISO% *everywhere* AND establish root to it:

find --set-root %ISO%

 

After the root has been established, the:

root

command will show current root (i.e., example, (hd1,5)). 

 

You can get the output of the command and put it in a variable, then parse it, just like you do for the %check%, something like:

root | set myroot=

set mydisk=(%myroot:~-1,3%)

set mydisk

pause

 

 

The above is FAR from being "perfect" as it wont work for disks higher than (hd9) and it doesn't check that the device is actually a hard disk.

 

The latter can be easily "fixed" by using:

find --set-root --ignore-floppies --ignore-cd %ISO%

 

that will only look on hard disk like devices

 

For the former (though it is a rare case to have more than 10 disks on a system AND have the bootable .iso on one of them) you would need some more complex parsing/checking of the string.

 

Probably a good method would be using call Fn.11 to get the position of the comma), i.e.:

call Fn.11 "(hd0,0)" ","

echo %@retval%

3838064

 

 

call Fn.11 "(hd10,0)" ","

echo %@retval%

3838065

 

  :duff:

Wonko

 

P.S.: Ooops, cross-posting with Steve, that was faster than myself and used more directly the @root built-in variable  :thumbsup:



#4 Al Gorithm

Al Gorithm

    Member

  • Members
  • 32 posts
  •  
    Canada

Posted 10 July 2021 - 07:00 PM

Thank you both for your concise, helpful answers!  I know that there are guys with servers having ten or more disks, but I've not come across that in my personal experience.  Still, I might just use the extra parsing for safety sake.  And of course skip checking of CD's and floppies.

 

In my example above, I believe the partition type is being set to 0, so that it should not affect UEFI booting?  And with the checking for in-use partition in place, I don't see too much risk in using the (empty) last MBR partition entry on any particular disk.  Is that a reasonable assumption, or are there other caveats that I should be aware of?



#5 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 10 July 2021 - 07:45 PM

0 means autodetect - if the file is an ISO then you should be safe.

If the file is an img or vhd then the type will probably be changed.

of course the disk could be MBR or GPT...



#6 Al Gorithm

Al Gorithm

    Member

  • Members
  • 32 posts
  •  
    Canada

Posted 10 July 2021 - 08:00 PM

Okay, so here is the entry so far:

 

title SystemRescueCD\nSystemRescueCD 8.03.\n\n\nPress arrows to highlight; ENTER or b to boot; e to edit; c for command-line.
set ISO=/iso/systemrescue-8.03-amd64.iso
find --set-root --ignore-cd --ignore-floppies %ISO%
set rd=%@root:~1,3%
if "%@root:~5,1%"=="," set rd=%@root:~1,4%
parttype (%rd%,3) | set check=
set check=%check:~-5,4%
if %check%==0x00 partnew (%rd%,3) 0x00 %ISO%
if not %check%==0x00 echo ERROR: Partion Table entry four already exists! && pause --wait=3 && configfile /grub/menu.lst
map %ISO% (0xff)
map --hook
root (0xff)
chainloader (0xff)

This should be fine as long as the disk is MBR, and the file is ISO?  If the file is some other type, the partition type could be changed.  In that case, it would be nice to set it back to 0 when done, but I doubt that that could be accomplished automatically?

 

The filename could be tested to see if it ends with ".iso", but that doesn't necessarily mean that it is and ISO file; though the test might add some safety.

 

If the disk were GPT... well, I have no experience with such.  Would the ISO still boot correctly?  And if it did, and if we only allowed ISO files (meaning that the partition type would remain 0?), then it should be safe?

 

Otherwise, is there a way to test, so that we only allow it to boot when the disk is MBR?



#7 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 11 July 2021 - 07:58 AM

On MBR environment there are usually no GPT partitions, (so they are an extremely rare exception).

 

GPT partitions are present always on UEFI environments where booting from internal HD your grub4dos 0.46a by means of bootmanager + grld.mbr DO NOT work.

 

So all is safe and you should not worry.

 

alacran



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 July 2021 - 08:06 AM

The point, as always, is about how much "safe" or "foolproof" you want the solution to be and what you actually want to achieve/your setup.

 

By definition:

1) The MBR is the first absolute sector of a disk on BOTH MBR and GPT disks
2) For BIOS booting the MBR contains (usually) boot code (up to first 440 bytes), a disk signature, the 4-entry partition table and end with the "magic bytes" 55AA
3) For GPT disk, the MBR is a "protective" MBR, it contains no code (all 00's), the disk signature (on NT systems) the 4 entry partition table with only the first entry populated with partition type 0xEE and addresses spanning the WHOLE disk, and end with the "magic bytes" 55AA

 

This said, there can be a number of "hybrid" MBR/GPT setups (which if you think about it may include also a GPT disk modified to write in 4th entry a .iso address with partition type 0x00), as an example you can write some boot code to a GPT "protective MBR" (in order to have it boot on BIOS machines) and/or write an additional entry to the partitin table (besides the 0xEE one) to have it access (still on BIOS) a given extent (file or partition).

 

So, if all you need is to exclude GPT disks from being affected (when booting in BIOS) by the running of that menu.lst entry (even if inside one of the GPT partition there is a .iso file corresponding to the find --set-root name), you can simply check that the first entry in the MBR partition table is NOT of type 0xEE.

 

parttype (hd0,0)

You will get something like:

Partition type for (hd0,0) is 0xEE.

 

The output of the above command can be parsed the "usual" way, i.e.:

parttype (hd0,0) | set mypt=

set myptype=%mypt:~-5,4%

 

 

Can GPT disks with one entry 0xEE that is not the first one?

Theoretically, yes.

 

So you might want to check all 4 partition entries, to be on the safe side.

 

:duff:

Wonko



#9 Al Gorithm

Al Gorithm

    Member

  • Members
  • 32 posts
  •  
    Canada

Posted 11 July 2021 - 09:14 PM

Thank you both; that is very helpful.  Earlier, I did investigate hybrid schemes, and decided against using them.  As of now, I do not have any GPT systems, though I envision that in the future it will likely be required.  So, the information you provided will help ensure that I don't trample on a GPT disk and make it unbootable.



#10 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 11 July 2021 - 10:09 PM

Thank you both; that is very helpful.  Earlier, I did investigate hybrid schemes, and decided against using them.  As of now, I do not have any GPT systems, though I envision that in the future it will likely be required.  So, the information you provided will help ensure that I don't trample on a GPT disk and make it unbootable.

 

In the future all Mother Boards will be UEFI only with no option to boot as CSM/MBR, as they are now many new OEM PCs, so the hybrid boot will be useless.

 

When the need arise it will be better to create with USB_FORMAT by wimb a USB device capable to boot on CSM/MBR and/or UEFI environments.

 

Or use Ventoy to create a USB device capable to boot directly, (no partnew required), on MBR/CSM and/or UEFI, hundreds of windows and Linux ISOs.   With the additional advantage that you do not need to create the config menus, it does all for you on the fly, creating a virtual CD/DVD device, and booting the selected ISO with the several preconfigured options.

 

alacran



#11 Al Gorithm

Al Gorithm

    Member

  • Members
  • 32 posts
  •  
    Canada

Posted 12 July 2021 - 12:19 AM

Yes, agreed.  Ventoy is excellent for a USB stick, and I have used and will use it when needed.

 

Up to this point, most of my posts and questions have been to do with G4D on a local HDD/SSD, since neither Ventoy nor E2B are designed for that purpose.  And most of my questions have been answered.

 

One funny little niggle:  using GRUB4DOS 0.4.6a, has anyone else noticed that it will not display the color 'brown'?  Whether in the menu, or in the console, it always displays brown as red (without generating an error)!  I've just noticed this on one system; I will test it also on another computer.



#12 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 12 July 2021 - 06:08 AM

How are you generating brown text?

#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 July 2021 - 11:44 AM

Al Gorithm, on 11 Jul 2021 - 11:14 PM, said:
Thank you both; that is very helpful. Earlier, I did investigate hybrid schemes, and decided against using them. As of now, I do not have any GPT systems, though I envision that in the future it will likely be required. So, the information you provided will help ensure that I don't trample on a GPT disk and make it unbootable.


Relax, don't worry.
The way UEFI works is the following (in theory) on GPT disks:
0) check if in the protective MBR there is one entry with type 0xEE starting on LBA 1
and/or:
1) check if on 2nd sector or LBA1 there is a GPT partition header
then:
2) check partitions/volumes (in GPT all partitions are primary, so volume=partition is an almost completely true equivalence) in the GPT partition table (that starts on LBA2) until it finds a volume that has an UUID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B (UEFI system partition)
3) find in it a suitable .efi bootloader/bootmanager (either with a pre-set name or getting it from NVRAM)
4) chainload this .efi bootloader/bootmanager

So, as long as you do not delete the 0xEE partiton entry in the protective MBR the GPT disk will remain bootable under UEFI.

This said, some firmwares (UEFI) when set with CSM enabled may switch to BIOS mode if they find something they don't like in the MBR, in these (I believe anyway extremely rare) cases the disk will fail boot because it is not booting in UEFI but rathewr attempting to boot in BIOS mode.

Only for the record/FYI, there are a couple ways (that you won't like as they are relatively complex to implement) that allow to make a GPT disk (normally bootable in UEFI) also bootable under BIOS to grub4dos in such a way that it will be "transparent", i.e. the protective partition table in the MBR is left untouched (unlike other "hybrid" solutions).

One way is the UMBR for grub4dos (that only writes some code to the code part of the MBR BUT that requires the grldr to be NOT moved in the filesystem) or my half-@§§ed "underfloppy" approach that writes both to the code part of the MBR and to the unused sectors before the first partition (placing there a copy of grldr).

:duff:
Wonko



#14 Al Gorithm

Al Gorithm

    Member

  • Members
  • 32 posts
  •  
    Canada

Posted 12 July 2021 - 07:46 PM

How are you generating brown text?

Both in the menu.lst with, eg.

color white/brown red/yellow brown/yellow brown/white
or at the console with, eg.

>color brown/black

 

In either case, no error is given, but everywhere where brown is expected, it is red instead.  Also in either case, using one of the other standard colours (blue, cyan, green, etc.) results in the correct colour.  Also, both the G4D guide and:

>help color

list brown as a valid colour.

 

I have tried this on two different machines with the same results.



#15 Al Gorithm

Al Gorithm

    Member

  • Members
  • 32 posts
  •  
    Canada

Posted 12 July 2021 - 07:53 PM

One way is the UMBR for grub4dos (that only writes some code to the code part of the MBR BUT that requires the grldr to be NOT moved in the filesystem) or my half-@§§ed "underfloppy" approach that writes both to the code part of the MBR and to the unused sectors before the first partition (placing there a copy of grldr).
 

That reminds me of some bootloaders that I have used in the past (long before UEFI).

 

Right now, everything (that I so far have need of) is working fine with G4D and a common menu.lst, both from USB and from a local HDD/SSD across three systems.  But looking toward the future, when my systems will be UEFI/GPT, what method can be used, in a similar manner, to boot ISO files from local HDD/SSD?



#16 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 12 July 2021 - 07:57 PM

Brown is a difficult colour. It is a mixture of RGB. The result depends on the graphics adapter, it's DAC output and the display device.

#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 July 2021 - 07:57 AM

That reminds me of some bootloaders that I have used in the past (long before UEFI).

 

Right now, everything (that I so far have need of) is working fine with G4D and a common menu.lst, both from USB and from a local HDD/SSD across three systems.  But looking toward the future, when my systems will be UEFI/GPT, what method can be used, in a similar manner, to boot ISO files from local HDD/SSD?

 

It makes very little sense to use a GPT disk on a BIOS system (though as said we do have a couple way outs for particular edge cases).

 

When you will have commonly GPT disks you will also have UEFI, and as such you won't have grub4dos anymore (which is BIOS only) and you will have to shift to grub4EFI (which is the "evolution" of grub4dos compatibel with EFI) or GRUB2 (or some other UEFI based/compatible bootmanager/bootloader).

 

And - as previously said elsewhere - a .iso does not "qualify" the *whatever* you want to boot:

http://reboot.pro/in...?showtopic=8944

most - if not all - Linux distro's/.iso's do have working "cheat codes" that allow to boot on BIOS with plainer grub4dos mapping and of course on EFI GRUB2 allows using the loopback device, and grub4efi and Ventoy have their own ways, so (hopefully) there will be no need of these partnew tricks.

 

:duff:

Wonko






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users