Jump to content











Photo
- - - - -

Boot BartPE as img from HDD with Grub4dos?


  • Please log in to reply
33 replies to this topic

#1 my77

my77

    Newbie

  • Members
  • 14 posts
  •  
    Afghanistan

Posted 14 August 2007 - 07:58 AM

Hi I am using Grub4dos and I added some images of rescue programs like Acronis Disk Director, Vista PE or Windows Recovery Console to my boot menu, just in case something happens and I do not have my set of rescue CDs with me.

Is it possible to put BartPE into an image, put this image on a hdd and boot from this image? How would one accomplish that? :loleverybody:

#2 was_jaclaz

was_jaclaz

    Finder

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

Posted 14 August 2007 - 08:50 AM

NO, it is not possible, UNLESS you use a RAMdisk approach.
You will need either plenty of RAM or a smallish image.

Check this:
http://www.boot-land...?...ic=2819&hl=
AND links therein.

jaclaz

#3 my77

my77

    Newbie

  • Members
  • 14 posts
  •  
    Afghanistan

Posted 20 August 2007 - 09:59 PM

Thanks for your help on this, jaclaz.

I created several SDI Images for me that serve the purpose. Some questions arose in the course of the implementation:
1. I have many BartPE disks that do not contain a NTOSKRNL.EXE. If I boot them from CD everything is fine, booting from the hdd image results in an error msg saying ntoskrnl.exe is missing. How is that possible?
2. On the Vista DVD there is a Boot.sdi. I wanted to look into this image to understand the interaction with the accompanying WIM image. But when I mounted it with sdiloader it showed a not initialised disk. How come?

#4 was_jaclaz

was_jaclaz

    Finder

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

Posted 21 August 2007 - 11:46 AM

Cannot say about 1.

About 2.:
SDI images are simply RAW "partition" images with a certain number of sectors pre-pended to it.
You can use IMDISK to mount (and thus explore) them.
You will need to find the exact OFFSET at which the raw image starts.

Generally it is 32256 bytes (or 63 sectors/blocks) but this may vary, typical other values are 4096, 8192, 16384.

Do the following:
1) Open the SDI file with any hex editor
2) Search for the "Magic signature" 55AA hex
3) try using as offset the result of subtracting 510 (dec) bytes from the address you find it. (result must be divisible by 512)
4) if it does not work, try with next occurrence of 55AA....

As said elsewhere, the SDI format is not needed anymore, as one can use any RAW disk image, specifying the correct /RDIMAGEOFFSET= to the bootsector.

jaclaz

#5 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 21 August 2007 - 01:15 PM

@jaclaz

Is there a way to boot a PE normal from ISO as well as to ram or 'ramdisk', without having to have two setups on CD?

:loleverybody:

#6 was_jaclaz

was_jaclaz

    Finder

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

Posted 21 August 2007 - 05:07 PM

@jaclaz

Is there a way to boot a PE normal from ISO as well as to ram or 'ramdisk', without having to have two setups on CD?

:loleverybody:


Could you better describe what you want to achieve, giving some examples? :w00t:

jaclaz

#7 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 21 August 2007 - 05:28 PM

Could you better describe what you want to achieve, giving some examples? :w00t:

jaclaz

I want a PE that i can boot on low RAM machines directly from CD, while on high RAM machines, i can put it into RAM, to speed things up/ have the CD drive free. Pesky Notebooks have only one of those! :w00t:

:loleverybody:

#8 was_jaclaz

was_jaclaz

    Finder

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

Posted 22 August 2007 - 11:04 AM

I see. :loleverybody:

I don't think there is a viable solution achieving exactly what you wish. (yet)

Possible approaches with available informations/tools:
1) put on the CD BOTH a \I386 "normal" PE and a .ISO (or .IMG) of the build to be eventually RAMbooted (after all a CD has 650/700 or even 800/900 MBytes available, two builds should fit)
2) Create a "modular" PE with a VERY SMALL "core" and all the rest loaded through hard links from NTFS filestem in RAM to disk volume image(s) mounted with VDK (or IMDISK).
Such a build should be able to RAMboot on systems with a relatively small amount of RAM, i.e. 256 MB, and, on the other hand, having XP running on a 128 MB PC is a SLOW way to induce suicide to the user.

jaclaz

#9 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 22 August 2007 - 03:07 PM

I see. :w00t:

I don't think there is a viable solution achieving exactly what you wish. (yet)

Possible approaches with available informations/tools:
1) put on the CD BOTH a \I386 "normal" PE and a .ISO (or .IMG) of the build to be eventually RAMbooted (after all a CD has 650/700 or even 800/900 MBytes available, two builds should fit)
2) Create a "modular" PE with a VERY SMALL "core" and all the rest loaded through hard links from NTFS filestem in RAM to disk volume image(s) mounted with VDK (or IMDISK).
Such a build should be able to RAMboot on systems with a relatively small amount of RAM, i.e. 256 MB, and, on the other hand, having XP running on a 128 MB PC is a SLOW way to induce suicide to the user.

