375 replies to this topic

[Motasem]

...

[Akeo]

CHKDSK is verifying indexes (stage 2 of 3)...
Correcting error in index $I30 for file 69.
Correcting error in index $I30 for file 69.
Correcting error in index $I30 for file 69.
Correcting error in index $I30 for file 3151.
Correcting error in index $I30 for file 3151.
(...)
Errors found.  CHKDSK cannot continue in read-only mode.
Error while checking disk.

Your USB is bad and you should feel bad.

Maybe the reason other tools appear to work is that they don't verify the filesystem after creating the drive, as Rufus does?
That would also explain why the app exits when you run a check (though I don't quite understand what you are saying - there is no "check writer" anywhere in Rufus).

At this stage, considering that in more than 300,000 downloads of Rufus for this year so far, you are the only person to report these issues, I can only advise you to do the following: Please try another USB flash drive and use the "Check device for bad blocks" during the formatting.

Unless you can confirm that another supposed good flash drive has the same issue, I can only conclude that your problem has to do with bad hardware (checkdisk is not supposed to report errors if your flash drive is good) or something with your system configuration.

[steve6375]

If using any new flash drive, you should first check it...

 

1. Use the RMPrepUSB Quick Size Test (this will destroy all data) - if OK then...

2. Use RMPrepUSB to format the whole volume (single partition max size) - or use Windows to format it

3. Download and run H2TESTW (link is in RMPrepUSB F1 help form) - it is slow but tests all sectors in the volume

[Motasem]

Akeo & steve6375

 

well lets say as you said "Maybe the reason other tools appear to work is that they don't verify the filesystem after creating the drive"

 

in fact this sentence is not reasonable because lets say all apps don't check !!! its okay but i must have errors in all because windows installation is so restrict for files integrity correct ?

 

and if it was 1 app its okay but im talking about 4  success apps "win2flash,xp iso boot with g4d.SARDU,Eazy2boot" and some based on iso booting and some on flat files so if there's any problem i must get errors "all apps tested with same winxp copy"

 

"you are the only person to report these issues"   so im the winner

you mean to tell me that "300,000 downloads of Rufus" NONE of them has used

corrupted usb or got Bad-blocks    !!!!!!!!!!

 

just to make things clear for you and help you know where the shot is see this report.
 

http://grabout.com/taMP2wQH

 

http://grabout.com/c33rQoIh

 

so what you think ?

[Wonko the Sane]

Just for the record, this is not the first time that Motasem's stick does this (presuming it's the same stick ) see:

http://reboot.pro/to...e-2#entry170011

http://reboot.pro/to...e-2#entry170027

 

It can well be some kind of "intermittent" problem.

 

Wonko

[Motasem]

in shot words my friend steve

 

do you see any errors in this usb ?

[Akeo]

Well, you're implying that Rufus is somehow creating corrupted USB drives whereas other applications do not, and what I am saying is that, if that is the case, then hundred of thousand of people must not be seeing that happening, because NONE of them have been reporting such an issue so far.

I'm providing plenty of ways for people to report problems with Rufus: This forum, the github tracker as well as an e-mail link on the homepage, so it's unlikely that people wouldn't be reporting this issue if it was a general problem.

So what's the logical conclusion then? That Rufus has a bug when it comes to NTFS formatting and USB checking, but the hundred of thousand of people who have been using Rufus haven't encountered it? Or that you are using Rufus in a special situation, where either your USB drive or your environment has an issue.

Also, you still haven't answered my question about seeing what happens when using another drive.

As to people using with bad flash drives, I have had reports of successful detection of bad blocks in these situation (without rufus crashing or anything bad happening).

If you feel that Rufus has a bug, you should first try to prove it by confirming that the same issue occurs with different flash drives and when Rufus is run from 2 completely different machines. Until you do that, I have no choice but to dismiss your issue as environmental, as I haven't seen such an issue when testing on my side, and I haven't received any other reports from Rufus users.

[Akeo]

I'll add that if your issue is with your target's BIOS not booting an USB drive created by Rufus, then yeah, there are known BIOS incompatibilities and since I'm not using the same method as everybody else, I wouldn't be surprised if there are situations where an XP installer created by Rufus will not boot where others will work. Obviously, since these reports are far and in-between, I'm not planning to spend much time trying to reverse engineer BIOSes to find what they're doing that makes the boot process fail. There's plenty of other boot creation tools for XP, so you can just try those.

[steve6375]

Another possibility is that there is data corruption during data transfer.

Are you using USB cables? Have you tried plugging the USB drive directly into the back USB ports? How many different systems and stick have you tried?

[Motasem]

usb is directly connected to pc i dont even have ext hub

 

i have tested this on 2 sticks 16g and 4g .... and im sure both working and healthy and passed all test apps

 

