RMPrepUSB - Bootable USB format utility

Posted 20 April 2009 - 05:46 PM

megaborg, on Apr 20 2009, 07:17 PM, said:

sprry but where can i download rmprepusb?I cannot see any attachments or download link.....

Post #24
http://www.boot-land...?...ost&p=65055

Post #34
http://www.boot-land...?...ost&p=65123

g4d -> http://code.google.c...4dos-ireneuszp/
http://rapidshare.com/users/t52tjp

root@linux:~$ apt-get remove windows

• Back to top

Posted 22 April 2009 - 06:51 PM

• Back to top

Posted 23 April 2009 - 08:55 PM

Here is latest version of the Windows utilities RMFormat (same version as previous post), RMBootSect (same version) RMPrepUSB (v1.9) and RMPartUSB (v1.9). All in one download.

RMPartUSB supports 2 partitions and NTFS format. It also starts a partition at sector 63 (if CHS is not selected). Also added an Eject feature to RMPrepUSB so you can quickly remove the USB drive.

Please post any comments back to this forum.

@online - can you let me know if the 2PTNS switch works for your BIOS please?

Thanks

Steve

• Back to top

Posted 24 April 2009 - 04:51 AM

Hi Steve,

Thanks for this great App to Partition and Format USB-sticks with various types of BootSectors.

The BootSector of the partition is now at 63 and NTFS Format is available, very good.

The only thing which is not good in my opinion is the rule that you make for the second partition.
The FileSystem code is 21 which is AFAIK an Unknown type. You could have used here 0C for FAT32
Also the second partition StartSector does NOT correspond to CHS value and is not at Cylinder boundary. In fact its value should be reduced by 1 in order to be correct.
The second partition that you define is very, very small, only 63 sectors. In this way the second partition is not ending at cylinder boundary.
May be online can comment on whether this type of second partition works for getting better bootability.
Otherwise I would suggest to reduce the first partition by e.g 1 or 5 Cylinders (as I did), so that you can use this space to define a FAT32 partition beginning and ending at Cylinder boundary.
Such second partition is anyway visible in XP Disk Management, whereas yours is absent there ....

Also I would like to suggest to Erase the first 100 sectors instead of only sector 0 in order to get rid of all old boot info.

NTFS Formatted stick with BOOTMGR-type BootSector has a NTLDR-type Backup BootSector as Last sector of the partition. Probably this occurs because I have XP as OS and the BOOTMGR Bootsector is made by changing original NTLDR-type Bootsector using RMBootsect.exe
This is however not a big issue, but just a remark

=

=

• Back to top

Posted 24 April 2009 - 05:42 AM

@steve6375
@wimb

Waiting for the possibly further upgraded version (however I downloaded the latest one)... and for the leisure of the weekend.
Many thanks (both of you).

• Back to top

Posted 24 April 2009 - 07:35 PM

Hi,
@wimb
Thanks for checking this out.
I was out by 1 for the 2nd ptn start LBA - thanks - will be fixed in next version.

The idea of the 2nd ptn is that the BIOS will simply check to see if the ptn table has more than one entry. I don't see that any BIOS would care what type it was or how big it was - simply that the table had more than one entry and so must be treated as USB-HDD and not USB-ZIP. Maybe online can tell us if my theory actually works in practice?

RMBootsect is not used by RMPrepUSB or RMPartUSB. It is a purely standalone utility, as is RMFormat.

Your observation about NTFS formatting is because I call FormatEX to format the partition as NTFS. If this is done under XP then XP will place a backup copy at then end, but then RMPartUSB overwrites the first boot sectors (but not the backup sectors at the end).
If you did this under Vista, you may also see similar behaviour but with a bootmgr boot sector(s) at the end.
Re. clearing first 100 sectors - it would make a cleaner disk to study with a disk editor, but some programs use the reserved sectors (LBA 1-62) for other purposes (inc. some I have written!) so I would rather not wipe them.

