Well thanks for the info, and I've read it but won't have time to reply to it all until a few hours from now, but I definitely will. And I haven't had the chance to boot into the USB and get the results of the commands as you've requested but I'll do that today as well.

No worries.

By the way, run 'lsblk -f' from inside your usual Mint with the USB stick merely plugged in. No need to boot into the live USB(unsuccesfully I might add ;)

Bonus points if you provide the output with your different methods of live USB implementations (ventoy+linux-live-kit iso, zip with no ventoy etc.), to see why UEFI is not working.

If you provide the detailed error message when trying to boot in through the live usb (in BIOS mode I guess), then more bonus points.

Darvond and clarry, here's what's confusing about that: the MBR is the Master BOOT Record, so I assume it has something to do with enabling the drive to boot, right? So if the GPT succeeds that then doesn't it also serve that purpose? And then clarry, you say that the EFI partition is what the UEFI boots, right? So how is that different at all?

rojimboo:

Then why is it that Ventoy gets installed on the second partition of its drive (32 MB all the way at the end), and the first partition is a non-bootable one just for holding ISO files and other stuff (they don't boot directly, anyway)? And btw I'm using Mint, which is Debian, not Arch, but I don't know if that makes a difference.

Well I think I used Live USB Creator or UNetbootin or something like that (I don't remember what I used) for burning the ISO, but I could try that again if you think it might put the stuff on there manually. And I also tried using Ubuntu Imager as an alternative to Live Kit, but that one doesn't work either in Ventoy or on its own. HOWEVER, the interesting thing is that the error I get is exactly the same in both cases, which means that theoretically if it can be fixed then it should work in Ventoy! As for UEFI vs. BIOS, I don't remember for certain but I think that I may have tested it both ways and gotten the same error, and if so then it would actually be fully compatible with both modes, with or without Ventoy! And by the way, it was booting already when it got the error sort of at the last minute just before it finished (it even did a system check and found no errors, and I tried it with and without toram). However, I don't remember exactly what the error was (something vague about failing to load or something), nor do I have any idea how to fix it, so sadly, Ubuntu Imager may not be an option.

I'll look that up after this post and then get back to you, but I might try that Suse ImageWriter (or does it only work on the Suse OS?).

If I understand you correctly, then I could have told you that - which is to say that if I look at the drive on which a live ISO has been burned, it doesn't have the home, media, bin, dev, etc directories, but instead just some stuff that implies that it goes in and extracts all of that from some read-only data files. That seems to always be the case with the live versions.

As for mounting the directory, without direct access to the fstab file I don't see how I would do that (full disclosure though, I don't think I've ever actually modified an fstab file except to disable the swap file).

Well I'll try burning the ISO again and see if I can get that to work, but I've always had better luck using the ZIP file instead.

Yeah, it's something that would be ideal but if it's not compatible then oh well, I guess.

Now here's another idea though, and I'd be interested to hear your thoughts on it: what if I use GParted to make a UEFI partition and a regular partition, and then extract the ZIP file onto the regular partition, and run the script to make it bootable? Would that fix the problem, do you think? And if so then please clarify:

- Do I need to have the UEFI partition first, or should I have the ZIP files partition first so that its script will correctly recognize it as being in the right spot, or does it even matter either way?

- Do I need to put an MBR on it first, or make an extra partition for BIOS also (ideally I want it even to be compatible with computers that don't have UEFI support, and Ventoy boots in both modes so I KNOW it must be possible to do that)? If I need to do any of this, how exactly should it be set up?

I guess that's all the questions I have for the moment. I'll go get the ls results and anything else you requested...

EDIT: Oh by the way, keep in mind that however I do it, it needs to be self-duplicating if it's run in RAM mode, so for example, if I have to burn an ISO file then that's fine, as long as it's possible to supply that same ISO file on the new drive itself, so that it can be burned again the next time, but I don't know if putting it on the drive with all of the files for the live system will interfere with them, or if the ISO will just be ignored.

Ventoy supports UEFI according to its documentation, which means it must create an EFI partition. If you didn't see one, maybe it's not visible to you as it's not mounted and/or Ventoy didn't setup UEFI mode if you were in legacy bios mode or didn't specify GPT flag. Is your Linux Mint and bootup under UEFI?

Knowing the precise error message might be the most important step to troubleshoot...

It's just one live usb creator - any of them should be fine if you have a normal valid ISO. You might even have one with your distro and DE (probably a Gnome one).

Yeah I don't know how to modify the mount points for a live USB, other than let the live USB creator deal with it. Which is why we need a process of elimination and cut back on the custom scripts that don't play nicely with each other and are poorly documented and we don't know what they do precisely.

Just stick with a stock ISO, it's more standard for the live usb creators.

I don't know how the zip file is created, and I have no idea what the script does and how it makes it bootable. That's part of the problem in my opinion, those custom scripts.

I would keep it as simple and vanilla as possible - live usb creator with an iso. If the custom ISO is adamant on having its own setup/partitions/boots, and the lsblk -f doesn't reveal anything after it's simply burned on the USB stick, then mount the iso experimentally with just an iso mount tool and potentially only then manually create partitions for it. But like we noticed already, live usbs don't look like a normal linux installation so we can't apply the same methods to install grub/partitions/mounts/fstab/etc.

Your UEFI will look for the EFI partition at the start of the disk, as the first partition. I'm not sure if this is a hard requirement though.

If CSM is on and in the bios it's set to 'legacy/uefi' instead of just UEFI, there should be a way to have your boot fallback to legacy bios mode if it can't boot in UEFI mode. You should pursue this further if you intend to make your live linux as compatible as possible. But this should be a lower priority than booting into the live linux with UEFI at all.

THat would be nice. Remember bonus points.

I know I've installed Ventoy with GPT before, because I've installed it multiple times in different ways, and I'm pretty sure I did it this time also, but I just can't guarantee that. In any case, I've looked at the drive using GParted and a Disk utility and I don't remember it ever saying anything about partitions other than those 2.

And yes, I regularly use UEFI mode to boot Mint, including the one that I installed to make the ISO and ZIP files.

Ugh... I don't remember, and it takes like 10 or 15 minutes to boot, and then I'd have to write the error on paper since I can't type it in at that time, just so that I can relay it (isn't there an easier way?). I might check it if this way doesn't work, but something tells me that one might even be harder to fix, just because I don't think it's an issue of booting improperly, but rather a file system organizational incompatibility or something. In any case, the only good thing about it is that it runs in BIOS or UEFI, so I don't see why I can't take this other ISO from Live Kit and just tweak it to be compatible in both modes. Isn't that what isohybrid is supposed to do? But I can never get that to work correctly for some reason.

Well I used UNetbootin (which seems to install its own boot loader, btw) to burn the ISO from Live Kit, and it booted fine, but only in CSM mode. In UEFI mode it didn't appear on the boot menu.

Wonderful.

Well that's what I'm leaning toward at the moment, since I don't have many ideas left for the ZIP file, except that my manually partitioning idea may require the ZIP file instead, because the ISO seems to wipe out the whole drive (though I suppose I could just burn it to a partition, but I don't know what the effect of that would be, though when I used UNetbootin I swear I choose /dev/sdb1, rather than /dev/sdb).

Yeah, that's a drag. Like I said I used UNetbooting for the ISO.

Alright, well I think I'm going to try the manual partitioning method. What could it hurt to test it?

Yeah the first priority is UEFI, but I'd like both, so I'll mess with it a bit to see if I can even get UEFI, and then try for CSM also.

Yeah, about that. Well I got the information that you requested, (though I don't see how it's very helpful), but I had to redact a few things, because I don't want the whole internet to have access to private information, but other than that it's all here.



First, here's the information from the lsblk -f for the ZIP extraction:

NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1
│ ntfs Recovery
│ Windows recovery partition (included with computer)
├─sda2
│ vfat EFI partition (/boot/efi) 62.3M 34% /boot/efi
├─sda3
│ Microsoft reserved
├─sda4
│ ntfs Windows partition 1.2T 31% /media/[user name]/[UUID]
├─sda5
│ ext4 Linux test partition (used for testing Live Kit)
└─sda6
ext4 Linux Mint (main HD installation) 43.5G 50% /
sdb
└─sdb1
ext4 Linux Mint
ZIP file extracted live mode 11.7G 12% /media/[user name]/[UUID]
sr0



And this is for the Ventoy drive:

NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1
│ ntfs Recovery
│ Windows recovery partition (included with computer)
├─sda2
│ vfat EFI partition (/boot/efi) 62.3M 34% /boot/efi
├─sda3
│ Microsoft reserved
├─sda4
│ ntfs Windows partition 1.2T 31% /media/[user name]/[UUID]
├─sda5
│ ext4 Linux test partition (used for testing Live Kit)
└─sda6
ext4 Linux Mint (main HD installation) 43.5G 50% /
sdb
├─sdb1
│ ext4 Ventoy drive first partition 5.3G 58% /media/[user name]/[UUID]
└─sdb2
vfat VTOYEFI
Ventoy drive second partition 20M 38% /media/[user name]/[UUID]
sr0



Next I guess I'll also get the one for the new burned ISO.

Look. MBR is legacy. It's the same 512 byte sequence that tells you to replace the floppy disk with a system disk. I'm not sure what's so confusing about that.

What's confusing is that if MBR and GPT are for booting purposes, and a BIOS and EFI/UEFI partition are also for booting purposes, then how is MBR different than a BIOS partition and how is GPT different than an EFI/UEFI partition, in terms of what they do or how they do it? And in any case, why have the extra partitions if you just need the MBR/GPT at the beginning of the drive before the partitions, or why have those if you do have the extra partitions for BIOS/EFI?

Take a pic with your phone I guess, since it's unable to boot. I think it's probably the only way.

And why the hell does a simple live USB linux boot take 10 minutes?? ARe they USB 1? How old is your mobo? There's something wrong there.

I'm confused. You've mentioned before the custom live linux usb couldn't boot in UEFI...?

What does isohybrid do?

It booted into Mint live usb session, or just booted until it failed to load linux?

Well the Ventoy one has an EFI partition and the ZIP one doesn't, so that would make it clear why UEFI didn't work. If it didnt work for Ventoy either then the EFI setup and grub might be wonky.

Let's see what the ISO one shows.

MBR contains some boot code, but not enough to load your OS. More code needs to be stored elsewhere.

GPT contains no boot code, but the UEFI needs to read it in order to figure out where the ESP is.

And then you need to have some place where the bootloader can find your kernel..

clarry, I think that makes sense, but I'm still not sure of the proper way to set it all up exactly, or at least when I try to do it, it doesn't necessarily seem to work.

My phone doesn't have a camera, and I wouldn't own one that does, because I'm private and I hate cameras.

I don't know why it takes so long to boot, but Mint has always taken a long time to boot for me. It seems to freeze for several minutes and then resume like nothing happened. It's USB 3.1, and it also happens when I boot on the HD. And my motherboard is about as old as my computer I guess, which I got in July.

Yes, but what I mean is that when I use the ISO made from Ubuntu Imager instead of Live Kit, it will attempt the whole boot process and fail, regardless of whether I'm running it in CSM or UEFI mode (and I get the same result when using Ventoy), whereas the Live Kit ISO won't even let the USB drive display on the boot menu unless I'm using CSM mode.

It's supposed to be able to modify an ISO file in a few various ways to make it bootable in UEFI, or on a USB drive rather than a CD/DVD, and can specify the partition, etc. But it just never works correctly for me.

No, it actually booted all the way and ran my live ISO just fine, except only in CSM, because in UEFI mode I couldn't get it to appear on the boot menu.

I've yet to find the EFI partition on the Ventoy drive but I'll take your word for it (unless the partition where Ventoy is installed actually is the EFI partition, but it's the second partition all the way at the end).

Alright, I got sidetracked by some other stuff that I had to do, but then I came back and forgot to get the lsblk for you, and then reformatted the drive and partitioned it 3 ways - sorry. But then I burned the ISO onto the third partition and here are the results of that:

NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sdb
├─sdb1 ext4 Linux Mint BIOS boot (bios-grub flag, not sure if this is right)
├─sdb2 vfat UEFI For the UEFI boot, but seems empty 698.6M 0% /media/[user name]/UEFI
└─sdb3 ext4 Mint 11G 13% /media/[user name]/Mint

I followed the instructions at https://forums.linuxmint.com/viewtopic.php?f=42&t=287353 to set up the partitions this way (the post with the heading "UEFI - Hybrid Install"), but I didn't use it for a normal Mint installation the way it says.

However, I stupidly made one mistake - I installed GRUB while booted into Mint on my HD rather than booting into the one on the USB and installing it from there (I think I'm losing my mind). But then when I booted with the USB it appeared on the boot menu even while I'm in UEFI mode! But when I booted it, GRUB only showed the option to boot stuff from the HD; I don't know if that's because I had installed it while booted from the HD, or if it's because it's having trouble finding the third partition on the USB drive, or doesn't consider it to be a valid instance of Linux, or just doesn't want to put it on the list because it's live (with that alternative directory structure and all) rather than actually being installed onto that partition (but then, why would the grub built into the Linux Mint live ISO work?).

But one other thing is troubling to me: even though I'm CERTAIN that I'm in UEFI mode, when it booted it showed signs of using CSM mode (for example, the text was larger, and it doesn't shrink at any point during booting, like it always does when I use UEFI, and the "LM" logo appeared larger and horizontally stretched, as though it were shown at a lower resolution which is a 4x3 ratio, and that's exactly what it does whenever I boot in CSM mode).

I've noticed a bit of a potential catch-22:

It seems that I'm supposed to install the boot loader on the EFI partition so that I can then boot Mint, but in order to properly install GRUB and have everything referenced correctly, I must do it from inside of that particular instance of Mint, so how can I do that if I can't yet boot it in the first place?

Also, would it even work for trying to boot a live copy rather than an installed copy?

You know what - the normal Mint installer ISO can be burned to a USB drive and it has NO problem booting in both UEFI and CSM modes, so why the hell can't my custom ISO do the same thing? I just need to figure out how to configure it the same way!

EDIT: Crap, I didn't realize that would end up on a new page, but I put a big, detailed post just before that, in case anyone didn't see it because it automatically jumps to the last page.

1) Running grub utilities with a priest and a prayer, mostly. This is one of those points where I'd simply give up and go with a more simple solution.
2) What new page? go poke your forum settings and adjust these.

What I got from reading your comments, is that you have some serious issues with your current setup and rig if a 2020 computer takes 10 minutes to boot up Linux. Even on a regular or old HDD compared to an SSD, it's about 7 minutes and an eternity too long at a worst case scenario. I would seriously consider troubleshooting that glaring issue first (I'm not sure how you can live with it and haven't done it already it :). Obviously if your windows bootup/install isn't affected by the horrendous slowness, then it's not your rig, but the Linux install. Which means the custom ISO might inherit some of that, so it's surely worth troubleshooting.

anyhoo, regarding the custom live iso.

Ok so let's try one approach at a time. After reading the linux-live-kit docs, I think it might actually be the best bet.

Approach 1:

1. Use default settings to create the custom ISO and tar file.
2. From the instructions, 'To make bootable USB, unpack the generated TAR archive (also from /tmp) to your USB device and run bootinst.sh from the boot sub-directory' (on the USB of course). I think you would have to have a partition setup already on the USB to unpack the TAR file, so make it whatever bootable ext4 GPT for example, if you need help just ask with this part but any partition tool or guide will help you.
3.I checked the script rudimentarily with my limited abilities, and it seems to set up the boot files in an EFI boot folder, which is great. There's a bit of a question mark regarding the partition though, but let's assume the script handles that part.
4. That should be it. Try booting from it. Remember, try with CSM on and legacy/UEFI option on in bios first, as both UEFI mode will work with those settings still. If UEFI is not visible then, you can try to force it with CSM off and UEFI boot mode in bios settings, but it probably won't make a diffference at that point.

Post any error messages if it didn't work. I can't believe you don't have a camera and a smart phone in 2020. That's...weird.

Approach 2 comes later, and will involve the apparently functioning UNetbootin + ISO combo that at least managed it succesfully, although in legacy bios mode. Here we just ensure a UEFI boot, which I think could be done with a UNetBootin change. Anyways, we'll see later.

Darvond, if I knew of a simpler solution that would accomplish what I need to do, don't you think I'd have tried it by now?

rojimboo, booting isn't that big of a deal, because I usually leave my computer running for days at a time, so that I can check something on the Internet at any moment I feel like it, but it's just that when I'm doing this stuff for setting up my thing, I have to keep rebooting and it's annoying. In any case, I don't know how to speed it up, or if it can be faster, and I have no idea how long it's supposed to take, but I was just telling you how long it's always taken for me (though when I run an ISO created using Live Kit it's actually MUCH faster to boot, but that's the only exception - even Ubuntu Imager makes slowly booting ISO files). In any case, I've had more important issues, like the rest of this stuff, to deal with, and didn't want to be sidetracked with an irrelevant, endless and futile attempt to improve booting speed.

1. I did that.
2. This is the ZIP file method that I was telling you about, and I've done it as you described (extracting and running the script), but as for the partitioning, I'm still working on getting it right and having the EFI partition set up properly so that it can boot correctly.
3. It doesn't seem to affect the partition at all. When I've used the ZIP file method, I had the USB stick set up with one partition filling the drive (except for the first MB), but it was empty. Then I extracted the contents of the ZIP file onto that, and then ran the script - that's it.
4. I've already done this and it boots fine, but only in CSM mode, which is the problem, because the only thing that I really need to do is get it to work in UEFI mode, and then it will do everything that I need. When I disable CSM and try to boot it, I don't get any error, but it simply doesn't appear as an option on the boot menu, like it can't recognize it as a valid bootable partition.

And I don't have a camera because I don't want a camera, much less a device which is essentially a wiretap to bug my home. I have no interest in making anything private become public. What's weird about that?

Well it would be nice to have a bit more details about what "approach 2" entails, since I seem to have already done the things that you suggested before you had suggested them (unless I'm missing something).

Now I'm going to test a few more things to see if I can get it to work with an extra partition...

You're free to do what you want, but I don't think you get my point. A ridiculously slow booting machine is a sign of something very wrong, and it's the opposite of 'irrelevant, endless and futile' to fix it as it is a glaring issue that affects a lot of things. But to each his own ;)

By the way, is the windows bootup/operations as slow?

Previously you mentioned modifying the config file, so I'm not sure.

So it boots up fine with this method in legacy bios mode?

Maybe it needs to have the EFI partition present already and the normal one after it, before running the script and copying the tar. Try creating the partitions manually following a guide, like for example in the Arch wiki. ESP+ext4 partitions for example if you don't need swap.

That means EFI setup/partition is not setup properly. Try manually creating the partitions as mentioned in point 3, before copying the tar and running the script.

By the way, you said you were CERTAIN uefi is enabled for your other boots. How are you confirming UEFI is working?

Whatever floats your boat dude :). I just find it incredibly hard to relate to someone living so backwards that they can't even conveniently show the offending error message when asking people to troubleshoot something for them, haha.

Well seeing as I got conflicting info about this approach 1, I'll wait for your answers to my questions, especially the one about using default settings for linux-live-kit. Then, before abandoning this approach and trying out a new, I think it's worthwhile just to explore how to make it UEFI bootable as that seems to be the only issue remaining (apart from something seriously wrong with your rig haha). But Unetbootin or other live usb creators could help us probably to make an UEFI bootable custom live usb, without the linux-live-usb script.

Oh and finally, what does the custom iso look like mounted? Have you explored it to look for boot config files especially? I found where they are on the Arch ISO for example, and by modifying them people can control the bootup process and partition/drive mounting, but I don't have access to your ISO.

I do have a spare USB key. Might reproduce this and experiment a little with linux-live-usb :)