Actually, the trick with the persistent Ventoy works! I just have to test it now to make sure I can set a secure login (obviously there's not one by default in live mode), and then disable persistence and see if it keeps the changes up to that point but prevents new ones.

I'll also look into TAILS over the next couple of days, though the security isn't so much of an issue, since either way, whatever I use, it will have security in logging in, and also it will be disconnected from any network and lack drivers or anything to enable it to connect, so I don't have to worry about attacks that way.

Well as it turns out, disabling persistence causes it to not only stop saving changes, but also stop reading the file that holds to changes, so that everything reverts to defaults! So I'll need to just disable write permissions on the file, but I can't seem to do that. Here's what I've tried:

- Disabling write permissions directly on the file, which simply doesn't work

- Moving the file to a different drive, disabling them there, and moving it back, which re-enables the permissions!

- Moving, disabling and moving back using cp -p to try to preserve the permissions

- Also with the -a parameter

NONE of these things will let me put the persistence.bat file back onto the drive without it automatically re-enabling write permissions! How can I do it?

EDIT: Now I've done sudo hdparm -r1 /dev/sdb and even that didn't work!

I think your approach is now completely wrong. Why complicate things? Why use a live usb from a burnt installer iso and try to make it persistent with god knows how many workarounds?

If Linux Mint has some kind of bug regarding GRUB and usb installations, then try something else.

If you don't see a UEFI usb boot option at bootup, then you did it wrong and didn't do it in UEFI mode.

I swear, I'm inclined to do this very simple task this weekend and document it for everyone, just to find out whether it can be done.

It's ridiculous how difficult it seems to be!

Best kind of Linux is the one, which gives you least amount of troubles.

Actually, I think I might have just figured it out! I'm going to boot and test it, but I'll tell you the results.

vsr, I agree, believe me!

Alright, here's what I've done:

First of all, I figured out that the reason why I couldn't change the permissions was because I had created the thing using the Windows version of Ventoy (back before I had realized that a Linux version exists), so I just made a new one today using Linux. I did it like this:

sudo sh Ventoy2Disk.sh -I /dev/sdb
umount /dev/sdb1
sudo mkfs -t ext4 /dev/sdb1
sudo e2label /dev/sdb1 ventoy
cp -p [Mint ISO] [USB partition]

So this enabled me to create the Ventoy drive, reformat the manually editable partition into ext4, relabel it "ventoy" (because the label got erased during reformatting and I didn't know if it needs to be called that), and copy the ISO file onto the partition of the USB drive. This all worked fine.

Then after that, I wanted to make it persistent and also have it load the whole ISO into RAM when it boots, so I ran:

sudo sh CreatePersistentImg.sh -s 4096 -t ext4
cp -p /[path]/persistence.bat [dest path/file]

Then I made a folder called "ventoy" on the partition, and a file inside of it which is called "ventoy.json" and contains this:

{
"auto_memdisk": [
"/linuxmint-20-cinnamon-64bit.iso"
],

"persistence" : [
{
"image": "/linuxmint-20-cinnamon-64bit.iso",
"backend": "/persistence.dat",
"autosel": 1
}
]
}

The persistence should work because it's the same way that I did it before, except that I added "autosel": 1, which causes it to choose the persistence option by default, bypassing the choice to be able to run it without persistence. The memdisk seems to work because now it says that it's loading the ISO into RAM just after I choose to boot Mint but while it's still in Ventoy.

When I booted it, at first I noticed that my boot menu only shows the partition that can actually boot it (when I had created it in Windows it showed both partitions, not that the other one needed to be listed, but it's just a notable difference).

Then when it tries to start Mint (using compatibility mode, as I always do for the installer), it starts off fine and normal, but it gets to a point where there's an error line that repeats numerous time and fills the screen:

/init: line 49: can't open /dev/sr0: No medium found

I'm not sure what /dev/sr0 is or why it can't find it. I mean usually I get /dev/sd something and it's a drive. Anyway, after if finally finished displaying that error hundreds or thousands of times, it said:

BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) unable to find a medium containing a live file system

Now if I had to take a wild guess about what all of that means, having no real idea, I'd say that "initramfs" is an abbreviation for "initialize RAM file system" (am I right?) and I guess that would mean that /dev/sr0 refers to some drive being emulated within RAM. So if that's all true then it means that it's having trouble getting the data that it needs to use for that, which means that the problem is being caused by my "auto_memdisk" in the .json file, meaning that memdisk isn't working for some reason. Is that accurate?

Why wouldn't it be working? I was really hoping to use memdisk mode, because the thing is - and correct me if I'm wrong - since I can't seem to enable persistence for loading in already stored data without also enabling persistence for storing new changes, but I think the changes only get made when the computer is told to shut down or restart, then theoretically, if I unplug the USB drive after it's finished booting and have it unplugged when I shut down (or perhaps even just push the button on the computer to shut down or restart, since there's nowhere to save any changes, anyway) then it should be prevented from ever writing any new information after that point, right? So I just thought that it would be best to have it load everything into RAM in the beginning so that the USB drive could be removed.

EDIT: Hmmm, I just read something that said it might work better if I put it into a USB 2.0 port (though I'm afraid that might be terribly slow!) or make the partition less than 4 GB (though Ventoy seems to want it to be the rest of the space other than what it uses for itself, and I'm currently using a 4 GB .bat file), but I'll try it in USB 2.0 and hope for the best.

It means that there's no disk in your computer's optical drive (and the system was trying to mount it).

memdisk emulates BIOS calls to make the computer think that there's a CD-ROM, and it works for the bootloader, but it only works in real mode. Once Linux (the kernel) has booted, it does not use BIOS calls to access the disk, and instead tries to access it directly, which fails due to the disk not actually being there.

In other words, the bootloader can find the (virtual) disk, but the Linux kernel can't. Make any sense?

That sort of makes sense - it's trying to look for something real which is only being emulated. But the thing is that the stick really is in the drive! And this is the way that the memdisk mode in Ventoy is supposed to work according to the instructions on their own website! In any case, you seem to know why it doesn't work, but how do I fix it?

I think I may have mentioned the initramfs mechanism earlier. In a typical Linux distribution, the following happens:
1. Bootloader loads the kernel into RAM, along with an initramfs image (actually a cpio archive).
2. Linux (the kernel) unpacks the initramfs image into a RAM-based filesystem, and executes /init from that filesystem.
3. The initramfs then finds the real root filesystem, mounts it, and switches to that filesystem root, while executing (via execve() or similar) the final init system.

In this case, it's step 3 (out of the ones listed here) that failed. /dev/sr0 is your physical CD-ROM (or other optical) drive, which has nothing in it. The Linux system is not able to access the ISO that was loaded into memory, so it can't use that.

Memdisk, unfortunately, will only work with a Linux distribution that does one of two things:
* One that is aware of said in-memory ISO (which would mean putting a program called memdiskfind in the initramfs, plus the phram kernel module)
* Or one that never does step 3, like Tiny Core Linux or Alpine Linux.

I think your best option is to master your own live image; start with an existing image, customize it to your liking, and "burn" it to a USB device (though you may want to test it in a VM first).

Alright, so I guess that means the memdisk mode is out if I use this whole Ventoy method at all. However, I may still be able to do it - can you verify something? It NEVER writes anything onto the USB drive until I shut down, right? So if I yank the drive before shutting down then no changes should be made, theoretically?

I had considered altering the live ISO before, but I read some instructions on how to do it and it may possibly be way over my head, because remember, I'm still relatively new to Linux, so I didn't really understand a lot of what it was saying and it kind of went on and on about stuff with which I'm unfamiliar.

However, I may ultimately have to resort to that, but first I want to see if I can get the Ventoy method to work, and if not that then I may try TAILS, and if all of that fails then I guess I'll have to somehow figure out how to modify the ISO directly.

EDIT: Or actually, I'll be making the persistence file read-only after I'm done editing it, so theoretically it shouldn't be able to modify it after that, but I'll have to test that when I get to that point.

Well here's a REAL puzzler. I managed to set the persistence.dat file to read-only, and then I booted with that, made a change, restarted and the change persisted anyway! Then I booted back to my hard drive again and checked the file, and it said it was still read-only, and the most recent modification was from this morning before I had set it to read-only! WTF is going on here?!

Also, I had set a secure login password and when I boot, it shows a login screen, but it won't let me type and if I click it automatically logs in! So much for security. I even went into the user accounts and changed the password for the "mint" default account, and changed the place where it says to automatically login as a specified user, to make it not do that (first I tried deleting the name "mint" but it put it back automatically when I reopened the window, so instead I replaced it with "0" and that seemed to stick). Why would that happen?

I think you better start asking these kind of questions here https://forums.linuxmint.com/
They will be fascinated by your problem

e: I see that you already did. Nice.

Yeah but honestly, people here are usually more helpful.

Well now I've tried installing Tails:

https://tails.mirror.metalgamer.eu/tails/stable/tails-amd64-4.12/tails-amd64-4.12.img

I followed these instructions and used the dd method:

https://tails.boum.org/install/expert/usb/index.en.html

At first I wasn't sure that it even installed onto the USB stick, but then I looked in GParted and noticed that there's a hidden partition called Tails (actually it's boot, hidden, legacy_boot, esp).

But neither the boot menu nor the advanced restart from Windows will even show that particular USB stick as an option, so there's no way to boot it.

I've decided that I might take a crack at trying to set up the custom ISO, but the instructions said that I will need to install and use VirtualBox, so I installed it through the Software Manager, and when I ran it, I tried to set up a new virtual machine to test it, but it only gave me the options for various 32-bit operating systems, and nothing 64-bit.

I read more instructions and it said I should install a different version and do things differently, so I uninstalled it through the Software Manager and then downloaded the package directly from the VirtualBox website and installed using their instructions:

sudo dpkg -i virtualbox-6.1_6.1.16-140961~Ubuntu~eoan_amd64.deb

but that said:

Selecting previously unselected package virtualbox-6.1.
dpkg: considering removing virtualbox in favour of virtualbox-6.1 ...
dpkg: yes, will remove virtualbox in favour of virtualbox-6.1
(Reading database ... 328400 files and directories currently installed.)
Preparing to unpack virtualbox-6.1_6.1.16-140961~Ubuntu~eoan_amd64.deb ...
Unpacking virtualbox-6.1 (6.1.16-140961~Ubuntu~eoan) ...
dpkg: dependency problems prevent configuration of virtualbox-6.1:
virtualbox-6.1 depends on python (<< 2.8); however:
Package python is not installed.
virtualbox-6.1 depends on python (>= 2.7); however:
Package python is not installed.
virtualbox-6.1 depends on python:any (>= 2.6.6-7~); however:

dpkg: error processing package virtualbox-6.1 (--install):
dependency problems - leaving unconfigured
Processing triggers for systemd (245.4-4ubuntu3.2) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24+linuxmint1) ...
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for shared-mime-info (1.15-1) ...
Processing triggers for man-db (2.9.1-1) ...
Errors were encountered while processing:
virtualbox-6.1

So there were some errors. I tried sudo rcvboxdrv setup and it said sudo: rcvboxdrv: command not found

Then I tried to install the other one from the Software Manager again, thinking that maybe I'll just use 32-bit ISOs instead, and it said "The package system is broken" with Details:

The following packages have unmet dependencies:

virtualbox-6.1: Depends: libcurl4 (>= 7.16.2) but 7.68.0-1ubuntu2.2 is installed
Depends: libdevmapper1.02.1 (>= 2:1.02.97) but 2:1.02.167-1ubuntu1 is installed
Depends: libgcc1 (>= 1:3.0) but it is not installed
Depends: zlib1g (>= 1:1.1.4) but 1:1.2.11.dfsg-2ubuntu1.2 is installed
Depends: python (< 2.8) but it is a virtual package
Depends: python (>= 2.7) but it is a virtual package
Depends: python:any (>= 2.6.6-7~) but it is a virtual package

So I can't even seem to re-install it through Software Manager until I uninstall the other one that I somehow erroneously installed.

So how can I get it to work, preferably with 64-bit, but at the very least get it to work again with 32-bit?

EDIT: I managed to install VMWare instead, and I watched a tutorial video, which was a slightly different version, but pretty similar. I've managed to create a virtual machine but I can't find any option to actually run the thing!