Jump to content











Photo
- - - - -

Rufus v1.3.0 has been released


  • Please log in to reply
168 replies to this topic

#1 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 17 December 2012 - 02:13 AM

*
POPULAR

(Starting a new topic with this new release, since the old one has gotten pretty long)
 
It is my great pleasure to announce the release of Rufus v1.3.0.
 
What this new release brings is as follows:
  • FAT32 format support for >32GB drives, based on fat32format, from Ridgecrop Consultants Ltd:
  • Automated update check
  • Relax ISO9660 compliance for Arch Linux images
  • Add support for VMWare ESXi 5.1 ISO images
  • Update Syslinux to v4.0.6 and libcdio to v0.90
  • Miscellaneous UI improvements and fixes
The feature that actually required the most development time was the check for updates, which I foolishly thought would be a matter of a couple of days to implement, but I hope it'll be worth it. I also hope that, time permitting, you won't have to wait another 6 months to get the benefits of having automated check for updates in Rufus... ;)
 
On that subject, since someone expressed doubts about prompting every new user about the update checks, be aware that you can avoid the prompt altogether, and get the default check for update options, if you either download the version called rufus.exe or rename your download to rufus.exe.
Personally, I believe that any feature that sends data to a remote server, no matter how minimal, should be opt-in, rather than opt-out, which is why I'll continue linking to a prompting rufus_v1.3.0.exe, rather than the promptless rufus.exe (which is what I did for the downloads section) but of course you're free to spread rufus using whichever option you prefer.
 
Also note that since github abruptly decided to remove their file upload feature, I am now hosting all downloads on http://rufus.akeo.ie/downloads (and yeah, there are ads here too, which I don't like either, but it helps funding my new code signing cert).
 
Finally, along with the automated check for updates, that creates some keys in the registry (under HKCU/Software/Akeo Consulting), I also added a new Alt-R "cheatmode", that will delete all the registry keys created by Rufus, in case you want to reset the check for updates settings. I'll try to create a wiki page with Rufus tips and tricks, where I list all theses cheatmodes, when I get a chance.
 
As usual, feel free to comment or report issues either in this thread, or using the github issues page.
 
PS: Most likely, the feature I'll be adding next will be NTFS support for Syslinux, and I'll also try to investigate the large FAT32/4K sector situation. I may also add a feature to try to detect DOS based ISOs, to copy their content to a FreeDOS formatted USB, but as usual, the time I am able to spare for Rufus will be the determining factor of what features make it into a upcoming version, especially as there are plenty to choose from...
  • plao, Master of Disaster, bee4u and 1 other like this

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,613 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 December 2012 - 10:29 AM

Finally, along with the automated check for updates, that creates some keys in the registry (under HKCU/Software/Akeo Consulting), I also added a new Alt-R "cheatmode", that will delete all the registry keys created by Rufus, in case you want to reset the check for updates settings.

 

This greatly saddens me :(.

In my perverted mind a simple tool should be simple ;), portable and NOT writing anything on the system (and no, writing it and later give an easy way to delete what was written is NOT the same thing).

A much simpler .ini (or similar) file in the same folder one puts the .exe would have done nicely, IMNSHO.

 

:cheers:

Wonko



#3 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 17 December 2012 - 07:13 PM

I respectfully disagree.

 

There are some things for which ini files work well. Storing update settings for an application that doesn't have an installer is not one of them.

 

Since Rufus doesn't come with an installer, and doesn't create an entry in the start menu, I fully expect Rufus users to move the executable around. And since my prime target audience is regular Joes rather than advanced users, I doubt they are going to remember to also move the ini along when they do. However, the last thing I want is for Rufus users to be prompted a second time to choose their update policy on the same machine, when they already indicated their preferences. So what should I do? Create an ini in a fixed directory in the user's local folder? Well, if you don't like entries being written in the registry, you're sure not gonna like that either (or I could also drop the file in Windows\System32, so that it's not too visible and remains available, since the app runs elevated, but that's not exactly what I would call considerate), and I personally don't see yet another application creating yet another obscure file somewhere as a good idea. As far as I'm concerned, there are way too many files that I didn't voluntarily create on my filesystem already, which makes seeking for the ones I did a pain, and I'm pretty sure I'm not the only one feeling that way. As such, I'd much rather leave Rufus users with only the application file ever, which I see it as a much more valuable behaviour.

 

