Ventoy (Another Multi-Boot App) to create bootable USB drive using iso's

[wizard]

@rockedge

I'm not sure what qualifies as Live except that it can be used without install. The 2 Ubuntus are the latest Clonezilla and Rescuezilla iso's downloaded from their sites and can be installed to a usb, so I think they would be live versions. Also not sure where to check if the puppy iso's have loopback.cfg. The versions are Precise 5.71, Dpup Stretch 7.5rc5, and Fossa64 9.5. All have been remastered.

wizard

[Clarity]

Guidance for ISO file booting

Puppy booted 'pristine', at shutdown allows the session to be save. When using the PUPPY wizard for session saving, sometime you will not be offered the prevailing system disk drive. This seems to be happening on those systems which do not have a Linux partition present on the system's drive.

This, I feel, was always a bug in Puppy Linux shutdown processing as there are multiple other system disk locations for the session be saved. But, in the years, this has not been fixed.

@gyrog has done some very credible work in the start & shutdown areas of PUPs since I have been a member here. As such he may be the best in the community to know if this is a processing bug or if some other hardware condition exist that cause that phenomenon of not offering anything but an ISO9660 at shutdown even when other writable disk may be present.

The current shutdown wizard used when a pristine boot is concluding does not allow a change in the drive selected in that final status screen before actual shutdown. I am sure that there is a reason, but I am not in a position of knowing.

FYI

[wiak]

@wiak

Just to note all of the iso files, 3 Puppy, 2 Ubuntu (the "zillas"), 1 Win7 and 1 Win10 booted without problems. It would be interesting to see if WDL would boot without the special code.

wizard

I made an WDL iso (slightly modified one I had from rockedge) and it booted in RAM successfully from Ventoy, for what it's worth...
Persistence option didn't work with Ventoy out of the box. I believe I would have to make the Ventoy persistence container you mentioned and put a kernel line boot option into the iso that told it to place the upper_changes save folder into there. i.e. I am sure an iso could be made with WDL that would work with Ventoy and include persistence capability.

However, that is quite a bit of work, and Ventoy is quite different in approach to SG2D. Ventoy does not (seem to me on quick look) use boot/grub/loopback.cfg and, usefully, SG2D does. Indeed I had a problem booting at all with Ventoy with rockedge created iso - reason is that rockedge used isolinux to boot on the iso I had and Ventoy used the isolinux.cfg file to effect booting - alas the method selected by rockedge there doesn't work from Ventoy's boot from iso file point of view. I thus modified that isolinux.cfg file to make it work from Ventoy's perspective, which it did. Question then becomes, could the iso be booted as rockedge intended (from say an actual CD or as such in qemu) and also as a boot from iso file from either SG2D or Ventoy perspective. With SG2D there is no problem there at all since SG2D uses the loopback.cfg file for its grub2 boot instruction (and couldn't care less about the underlying isolinux boot, which is great).

But yes, I could create a suitable iso config that would boot via Ventoy too I think, and without changing any inside initrd WDL code, which has all the functionality needed already). However, bottom line is, I find it a real pain with no real gain and feel that Clarity is actually correct - SG2D works without effort - Ventoy needs special iso construction consideration - also SG2D can find and boot isos no matter what partition you put them on. Frankly, there is not enough time in the day (and specially since personally I prefer straight grub2 booting, including if I want to boot from an iso file), so my inclination at the moment is that I won't be bothering to specially support Ventoy - but SG2D is already catered for and working without any further thought required so just use it (or as Clarity suggests, use SG2D inside your ventoy creation too). Part of the reason it is needs a special configuration to let Ventoy boot WDL is because WDL is designed to allow a user to specify (on grub kernel line) where they want to put their save file (it doesn't just simply always get put into the bootfrom directory) and Ventoy needs to be passed that info carefully (so does SG2D, but loopback.cfg makes that easy since it is completely separate from normal grub.cfg or isolinux.cfg), and even the sfs layer files can be stored in various alternative partitions with WDL if a user so specifies; no problem for Ventoy booting Win10 of course since that is simplest scenario of all - just that one partition boot from start location.

Maybe later I'll come back to Ventoy if it is proving really useful to many people, though no promises. Basically I'm taking a rest at the moment - but no new coding is required, I think, anyway - it is hopefully just config files to set up in a different way. I'd have to document how-to-configure the boot files if making a WDL iso (and let rockedge know since his current method won't work with Ventoy but will work with SG2D as long as he supplies the required loopback.cfg file, which I've already given exemplars for).

[rockedge]

I'm not sure what qualifies as Live except that it can be used without install.

That is exactly what I meant!

[Clarity]

