IODD is a korean manufacturer of special harddrive enclosures.
They have an LCD and controls to navigate through the files/folders stored on NTFS/FAT.
By selecting an ISO file, the drive announces itself to the computer as a CD/DVD/BD drive containing the ISO. It can also do this to emulate a floppy disk drive, and up to 4 non-/removable USB drives.
No need to hope for GRUB magic to maybe work.
Their website and documentation sucks, but the product makes you giggle at the idea of using yumi/rufus/easy2boot/looking for empty/erasable thumbdrives.
The latest iteration is the IODD-MINI. Though it looks like the crowdfunding campaign botched, i just bought myself the 512 GB version off Amazon Germany this week.
most rooted Android devices can do something like this with the USB Mountr app (available on F-Droid). unfortunately, most kernels only provide mass storage device support, not optical drive, but it's usually good enough.
any usb gadget should require root, otherwise there are serious security issues. my concern with drivedroid is that it is closed source, which is highly worrisome for a root app.
I've owned two IODD drives, one a "Zalman VE300"-rebadged IODD 2531, and a IODD 2541. Both second hand when I had them.
After a few years of heavy use by me, the 2531's firmware corrupted. Reflashing using arcane prayers, legacy software flashing tool, and a physical Windows XP box got it back up and running. I gave it to a friend who still uses it.
With a 120GB cheap (no DRAM) SATA SSD, these things are fantastic.
I vaguely remember having some hassle initially formatting the drive for the ISOs once, but after that, it's worked flawlessly for so long I can't remember the details.
Despite both working solidly, I really want a Mini just because it would let me slim down my toolkit further.
Yes. It's disappointing to hear your friends didn't receive theirs. If they're still interested, there are comments on that Kickstarter organizing an independent production run of the open source design.
I wish every ARM device supported UEFI. Custom images for ever singly ARM device is not sustainable. Only Microsoft required UEFI on ARM devices (and maybe Apple now with their own silicon?) but they locked all those bootloaders. Even when people found ways past those locks, there are no open source drivers for all the hardware on Lumia phones, so they're all useless e-waste bricks now.
Afaik, UEFI (at least on ARM hardware I worked with) embeds the DeviceTree for non-ACPI boot usecases, so the user is no longer responsible for providing the proper DTB for that board, although the user can still override it if needed.
Last time I worked with ARMv8, UEFI provided both ACPI tables and the embedded DTB, since ACPI support was undergoing a major rewrite in the kernel at that time.
I have a sacred USB thumb drive with the Windows 10 installer on it. It is sacred because it took me hours to figure out how to make it bootable. If I recall, Microsoft's own tool for _expressly this purpose_ did not work (after having to set up a virtual machine to use it, etc. etc.), and was apparently a known problem.
I think it was WoeUSB that finally worked for me, not plain dd or Rufus or Apple's Boot Camp utility. Ventoy looks impressive, but unfortunately too many tools don't work.
Weird I've never had a problem using Rufus to setup a bootable windows installer USB from the official ISO download. Have never tried from a VM though.
Rufus consistently for me for making a win10 USB using a Windows VM on a Linux host, after hours of trying with dd and other methods inside Linux. It's a ~2.5 mb executable which just works. And since you already have the win10 ISO to be flashed, making the VM isn't too hard.
Ventoy installs special software on the removable media and from then on you can freely add or remove .iso files to its root directory whenever you please. It worked without hassle on 3 separate old laptops for me, including with the official Win10 ISO image.
Windows file systems work very differently from Linux. If a file is open, Windows will put a lock on it that prevents moving or deleting the file -- and the executable image of a process is open for as long as the process runs.
This is different from the Linux situation, in which a file's name and directory location are separate from its inode, or the data structure holding actual information about the file including where the data lives on disk: once the inode associated with a file name is looked up and the file opened, anything may be done with the file name, including changing or unlinking it. Inodes with no links will also only be freed once every open file descriptor on the unlinked inode is closed. So a process will keep on chugging even if its executable file on disk is deleted, as though nothing happened -- because the file itself is only deleted once its inode is closed and unlinked.
This sounds like the VM hypervisor was not correctly setup to provide the required access to your USB stick to the virtualized OS. That’s hard to fix from inside the VM.
That only works if the system you're trying to boot the drive from has NTFS UEFI drivers, or if you format your drive as FAT32. Recent versions of Windows 10 cannot be copied and pasted to FAT32 drives because the system image is bigger than 4 GB.
When I built my new PC I also spent a couple of hours on it, because most of the old documented and simple solutions did not work.
When I had a big partition that could hold the image the system wouldn't want to boot from it. On the small Fat32 partition the image didn't fit.
I think in the end I had to create 2 paritions, a Fat32 and an ExFat one. Then I had most of the boot files on both, but the big windows image only on the ExFat one.
That actually works - when the installer can't find the big image on the original partition you can point it to the other one and the installation will continue.
Not sure why the downvotes for you. I just did this last week and expected to have to jump through a bunch of hoops and download some software that would burn a bootable image to a usb. Nope just format it as NTFS and copy paste the files from the iso.
Although now this is even easier if you commonly are installing a new OS. But for the typical enthusiast that installs a new OS every couple years this solution is overkill.
only works if you are already using windows and therefore can use diskpart/"mark as active", or you are booting from an extended uefi firmware with the appropriate drivers (e.g. dell).
I formatted the stick on ubuntu as NTFS and installed it on a new sdd. No windows used during the process. Don’t know if the MSI MoBo had appropriate drivers.
> UEFI:NTFS is a generic bootloader, that is designed to allow boot from NTFS or exFAT partitions, in pure UEFI mode, even if your system does not natively support it. This is primarily intended for use with Rufus, but can also be used independently.
This didn't work for me for Windows 10 - I tried for a few hours using all the methods I could find online, with fat32 and NTFS partitions, as well as the 'traditional' dd/cat method, and in the end only Rufus worked.
While I think this is really cool, and would have come in handy earlier in my life. Where I’m at now I don’t commonly install new OSes, and if I want to play with a new OS I’m more likely to do it in a VM. So the only time I really do a fresh install is every 5-8 years when I do a full new build.
This is a slick solution, but I think the average person it would be easier to just copy paste the files from the iso onto a usb and call it a day.
I've used YUMI in the past too.. But it's Windows-only, and I only keep a Windows install around on my desktop, not laptop. Also, this tool's ability to just copy isos over to the drive looks amazing. Haven't tried it yet so I hope it works!
Ventoy works surprisingly well, almost exactly the way you describe. First you run the tool that installs software on the USB stick and then you can just add/remove ISO files to it whenever you like. The boot manager installed on the stick detects them and allows you to boot through any of them.
I’ve been using this for a few months. Once it’s setup you simply drag and drop distros onto it. I’ve tested the following and it works fine: Kali, Pop_OS, Elementary, Ubuntu and Mint.
In my case, I use a few different distros around the house, arch for my desktop/laptop, fedora for the htpc, popos for my wife's laptop, elementary for the kids.
Having a single boot drive to install / update / fix problems is handy.
I know running `cat distro.iso > /dev/sda` isn't hard but at least I don't need to tie up multiple 32gb flash drives with 700mb isos.
I think the main thing today is that I have very high capacity flash drives regardless, may as well make good use out of them.
I have a multi-boot MacBook Pro 2007 with Mac OS 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, Windows Tiny7, Windows XP, and Ubuntu.
It's been useful to boot into WinXP to play AoE or WoW, or Mac OS 10.9 to run p0sixspwn to jailbreak an iPhone 4S. The laptop has a 2 TB drive, and a lot of legacy software just in case I need to open some obscure file (e.g. AppleWorks).
I regularly find old laptops in the trash, and friends like it very much when I repair them and give them away. Some only boot Win10, others only Win7 (x64 or x32), and the oldest only XP. As for why you'd want various Linux distros, I imagine it's a similar platform-sensitivity issue.
I wish there were a bundle pack of USB drives with installers for all Windows and Mac OS versions, so I could just pick out the right installer and install. And another bundle of live USBs. Carrying around lots of USB sticks would be bulky, but somehow I expect it to be more reliable than Ventoy - my experience with the Zalman ZM-VE350 has never been reliable enough to replace an external CD drive.
I have a late 2007 MBP too (superdrive removed) and was never able to boot and install an OS straight from USB(tried refit and refind too)
, be it clonezilla, Win 7 32/64Bit; only OS X works via USB. (Windows via superdrive worked flawlessly).
Luckily I had an old winclone backup I could use, when I replaced the SSD last year.
It sounds like you have one of the last of the early 64-bit Macs that had a 32-bit EFI. They were difficult beasts to get working with anything other than officially supported macOS versions. You can follow the guide linked below but basically you need to create a 32/64 hybrid EFI boot image. There were some Windows machines (mainly BayTrail and similar vintage tablets) that also had this issue and the solution is very similar.
Thanks for the hint ("beast" descibes it perfectly :) ), seems mine is castrated:
"Furthermore, it appears that although subsequently released MacBook, MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped with "Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked these "consumer-targeted" Macs from booting in 64-bit mode. iMac and MacBook Pro models released in 2007 with 64-bit EFIs seem to have been blocked as well."
Ouch, I had forgotten about those specific devices. I had a Mac Mini Core Duo that I had upgraded to a Core2 Duo and was never able to get Snow Leopard to boot into 64-bit mode. I was able to get Linux and even OpenBSD installed on it using the previously mentioned bootia32.efi method.
Also, you may be able to boot 64-bit macOS on your system if you follow the netkas.org link from your everymac.com link:
Instead of using multiple USB drives, each dedicated to one OS install image, a sysadmin only needs to have one large USB drive that olds all ISO images they need.
> GRUB can read ISO9660 (”iso”) images. It can for example load the first few sectors and boot it. But most people do not realize is “what then?”. What would the loaded operating system do? It will most likely look for a CDROM, which it won’t find, and fail.
> A "Ventoy Compatible" concept is introduced by ventoy, which can help to support any ISO file.
from the "Ventoy Compatible" page:
> From the document you can see that ventoy will create a virtual disk from the iso file and boot it. But the virtual disk is only on BIOS(Legacy or UEFI) level. In most case it works only in bootloader period. Most of the morden OS's kernels will use their driver to access hardware after boot, so the virtual disk will not be visible to them. In normal case, the OS will search all the hardware storage media(CDROM/USB/HD ...) to find the source medium. But with ventoy they will not find such medium because there is no such physical media and they don't know that they were booted from a virual disk. In order to support that ventoy must do some hook before boot. But the hook is really a hard work because there are so many different OS distros and so many special cases.
I wonder how true that is nowadays - that answer is 10 years old and I remember some Linux distro those days having seperate images for liveusb/livecd/netinstall etc., But most distros these days have a single image for both usb boot and cd boot.
I.e. files that are at the same time a valid .iso and a valid disk image.
Basically you can add to a normal bootable .iso a MBR taking advantage of the fact that the MBR is first absolute (512 bytes) sector of the device whilst the CD/DVD bootsector is the 17th sector (2048 bytes).
A BIOS will chainload the MBR on hd-like devices (including USB sticks) or the CD/DVD bootsectors (on optical media), then Syslinux/Isolinux, or grub4dos or GRUB2 (among others) will do the rest (chainloading the kernel and initrd and boot the Linux.
> What would the loaded operating system do? It will most likely look for a CDROM, which it won’t find, and fail.
This answer doesn't seem right to me at all.
I'm not a OS expert, but I've spent some time booting weird hardware.
Generally, the boot process will load a kernel into memory, which has drivers for (hopefully!) the hardware needed to load the rest of the OS. The boot instructions (from GRUB or whatever) will specify the root partition (in linux) and enough information on how to load it.
That might be on a local drive, a CD/DVD or a network device, but provided the kernel has the driver available it doesn't really matter.
Of course it depends on the OS but generally speaking Linuxes will auto-recognize/automount .iso files, as long as they have an entry in the MBR (that - just as an example - can be done on-the-fly by grub4dos using its partnew command):
Since all in all that happens is that a contiguous extent on disk is mapped as a partition, there is the requirement for the .iso image to be contiguous in the hosting filesystem.
Ventoy goes beyond this as it virtualizes the .iso blocklist , thus allowing non-contiguous images:
I discovered it a few days ago and used the latest (1.0.19) version to boot the Linux Mint 20 iso and install it to my laptop without problems. Looks like there's also a "Tested ISO" page[0] on the official site.
I used this to fix a broken windows system recently while visting my "in-laws".
Probably a bodged update, booting windows resulted in "Boot device not found".
I had created the stick a couple of weeks earlier and put some ISOs on there, including windows 10 and ubuntu. Just have it with my leys now.
Used the Ubuntu stick to assess the situation, run smartmontools on the disk, backup data to an external hard drive and then used the windows stick to restore a recovery point which fixed the system.
I have been using a rooted Android phone with DriveDroid which mounts images as a USB drive for a PC. It works pretty well too. (Except for Windows setup ISOs. Those does not support direct booting from a USB drive and I had to mount a blank image and use Rufus to properly write it as a bootable non-optical disk.)
This seems to be a fine alternative that I will have to try. The problem is that I don't really have large USB sticks for this anymore...
You can't dd them. Format a USB drive, make a fat32 or ntfs[1] partition. Extract all the files from the ISO (mount -o loop to an intermediate directory and copy the files out, 7z can also do it) onto said partition. Set the bootable and ESP (EFI System Partition flag) flags. Works like a charm every time.
(You can also try the woeusb[2] tool, but it's not doing anything fundamentally different to or better than that.)
1. Fat may be problematic; iirc install.wim is >4gb lately. But ntfs-3g is adequate if lacklustre.
I think it would only work if your UEFI firmware happen to contain a driver for reading NTFS partitions. UEFI firmwares are only required to read FAT12/FAT16/FAT32. Rufus solves this by making an extra FAT partition with a UEFI:NTFS [1] binary which loads its own NTFS driver to boot the Windows `bootmgfw` EFI binary.
That's why after all these years I am still interested in the Firmware or the hypervisor level emulation of the optical drive.
Maybe by even including the whole virtual storage controller (like Adaptec 29160N SCSI Card), OpROM on which could support boot seamlessly for most BIOS or UEFI firmwares.
And which would be supported by most PC OSes including some more obscure like MS-DOS, OpenBSD, Solaris 10, BeOS, MorphOS.
(Or maybe by trying to integrate the emulated ODD subsystem into physical USB stack. Which I guess would be a lot more difficult)
I wish I'd known about this six months ago. I never had time to sort out Windows boot USBs in my last role (always other priorities), but if this made it easy enough I could have snuck it on.
Holy shit this is some fast progress. I've had to fiddle with EFI and iPXE recently and the experience was horrible. Basically you try ten different systems and they all have ten different issues. Very recent systems are somewhat ok but running a machine from four years ago in efi mode is a clusterfuck if you try anything more involved than "boot Windows or Linux from disk".
The compatibility matrix of this tool right here is impressive.
Actually you most probably had to fiddle with so-called UEFI, i.e. Universal EFI which should really-really be called UUEFI (Unlike Universal Extended Firmaware Interface).
This seems very similar to Easy2Boot[0] which I’ve used for several years with mixed success. Some systems don’t like booting from weird embedded GRUB variants. Some systems don’t boot it at all. I would assume Ventoy is based on a similar approach, I wonder if they have managed to solve some of E2Bs problems?
> With ventoy, you don't need to format the disk over and over, you just need to copy the ISO/WIM/IMG/EFI files to the USB drive and boot them directly.
But isn't copying the ISO file about as much work?
Instead, I suspect a better solution would be to have a bootable file system on the USB drive (instead of an ISO file), which you can rsync new versions to.
With this you can have several ISOs on a single USB and select between them, instead of having several USBs. It's also not super beneficial for my use, but I can imagine it being convenient if you use ISOs/whatever a bit more frequently than I do.
Why is copying ISO file the same amount of work as launching Rufus and going through menus?
> which you can rsync new versions to
Both cases, it is more work than what you're objecting.
"you just need to copy the ISO/WIM/IMG/EFI files to the USB drive and boot them directly" - Can you explain what specifically is painful about this process?
With Windows you just copy paste the contents of the iso over to the usb. I just completed a ryzen build last week and expected to need special software to build a bootable usb. Microsoft’s documentation told me that I didn’t and to just format as NTFS, mark the partition active and copy/paste the iso.
This tool is fantastic. It saves me from writing different images to a usb stick when need different boot media, especially when working on windows as windows disk manage seems to have problems cleaning usb sticks with some particular iso images.
This is the first I've heard of it and I'm definitely keen to try it out. I can keep one 128GB USB3 flash drive rather than a handful of smaller drives that need to be labeled or color coded so I don't forget which one boots a particular OS.
The Windows WIM support is especially nice for work where most of our machines are Windows based and again I can carry just one flash drive to cover several different builds of Windows plus HBCD.
It appears to be read only be default but supports persistence, according to that page:
> Persistence supported (1.0.11+)
There's a link to more info [1] which says how to configure it: there's a JSON file with config info, in which you specify a file on the USB stick for it to save the data.
Ah, then this might be exactly what I am looking for for my 128gb flash drive: I want a persistent Ubuntu image with all my software, and an encrypted dmcrypt (cryptsetup makes this easy) partition to hold my backups.
One distinction is that ventoy is straight open source software. easy2boot is free (no cost), but appears to be a mix of open source and closed source software.
This reminds me of tonymacx86 bootable cd iso's if you have created a hackintosh before. Similar idea if you interested in a mac(although I don't believe the iso's are bootable anymore).
Their website and documentation sucks, but the product makes you giggle at the idea of using yumi/rufus/easy2boot/looking for empty/erasable thumbdrives. The latest iteration is the IODD-MINI. Though it looks like the crowdfunding campaign botched, i just bought myself the 512 GB version off Amazon Germany this week.