208 replies to this topic

[cdob]

iso-info and iso-read are default libcdio applications.

libcdio-0.90 compiled at cygwin:
 

$ ./iso-info ./archlinux-2013.01.04-dual.iso

/EFI/:
drwxr-xr-x 1 0 0 [LSN 33] 2048 Jan 04 2013 23:04:47 .
drwxr-xr-x 1 0 0 [LSN 19] 2048 Jan 04 2013 23:04:43 ..
drwxr-xr-x 1 0 0 [LSN 34] 2048 Jan 04 2013 23:04:47 archiso
drwxr-xr-x 1 0 0 [LSN 35] 2048 Jan 04 2013 23:04:43 boot
-rw-r--r-- 1 0 0 [LSN 794] 771072 May 30 2012 11:08:33 shellx64_v1.efi
-rw-r--r-- 1 0 0 [LSN 128861] 847232 May 30 2012 22:10:20 shellx64_v2.efi

$ ./iso-read -iarchlinux-2013.01.04-dual.iso -e/EFI/shellx64_v1.efi -ofoo

There is a file foo extracted.

 

The file case is respected: the directrory EFI is available.
libcdio example extract seems to be another case.

libcdio itself works at expected.
Use libcdio iso-info and iso-read as a example.

[Akeo]

Well what do you know, iso-info does have an exception for Rock Ridge.

 

So much for using iso9660_name_translate_ext() to get the right filename independently of the ISO9660 extension in use...

Why libcdio doesn't take care of Rock Ridge in iso9660_name_translate_ext(), where it should really belong, is beyond me.

 

Anyway, it seems that applying the same exception to the ISO processing in Rufus should straighten things out, without interfering with WinPE media, so I'll add that in Rufus v1.3.2.

 

Not sure when 1.3.2 will be released, as I'd like to sort out EFI boot support for Windows 7/8 images there as well, and it also turns out that Visual Studio 2012 introduces a crash in the Syslinux installer, whereas VS2010 was fine, which I'd also like to fix. Not that this affects the release version, as it's compiled using MinGW/gcc, but still...

 

Still, thanks a lot for looking into this - it really helped identify what the issue was.

[Akeo]

BETA version of Rufus 1.3.2 is now available at the usual place (or will be delivered right through your door if you told Rufus to check for betas).
 
Besides the (hopefully) final fix for Arch Linux support, what 1.3.2 brings is the long awaited support for UEFI and GPT, which conveniently also enables the latest ArchLinux -dual ISOs to boot in UEFI mode
 