jaclaz

Thanks for looking into the problem jaclaz. But:
1) I wanna use a minCD for the project, so having two independant systems isn't a possibility.
2) System is running at the moment fine with just 64MB and without paging file. So more ram shouldn't speed things up, just enable one to run more applications at the same time.

:loleverybody:

#10 was_jaclaz

was_jaclaz

    Finder

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

Posted 22 August 2007 - 06:18 PM

Then most probably you could get away with something similar to the flyakite's multiboot CD/DVD guide (hexediting hardcoded files and directory names) and then use either the "duplicate once" switch in mkisofs or Microsoft OSCDIMG/CDIMAGE to build an optimized .ISO.

Grub4dos' grldr might come handy, used as no-emulation bootsector, as it is capable to chainload through menu.lst differently hexedited SETUPLDR.BINs in different directories.

2) System is running at the moment fine with just 64MB and without paging file. So more ram shouldn't speed things up, just enable one to run more applications at the same time.


Yes, in my mind I "mapped" the hypothetically minimum 256 MB of RAM as follows:
1) 64 MB for system
2) 128 MB for RAMDISK
3) 64 MB for running apps (without swapfile)

jaclaz

#11 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 22 August 2007 - 07:21 PM

Then most probably you could get away with something similar to the flyakite's multiboot CD/DVD guide (hexediting hardcoded files and directory names) and then use either the "duplicate once" switch in mkisofs or Microsoft OSCDIMG/CDIMAGE to build an optimized .ISO.

That was my original idea. But couldn't find a way to ramboot from anything but an image. And there is no optimizing between individual files and an image.
Do you know more?

Yes, in my mind I "mapped" the hypothetically minimum 256 MB of RAM as follows:
1) 64 MB for system
2) 128 MB for RAMDISK
3) 64 MB for running apps (without swapfile)

Now i'm curious, what do you need 128MB Ramdisk for? :w00t:

:loleverybody:

#12 thunn

thunn

    Silver Member

  • .script developer
  • 531 posts
  • Location:Brooklyn, New York
  • Interests:computers<br />mechanics<br />distortion<br /><br />
  •  
    United States

Posted 22 August 2007 - 11:29 PM

I wrote a script for img based pe from hdd a few weeks ago..

http://bartpe.boot-l...mPEtoHdd.script

If you care to test it, I'd like to know what you all think. :loleverybody:

#13 was_jaclaz

was_jaclaz

    Finder

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

Posted 24 August 2007 - 09:02 AM

@Medevil

I was referring to the previous idea of booting ALWAYS through a RAMdisk, once with a reduced size and once with a "full" one.
Of course before you introduced the new "complication" of a mini-CD. :loleverybody:

However I had an idea that could work. :w00t: MAYbe.....

Give me a few days to do some tests about it's feasibility, then, IF it will work, I'll give you the bases to experiment with.

jaclaz

#14 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 24 August 2007 - 11:45 AM

However I had an idea that could work. :loleverybody: MAYbe.....

Give me a few days to do some tests about it's feasibility, then, IF it will work, I'll give you the bases to experiment with.

Looking forward to your solution! :w00t:

:w00t:

#15 was_jaclaz

was_jaclaz

    Finder

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

Posted 24 August 2007 - 05:25 PM

Looking forward to your solution! :loleverybody:

:w00t:


Just as a teaser :w00t:, have a look at the three floppy images inside the attached .zip file, have a look at them mounted with IMDISK, try booting from each of them in QEMU, see if you can spot any difference.

Hint:
check carefully the QEMU screenshots, and the the amount of free space on the volumes....


Just to be on the safe side :w00t: , I hereby declare my intellectual property and rights August 24th, 2007, to the idea of a filesystem called OFS, acronym for Overlapping FileSystem. :w00t:

The concept appears to work on FAT12 formatted volumes, thus it wil definitely work on FAT16 ones, and most probably with FAT32 ones.

Cannot say if it will work on CDFS volumes, (which would be the solution to your problem) but I'm optimist about that. :w00t:

Please note that the attached example has been hand crafted by using manually a number of "tricks of the trade", directly hexediting floppy images, and that at the moment there is no straight way to replicate/manage this.

No animal was harmed in the making of these, and the increase in air pollution due to my smoking has not increased as compared to normal emissions, so it is also environmental safe.
:w00t:

jaclaz

Attached Thumbnails

  • OUTER_G3_OFS4.jpg
  • OUTER_G3_with_Files.jpg
  • OUTER_G3_with_IMG.jpg

Attached Files

  • Attached File  OFS.zip   556.43KB   638 downloads


