Booting BartPE from Grub4Dos bootlaced to a second disk

I have BartPE installed on two disks, to (hd0,2) and (hd1,0). Both instances of BartPE boot ok but only if they are chainloaded from a primary partition on the first disk:

- BartPE installed on (hd0,2) boots ok when chainloaded from Grub4Dos bootlaced to (hd0,2)
- BartPE installed on (hd1,0) boots ok when chainloaded from Grub4Dos bootlaced to (hd0,2)
- BartPE installed on (hd1,0) will not boot when chainloaded from Grub4Dos bootlaced to (hd1,0):

Error 15: File not found

I have tried the following commands as suggested by Steve6375 on another thread:

title Bart PE & Grub4Dos on Hard Disk #2
hide (hd0,0)
hide (hd0,1)
hide (hd0,2)
unhide (hd1,0)
hide (hd1,1)
hide (hd1,2)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
# hd1 is now hd0   and  hd0 is now hd1
root (hd0,0) || rootnoverify (hd0,0)
chainloader (hd0,0)/minint/setupldr.bin

The "ls" command can be used for debugging:

.....
# hd1 is now hd0   and  hd0 is now hd1
root (hd0,0) || rootnoverify (hd0,0)
ls (hd0,0)/
pause
ls /minint/
pause
chainloader (hd0,0)/minint/setupldr.bin

Running "ls (hd0,0)/" command returns the contents of the "real" (hd0,0) and not the contents of (hd1,0), which indicates that disk mapping did not take place for some reason. As partition (hd0,0) does not contain:

/minint/setupldr.bin

the subsequent "chainloader" command fails with "Error 15: File not found".

I'm thinking about trying out "map --harddrives=N" command but I'm not sure how to properly implement it:

.....
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
# which value is correct, 0 or 1?
map --harddrives=0
map --harddrives=1

--------------------------------------
- BIOS: Phoenix version: 3.15, date 01/25/2007

- Disk #1: 500 GB with 4096 / e512 sectors, aligned to CHS

- Disk #2: 500 GB with 4096 / e512 sectors, aligned to 1 MiB

- MBR bootloader: Boot-US

- PBR bootloader: Grub4Dos v0.4.5c-2014-12-24 bootlaced to (hd0,2) and (hd1,0)

- BartPE installed on (hd0,2) and (hd1,0)

Edited by Kirkx, 25 January 2015 - 12:18 PM.

BartPE installed on (hd1,0) will not boot when chainloaded from Grub4Dos bootlaced to (hd1,0):

So what do you see if you do

ls /

ls (hd0,0)/

ls (hd1,0)/

root

pause

at the very top of of the menu?

It seems to me like there is something either missing or wrong or both.

I mean, when you boot, which device is set to boot in BIOS? (First hard disk, second hard disk,  something else)

What MBR has the device designated as boot device? (standard MBR, grldr.mbr, something else)

What do you EXACTLY mean by "Grub4Dos bootlaced to (hd0,2)"?

Bootlace may:

a. write to the disk MBR (+hidden sectors) the grldr.mbr (and in this case you may call this  "bootlaced" to (hd0) or to (hd1), etc. i.e. to a Disk - WHOLE device)

OR

b. create a special bootsector (on some file systems only) invoking grldr as "system file" (and in this case you may call this "bootlaced" to (hd0,0), (hd0,1), etc., i.e. to a partition/volume)

Apart from this, you seem to me (no offence intended ) to be unfortunately slipping on a chocolate covered banana

http://homepage.ntlw...red-banana.html

If I get it right from the other thread:

http://reboot.pro/to...tor-63-or-2048/

 the "final goal(s)" is/are to:

My setup is actually a bit complex because I have BartPE installed on (hd0,2) and on (hd1,0). With a properly designed "menu.lst" this alllows forcing BartPE to always assign drive letter C to the primary partition that you want to image. Also, when making a partition image you do it using BartPE installed on a different disk, not the one on which the imaged partition resides.

There is no real *need* to have two distinct BartPE's for this, and that has no particular advantage.

Of course you are perfectly free to make overly complex setups , but you should know that they are over complex.

To pre-assign a given drive letter to a given device, using a migrate.inf is simple and effective:

http://www.911cd.net...showtopic=19663

but since the "partiton to be imaged" is obviously not the "system" (or "boot" or viceversa) partition/volume, there are absolutely no issues in changing the drive letter assignments in PE after boot (say through a batch).

And if the scope is to make a partition image, there are no issues in running the BartPE from another volume partition on the same disk where the partition that needs to be imaged resides, and in case it would make much more sense to run a minimal BartPE entirely from RAM.

Wonko 

 

