why? just why?

Because reasons.

I'm writing this from Mint, woohoo! I am actually doing some work from this same PC as well, just waiting my colleague to call me so we can continue.

A better question would be: why not? Distro-wars are a bit like console wars, except lamer because Linux distros don't normally cost anything.

Congrats. I think.
get stuff done vs raise the world's entropy is the real q here.
but hey-ho.

Ugh! I switched from UEFI mode to BIOS mode so that I cold install without corrupting GRUB, though somehow it got corrupted anyway! But I fixed that (I think), so that's the least of my worries.

However, for some reason it took like 4 hours just to install Linux Mint 20 onto a USB stick, and once I did it, it ran EXTREMELY slowly and I couldn't access the hard drive or any other USB drives, which means that I couldn't see my notes for what other things I had to do to configure it, and I couldn't get my WiFi adapter driver installed so that I could access the internet! There were a lot of other related problems, but the gist of it is that I couldn't get it to work well at all!

Does anyone know a reliable way to do this, such that I'll be able to continue to boot from the USB stick afterwords, without messing up my ability to boot from HD also? Ideally, I'd like it to be able to boot in a computer whether it's in BIOS or UEFI mode, and it NEEDS to be able to boot regardless of what other operating systems may or may not be installed, or boot loaders for that matter (even if there are none on the HD!).

This is one of the most important things in the world to me, so I absolutely MUST get it to work, but have had unbelievably terrible luck so far!

For the speed, is the USB device using the same data rate as the USB port? If the device is much older than the port, or vice versa, you'll probably have worse performance since it would be operating in some compatibility mode. As for the access-the-harddrive issue, were there any signs that hardware wasn't being detected properly in "dmesg"? Was there an "lsblk -f" command available to list all the detected disk devices and their partitions?

The USB stick that I was using is new and I just got it from the store, and the computer is only a couple of months old.

I didn't check dmesg or lsblk or really anything else, because I didn't have my notes with me or any way to access them, so I couldn't remember most of the commands.

EDIT: And also, even if something about the USB drive slowed down the installation somehow, that wouldn't explain why the OS itself was running slowly, right? I mean, even for doing almost anything, whether it involved accessing a drive or not.

I don't know how you got the idea that switching from UEFI to legacy mode makes any difference with respect to your ability to corrupt GRUB. GRUB is just data on disk, you can corrupt it no matter what if you can write on that disk. Yeah some USB sticks are horrendously slow. They're usually optimized for large files, whereas an operating system will have thousands and thousands of small files + metadata. Updating small files can be an order of magnitude slower than copying a big file. Can you describe the failure? Drives failed to probe? Drives failed to mount? I/O errors? What, why couldn't you? Install your bootloader on the USB stick, not on the HD. Ok I haven't tried it personally but I think you can support both: legacy mode starts off from MBR, and finds the next stage often in the empty space between MBR and the first partition, then loads the full shit from the first partition. UEFI looks for \EFI\boot\bootx64.efi on the (usually FAT32) ESP. So I don't see why you couldn't have bootloaders installed supporting both modes. Just partition appropriately and install a bootloader for each mode. It is entirely up to the computer's firmware. Virtually all PCs today should support booting from USB though.
Graphics mode? What drivers were you running? Legacy vesafb can be pretty effin slow. UEFI framebuffer is usually much more usable, in my experience.

Did your Mint 20 install on a USB stick include a swap partition, because putting Swap partitions on usb media is a really bad idea.

morrowslant, no, I don't use swap at all, either in partitions or in files (I disabled the swap file immediately after I booted, but that didn't fix anything in terms of speed)



clarry, as always, you've provided very good advice, but unfortunately in this case, it's mostly stuff that I already knew and did correctly (though you did have a couple of good new ideas an information to consider), but I'll go over the specifics, because it's very important to me that I not miss anything! So I'll address each of your questions/statements in the order that you said them:

The reason why I thought that switching from UEFI to BIOS would prevent the problem is because of something that I read on the Linux Mint forum, posted by someone who has provided detailed tutorials and seems to know what he's talking about:

https://forums.linuxmint.com/viewtopic.php?f=42&t=287353&p=1590470#p1590470

