Hi all,

Although ive read many posts, either i'm too confused, or maybe it cant be done as I can find an answer....

I am trying the following with 1 USB drive (HDD or thumb)

1. Boot grub4dos from USB drive
2. load image containing USB2.0 drivers (copy to ramdisk and run drvload.exe to install aspiehci.sys or usbehci.sys and di1000dd.sys)
3. reload grub
4. load bartpe (now at USB2 speed)

I can do the first 3 no worries, but grub will not recognize the USB drive the second time around.

Does anyone know if something like this can be done? either this way or a completely different approach?

Basically I just want to load bartpe at USB2 speed using one USB drive (i.e. no CD,floppy, or internal HDD)

Thanks all.

Well, that won't work, as when you leave DOS executiing GRUB.EXE all drivers are "lost".

Something has been ONLY hinted in the "fake signature" or "XP Kansas City shuffle" thread:
http://www.911cd.net/forums//index.php?showtopic=21242

The thread is a bit chaotic, as often happens when new techniques are developed, browse the entire thread, then start again from this post:
http://www.911cd.net/forums//index.php?sho...21242&st=89

NOTHING yet working, mind you, but maybe a start.


jaclaz

thanks Jaclaz.

@brown111723
Can you clarify: how do you boot BartPE now?

There are two different USB approaches:
RAM loading a big image (2003 setupldr.bin)
\minint folder at USB drive

RAM loading works at more BIOS versions.
Loading a big image takes some time at USB 1.1 speed.

At \minint solution there are drivers loaded at text mode.
Strip down text mode part, integrate as less text mode drivers as possible.
USB 2.0 drivers are loaded at textmode.
At gui mode there should be USB 2.0 speed.


BartPE does boot with "fake signature" solution.
\minint folder is used that way.

No idea to use setupldr.bin RAM loading and "fake signature" solution.

"fake signature" solution load textmode part at BIOS speed too.
That's USB 1.1 speed at some BIOS. "fake signature" image is approached at USB 1.1 speed.
That's integrate as less text mode drivers as possible too.
At gui mode files are read from USB drive \minint folder. There should be USB 2.0 speed now.

Therefore I wonder. Given a BIOS USB 1.1 speed:
is "fake signature" \minint folder faster than \minint folder at USB drive?


Well, given a BIOS USB 1.1 speed and \minint folder fails at USB drive:
"fake signature" solution should work. And boot much faster than setupldr.bin RAM loading.

if you're pe is ISO format. do you think the following step works ?
1. first time boot grub also ram load a .img blank image as hdd (gzip to save space and speed up) .
(you have to create it with size you need, but it's small after gzip cause it's blank)
map --mem ()/blank.GZ (hd0)
map --mem ()/yourdosusb2support.IMG (fd0)
; map (hd0)(hd1) (Swap you real hdd if you need it)
; map --rehook
2. copy you PE ISO to the grub hdd.
3. run grub again and chainloader the iso and boot pe.
map --mem (hd0,0)/youpe.iso (hd32)
map --hook
map (hd0) (hd0)
' release memory use by map --mem hd0
map --rehook
chainloader (hd32)
i haven't try if this gain any speed? grub load .gz need time, copy ISO from USB flash to hdd (create by grub) need lot of time although it's now ram to ram.
and this require big memory . 1 copy in grub ram load hdd from USB flash, 1 copy in grub ram load CD/hd32.

i have any other solution to speed up usb1.1 , it's split PE to 2 parts after trim.

1st part files only able boot PE to cmd prompt (startnet.cmd) and network support. copy/mount 2nd part to x: before xpeinit and load xpe desktop.
1st part around 60mb/40mb(gzip).

2nd part about 130mb / 50mb (wim format file),it's a pe with xpe and more then 10 plugin.
mount .wim and copy some files of them to x: between PE start up to cmd prompt and xpelogon.
it should have usb2.0 support at any box at this stage.

gcru, soory, but I cannot make head or tail of your post.

Could you re-post (or edit the post) with more details?

Also, can you confirm that NO MATTER how it got there, (copied before with any means) you actually succeeded in booting a PE image on hard disk with (hd32) mapping?

Did this actually work?:



jaclaz

sorry for by poor english .

map --mem (hd0,0)/youpe.iso (hd32)
; this (hd0,0) is blank.gz, copy brown111723's PE ISO here. and map to (hd32) . *hd32=cd not harddisk. or you can map --mem (hd0,0)/youpe.iso (0xff) . 0xff also = cd.
map --hook

brown111723's problem is

1. USB flash boot to dos and load usb2 dos driver.
2. run grub and under grub enviroment not recognize USB flash , that mean not found PE.ISO.