But mostly this is aimed at Windows 7 (x64 only, since Microsoft didn't bother including EFI support at all on x86 media) and Windows 8 installations on UEFI platforms. Oh, and you can very much produce an UEFI bootable drive, from a Windows 7 ISO, even when running Rufus on XP.
 
Now, for some gritty details:

• Windows 8 is a no brainer - it has the bootx##.efi at the right location, so just copy the files to a FAT32 partition, preferably on a GPT drive, but MBR will work too, as Rufus will let you choose the option you prefer, and you're golden
• As most of you should know, Windows 7 x64 is a bit more of a headache, since, for whatever strange reason, Microsoft did not provide a bootx64.efi on the ISO. So we have to go fetch bootmgfw.efi from the sources\install.wim archive, as it can then be used as efi\boot\bootx64.efi... But of course, this is where you find out that, from a programmer's perspective, only Windows 7 and later provide native WIM extraction, through wimgapi.dll. So what do we do for XP and Vista? Why, we use 7-Zip of course!
  Any recent version of 7-Zip has the ability to extract from WIM archives, and also comes with the oh-so-nice 7z.exe commandline utility which we can simply invoke from Rufus. And yeah, that requires XP and Vista users to have 7-Zip installed on their machine, but Rufus will be ever so kind to let you know if it requires it before it starts formatting the drive, and will even open a browser window to the 7-Zip download page for you. As any sane person will tell you, if you don't have 7-Zip installed on your Windows machine, you're a fool. Thus, I don't consider the extra requirement as a big deal.
  Now, the one potential tricky part about using 7-Zip could have been to figure out where exactly 7z.exe is located on the system, since a user can really install 7-Zip anywhere, and even the default locations vary between x86 and x64 vary. But thankfully, 7-Zip does store its installation directory as a "Path" entry in the registry. Ahem. Boy, it sure is nice when an application writes all sorts of useful data to the registry! That can really make one's life A LOT easier...  
  Where was I? Oh yeah, all this to say that even creating an UEFI bootable Windows 7 x64 UFDs from a Windows 7 ISO on XP should be a breeze using Rufus. Of course, you will not be able to create GPT partitions there (no support for GPT before Vista - I'm not going compensate for it in Rufus, which I could do by manually creating raw GPT structures, when XP is a platform that is essentially dying), but as long as your UEFI firmware isn't broken, MBR/UEFI should work just as well.

Anyway, if you're interested, please check this BETA, and let me know if you see issues, either with the new features or the existing ones.

[Wonko the Sane]

As any sane person will tell you, if you don't have 7-Zip installed on your Windows machine, you're a fool. Thus, I don't consider the extra requirement as a big deal.

Obviously Wonko (the Sane) greatly approves of this .

 

Ahem. Boy, it sure is nice when an application writes all sorts of useful data to the registry! That can really make one's life A LOT easier...

Sure it is. .
A cannot-live-without app, that can manage *any* kind of compressed formats, besides .iso, .wim and *any* kind of disk/diskette image, besides doubling as a very convenient (almost Orthodox) dual pane File Manager has some "dignity" and is awarded "special privileges", including that of writing to the Registry (and it deserves it).

Another app, used NOT on a daily/hourly base, intended to be "portable" might not have (yet ) reached that same "privilege level" (in my perverted mind).

Of course, if that app is only one among several utilities.

 

When (and if) it will become the answer to the "ultimate question about  life, the universe and booting" (just like 7-zip is already the answer to the "ultimate question about life, the universe and compression and disk images") things will be different .

 

Go, Akeo, go.

Wonko

[Akeo]

Hehe. 
 
Well I'll be the first to agree that I have a long way to go to produce something that's as useful as the gem Igor Pavlov produced with 7-Zip... as well as much catching up to do to be as effective a developer as he is.
 
I also do like the 7-Zip philosophy of just adding features, without bothering that much about advertising for them...
Speaking of UEFI, it might be worth pointing out that recent versions of 7-Zip can also open UEFI "BIOSes" to extract their components... Is there anything 7-Zip can't do?

[Akeo]

And Rufus 1.3.2 has now been released. The changes for this version are as follows:

• Fix support for newer ArchLinux ISOs, that was removed in 1.3.1
• Add support for UEFI boot, as well as GPT.
  What this means is that Rufus can now produce UEFI bootable UFDs from EFI compatible ISOs, such as Windows 7 x64, Windows 8, ArchLinux, etc.
• The first partition is now always aligned to 1MB (unless advanced options are used)
• Internal refactoring and fixes

Enjoy!

[bblaauw]

Ah opening a can of worms by adding UEFI I see

 

Next thing you know we'll be requesting support for:

* http://en.wikipedia....ystem_partition

* GPT partitioning scheme

* hybrid MBR

* Apple EFI compatibility

 

And then there's that silly SecureBoot stuff, Fedora shim, EFI versions of GRUB and Syslinux, etc.

 

But first things first: Thank you for releasing another improved version!

[Akeo]

Next thing you know we'll be requesting support for:
* GPT partitioning scheme

You mean this?:
 

 
GPT partitioning is already in (and yeah, GPT can be used on non-UEFI computers, so the dropdown isn't 100% accurate, but I've been going back and forth on how to present GPT and UEFI for users who may have little clue what GPT, UEFI or even BIOS stand for...).
Anyway, GPT is already in 1.3.2. I saw GPT and UEFI as part of the same item actually, as my initial idea was to create EFI bootable UFDs using GPT only... before discovering that XP wasn't supporting GPT at all.
 

* http://en.wikipedia....ystem_partition
* hybrid MBR
* Apple EFI compatibility

 
Well, the way I see it, an EFI System Partition is pretty much only useful if you're going to multiboot. That is, unless you need to boot something that can't reside on FAT32, which apart for grey area OS-X installation, I don't really think there exists many instances of right now (but I'd be interested in examples that say otherwise).
And as previously stated, if you want multiboot, you probably want to find another tool than Rufus to automate those very specific needs for you.
Somehow, I can't help but feel that I dodged a large bullet the day I stated that multiboot was out of Rufus' scope...
Right now then, EFI System Partition is likely to remain out until there's a good non-multiboot reason to add one.
 
Hybrid MBR - I'd say that as long as there doesn't exist a >2TB flash drive out drive (or did I hear some recent claims that there was?), there's not much point supporting hybrid MBR for UFDs. Remember that Rufus doesn't officially support USB HDDs, so I expect a few more years still before the 2TB limit becomes an issue (phew, second bullet dodged!).
Plus, for personal reasons (struggled with that about 4 years ago and got frustratingly nowhere) I'm kinda annoyed at Hybrid MBR, as it still makes it a massive pain to install and boot Windows from a BIOS machine with a >2TB GPT disk/RAID array, if workable at all (though the fault is really Microsoft's, who have no second thoughts about creating extra partitions and who could have worked some kind of Hybrid MBR + DUET solution for all the BIOS users with large disks out there, as well as mobo manufacturers, for completely blowing off their customer base by not providing a BIOS -> UEFI transition path, even for hardware that was purchased when they were well into the process of transitioning to UEFI themselves).
 
