Chainboot other MBR boot device, Even without BIOS support Options

[cdob]

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/forums//index.php?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, Image at CD
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 BartPE 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.microsoft.com/en-us/library/bb457123.aspx

Real hardware has to contain a MBR:
USB hard disk, USB stick, CF card, SD card

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

This batch prepare a hard disk image ChainBoot.img.
Boot files are read from a PE %OutDir%.
Builded hard disk image match current PEBuilder output.
Select a physical drive containing a MBR. Disk Management list drive number.


Expand attached files to

pebuilder\plugin\chainboot\ChainBoot.inf
pebuilder\plugin\chainboot\Chainboot_example.img
pebuilder\plugin\chainboot\mk-Image.cmd
pebuilder\plugin\chainboot\mk-ImageCopyFiles.cmd

And add file copysgcs.exe by karyoni http://www.911cd.net/forums//index.php?s=&...st&p=145456
And vdk by Ken Kato http://chitchat.at.infoseek.co.jp/vmware/vdk.html

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

Run PEBuilder and create a BartPE once.
Next goto plugin, select "chainboot (press config)" and press config.


Integrate hard disk image, grub4dos grldr and menu.lst to a boot media yourself.


Crossing physical devices you may get a message:
An unexpected error (769) occurred at line 5692 in setup.c
Well, read this as a sucess message. Press a key to continue boot.


New 1.02 version added.
Updates:
list physical drives
automatic virtual letter setting, idea by jaclaz
non important MBR and boot sector code deleted

This post has been edited by jaclaz: Oct 22 2008, 11:53 AM

Attached File(s)

 chainboot.zip ( 33.39K ) Number of downloads: 565
 chainboot_v1.02.zip ( 33.69K ) Number of downloads: 562

 

[jaclaz]

GOOD work, as always.

I must find another 24 hours to add to the conventional daily ones to test this too....

jaclaz

[ktp]

GOOD work, as always.

I must find another 24 hours to add to the conventional daily ones to test this too....

jaclaz

For your information, I tested the function OK on two different laptops :
http://www.911cd.net/forums//index.php?sho...mp;#entry149279

[brown111723]

I've just tried this excellent method but get a BSOD (7b) at the end of the windows xp splash screen and have no idea why...

I built using UBCD4WIN 3.2
then ran 'chainboot' config
then ran 'UBCD4WINtoUSB' config and used all default settings
then copied chainboot.img and menu.lst to flashdrive from chainboot plugin directory

Everything starts well and boots at USB2 speed up until the BSOD.
If I boot using the original grub4dos entry (USB1 speed) it boots no problem.

Any ideas?

Great work by the way to all involved, i've been waiting for this for AGES!

EDIT: Hold the phone! IT WORKS when I swap points 2 and 3 around above, i.e. run 'UBCD4WINtoUSB' config, then 'chainboot' config

Fantastic.

This post has been edited by brown111723: Aug 28 2008, 08:53 PM

[jaclaz]

EDIT: Hold the phone!

Oh, I see:
http://www.answers.com/topic/hold-the-phone


Happy to know that it works for you.

jaclaz

[Bastian]

Chainboot other MBR boot device, Even without BIOS support

Well, I don't want to be a nitpicker... I hate nitpicking. But in this case I feel to clarify the term chainloading. Imho chainloading is when a bootmanager (such as grub or grub4dos) loads an MBR of a harddisk into RAM, shuts down itself and jumps into it to execute it. The full control of one bootloader is hand over to another bootloader.

In grub4dos menu.lst:

CODE

title chainload hd1
map             (hd0) (hd1)
map             (hd1) (hd0)
map             --hook
chainloader     (hd0)+1

Can we agree this definition?

For example you could chainload anything then, linux or whatever. It would be great to boot from CD and then have real chianloading support for USB 2.0/firewire. It could be used as a generic fix for old BIOS or BIOS with bugs.

But it's not generic. The Fake Signature Method is a hack to fix stupid behavor of Windows XP' startup phase AFTER booting.

I am not saying Fake Signature Method is bad, imho it's a great effort.

Maybe I've understand something wrong or overseen something. If it's really possible to boot from CD, then load USB/firewire/cardreader driver and really chainload another MBR to boot linux, DOS, 9x or XP/Vista then please tell me. A "BIOS extender" who adds the missing function to the BIOS would be great.

[cdob]

Updates:
list physial drives
automatic virtual letter setting, idea by jaclaz
non importand MBR and boot sector code deleted

As indicated there http://www.911cd.net/forums//index.php?showtopic=21965
It's nice to Chainboot the same drive.
Some BIOS have limitations, e.g. BIOS USB1.1 speed despide USB2.0 hardware.
Chainbooting the same device may speed up boot.