Note that in the second paragraph of his first post he says, "No one strategy is appropriate for everyone. A crucial issue is whether the host machine (the one from which the installation will be done) uses UEFI or BIOS (legacy boot, CRM, etc.). This is crucial because there’s a bug in the Ubuntu installer, also used by Mint, which in UEFI will bollix the internal hard drive’s boot loader even if one specifies the new boot loader should be installed only to the USB drive." And that's the effect that it had on me - whenever I install on USB it was messing up my GRUB on my HD, even if I told it to install the GRUB on the USB (the drive itself, not the partition). But then when I turned off UEFI and used BIOS instead I still got the same result!

I didn't realize that USB sticks were optimized for either large or small files! Now I have several questions pertaining to that:

- But wouldn't that depend on the file system that I choose when I format it, or is there another factor? And if so then what is it and how can I adjust it?

- By the way, the drive that I used is exactly the same kind as the one onto which I installed Porteus (which I couldn't get to boot at all), but that one installed MUCH faster, so why would that be?

- Also, the store that sells them (it's a local store that makes their own) also used to make 8 GB ones (this one's 16 GB because evidently they've stopped making the 8 GB ones), but I had previously installed Linux Mint 20 onto one of the 8 GB ones (which I also couldn't get to boot right), and that installed MUCH faster, so why do you suppose that might be?

- And would all of this also account for why it runs extremely slowly once it has already booted?

EDIT: I think I might have figured out why it's so slow. The drives that I get say USB 3.0 whenever that's applicable, but this one doesn't say 3.0, so presumably it's probably 2.0, which is great, because I just got 6 of them.

Onto the next question, the way in which I was unable to access my hard drive or other USB drives was simply that they didn't show up in the list on the left side of a window, as though they didn't exist at all, even though they show up fine now that I'm in the HD Linux. I didn't try using text commands but I guess I figured that if they were recognized then their names wold be listed in the windows as well.

I did install GRUB onto the USB stick (the drive, not the partition), and I've also tried installing it onto the hard drive (when I did it the previous time), and in both cases, it corrupts the GRUB on the hard drive, and ultimately I end up with a USB drive that won't boot, because whenever I try to boot into it, it just boots from the HD GRUB instead, and doesn't recognize the USB Linux Installation. BUT ironically, when the GRUB on the HD is corrupted that's the only time that the USB GRUB will run, which is very fortunate, because I've found that it's the only way that I've ever been able to boot back into the HD Linux to reinstall GRUB on the HD and fix the problem, thereby unfortunately also locking me out from being able to boot from the USB any time after that (by the way, I can't seem to configure my computer in BIOS/UEFI to allow booting from USB, so instead, just go into Windows 10, do an advanced restart, then tell it to boot from the USB, though in doing so, I can always boot from the Linux installer, but never from the installed Linux on USB, unless the HD GRUB is corrupted, like I said, so it's a very weird catch-22!).

Yes, there is a way to support both BIOS and UEFI on a USB Linux installation (supposedly) by partitioning the drive, which is detailed in the link that I pasted near the beginning of this post. It's in the post that mentions "Hybrid Install" in the heading. Please read that, because it's interesting and potentially very useful (if I could get it to work), and also because you'll see exactly what I did. I followed the directions precisely (except that I used GParted to make the partitions while I was running in the HD Linux rather than in live mode just before installation). And it's funny that you should mention empty space, because for some reason, when I was creating the first partition, it wanted to put a single MB of blank space before it by default (which I let it), but the rest of the partitions didn't want any space padding before them - why would that be, and could it have caused a problem?

I know that the computer needs to be able to boot from USB, and that virtually all of them can, but that wasn't really my issue - it's more a matter of being able to boot in BIOS more and UEFI mode because I don't know which each computer will be using.

I don't know if you thought I said "driver" but I said "drive". In any case, I don't think drivers would be causing the slow-down, because if they were then it would affect the HD installation in the same way. Yes, I've had issues with my Nvidia card, but if I insert the "nomodeset xforcevesa" boot parameters then it works fine. I was having a weird resolution limitation of like 1024x768, which is way lower than what i normally use, but that only seems to happen when I use BIOS mode, which I only need for setting up the thing in the first place, so that's not a long-term problem (it might be for other computers that only have BIOS mode, but hey, if there's a limitation then there's a limitation, and in any case, it's certainly not my biggest concern).

OK, I've never used Mint and I didn't know it has a broken installer. GRUB can be installed manually once you get a Linux system up and running. I think you're after a BIOS/GPT setup, with an MBR that has some partition marked bootable. Idk if there's a step-by-step walkthrough, and I'm not really going to look for one, but these are the instructions I'd start with:

[url=https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_(GPT)_specific_instructions]https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_(GPT)_specific_instructions[/url]
https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation
https://wiki.archlinux.org/index.php/GRUB#Intel_BIOS_not_booting_GPT It's the hardware, primarily. The problem is that flash can't just write a byte onto the media. Instead, if I change one byte in a file, the flash will have to erase an entire block (multiple kilobytes, or worse..) and then rewrite all of it, with the new changes included. Erasing also tends to be really slow, especially on flash optimized for density. (Of course, writes are also slow on cheap flash, but they're nowhere near as bad as erases). Of course cheap flash doesn't include much cache to speed this up either.

I suppose a filesystem could be tuned for flash, making sure it uses these multi-kilobyte chunks as the minimum size of allocation. That wastes some space. Unfortunately you'll still need to start erasing, eventually. It's really hard to say, there are so many possibilities. The first one I'd check though is the size. People can correct me if I'm wrong but I got the impression that Mint is pretty large, whereas I'd imagine Porteus is optimized for size, given its intended use. Different chips, possibly. Just because a stick looks the same doesn't mean the hardware inside is the same. If I had such sticks and wanted to understand the difference, I'd first of all do controlled tests by raw writes into the block device (i.e. dd onto /dev/sda or whatever the device is) and try different block sizes starting at 512 bytes, going up to maybe 32k or even 64k. That would give me an idea about what the hardware is capable of when you take filesystem and other things out of the equation. Unlikely. I'd expect disk I/O to be painfully slow, but this shouldn't affect things running from RAM and on the CPU. I suspect you're being slowed down by the vesa framebuffer (that's what you get for graphics if you're not using UEFI and have no other working graphics drivers.. yeah you mentioned xforcevesa). OK, I'm unable to help with the left side of a window because as I don't really use these things.

However disks should show up in dmesg when the kernel probes them. Look for sd (scsi) or hd (ide). If they do not show up, something up the chain is failing. Linux dmesg is rather messy (sigh, why can't they do it like OpenBSD) but you should be able to follow the chain which depends on your hardware. For example (in case of SATA) from pci to ahci to ata to scsi to sd. Let's take a look at the dmesg on my desktop (AMD X370 chipset), I have two sata controllers and two SSDs (cutting some excess fluff):

[ 0.252857] pci 0000:01:00.1: [1022:43b5] type 00 class 0x010601
[ 0.256614] pci 0000:0c:00.2: [1022:7901] type 00 class 0x010601
[ 0.609449] ahci 0000:01:00.1: AHCI 0001.0301 32 slots 8 ports 6 Gbps 0xff impl SATA mode
[ 0.610517] ata1: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780100 irq 42
[ 0.610519] ata2: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780180 irq 42
[ 0.610520] ata3: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780200 irq 42
[ 0.610521] ata4: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780280 irq 42
[ 0.610522] ata5: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780300 irq 42
[ 0.610523] ata6: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780380 irq 42
[ 0.610524] ata7: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780400 irq 42
[ 0.610526] ata8: SATA max UDMA/133 abar m131072@0xfe780000 port 0xfe780480 irq 42
[ 0.610640] ahci 0000:0c:00.2: AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
[ 0.610788] ata9: SATA max UDMA/133 abar m4096@0xfe808000 port 0xfe808100 irq 44

Following the chain I have two drives connected, both on the first controller (on ata2 and ata4):

[ 1.394999] ata2.00: ATA-9: Samsung SSD 850 EVO 250GB, EMT02B6Q, max UDMA/133
[ 1.398973] scsi 1:0:0:0: Direct-Access ATA Samsung SSD 850 2B6Q PQ: 0 ANSI: 5
[ 1.399164] sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[ 1.400512] sda: sda1 sda2 sda3 sda4

[ 2.184637] ata4.00: ATA-11: KINGSTON SUV400S37240G, 0C3J96R9, max UDMA/133
[ 2.185200] scsi 3:0:0:0: Direct-Access ATA KINGSTON SUV400S 96R9 PQ: 0 ANSI: 5
[ 2.185439] sd 3:0:0:0: Attached scsi generic sg1 type 0
[ 2.185455] sd 3:0:0:0: [sdb] 468862128 512-byte logical blocks: (240 GB/224 GiB)
[ 2.185897] sdb: sdb1

So I have found my disks, and I can also tell that the first one has four partitions (sda1-sda4) and the second one has one partition (sdb1). Those are things I see under /dev, for example /dev/sda is the first drive and /dev/sda1 is its first partition. Assuming it is formatted and Linux knows the filesystem, I should be able to just say mount /dev/sda1 /mnt and it will be mounted under /mnt, or there will be some error that gives me a clue about what's going wrong.

What if those dev entries are missing? Then you would need to know a bit about your hardware and follow up the chain in dmesg and see who's the missing link. After that, it's more hardware specific, you need to figure out why the driver isn't probing or attaching (it could be something as simple as a driver missing from the kernel, it could be some kind of error, could be firmware acting up or misconfigured bios (devices disabled?), it could be something that requires an expensive oscilloscope to diagnose!). But knowing which part is the failing link helps one get started looking for a fix.
Ok yeah so I guess you're talking about Mint's broken installer, not GRUB's own installer, right? GRUB's own tools really should do exactly what you tell it to do and not mess with anything else (but of course, as you know, bugs are not unheard of.. just somewhat unlikely in case of GRUB).

By the way -- and I'm sorry if we talked about this already and I forgot or missed it -- but you really should check your computer's (or motherboard's) manual and see if there's a way to select the boot device. Because I've never seen one that doesn't allow it. Not saying there couldn't be such a thing.. also in addition to setting boot order in BIOS or UEFI, many PCs additionally have some alternate key (often something like F12 or F10 or F1 or whatever) that you can press during POST and it'll bring up a boot menu from which you can directly select the boot device, without going through the UEFI jank. This too should be documented in the manual. Ok, so they went the way of the BIOS GPT installation described in my links above. And your problem is still that the Mint installer messes up the bootloader on your HD? Then I'd try to install GRUB manually instead of letting Mint botch it up. Or just unplug the HD for the duration of the installation, there's no way it'll mess with a drive sitting in your desk drawer ;-) There's generally no need for padding between partitions, as long as the partitions are aligned and their size is some multiple of the alignment size (which depends on a lot of things, including the sector size and hardware blocks on a flash drive which I talked about earlier). The first partition is preceded by the MBR, GPT, plus any space that might be reserved for a legacy bootloader, disklabel, or whatever else one might put there. So you can't start the first partition at the very first byte of the HD. Thus the starting offset of the first partition is rounded (aligned) somewhat arbitrarily to 1 megabyte. The alignment could be smaller than that, but it doesn't hurt to sacrifice one MB given the size of current drives. When you're in UEFI mode, you get a different display driver than when you're in BIOS mode. The vesa framebuffer in BIOS mode can be ridiculously slow. UEFI framebuffer isn't guaranteed to be fast either but in my experience it always is much faster than vesa fb.

(WHEW that got a bit long and the forum software really tried its hardest to keep me from posting all this!)

Isn't that what f2fs is for?

Yep. Turns out "multi-kilobyte" is a rather big understatement, apparently the erase blocks go up to multiple megabytes! That would explain f2fs's choice of segment size (2MB), and also helps understand why small files are normally a massive slowdown.

https://lwn.net/Articles/428592/

I once tried running OpenBSD on a tiny USB flash, and while installation after fresh formatting was pretty quick, trying to update it in place was ridiculously slow. As in it took hours and I gave up.

Just like Hard drives and sata SSD's can have roughly the same speed reading or writing large files, when it comes to lots of small files, SSD's are a order of magnitude faster.
High cache pen drives helps but tend to be expensive..

There's a "new" rating system for memory cards to deal with this issue, A1 and A2 rating. Not sure if is aplicable to pen drives.
Older ratings deal with maximum transfer speed but smatphones with apps installed on the card were notoriously slow in some cases. That's why the A1/A2 rating was implemented.
I have a couple of Sandisk A1 rated memory cards and they are quicker to copy small files compared to other cards I have (tbf, the other cards are older). Can even feel the diference using it on raspberry's GUI.

Porteus runs on the RAM (meaning it's way faster to use), is much smaller size and focus on using less resources. I also had issues with Porteus but was quite some time ago.

If your pen drives are "made" by your local shop, the most likely is they buy very cheap chinese drives and print a logo on them. If this is the case they are usually very slow...

Depending on a lot of factors, bigger drives are usually faster.

USB 3.0 (now called 3.1 gen1) connectors are blue (sometimes red) and have more physical pins, 9 vs 4.,and both the pen and the computer need to support 3.0 standard.
USB3 is faster but cheaper drives still suffer from the small files problem,

The fastest device to install a OS is a USB SSD., 2.5" is quite bulky but some m.2 are pocket size, although way more expensive.
A A1 (or better A2) rated memory card with a USB3 card reader is the next best, preferably 64Gb or more.