to fix it .
1. boot USB flash with DOS.
2. run grub and map dos.img as fd0, map blank.gz as hd(0), and boot dos.img
dos.img is brown111723's dos boot disk that support USB 2.0.
3. after dos.img boot up. copy PE.ISO to (hd0) before run grub again.
4. in grub enviroment, map PE.ISO in (hd0) as (hd32) or (0xff), and boot it. you don't need to access USB flash to find PE.ISO at this moment.

No problem with your English , what I am wondering about is what you write, not how you do it.

I'll try again, I just need a "yes" or "no":

Can you answer to this question, please:
Did you succeed in booting a PE.ISO on HD by mapping it as (hd32) with grub4dos?

jaclaz

YES. whenever PE.ISO on local HDD, USB flash, PXE boot. All works like a charm.

why not ? new version grub4dos is able boot ISO (no emu).
* you can not gurb map a windows cd's iso to install XP. it boot up but fail to install XP.

I'm now running PE on Local HDD to reply this topic.


==== modify post 2:00 PM =====
I boot up PE again, and map PE.ISO (0xff) , it works. there is no different between 0xff and hd32.

If I get it right, you are probably using a "RAMDISK" booting .ISO.

RAMDISK booting involves the using of SETUPLDR.BIN and RAMDISK.SY_/RAMDISK.SYS from Server 2003 SP1 or R2 (NOT Server 2003, NOT Server 2003 SP2).

The point I am tryng to make is the following, with "plain" .ISO :
1) grub4dos maps a .iso image to (hd32)
2) the "real mode" part of SETUPLDR.BIN loads
3) as soon as it switches to "native drivers", it cannot find anymore the grub4dos mapped device and errors out, failing to boot

with RAMDISK booting:
1) grub4dos maps a .iso image to (hd32)
2) the "real mode" part of SETUPLDR.BIN loads the image in RAM
3) as soon as it switches to "native drivers", it connects to RAMDISK.SYS and finds the copied files in RAM, thus booting allright

jaclaz

Yes or No.
I using ram boot .ISO .
but i'm not using setupldr.bin + 2k3 ramdisk.sys.
i do use setupldr.bin from 2k3 for other reason. but no ramdisk.sys .

there is no winnt.sif also.
[SetupData]
BootDevice = "ramdisk(0)"
BootPath = "\I386\SYSTEM32\"
OsLoadOptions = "/minint /fastdetect /rdexportascd /rdpath=WINPE.ISO"

no WINPE.ISO inside RAMBOOT.ISO (winnt.sif + WINPE.ISO + \i386\ntdetect.com + \i386\setupldr.bin)

grub can also boot ISO without load to ram map ()/PE.ISO (0xff) (no --mem parameter).
but ISO need contig and i haven't success. anyway i like ramboot.


How grub boot ISO doesn't help brown111723 problem .
I've been try what brown111723 do months before. only few computer in office success (di1000dd.sys or duse.exe....) , so i give up without try to boot PE.
if our computer has no compatible issue. it's good to do it this way.
i have't try it, i don't know if this success.


but we have similar situation and successed.
USB flash dos boot
grub map --mem 1 dos boot disk. + 1 hdd format PE.IMG (minint folder). Boot DOS boot disk , not PE.IMG.
write something to hdd format PE.
run grub again and boot the hdd forma PE.

Ok, you are using RAMDISK booting, that of course works.


(bolding is mine)

The point, as per my post above, is that without RAMDISK booting it CANNOT work, until we find a "filedisk" type of driver capable of "taking" control once the "real" part of booting is over.

What I am trying to prevent is that a number of people, reading your report, may attempt (uselessly) to DIRECT booting a PE.ISO, which will fail.

Also, it is VERY important to have the "right" SETUPLDR.BIN, as said, and I am almost tired to post this all over:
http://www.boot-land.net/forums/?showtopic=4952&st=2


Double check the SETUPLDR.BIN you have, it CANNOT be a Server 2003 one, the ability was introduced with Server 2003 SP1, if you do not trust me, you may want to trust either Bart Lagerwej:
http://www.911cd.net/forums//index.php?showtopic=10806
or the actual people who wrote it:
http://technet.microsoft.com/en-us/magazine/cc160905.aspx

Ramdisk booting, whilst VERY convenient with smallish .ISO's, has serious limits in both max size of the image (512 Mb using any of the MS ramdisk.sys drivers) and in required physical RAM on the machine.

More details are here:
http://www.boot-land.net/forums/?showtopic=1507
http://www.boot-land.net/forums/?showtopic=2692&st=26

jaclaz

I got you point now. you're correct . you must boot ISO in ram or it end up with 0x7b.
this should be the same reason why we can not boot a windows cd iso to install windows.

Just for the record, and to keep things as together as possible, brown111723 just reported success with the "fake signature method" a.k.a. "XP Kansas City Shuffle" a.k.a "Chainboot other MBR device" method, using the batches by cdob:
http://www.911cd.net/forums//index.php?sho...c=21939&hl=
that take care of most if not all of the "difficult" parts.

jaclaz