Jump to content











Photo
- - - - -

Booting BartPE from Grub4Dos bootlaced to a second disk


  • Please log in to reply
9 replies to this topic

#1 Kirkx

Kirkx

    Member

  • Members
  • 31 posts
  •  
    Canada

Posted 25 January 2015 - 12:06 PM

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.


#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7071 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 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?



#3 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 January 2015 - 01:19 PM

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)"? :dubbio:

 

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 :w00t: :ph34r:

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

If I get it right :unsure: 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.

 

:duff:

Wonko 



#4 Kirkx

Kirkx

    Member

  • Members
  • 31 posts
  •  
    Canada

Posted 25 January 2015 - 03:10 PM

 

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.


#5 steve6375

steve6375

    Platinum Member

  • Developer
  • 7071 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 25 January 2015 - 03:27 PM

No! I said

at the very top of the menu


#6 Kirkx

Kirkx

    Member

  • Members
  • 31 posts
  •  
    Canada

Posted 25 January 2015 - 04:59 PM

Booting command-list

Filesystem type is ntfs, partition type 0x07

Document\ and\ Settings, ...



#7 steve6375

steve6375

    Platinum Member

  • Developer
  • 7071 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 25 January 2015 - 05:17 PM

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?



#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 January 2015 - 05:17 PM

Good. :thumbsup:

By applying some  form of (light) torture :w00t: :ph34r: 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 :unsure:, re-reading it I am not too sure I managed to explain myself.

 

:duff:

Wonko



#9 tinybit

tinybit

    Gold Member

  • Developer
  • 1157 posts
  •  
    China

Posted 27 January 2015 - 03:04 AM

Perhaps, it is probable, BOOT-US destroyed something in someway.

The something and someway may include: Interrupt vector table, BIOS data area, Extended BIOS data area, or made a mistake in its own int13/int15 handler.

#10 Kirkx

Kirkx

    Member

  • Members
  • 31 posts
  •  
    Canada

Posted 29 December 2018 - 03:19 PM

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.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users