Apple EFI - I had a request to support OS-X installation media recently, but I'm a bit dubious about the base of users who would need to use a Windows tool to install OS-X <cough>Hackintosh!</cough>. Outside of booting, I'd expect an UFD created by Rufus, especially a GPT one, to be recognized just fine by a Mac, so I'm not sure I see a point in going further than that.
 

And then there's that silly SecureBoot stuff, Fedora shim, EFI versions of GRUB and Syslinux, etc.

 
Secureboot and shims should work out of the box, if the installation media is secureboot compatible. Wether the signed executable is on optical or USB shouldn't change a thing in terms of security and boot, unless that signed executable was specifically tailored for optical. I doubt however that people who'll go the trouble of signing executables for secureboot would limit themselves to optical only.
GRUB.efi is not something I plan to support anytime soon, unless distros start to ditch (non EFI) Syslinux or native EFI boot for GRUB.efi (are they?)
Syslinux.efi is something I follow from afar right now. Not exactly sure what to do with it yet, since UEFI and the latest EFI bootable kernels seem to make the need for a middleman obsolete (a menulike feature, such as Refind, ontop of an EFI partition is pretty much all that you need these days). Then again, if there is demand for that, or more precisely, if newer Linux distros start to use Syslinux.efi, why not.
 
 
Now since you're around, how about some requests on my own? Or more exactly feasibility questions to quench my curiosity, rather than requests:

• Does an EFI bootable FreeDOS kernel look feasible to you? I'm kind of thinking that the whole 16bit real-mode DOS vs 32/64 bit protected mode of EFI will get firmly in the way, notwithstanding DOS being based around a BIOS ecosystem and BIOS interrupts. Still I can't help but wonder if there will come a day where MBR/BIOS emulation boot is disabled from newer PCs and good old DOS will be gone too, if there doesn't exist an EFI bootable version...
• While we're at it, how about GPT disk access from FreeDOS?

[bblaauw]

EFI bootable FreeDOS kernel doesn't seem feasible as DOS is 16bit while EFI is always at least 32bit (usually 64bit). Not sure if some kind of semi-CSM (SeaBIOS?) file ("bootfdos.efi") would work that then chains to FreeDOS kernel (kernel.sys).

GPT access seems highly unlikely. Maybe FreeDOS kernel could be adapted to boot from the Emergency System Partition as it uses FAT anyway. Probably requires adding partition type somewhere.

 

For Windows, I'm aiming at providing Bochs and the main "fdbootcd.iso" CD-image as part of "fd12.iso" FreeDOS 1.2 distribution CD-image file (adding RUFUS as well so it also can point to fdbootcd.iso)

I've got ramdisk support implemented, so FreeDOS CD inside Bochs creates a drive C: of itself if no C: exists yet. Ofcourse disk partitioning is also available if a harddisk is found.

 

For physical machine, either installation to found drive C: , or if not found, create by ramdisk. Thus, always a FAT filesystem present.

Considering a simple 13MB MEMDISK harddisk image also. That would add nicely a harddisk + MBR + partition + bootsector

