Jump to content











Photo
- - - - -

Chainboot other MBR boot device


  • Please log in to reply
7 replies to this topic

#1 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 20 August 2008 - 09:36 PM

s4e solved to split XP boot:
text mode boot phase is run from a hard disk image
boot device is changed to real hard disk
gui mode boot phase is run from a hard disk
http://www.911cd.net...showtopic=21242

At text mode boot phase windows remember a hard disk like device by MBR signature and a internal checksum.
At gui mode boot phase these infomation are used to detect boot device again.
Behaviour can be used to change boot device on the fly.

Examples:
boot from USB/Firewire HD without BIOS support
boot from Compact Flash card at PC Card adapter without BIOS support
boot from SD card at laptop without BIOS support
boot from USB stick with half broken BIOS (image and PE at the same device)

Text mode boot image has to load appropiate drivers for external devices.
Gui mode boot phase switch boot hardware next.

A more general boot description: Troubleshooting the Startup Process
http://technet.micro...y/bb457123.aspx

To accomplish chain boot real hardware has to contain a MBR:
USB hard disk, USB stick, CF card, SD card. Actually there is no limitation.

This approach is possible at setupldr.bin PE too.
Txtsetup.sif desribe early boot environment.

Of course loaded image has to contain required drivers.
E.g. use USB drivers, if you like to chain boot a USB device. That's enable USBSupport.Script at this example.

Thanks to jaclaz, default image was created with mkimg.cmd. http://www.boot-land...?showtopic=3191


This script prepare a hard disk image. Boot files are read from a PE %TargetDir%.
Hence use this hard disk image with this PE %TargetDir%.
Select a physical drive containing a MBR. Disk Management list drive number.
Select the same format for hard disk image and physical drive partition.
Integrate hard disk image, grub4dos grldr and menu.lst to a boot media.


@Galapo
I've difficulties to include this to LiveXP at boot CD.
A addional grub4dos boot option would be nice.

I understand:
Multiprocessor files are not copied at multiprocessor.script runtime.
CreateISO.script create a new menu.lst and Run,%multiprocessor_script%,CreateISO-%multiprocessor_section%.

Different approaches are possible:
multiprocessor.script copy files at multiprocessor runtime. And menu.lst is appended at CreateISO.script.
Or CreateISO.script build a new menu.lst. And run chainboot.script [Create_Add_menu_lst] and [multiprocessor].
Not tested, remember that's my first script.

What's your opinion? Do you adjust multiprocessor.script or CreateISO.script?

Atttachment updated 2008-Sep-02:

Attached Files



#2 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 20 August 2008 - 11:28 PM

Hi cdob,

Very, very interesting. I'll give this some on how to integrate. I'll get back to you. Firstly, though, a few comments:

I understand:
Multiprocessor files are not copied at multiprocessor.script runtime.
CreateISO.script create a new menu.lst and Run,%multiprocessor_script%,CreateISO-%multiprocessor_section%.

There's two options with the current multiprocessor script: a) mutiprocessor only; and b) both uni- and multiprocessor. In the case of a), files are copied on first run of script. In the case of b), option at boot needs to be provided, as you know, because of dumb setupldr which does not dynamically detect appropriate kernal outside of network boot. Because the project also provides other options of patching (I'm thinking here of the BootSDI option to patch setupldr so as to not have cab-compressed image use double amount of ram), patching for multiboot is left till the last possible moment since two instances of setupldr.bin and txtsetup.sif are generated.

I need to give this more thought, but my initial feeling is to adjust multiprocessor, bootsdi, and createiso scripts to work with a new script which would handle grub4dos menu input from previous scripts (eg multiprocessor.script, chainboot.script).

Regards,
Galapo.

#3 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 21 August 2008 - 06:39 AM

Hi cdob,

I've adjusted your script so that it is now compatible with LiveXP. Attached script should be placed under 'Finish\2 Create Image'.

Dependencies: WB 075; CreateISO.script v.28 available off the LiveXP server as of now.