tested on desktop and laptop

[Motasem]

Akeo "There's plenty of other boot creation tools for XP, so you can just try those"

 

what does this means ? sorry maby i misunderstand you...

[Akeo]

im sure both working and healthy and passed all test apps

Do you get the Checkdisk errors on all the drives and the machines you tested with then?

The fact that the checkdisk invoked by Rufus fails seems to indicate that at least the drive you tested it at the time isn't healthy. Considering that Rufus isn't doing anything fancy in terms of formatting the drive and copying the XP files (we're using the exact same APIs as if you were to format and copy the files manually), there's really no reason for checkdisk to fail apart from a hardware issue, and given that you are the first person with a supposedly healthy drive to report that they are seeing errors with checkdisk during Rufus operations, the most logical explanation is that at least one of your drives is not as healthy as you think it is.

Unless you are consistently seeing checkdisk errors for both your drives, and on all the machines you tested with, we have to ignore whatever drive is producing the errors, even more so as you also indicate that trying to check bad blocks with Rufus makes the application crash (which would be consistent with a bad flash drive).

Now, if both your machines and your different flash drives produce checkdisk errors, you will have to tell me what options you use, and what is special about your environment, because I can't reproduce that issue on any of the test systems and flash drives I have.

For reference, this is what I get in the Rufus log when I format a drive with XP SP3 (using the "Add fixes for old BIOSes" option, since your log shows that you checked this, due to presence of the extra partition. I assume you have also tried without checking that option, right?)

Succesfully added 'SetupSourceDevice = "\device\harddisk1\partition1"' to H:\txtsetup.sif
Patching file H:\BOOTMGR
  0x000226CA: '\minint\txtsetup.sif' -> '\i386\txtsetup.sif'
  0x0002275E: '\minint\system32\' -> '\i386\system32\'
  0x000226A3: '$WIN_NT$.~BT' -> 'i386'
  0x0002277F: '$WIN_NT$.~BT\' -> 'i386\'
  0x0003763B: 'rdisk(0)' -> 'rdisk(1)'
  0x0003765F: 'rdisk(0)' -> 'rdisk(1)'
  0x00037723: 'rdisk(0)' -> 'rdisk(1)'
Finalizing...
H:autorun.inf already exists - keeping it
Successfully remounted Volume{57a71f64-4204-4af3-9d3c-c6ec8be80103}\ on H:\
NTFS Fixup (Checkdisk)...
Volume label is GRTMPFPP_EN.

CHKDSK is verifying files (stage 1 of 3)...
  7424 file records processed.

File verification completed.
  0 large file records processed.
  0 bad file records processed.
  0 EA records processed.
  0 reparse records processed.

CHKDSK is verifying indexes (stage 2 of 3)...
  7790 index entries processed.

Index verification completed.

CHKDSK is verifying security descriptors (stage 3 of 3)...
  7424 file SDs/SIDs processed.

Security descriptor verification completed.
  183 data files processed.

Windows has checked the file system and found no problems.

  30869432 KB total disk space.
    632988 KB in 7065 files.
      1800 KB in 185 indexes.
     74316 KB in use by the system.
     65536 KB occupied by the log file.
  30160328 KB available on disk.
      4096 bytes in each allocation unit.
   7717358 total allocation units on disk.
   7540082 allocation units available on disk.
NTFS Fixup completed.
Found drive 'ADATA USB Flash Drive USB Device'
1 device found.
Sector Size: 512 bytes
Cylinders: 3843, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 2
Disk ID: 0x025683AC
Partition 1:
  Type: NTFS (0x07)
  Size: 29.4 GB (31610299392 bytes)
  Start Sector: 63, Boot: No, Recognized: Yes
Partition 0:
  Type: Hidden NTFS (0x17)
  Size: 31.5 KB (32256 bytes)
  Start Sector: 61738929, Boot: No, Recognized: Yes

Now, if the checkdisk error was only occurring with one flash drive, and you are still having a boot issue when using your other flash drive, despite not having any checkdisk errors, then I guess that it is indeed possible that the way Rufus attempts to boot XP may not work, in which case this may be a boot setting issues. For instance, if you have more than one HDD on the machine you are trying to install XP on, you should either disconnect any drive that you are not going to install XP on, and use the default Rufus options, or change BIOS ID in the advanced options.

If this still doesn't work, especially if you only have one disk connected to the target system, then the issue is probably due to an incompatibility between your target's BIOS and the custom MBR that Rufus installs for booting XP. In that case, and to answer your last question, you should try an installation method for XP that doesn't rely on a custom MBR, such as the one that RMPrepUSB, UNetbootin and possibly Universal USB Installer are using. I'm sure other people following this thread can fill in with some other tools that may do the trick.

[steve6375]

Hi Akeo

I wanted to ask you about the boot code that you use in LBA 0 for rufus. 

The first few bytes seem to be

 

 

0000 41 4B 45 4F FC 31 C0 FA - 8E D0 BC 00 7C FB 89 E6  AKEOü1Àú ŽÐ¼.|û‰æ

 

I thought that when a BIOS boots from a device, it will load the first sector into memory and then jump to the start of that sector's code in memory.

I notice that your code starts with the ascii string AKEO rather than the normal jmp op code. I noticed this because RMPrepUSB does not recognise the sector as a valid MBR due to the lack of a jump instruction. Could you explain how this works please and also what is the MBR code that you use. Does it do anything that a normal MBR does not?

Thanks

Steve

[Akeo]

Hi Steve,

The details of my MBR are all here. Have a look at the "Primer" for a breakdown of what the Akeo MBR does.

 

As to why it starts with "AKEO", this is because I was, and am still quite proud to have managed to add all the features I want into an MBR, with a few extra bytes to spare. Plus, there's a certain satisfaction to know that the very first instructions that someone will execute after BIOS handover, if they boot from a drive created by Rufus, will spell 'AKEO'.

These instructions don't really do anything (none of the registers modified have data that needs to be preserved) and I sneakily called it "Register fixup" in the code and set them as instructions to make it a bit less explicit... You're actually the first person to report about it!

 

Now, this MBR still has jumps, but unlike a regular MBR, since we want to prompt the user on that, it first needs to figure out what sector it should use for the jump, so the jump occurs late rather than early.

 

As to why RMPrepUSB does not recognise the sector as a valid MBR, and since I don't believe there are any guidelines as to how an MBR should be written (especially since there's only so much you can do without optimizing as much as you can in less than 512 bytes of code), I would suggest that the RMPrepUSB detection code needs to be updated.

 