Besides, while I understand where you may come from, my personal opinion is that people are making way to much of this "don't write in the registry, ever".

Using the registry is part of the the Windows application microcosm, and has the merits of avoiding the multiplication of ini files in a common repository, which isn't a bad idea (cf. the mess introduced with the need to improve security on apps that stored their settings in the system directory...).

 

PS: for the record, I've written quite a few apps that used an ini, and from which I could have reused code, so it really wasn't a matter of what was more convenient, but what made most sense to me.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,613 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 December 2012 - 07:30 PM

Well, the good thing is that everyone has their own views on things :).

 

I personally don't see how having:

  1. a check for a .ini (or other .cfg file as long it is "plain text" or however "human readable") in the same directory the .exe is
  2. a check that the actual .exe is not in a read only media/volume/whatever
  3. then either create a new config file for the app (if the media is Write accessible) and assume that the check for update is to be carried
  4. prompt the user if he wants the tool update <- the opt-in option that you very correctly already implemented :worship:
  5. provide an example file for "DO NOT prompt user for updates and DO NOT carry automated updates"
  6. give the user the possibility to choose between ,ini (or .cfg) file and Registry

could create a mess, but if you are happy in writing needlessly to the Registry you are very welcome :), I retain the right to be saddened :( by your decision, however, and wanted to let you know about this feeling of mine.

 

:cheers:

Wonko



#5 robertcollier4

robertcollier4

    Member

  • Members
  • 32 posts
  •  
    United States

Posted 17 December 2012 - 08:18 PM

Rufus behavior for advanced computer audiences dictates that INI file usage would be better. Advanced computer users / computer hobbyists all over the Internet have begun standardizing on Portable format.

 

The reason is -- because these days everyone has more computers. I would like to be able to move my applications around between computers and have them retain their settings. Often times it takes me hours to get an application how I would like it and get it to what I consider is "perfect behavior". Having to do it more than once is a HUGE pain since choosing settings is often hugely a guess-and-test effort.

 

If Rufus was meant to be used by computer novices - then perhaps they want the out-of-sight / out-of-mind approach of Registry settings where it seems to "magically" work. But advanced computer users, which is the main user of Rufus - want to know what their application is doing and want to be able to see and control everything precisely. Having the INI file in the folder of the EXE - is obvious and I can instantly see - okay here are the settings. But having the settings in the registry - is a hidden way, I do not know where in the registry the application is writing without running a specialty Registry monitor tool - and to access those settings or import-export them between computers requires way more keystrokes than editing or copy-pasting an INI file across a network share.


  • dfine2k likes this

#6 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 18 December 2012 - 12:35 AM

@robertcollier4, you've missed the mark by quite some range:

1. Rufus is primarily intended for novice users, not advanced ones. That's how I designed it, and why it's very similar in terms of UI to the default formatting UI users would be familiar with on Windows, as well as why the most advanced options are hidden from view by default. I do appreciate that advanced users like yourself want to make the application your own, and may consider it advanced. But please don't tell me that I designed Rufus for advanced users, because it's actually the opposite

2. Rufus does not store any settings, besides the check for update. And I don't think it ever will store anything besides that. As such I don't see what the big deal is. Either you want Rufus to check for updates on each computer you run it, or don't, in which case it's a simple one time click per device (or not even that if you want opt-out by default, and go with labelling the executable 'rufus.exe'). There aren't any settings for "I prefer NTFS over FAT32 by default" or "I prefer MS-DOS over FreeDOS", and I'm not planning to add any, because I plan to keep the application simple, as per 1.

 

@Wonko, please understand that we're talking the settings for the update check policy, and I went with writing to the registry because I'm pretty sure that I will not need to write more than 3 or 4 keys, and they will all be related to the check for updates. I am actually quite saddened myself that you are saddened , as I think you are blowing this design decision a bit out of proportions, with regards to what it actually means for the future of Rufus...



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,613 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 December 2012 - 10:03 AM

Oww, come on :), you took your decision, I respect it, but I cannot and will not agree with it :(.

You asked for comments, you got them.

Now that it is clear that the tool is primarily intended for novice users, my pride won't allow to lower my level and use the app, so everything is fine and dandy :thumbsup:.

I perfectly understand how the Author of a program is entitled to have his/her own vision of the tool and implement it the way he/she see fits :worship:, but he also has to deal with the reactions of its users and carry the burden of risking making them sad (or get the satisfaction of having them happy and satisfied :smiling9:).

You have no reasons to be saddened :thumbup: :dubbio:

 

Spoiler

 

:cheers:

Wonko

 



#8 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 18 December 2012 - 08:20 PM

OK, since comments are a 2 way street indeed, let me keep the traffic flowing...
 
I'm afraid I cannot help but take objection with how much a minor and carefully weighted design decision to use the registry seems to have become a contention point (if one is to consider that Rufus attempts to catter for both the masses and the classes, I must reiterate that the decision to go with registry makes 100% logical sense), and more specifically with how it has now degenerated into what I can only qualify as the very deprecating statement below, that I feel compelled to comment on:
Now that it is clear that the tool is primarily intended for novice users, my pride won't allow to lower my level and use the app, so everything is fine and dandy :thumbsup:.
I believe that the statement is deprecating as well as misses the mark on multiple counts:
  • regular Joes != novices. At least not in my mind. A novice is someone who is starting with computer and is still lacking some of the basics. A regular Joe is someone who is familiar enough with computing, but who may be attempting to peform a task that they haven't spent hours researching beforehand, as we all did at one stage or another (in which case, we are all ever-novices)
  • Likewise, primarily != exclusively. In case you haven't noticed, I added options in Rufus that can only qualify as intended for advanced users. So does the fact that I decided to catter primarily for regular Joes, because, obviously they are the ones who requite the most help, means that any feature I also add for advanced users becomes instantly negated?
  • Also, though this is an extension of the "pigeonholing" point above, does this mean that, no matter how well a tool or application may perform the task that you may actually want to achieve, unless the app is tagged "for Advanced users primarily", you're going to dismiss it as a whole? Seems about as irrational as deciding not to use a piece of luggage that has all the qualities to fit your needs, on the grounds that it is missing a "Louis Vuitton" tag.
  • Finally, because your opinion is well respected, and usually deservedly so, I can't help but find the statement above quite damaging, as it conveys the idea that experienced people will be better off keeping away from Rufus. In other words, if Rufus would require you to "lower your level", aren't you somewhat trying to convey that experienced users should consider it a lesser app? At least, as someone who takes pride in my work and invested resources making sure the app couldn't be construed as exclusive, that's how I interpret it...
In my book, a more neutral and to the point "Well, I don't consider Rufus to be portable enough now, so I'm not planning to use it", is what would have qualified as all fine and dandy.

#9 B0K

B0K
  • Members
  • 5 posts
  •  
    Canada

Posted 18 December 2012 - 09:44 PM

First off, thanks for a great program.

 

For me, too bad, XP installation fails at the GUI file copy step.  Complains of missing D:\i386\asms.  Oddly enough if I do shift-F10 I can find this directory, it's not empty, I can mkdir so I don't understand the access denied error.  

 

I know this is probably not related to Rufus.  After digging up a quote by ilko: "...You are welcome.  In this case there won't be different drive letters. There won't be a drive letter at all for the USB disk. This has nothing to do with the masqueraded BIOS disk number. Windows simply doesn't mount yet partitions on the USB (fixed)disk, thus inaccessible source via a drive letter and Setup a bit misleading complains about missing ASMS folder, since it's the first one needed. All details are in that topic...."   I thought maybe that's it and Rufus isn't savvy enough (sorry!) so I tried WinSetupFromUSB which gave the exact same result, only with different path D:\$WIN_NT$.~LS\asms or some nonsense.  Which oddly enough is about the same error I got after an excruciating process involving WAIK and a winpev2 bootable USB stick.

 

My noob head is hurting but anyway!  your time is precious and your product is savvy.  I write here because there are super knowledgeable folks lurking (where is that ninja emoticon hiding o.o ) and my brain is so full and unable to think of a next step... I'm very much on the novice side of things.

 

There must be something to my setup so I will think of all details that may be relevant.  I have eliminated things as I read about them.  BIOS is already in legacy / native IDE mode so no AHCI.  I have deleted partitions to make sure the target partition is Partition 1.  There is only one disk in the system, a 60GB SSD.  The motherboard is a brand new Gigabyte 78LMT-S2P, 4 GB ram.  (I know I know! but I don't know!).  CD-ROM controller is SATA.  There is no IDE anywhere in this thing, or floppy header.

edit doh!

The OS is XP PRO SP2 french.  Oddly, the last line of the EULA.TXT file indicates SP1 and there has been some fiddling with the unattend.txt (which I am not using) so I guess it may not be 100% vanilla.  Could this possibly cause any headache?  Seems so unrelated.  When I went the WinpeV2 by WAIK route, the installation got to asking for the product key but failed at that point.  I know the key is good, damn it was running before!  Obviously something about the env was not quite right so it was expecting another type of key.  (seemed strange installing XP in a win7 env anyway).  I have no other XP cds to check but wouldn't write here anyway if I thought that would be the issue!

 

The next logical step seems to be slipstreaming SATA drivers from Gigabyte site onto my XP CD.  Somehow I don't believe that will work.  Not only because Shift-F10 shows the files windows is complaining about, but because most users reporting success probably also have SATA CDROM and no problems.  Also at this point in the process the file copy is off the USB partition anyway.  (again that comment by ilko comes to mind but I am so clueless I assume it is irrelevant.)

 

I'm willing to help out by trying anyone's suggestions or reading up more.  Admittedly I don't know how to setup/run DebugView to get you a log.  I'm running on actual hardware so I doubt that's possible anyway.

 

I half expect my problem is obvious to someone out here hehe.  

 

 

One other things I noticed while poking around, but again, no idea how relevant: at G4D command-line, `geometry` borks at "partition 1,"  pausing then saying error 25 disk read error, something I've never seen.  Guess G4D doesn't grok USB drives?  oddly, my SSD is hd1, not hd0.  doing root (hd1 then tabbing shows the partitions for the SSD and I can still boot ubuntu from the second partition.  doing root (hd0) gives the read error.  yet I found no map command switching hd 0 and 1 so far in the boot process.  (at this point Wonko is laughing saying this is like sudoku with 1 square empty... I hope!)


Edited by B0K, 18 December 2012 - 09:54 PM.


#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,613 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 December 2012 - 11:12 AM

In my book, a more neutral and to the point "Well, I don't consider Rufus to be portable enough now, so I'm not planning to use it", is what would have qualified as all fine and dandy.

Quite the other way round.

 

If I wrote that I didn't consider Rufus portable enough (something that I do NOT actually think, writing to the Registry is IMHO "wrong", but from this to say that a tool is "not portable" or "not portable enough" there is an abyss) it could have sound -besides being a lie - as a "judgement" of some kind, and "I am not planning to use it" would have been attributed to the hypothetically flawed design of the app.

 

The sentence, exactly as stated conveys instead (or at least it was written to the scope of conveying instead) how the only reason why I won't use it is because of my pride, and since I am known around as a grumpy, old, bastard actually lifts each and every responsability for this decision from  the "qualities" of the app and connects them entirely to my perverted way of reasoning.

 

I would say it is actually all fine and dandy :).

 

:cheers:

Wonko



#11 B0K

B0K
  • Members
  • 5 posts
  •  
    Canada

Posted 19 December 2012 - 03:37 PM

there is something interesting that I have no explanation for.  Although created from the same XP pro CD, WinSetupFromUSB and Rufus give slightly different results.

 

when installing from Rufus, the behaviour is precisely like have the CD in the drive, I am able to find and repair an existing installation of windows.  this is not the same as the first repair off which is to drop to repair command prompt, but later after choosing to install windows and finding an existing installation, the Rufus-created installer offers me to repair this existing installation by pressing R.  this is familiar to me from the CD and I've used it many times, it goes through the xp installation all over however without removing installed programs, basically an in-place copy of the system files.

 

installers created with the other methods didn't offer this.

 

I copied an existing windows xp installation directly to the drive.  this failed to boot, however doing the above-mentioned process I got to the same point in the GUI-install phase where it complains about asms folder *however* this time instead of giving access denied and quitting, it asks for the path to the files.  then I am able to continue file copying off the USB stick.



#12 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 19 December 2012 - 08:52 PM

B0K,

 

Let's start with the simplest explanation: is is possible that your original XP media is defective or was not created in a manner that XP setup is happy about?

Googling around, a few of the i386\asm errors I see hint at a bad source media being the cause (or custom XP install media being created improperly), which would explain a lot. I'm also seeing some reports of people getting asms issues due to bad RAM (which could make sense if the XP GUI setup starts using large amounts of RAM during the asms readout process), which you may want to consider as well.

 

I guess I'd start by trying to weed out hardware issues, especially as you indicate that the hardware is brand new. Using an ISO from an original XP media would also be a must, but I understand that you may not have one accessible.

Otherwise, it's always possible that Rufus could add some patching for specific hardware configurations, but unless we can get some idea of what the issue is, it'll be difficult to accomplish.

Finally, I believe I tried a vanilla XP SP2 French media (or was it SP3?) when testing XP support with Rufus, and didn't find issues, but I'll see if I can ran a similar test again (I'm of course interested to confirm that Rufus isn't the culprit here). I probably won't be able to run such a test for a couple of weeks though.



#13 steve6375

steve6375

    Platinum Member

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

Posted 20 December 2012 - 10:58 AM

I just tried a standard MS XP SP3 Install ISO with rufus 1.3. It boots OK but when I press Enter, it said 'Setup cannot find the End User Licensing Agreement (EULA).'

I tried this with a different (OEM XP SP2) ISO and the same thing happened.

I have used these ISO files many times so I don't think the fault is with the ISOs...

 

Log file attached.

Attached Files



#14 B0K

B0K
  • Members
  • 5 posts
  •  
    Canada

Posted 20 December 2012 - 01:29 PM

I wasn't expecting that!  my hope in writing on this forum was that my issue would be known and obvious to someone, and then to maybe help the cause by giving results on my particular hardware.  please don't spend time you could be devoting to Rufus on (albeit logical and kind) efforts to help me through the internet to debug my case!

 

in answer to your questions, I'm confident in my XP disc since it's the one I have been using since the computer I bought in like 2006.  I have used it again and again through my upgrades and just last year installed XP side by side on hardware that is soooo close to my target right now - the computer I'm typing this on which also has no floppy and a SATA dvd, however with intel mobo instead of gigabyte.  I may have installed it through shift-f10 just after the beginning of windows 7 install... I only remember being relieved that it finally worked, but can't remember what I did!

 

the memory memtested ok but I didn't run it 24h or anything.  I should have thought of that last night before bed but I've been on this issue 2 days straight so not thinking very well anymore.

 

oddly enough I hadn't come across the softwaretipsandtricks link you offered.  thanks for that one, it's very interesting reading and I will post back if something on there gives the solution in the hopes it may help someone.



#15 B0K

B0K
  • Members
  • 5 posts
  •  
    Canada

Posted 20 December 2012 - 02:49 PM

the installation has completed using Rufus.

 

the steps that finally worked were:

copy i386 to partition 1, c:\

insert Rufus-created USB image and do text mode install

*remove USB on reboot*  (this is what I hadn't done before)

GUI mode copied files automatically from c:\i386 without even asking.

 

my suspicion is that drive / partition order confuses the installer if the USB stick is left in the drive.

HTH!  

 

thank you for Rufus.



#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,613 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2012 - 03:03 PM

my suspicion is that drive / partition order confuses the installer if the USB stick is left in the drive.

Yes, this is known.

Other methods use grub4dos to swap the disks order to make the  removing of the USB stick during the two installation phases unnecessary.

 

:cheers:

Wonko



#17 B0K

B0K
  • Members
  • 5 posts
  •  
    Canada

Posted 20 December 2012 - 03:50 PM

thanks for confirming.  the idea had floated in my head to install g4d on the Rufus-created image (since it uses syslinux?  it should be easy?).  it would be interesting to see if that would work to make it even more noob friendly.

 

the problem when one has so little knowledge like me is that all possibilities seem good so I had a long long list of things to try!



#18 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 20 December 2012 - 07:15 PM

Well, Rufus should not require removing the USB drive either. It was very much designed not to have to, and yours would be the very first report I get from an XP installation requiring it. That's the whole point of the MBR that Rufus installs on the USB drive.

 

Would you by any chance have disabled the use of the Rufus MBR during the drive creation (from the advanced options of Rufus - it will always be enabled by default for an XP image, but it can be removed manually if you choose so). Finding out if you are using the Rufus MBR or not should be easy: if you boot from USB on a system where you already have a bootable OS installed, you should see a message "Press any key to boot from USB...".

 

If you don't see that message, that would explain your issue. And for the record, using grub4dos is not the only way to make the removing of the USB during installation phase unnecessary... ;)



#19 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 20 December 2012 - 07:44 PM

steve6375, the EULA error is what I used to get before I added patching to the MS setup executables, but looking at your log, the patching seems to be occurring OK (those rdisk and $WIN_NT entries towards the end - the percentage errors are just UI issues, that I need to fix, but that have no incidence on the USB content).

 

Now, it's always possible that a regression was introduced in 1.3 with regards to XP support as, as much as I'd like to test all regressions possibilities out there, I just don't have the time for it. Can you try with 1.2 and find out if you still see the same issue? XP SP3 is something that was fairly thoroughly tested prior to 1.2, and that I'd expect to work just fine as long as your hardware configuration is standard (1 HDD, 1 USB)



#20 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 08 January 2013 - 12:49 AM

Just an update to indicate that I have now tested XP_SP2 and XP_SP3 (EN versions - couldn't get hold of FR ones) with Rufus v1.3.0.

While I am not seeing any EULA issue (it's most likely environmental), I am seeing the GUI setup complaining about missing files from the SP3 (or SP2) CD.

At least with XP_SP3, The same ISO installed with Rufus 1.2.0 appears to work alright, so it looks like v1.3.0 did add a regression with the XP install process...

 

I have now logged issue #115 for that problem, and I guess the next step will be comparing the differences between the 1.2.0 and 1.3.0 content...



#21 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 10 January 2013 - 12:29 AM

And Rufus v1.3.1 has now been released, mainly to fix XP support.

 

The issue, really, is that you shouldn't try to ignore ISO9660 compliance in order to support broken ISO images, as it leads to all sort of issues for images that ARE ISO9660 compliant.

In this case, Rufus 1.3.0 was copying the XP files in uppercase onto an NTFS partition, instead of lowercase with v1.2.0, which of course didn't sit down to well with the XP UI installer process as it seems that at least part of it expects to find lowercase files, hence the issue above with files being present but not found.

 

Lesson learned: the specs are not to be deviated from.

Therefore, if your ISO doesn't comply with ISO9660, don't count on Rufus to support it... I'm looking at you, ArchLinux!

 

I have now tested XP_SP2 and XP_SP3 install using Rufus v1.3.1, and found no issues.



#22 cdob

cdob

    Silver Member

  • Expert
  • 974 posts

Posted 10 January 2013 - 10:34 PM

Therefore, if your ISO doesn't comply with ISO9660, don't count on Rufus to support it... I'm looking at you, ArchLinux!
File system ISO9660 with Rock Ridge extension is very common at *nix world.
A uppercase ISO9660 and mixed case Rock Ridge is normal at a *nix CD.
A mixed case *nix CD is normal.
Core boot files uses ISO9660, booted OS use Rock Ridge.

How to transfer this condition to another file system at USB flash?

#23 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 11 January 2013 - 01:03 AM

Well, the issue is not with Rufus but somewhere between libcdio and Arch, and libcdio does support RockRidge, along with Joliet and all the common ISO9660 extensions.

Rufus does enable Rock Ridge extensions when compiling libcdio, and I'm pretty sure I was able to use Rufus to succesfully extract Rock Ridge images with Rufus before.

It's only the Arch Linux ones that fail (which I believe could easily be fixed if they enabled Joliet, since not having Joliet is the reason the problematic EFI dir gets converted to lowercase)

 

Last time I checked, ArchLinux ISOs were mixing uppercase and lowercase in the descriptors, which I don't remember seeing allowed by the ISO9660 specs outside of Joliet, whether Rock Ridge is in use or not.

So, the issue, really, is between libcdio and Arch Linux. One of these two need to fix something so that the name Rufus gets from libcdio when it parses the descriptors is the same as the name it should use to query for the file. I'd rather not try to attempt to venture a fix on my own, as this is exactly what I did in 1.3.0, and it broke support for other ISOs.

 

Please feel free to try the following on Linux:

# wget http://ftp.heanet.ie/mirrors/ftp.archlinux.org/iso/2013.01.04/archlinux-2013.01.04-dual.iso
# wget http://ftp.gnu.org/gnu/libcdio/libcdio-0.90.tar.gz
# tar -xzvf libcdio-0.90.tar.gz
# cd libcdio-0.90
# ./configure --enable-rock
# make
# cd example
# mkdir tmp
# ./extract ../../archlinux-2013.01.04-dual.iso ./tmp
(...)
Extracting: ./tmp/arch/i686/root-image.fs.sfs
Extracting: ./tmp/arch/pkglist.i686.txt
Extracting: ./tmp/arch/pkglist.x86_64.txt
Extracting: ./tmp/arch/x86_64/root-image.fs.sfs
Could not access /efi

Fix that, and you'll have fixed Arch Linux support in Rufus.



#24 cdob

cdob

    Silver Member

  • Expert
  • 974 posts

Posted 11 January 2013 - 06:28 PM

Extracting: ./tmp/arch/x86_64/root-image.fs.sfs 

Could not access /efi

isoinfo -l -i archlinux-2013.01.04-dual.iso
Directory listing of /
d--------- 0 0 0 2048 Jan 4 2013 [ 21 02] ARCH
d--------- 0 0 0 2048 Jan 4 2013 [ 33 02] EFI
Directory listing of /ARCH/X86_64/
---------- 0 0 0 222367744 Jan 4 2013 [ 1189 00] ROOT_IMAGE_FS.SFS;1
Directory listing of /EFI/BOOT/
---------- 0 0 0 78640 Jan 4 2013 [ 754 00] BOOTX64.EFI;1

isoinfo -l -R -i archlinux-2013.01.04-dual.iso
Directory listing of /
drwxr-xr-x 1 0 0 2048 Jan 4 2013 [ 21 02] arch
drwxr-xr-x 1 0 0 2048 Jan 4 2013 [ 33 02] EFI
Directory listing of /EFI/boot/
-rw-r--r-- 1 0 0 78640 Jan 4 2013 [ 754 00] bootx64.efi


isolist archlinux-2013.01.04-dual.iso
d [LSN 21] 2048 /arch
d [LSN 33] 2048 /efi


There exist a directory ARCH at ISO9660. And arch at RockRidge.
libcdio access the lower case name arch.

There exist a directory EFI at ISO9660. And EFI at RockRidge.
There is no efi at archlinux-2013.01.04-dual.iso image.
libcdio searches a lower case name efi and fails.

 

Archlinux ISO is a valid example. There is no need to add another file system like joliet.

Why fails libcdio at name efi? Does libcdio search a lower case name efi?
libcdio seems to convert case on it's own. That's a broken design.
Either read ISO9660 or RockRidge and respect given case.

Rufus may adjust case at known circumstances, e.g. a Windows XP ISO image.



#25 Akeo

Akeo

    Frequent Member

  • Developer
  • 207 posts
  •  
    Ireland

Posted 11 January 2013 - 06:41 PM

libcdio seems to convert case on it's own. That's a broken design.
Then please bring that up with libcdio. They should be able to tell you why they did that, and/or acknowledge that it's something they need to fix.
Rufus may adjust case at known circumstances, e.g. a Windows XP ISO image.
Sorry but no.
If the problem is with libcdio, I'm not going to add workarounds that will require testing and maintenance in Rufus. My time is too limited for that.
Still, I would appreciate if someone else but me could bring the matter up with libcdio and find out what the story is.




2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users