About boot.ini, wouldn't a good old batch file be more than enough?
I normally run Win2K, coming with experience on NT4, never used bootfix.bin in my life, just the old way with batches, here are some examples, but of course we need to modify them according to our needs, it won't be difficult once I understand what they are.http://www.msfn.org/...topic=66101&hl=
One could easily search for a "tag file" like a file that is only in %windir% on all drives, and prompt the user to confirm the entry or entries.
Just let me know which "features" are required.
BTW Roadkil's Disk Image v1.1 always gives me "image creation failed" with all USB sticks I have, formated by various tools, most of the time I can see progress going beyond 100%, i.e. 102, 105 and I completely stopped using it as a backup solution.
Yep, that's perfectly normal, as, as seen in the case you posted, the real size of the stick differs from what is "declared" or at least from what Windows can "see".
To calculate the percentage of progress, rather obviously the programmer needs to calculate in "real time" the amount of data transferred divided by the total amount of data, the algorithm Roadkil's Disk Image uses is something like (in VERY "pseudo"code):
If exist source\sector(N) do Copy source\sector(N) dest\sector(N) else goto :end
So, when N becomes bigger than SOURCESIZE, the number displayed becomes bigger than 100%, and it is probable that there is some check control that throws an error because the program thinks it has copied more data than available.
I would be curious about a comparison between image size results coming from the use of Roadkil's, Acronis and with dsfi/dsfo, part of the DSFOK toolkit:http://members.ozema...eezip/freeware/
(command line, but VERY accurate, that, not having the check hypothized above, does not throw any error)
2,046,820,352 should then be the "real" size of the stick, this corresponds to the CHS end address of 248
/31, this means that maybe, instead of "topping" to MaxCyl, the (wrong) partitioning simply takes 1 off BOTH NumCyl and NumHds.
On a different geometry, like Nx128x32, End address of 2,046,820,352 would be exactly CHS 976/0/32, i.e. a "correct" Head boundary one.
The maximum "correct" CHS address in a 248x255x63 geometry remains however 247/254/63, which leaves you with 2,046,820,352-2,039,837,184=6,983,168 bytes or 13,639 sectors not accessible/unused.
Yep, if we find a way to invoke setupldr.bin directly from BOOT.INI GRUB will be no longer needed. At the moment if it is called, result was restart as far as I remember, because stick at that time is initialized as hd1, perhaps newer or HEX edited versions of these files will avoid it, but that's beyond my capabilities.
I don't think patching MBR will be of any use at this stage, it should be setupldr.bin or ntdetect.com which cause that reboot. I will redo the tests and will report what may be causing reboots later.
No need to patch the MBR, all the "fun" happens in the bootsector, as cdob pointed out.
If I am "allowed" to use dsfi/dsfo above, I can put together a small batch file that:
1) gets the bootsector from the stick and makes a copy of it
2) patches the copy so that it is invoking SETUPLDR.BIN
3) adds an entry in boot.ini directly chainloading the modified bootsector
I have used similar batches in the past, they work for both FAT16 and FAT32, using it for NTFS might need some more work, but the USB device is normally FAT16 (or 32) anyway, isn't it?