#16 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 24 August 2007 - 07:52 PM

From the name of your OFS i guess, you pretend that part of the original disk is in fact part of an image, right?

Very clever even for a genius like you! :loleverybody:
The thing should be a pain in the ass to set up, but should do exactly what i need.

:w00t:

#17 TheHive

TheHive

    Platinum Member

  • .script developer
  • 4197 posts

Posted 25 August 2007 - 08:25 AM

Dont know what youre doing but sounds interesting from viewing the size of the what im guessing is bootable floppys.

#18 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 05 September 2007 - 09:54 PM

jaclaz, are you still working on your OFS idea, or have you found more interesting things to do? :w00t:

:loleverybody:

#19 was_jaclaz

was_jaclaz

    Finder

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

Posted 06 September 2007 - 05:15 AM

No,
I am still working on it, but things are not that easy. :loleverybody:

I found myself with a theory in my head, a series of steps to perform jolted down, and a prototype (above) as practical demonstration.

But I found out that I was simply missing the tools needed to repeat the experiment in an automatic way (thus easily accessible to all and with possibility for bug corrections/troubleshooting).
So I started the way my grandfather used to work: every time he needed to build something he started from designing it, then he used to take his time to build the tools needed to build the something, and finally he started to build it.

The problem is that I tend to be distracted quite easily, and moreover, being in some way a perfectionist, it takes me lots of time to get something the way I want it to be.

Just as an example, I could get away with a hex to dec to hex conversion problem I was having rather easily, but I started working on it and then decided to go all the way on until I got two small batches that could be used independently:
http://www.boot-land...ccmd-t2986.html

A (completely and utterly theoretical) "roadmap" is the following:
End of 2nd week of September: tools ready for FAT OFS (i.e. for .img type of files)
End of 3rd/4th week of September: repeatable prototype for FAT OFS
End of 3rd/4th week of September: start getting documentation for CDFS OFS (i.e. for .iso type of files)
????: repeatable prototype for CDFS OFS (IF I find a way to it)

You know, we "admins" are a bit slow....:w00t:

jaclaz

#20 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 September 2007 - 11:14 AM

You know, we "admins" are a bit slow....:loleverybody:

Hey, finaly one that admits it! :w00t:

Just wanted to check, if i might have to put it on my tab.

:w00t:

#21 g_BonE

g_BonE

    Newbie

  • Members
  • 21 posts
  •  
    Germany

Posted 25 October 2007 - 03:57 PM

*bump*

sounds promising, jaclaz ?

#22 was_jaclaz

was_jaclaz

    Finder

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

Posted 29 October 2007 - 10:07 AM

A small (due) update. :cheers:

I have now written all (or most of) the tools needed, but I am (temporarily) at a still.

I am waiting to find the time to install a new hard disk on my system as I have NO space left (at least not enough to experiment with the images the way I want to)

I have found a problem with using the FAT filesystem, which is the fact that after a certain number of directory entries (files) are written the cluster that contains this DIR info gets (obviously) full (depending on the size of the cluster) so that the DIR entries coontinue in a cluster that is appended AFTER last file written.
I need to find a way to re-locate this cluster after previous "DIR cluster" and BEFORE the first file.
I have a couple of ideas, but as said have not for the moment the possibility to test them.

After a suggestion by Medevil, I started however studying ISO9660 (or CDFS) to see if using it would be easier, but whilst I have found a VERY good feature of it (the ability to establish filesystem links, corresponding to the -duplicate-once switch of mkisofs), I have also found what could be a drawback, i.e. the fact that on cdfs DIR info, which is "consolidated" BEFORE files (which is a good thing) uses a rigid alphabetical order for entries.

I have possibly found a workaround, by means of using the same approach "multi-session" CD's use, but am however (again momentarily) stuck by the fact that most probably for using OFS for a "dual-boot" PE boot one will be obliged to use a bootmanager (grldr or a similar one) and two different SETUPLDR.BIN, at least one hex-edited to point to a different directory from /I386. For the moment I just checked original ISO9660, I still have to check what is present in later extensions, like the 1999 ones, (corresponding to -iso-level 3 and -iso-level 4), that may possible solve the problems found.

As soon I can start experiments I will report progresses.

In the meantime it would help me if either g_BonE or Medevil would post:
1) a DIR /S >MainIMA.dir of the "main" image
2) a DIR /S >InnerIMA.dir of the "inner" image (the smallish one to be booted through RAMDISK)
3) the text file(s) that change between the two (BOTH versions) such as txtsetup.sif, WINNT.SIF and similar files.
All the above possibly coming from either a XPSP2 or Server2003 SP1 build ENGLISH.

jaclaz

#23 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 29 October 2007 - 06:20 PM