Persistence option didn't work with Ventoy out of the box. I believe I would have to make the Ventoy persistence container you mentioned and put a kernel line boot option into the iso that told it to place the upper_changes save folder into there. i.e. I am sure an iso could be made with WDL that would work with Ventoy and include persistence capability.

Puppy and DOGs, too, have their own methods of persistence for the running desktop; namely the save-session subsystem.

Ventoy's idea of a "universal persistence" for what it does for ALL ISOs does not compete with what Puppy Linux has built-in. This Ventoy version of persistence is rather new. It still seems to have a ways to go before it is universally accepted in the wider Linux community of Distros.

As a boot-lister, I find its value, same as I do using SG2D... present a list of available files it will launch to an OS desktop. But, Ventoy's persistence seems is early, new, and different, at this point in time.

When booted, PUPs & DOGs, today, continue behaving, as always, allowing session persistence within their framework(s).

IMHO.

[wiak]

When booted, PUPs & DOGs, today, continue behaving, as always, allowing session persistence within their framework(s).

Well, session persistence doesn't happen by itself. It is a matter of coding (which is what I assume you mean by 'their framework), and particularly the method by which it is arranged to work by code inside the initrd/init script (usually). Of the various forms of save persistence, the most common is that of saving back to either a file or folder on the partition the linux kernel and initrd is stored. But when booting from an iso file, you cannot save back into the iso file, so the partition/directory where that iso file is stored 'might', most likely, be used for save persistence location (if the internal initrd/init code is designed to do that for boot from iso file situation). Such persistence mechanisms may work out of the box with Ventoy with many distros, on most occasions, but perhaps with not all optional boot modes.

With WDL, for example, it is possible to arrange booting inside an iso by specifying /mnt/sr0 as the location to boot from - to WDL that implies (meaning is interpreted by the initrd/init shell script code as to use dir / as the location on the cdrom where kernel is and thus location for save file/folder, but for boot from iso scenarios that isn't going to work since cdrom is read/only and what really needs to be used in boot from iso file situation will be something like /dev/sdb1/BOOTISOS/.

That is the issue in a nutshell - so depends how the distro initrd/init shell script is designed to arrange matters - so to use boot from iso file method may well require substantially modified initrd/init code - just depends on the original design. The distro's initrd/init knows nothing about Ventoy and doesn't care or need it - unless that init file has been specially designed/coded to be able to know to use, for example, /dev/sdb1/BOOTISOS for saving back to even when being booted directly via an iso file.

WDL basically provides/understands three main ways to find the kernel being: 1. directly (e.g. /mnt/sdb2/WDL_dir, or, say, /mnt/sr0/) - but that's a simple unreliable location specification since system can randomly assign sd letters to actual devices, particularly when usb hardware; 2. via specified UUID; 3. via specified LABEL.

WIth SG2D some new code has been added to allow special treatment of .iso files (the initrd/init) and to accordingly then determines the rw partition/dir to put the save persistence information. For SG2D boot from iso file capability, the iso designer just needs to provide a suitably configured loopback.cfg file and all will basically work, even when isolinux.cfg just says to use /mnt/srX (the cdrom). Ventoy doesn't provide the same info via any loopback.cfg file but instead reads the main isolinux.cfg line, hence not so easy to fix the issue (since simple /mnt/srX won't work with Ventoy), but should be possible in WDL boot configs to use LABEL boot method rather than /mnt/srX - i.e. have a LABEL assigned to the iso file, and boot via that and all should be well for Ventoy use (I think). This is just off the top of my head - I haven't focussed on the matter or tried it further.

[Clarity]

Although, slightly more advanced, for PUP-DOGs I interrupt each at the distro's boot-menu, and add a "save location director" to the linux line. For example for all my PUPs & FATDOG, I add this for EVERY PC I boot to using either of the 2 ISO file booters; Ventoy/SG2D:

Code: Select all

vmlinux .... psave=sdaX:/Sessions/ 

Code: Select all

vmlinuz ... savefile=direct:device:sda3:/Sessions/fd64save-812

Of course, everyone knows that sdaX is the partition number where you are permanently keeping your /Sessions folder. Since ALL save-session folders for each PUP are kept in that Sessions folder location, it get around the sometime issue that would occur with ISO9660 some users run into...depending which PC platform they pristine boot on.

On another note, here is my list of PUP-DOG ISOs on my SG2D & on my Ventoy USBs in the BOOTISOS folder. My KVM setup for booting each 4 PCs from single USB is seen here.

Code: Select all