[Akeo]

Sounds good. And yeah, FreeDOS/EFI looks like an interesting challenge

 

For the record, I have plans to add commandline support for Rufus eventually, so that one can produce an UFD by specifying the destination drive, ISO image and other parameters, but that's not very high on my list right now and likely to take some time...

 

But I guess in the meantime, one thing I could do is add an option to at least specify an ISO when Rufus starts, so that the user can just select their target drive and click Start.

Would you be interested in something like this for 1.3.3?

[bblaauw]

That would be most interesting.

[D0UG]

I have a feature request - - -  add boot testing.

 

I have made several USB boot drives (3 differenct flash drives) to boot a Lenovo G560 laptop to a Hirens ISO.  The most progress I have made is a "C:" prompt.  I can use  dir command and see all the files but the drives do not boot to Hirens like the CD does.  Same problem with other bootable CD images.

[Akeo]

Can you clarify what you mean by "boot testing"?

 

But in all seriousness, it's unlikely I'm going to add that feature to Rufus ever, since I expect very few people to use it and the time I can spend on developing features that will only benefit a minority is very limited.

If you're unlucky enough to have a BIOS that doesn't boot the USB you created, I'd rather leave you in the good hands of more advanced tools, such as RMPrepUSB, as they have a feature for just that situation.

 

Also, I'm afraid that if you find that your USB doesn't boot, you won't really be able to avoid having to troubleshoot some of the issue on your own, as well as become knowledgeable about the boot process. There's only so much that an automated tool can do...

[bblaauw]

The USB stick is created wrongly then? Hiren's is something like UBCD I guess, thus starting Grub or Syslinux as bootloader (be it on CD or USB). Are you sure you made RUFUS point to the Hiren ISO as well as select to extract its contents?

RUFUS first creates a blank formatted FAT32 filesystem, then either extracts ISO contents, or optionally puts a few integrated files (FreeDOS or Syslinux) on the USB stick.

 

Originally I thought you were asking for the feature that RMprep has: test the USB stick in QEMU. Then again, that requires QEMU to be installed on harddisk.

[Akeo]

Just for the record, I have now tested a Rufus created stick with the latest Hiren Boot CD on 3 different machines (2 BIOS, 1 UEFI) and found no issue.

 

I agree with Bernd that you may want to detail how you created you created your USB drives in the first place. Did you point Rufus to the ISO image by clicking the disc icon, or did you just create the default type of boot drive (FreeDOS) with Rufus, and then copied your CD content? The second method will not work, but it may give you a C: prompt, which is what you observed. And in this case, even if Rufus had a test for boot, it would have reported success, since FreeDOS is bootable, so I don't think it would have helped much...

 

There are multiple ways to created bootable content for USB, and not all these methods are interchangeable. Make sure you select the right one for what you want to do.

[D0UG]

Can you clarify what you mean by "boot testing"?

 

But in all seriousness, it's unlikely I'm going to add that feature to Rufus ever, since I expect very few people to use it and the time I can spend on developing features that will only benefit a minority is very limited.

If you're unlucky enough to have a BIOS that doesn't boot the USB you created, I'd rather leave you in the good hands of more advanced tools, such as RMPrepUSB, as they have a feature for just that situation.

 

Also, I'm afraid that if you find that your USB doesn't boot, you won't really be able to avoid having to troubleshoot some of the issue on your own, as well as become knowledgeable about the boot process. There's only so much that an automated tool can do...

It is probably the BIOS blocking it.  I found other people on the Internet complaining about USB boot problems with this series of laptops.  I tried making bootable USB flash drive from Grub4DOS and it failed too.  I can burn the ISO image bootable with ImgBurn and it works fine.

 

PS

I copied the "grldr" and "menu.lst" files from the HBCD folder to the root of the flash drive and then it worked great.  I don't understand why it worked as a CD without copying those two files.

Edited by D0UG, 02 February 2013 - 03:36 AM.

[D0UG]

The USB stick is created wrongly then? Hiren's is something like UBCD I guess, thus starting Grub or Syslinux as bootloader (be it on CD or USB). Are you sure you made RUFUS point to the Hiren ISO as well as select to extract its contents?

