Nice that the community is addressing this. I was never able to trust Ventoy in the past, and as such still have a wide array of USB sticks to install Linux flavors with.
That was both it's charm,and it's notoriousness. I was using it, but when the blob thing became a concern, me and the guy who recommended it, stopped using it,and now it's more of a curiosity, but no longer used. EFI is basically crippleware now,and two dev friends of mine just bought macs, leaving me their Lenovo collections. Two X1 carbons and three T590s.
For installation I have had to drop back to a normal single-image USB stick before now because the installer became confused by the EFI partition presented by the unpacked ISO and anything found/not on the target drives.
Ventoy is very handy for running things live though, and not all installers/situations are affected by this (and there they are, it isn't really ventoy's fault).
You don't image it. You drag and drop ISOs into a directory on the SSD, and the USB device emulates a DVD ROM drive with the contents. You choose the ISO through a small screen and button on the device.
Can confirm, also have 2 IODD devices for this purpose, though I usually grab my (simplest) USB stick that has netboot.xyz flashed to it, and just boot off that, and select whatever netboot image I want and have it get everything from the interwebs. No need to ever update this workflow.
With the iODD 2531: It has modes: CD, HDD, and dual. CD provides emulation only. HDD and dual expose an FAT32 drive volume that can contains a magic _ISO directory to store .iso's. One limitation though is it doesn't support fragmented (discontinuous) files, and so those need to be minimally defragmented occasionally.
It also has an issue with remembering the last mounted .iso if its filename is beyond a certain length, in which case it will instead load a random (although always the same) .iso in the same folder.
I mainly had this issue with the default Windows install image names.
Fragmentation can be a bit annoying, especially when using exFAT, which doesn't appear to have defragmentation tools available. It can be avoided by never deleting files and instead reformatting every so often.
That being said, it's still a fantastic tool because all the images "just work" everywhere a class-compliant USB optical drive would.
No sense using exFAT because it's not as widely-supported. Don't have to reformat fat32 because File Allocation Tables are extremely simple. Move all files off, and then move them back serially, and presto, no more fragmentation.
FAT32 is not an option because Windows images these days are all over 4GiB. exFAT is very widely supported; the alternative would be NTFS, which doesn't work well (no write support) on macOS.
I have a bunch of network-bootable installers set up on my DHCP server. If I want to install a new machine I simply set it to boot from the network. From there I can just select whichever distro I want. I also added some utils like Memtest86
I tried to set up netboot a few times, it seems like this should be very easy to do, especially that I self host many things, but I get lost in the technical details every time. I think I succeeded once, with the dhcp server running on a laptop running Debian…
Turns out doing some speleology to find a USB key and burning an ISO on it using cat or pv ends up being radically easier…
(OTOH it's been a while since I last tried and now I have root on my router running OpenWrt so I guess it would be a tad easier…)
I'm sure there's howto's around, maybe this one from ipxe is a good place to start [1], but if you're running isc-dhcpd (which is discontinued, but still works, so....) you add something like this into your subnet config:
(use your addresses instead of rfc 5737 addresses). Note that the client-arch for amd64/x86_64 matches what PXE clients actually use instead of what the rfc 4578 says (there's an errata, but rfc policy is not to incorporate corrections sigh ). If you've got other archs, you can probably figure it out.
You've got to run a tftp server on the next server address; and just FYI some PXE clients won't reach outside their subnet to get to the tftp server. Grab the ipxe binaries from wherever is convenient and they live in the root of the tftpserver.
You can follow the ipxe docs for what to put in your menu file. I've got a menu of weird things, which includes
item --key n netboot netboot.xyz [n]
You could probably just use the boot.netboot.xyz in your dhcpd config and then you don't have to write a menu at all.
Depending on your client machines, expect to have to fiddle around a bit. I've got some machines where PXE works, but the keyboard won't work in PXE, so that's not super useful. Others where PXE doesn't really work in UEFI mode, only in BIOS mode; there's probably some vice versa. Also, I've never figured out a good way to load ISOs in UEFI mode ... in BIOS mode you can use MEMDISK and if the OS supports it, it can find the disk image in memory and mount it when it boots. The netboot people do a good job of finding ways to make things work, but don't expect everything to work.
I originally started from some version of this document [2], but I've moved on since then. IMHO, netbooting is a nice way to run hobby OSes... no need to worry about a boot loader and all that, just build for multiboot and ipxe will work (and grub will work, too, if you ever do want to run off a disk)
It's possible to get Windows ISOs to boot with PXE, but it takes a lot more patience than I've got to make it work well ... if I use iscsi, the OS loads, but takes several minutes to get the disk image mounted after the installer starts; it would probably be faster to write the image to a usb disk and run from there. I was able to install to an iscsi drive, but then the same problem with mounting happened when I tried to boot from there, and then you just end up at a stop error screen because the OS really does want a mounted filesystem when it starts. (there's something about tweaking the driver setup, but that's too much work for me, I found a drive to run off of, and did what I needed to do)
If[0] the maintainer is entirely honest and well-intentioned, they are clearly a vulnerable target lacking the capabilities to reliably detect if their supply chain would be compromised. Using Ventoy is a huge risk regardless of what you think of maintainer credibility at this point.
The cynical take is that what's on display in this issue is feigned ignorance/incompetence constructing plausible deniability.
Their security posture has not evolved with the times, the threat-landscape, and the growth of the project.
[0]: Very doubtful if you have been following this saga or dig around enough
https://github.com/fnr1r is currently working on a reproducible open build system. If you wish to help the process, direct your attention there! You can see progress on the issues of their repos, as well as in this now (appropriately) locked issue: https://github.com/ventoy/Ventoy/issues/2795
FWIW "blob" isn't an acronym. It refers metaphorically to an amorphous ball of goop. In databases only, it has been backronymed to "binary large object".
Or where the LOB types could actually be text ([N]NVARCHAR(MAX) in SQL Server, or the deprecated [N]TEXT in the same), I refer to them as Bloody Large OBject.
Or if you don't like blobs but do like recursive acronyms: Bloody Large Odious BLOB.
As far as I am aware, BLOB is an acronym for "Binary Large Object" [1], but it is part of the pun that, as you wrote, a blob is (also) an amorphous ball of goop.
I used Ventoy for a long time with various distros and even Windows, but for some reason it didn’t work with Arch (btw). I had to use a separate USB thumbdrive just for it.
In fact there's no suspicion or allegation of malicious activity. This all started as a "hey it's not oss and i can't stand things that aren't oss." With all the security scare theater being used to justify the "it needs to be oss" demands.
I'll believe it when it happens. The maintainer hasn't done much regarding this for over 5 years. There are issues raised about this back in 2020 and not much has changed. It just seems suspicious to me. But I might be paranoid.
The primary reason why I use Ventoy is because of its ability to use multiple ISO's, which I can select from when booting. I don't think that's possible with dd.
It's also possible to use the usb stick for regular files, Ventoy will just ignore them. Pretty useful when you need it.
Nice that the community is addressing this. I was never able to trust Ventoy in the past, and as such still have a wide array of USB sticks to install Linux flavors with.
NB mainly iVentoy seems to be suspicious, relying on Windows exploits to bypass certification needs.
That was both it's charm,and it's notoriousness. I was using it, but when the blob thing became a concern, me and the guy who recommended it, stopped using it,and now it's more of a curiosity, but no longer used. EFI is basically crippleware now,and two dev friends of mine just bought macs, leaving me their Lenovo collections. Two X1 carbons and three T590s.
For installation I have had to drop back to a normal single-image USB stick before now because the installer became confused by the EFI partition presented by the unpacked ISO and anything found/not on the target drives.
Ventoy is very handy for running things live though, and not all installers/situations are affected by this (and there they are, it isn't really ventoy's fault).
I just use an enclosure that emulates a dvd-drive. Put a cheap SATA ssd in there and you can stop worrying about incompatibilities.
How do you image the SSD? Isn't it kind of the same issue as with imaging a USB stick?
You don't image it. You drag and drop ISOs into a directory on the SSD, and the USB device emulates a DVD ROM drive with the contents. You choose the ISO through a small screen and button on the device.
Can you give the model name of the one you use?
not the OP but I use the IODD ST400 for this purpose and wish I had gotten something like this long ago
Can confirm, also have 2 IODD devices for this purpose, though I usually grab my (simplest) USB stick that has netboot.xyz flashed to it, and just boot off that, and select whatever netboot image I want and have it get everything from the interwebs. No need to ever update this workflow.
Will netboot.xyz boot from a WiFi connection? I've always assumed no, and most of my machines do not have Ethernet jacks anymore.
Way too many unnecessary features and too expensive. The 2531 is perfect.
I've had this since about 2014.
I think both of them have been at the same price for at least 2 years now.
All things being equal, simple and proven is better than over-complicated and extraneous.
With the iODD 2531: It has modes: CD, HDD, and dual. CD provides emulation only. HDD and dual expose an FAT32 drive volume that can contains a magic _ISO directory to store .iso's. One limitation though is it doesn't support fragmented (discontinuous) files, and so those need to be minimally defragmented occasionally.
It also has an issue with remembering the last mounted .iso if its filename is beyond a certain length, in which case it will instead load a random (although always the same) .iso in the same folder.
I mainly had this issue with the default Windows install image names.
Fragmentation can be a bit annoying, especially when using exFAT, which doesn't appear to have defragmentation tools available. It can be avoided by never deleting files and instead reformatting every so often.
That being said, it's still a fantastic tool because all the images "just work" everywhere a class-compliant USB optical drive would.
No sense using exFAT because it's not as widely-supported. Don't have to reformat fat32 because File Allocation Tables are extremely simple. Move all files off, and then move them back serially, and presto, no more fragmentation.
FAT32 is not an option because Windows images these days are all over 4GiB. exFAT is very widely supported; the alternative would be NTFS, which doesn't work well (no write support) on macOS.
> exFAT is very widely supported;
Except it's not by all of the things I need to use, so that's not going to work. Compatibility vs. 4 GiB limit. There is no perfect, only trade-offs.
iODD 2531 is the cheapest and simplest such example.
doesn't it have firmware? :)
I have a bunch of network-bootable installers set up on my DHCP server. If I want to install a new machine I simply set it to boot from the network. From there I can just select whichever distro I want. I also added some utils like Memtest86
Do you have this documented somewhere?
I tried to set up netboot a few times, it seems like this should be very easy to do, especially that I self host many things, but I get lost in the technical details every time. I think I succeeded once, with the dhcp server running on a laptop running Debian…
Turns out doing some speleology to find a USB key and burning an ISO on it using cat or pv ends up being radically easier…
(OTOH it's been a while since I last tried and now I have root on my router running OpenWrt so I guess it would be a tad easier…)
I'm sure there's howto's around, maybe this one from ipxe is a good place to start [1], but if you're running isc-dhcpd (which is discontinued, but still works, so....) you add something like this into your subnet config:
(use your addresses instead of rfc 5737 addresses). Note that the client-arch for amd64/x86_64 matches what PXE clients actually use instead of what the rfc 4578 says (there's an errata, but rfc policy is not to incorporate corrections sigh ). If you've got other archs, you can probably figure it out.
You've got to run a tftp server on the next server address; and just FYI some PXE clients won't reach outside their subnet to get to the tftp server. Grab the ipxe binaries from wherever is convenient and they live in the root of the tftpserver.
You can follow the ipxe docs for what to put in your menu file. I've got a menu of weird things, which includes item --key n netboot netboot.xyz [n]
You could probably just use the boot.netboot.xyz in your dhcpd config and then you don't have to write a menu at all.
Depending on your client machines, expect to have to fiddle around a bit. I've got some machines where PXE works, but the keyboard won't work in PXE, so that's not super useful. Others where PXE doesn't really work in UEFI mode, only in BIOS mode; there's probably some vice versa. Also, I've never figured out a good way to load ISOs in UEFI mode ... in BIOS mode you can use MEMDISK and if the OS supports it, it can find the disk image in memory and mount it when it boots. The netboot people do a good job of finding ways to make things work, but don't expect everything to work.
I originally started from some version of this document [2], but I've moved on since then. IMHO, netbooting is a nice way to run hobby OSes... no need to worry about a boot loader and all that, just build for multiboot and ipxe will work (and grub will work, too, if you ever do want to run off a disk)
It's possible to get Windows ISOs to boot with PXE, but it takes a lot more patience than I've got to make it work well ... if I use iscsi, the OS loads, but takes several minutes to get the disk image mounted after the installer starts; it would probably be faster to write the image to a usb disk and run from there. I was able to install to an iscsi drive, but then the same problem with mounting happened when I tried to boot from there, and then you just end up at a stop error screen because the OS really does want a mounted filesystem when it starts. (there's something about tweaking the driver setup, but that's too much work for me, I found a drive to run off of, and did what I needed to do)
[1] https://ipxe.org/howto/dhcpd
[2] https://wiki.debian.org/PXEBootInstall?action=show&redirect=...
It’s been a while since I set it up. I use dnsmasq as my DHCP server and if I recall correctly it includes everything needed to set this up.
It's been something like two decades since I last set up a network installer, but iirc, there is a dnsmasq tutorial for pxe booting online.
That used to be the only way to install Linux on apple hardware (think original iMacs here). You could likely find some archived docs there.
> Do you have this documented somewhere?
For what it's worth, there is a Ventoy for that, too.
https://www.iventoy.com/en/index.html
Thanks all for your answers.
If[0] the maintainer is entirely honest and well-intentioned, they are clearly a vulnerable target lacking the capabilities to reliably detect if their supply chain would be compromised. Using Ventoy is a huge risk regardless of what you think of maintainer credibility at this point.
The cynical take is that what's on display in this issue is feigned ignorance/incompetence constructing plausible deniability.
Their security posture has not evolved with the times, the threat-landscape, and the growth of the project.
[0]: Very doubtful if you have been following this saga or dig around enough
> Very doubtful if you have been following this saga or dig around enough
This is the first I'm hearing of any of this drama. Any links to relevant information indicating that the maintainer is being disingenuous?
There are probably better links still around if you DYOR but a sample with further pointers:
https://nixsanctuary.com/ventoy-718-shades-of-open-source/
https://news.ycombinator.com/item?id=40689629 (See also: Sus behavior from Deepin which recently got the project removed from Suse)
https://feddit.org/post/12078124
https://linuxmom.net/@vkc/112906968594601449
I really like Ventoy and use it and I’m just not worried about getting attacked with it on my personal homelab.
It just works really well.
https://github.com/fnr1r is currently working on a reproducible open build system. If you wish to help the process, direct your attention there! You can see progress on the issues of their repos, as well as in this now (appropriately) locked issue: https://github.com/ventoy/Ventoy/issues/2795
FWIW "blob" isn't an acronym. It refers metaphorically to an amorphous ball of goop. In databases only, it has been backronymed to "binary large object".
Good point, [1] is a handy reference on the word. Also used in the compound word "blobfish", of which [2] is a well-known specimen.
[1]: https://en.wiktionary.org/wiki/blob
[2]: https://en.wikipedia.org/wiki/Mr_Blobby_(fish)
Or where the LOB types could actually be text ([N]NVARCHAR(MAX) in SQL Server, or the deprecated [N]TEXT in the same), I refer to them as Bloody Large OBject.
Or if you don't like blobs but do like recursive acronyms: Bloody Large Odious BLOB.
> FWIW "blob" isn't an acronym.
As far as I am aware, BLOB is an acronym for "Binary Large Object" [1], but it is part of the pun that, as you wrote, a blob is (also) an amorphous ball of goop.
[1] At least according to the German Wikipedia: https://de.wikipedia.org/wiki/Binary_Large_Object
The Blob is a movie from 1958 and the blobs in databases were named after the movie. Later, some people felt that blob should be an acronym.
https://web.archive.org/web/20231108173312/https://www.ibpho...
> Later, some people felt that blob should be an acronym.
At least this acronym took on a life of its own: we now also have CLOBs (which correspond to no English word that I am aware of): https://en.wikipedia.org/wiki/Character_large_object
Aka a backronym.
clobber
verb: informal hit (someone) hard. treat or deal with harshly. defeat heavily.
Noun: British slang for Clothes, circa 1879
The Fantastic Four's The Thing's catchphrase, "It's clobberin' time!" was the only "clob" I was aware of prior to doing these searches.
Well, hmmm, the word "blob" way predates the 1958 SF horror film of that name:
https://www.etymonline.com/word/blob
https://en.wikipedia.org/wiki/The_Blob
I used Ventoy for a long time with various distros and even Windows, but for some reason it didn’t work with Arch (btw). I had to use a separate USB thumbdrive just for it.
Arch worked just fine for me
I’ve never had issues using Ventoy to install Arch.
I've had Arch isos work fine from Ventoy, also had Arch isos not able to complete installs without Ventoy.
Having just used Ventoy to install Linux on a computer, should I consider it compromised and reinstall? Or technically completely trash it?
That would be quite an overblown reaction. There is currently no proof of malicious activity.
In fact there's no suspicion or allegation of malicious activity. This all started as a "hey it's not oss and i can't stand things that aren't oss." With all the security scare theater being used to justify the "it needs to be oss" demands.
I'll believe it when it happens. The maintainer hasn't done much regarding this for over 5 years. There are issues raised about this back in 2020 and not much has changed. It just seems suspicious to me. But I might be paranoid.
I'm not willing to trust it.
Same. Even the issue presented here seems to not be taken seriously.
Paraphrasing, but things like: "Ah well, some blobs are ok, it is just for convenience" just smells like trouble.
The project is free and all, but damn. Has nobody, in the last half a decade, thought about automagically building those blobs alongside the project?
In my brain you're just postponing a large build system refactor, one that will get worse over time.
So much work because most people can’t manage a simple dd-invocation.
And because Windows don’t allow direct access to the physical layer from a user-space shell.
Such a waste.
The primary reason why I use Ventoy is because of its ability to use multiple ISO's, which I can select from when booting. I don't think that's possible with dd.
It's also possible to use the usb stick for regular files, Ventoy will just ignore them. Pretty useful when you need it.