Your prompting made me tidy up the multiprocessor script, which now makes use of %PreISOScript%. Because of this change, CreateISO and BootSDI had to be be adjuested for the changes.

Regards,
Galapo.

Attached Files



#4 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 24 August 2008 - 09:19 PM

Short notice:
thanks so far, great support.
I need some time to ask a decent question. Be patient.
I'll respont later this week.

#5 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 02 September 2008 - 09:58 PM

Developer release, under construction.

Actually there are a lot of combinations possible.
Boot image from CD, integrate to project CD (LiveXP), USB device.
Continue at the same device, or use another USB: firewire, PC card...

Over there at 911 there has been reports:
given a USB 1.1 speed BIOS at USB 2.0 hardware: chainboot the same USB device activate windows USB 2.0 drivers early.
Overall boot time is reduced.

@Galapo
I don't like to replace CreateISO.script.
I like to add settings to your %PreISOScript%, thanks.
Can you remove 'Disable="%scriptdir%\ChainBoot.script"' at CreateISO.script.

Grub4dos is another general matter.
Currently there are two freeware multiboot environments developed: syslinux and grub4dos
Other multiboot environments are not developed since years now.
Boot-land is the official english language support forum.

My current ChainBoot solution expect a activated Multi processor "Create uni- and multiprocessor PE ( adds grub4dos menu choices )".
That's a design error from me.

Grub4dos should get a more central place inside Boot-land projects.
What about a own grub4dos script? This script adds grldr and a basic menu.lst.
Other scripts append to menu.lst.
What's your opinion?


Background WinBuilder run did fail:

RegRead - Failed to read specified key from: [HKCU]Section: [Software\EasyBoot Systems\UltraISO\5.0] Key: [Registration] to variable:: [%Registration%]

Yes, there dosn't exist a UltraISO key at localhost.
Can you deselect (Selected=False) all shareware applications before upload?


@Nuno, jaclaz and all
I integrated a default prebuilded image.
MBR and partition sector contain windows default code.
There are no files inside the image.
Do you aggree? Should I avoid current code?

#6 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 02 September 2008 - 10:57 PM

Developer release, under construction.

Great, I look forward to seeing it!

Over there at 911 there has been reports:
given a USB 1.1 speed BIOS at USB 2.0 hardware: chainboot the same USB device activate windows USB 2.0 drivers early.
Overall boot time is reduced.

I read that also with interest. It's good to hear of success with the method.

I don't like to replace CreateISO.script.
I like to add settings to your %PreISOScript%, thanks.
Can you remove 'Disable="%scriptdir%\ChainBoot.script"' at CreateISO.script.

Understood. I didn't really want to disable the script, either. But as I couldn't devote too much time getting your script up and running for testing, I chose to do what I did. I'm more than willing to reverse so that a more robust solution can be offered. I'll upload CreateISO.script shortly with the entry removed. (Also upload deselected UltraISO.)

Regarding grub4dos, I think your idea of having a separte grub4dos script is a good idea, possibly to be placed under 'Build'. It would have to run early and possibly set a %bootsect% variable to script.project. I like the idea of other scripts appending to menu.lst.

I integrated a default prebuilded image.
MBR and partition sector contain windows default code.
There are no files inside the image.
Do you aggree? Should I avoid current code?

Shouldn't necessarily be an issue, although it isn't a problem automatically generating an image each time though is it?

Regards,
Galapo.

#7 Lancelot

Lancelot

    Frequent Member

  • .script developer
  • 5013 posts
  • Location:Turkiye/Izmir
  • Interests:*Mechanical stuff and Physics,
    *LiveXP, BartPE, SherpyaXPE,
    *Basketball and Looong Walking,
    *Buying outwear for my girlf (Reason: Girls are stupid about buying bad stuff to make themselves uglier :))
    *Girls (Lyric: Girl,...., You will be a womann, Soon)
    *Answering questions for "Meaning of life",
    *Helping people,

    Kung with LiveXP, Fu with Peter :)
  •  
    Turkey

