Jump to content











Photo
- - - - -

Boot BartPE as img from HDD with Grub4dos?


  • Please log in to reply
33 replies to this topic

#26 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,098 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 30 October 2007 - 07:40 PM

What do you wanna use winnt.sif for?

To use the RAMDISK, of course, I also posted an example of it.

Or do you suggest another method? :cheers:

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

As far as I understand, yes, but the idea was not to rewrite (in batch :cheers:) mkisofs from scratch, but to try and find a way to use it to the max possible extent and just do a few hexedit from batch.
If I get it right mkisofs does copy files along the same order.

This however won't apply to your "subset" in which files in MAIN and INNER are exactly the same.

jaclaz

P.S.: I am making some tests with the Recovery Console, and since one has to hexedit SETUPLDR.BIN anyway, I used the idea from gray here:
http://www.911cd.net...o...3784&st=249
in order to get rid of the /I386 vs. /minint differences, now everything is /I386

#27 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7,754 posts

Posted 30 October 2007 - 09:00 PM

To use the RAMDISK, of course, I also posted an example of it.

Or do you suggest another method? :cheers:

Never used ram boot, but assumed that the boot parameter would be set in txtsetup.sif like minint.
If winnt.sif is used for ram boot, even txtsetup.sif would stay the same on my build.

:cheers:

#28 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,098 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 31 October 2007 - 08:24 AM

Never used ram boot, but assumed that the boot parameter would be set in txtsetup.sif like minint.
If winnt.sif is used for ram boot, even txtsetup.sif would stay the same on my build.

:cheers:


Well, than in "your" build, "my" way with WINNT.00x is even simpler. :cheers:

The contents of \I386 remain ALL the same

jaclaz

#29 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7,754 posts

Posted 31 October 2007 - 07:36 PM

Well, than in "your" build, "my" way with WINNT.00x is even simpler. :cheers:

The contents of \I386 remain ALL the same

jaclaz

Sounds great!

:cheers:

#30 thunn

thunn

    Silver Member

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

Posted 04 November 2007 - 08:12 PM

I'm using a modified setupldr.bin in a couple scripts, I made it point to winpe.sif for my inram boot options.
---
~ & regarding a script mentioned before,
While it doesn't use grub for dos, the ramPE to (nt5x)hdd script I have in bartpecore tools was recently revised as it contained spaces (replaced with '#$s') preventing it from working with some versions of wb. It may proove usefull as a rescue option (not for usb unless used as active partition).
--
.. It will be fun to see what you guys come up with!

#31 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,098 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 06 November 2007 - 07:50 PM

If you asked me yesterday, I would have said that I was wrong and that it was not possible to make a FAT OFS able to run "windowish" software, I was really depressed, as I throwed everything I had in store + something I invented on the spot :cheers: against those disk images and could not get anything out of it...:cheers:

...but today is ANOTHER day and I succeeded for the first time in making a Recovery Console 16 Mb image (which contains BOTH a 14 Mb image - with 6.5 Mb free - AND a "normal" 8 Mb /I386 structure + the various loaders) that is bootable BOTH "directly" and through 2003 RAMDISK! :cheers:

The procedure is still half manual and prone to errors, the sizes of the images have been chosen to simplify the work (same number of FAT sectors) but I got most of the math involved and in due time I think I can extend to anything below 512 Mb (limit of the RAMDISK). :cheers:

Another small teaser, drive K:\ mounted from INNER.IMG contained in drive J:\ mounted from OUTER3.IMG:
Posted Image


I will be very busy in real life in the next few days, but I hope that end of next week to be able to release a set of .cmd/instructions to make the above replicable.

jaclaz

#32 cdob

cdob

    Silver Member

  • Expert
  • 901 posts

Posted 07 November 2007 - 07:12 PM

@jaclaz
Thanks this looks promising. I'm looking forward to a release.

Do you like another request?
OFS combines FAT(32), NTFS and CDFS. A RAM loaded FAT(32) image at CD.


@all
Another approach:
Boot PE normal from CD and ISO RAM loading, with one file section.

RAM loading read a ISO image from CD.

Obvious but worth to remember: A CD image contains a CD image.
Or the other way round: A CD represents a image.

Or if we like to load a image, we can RAM load hole CD.
Normal PE boot and RAM load boot use the same filesystem.

Default CD boot: use files at CD\I386
RAM load: load hole CD

Standard ECMA-119 is also approved as ISO 9660.
http://www.ecma-inte...ds/Ecma-119.htm
Section 9 describe File and Directory Descriptors

Prepare a PE.ISO. This goes to CD.
Add a multiboot environment. This can be grub4dos, bcdw, isolinux, and more.

RAM load part:
\WINN2.SIF
&#91;SetupData&#93;

BootDevice = &#34;ramdisk&#40;0&#41;&#34;

BootPath = &#34;\i386\System32\&#34;

OsLoadOptions = &#34;/noguiboot /fastdetect /minint /rdexportascd /rdpath=LOOP.ISO&#34;
\I386\SETUPLD2.BIN: renamed 2003 SP1 setupldr.bin
gsar -o &#34;-s&#58;winnt.sif&#34; &#34;-r&#58;x46&#58;winn2.sif&#34; setupld2.bin

rem ignore checksum&#58; geitonaki http&#58;//www.msfn.org/board/index.php?showtopic=58410

gsar -o &#34;-s&#58;x46&#58;xda&#58;x74&#58;x03&#34; &#34;-r&#58;x46&#58;xda&#58;xEB&#58;x1A&#34; setupld2.bin

Add a dummy file: LOOP.ISO. Use a zero size file (part of command): mkisofs -graft-points /LOOP.ISO=nul
A zero size file gets a known LBA. That way a known LOOP.ISO file descriptor is added to PE.ISO.
A recent mkisofs version is expected
http://cdrecord.berl...e/cdrecord.html
http://www.student.t...t/thomas.plank/

Next patch file PE.ISO: adjust LOOP.ISO file descriptor.
Map LOOP.ISO Location of Extent to zero. And Data Length to PE.ISO file size.
Now LOOP.ISO file descriptor match the hole CD.

Gsar is used to patch PE.ISO.
That's a working, but quick and dirty solution.

Maybe another member like to create nicer a solution. Walk through File and Directory Descriptors, find appropiate LOOP.ISO File Descriptor and patch this entry.

Attached Files



#33 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,098 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 07 November 2007 - 08:08 PM

@cdob
As always, interesting points. :cheers:

However, the general idea, at least for me, would be to have a very small "INNER.IMG" (or if you prefer a very basic build) so that it can be RAM-booted on systems with low memory, and a more "complete" "OUTER.IMG" i.e. the actual FAT partition, that could be booted normally on the same low memory systems, but with a bigger number of apps tools.

I am afraid that mixing different filesystems might prove to be not possible, at least not in the way I am currently building the filesystem, basically creating TWO images, one (patched to be suitable) containing "INNER.IMG" and the second containing the contents of "INNER.IMG (the /I386 directory) and finally "exchanging" the FAT tables and "correcting" a few bytes.
In other words, the "container" and the "contained" filesystems need to be the same, as I use (mainly) built-in filesystem functions for the specific filesyste to create (twice) the FAT's and directory structure.

Your CD approach should be however all is needed by Medevil for his project, where "inner" and "outer" /I386 are just the same.

:cheers:

jaclaz

#34 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7,754 posts

Posted 31 October 2009 - 03:24 PM

jaclaz wouldn't it be possible to marry two different file systems, if we just kept the clustersize identical?
As far as i know, neighter CDFS nor FAT store additional information in the clusters or sectors. No idea about NTFS.

:cheers:




2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users