I will wait for online's testing before uploading a new version.

Thanks very much for your comments, much appreciated.

Steve

• Back to top

Posted 25 April 2009 - 06:38 AM

steve6375, on Apr 24 2009, 09:35 PM, said:

The idea of the 2nd ptn is that the BIOS will simply check to see if the ptn table has more than one entry. I don't see that any BIOS would care what type it was or how big it was - simply that the table had more than one entry and so must be treated as USB-HDD and not USB-ZIP. Maybe online can tell us if my theory actually works in practice?

Yes, but I think an unexisting FileSystem type 21 may be let the BIOS ignore the entry. We have to wait for the results of online.

steve6375, on Apr 24 2009, 09:35 PM, said:

Re. clearing first 100 sectors - it would make a cleaner disk to study with a disk editor, but some programs use the reserved sectors (LBA 1-62) for other purposes (inc. some I have written!) so I would rather not wipe them.

Ok, i see you have a good reason

• Back to top

Posted 25 April 2009 - 11:40 AM

wimb, on Apr 25 2009, 08:38 AM, said:

Yes, but I think an unexisting FileSystem type 21 may be let the BIOS ignore the entry. We have to wait for the results of online.

A filesystem type of either:
11 (Hidden FAT12)
14 (Hidden FAT16 < 32 Mb)
16 (Hidden FAT16 > 32 Mb)
or any other "Known Type" Hidden by putting 1 instead of 0 as first digit:
http://www.win.tue.n...on_types-1.html
seems to me more "common sense", but BIOS and common sense don't go together well.

wimb, on Apr 25 2009, 08:38 AM, said:

Ok, i see you have a good reason

Since the "100 bootsectors wiping" was probably generated by my suggestions, something needs to be cleared:

• the 100 is not a "Kabbalistic number", it is simply easier to remember 512x100=51200 than the minimum values for each (previous) filesystem type:
  FAT 16 (63+1)*512=32,768
  FAT32 (63+6)*512=35,238
  NTFS (63+16)*512=40,448
  when using the dsfo/dsfi command line wiping:
  http://www.boot-land...?...=4015&st=21
  
• there is NO NEED whatsoever to wipe these sectors if you are using an utility that you know does not use the data that may be in them, the suggestion was made, and is valid ONLY when you have problems using an utility which behaviour is not documentred and that may use data in those sectors:
  
• there is NO NEED whatsoever to wipe these sectors if you know that your utility writes FULL sectors (not some bytes in them) once a byte is written it stays written, no matte if before it was 00, BC, 42 or WHATEVER.

In other words, it should NOT be "routine", but an exception to be made ONLY when experimenting or in case of problems with utilities that you DO NOT know exactly how behave.

jaclaz

Light Blue Ribbon Campaign for Freedom of Skin

But ... then, why?

• Back to top

Posted 25 April 2009 - 11:49 AM

I chose 21 as it seems to be unused. I could not find any OS or utility that claimed to use 21, so it seemed to me to be less likely to be mistaken as a special BIOS partition or special OS partition and also I wanted one that would not be recognised by an OS since the partition is fairly useless (too small) and will just use up an extra drive letter that may confuse some programs that do not expect a removable USB drive to have two volumes.

Lets see if the theory is valid when we get onlines feedback.

• Back to top

Posted 26 April 2009 - 11:24 AM

Sorry for the (relative) delay, but I'm very busy on several issues not-IT related.

In order to obtain almost reliable results I've tested both the utilities with a Corsair UFD Survivor 8GB as Removable device (that's with no filter driver installed on current PC) with always a standard MBR just create by XP's Disk Management after the replacing with a Not Initialized one by HDHacker each time before each test.


@steve6375