And other BIOS may result a BSOD 0x7B because of reconfigure USB at boot.
Chainbooting the same device may overcome this too using XP default files.

This post has been edited by jaclaz: Oct 22 2008, 11:52 AM

Attached File(s)

 chainboot_v1.02.zip ( 33.69K ) Number of downloads: 298

 

[cdob]

Grub4dos does support gzip compressed images. This image can be loaded to RAM.

A basic BartPE compressed image is about 4 MB data.
Given a USB1.1 speed BIOS, this file is read at USB1.1 speed.

Run: gzip -9 ChainBootPE.img
http://www.gzip.org/
http://unxutils.sourceforge.net/

CODE

title PE - ChainBoot Physicaldrive2
map --mem --read-only /ChainBootPE.img.gz (hd0)
map --hook
chainloader (hd0,0)/minint/setupldr.bin

Add storport.sys at 2003 source files.

Tom created a very nice application UBUSB:
http://ubcd4win.com/forum/index.php?showtopic=11375

[ChinaDragon]

@cdob

Thank you for your information , for the utility of gzip, it save many space for my stick, the size drop from 25.8 M to 7.67M.
For the grub menu item of below, thank you for your correction , as I miss the parameter of --mem before

CODE

title PE - ChainBoot Physicaldrive2
map --mem --read-only /ChainBootPE.img.gz (hd0)
map --hook
chainloader (hd0,0)/minint/setupldr.bin

And I have one more question, I just update the plugin to include the file of storport.sys, but what is the purpose? I found that it still work even it haven't this file.

This post has been edited by ChinaDragon: Nov 22 2008, 11:12 AM

[cdob]

to include the file of storport.sys, but what is the purpose?

http://www.911cd.net/forums//index.php?s=&...st&p=151439

STORPORT.SYS - the new Port-driver designed for OS Win2003 Server.
It is designed specifically for hardware RAID-controllers.

Windows 2003 driver i2omp.sys refers to storport.sys.

There is a error "file i2omp.sys could not be found" without storport.sys. File i2omp.sys does exist.
File i2omp.sys is found and loaded, if storport.sys exist too.

[jaclaz]

@ChinaDragon
From what I can understand, if the

map

works, it is preferrable over

map --mem

map (without --mem) requires a contiguous file, but should be (very slightly) faster than map --mem and use some less RAM (though of course it won't make any difference on a modern machine)

@cdob
Maybe it's time, after all the progresses made with the "fake signature" approach to "stretch" it a little beyond, and "fork" the method.

I mean, it has been proved that it is an effective workaround (using the "kicker") to BIOS USB booting limitations, but it has also been proven that it quickens booting on a large numebr of setups where initial booting is at 1.1 speed, while it makes not an actual difference with "full USB 2.0" booting.

The disk occupation of the additional "kicker" image seems to me negligible, expecially when gzipped and with today's largish USB sticks.

So, it could be adopted as the "standard" way of booting from USB.

And then some new tests can be started.

A few possibly completely senseless ideas :
1) how do NTFS links work in initial stages of booting?
When do they "start" working?
I mean, is it possible to use a NTFS kicker image with just links to the "main" drive?
2) it is possible to somehow "divide" the Registry with additional sub-hives mounted on-the-fly?
3) how would behave the Perisoft demo Miniport Minifile File Driver (128 Mb capacity) work when booting?
I seem not to be able to "install" it with F6, have you some spare time to review it's .inf file/do some testing?
http://www.perisoft.net/miniport/index.htm

Cheers,
jaclaz

[ChinaDragon]

@cdob

Just found a problem that insufficient disk space occurred during flushing the last file of NDIS.SYS, what should be the possible value of C/H/S for the VDK ......

CODE

USBD.SYS
Microsoft (R) Cabinet Maker - Version 5.1.2600.5512
Copyright (c) Microsoft Corporation. All rights reserved..

100.00% [flushing current folder]
複製了         1 個檔案。

NDIS.SYS
Microsoft (R) Cabinet Maker - Version 5.1.2600.5512
Copyright (c) Microsoft Corporation. All rights reserved..

36.33% [flushing current folder]
ERROR: (FCIFlushCabinet)Failure creating or writing cabinet file: out of disk space

磁碟的空間不足。 <-- insufficient disk space
複製了         0 個檔案。

MUP.SYS
Microsoft (R) Cabinet Maker - Version 5.1.2600.5512
Copyright (c) Microsoft Corporation. All rights reserved..

100.00% [flushing current folder]
磁碟的空間不足。
複製了         0 個檔案。
Virtual Disk Driver for Windows version 3.1
http://chitchat.at.infoseek.co.jp/vmware/

