The smallest possible size of boot.sdi

[joakim]

Microsoft still uses the same file they created for Longhorn on 15.02.2005, over 5 years ago (assuming their timestamps are more trustworthy than mine).

Three severely retarded things are worth noting about the original boot.sdi;

1. The $LogFile is 2 Mb

2. Free space is set to 0,6 Mb

3. Page alignment is set to 8192 bytes (instead of 4096) in the sdi header

Strange that they still keep this one.

Joakim

[jaclaz]

Strange that they still keep this one.

Well, if you compare with the Windows ME floppy disk "embedded" in XP, you wiil see how they used a floppy they had around, deleted a few files (most of them recoverable/undeletable) and simply "dded" them inside an .exe.

So, they are not new to this kind of behaviour.

JFYI:

http://www.911cd.net/forums//index.php?showtopic=16745

jaclaz

[Bilou_Gateux]

Size now at 307 200 bytes; http://www.mediafire.com/file/k3qdkrucb6ce8ej/boot_sdi_300.zip

The partition image is now basically constructed like this;

Sector 0:         $Boot
Sector 1 - 64:    $MFT
Sector 65:        $MFT:$Bitmap
Sector 66 - 73:   Root directory
Sector 74 - 586:  $LogFile

The rest of the systemfiles are found "inside" the $LogFile starting at sector 136.

It is now much easier to read it too.

Also tried putting the $LogFile in sector 1 and placing all other systemfiles inside it, but that did not work.

Btw, it is a really good way to learn about ntfs when working with such a small partition image.

Joakim

How do i mount this file as virtual disk?

With the initial release, i can mount boot.sdi with imdisk:

imdisk -a -t vm -f boot.sdi -b 8192 -m C:\Dev\boot

Now your archive contains both 300.part file and boot.sdi

I tried mounting boot.sdi but can't find NTFS bootrecord which starts with EB5290

Edited August 23, 2010 by Bilou_Gateux

[joakim]

That is expected behaviour since the ntfs filesystem is invalidated. No existing tool will be able to mount that partition image normally. You must use a hex editor and/or a similar low level reader (like ntfs diskexplorer). Btw, the starting offset is 4096 and not 8192 (determined by the page size of the sdi). The bootsector is completely removed.

The first version that you mention is mountable, has a good and valid filesystem, and therefore is possible to mount using "normal" tools.

Joakim

Edited August 23, 2010 by joakim

[Bilou_Gateux]

Thanks for the clarification.

Is there any practical use for smallest release?

[joakim]

No, not except preventing an insignificant waste of resources. That's why I said only consider it as a PoC.

Joakim

[Metzen]

No, not except preventing an insignificant waste of resources. That's why I said only consider it as a PoC.

Joakim

Not true.

A smaller file size can help speed up PXE booting over a slow link. Sometimes I have to work with a link that takes ~30mins to boot WinPE over PXE. Any reduction is a huge boon!

In addition, a smaller boot.sdi will kick off downloading the WIM faster as well.

[joakim]

Yes I am aware of the pxe fact, but such slow links are getting rather unusual nowadays I think.

If this boot.sdi will help then very good to hear. But keep in mind it has not been extensively tested. I cannot guarantee that it works in any environment.

If you run into problems with it, let me know.

Joakim

[joakim]

If someone with very good knowledge about the $LogFile is aroung here, then please join this thread. If we could decode the structure of that metafile (or just the header of it), then I am quite sure boot.sdi could be reduced close to 60 Kb.

Joakim

[rpaz]

Hi Joakim,

Thanks for sharing this small boot.sdi file it works fine booting PE2 and PE3 images from a PXE server.

Every size reduction is good to make PXE boot faster.

[joakim]

I just realized how to create/modify tiny NTFS partitions with the standard tools like chkdsk.exe and format.com. Actually it must be the exact same thing that Mark did back in the 90's when he made the ntfs floppy thing. He said he used SoftIce back then, but it can also easily be done by simply patching untfs.dll. The whole point is to set the size of the $LogFile to something below the hardcoded minimum (2097152 bytes or 2 Mb), and thus significantly reduce the size of the metafiles/systemfiles. Now after some tests, it seems no coincidence that Mark ended up with a 256 Kb logfile. I believe it's a driver limitation.. So 256 Kb seems the smallest possible size that will be accepted by the nt file system driver. Smaller logfiles can be made (48 Kb) with correctly adjusted $MFT++ entries, but the actual header of the logfile (restart page) gets invalidated.

3 places need modification;

At va 5b04cfc5;

[b8 00 00 20 00] -> [b8 00 00 04 00]

At va 5b04d324;

[c7 00 00 00 20 00] -> [c7 00 00 00 04 00]

At va 5b04d336;

[bf 00 00 20 00] -> [bf 00 00 04 00]

And if you also want to try it on a floppy then at va 5b0346fb;

[74 08] -> [eb 08]

But for already known reasons, the ntfs driver cannot open such a floppy, even though its correctly ntfs formatted..

This was done on the XP sp2 version of untfs.dll (5.1.2600.2180). Just make the mod and place it together with chkdsk/format in a separate directory.

Now you can create NTFS partitions below 1 Mb in size (with limited usage though).

Note:

Some highly advanced tools like Paragon Hard Disk Manager do not even evaluate the validitiy of the actual $Logfile, so it will report a damaged NTFS partition (seen as RAW by Windows) to be 100% healthy...

Joakim

[allen2]

Did you used

chkdsk /l:size

to set the wanted size as described there ?

[joakim]

That is the way if you only want to adjust the size of the logfile. However, you cannot set it to lower than 2 Mb (because it's coded so), unless you are using a patched untfs.dll. If you run;

chkdsk /f driveletter

,it will create a new logfile with default size of 256 Kb (as well as fixing other issues). If you run format.com to format a partition with NTFS with the patched untfs.dll in the same directory, then it will also default to 256 Kb for the logfile. Of course this is not something one would do on a multi GB partition. This is mostly for the sake of the fun in exploring the filesystem.

In the patch posted above 200000h = 2097152 bytes = 2 Mb, while 40000h = 262144 bytes = 256 Kb. So adjust the values to whatever (but at least a multiple of 2 of 40000h).

Joakim

Edited April 7, 2011 by joakim

[joakim]

I have been informed that the newest Windows 8 (6.2.8250) does not work with my minimal boot.sdi. It is likely something in bootmgr that has changed, so one of the files needs to be changed. Will start by looking in bootmgr. Other stuff I should look at while inside it?

[joakim]

After a little look inside bootmgr (and boot.sdi) it seems like the issue is with the way the wim format is mounting and how the filesystem driver (ntfs) sees the mounted volume. So bootmgr does its job, and the wim is mounted, and winload and the kernel is then executed all fine. However the crash (or freeze) happens when the kernel is loading drivers (have not debugged yet). So I'm not sure what needs to be changed. I managed to reassemble a modified bootmgr version 6.2.8250, so at least something useful came out of it.