I've never heard of M1 before, but I just looked it up and it didn't explain much or anything of relevance. Please tell me why would that have a problem with compatibility for Linux?

Well as far as I can tell, they only need to be able to get into the UEFI/BIOS and change a few settings if applicable (such as whether to enable or disable CSM, possibly disable Secure Boot, enable booting from USB, etc.), and those things aren't generally hard to do, but I could provide instructions in a somewhat generic way, which is to say that they need to look for specific kinds of options which tend to be on certain menus but the interface may vary.

The ultimate reason for it is confidential, but suffice it to say that it is the only feasible way to accomplish what I'm trying to do.

Actually, I wouldn't be so sure of that, because I've made amazing progress with it, and it's really like 99% of the way there. In fact, the solution that I have works very well, except my only concern at this point is a possible issue with incompatibility with some hardware, and I'd really like to alleviate any of those potential problems.

What do you mean these forums are dead? Are you referring to my posts specifically or the GOG forums in general? And if so then why would they be dead? GOG is still a popular website, isn't it? To be honest, I only tend to read a few of the topic and they're in my favorites, so I don't really check the main list, so I wouldn't know how many posts there are each day.

Well as I said, I can't tell you all of the specifics, but in abstract terms, I'm trying to make a live configured in a specific way, with specific software on it, such that it is portable and can be used by anyone, and can't be modified or cause wear and tear on the USB stick (hence the live mode). I wouldn't think that was such an unusual thing to do. And I don't think that software for making live ISO files is obscure, is it? I mean, how else would people make customized ones, even to make whole new distributions? Wouldn't that be the easiest way?

As for the reasons why I've had so many problems, glitches and errors always seem to follow me around whenever I'm trying to do anything on a computer, but I don't know if it's just because the software that I'm using is always buggy in some way, or if I'm using it differently than the usual way that it's intended to be used (though I doubt it, because the Linux Live Kit is intended specifically for this purpose!).

Well what's the incredibly easy method of making them work?

First of all, I think you may have accidentally said that backwards, because CSM/Legacy are for using the old BIOS mode, and UEFI is the new mode, so to use that I'd have to turn CSM off, right?

Well I am using UEFI mode when I create the thing, but I'm not sure, why would it matter whether I'm using UEFI or CSM when I create the USB drive? Creating it just involves writing bits to it of the correct values in the correct places, and thus can be done no matter what mode the computer is using. I could even do it on a completely different kind of computer. If I plug the USB stick into my XBox and it can access the data then it could theoretically set it the way I want.

But it doesn't seem to be making an extra partition - isn't putting a GPT where the MBR would be enough to make it bootable in UEFI? I'm not sure how a UEFI partition gives it any extra capabilities. And in any case, here's the problem with that - there are basically two methods that Linux Live Kit provides:

