Jump to content











Photo
- - - - -

Rufus v1.3.0 has been released


  • Please log in to reply
208 replies to this topic

#126 steve6375

steve6375

    Platinum Member

  • Developer
  • 6641 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2014 - 02:19 PM

Try formatting the stick using RMPrepUSB - Boot as HDD(2PTNS) + WinPE v2 BOOTMGR + FAT32 or NTFS.

Then use Rufus to copy the files over (without formatting).

 

memtest is completely different format than normal Windows partition.



#127 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 05 March 2014 - 03:37 PM

Thanks for your replies, Steve,

 

I've followed your instructions (using RMPrepUSB 2.1.716) and now I get to a "Windows Boot Manager" screen where I can read the text:

Windows failed to start. A recent hardware or software change might be the cause. To fix the problem:

 

1. Insert your Windows installation disc and restart your computer.

2. Choose your language settings, and then click "Next."

3. Click "Repair your computer."

 

If you do not have this disc, contact your system administrator or computer manufacturer for assistance.

 

File: \Boot\BCD

 

Status: 0xc000000e

 

Info: An error occurred while attempting to read the boot configuration data.



#128 steve6375

steve6375

    Platinum Member

  • Developer
  • 6641 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2014 - 03:56 PM

See if you get the same result using RMPrepUSB.
Make an NTFS, Bootmgr, Boots as HDD(2PTNS) USB drive. Set the 5 Copy files box to point to the ISO file and click 6 - Drive Prepare.
Now boot it - do you get the same result?
If so there is something wrong with the ISO or something wrong with the USB drive (did you test it?).



#129 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 05 March 2014 - 04:13 PM

Yes, same result. The exact same error message.

 

I've unplugged the USB stick from this mainboard and I've made a small tour around my office, trying to boot other computers.

 

This stick has been successful in booting all of them (I tested six computers in total, a mixture of ASUS, Gigabyte and MSI mainboards).

 

