Unsupported image with FreeBSD ISO

[wbsdty331]

<PLEASE READ THIS CAREFULLY: You MUST read and complete the checklist below, by placing an x into each [ ], BEFORE clicking on 'Submit new issue'. Failure to perform these steps, WHICH ARE ONLY THERE TO HELP YOU, will result in the issue being dismissed without warning.>

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
• I clicked the Log button in Rufus and copy/pasted the log into the line that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: 2.10 - I have NOT removed any part of it.

Issue description

Could not find FreeBSD ISO Image(except memstick*.iso)

FreeBSD-10.3-RELEASE-amd64-disc1.iso

---

Scanning image...
ISO analysis:
  Image is an ISO9660 image
Disk image analysis:
  Image does not have an x86 Master Boot Record
ISO label: '10_3_RELEASE_AMD64_UEFICD'
  Size: 733122560 bytes
  Note: This ISO uses symbolic links, which will not be replicated due to file system limitations.
  Because of this, some features from this image may not work...

[pbatard]

Despite the guide (which is exceedingly explicit about this), and the checkbox to the same effect (which you shouldn't have checked and which I unticked for you), you truncated the log. Why???

[pbatard]

Could not find FreeBSD ISO Image(except memstick*.iso)

What does this mean?

Clearly you were able to "find" the ISO image, since you selected it.
And what is "memstick*.iso"? Where does it come from?

[wbsdty331]

@pbatard
Rufus cannot recognize FreeBSD ISO Image.
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.3/
I download it and use rufus to create a bootable USB Disk,but rufus cannot identify this iso.
Maybe It's a non-standard ISO.

*-memstick.img is DD image, rufus can identify it.
but NOT iso

[pbatard]

Rufus cannot identify FreeBSD ISO Image.

The actual error reported by Rufus (which I would really encourage you to report next time) is:

Unsupported image
This image is either non-bootable, or it uses a boot or compression method that is not supported by Rufus

So, yeah, Rufus does tell you that it just can't support that image, which mostly has to do with the fact that the FreeBSD people are doing their own thing, and, unlike the Linux people, don't seem to care that much about people trying to install their OS from a FAT32 formatted USB flash drive created from Windows.

See also the first paragraph of this relevant FAQ entry.

Now, because there is little demand for FreeBSD support, I'm not planning to go out of my way to try to compensate for something that I personally think the FreeBSD should be looking into, but aren't. So I can only advise to use the memstick images, as these work fine with Rufus.

As such, I will close this issue.

[yurtesen]

@pbatard I am having the same problem. You will have no demand for FreeBSD support because you do not support it. There will simply be occasional people who bother making issue reports. :)

I find it kind of ignorant to tell that FreeBSD people do something different and they must fix it. If you have an ISO file which is standards based and you can write it to a CD and your BIOS can boot it and it works. There is no other restriction. Then how can you blame FreeBSD people for doing something wrong? Also, do you blame Linux people for creating extra work for you because they do something different than Microsoft? These are different operating systems, lets be reasonable.

Thats said the .img files can be written directly to usb drives. Here is the mailing post and the conversion info about them:
https://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048762.html
But perhaps it is best to hint to user that they should use the img file ?

@wbsdty331 you can use the .img file from freebsd downlods with win32diskimager

[pbatard]

I find it kind of ignorant to tell that FreeBSD people do something different and they must fix it. If you have an ISO file which is standards based and you can write it to a CD and your BIOS can boot it and it works. There is no other restriction.

That's where you are wrong.