- It can create an ISO which is bootable if I burn it on a CD/DVD (but that's REALLY not the preferred option at all!), but it doesn't seem to work on a USB stick. Though if I wanted to use the ISO I'd just put it on a Ventoy drive so I can multi-boot. My Ventoy drive works fine and seems like it should be very compatible with various hardware, but when I try to use it to boot my custom ISO I always get weird errors, no matter whether I tweak the ISO file using isohybrid.

- It can also create a ZIP file of all the same data which is in the ISO, and I can just extract that onto a blank USB drive (so it won't work in Ventoy, unfortunately) and then run a script on it to make it bootable. However, this drive would then not contain an extra UEFI partition, and I don't even know if that would be compatible, because something tells me that the script just makes it boot directly to the partition on which the files from the ZIP file (including the script itself) are stored. Also, I've had bad luck getting things to boot when I've tried to manually create a UEFI partition (even when PRECISELY following instructions that supposedly other people have been able to use to make it work), or otherwise it ends up making things run unbearably slowly for some reason.

I don't want a Linux install - I just want live mode without even having an installer available, so that it's trapped on the stick. And I'm not sure how the Mint installer is relevant to this. I'm not installing onto the USB stick - I'm just installing onto a test partition on my HD, and then setting it how I want it, and using Live Kit to create an ISO from that.

I'm really not comfortable modifying the script. I have no idea what it's doing precisely, except that it must be putting an MBR/GPT on the stick to make it bootable. But as I've said, I'm somewhat new to Linux, so I really haven't even had much experience with shell scripts at all.

In any case, I don't see why that would be necessary, because the whole point of Live Kit is to make the thing bootable live on external devices (such as a USB stick), which it is, but not in UEFI mode, or so it seems (though I never read anything that said whether it is or isn't compatible with UEFI - why wouldn't they even specify that?).

So your objectives are to
1. Boot into one Linux distro on a removable media (USB) in either UEFI or BIOS mode
2. Have it Live - i.e. non-persistent so all changes evaporate at shutdown
3. Make it compatible with as many rigs as possible
4. Make it have custom software/apps, i.e. it should be customised.

Did I miss something?

Because the hardware requires drivers to function but, given that it's new, it isn't documented anywhere so it needs to be reverse-engineered. I heard someone was going the crowd-funding route to the tune of $4K/month to get a version of Linux working on it ("nice to use" usable, not "well, technically it boots" usable).

Didn't you notice that the M1 is a custom ARM SoC.
Your Linux stick is for x86 (presumably -64).
Try Goggle (or duckduckgo) for "Linux", "Mac" and "M1" in any order.

IIRC, you've said they were less computer savvy than yourself.
It might not be advisable to have them poking around in BIOS settings, if you don't want to have to help them undo the wrong changes later.

I can't help to think there's a simpler way.
How about a Raspberry Pi Zero instead? They're dead cheap.

rojimboo, yes to all except with a clarification that for 4 I do the customization and then it becomes like 2 and "evaporates". And I can't think of any other specific requirements.

eric5h5, well that's interesting - I'll have to keep an eye on that. But seeing as how this M1 thing is bran new, I don't think it will be an issue yet and hopefully not ever, but I'm not sure.

brouer, well I guess I should clarify that I just need to work work on x86/64, because I don't think anyone's using anything other than that (and I hope not!). Yeah, in general I agree that laymen shouldn't necessarily mess with the BIOS much, but I can instruct them to only change the particular settings that I specify, because changing anything else could have unintended consequences. I don't see how a Raspberry Pi would be easier (and are they cheaper than 16 GB USB sticks?), because I don't think any of these people have ever used one (I've never even used one), and also, I don't think most distributions work on something like that.

True 100% compatibility is an impossible promise. There are simply too many wildcards in chipsets alone to guarantee that.

Ok so you need a customised live linux usb.

Can you walk us through what you did to make that happen? What did you do with Ventoy and Linux live kit, and what that script is to make it bootable and where you got it from?

The error message sounds a lot like a frakked up /etc/fstab and not finding the root partition, as a first guess.

Well for Ventoy, I just installed it onto a USB drive like normal, and it put itself on the second partition (32 MB all the way at the end) and left the first partition (the whole rest of it) blank/empty. Then I formatted that empty one because it was FAT32 and I wanted it EXT4 instead (and that hasn't ever caused me a problem so I doubt it's an issue).

Then I installed the dependencies for Linux Live Kit:

sudo apt-get install aufs-tools
sudo apt-get update && sudo apt-get install squashfs-tools
sudo apt-get install genisoimage
sudo apt-get install mkisofs

Then I placed the folder for Live Kit in /tmp, extracted from a .tar.gz found at:

https://github.com/Tomas-M/linux-live

I went into that folder and edited the config file and changed /vmlinuz to /boot/vmlinuz (because that's the more accurate path and the default one doesn't work - I don't know why they have it set that way), and then ran the build file:

sudo sh build.sh

It then generates several files and folders, including gen_linux_iso.sh and gen_linux_zip.sh, and I ran both of those to create an ISO and ZIP file, respectively. I made a backup of both files.

If I burn the ISO onto a drive directly then it doesn't boot, and if I modify it with isohybrid (I tried making it recognize as the first partition and a couple other simple options like that, but it wouldn't make it UEFI compatible, and had some error like it couldn't find the EFI stuff) then that just makes it worse.

And I put the ISO on the Ventoy drive (you're just supposed to place them there and it does the rest) it will appear on Ventoy's boot list but when I run it, it gives the error as I said before. If I modify the ISO using isohybrid first and then rty to boot it in Ventoy, it still allows me to pick it from the list that Ventoy gives me, but it no longer even gives the boot loader with the yellow screen (created by Live Kit), and instead just shows a black screen with a blinking cursor in the top left, but I can't type anything.

If I extract the ZIP file onto a blank USB drive and then run a script in /linux/boot (I think that's the directory, but in any case, it's whatever script it tells me to run, except that I use the SH file instead of the BAT equivalent that it says to use, because I can't get that one to work and I think it's only for Windows, isn't it?). That script makes the drive bootable, and then it works fine, except that it won't run unless I switch to CSM mode, and it won't boot in Ventoy of course, because it's not an ISO but rather a bunch of files on a USB stick.

Then if I use dd or the Disk tool to try to make an ISO of that, it complains that it's too large when it hits 4.3 GB (I suppose because of a 32-bit address limitation, and because that's the maximum size of a DVD, for which ISO9660 is usually used), but the weird thing is that the ISO file that it gives me and the ZIP file are only like 1.7 GB each (they're the same size, so I guess they're both compressed), so shouldn't the new one that I make of the same files be the same size?

I think there are two conflicting things happening here, due to the two different scripts/utilities (ventoy, linux-live). These are my suspicions at least, others can chime in. It's still confusing as hell :)

Ventoy creates an EFI partition and a custom grub installed on it, to pick ISOs at will. An /etc/fstab points to the / root partition based on the USB drive.

This is after linux-live creates its own /etc/fstab and tries to mount /linux/ on the USB drive to root. But it was overwritten with the ventoy one. Hence the error message and failure. Also, the linux-live script might mess with grub on its own install, hence no UEFI, but I'm not sure what goes wrong here to be honest.

You could just create a new /etc/fstab and mount it correctly yourself, based on your current configuration. Also you could re-create the EFI partition and setup boot to get UEFI. But you shouldn't limit yourself only to UEFI due to incompatibility with legacy BIOS.

anyhoo

Maybe first post some useful info like

lsblk -f

when the USB is plugged in

and the contents of /etc/fstab on the linux-live partition/iso (it might be under /linux/etc/ as well as /etc/fstab, post both just in case).

Also how did you install ventoy? Which flags? Did you make it use a GPT partition?

I'll answer this more fully later this afternoon when I have time to do so, but I read it, and it seems like you might be a bit confused, because keep in mind that there are two different methods that I've tried with Linux Live Kit:

- Installing onto the USB drive to boot it directly (which can use the ZIP file or the ISO file but I've only been able to get it to work with the ZIP file).

- Putting the ISO file on the Ventoy drive, and not installing it at all, but only installing Ventoy.

Some of the things that you said seem to be mixing those two separate methods together, unless I'm misinterpreting you.

EDIT: And frankly, I'm not sure how I can be expected to modify those paths and stuff for an ISO file which isn't even installed, before I even boot into it, because it can't boot in Ventoy, unless you want me to just find out what the paths are on when it's installed directly onto a USB drive, because presumably they'd be the same in Ventoy, and that may verify the problem but it still wouldn't solve it. But is that what you meant?

Now that I get a chance to look at this a bit more, yes if I recall correctly, I installed Ventoy with GPT rather than MBR, and I'll look into the fstab stuff, but I don't know how I can modify that within the ISO which is already created (Linux Live Kit seems to mess with a lot of stuff automatically and I don't know how to prevent it - for example, it changes the boot parameters). And when I install from the ZIP file there's no EFI partition, but I suppose I could make one and see how that works, but it's just that when I've done that in GParted before it hasn't worked very well for me, and ended up making stuff that booted and ran VERY slowly, but then that was installed rather than live, so who knows? This might work! In any case, I have to go now but I should have more time to deal with it tomorrow afternoon.

I thought of something else. First of all, can I have some clarification of the advantage of having an EFI/UEFI partition rather than just a GPT (which would just go in the first MB of the drive rather than the MBR, wouldn't it?). Don't they have the same effect, or what exactly is the difference?

So if I do need a UEFI partition then can I just make it the whole drive and put the other files on with it, or does it need to be a separate partition from the other files? And if so then how does it find them and know to boot them exactly? And then would it matter which order the partitions are on the drive - keeping in mind that I don't know whether the script expects the files to be on the first partition or just uses them wherever they happen to be?

I actually have a method for creating a 3-partition drive (one for BIOS, one for UEFI and one for the rest of the files), but I've never actually been able to get it to boot properly, and when I boot it indirectly through GRUB on the HD, it runs VERY slowly (but in all fairness, I never tried it with anything live before).

In any case, this applies to using the ZIP file and extracting its contents onto the other partition and then running the script. I don't know how I would apply this to Ventoy, and ideally it would be nice to use that, but if I can't then I'd at least like to make a drive with my custom live Mint to be able to run and boot in either BIOS or UEFI.

Basically, Ventoy itself can do that, so I know it's possible, so if I can just set up a drive to boot the same way that Ventoy does, even if Ventoy isn't actually on it, that would be great.

Okay, Hi. Let me clarify something real quick. UEFI≄GPT. BIOS≄MBR.

These are two different areas of very low level code. GPT is GUID Partition Table; it succeeds the Master Boot Record idea by being more versatile and less limited. Think of it more like a baseline choice made when formatting.

MBR and BIOS should only be required on legacy systems. Which at this mark, is anything made before 2010.

The efi system partition is where UEFI looks for a system to boot.

Like others have mentioned, an EFI partition (FAT32, GPT for the drive, and the EFI partition at the beginning of the drive) is mandatory for UEFI to work. Check the Arch wiki under EFI partition/UEFI.

Usually, if not done manually, the live usb creator will do the work. THat's why mixing up ventoy and linux-live-kit might not work out so well - both try to mount drives and create partitions according to their own scripts.

Knowing more about the final USB setup you have (with the lsblk -f, which you never provided) can help me/us to get a better grasp at how the live USB is formatted. For example, my Arch ISO live USB burnt with Suse ImageWriter had an EFI partition created for it automatically, I can see that.

This is only to get UEFI to work. There's still the main issue of booting into Linux Mint. The /etc/fstab configuration might not work out so great after all, as an idea, because I checked my live USB and it does not have the apparent structrure of a linux system burnt onto it - just a bunch scripts/configs/archives. One of those scripts will control how the partitions are mounted - in your case your ISO's /linux/ needs to be mounted as root and in addition the EFI partition to /efi preferably(though it's not crucial).

Again, something the live usb creator would have probably handled. Alternatively, it's baked into the ISO maybe. Somehow :)

Anyways, get back with that info I asked for, and we'll see what's next. I will probably recommend dropping ventoy for now, as it's unnecessary and not as crucial for what you are trying to accomplish, is my understanding.