It only fails with the stubborn AsRock P4i65G motherboard :(



#130 steve6375

steve6375

    Platinum Member

  • Developer
  • 6641 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2014 - 04:26 PM

OK - a wild experiment....

 

Install grub4dos to the working USB drive using RMPrepUSB - Install grub4dos - install to MBR.

Press F4 in rmprepusb and add

errorcheck off
usb --init
chainloader /bootmgr

Now check it boots OK in QEMU or on another system.

 

Now add grub4dos 0.4.6a grldr file from here (link now fixed) and overwrite existing grldr.

Any better ?



#131 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 05 March 2014 - 05:05 PM

Exact same error with grub4dos installed by RMPrepUSB :(

 

However, QEMU and the other six computers boot perfectly fine.

I'm going to download the newer grub4dos 0.4.6a and will report back



#132 steve6375

steve6375

    Platinum Member

  • Developer
  • 6641 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2014 - 05:09 PM

Exact same error with grub4dos installed by RMPrepUSB :(

 

However, QEMU and the other six computers boot perfectly fine.

That was expected. It's the new grldr we are testing which has it's own usb driver to replace the BIOS USB driver.



#133 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 05 March 2014 - 05:14 PM

SUCCESS!!! YAY!!!!

I've replaced the grldr with the newest 0.4.6a version here, 2014-01-17:

https://code.google..../downloads/list

 

And it DOES work!! Yeeeah!! That means that I'm going to be able to install Windows 7 from a USB pendrive on this dreaded mainboard!

 

It's great, because this computer has a broken DVD reader, and I didn't want to buy a new one.

 

Thank you, thank you, thank you!!



#134 steve6375

steve6375

    Platinum Member

  • Developer
  • 6641 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2014 - 05:24 PM

That's good news!

The new grldr looks like it is going to be very useful for buggy BIOSes with poor USB support. :clap:

I have an EeePC which gives errors when booting Easy2Boot as it cannot access sectors past 137GB on the USB 2TB drive. With the new grldr it boots without error.

 

Sorry for bad link This one is latest and much better for USB support.



#135 TheHive

TheHive

    Platinum Member

  • .script developer
  • 4138 posts

Posted 08 March 2014 - 10:11 AM

Tested rufus-1.4.5.exe on following test.

Worked as expected. Thanks! :1st:

http://reboot.pro/to...stuff/?p=182664



#136 Akeo

Akeo

    Frequent Member

  • Developer
  • 303 posts
  •  
    Ireland

Posted 15 March 2014 - 02:31 PM

Here's to a quick beta for Rufus 1.4.6, which I'm planning to release in about 48 hours, mostly because of the vesamenu.c32 issue below that likely prevents proper boot of isolinux based images with an obsolete vesamenu.c32.

 

The current changelog is as follows:

  • Display USB size in the dropdown list (NEW)
  • Add Bulgarian translation, courtesy of Krasimir Nevenov
  • Improve checkbox handling in the UI and fix UDF/exFAT formatting issues
  • Fix replacement of obsolete vesamenu.c32 (reported by Liang)
  • Fix an issue that could prevent the download of files from the Rufus website
  • Fix untimely libcdio messages when processing Rock-Ridge ISOs (such as Ubuntu ones)

The BETA can be downloaded here.



#137 Akeo

Akeo

    Frequent Member

  • Developer
  • 303 posts
  •  
    Ireland

Posted 17 March 2014 - 09:52 PM

And Rufus 1.4.6 has now been released. Same changelog as above. Enjoy!



#138 ianst

ianst

    Newbie

  • Members
  • 20 posts
  •  
    Austria

Posted 19 March 2014 - 04:51 PM

A small report of Rufus use, many thanks to Akeo for making it.

 

I've tried using the newest Rufus and trying to copy CentOS-6.5-x86_64-bin-DVD1.iso to the USB as DD image, as the substitute for 

 

http://wiki.centos.o...stallFromUSBkey

 

their recommendation to use "Win32 Disk Imager." I believe they use  "isohybrid" for that image: 

I guess they used "isohybrid" as described here: http://www.syslinux....hp/Doc/isolinux

 

My attempt nevertheless resulted in Rufus switching to the ISO mode and copying file after file. I believe copying of the image at once would be faster and with less rewrites to the stick, as there are many thousands of the files in the image. I don't know if the DD mode is what is supposed to achieve that or if such images are supposed to be supported at all by Rufus at this moment.

 

Alternatively, it's possible to copy the whole file using RawCopy from Olof (as in the another thread here http://reboot.pro/to...physicaldrive3/) but it's not trivial, I had to delete the existing volume on the USB stick before I was able to do the copying.


Edited by ianst, 19 March 2014 - 04:54 PM.


#139 Akeo

Akeo

    Frequent Member

  • Developer
  • 303 posts
  •  
    Ireland

Posted 19 March 2014 - 07:17 PM

My attempt nevertheless resulted in Rufus switching to the ISO mode and copying file after file.


Yes. Given the choice, Rufus will default to file copy mode rather than DD mode for ISOhybrid images, because it makes more sense:
  • DD mode might not allow you to alter the files, after are copied over
  • DD mode will limit the size of the partition to the size of the original ISO. This means that if your ISOHybrid is 4 GB, and you copy it to a 32 GB UFD, you will lose 28 GB of space on your flash drive. And because it's a removable drive, even if you were to create an extra partition for the 28 GB space, Windows won't let you access it, so this is really lost space.
All in all, given the choice, it makes a lot more sense for users, especially the ones that may not be tech-savvy, to be presented with a writable partition that occupies the whole space of their flash drive, and that contains modifiable file contents. Else, I'm pretty sure I'll have to spend a lot of my time answering: "Why does Window say my flash drive is only X GB after I used Rufus, when it should be a lot bigger than that?"
 

I believe copying of the image at once would be faster and with less rewrites to the stick, as there are many thousands of the files in the image


Copying a straight image is indeed (usually) faster.
However the assumption that it will use less rewrites is wrong.

Unless you have a lot of files smaller than 2 KB (the size of an ISO block), which I doubt is the case for this image (if it's a set of Linux packages, they're not going to be that small) then writing a 10,000 files separately or writing an straight image that contains 10,000 files will use about the same amount of blocks on the target, and therefore the same amount of writes will have been issued for the flash. In other words, you're not going to extend the life of your flash drive by writing a single large file instead of a multitude of small ones - as far as the flash itself is concerned, it's pretty much the same amount of writes, and therefore the same amount of wear and tear.


This being said, I may add a cheat mode switch the preference for DD over isolinux, for advanced users, in a future version of Rufus, but that will probably be about it...

#140 ianst

ianst

    Newbie

  • Members
  • 20 posts
  •  
    Austria

Posted 20 March 2014 - 11:55 AM

The rewrites I assume happen are the ones being made as the updates to the file allocation table and to the directory records. As far as I understand Windows has a special treatment of the USB devices, as they assume the users won't unmount them but just plug them out. Therefore the updates to the both structures (not the writes of the file blocks) have to be performed often enough, exactly how often I haven't tried to analyze, but I'm quite sure that at least as soon as every new file is closed. That's at least one update to the file allocation table and one to the directory. I believe the difference should be observable: take any big set of files, measure copying of them to the stick when done one by one. Then make one plain  .tar (uncompressed) out of them, copy the tar. I haven't performed any exact measurements however.

 

I fully agree with you that it's much more convenient for the user to be able to modify the content of the partition and add the files to the rest of the stick and I've just believed DD option had another semantics. I assumed the program is able to recognize the format and that DD option was not the program what the input format is but the mode of the operation.


Edited by ianst, 20 March 2014 - 11:55 AM.


#141 Akeo

Akeo

    Frequent Member

  • Developer
  • 303 posts
  •  
    Ireland

Posted 20 March 2014 - 07:27 PM

You'd be surprised by the amount of caching and buffering Windows does when accessing mass storage devices (something I actually had to fight in Rufus when the user cancels an operation, as Rufus does not do anything to force synchronous operations with the UFD).

 

A lot of Windows I/O is optimized to reduce the amount of Read and Write operations, so, unless you can back it up, I am exceedingly dubious about your statement that Windows will effectively alter the File Allocation Table, on the UFD itself, each time a file is written.

 

I/O operations these days are a lot less dumb and a lot more optimized than people seem to think. I can actually vouch for this after having spent hours doing my best to implement asynchronous double buffering for DD operations, to try to speed things up, only to find out that the default Windows buffering was still faster than whatever I could come up with.



#142 ianst

ianst

    Newbie

  • Members
  • 20 posts
  •  
    Austria

Posted 21 March 2014 - 12:35 PM

Akeo, thanks, I'm not trying to change your decisions for Rufus, I think you're really doing good in deciding about the balances needed to keep the program simple.

 

However, I know that there is a significant overhead when the files are copied one by one and I've made an example to prove it:

 

I've took the source.7z file from Olof (around 1000 files) repacked it with -0 compression (store in the file) and added to the archive one more file with 3 MB to adjust for "Size on disk" size seen for the folder in "Properties". I've also unpacked the sources to the tmp folder, everything on the SSD, and everything also copied before, so the file cache on my computer is also filled. Then I made the following bat, started it more than once and also changed the order which action is done first. The results are always consistent:

dir source.7z.zip | grep "bytes$"
dir /s source | tail -4 | grep "bytes$"
mkdir f:\source
echo %time%
xcopy /e source\* f:\source >nul
echo %time%
echo %time%
xcopy source.7z.zip f: >nul
echo %time%

The output:



c:\tmp\01>copyOneFile.bat

c:\tmp\01>dir source.7z.zip | grep "bytes$"
1 File(s) 13,244,304 bytes

c:\tmp\01>dir /s source | tail -4 | grep "bytes$"
1100 File(s) 9,969,340 bytes

c:\tmp\01>mkdir f:\source

c:\tmp\01>echo 13:46:21.94
13:46:21.94

c:\tmp\01>xcopy /e source\* f:\source 1>nul

c:\tmp\01>echo 13:46:39.43
13:46:39.43

c:\tmp\01>echo 13:46:39.43
13:46:39.43

c:\tmp\01>xcopy source.7z.zip f: 1>nul

c:\tmp\01>echo 13:46:41.28
13:46:41.28

It takes approximately 2 seconds to copy one file to the stick, it takes approximately 17 seconds to copy the files one by one to the stick. Windows 7 x64, 64 bit cmd.exe. That means that on my stick the overhead of copying 1000 files (in 300 directories) separately is 15 seconds.


Edited by ianst, 21 March 2014 - 12:48 PM.


#143 steve6375

steve6375

    Platinum Member

  • Developer
  • 6641 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 21 March 2014 - 12:51 PM

Is the USB stick NTFS or FAT32? Does Windows use a Policy of 'Quick Removal' or 'Better Performance' for it on your system?

 

Right-click on USB drive - Properties - Hardware - Properties



#144 ianst

ianst

    Newbie

  • Members
  • 20 posts
  •  
    Austria

Posted 21 March 2014 - 12:54 PM

Steve, the stick is formatted with FAT32, the settings are the default ones of Windows 7, I haven't tweaked anything just like any normal user wouldn't.

 

The test is simple enough that everybody can repeat it on his own computer. I suggest everybody interested in the topic to try it. The slower the stick, the effect is more easy to see.


Edited by ianst, 21 March 2014 - 01:36 PM.


#145 steve6375

steve6375

    Platinum Member

  • Developer
  • 6641 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 21 March 2014 - 12:57 PM

It would be interesting to repeat the test but enable 'Better Performance' + Write caching policy.



#146 ianst

ianst

    Newbie

  • Members
  • 20 posts
  •  
    Austria

Posted 21 March 2014 - 02:39 PM

Steve, if you enable write caching you allow the copy process to be reported as finished before the data is copied to the stick at all. You are then just measuring the speed of moving the data through the RAM. For example, Intel i7-2600 copies up to 21 GB per second! I wouldn't be surprised if you get zero seconds for every operation that way. But you aren't measuring copying to the stick then.


Edited by ianst, 21 March 2014 - 02:42 PM.


#147 Blackcrack

Blackcrack

    Frequent Member

  • Advanced user
  • 325 posts
  •  
    Germany

Posted 21 March 2014 - 05:42 PM

 Akeo,

 

an lil' question, can you maybe adapt something like xboot,

the possible for creating with syslinux with more iso's an Tool-USB-stick ?

on you rufus, for have maybe an ultra-rufus or something *s*

because, xboot was an really nice thing/tool.. but.. you know.. the Developer/owner no longer living  :\

and therewith no further developing :\ therewith, maybe add on your rufus something like xboot ,

the/a possible for adding iso's for boot  ? Maybe create therewith an Ultra-Rufus :)

 

best regards

Blacky



#148 Akeo

Akeo

    Frequent Member

  • Developer
  • 303 posts
  •  
    Ireland

Posted 21 March 2014 - 09:21 PM

However, I know that there is a significant overhead when the files are copied one by one


I'm not questioning that! I believe I pointed it out in my first reply.

The only thing I have an objection with (until proven otherwise) is where longer time is directly proportional to the number of blocks being written (and rewritten) on the USB, as I have yet to see conclusive evidence that this is the case, and yet a lot of people seem to be under the impression that slower = more wear and tear = bad.

I've long known that writing a lot of small files to an USB drive will take a lot longer than writing a large file. As pointed out on the timings listed at the bottom of the Rufus homepage, it's fairly obvious that when a 4 GB image like Slackware Linux takes 20 minutes to be written, whereas a Windows 7 image of the same size takes about 3, this boils down to the number of files. So you don't have to convince me that it's slower - I already know! ;)

Now, if anyone has a report of the actual block writes occurring on the flash between a large file and a multitude of small files, I'd be quite interested...

#149 Akeo

Akeo

    Frequent Member

  • Developer
  • 303 posts
  •  
    Ireland

Posted 21 March 2014 - 09:33 PM

Hi Blackcrack,
 

an lil' question, can you maybe adapt something like xboot,
the possible for creating with syslinux with more iso's an Tool-USB-stick ?


xboot is a multiboot tool, and I have an entry with regards to adding multiboot support in the FAQ.

 

To tell the truth, besides the reasons listed in the FAQ entry, one of my concerns is that I have yet to be convinced that the majority of people asking for multiboot are legally entitled to using the images they wish to use (else, it seems to me that there are an awful lot of non tech-savvy sysadmin people out there, with MSDN access).

Another reason is that I'm still working on adding new features to Rufus, and it will most likely be years before I find myself looking at the app and wondering "Now, what else could I add...?".

 

Finally, since I'm pointing to RMPrepUSB in the FAQ entry for multiboot, I guess gotta leave a few things for RMPRepUSB to do that Rufus does not do...

I wouldn't want Rufus to be so successful that nobody uses RMPrepUSB any more, would I? ;)


  • Blackcrack likes this

#150 ianst

ianst

    Newbie

  • Members
  • 20 posts
  •  
    Austria

Posted 23 March 2014 - 01:57 PM

Akeo, I've downloaded http://desowin.org/usbpcap/ and captured the process of copying 1000 files of 2048 bytes each. The repetitive sequence I've observed was





216 10.142090 SCSI: Write(10) LUN: 0x00 (LBA: 0x00704488, Len: 8)
219 10.157690 SCSI: Write(10) LUN: 0x00 (LBA: 0x00704488, Len: 8)
222 10.157690 SCSI: Write(10) LUN: 0x00 (LBA: 0x00002014, Len: 1)
225 10.173323 SCSI: Write(10) LUN: 0x00 (LBA: 0x00003e4a, Len: 1)
228 10.173323 SCSI: Write(10) LUN: 0x00 (LBA: 0x00704488, Len: 8)
231 10.173323 SCSI: Write(10) LUN: 0x00 (LBA: 0x00704488, Len: 8)
234 10.188946 SCSI: Write(10) LUN: 0x00 (LBA: 0x007040a0, Len: 4)

Note that the commands sent to the stick are SCSI commands. http://en.wikipedia....ki/SCSI_command

 

Observing the content, the writes of 8 blocks (4K bytes and to the same address) were always the directory info data, the writes of 1 block (512 bytes) were file allocation table updates and the write of 4 blocks was the 2048 bytes of the file content.

 

Between every group of these writes were more queries:

 

SCSI: Test Unit Ready LUN: 0x00 

 

Total, there were around 20 MB writes to copy exactly 1000 files of 2048 bytes (less than 2 MB of data).

 

When I copied one file of 4 MB of data there were just a few writes more than the 4 MB of the file size. All data transfers transfers except the last were in 64K blocks.

 

I've performed these tests on Windows 8.1 x64 this time. As you can see not only there were  two file allocation table updates per file, but also 4 writes to the same 4K directory block for every copied file. If I can guess why they do more directory writes, I'd guess they concluded that such pattern results in less problems when the user plugs out the stick without waiting.

 

I conclude that for every copied file to the FAT32 both the directory entry and the file allocation table are updated. Whoever is interested in more can also make his own captures and analyze them.

 

Akeo, you can also be interested to capture the actions of your Rufus, as that would help you to decide the optimal sequence of the file actions you do, like the optimal write buffer sizes (does your buffer size results in more writes than if it would be a 64 KB file buffer size?) and the optimization of the file copy (before you even start copying file you can tell the file system the expected final length of the file and that can maybe result in less writes than when you open the empty file and then append?) The answers are in the captures.


Edited by ianst, 23 March 2014 - 02:41 PM.





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users