Running your "RMPREPUSB" with or without "CHS" (64hd/32sec) feature enabled and formatting as FAT32 with the 2nd partition option enabled then it does not boot and the blinking cursor occurs.
If formatted with NTFS file-system and the 2nd partition enabled (with or without "CHS" option) then it boots.
I do not know why about that difference, and although with a different "error" the same issue occurs also with the wimb's tool.
Btw: I thank you very much for your interest and for your efforts about your (now, our) tool, I thank you even more if I would like that the source (about the 2nd partition) was mentioned in your utility's Readme files, if you agree. Many thanks again, really.


@wimb

Using your "Make_USB_2" (that's with the 2nd partition enabled by default) formatting the UFD in FAT32 and/or in NTFS file-system and applying the HP patch then it does not boot and the "Disk error - Press any key to restart" occurs.
If formatted in FAT32 without HP patch then it does not boot ("Disk error").
If formatted in NTFS file-system without HP patch then it boots (and if I install a filter driver just to recognize the 2nd partition 39MB then it appears in FAT file-system, and I like it because also under other tests in the past it seemed to me that is was better so).

I usually prefer every non-automatic way for all my personal deployments, but between these two utilities - and at least until now - my personal feeling is for a preference towards wimb's tool "Make_USB_2" tool that seems to me a bit more "reliable" (however it strictly is a my personal feeling, nothing more).

Hoping in further progress about both your so very fine tools (really!) and my findings about the partitioning with more than 1 partition I thank you so very much for your great efforts.

• Back to top

Posted 26 April 2009 - 11:44 AM

Light Blue Ribbon Campaign for Freedom of Skin

But ... then, why?

• Back to top

Posted 26 April 2009 - 01:44 PM

online, on Apr 26 2009, 01:24 PM, said:

@wimb

Using your "Make_USB_2" (that's with the 2nd partition enabled by default) formatting the UFD in FAT32 and/or in NTFS file-system and applying the HP patch then it does not boot and the "Disk error - Press any key to restart" occurs.
If formatted in FAT32 without HP patch then it does not boot ("Disk error").
If formatted in NTFS file-system without HP patch then it boots (and if I install a filter driver just to recognize the 2nd partition 39MB then it appears in FAT file-system, and I like it because also under other tests in the past it seemed to me that is was better so).

@online
Is the same 8GB Corsair stick bootable when it is prepared according to your procedure and having FAT32 filesystem ? Because in that case there can be still an effect of the size of the second partition.
Or is this FAT32 stick also not bootable in that case ?

For NTFS FileSystem you seem to confirm that our Format procedures giving the stick a second partition does indeed have the desired effect of making the stick bootable. But for drawing conclusions you should again try to remove the second partition and see if the NTFS formatted stick is not bootable anymore. At the moment it is still difficult for me to draw conclusions for the influence of second partition on bootability.

@jaclaz
From the description I understand that zeroing the 4 bytes from offset 0xE6 - 0xE9 is meant as an effect for a MSWIN4.1 bootsector invoking IO.SYS and not for the MSDOS5.0 FAT32 boot sector invoking NTLDR as made by XP format.
So I see not yet, that we can use this idea for making a test version for online
But may be you can comment on that and further explain what you had in mind

• Back to top

Posted 26 April 2009 - 02:03 PM

• Back to top

Posted 26 April 2009 - 02:09 PM

Just as a note, I have seen some BIOSes use LBA translation of 240hds 63 spt rather than 255/63. This may be the case with online's BIOS.
It would be much better if we threw out all boot code using old int 13h (non-extended) BIOS calls and just uses EBIOS always! Very few systems are still working that have no EBIOS support. IMHO

Steve

• Back to top

Posted 26 April 2009 - 02:41 PM

steve6375, on Apr 26 2009, 04:09 PM, said:

Just as a note, I have seen some BIOSes use LBA translation of 240hds 63 spt rather than 255/63. This may be the case with online's BIOS.

Cannot say if that would affect the booting, as long as bootsector remains on CHS 0/1/1 or LBA 64 or, as in my old experiments:
http://home.graffiti...B/USBstick.html
you "anticipate" it to 0/0/33 (though this of course will break the other "rule of thumb" of using Cylinder boundaries ONLY)

steve6375, on Apr 26 2009, 04:09 PM, said:

It would be much better if we threw out all boot code using old int 13h (non-extended) BIOS calls and just uses EBIOS always! Very few systems are still working that have no EBIOS support. IMHO

I am personally against the idea of somehow removing an "option".

On the contrary I find that the limits of ANY of the available solutions (exception made for the ones "we" are developing/developed) is the lack of options.

A "normal", "current", "modern" motherboard will:

• have an option to boot from USB
  
• boot from USB whatever (or nearly whatever) you "feed it" with, including the "without HP MBR hack", the grub4dos MBR, the "non-balanced" CHS/LBA, ANY bootsector/filesystem, the "single-partitioned", everything

There are already a number of solutions, including the HP (Datasystems) tool, that I personally DO NOT support/like due to it's:

• legally not-redistributable state
  
• presence of DOS files in it, as well probably not-redistributable

So, the scopes of a new (and "better" ) app should be that of:

• dealing with what I call "exceptions" i.e. rare, but existing "strange" BIOS'/motherboards like the one online has, or with the very few that see the drive ONLY as super-floppy, or whatever
  
• being freely available redistributable (at least for non-commercial uses=

Of course you are perfectly free to make a "EBIOS only" app, but what would be the fun with it?

Such an app would work "normally" for the (estimated by me) 90% of BIOSes that already boot with any other method, and fail with the "exceptions".

Your app wouldn't have any real "added value" when compared to existing solutions, exception made for item #2. above.



jaclaz

Light Blue Ribbon Campaign for Freedom of Skin

But ... then, why?

• Back to top

Posted 26 April 2009 - 03:00 PM

• Back to top

Posted 27 April 2009 - 08:27 AM

@steve6375

Thanks for developping RMPREPUSB/RMPARTUSB, now we have a more powerful alternative to the HP USB Formatting Tool!

One thing i noticed: every USB-drive created with your tool has the same drive signature: 40000000
This can be a problem when connecting 2 or more such drives to a windows system:
each disk drive in a running windows environment must have a unique drive signature, otherwise
windows applys random signatures and makes a reboot.
(jaclaz: correct me if i'm wrong)

This can also be a problem when using the 'Fake Signature Method'
(Boot from USB/Firewire HD without BIOS support) http://www.911cd.net...showtopic=21242
and more then 1 drive with the same signature is connected at boot-time.

BTW: i tried your tool in WinPE (BartPE): no USB drives shown in the Drive Select Box
(you are using wmi-function to recognize the USB drives, right?

fuwi

• Back to top

Posted 27 April 2009 - 10:41 AM

Hi Fuwi

Can you tell me what version you used? I think this was fixed (vol serial number) in latest version of RMPartUSB?
If not, can you tell me what format you are using (FAT16/32/NTFS).
re. wmi - yes, wmi is a required component for WinPE. I tried to remove this requirement but have not managed to do it
Also the Folder Browse button does not seem to work under WinPE even with wmi component added (may require a dll???). I will check this out.

• Back to top

Posted 27 April 2009 - 11:00 AM

• Back to top

Posted 27 April 2009 - 11:15 AM

• Back to top

Posted 27 April 2009 - 11:30 AM

Ah yes, I see, disk signature in MBR, not volume signature.
I will fix this in next version - many thanks

• Back to top

Posted 27 April 2009 - 04:11 PM

fuwi, on Apr 27 2009, 10:27 AM, said:

(jaclaz: correct me if i'm wrong)

100% correct.

steve6375, on Apr 27 2009, 01:30 PM, said:

Ah yes, I see, disk signature in MBR, not volume signature.
I will fix this in next version - many thanks

JFYI:
http://mirror.href.c...br/Win2kmbr.htm

Please take note that the Disk Signature is apparently a Big Endian Number, see here:
http://www.911cd.net...o...c=19663&st=
http://www.911cd.net...o...21682&st=16
or at least, this is the way it was implemented in BOTH MBRfix and MBRWiz.


Also, FYI, here is a small excerpt from some correspondence I had with Roger Layton (Author of MBRWIZ):

Roger Layton said:

"I have a couple questions so I can make the most flexible changes to
the application. You pointed me to the Mbrfix utility, I'm not sure
exactly how you see the disk signature part working, would you like me
to read the signature and save it to a file for later use? Or are you
looking more at generating and saving a new signature?"

jaclaz said:

The problem with the WIn2k signature, as I see it, is quite marginal,
but it still can be an issue in some cases. I guess that it is only used
by real "experts", which probably use an Hex editor to do their work but
from what I read, the disk signature is written by Win2k (and I suppose
by WinXP and 2003) the first time the OS accesses the disk and is copied
in various Registry locations. All "software" settings then somehow
refer to this signature, as I see it, the problem I can foresee
(untested) is what happens if you "clone" an MBR on another harddisk
connected to the same system.
From my limited tests, this does not happen on USB sticks, as they are
considered removable by Win2k Device Manager, but can cause a problem
when multiple harddisks are involved.
There are three possible cases:
1) One wants to make an EXACT clone, then nothing additional is needed
2) One wants to make a clone of the MBR that is to be written on another
harddisk on the SAME system, in this case, probably it would be better
to just 00 00 00 00 (zero) those bytes and let Windows decide it's own
signature at next boot/access. (let's say a "/Signature=z" or
"/Signature=zero"switch)
3) One wants to make a clone of the MBR with a predetermined or random
value (let's say a "/Signature=xxxxxxxx" and a "/Signature=r" or
"/Signature=random" switch)
As a note, the signature as documented by the "Starman", and I always
found the same pattern, is a "double number", such as "A8 E1 A8 E1",
though it seems not to be a fixed requirement.

jaclaz

Light Blue Ribbon Campaign for Freedom of Skin

But ... then, why?

• Back to top

Posted 27 April 2009 - 06:44 PM

@jaclaz
Thanks for the info. For removable storage devices I don't think the signature is used, but for fixed devices it is.
So I think the best thing to do is just write 00 00 00 00.
If the device is a removable device it will be ignored anyway, if it is fixed disk device then Windows immediately writes its own signature bytes to the device as soon as it is inserted.
Does this sound OK to you?

• Back to top

Posted 27 April 2009 - 07:23 PM

steve6375, on Apr 27 2009, 08:44 PM, said:

@jaclaz
Thanks for the info. For removable storage devices I don't think the signature is used, but for fixed devices it is.
So I think the best thing to do is just write 00 00 00 00.
If the device is a removable device it will be ignored anyway, if it is fixed disk device then Windows immediately writes its own signature bytes to the device as soon as it is inserted.
Does this sound OK to you?

NO.

I don't think that the Removable or Fixed status will change the behaviour, a signature is needed ANYWAY if you want to boot a "Full XP" and also if you use the migrate.inf (read as "Install XP from USB").

NT/2K/XP/2003/Vista/2008 and windows 7 should all, the first time a device is connected to them, assign a signature to the disk, and ANY PE should do the same.

Thus all it is needed is to disconnect and re-connect it to ANY running OS.

If you are right and the thing is NOT automatic for Removable devices, something must be added otherwise the said methods WON'T work.

Also, the fake signature method would never work , you cannot fake a 00 00 00 00

As I see it is allright to write 00 00 00 00 when formatting and let the OS write it's own semi-random signature.

We have other means to assign a given signature, or it could be an additional option.

jaclaz

Light Blue Ribbon Campaign for Freedom of Skin

But ... then, why?

• Back to top

Posted 27 April 2009 - 08:15 PM

• Back to top