Posted 03 September 2008 - 01:37 AM

not much thing to say, i support things i read here :whistling: ;)

#8 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 03 September 2008 - 01:01 PM

@Nuno, jaclaz and all
I integrated a default prebuilded image.
MBR and partition sector contain windows default code.
There are no files inside the image.
Do you agree? Should I avoid current code?


Personally I do not see a problem, I mean empty images have been hosted for years.

Bootpart has been containing all MS bootsectors for years.

MBRFIX more recently contains the MBR code, the "HP" USB formatting utility contains both, and most probably a number of other utilities that I am not familiar with.

I have had not time to check the latest developments/test anything of your latest release, is it FAT16 or FAT32 formatted?

If yes, it is easy to write the batch code for a "FIXED" size (or a few pre-fixed sizes) image that takes care, besides the MBR which is contained in either:
dmadmin.exe
spcmdcon.sys
setupdd.sys

but also for the FAT (16 or 32) bootsector, which is contained at least in:
spcmdcon.sys
autochk.exe
autofmt.exe
autoconv.exe
(the English version) I'll have to check where is the "local" version.

and to create the (very simply structured) empty FAT tables.

It is even possible to do that using just the (self-contained) ECHOO.COM and the internal COPY command (with copy /b file1+file2 file3) + a smallish third party program, like dsfo or the small program Nuno wrote some time ago (which I guess can be "ported" easily to command line only) to get the internal ME disk:
http://www.911cd.net...showtopic=16745

Although as said I see it as "safe" and "legal" to distribute an empty image, this later approach is more "elegant" and is without any doubt redistributable.

When I put together the MRBATCH/MKIMG batches, I used the approach of using VDK (monting the image and formatting it through windows FORMAT command) for several reasons:
1) the image had to be as "standard" as possible, not knowing what use of it would be made
2) the bootsector "messages" are in the language of the OS on which the image is created
3) also NTFS is supported (being NOT trivial to write the NTFS filesystem structure)
4) the mounting of the image gave also the opportunity to copy to the image the files the user wanted to in a "friendly" way

Of course the whole creation process could be made totally automatic, if only Nuno or karonyx (or another programmer) joins our effort and writes, starting from Open Source software the routines.

But, as only hinted on the original thread on 911CD, we do not need the MBR code to be the "MS windows" one, the Linux or other Open Source one will do as well.

And, if grub4dos is used (which is ;)) in the initial loading of the image, we do not even need the CODE for the MBR, as all that is needed for a MBR to be valid is:
a. the partition table
b. the "magic number" 55AA at the end.
as well, there is no need for the bootsector CODE, only DATA is needed, as grldr can chainload directly the NTLDR inside the partition.

The above two considerations open the way to a few posibilities further possibilities:
1) include one or more pre-formatted empty images NOT using Microsoft MBR and bootsector CODE
2) include a program based on either mkdosfs.exe:
http://www1.mager.org/mkdosfs/
or FAT32 formatter:
http://www.ridgecrop...fat32format.htm
or makebootfat:
http://advancemame.s...akebootfat.html
(which archive by the way already contains an alternate MBR code)
3) include a program mimicking the behaviour of MKIMG/MBRBATCH batches, only in the part where extraction of the MBR and bootsector is done, then re-assembling the extracted CODE together with custom DATA, add a couple of sectors to "delimit" the FAT tables, add a number of 00 filled sectors, thus forming a "complete" image

But anyway the image has to be mounted under XP to "populate" it with the files, thus if using VDK, the only DATA needed is a MBR sector with one partition entry filled and ending with the 55AA "magic number", i.e. the bare minimum needed is a number of sectors filled with 00's (that will compress nicely with any zip like or 7zip ;)) with just the first one containing 16+2 values.

It's just a matter of using the few lines of batch commands I use in MKIMG/MBRBATCH to mount the file and format it.

Most probably the same can be done with IMDISK, though I didn't test it (there may be a problem with the hidden sectors). :whistling:

;)

jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users