clonezilla-live-2.7.1-22-amd64.iso
devuanpup-9.7.0-chimaera_4.0.alpha-20210523_amd64.iso
Fatdog64-811.iso
FossaDog-2020-09-07_64-bit-UEFI.iso
fossapup64-9.5.iso
FossaPUP64-ETP_custom-puppy-uefi.iso
FreeDOS13LIVE.ISO
hirsute-desktop-amd64.iso
imppup64-9.6.1.iso
LxPupSc64-21.04+4-T.iso
manjaro-xfce-21.1.2-210904-linux513.iso
MX-21_x64.iso
redorescue-3.0.2.iso
rescuezilla-2.1.2-64bit.groovy.iso
rescatux-0.73.iso
SAVESPEC
ScPup64-21.04+2-T.iso
slacko64-0.0.5.iso
slacko64-8.2.1.iso
slc_64-2020.12.iso
Sparkybonsai_2.0_64_modules.iso
supergrub2-2.04s2-beta2-multiarch-CD.iso
supergrub2-2.04s2-beta2-x86_64_efi-CD.iso
systemrescue-8.00-amd64.iso
ubuntu-21.10-live-server-amd64.iso
ubuntustudio-21.10-dvd-amd64.iso
ventoy-1.0.38-livecd.iso

They boot without issues.

[wizard]

Ventoy, how to put a puppy savefile in another partition

In this example, the Ventoy usb was created with a third partition (during setup by reserving space, then formatting with gparted)
The third partition is sdb3 in this example.

Assuming the Ventoy usb is sdb:
-boot Puppy using Ventoy (example using fossa64 9.5)
-when the puppy boot menu appears, press the "e" key twice (this enters edit mode, key presses may be different for other pups)
-press the space bar and then type: psave=sdb3
-press: enter
-press: b (may not be required)

When you shut down the savefile will be created in sdb3

Each time you boot repeat the editing steps above