Wonko the Sane: Of course you are perfectly free to make overly complex setups, but you should know that they are over complex.

My setup is complex but it works perfectly when using Grub4Dos installed on any primary partition on the first disk. One day I might change it and make it more efficient using your suggestions about "migrate.inf", changing the drive letter, etc. Running BartPE from RAM won't work in this case, I have a plugin with a workstation version of Acronis (500 MB). At this point I'm just curious why BartPE won't boot from G4D installed on the second disk.

The boot sequence is as follows:

boot disk set in BIOS to (hd0) -> Boot-US in MBR of (hd0) -> G4D in PBR of (hd0,2) and (hd1,0)

Partitions (hd0,2) and (hd1,0) are bootlaced from Linux:

sudo ./bootlace.com --floppy=2 --ntfs /dev/sda3

sudo ./bootlace.com --floppy=0 --ntfs /dev/sdb1

 

Steve6375: So what do you see if you do ...

I placed two empty tag files in (hd0,0) and (hd1,0) to avoid any mistakes reading the output after running your commands:

(hd0,0): _tag-c1.txt
(hd1,0): _tag-c4.txt

The code below:

title Bart PE & Grub4Dos on Hard Disk #2
hide (hd0,0)
hide (hd0,1)
hide (hd0,2)
unhide (hd1,0)
hide (hd1,1)
hide (hd1,2)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
# hd1 is now hd0  and  hd0 is now hd1
root (hd0,0) || rootnoverify (hd0,0)
ls /
ls (hd0,0)/
ls (hd1,0)/
root
pause
chainloader (hd0,0)/minint/setupldr.bin

generates the following output (in a single line):

- folders and files from the real (hd0,0)
- folders and files from the real (hd0,0)
- folders and files from the real (hd1,0)

So it seems that the mapping did not take place.
 

Edited by Kirkx, 25 January 2015 - 03:13 PM.

No! I said

at the very top of the menu

Booting command-list

Filesystem type is ntfs, partition type 0x07

Document\ and\ Settings, ...

OK, last attempt.

Make a menu entry in menu.lst in the menu that does not currently seem to work

title test
echo ls
echo
ls /
echo
echo ls (hd0,0)/
ls (hd0,0)/
echo
echo ls (hd1,0)/
ls (hd1,0)/
echo
echo root
root
pause test complete!

Now fresh boot to the menu and run this entry.

Now the object of this test is to see what drives are currently hd0 and hd1 - maybe this menu will help you to answer that question?

Good.

By applying some  form of (light) torture  I managed to get from you the actual relevant info. (or very possibly I missed them earlier)

If you are booting from a "normal" MBR code and this has an "Active partition", the bootsector that bootlace created will be the one on the same "first boot device" and  chainload the specific grldr on the same partition, and the drive table will remain (until the menu.lst and it's overly complex provision are executed) the one that the BIOS created.

BUT you are using instead another "particular" bootloader/bootmanager/whatever "in the middle" the Boot-US, that may well make it's own changes/whatever, it is likely that the issue lies in this intermediate (and as well unneeded/over complex) step, i.e. a conflict of some kind between BOOT-US and grub4dos is possible, I would say probable.

Can you (at least temporarily) take the BOOT-US out of the equation?

I mean, when you say that "using BartPE installed on a different disk, not the one on which the imaged partition resides", this obviously applies to the BartPE and not to the grldr/grub4dos used earlier to chainload it, as soon as a setupldr.bin is chainloaded, the grub4dos/grldr "vanishes", or, if you prefer if you use a grldr residing on *any* disk/device and it correctly maps drives, it can chainload the setupldr.bin on *any* disk/partition, the "booted BartPE" will be the one depending on which setupdr.bin you chainload.

I hope I was clear in the above last paragraph , re-reading it I am not too sure I managed to explain myself.

Wonko

I will bump this old thread as I have found the resolution of the problem. It is actually very simple. In case anyone else has a similar setup, with Boot-US code installed in MBR and Grub4Dos code installed in Partition Boot Sector, please keep in mind that:

Boot-US automatically performs disk mapping when a primary partition on the second disk is selected for booting:

map (hd1) (hd0)
map (hd0) (hd1)

So obviously the "map" command should not be included in menu.lst of G4D and all device IDs need to be modified accordingly (also in files like Boot.ini, etc.)

For the record, the reason for using Boot-US in addition to G4D was to take advantage of its "true hiding" functionality, which is recommended on systems with multiple instances of Windows installed. Implementing "true hiding" natively in G4D was later discussed here:

http://reboot.pro/to...de-a-partition/

Edited by Kirkx, 29 December 2018 - 03:22 PM.