Closing the image on the virtual disk 0...The image is closed.
Closing the image on the virtual disk 1...The drive is empty.
Closing the image on the virtual disk 2...The drive is empty.
Closing the image on the virtual disk 3...The drive is empty.
Stopped the Virtual Disk Driver.
Uninstalled the Virtual Disk Driver.

@jaclaz,
Sorry for my bad English

This post has been edited by ChinaDragon: Nov 23 2008, 12:56 PM

[cdob]

map (without --mem) requires a contiguous file, but should be (very slightly) faster than map --mem and use some less RAM (though of course it won't make any difference on a modern machine)

Used hardware gives difference with and without --mem.
There is continuous reading. And there is file access time.

Grub4dos --mem does read one big file continiously to RAM. Single files are read from RAM: very fast file acess time.
Grub4dos without --mem does read single files from media. Acess time maybe slow. There are slow acess time USB drives.

Another example: boot image at CD-ROM. without --mem is very slow.
CD drive makes terrible noises, much worse than plain BartPE booting.
File is accessed twice: once at FAT image and a second time at ISO9660 file system.
With --mem: no strange noises and fast boot.

So, it could be adopted as the "standard" way of booting from USB.

Well, in my opinion kicker image is a work arround half broken hardware.
Today hardware should boot at USB 2.0 speed. Unfortunately even hardware from this year boot at USB 1.1 speed.
At good hardware: I prefer \minint solution.

1) how do NTFS links work in initial stages of booting?
When do they "start" working?

As far as I remember, four years ago: Setupldr.bin works at hard links, but no junctions.
A loaded driver ntfs.sys support junctions.
Hard links are possible within one volume, junctions can cross volumes.

I mean, is it possible to use a NTFS kicker image with just links to the "main" drive?
2) it is possible to somehow "divide" the Registry with additional sub-hives mounted on-the-fly?

That's completely impossible. As impossible as booting XP from USB Seriously: I've no idea.

I'll test Miniport Minifile File Driver. Thanks.

@ChinaDragon
You may create a image yourself. I used jaclaz's mkimg.cmd, compare first post. Use all possible value of C/H/S from mkimg.cmd.

Which boot driver do you add?

Is there a comression timing error?
As you use --mem, remark makecab.exe line at mk-ImageCopyFiles.cmd

UBUSB creates a 40MB image by default.

[ChinaDragon]

@cdob

CODE

UBUSB creates a 40MB image by default.

You may create a image yourself. I used jaclaz's mkimg.cmd, compare first post. Use all possible value of C/H/S from mkimg.cmd.

Thank you for your information, I think 30M is enough for me.
I will create a 30M img file by jaclaz's mking.cmd for test.
Disk Capacity : 61440 sectors (30 MB)
Geometry : ( C) 30 * (H) 64 * (S) 32

CODE

Which boot driver do you add?

I boot it from USB stick.
1 \\.\PHYSICALDRIVE1 Imation Atom USB Device F:, also it is selected for the copysgcs.exe

CODE

Is there a comression timing error?

No timing error occur. , VERY FAST when boot from the ChainBootPE.img.gz, the boot process can be complete around 2 min.

CODE

As you use --mem, remark makecab.exe line at mk-ImageCopyFiles.cmd

Yes, I'm using "map --mem --read-only /ChainBootPE.img.gz (hd0)", and it is flushing by the makecab.exe, but it work great for me, remark it out may increase the size of ChainBootPE.img

This post has been edited by ChinaDragon: Nov 24 2008, 04:46 AM

[jaclaz]

@Chinadragon
The nx64x32 geometry was used in NT 3.5 and 4.0. (it is kept in MBRBATCH only for compatibility purposes, as well as the nx128x63 very rarely used)

It is recommended for all images to use either the
nx16x63 geometry for smallish images (Qemu defaults to this when smallish images are used)
or
nx255x63 for bigger ones (this is the standard for ANY device under 2K/XP/2003 and Vista/2008)


@cdob

Thanks for clarifications and your interest in the matter.

As impossible as booting XP from USB

...which gives us the opportunity to state how current achievements are a mere intermediate step, to be seen not as a point of arrival, but rather as a start towards new, better and greater achievements....
http://www.boot-land.net/forums/index.php?...c=2398&st=1


jaclaz

[ChinaDragon]

@jaclaz / cdob

Just create a 31M img for test, it work, no "insufficient disk space" any more.

Here is the information for the image file.
ChainBoot.pln

CODE

DRIVETYPE ide
CYLINDERS 62
HEADS 16
SECTORS 63
ACCESS ChainBootPE.img 0 63488

and following Geometry can be retrieved : © 62 * (H) 16 * (S) 63

CODE