This method should work on most modern puppies (haven't tried old pups) and can be modified to use any other partition by just changing sdb3 to the desired path.

wizard

[esos]

My previous test: quickpup64_21.08-beta-9.iso is not fully support ventoy exFAT

This is my last finding using external USB-HDD:

DpupBullseye-9.7.0-beta1.iso, imppup64-9.6.1.iso and
quickpup64_21.08-beta-13.iso work fine sofar with ventoy/sg2d.
It can read/write support to ventoy exFAT.
I think to support exFAT, it must be kernel above version 5

[wizard]

After some more testing on putting the savefile on a different partition, it is simpler than I first thought. You just have to tell puppy where you want the savefile to go during the first boot. I revised the "howto" in the post above to reflect that.

wizard

[bigpup]

Ventoy can also boot image files.
I am running EasyOS 3.1.15 on a USB stick, using Ventoy to boot it.

Installed Ventoy to the USB stick.
Reformatted the Ventoy storage partition from exfat to ext3. (I know any Puppy or whatever OS, will support ext3 format)
Placed the EasyOS image file on the storage partition.

Using it to make this post.

[BarryK]

Ventoy can also boot image files.
I am running EasyOS 3.1.15 on a USB stick, using Ventoy to boot it.

Installed Ventoy to the USB stick.
Reformatted the Ventoy storage partition from exfat to ext3. (I know any Puppy or whatever OS, will support ext3 format)
Placed the EasyOS image file on the storage partition.

Using it to make this post.

That's great, thanks for confirming that it works!

[Clarity]

It is NOT required, but I STRONGLY URGE all Ventoy users to keep all of your partition's ISO files in a folder on the partition named BOOTISOS. Its not just for good housekeeping.

Ventoy folder.jpg (5.2 KiB) Viewed 3711 times

[bigpup]

I think to support exFAT, it must be kernel above version 5

Not exactly, the Puppy version has to have the support files in it, that can work with exfat format.
exfat-fuse
exfat-utils

I think kernel version 5.4 -> started having exfat support in it.
Not sure if that eliminates needing support software.

That is why, before putting any Puppy ISO's on the USB.
I reformat the Ventoy exfat partition to ext3.
Any Puppy version can work with ext3 format.

[esos]

Ventoy can also boot image files.
I am running EasyOS 3.1.15 on a USB stick, using Ventoy to boot it.

As I mentioned a while ago:
viewtopic.php?p=26462&hilit=easyos+ventoy#p26462

EasyOS is autosave capable even in ventoy exfat format or whatever linux format, but the problem it is limited autosave amount of memory (I think 64Mb only).
How to overcome the limit?

[Clarity]

Hi @esos As you share, you are booting to desktop but are limited.

This is NOT a Ventoy issue. If you are reaching desktop, this is a EasyOS issue and @BarryK should be alerted for resolution.

[peebee]

Does Ventoy boot any RECENT 32-bit pups?

I have a report that JammyPup32 will not boot under Ventoy.....

[Clarity]

Hi @peebee I only have 1 32bit PC. I, personally, do not boot 32bit OSes on a 64bit PCs...ever.

Scenario
The 32bit PC I have that I for tests is a Netbook.

• I use a Ventoy v1.73 microSD on it for booting.

• On the Ventoy disk it has a /BOOTISOS folder where ALL ISO files are kept

• In the folder I have 10 forum 32bit distros that I have tested from time to time.

• In addition to forum ISO files, I ALSO have the SG2D ISO file within as well just for the troublesome PUPs that Ventoy runs into problems with (this is because SG2D has few/no problems with PUPs while Ventoy sometimes struggles. In this case I merely reboot Ventoy, select SG2D, and choose the PUP from its list. I use SG2D to prove it not a PUP issue in my tests over the past 3 years.

Tests on bare-metal
JammyPUP32 is tested today. In every case of the following tests, when the JammyPUP32 Menu arrives, I ONLY hit enter-key. Thus, no changes to any menu line to initiate Jammy boot. Results:
Ventoy ONLY

• v04.iso is a no-go

• v04+jwm2...iso is also a no-go

Ventoy>SG2D ISO selection

• v04+jwm2...iso is a no-go (odd???)

• v04.iso is a go. Further, as it appears I used JammyPUP32 for testing on this PC several months ago, the distro during boot, finds the prior session-save that is on the system drive in /Sessions folder on its own. (SWELL...same as Slacko32)

Summary
Some issues exist with Ventoy...although sometimes, depending on ventoy releases, ISO boot issues for some distros (not PUPs) disappear.

Hope this is helpful. I will test your 64bit versions again on one of the 64bit PCs. If there is a problem, I will report here.

Any questions or additional tests you want me to perform, post and I will report results.

P.S. I HAVE NOT tested in QEMU: If desired I could, to help. I would expect the same from booting a Ventoy configuration as in the past, I have done so for booting the same Ventoy configuration via BOTH a Ventoy USB with ISO files, as well as, a QEMU disk formatted by Ventoy containing ISO files where each of these tests worked find in the past.

Again, this was bare-metal tests on the 32bit NETBOOK, circa 2008

[Clarity]

Update to booting 32bit ISOs files on an old 32bit Netbook.

@peebee the PUP of yours I tested was JammyPup32-22.04+0,iso.
I just discovered such and have added and tested JammyPup32-22.04+4. It exhibits the very same boot characteristics of the prior report on the netbook.

Today I have tested FF, GG, HH, AND the various Jammy(s) from you. I also tested Arch32Pup-20.05+6.iso and found something of interest. It boots to desktop in Ventoy, BUT SG2D doesn't see it because its missing its loopback.cfg.

If I have a few moments tonight, I will try to manually create to test SG2D booting it. YET, I am sure you may know why it is different from the others from you.

[peebee]

Today I have tested FF, GG, HH, AND the various Jammy(s) from you.

What was the result of these tests please?

Could you please try VoidPup32 ?

Are any error messages appearing to provide clues as to why builds do not boot?

Thanks

p.s you do not have to test 32-bit builds on 32-bit hardware...........

[Clarity]

@peebee Sorry for the delay.

What was the result of these tests please?

Forgive me if the prior post was not too clear: My experience is that they do not boot OOTB on the Ventoy v1.73 msdos USB. My USB stick also has the SG2D ISO in the /BOOTISOS folder along with the various 32bit PUP ISOs.

Selecting SG2D on a boot allows SG2D to launch any of its PUP ISO files. WoofCE PUPs boot without issues.

Could you please try VoidPup32 ?

Today I have tested FF, GG, HH, VoidPup32 AND the various Jammy(s) from you. And like the others if has no problems finding a saved-session.

Are any error messages appearing to provide clues as to why builds do not boot?

Frankly, I made no attempt to debugsve or use GRUB2 to try to capture/debug the process on Ventoy. This is because I have known for years that if Ventoy wont boot the WoofCE PUPs, SG2D will. So any comment about that would be speculation on my part; for example WoofCE PUPs use Grub and syslinux within each PUP; thus I would be guessing if I attribute that being the problem. Many distros, now, only use GRUB2 to be compatible with old and new PCs. (knowledge tells me that this guess is wrong, but ???)

p.s you do not have to test 32-bit builds on 32-bit hardware...........

Yeah, I've known that for centuries. My reason for the test is to use the lowest common denominator for 32bit testing. I never boot any 32bit OS on any of my 64bit PCs...ever, although I have ran QEMU-KVM to test OSes of all sorts from time to time. And, I pulled this old Netbook out of mothball couple months ago in helping someone else with a question.

[LANdpLAN]

where do I get SG2D ISO file?

[bigpup]

From their web site:
https://www.supergrubdisk.org/category/ ... sk-stable/

Just make sure to get the correct one for your computers type bios.