USB boot and ISO boot use VERY DIFFERENT standards (El Torito vs MBR boot, since we're not talking about UEFI here), so there are two types of ISOs in this world:

• ISOs that understand that the content may be converted to USB or HDD and want to be bootable, and that take measures to ensure this can be achieved (by using a bootloader such as GRUB or SysLinux that can use the same set of config and boot files for both)
• ISOs that consider that they will only ever need to be booted through optical and don't need to accommodate USB/HDD conversion.

Obviously, *BSD falls in the later category.

You cannot simply take an El Torito bootable ISO, and, through some quick magic, turn it into an MBR bootable USB. There is no straightforward conversion between El Torito and MBR boot, because, since an ISO is not MBR based, so you have to invent an MBR that will perform the same stuff as what the El Torito process does, and since an El Torito bootloader can contain any type of bootable code you can think of (and be restricted to only work with the ISO 9660 file system, which you won't have on USB), you'd basically need to reverse engineer what that boot code does, and convert it to something that is applicable for USB. I sure wouldn't mind being able to do that in Rufus, but I don't think deep learning algorithms are quite there yet...

Then how can you blame FreeBSD people for doing something wrong?

Because they have repeatedly chose to completely ignore what the Linux distros do, which is use bootloaders that can accommodate both USB and optical boot, and therefore made their users lives more annoying as a result.

It's really not that hard to look at what other people do, and, if they managed to find a way that makes their users life better, emulate that. GRUB and Syslinux can accommodate *BSD boot. Why the *BSD people don't want to use them, is beyond me. Or, if it's because they don't want to touch anything GPL, they could also create their own dual bootloader...

Also, do you blame Linux people for creating extra work for you because they do something different than Microsoft?

Hyperbole much?

I blame ANYBODY when they screw up or make one's job harder than it should (if you look at my track record, you'll see that I rarely have any praise for Microsoft, especially when it comes to UEFI and Secure Boot).

So I will blame some Linux distro maintainers when they make the conversion process either impossible or much harder, just as I blame the BSD distro maintainers, when, and this is where you'll find consistency, they forget that they produce bootable ISOs that may be converted to bootable USB. If you create a distro and screw the possibility of converting your ISO to USB, by assuming things that won't hold, I'm gonna tell you that you're really not helping your users.

And this is one of the rare cases where using a Microsoft ISO is usually trouble free, because their (second stage) bootloaders are designed to work unmodified for both USB and optical boot, which is AWESOME for users.

Thats said the .img files can be written directly to usb drives.

I'm well aware of this. But a lot of users don't understand why they should have to use a different image file for optical and USB boot, especially when 99% of Linux ditro ISOs can be easily converted to bootable USB.

[yurtesen]

OK I accept that I was too quick to judge. But I dont know if they realize even that this problem exists or how serious it is. Thanks for the explanation. I will see what they say at FreeBSD forums.
https://forums.freebsd.org/threads/57687/

[yurtesen]

@pbatard I found that the FreeBSD people are using a very simple script to convert the ISO image to IMG file.
https://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048762.html
Isn't it so that Rufus also copy the files etc. similarly. I mean cant this be implemented?

[pbatard]

That sounds simple... until you realize it requires an OS that supports the *BSD file system (therefore has a driver for UFS) which Windows doesn't. And the issue is not IMG conversion, coz I'm pretty sure the *BSD people could create an ISOHybrid if they looked into it, but booting and installing from content that resides on a FAT32 file system, which is what they really need to support if they want to to make their installation (and conversion) process more user friendly. Which brings us back to the part where I'm curious as to why, nearly every single Linux distribution out there has been supporting FAT32 installation almost from the start, even though they genuinely don't have to (they could have taken the same approach as *BSD and require a bootable drive formatted into one of their native file systems, such as ext2/3/4), whereas *BSD has made no effort in that direction...

[yurtesen]

@pbatard I wonder why the installer shouldnt be able to use the fat filesytem. It simply mounts it as readonly root filesystem. I am not sure UFS2 is the only possible root filesystem (since ZFS also can be used, perhaps msdosfs can be used as root also). So I guess the only question is if you can tell kernel to use msdosfs as root filesystem. Which I dont know the answer to but I think I wont have time to test this out anytime soon. Maybe you could reach out to FreeBSD community and ask them about this. Just a suggestion....

[pbatard]

I wonder why the installer shouldnt be able to use the fat filesytem

The exact reason for my criticism of the path chosen by the *BSD distro maintainers, though one thing you need to realize is that FAT can be VERY limiting in terms of file names (also no symbolic links and other goodies). So it requires some consideration for an installer process to handle FAT alongside ISO9660 or UFS. And the installer process is only one part of it, you also need a bootloader that is FAT friendly (i.e. able to look up second stage loaders on FAT fs), which GRUB and Syslinux are, but AFAIK the *BSD one isn't. Oh, and it wouldn't matter if they used ZFS, since there's no native ZFS driver on Windows anyway, and again, there's a lot more than having a kernel able to handle a Windows/DOS fs.

I'm afraid that I have better things to do than try to reach to the *BSD people, especially as I consider that they should be smart enough to realize, as pretty much EVERY SINGLE LINUX DISTRIBUTION has realized, that they need to be somewhat more friendly towards an installation process that originates from the one OS that the majority of the planet uses (for better or for worse). I've had my share of trying to convince people of something that should be obvious when it comes to being user friendly, and getting frustratingly nowhere, so I have absolutely NO interest in starting another battle like this, sorry. Besides it shouldn't be up to me to get the *BSD people to be more open to what happens outside of their own microcosm.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.