D:\PEBUILDER\plugin\chainboot>vdk open * ChainBootPE.pln /rw
Virtual Disk Driver for Windows version 3.1
http://chitchat.at.infoseek.co.jp/vmware/

Installed the Virtual Disk Driver.
Started the Virtual Disk Driver.
Virtual Disk 0
Access Type     : Writable
Disk Capacity   : 63488 sectors (31 MB)
Geometry        : (C) 62 * (H) 16 * (S) 63
Number Of Files : 1

  Type     Size    Path
-------  -------  ----
  FLAT      63488  D:\PEBUILDER\plugin\chainboot\ChainBootPE.img

Partitions      :
      #   Start Sector    Length in sectors    Type
     --   ------------  ---------------------  ----
      0              0      63488 (    31 MB)  <disk>
G:   1             63      62433 (    30 MB)  04h:FAT16

And following warning appear when booting,


Finally, I can start the PE.
Do not know WHY Grub calculated the total sectors from the partition table is 63504 !! likely ONE more CYLINDERS determinated by GRUB itshelf.
What is the problem and how can I fix it ?!

This post has been edited by ChinaDragon: Nov 24 2008, 01:35 PM

[jaclaz]

Do not know WHY Grub calculated the total sectors from the partition table is 63504 !! likely ONE more CYLINDERS determinated by GRUB itshelf.
What is the problem and how can I fix it ?!

Rest assured that grub4dos (NOT, NOT GRUB) did it's work allright.

Let's see if we can use a bit of Math simple arithmetic:

Partitions :
# Start Sector Length in sectors Type
-- ------------ --------------------- ----
0 0 63488 ( 31 MB) <disk>
G: 1 63 62433 ( 30 MB) 04h:FAT16

Since 63+62433=62496
and
62496 < 63488
where have the 63488-62496=992 sectors gone?

They are AFTER the partition, in an unused space of the image.

Now, you want to get rid of that grub4dos warning?

Use an image size that leaves no "empty space":
63x16x63=63,504 sectors x512=32,514,048 bytes

but your image is 31M =31x1024=31,744K=31,744x1024=32,505,856
so the biggest possible CHS address is
62x16x63=62,496 sectors x512=31,997,952

32,505,856/512=63488 sectors

Do the numbers start to make sense?


Try making an image EXACTLY 32514048 bytes in size and see what happens...

...or make one EXACTLY 31997952 if it's enough....

jaclaz

This post has been edited by jaclaz: Nov 24 2008, 03:03 PM

[ChinaDragon]

@jaclaz / cdob

BINGO


I make new img file by following value

mkimg (MbrBatch.zip)

Please enter target file name: 32514048.img
Image size, in bytes or suffixed by K, M or G for Kilo Mega or Giga
Please enter target image size: 32514048
Please type desired geometry [255/63 128/63 64/63 16/63 64/32]: 16/63
Available partition types for this image, 32514048 bytes:
04 FAT 16 <32 Mbytes
06 FAT 16 CHS Mapped
07 NTFS
0B FAT 32 CHS Mapped
0C FAT 32 LBA Mapped
0E FAT 16 LBA Mapped
Please type desired Partition Type [04 06 07 0B 0C 0E]: 0E
Please type /fsz to use fsz.exe or [ENTER] to use mksparse.exe:

vdk open * 32514048.pln /rw

Virtual Disk Driver for Windows version 3.1
http://chitchat.at.infoseek.co.jp/vmware/

Installed the Virtual Disk Driver.
Started the Virtual Disk Driver.
Virtual Disk 0
Access Type : Writable
Disk Capacity : 63504 sectors (31 MB)
Geometry : © 63 * (H) 16 * (S) 63
Number Of Files : 1

Type Size Path
------- ------- ----
FLAT 63504 D:\PEBUILDER\plugin\chainboot\32514048.img

Partitions :
# Start Sector Length in sectors Type
-- ------------ --------------------- ----
0 0 63504 ( 31 MB) <disk>
I: 1 63 63441 ( 30 MB) 04h:FAT16

I get rid of the grub4dos warning now.
Thank you



This post has been edited by ChinaDragon: Nov 25 2008, 11:47 AM

[jaclaz]

Yep.

Also please note that Partition Type has been "automagically" fixed by Windows Format from 0E (FAT16 LBA mapped) to 04 (FAT16, CHS mapped, size <32 Mb)

jaclaz

[ChinaDragon]

@cdob

CODE

As you use --mem, remark makecab.exe line at mk-ImageCopyFiles.cmd

I get what you mean now , will follow.

@jaclaz
Thank you for your information, updated and it work fine too.

mkimg.cmd 32514048.img 32514048 16/63 04 /mks

This post has been edited by ChinaDragon: Nov 26 2008, 01:33 PM