RUFUS first creates a blank formatted FAT32 filesystem, then either extracts ISO contents, or optionally puts a few integrated files (FreeDOS or Syslinux) on the USB stick.

 

Originally I thought you were asking for the feature that RMprep has: test the USB stick in QEMU. Then again, that requires QEMU to be installed on harddisk.

 

I did point RUFUS tot he Hirens ISO but see not option to "select to extract its contents".  I believe that the extraction is performed by default when "create a bootable disk using" is selected.

 

Thanks for mentioning QEMU.  I had not heard of that program but find it very interesting.

[TheHive]

TEST:

Used: rufus_v1.3.2

Burn Win7PE SE 04-13-2012 to USB = Successful. Booted and Working.

 

 

Im hoping to test Windows XP again on USB. I was having problems during WIndows XP install Phases, with the older version of Rufus. Will write back in future when i get more time to test.

[TheHive]

TEST:

Used: rufus_v1.3.2

Burn Windows XP Pro to USB = Successful. Booted thru the Install phases and Working.

[ziadkiwan]

Great job ! i own you you saved my ass today! tested on ISO image worked great !

[Akeo]

Thanks for the updates. Always nice to hear about success stories.

[alacran]

@Akeo

 

Using Rufus 1.3.2 (First time using your great tool):

 

USB Kingston 2GB used.

 

1 Selected Check device for bad blocks 1 Pass.

 

2 Selected Win XP-SP3.iso, partialy unnatended, fully updated using nLite, several Driver Packs added using DPs_BASE.

   (That ISO works very well from CD, already tested)

 

3 All other upsets were default, just cliked "Start"

 

After some time all was done. Checked log to verify if some bad sector where found, none.  When booting no problem but when traying to fast format HDD to procede with install there is a message saying the CD can't do it and some file is missing (as far as I remember) and when clicking OK system reboots.

 

Can you provide any help?

 

Thanks in advance.

[Akeo]

Well, having a more precise error message would be the first step in getting help. Unfortunately "some file is missing" doesn't provide much data to work with. Having a look at the Rufus log and see if it reported any errors (especially during the patching of the XP files) would also help

 

Also, since Rufus can't really make any promises with regards to customized ISOs, could you try using the original ISO without nLine customization? We're patching some XP files and expect to work with an untouched image - if nLite modified some of the files we patch, then we're going to have a problem.

 

Finally, while this may not be your issue, I know of some machines where an XP ISO works perfectly fine, and the USB created by Rufus doesn't, with the XP installation process failing early with an error. I do happen to have such a machine - an old Dell GX260.  As far as I know, this is due to the BIOS from some machines being just incompatible with XP and the boot method used by Rufus, as well as the XP installation process never having been designed to be used from USB in the first place anyway.

Now, considering that XP is fast nearing official end of support from Microsoft (less than a year now!), and seeing that XP installation from Rufus seems to work for the vast majority of people who try it, I am not really planning to invest that much more time into improving XP support in Rufus: it just doesn't seem like a good investment (plus I really don't have the time for that anyway). So if your issue is limited to a single machine, and cannot be reproduced on the computers I have access to, it's unlikely I will try to fix it. But then again, Rufus is fully Open Source, so if someone sends a patch to improve XP support on some machines that I can't test against, I will gladly add it.

 

Anyway, if you can test with a non customized XP ISO and find out if there are any errors reported in the Rufus log, I would appreciate it.

[alacran]

@Akeo

 

I trayed again looking for more info, there is no referece to any especific file(s) name(s), any way no problem, I can use WinSetupFromUSB to do this without any problem if needed, I was just traying your application to see how it works and the first thing came to my mind was tray XP install because it is a very small ISO, I'm going to try Win7 install next.

 

Best Regards

[Akeo]

OK. I'd expect a lot less trouble with Win7, as, unlike XP, the installation process was designed by Microsoft to support USB installation. I'll also point that Rufus supports EFI installation for Windows 7 and Windows 8, which I don't think many other tools do yet, including the Windows 8 USB installer from Microsoft (or at least this was the case when I purchased Windows 8 in December).

 

And yes, Rufus uses a slightly different method than other tools for XP installation, so results compared to those may vary. Sometimes it seems to work better (I get regular reports indicating success where other tools failed), sometimes not so much. I'd say as long as you can find a tool that works for you, then all is good.