stuck by the fact that most probably for using OFS for a "dual-boot" PE boot one will be obliged to use a bootmanager (grldr or a similar one) and two different SETUPLDR.BIN, at least one hex-edited to point to a different directory from /I386.

I can see why 2 different txtsetup.sif and setupldr.bin, but why 2 different folders for OFS? :cheers:


In the meantime it would help me if either g_BonE or Medevil would post:
1) a DIR /S >MainIMA.dir of the "main" image
2) a DIR /S >InnerIMA.dir of the "inner" image (the smallish one to be booted through RAMDISK)
3) the text file(s) that change between the two (BOTH versions) such as txtsetup.sif, WINNT.SIF and similar files.
All the above possibly coming from either a XPSP2 or Server2003 SP1 build ENGLISH.

Can't help you with a list from an english source, but can tell you what would differ on my system.
1 + 2) Inner and outer image are identical, except for a single boot parameter in txtsetup.sif and maybe a second patched setupldr.bin. (But not sure about setupldr.bin)
3) txtsetup.sif possibly setupldr.bin too

:cheers:

#24 was_jaclaz

was_jaclaz

    Finder

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

Posted 30 October 2007 - 09:18 AM

@Medevil
If the files in "inner" image are exactly the same (exception made for SETUPLDR.BIN and a couple of text settings files) as the ones in "main" image, we are in a "subset" of a more general approach, where "inner" image might be a "reduced version" (smaller footprint to limit RAM requirements) of "main" image.

I am writing the following just as a brief note, (assuming, for the moment, that I am able to create images as described - which I am not - yet :cheers: ) please do correct me whenever something is not correct:
1) We need two copies of SETUPLDR.BIN, for the sake of simplicity let's call them SETUPLDR.001 and SETUPLDR.002

2) Each of them is hexedited to point to a different WINNT.SIF, respectively WINNT.001 and WINNT.002

3) There must be a way to select at boot time which SETUPLDR.00x to boot from, this can be grub4dos grldr or another bootmanager, let's assume that this part is already clear and tested:

title Boot PE Normally
chainloader /SETUPLDR.001

title Boot PE in RAM
chainloader /SETUPLDR.002


4) For normal booting WINNT.001 can be empty or non-existant

5) For RAMdisk booting we need, for "ISO in ISO" a WINNT.002 like this:

[SetupData]
BootDevice = "ramdisk(0)"
BootPath = "\i386\System32\"
OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=INNERIMG.ISO"

and for "FAT in FAT":

[SetupData]
BootDevice = "ramdisk(0)"
BootPath = "\minint\System32\"
OsLoadOptions = "/noguiboot /fastdetect /minint /rdimageoffset=32256 /rdpath=INNERIMG.IMG"


6) at least SETUPLDR.002 must be from Server 2003 Sp1+

7) ramdisk.sys in \i386\S (ISO in ISO) or in /minint (FAT in FAT) must be from Server 2003 SP1+

8) Structure should be something like this (ISO in ISO):
ROOT
|
| grldr
| menu.lst
| SETUPLDR.001
| SETUPLDR.002
| WINNT.001 (dummy file or unneeded)
| WINNT.002
| \I386
and something like this (FAT in FAT):
ROOT
|
| grldr
| menu.lst
| SETUPLDR.001
| SETUPLDR.002
| WINNT.001 (dummy file or unneeded)
| WINNT.002
| \minint

9) if one needs two different TXTSETUP.SIF's, one can do the same already done with WINNT.SIF, i.e. have a TXTSETUP.001 and a TXTSETUP.002

10) in the case of ISO in ISO one could somehow use the -duplicate-once ability of the CDFS filesystem to have on the same CD two different source directories, like \I386 and \MYNT linking between them the same files, thus increasing the size of the CD only of the size of different files (in other words we can have two directories with different names containing a number of identical files, and a number of different files with the SAME name).
Of course we cannot have in the same directory two files different in contents but with the same name, this is why I was talking about doubling the directories. From what I read the ISO filesystem directory entries NEED to be in strict alphabetical order, and I don't think there is a way of "removing" one or more entries and keep everything working, as I propose to do in the following

11) in the case of FAT in FAT this can only be partially replicated by putting the different files (but with SAME name) after the INNER.IMG extents and removing the entries corresponding to the files within the INNER.IMG from the "main" directory records (i.e. act like the first file was deleted and add the other one at the end)


jaclaz

#25 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 30 October 2007 - 06:21 PM

2) Each of them is hexedited to point to a different WINNT.SIF, respectively WINNT.001 and WINNT.002

:cheers: What do you wanna use winnt.sif for?

From what I read the ISO filesystem directory entries NEED to be in strict alphabetical order, and I don't think there is a way of "removing" one or more entries and keep everything working, as I propose to do in the following

Can't see your problem. It's just the directory that's sorted, not the filesystem, or is it?

:cheers:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users