For the record, the Akeo MBR is very similar in concept to the bootblock that Microsoft uses on the XP ISOs, so I'm pretty sure that RMPrepUSB will equally fail to recognize that Microsoft bootblock as valid.

Of course, RMPrepUSB probably doesn't care about recognizing ISO bootblocks, but please be mindful that there might be additional boot signatures out there...

[steve6375]

Thanks, very interesting!

[steve6375]

If anyone has made a Rufus XP install USB drive but wants to add it to their multiboot grub4dos USB stick, here is how to do it.

[Motasem]

Thanks Steve.

[alacran]

  Good, well done, a single tool to make a single ISO install or run, good use for my old small size USB sticks.  I have one 4GB, two 2GB and one 1GB just to play with, any way I also like multiboot with Grub4dos wich is in a 16GB stick (exFAT formated) with several ISO's (Full to the top now), all my VHD's are in a 2.5 " USB HDD that can be booted using Windows bootloader or Grub4dos, now is time to start learning UEFI booting USB devices but that's another history.

 

I'm telling you all this in order to make clear to every body there is room an good use for this tool even if you like multiboot tools.

 

I'm quite shure every body has more than one USB stick out of use, just because you got a biger one in a good price.

 

Thanks for your nice little GREAT TOOL

Edited by alacran, 30 March 2013 - 10:09 AM.

[renee]

Please let me know when you do...

 

Renee

[alacran]

Done...

[colchaodemola]

Hi, i created a windows xp sp3 usb using rufus but everytime i try to install i get ''can not detect windows previous version and can not check if they are qualified to install this upgrade , press f3 to exit'

I am sure i don't have problems with the ISO because i can install just fine from the burnt cd. Is this a known problem ? Is there any workaround ?

Thanks !

Edited by colchaodemola, 05 June 2013 - 10:34 AM.

[Rui Paz]

Hi,

 

Sorry if this question was already asked but I could not find the answer on the forum...
 

Can the message "press any key to boot from USB" be removed from the mbr used by Rufus? Any option to change this?

 

TIA.

[Akeo]

Can the message "press any key to boot from USB" be removed from the mbr used by Rufus?

 

Yup. All you need to do is click on the white arrow next to format options, and uncheck the box "Use Rufus MBR with BIOS ID:"

If you do that, then the standard Windows MBR will be used, which won't prompt you to press a key.

 

Of course, this means that you will need to manually remove the USB for the second stage Windows installer, as this is the whole point of the "press any key" message...

[Rui Paz]

Hi Akeo,

 

No problem the manual remove isn't needed because its for a Live PE and not for install.

 

By the way your tool rooks and its very friendly to use.

 

Thanks.

[Akeo]

Thanks. I'm glad you like it.

 

By the way, I have just uploaded a new beta (BETA 3) for the upcoming Rufus v1.3.4. Compared to the last beta, this adds UDF formatting support (for Vista and above) and also fixes a few minor bugs that I discovered.

As usual, the download is available here.