Testy Tessa

[yogi]

I used to like Linux Mint. It was so eye appealing that I gave it some serious consideration as a contender to replace my old reliable Windows 7 when life support is pulled from that OS. I've used several versions of Mint with its Cinnamon desktop, but the 19.1 distribution was the latest when I started the present adventure with my MSI laptop. The goal was to install Mint 19.1 on the lappie alongside of Windows 10, and whatever other Linux OS's that I could install in the UEFI mode.

By now you must be sick of reading about the difficulties I encountered trying to get any version of Linux installed on a GPT formatted disk in the UEFI mode. The nVidia card in the MSI computer further complicated Linux installations. This seemed a bit odd to me given that I had no conflicts installing Linux in a MBR/BIOS environment on the desktop. I've more or less resolved the lack of native support for nVidia in Linux by adding kernel commands to the GRUB bootloader. Mint, however, was a particularly difficult challenge in that regard and nobody in the Mint tech forums I visited had a solid solution. After much wailing and gnashing of teeth, I conceded that Linux Mint was not intended to run alongside Windows 10 on a UEFI system. Sadly, I abandoned my attempts to multi-boot with Linux Mint as an option.

While I was struggling with Mint and a few others, I ran across a method of installing any OS onto a bootable USB memory stick. This essentially would be a "live" version of the .iso and include persistence should you want to save anything. Persistence works fine but given this type of OS is an image of some known working system, it cannot be updated. There are a couple ways to create this type of USB install, but a Linux snap in called mkusb is the easiest way to do it from inside an existing Linux OS. It's the easiest, but it is not easy. Be that as it may, I found a way to make bootable iso versions of Linux Mint. Not what I was looking for, but there it was.

During one of my pity parties I made an executive decision. Forget Linux Mint! That decision led me to installing Linux Ubuntu, Kali, and mageia alongside of Windows 10. As of this moment the control of the boot process is strictly in the hands of Windows, which means I have to boot into Windows to get to the Grub menu that will allow me to select one of the three Linux installations. That can be changed in theory, but that project is for another time; it's way too complicated for me at the moment.

I loved what I saw in mageia so much that I posted a thread about it in these forums. While mageia is great the real satisfaction is to discover that Windows allows installation of any other UEFI compatible OS as long as you play by their rules. My happiness continued for a few weeks, until today. I ran across the USB Linux Memory stick that would not install on the MSI lappie. So ... I decided to try one more time and hope to become more enlightened. I used mkusb from inside Ubuntu to make a Linux Mint memory stick with persistence. That worked but being the original Mint iso, no nVidia support was included. Gritting my teeth I boogered up Grub a few times until I got the USB Mint to boot. Looked great when it did. It had that shortcut on the desktop to install the OS at the location of my choice. I clicked it and installation began. Unfortunately, since I didn't expect it to get to this point, I had no place to install Mint. All the HDD partitions were taken up. So, I backed out of the install program and formatted another USB stick using mkusb. It has an option to make a clean USB stick, which is what I did. I now had the Linux live disk and a blank USB stick both created within the Linux environment via the program mkusb.

Well, installation went perfectly. That was breathtaking. Since Linux Mint was now on USB, and since I set my BIOS to boot from USB before booting from HDD, I thought I had it made in the shade. I booted from a cold start and the system never even saw the external memory not to mention the GRUB resident on it. After severlal unsuccessful iterations I chose to go with the flow. Booted Windows 10, then restarted using SHIFT+reboot. The expected choices of Ubuntu, Kali, or mageia showed, but no Mint. Because I could not think of anything better to do, I selected Ubuntu on the next boot, and when the GRUB menu appeared I nearly fainted. There was MINT, right at the top where you would expect it in a normal boot situation. I chose that as an option and got no objections about video cards. It just booted into Mint as it should; the exact same Mint iso I could not get to work all these weeks prior. Do you recall the article I posted about how Linux Mint calls itself Ubuntu? Well, I uncovered proof that is exactly what happens. Both Mint and Ubuntu were on the Grub selection menu. The proof of the pudding will be in the next boot when I try to select Ubuntu. What are the odds Mint will come up instead?

So, for the moment I can run Linux Mint from USB memory. First thing I did was open Firefox and it landed on the Linux Mint community page. Lovely green page it is. But wait ... the top announcement is that Mint has now moved up to 19.2 BETA. So, in a couple weeks what I just did will become obsolete.

[Kellemora]

I don't know how or way you are having so much of a problem.
I did get around to installing Linux Mint Maya on the frau's computer and it went without a hitch in EFI mode.
When I boot up the computer, it brings up the normal looking Windows log-in screen, except it show Windows or Linux Mint.
If I click on Windows it brings up the usual options of Administrator, Gary, or Debi to log-in.
If I click on Linux Mint it brings up the log-in window for Linux Mint, gary which I can highlight to select password.
So Windows definitely has control of the UEFI and using their screens. Almost looks like a Wubi install.

The downfall is simply this. From a cold boot up, it takes a long time, like as if Windows is loading before I get the option to select Windows or Mint. If I select Windows, I get the Windows log-in window immediately. But if I select Mint, then it takes a long time once again, probably because it is going through a cold boot to bring up Linux.

I did discover you cannot Shut-Down from LInux, even if you select the Shut-Down option. Linux does Shut-Down, but then Windows boots up back into the Windows or Linux window, slowly.
If I select Log-Off, I'm faced with the Linux Mint log-in screen.
If I'm in Windows and select Turn Off Computer, it turns off the computer as expected.

I will say this, on that new machine that ran as slow as molasses in the dead of winter using Windows 10, running Linux Mint it is almost, but not quite as fast as the Silver Yogi. My test was going into Farm Town to do some harvesting and planting.
In Windows 10, it can take up to ten minutes for a plowed and planted field to catch up and save the project.
In Linux Mint, you can't get more than a couple of seconds ahead of the project. It's ready to save the second you finish plowing and planting. So, there is a really big speed difference between Windows and Linux on this machine.

If you don't play Farm Town, then my explaining blue and red save boxes would be meaningless.
Blue means saving, Red means there are saves ahead and it shows a queue number, in Win10 than number goes as high as 26 saves waiting to save. In Linux, it never gets off the blue, which instantly turns white meaning saved.
It doesn't mean net lag, it means it is waiting for the project process to finish so it can be saved.

On another note: In my stack of old IDE drives, I found some really old FAT IDE drives, too thick to fit in the docking station, hi hi. I used an old ribbon cable and power cord to see what was on them. One has Windows 3.11, the other has Windows 95, which I also have on some smaller normal size IDE drives.
But dig this, neither OS will run on the newer computers, hi hi.
When I tried Win 3.11 the monitor came up but said, Soundblaster 16 not found, CGA monitor not found, then the screen went black. The one with Win 95 did nothing, the screen looked like it was getting ready to boot, then went black also.

I remember on Windows XP I installed some Win 95 programs by using Win 95 compatibility mode.
I did move several WRI files over to my external HD, so I can load them into the Win XP machine and convert them to TXT files. Well actually Win XP will open them and let me save them as RTF which then sticks me with saving as a PDF and I really need them as TXT files to see if what is on them is important or not.
Probably not, because as I got each new computer I moved all the files to the new computer, but I have several, even on this Silver Yogi from the early days that have no programs that can read them. I wonder why I keep all that stuff?

[yogi]

The answer to why we are having different experiences with Linux Mint is that you and I are doing two different things. Plus, the hardware we are doing it on is not similar either. As you would expect, some of the problems I run into are due to me simply not being familiar with the process. I'm not at all comfortable with Linux and only slightly warm and fuzzy about Windows. That's due to me having more current experience with the Microsoft product.

I must say that the situation today is much different than it was when I wrote the opening commentary in this thread. It all looked remarkably well, but as I suggested a second boot proved I'm no further along than I was when I abandoned Mint the last time I touched it. One class of problems I've encountered has to do with booting. I've mastered multi-boot as long as I don't try to mix Linux Mint into the formula. All the bootloaders are indeed under the control of Windows, which is a major change from previous lifetimes when I let GRUB do all the work. UEFI for Windows takes over what Grub used to control and does its own thing with it. It was a major effort coming to that conclusion, but that's the way it is.

When installing Ubuntu, and Linux Mint thinks it is Ubuntu, there is a choice of where to install GRUB. The installer looks at all the partitions and all the disks and lists them out for you to pick one. My first attempts at reconciling UEFI and Linux gave me those choices, but never put GRUB where I designated it should be. It ALWAYS installed GRUB on the Windows UEFI partition. I suppose this makes sense if Windows is taking control of the boot process, but I have yet to see any mention in the Linux installer that GRUB is going to go to the Windows partition whether I like it or not. OK, I give up. WIndows can take control - for now. Conceding that point is what made installing Ubuntu, Kali, and Mageie on the same SDD with Windows possible. The default boot is into Windows unless I press SHIFT+Restart. Doing that will give me a menu from which I can choose where to boot from the next go around. Don't like it, but fine. I'll go along with it for the time being.

Linux Mint for some ungodly reason insists on calling itself UBUNTU on any boot menu except it's own. If you install Mint as a stand alone OS, it says you can pick a version of Mint from which to boot. Multi-boot with Mint and something else, and suddenly Mint >>> Ubuntu. That is a problem for me on the laptop because I already have a version of Ubuntu, the real one, installed there. So, naturally, when the Mint installer asks where do I want to install GRUB, I say on the USB stick along with the OS. Call yourself whatever you want. Just stay out of my SSD with those perfectly working other OS's. The amazing thing that happened last night was that the Mint installer did what I told it to do. It installed GRUB on the USB memory stick along with Mint the OS. What could go wrong with THAT?

Let me tell you.

When I boot the computer from a cold start, and do the SHIFT+restart thing, there is no choice to boot from the USB stick. Thus, I clicked on the Ubuntu box and was surprised to see a GRUB menu with not only Ubuntu 19.04 but also Mint 19.1, and all the other OS''s on the SSD as well. That's when I documented my success in this thread. Today I removed the USB memory stick from the laptop and booted into that Ubuntu but did not get GRUB menus. I did get the GRUB shell, which is totally useless to me. That shell is resident in the laptop and the GRUB I saw yesterday is on the USB stick. If I want to boot into the real Ubuntu now, I have to have the USB stick plugged in because that is where the current GRUB bootloader is resident. Works like a charm in fact. Not at all what I want, but it does work. I can't be happy with it because I will be changing USB sticks in the future to accommodate other OS's I want to play with. I suppose I could simply put a new version of GRUB on each memory stick and hope they all work. But I would much rather have a single GRUB resident on the Windows SDD. Which gave me an idea that seems obvious. Why not tell Linux Mint to install GRUB in the Windows UEFI partition? If it can do it on a memory stick, why not do it on SSD? That is my next major test and I'll report back how that goes.

My previous research on this exact problem uncovered a solution that I cannot fully explain here. Basically it involves editing the fstab config file to tell GRUB two different memory devices are in play; USB and SSD. The Windows datastore also needs editing to stop it from looking for GRUB in all the wrong places. While all this reads perfectly fine in theory, I could end up not being able to boot anything from anywhere. Thus I'm hesitant and am looking for alternatives to modifying actual bootloader scripts.

[yogi]

Understanding how to boot reliably and consistently is one branch of the problem. Admittedly I'm trying to do something very complicated, but there is no reason why it cannot be done. The second branch of the problems I see is related to hardware. You do not use nVidia cards and thus would not see this type of problem. Again, I chose a computer with this specific video card so that to some degree I'm causing my own problems. But, just as is the case with UEFI booting, Linux in every flavor I tried using assures me they will work with nVidia hardware. Some OS's will not. I avoid those if I know about them ahead of time. Anything remotely related to Ubuntu, however, is or shortly will be nVidia compatible. Their drivers are now in the repositories for example.

Linux Mint 19.1 is installed and working as expected in my tower. I did have a virtual machine version too, also with no problems. I uninstalled that simply to make room for something else. And, I have successfully installed Linux Mint on USB memory sticks wherein there were no more than the usual problems. The thing that irks me with Mint (and others) not working in my laptop is the nVidia video card in the lappie is exactly the same as the one in my tower. Only the form factor has changed. And, of course, the tower is MBR while the lappie is GPT.

I discovered a nifty program in Windows, and then something functionally the same in Linux, which will create a bootable USB stick for any iso image. The programs add persistence in the form of a partition called casper. For some reason I have yet to understand these iso's with persistence boot on any computer. Any, meaning GPT or MBR formatted drives. My BIOS on both computers is set to boot from USB before booting from HDD so that all I need to do is plug in these babies and power up. The image is essentially a live disk with memory. I can do most things but cannot update the OS. In order to update, a new USB iso must be created. This isn't what I'm used to and I do miss the security updates, but it's great for recovery in that it always boots. In fact a few recovery CD's and USB's in my collection are exactly this sans persistence.

Having said all the above, if the OS of which I have an image on the USB stick pukes when it sees nVidia, it will not boot. Or, if it does boot it freezes shortly thereafter. Every time I ran into this I was able to get the iso to boot by manipulating the kernel commands in the GRUB menu. It befuddles me when I know what the fix is, but it doesn't work in every instance. Those GRUB scripts are different in almost every case and the fix goes into different lines each time. So it's a lot of trial and error to get these iso's to boot. Once they come up I can then experiment with them and modify GRUB each time I turn it on, or I can use it to install the OS somewhere else. That's what iso's are for in the first place. They are not intended to be persistent. Once the OS is installed, there is typically a recovery mode in the boot menu. That recovery boot can be used to install the missing nVidia drivers and make things work beautifully ever after.

All that works well, except when dealing with Linux Mint. I note that Mint 19.2 is in BETA and I have been tempted to download it to try it out. I may just wait until it is supposedly fully debugged before I see what, if any, improvements have been made. I want to get this all to work just because... . I doubt that I will dump Windows in favor of Mint. If I must do the swap it's looking like Ubuntu is the most reliable bet. That new distro called Mageia is looking good too but I don't have enough experience with it to make it my go-to system. Besides, the nerds on their tech support web site seem to have an attitude. Phooey on them.

[Kellemora]

Sorry you are having so many problems Yogi.
Honestly though, one of the reasons I run straight DEBIAN is because all those others are built on top of Debian.
That tells me Debian is the stable version without the bells and whistles.
In most cases, if I want a feature from Ubuntu or Mint, I can download and install that feature right on Debian and it works, while the same feature may not work in the latest Linux Mint for some reason. Illogical for it not to work, but it don't because Mint changed something it needed.

Here's a good one for you, not that I can use them for anything today.
Back when I got my first commercial grade dot-matrix printer, an Integral Data Systems 9-pin dot-matrix with a Ford Aerospace manufactured engine.
I wrote a few songs using only keyboard characters. The song played by the pins striking the paper when printing. Leave the ribbon out of the printer and the song was much louder.
After we got the Wang VS 300 system with it's large wide carriage printer, I wrote a few songs for it too, mainly to entertain the kids who went on a tour of our greenhouses and offices.
Had I not found that file on one of the old super thick IDE drives, I would have completely forgotten about making dot-matrix printers play music by the pins striking the paper. They were plain text files so I could open them to see they were all gibberish, but the file name reminded me what they were for.
The crazy things we used to do for phun back then, eh!

Also had a file of dot-matrix images made using only keyboard characters. If you held them ten feet away from you, they looked pretty darn good to. Also had a folder filled with BAT files, also probably mostly nonsense things I did.
Look how far we've come since then!
And how much more convoluted it is to get things to work right too, hi hi.

[yogi]

Some of the problems I document here are not as terrible as I might make them sound. Part of it is simply a description of my learning process. People who invented what I'm trying to figure out today think it's all trivial. My only regret is that I don't know who those people are so that I can contact them to explain all this trivial information. For example, you and I both agree "something" was done to Linux Mint to make it so obnoxious outside of it's native environment. If I knew what that "something" was, I might be able to solve some of the problems. And that brings up another point. Even if I do know what the problem is, I may not know how to fix it. So, documenting it all here kind of solidifies it. It may also help somebody who finds these threads by accident. The truth is that it's not difficult to install Linux Mint and have it work flawlessly, if that is done on a stand alone system with generic hardware.

My favorite gripe about Linux is the help system, or lack of it. Let me ask you this, "What is the minimum memory requirement for a typical Linux Mint installation?" If you have an answer to that, you are lying to me. LOL I'm trying to put Mint on a USB memory stick and the thought crossed my mind that maybe the memory on that stick isn't large enough. What IS large enough? I went to the Linux Mint Support Forums and could not get a definitive answer. It depends on ... a dozen factors that a n00bie like myself doesn't care or know about. One of them is the type of desktop. You and I had that discussion a few times. There is an infinite number of possibilities in Linux that you say do not exist in Windows, including a choice of an apparently infinite number of desktops. From what I can gather those choices determine how much space you need to install Linux Mint. My point is that I don't want to have those choices. All I want is Linux Mint on a USB memory stick so I can see how it works. I just completed an upgrade of my Windows 10 Beta. Do you know how many choices I had for installation? Correct if you said one. To be fair I don't know what the minimum disk memory requirement is for Windows 10 Pro. But I DO know where to look to get a straight forward answer.

The answer for Linux Mint is 15GB but could be 20GB, not counting swap space which is another variable that depends on how much RAM you have. Then there is the UEFI partition taking up a small amount of memory, but still part of the total that I cannot determine.

Anyway, there is no change in the status of Linux Mint as of this writing. I've been side tracked with other things today and have not had time to get into it yet. I did manage to get the laptop back to normal booting of Windows and the three versions of Linux all on the same SDD. I'm beginning to think Linux Mint needs a dedicated computer of it's own.

[Kellemora]

Well let's see here Linux Mint 18 will install on a desktop computer with 512 megs of ram and 9 gig HD. Of course they recommend 1 gig ram and 20 gig HD.
I have Linux Mint Maya on a computer with only 512 megs of ram, and a 2 gig swapfile, hi hi. SLOW Running.

Linux Mint 19 needs 1 gig or ram (2 recommended) and 15 gig HD (20 recommended)
Until I got the Silver Yogi, none of my computers had over 2 gigs of ram.
Well, one had 4 gigs, but I took 2 gigs out to build a second matching computer. Never had problems with either.

I'm still using Debian because I couldn't get mint to load on my laptop, but then too, I did happen to have Ubuntu on it.
You are going to love this one. I booted up Ubuntu 8 on the laptop to see if it still worked. Ubuntu likes to check your hard drive every so often for errors. In the boot up process it got into this routine and said, IT HAS BEEN 1777 DAYS SINCE YOUR FILE SYSTEM WAS CHECKED, and started the file check program. Geez, that's almost FIVE YEARS I've been using Debian on that little netbook computer. The reason was, Debian could connect to my WiFi no problem, but Ubuntu could not. Even got a new wifi card to put in it, but never had to put it in because I had already found out Debian worked just fine.

I used to test out several different OSs, so had my HDs all partitioned out to do so. And I"m thinking, perhpas the reason I couldn't load Mint on the netbook was because I already had Ubuntu on it.
But then dig this, I have Ubuntu 8 in one partition and Ubuntu 9 in another partition, and both do boot up OK.
I had this habit of creating a new partition to install a new upgrade to an OS, just in case the new OS gave me problems. I just never got around to removing one of them is all. Glad I didn't too, I found a missing file I needed and never knew where it was. Hiding in Ubuntu 8's desktop folder, hi hi.

[yogi]

Taking a quick inventory, I see three incidents of Linux Mint running as expected. One version is in the ASUS tower on a HDD alongside a couple other distros of Linux. Grub is resident on that hard drive and controlling the boot process for all the OS's therein. It is my current opinion that this configuration is the only one that will work reliably where Linux Mint is concerned.

A second copy of Linux Mint is installed in a virtual machine with only 11GB of memory allocated to it, not including the 1GB of RAM it is sharing with the rest of the computer (i.e., Windows 7). To be honest, after trying to figure out how little memory I can get away with, I am very surprised that Mint works at all in such a small space. My main activity there is to use the browser in a secure environment. The VM essentially is using Windows as a firewall, and that's all I wanted from that OS. Grub must be in there somewhere too, but I never see it. Mint is the only choice in that environment so that the need to see Grub does not exist.

A third copy of Linux Mint (all three are 19.1 BTW) is on a 32GB USB memory stick with persistence. This is a live CD version that has memory capability. I use this stick to attempt installation on other devices, but I can actually plug it into any computer, GPT or MBR, and it boots up fine. I'll qualify that and say that I must first modify the GRUB scrip and add some kernel commands to get it to ignore nVidia. Other than that it's booting fine.

So, it's vividly clear that I can install Linux Mint and have it work to my expectations in multiple environments. My goal was to install Linux Mint on a memory stick that can be used with a GPT formatted disk and UEFI boot. The intention there was to be able to remove the USB memory and replace it with some other OS de jour for experimental purposes. That is exactly what I was doing on my former laptop. That is to say, the laptop with MBR formatting and no EFI boot. The MBR system allows the user (me) to select which physical device to boot from. This is a function in BIOS that is not available when using UEFI. That device boot selection violates all the security built into the EFI process which is why it's not allowed.

I was fooled by the fact that I could install Linux MInt (or anything else) onto a USB memory stick and have it run properly; it runs properly only while the USB memory is plugged in and mounted. Whenever an OS is installed, be it locally or on a removable device, that fact is recorded in the efi boot partition of the GPT SSD. All booting is done from that efi partition regardless of the hardware on which the OS is installed. That means when I installed Mint on the USB memory stick, the efi partition on the SSD recorded its location as the UUID of the USB memory stick. Unplug the stick, and the UUID cannot be located at boot time. In the case of Linux Mint an additional anomaly appeared. Mint calls itself UBUNTU. Because it does that I can no longer boot the actual Ubuntu OS installed on the SSD. It's location is now being identified with the missing UUID created by installing Linux Mint. Fortunately, the other two Linux OS's not identified as Ubuntu boot as expected.

You might be clever enough to say the solution is simple. Copy the GRUB from the USB memory over to the SSD where the Windows efi bootloader has no problem identifying things. That can be done in fact. It's not practical to do, however, because that means the USB memory stick must be permanently installed or there will be a boot error saying GRUB can't find the physical disk referred to in it's store. The solution to that situation is to keep GRUB on the USB memory stick and modify the Windows efi bootloader to do some GRUB chainloading; make one GRUB call up a second GRUB to do the actual boot. All this GRUBing, of course, must be controlled by the Windows bootloader. AND, that errant copy of Mint that calls itself Ubuntu must be renamed. I got a migraine after reading that and stopped the whole project.

I realize the dedicated Linux fans of the world would take exception to my criticisms about Linux being immature at best and grossly convoluted at its free and open source worst. But, really, that is exactly the case here. Why in all hell must Linux Mint call itself UBUNTU??? The derivation tree does have roots in Ubuntu, but Ubuntu has its roots in Debian. So why not call it Debian instead? Better yet, why not just call it MINT??? My answer to that is that the developers of Mint were being nearsighted or just plain stupid. If there is some other explanation I'd love to read about it.

In conclusion I have decided to not modify a perfectly good Windows efi bootloader to accommodate the eccentricities of an errant Linux operating system. I also learned something positive in my adventures. It does not seem possible to accomplish my original mission with my present knowledge. Swapping out USB memory sticks to test out various OS's cannot be done easily (or at all) on a GPT formatted disk with UEFI boot.

[yogi]

The second chapter of the Life and Times of Linux Mint focuses on it's ability to deliver video. In my case it's the inability of Linux Mint to use the nVidia card in all environments. As noted elsewhere, I have Mint installed in the ASUS tower where the nVidia card is exactly the same model as is in the laptop. There is a nouveau.nvidia driver built into the kernel of Linux Mint. I don't know what it's supposed to be driving because in every case I've tried to use it with my GTX960 video card, Mint fails to boot in one way or another. I've discovered a few ways to get around that problem and every one of them involves disabling the nouveau driver supplied by Linux. I gave up on the project I described above because even after applying all the fixes and work-arounds, Linux Mint crashes when booting UEFI. It irks me that I've found nobody willing to corroborate what I now know to be fact. I'll test Mint 19.2 when it sends out it's stable release in a few weeks. I don't hold out a lot of hope for it to have the nVidia problem solved entirely.

The question I have now is in relation to one of the methods used to fix the nvidia problem in Linux Mint. The idea is to disable the nouveau.nvidia native driver and then install the recommended driver from nVidia. It turns out there are two, but that's a side issue. Apparently disabling the driver means adding a kernel instruction to Grub and/or to some file called blacklist-nvidia-nouveau.conf. At first I thought this was a configuration file invented just for nVidia problems, but it's not limited to that. When I looked for the presence of this file I found several "blacklist" files for various things other than nVidia drivers. Have you ever blacklisted anything this way? And, why? My installations seem to work without the blacklisting as far as the MBR formatted disks go. I don't see why the disk format would matter in any way, but as previously noted nVidia drivers cannot be used in Mint that is run on GPT disks.

The latest release of Ubuntu has the problem solved. It uses the 5.x series of the Linux kernel while everybody else seems to be stuck on the 4.x series. Ubuntu went so far as to include a "safe video" option for it's live disk version. Using that mode means I do not have to add any kernel commands to GRUB. The kernel already has the fix built in. Since Mint is build on Ubuntu, I'm expecting big things from its next release. That new Linux kernel looks spiffy, but it's 8 months away from becoming an LTS staple for Ubuntu. Will Mint devs feel free and open to change things enough to work? Only time will tell - and I don't feel like waiting around much longer.

[Kellemora]

How about if I start here, Linux Mint is not a complete OS, it IS Ubuntu with bells and whistles added. This is why it loads with Ubuntu as the EFI manager name.

However, you can change this to LinuxMint.
But you have to first disable Secure Boot in the Bios (this is only a temporary change and will be put back).
Next, in Terminal, you open the EFI Bootloader using (sudo efibootmgr)
Rename ubuntu to linuxmint and make sure the boot number is not changed.
Save and reboot into Bios, change it back to EFI mode, and reboot again.
Now you can install Ubuntu and it should work Ok.

I've not tried this myself, and I know you've already read everything online on how to do it. So obviously it must not be that simple.

On the second message: I too have a problem with an nvidia driver. When my system boots up, it says I must install R600 video driver. If I do that, I get no picture at all because the R600 driver does not contain the driver for my video card.
It's been so long ago, I don't remember how I installed the correct video driver, but I do know I did not have to remake the kernel, I found another option. Seems like there is a place the kernel looks for drivers, similar to the way Windows NT kernel looks outside the kernel. Seems like the new driver got installed in a PPA folder. I still get the error message during boot up, but it ignores it and moves on, after a little bit it does load the correct video driver. I used to check to see which video driver was the one running, and it always showed the right one, so I quit checking eons ago.
What I do remember is you have to select the correct driver for AMD or Intel CPU or it messes up.

[Kellemora]

One question: If a computer has only a VGA video output, using mobo video, and the video section is burned out, is there a way to get video through a USB port, or does that require the onboard video to be working.
I have old video cards, but they are the wrong type of slot, and I hate to buy a video card only to find the rest of the mobo is bad. I can tell it does boot up though.

I was told by several folks that the VGA cord and plug does not have any power source in it, so one should not have burned out the video section by having the VGA cord come out and plugging it back in again, but I'm sure that is what happened. Possible a static discharge burned it out?
Another person said I should try a different monitor, even though I know the monitor is working because it is now used on another computer. I tried that and still nothing.
I know, mobo's are cheap, but trying to swap out the CPU and memory will only deal me more fits. I just don't know how to do that kind of stuff anymore. Seems old cases are no longer good anymore either, since they all come with a power supply which is too small to get a new mobo for, and they never have the power for graphics cards either.
Oh well. Live and learn, and or forget in my olde age too, hi hi.

[yogi]

Thank you for the inputs on resolving the "Ubuntu" naming conflict with Linux Mint. I posted a link to that somewhere in the beginning phases of this project. I don't recall all the steps necessary now, but what you describe sounds reasonable. It's not so easy editing the efi bootloader for starters, and if you screw up nothing will boot ever again. LOL I may have a special case which cannot be resolved given the way UEFI works. The glitch in all of what I'm doing is that USB memory is removable, and I intend to do just that. UEFI can be made to point to the USB stick as the location of Mint, or whatever it wants to call itself. But when I remove that memory card to replace it with another OS, GRUB stops cold. The UUID is unique in each case so that the new USB stick will no longer be recognized by the edited GRUB bootloader.

There is a theoretical solution I've also read about but have not tried. The idea is to keep GRUB on the same media in which the OS in installed. This makes a lot of sense and is exactly what I did when I had an MBR based laptop. Put in a new USB stick and a new GRUB comes with it. The challenge there is to get the Windows UEFI GRUB to chain load into the GRUB on the memory stick. In this situation the UUID doesn't matter because it remains the same inside the UEFI partition resident on the Windows hard drive. Chain loading involves the same kind of file editing as the Ubuntu/Mint problem requires, along with the same risks. Screw it up and you will need to start from scratch because nothing will boot.

Regardless of what scenario is used, the secure boot function is disabled in my system. It's not needed at home and it adds a whole new dimension of complexity to the boot process. I don't need that right now and may never need it in the future. However, I do have a problem trying to reconcile the statement from Microsoft wherein they say all OS's they release going forward from Windows 8 MUST BE GPT and UEFI bootable. That would lead one to believe that Windows 10 cannot be installed on an MBR disk, but that is exactly what was going on with the laptop that died. The only explanation I have for that is that I upgraded from Windows 7 on that laptop, and there were no conflicts with MBR in that version of Windows. So when I upgraded to Windows 10, it didin't know it wasn't supposed to work. I tried to install Windows 10 directly onto an MBR formatted media and it won't allow it.

My understanding of video cards is that the data from the card (or mobo chipset) has it's own bus tied directly to the microprocessor. It's a parallel bus I believe so that trying to duplicate it using USB would not work very well. I don't think it's the PCIE bus either, but it could be. If that's the case then all you need is an adapter or extender for the expansion slot on the motherboard. Giving it further thought, however, HDMI seems to be serial. But your monitor probably is something else anyway.

I hear you loud and clear about Mint being an add-on to Ubuntu. I wish it were that simple, but it's not. Ubuntu has a problem with nVidia in versions prior to their current one. I can fix those. Today I experience what might be the last straw with Linux Mint. One method of installing nVidia drivers into Mint is to download the binary version in the form of a shell script. Then use bash to run the shell and voila. Drivers installed. Sounds easy until you realize that you can't move the driver into the Mint system that won't boot in the first place. I can't get past the login screen no matter what. So then I booted up Ubuntu and tried to move the driver to Mint, which was a royal pain because the permissions were not compatible. Well, I fixed that and finally was able to put the nVidia binary in the home directory of Linux Mint. Then, I had to boot Mint in the recovery mode so that I could call up a terminal session and from there kill off the fricken bogus nVidia driver that the Linux kernel has embedded. Well, it said that driver wasn't installed when I tried to kill it. So I ran the nVidia script and the installation began, but halted shortly thereafter. It said the nouvaeu driver would not change power states so the install shut down. Yeah, the nauvaeu driver I was just told was not installed in this terminal session.

All this works in Ubuntu. I'm fairly certain I cannot accomplish my original mission. The greatest drawback is that UEFI doesn't allow for changing boot media. It wants everything stable and predictable so that it can maintain the integrity of the boot process. I guess that's great as far as safe OS's are concerned. It's just looking as if we lost some functionality when UEFI became the standard.

[Kellemora]

You are getting over my head here Yogi.

From what I understand, you can easily change the boot order on a UEFI computer, just as easily as the old Bios computers.
You can set it to boot from CD/DVD drive first, which is usually the default. From USB second, and from the HD third.

If you couldn't do this, then LIVE CD/DVD's would not work in any UEFI computer, but they work just fine.

I don't see why you couldn't make a LIVE USB stick of any OS, including those that are UEFI and run it in Secure Mode.
The only thing you couldn't do is save to the USB stick UNLESS you set up the USB stick to stand-alone. I think you called this with Persistence.
To the computer, it really wouldn't know if you were accessing a HD or a USB stick, if the USB stick was entirely self-contained.

I've not asked the kids who use the computers up at the library exactly what they are doing, but all the computers at our local branch are Windows10 computers. Yet I see kids up there using various Linux Distro's all the time. They do whatever it is they are doing, and they don't have to save their work to the USB stick as a separate operation, because they are running the OS on the USB stick, and the program they are using is saving to their own programs data files.

Heck, the way things look to me, an 8 or 10 year old kid knows more about computers than us old geezers can even understand, hi hi.

Back to the Library. I've seen things I don't understand at all. Kids with Schmartz-Fonz connected to the Libraries computers, using the monitor and keyboard, but the display is from their Schmartz-Fonz.
Seems to me the Library would have some type of security system to make sure they are not getting hacked with what all these kids do up there.
I do know you cannot install anything on their computers. If you don't like the EDGE Web browser you are SOL. But I see a lot of kids using Google Chrome, complete with all their bookmarks, and I know Google Chrome is not on those computers, much less with all their bookmarks present. So they have to be running from a USB stick.
As I said, way over my head!

[yogi]

I'm doing some complicated stuff that you may never have attempted, but I can't believe its over your head or beyond your ability to understand. I know about your memory issues and I think that comes into play, but all I'm doing is telling you what I'm up to with the hope it will be of interest. If it's also of some benefit, that's even better. And, you may find this hard to believe, but I learn things from your experiences too. What better way is there to learn of your experiences than to tell you about mine?

You described something very common to us old time hackers, but maybe not so familiar to the everyday computer user. The boot order for devices connected to your computer is something set up in BIOS. This search for bootable devices in a specific order takes place prior to loading the operating system of choice. The boot order is not what I'm having difficulties setting up. The issues I've been describing in this thread occur after the device to boot from has been selected.

In my case, and in most computers, the hard drive (HDD or SSD) is where the operating system of choice is located. That choice system has its own boot scheme, and it's there where I am stuck. Multi-boot off that default HDD is a no-brainer. The reason for that is a special partition just for efi boot is located on the default drive. That partition controls the whole show regardless what is attached to the computer. It is this absolute control via the efi partition that makes the system secure. Nothing else is allowed to control the boot method. Secure boot simply adds a password that ties the operating system to the hardware. If whatever you put in there doesn't have that password, it's shut down and not allowed to boot. I'm sure you can see how this is a good way to keep out hackers. Adding that password to make it a "secure" efi boot is optional. Microsoft does it but it can be disabled. Not all Linux systems can do it, which is why secure boot is an option. In order to get Linux to secure boot, there is a process you must go through to generate that secret password that gets burned into the efi partition. Given all the problems booting Linux in the first place, I choose not to enable the secure boot.

In the multi-boot scenario it is typical for the additional operating systems to be installed onto the same HDD/SDD as is the controlling OS. All the boot instructions, that which used to be in the MBR of old BIOS, is now stored in this efi boot partition. Thus, when a Linux OS is installed along side of Windows, the GRUB portion of it is in that efi partition that Windows controls. This was peachy for Windows, but Linux is, as you would say, more flexible with many choices for the location of GRUB. A stand alone Linux OS can have that GRUB in any number of places. It can even be on a network drive in some other city. LOL While that is nice for Linux, Windows wants a copy in it's own efi partition. That is why we are told Windows must be the first OS installed on a disk at the lowest level; /dev/sda is the typical device designation in Linux language. Being in that first spot gives it control of the entire process. The default Windows bootloader hands off boot control to GRUB and from that point forward it's what we all know and love.

The above is pretty well developed, documented, and in standard use. Not many people go beyond installing Windows and Linux on the same hard drive. The efi partition is there and all goes well. My efforts are focused at booting from a removable device; a USB memory stick. It's pretty much the same as the standard boot routine in that the GRUB script is stored in the efi partition of the controlling OS - Windows 10 in my case. It's complicated, but well organized, that is until you think about how all this is accomplished. Each device has a UUID; my Linux USB memory stick has one. That UUID is burned into the GRUB that is located in the efi partition. Makes sense, eh? So, what happens if the memory stick is removed, as I am wont to do? The USB device with its UUID suddenly goes missing and the efi bootloader (Windows or Linux, doesn't matter) can no longer find the device.

A missing device will cause a fatal error. That means if I put a second USB memory stick with a different UUID into that slot, GRUB generates a fatal error. The trick is to get the controlling bootloader to pass that control onto the external memory device. If that can be accomplished, and I'm sure it can, somehow, then the GRUB resident on the USB stick will take over the boot process and there will be happy campers everywhere. Again, I've not delved into it, but the way to accomplish this passing of control is via a process called chainloading. In other words, one bootloader chains to another and passes control to it. As far as I know the way this is done is to manually edit the Windows efi boot script on the master HDD so that it permanently points to the USB port with the next GRUB (bootloader) on it. Apparently chainloading overcomes the fact that the UUID of the device on that USB port keeps changing.

You told me something a while back that I've been thinking seriously about doing. You described how somebody is doing what I want to do by taking the master control away from Windows and using GRUB as the controlling bootloader in the efi partition. I don't know how to do it, but I would guess wiping the disk clean is a start. Then partition it for efi boot and install, say, Linux Ubuntu, first - before windows. In that case the computer will think Linux Grub is the master of all booting. Then, when Windows is installed, with it's own bootloader, it is called up from GRUB and not the Windows bootloader. That's the theory, but I'm not sure how Windows feels about it. They like to be the masters of the universe, you know?

So, how can some 12 year old in the library possibly know all this? LOL I can assure you that they don't. Just ask one to explain what is going on and he will give you the typical blonde headed woman version of how to use computers. To that kid, it just works if you do it a certain way. Ask him/her to set up your home computer to do it and you will see a blank stare. Now, some kids are pretty damned smart. I'm sure a few know how to do this without blinking an eyelash. But that's not true for the bulk of the crowd you are eyeballing in the library. It would be nice to know what is really going on there and how they are accomplishing it. I have seen references to the fact that some people are able to plug in any Linux OS to their Windows machine and run like a rabbit. I've not see any of them explain how they do it.

[yogi]

I think you know about iso images. These files are typically burned onto a CD/DVD or USB memory stick for the purpose of installing that image onto some computer. Because they are an image of a working OS, you can run the software therein if you make the storage media bootable. A bootable image thus becomes a "live" CD/DVD which can be used to evaluate the operating system. I'm sure between us, we did that at least a million times. LOL

The disadvantage of a live CD is that it cannot save files. Anything you store to it is actually put into RAM. Thus, when you shut down the live CD, all your stored data is gone. That's a good thing. This is supposed to be a known good image of a working system. We don't want to modify it with extraneous files, usually. What if you want to keep this OS for personal use but not install it on your computer? The way to do that is to simply put the image on USB memory and add a directory called casper-rw. That is a partition used to save data generated on a live CD. So, now, when you use your browser, you can save the bookmarks to the casper-rw partition, for example. Doing that is called persistence. The disadvantage is that you cannot update the OS. It's still a static image not to be modified. But, you can create data and store it in the persistent partition. Also good is the fact that this being an install disk, it will boot on almost any computer that knows what is a USB memory stick.

My clever phone (called smartphone by many) is in reality a computer of the variety we are all familiar with. The only new part is that it can make phone calls too. Well, I can do that on WIndows 7, so maybe it's not such an innovation. My clever phone is run under the Android OS and as such can do whatever Androids are wont to do. You can even go so far as to install a terminal emulator and "root" your clever phone. I think at THAT point I might call it a smartphone. LOL Also, you can do rpc - remote procedure calls. To us real computer users the term would be called remote desktop. I have an AirDroid app on my phone, and desktop, which allows rpc. This gives me the ability to transfer pictures, for example, directly from the phone to my NAS where I store such things. It's not telnet nor ftp in that I can actually take control of the phone from my Windows 7 desktop. The camera on the phone is at my disposal, for instance. I can send text messages composed on my desktop using the messaging system on the phone. It seems fascinating from a distance, but if you ever did rpc, or remote desktop, it's old hat.

[Kellemora]

I don't know if this will help or not Yogi.
I stopped by the Library on the way home from my doctors appointment.
I talked to the first kid there using Linux Mint 14 from a USB stick.
He said it is real simple.
He just reboots the Libraries Windows10 computer and holds down the SHIFT KEY while it boots up.
A window pops up and he selects USE DEVICE OPTION, then selects USB EFT Drive.
He didn't know how to make a USB stick since he bought his ready to use.

I waited around for about 15 minutes and an fellow in his 30's came in.
I saw him reboot the library computer and holding down the shift key, so watched.
He had Ubuntu come up. So before he got started doing what he came to do. I pestered him, hi hi.
He pulled three different USB sticks out of his bag, and said he has Ubuntu, Linux Mint, and Puppy Linux all on USB sticks.
I asked if he could save to them, and he said yes, no problem.
So I asked how he made them, as I have a friend having a whale of a time doing so.

He said he used the Libraries Windows10 computer to make them, and since they don't let you take the computer apart to unplug the HD, he had to find another way, and he did.
You need to download the ISO of the OS you want to install on a USB stick, then move it from your download folder to the desktop or onto an empty USB stick.
Next you need the windows program named "Universal-USB-Installer-1.9.3.2.exe" and save it on a USB stick. That's the version he had on his Tools USB stick.
He didn't know if they make one for Linux to install to a USB stick, but the Windows one installs any Linux LIVE ISO to the USB stick.

He said he copies the ISO file and the EXE installer file to the Library computers desktop first.
Then he puts an empty USB stick into the computer and runs the EXE file.
It gives you a Window to select the location of the ISO, and where you want to install the OS.
You select the Drive Letter the USB stick is in, on the Library computer it is Drive F.
Then you checkmark the box that says PERSISTENCE, and then move the SLIDER under it to the amount of space you want to use as a Data Partition. He select the most it will let him select.
Then hit OK, and wait for the Live ISO to Install the OS on the USB Stick.

So, I finally managed to hit someone who knew something. I hope it works for you.
If not, according the first kid, you can buy a USB stick with Linux Mint Live you can save to for under 20 bucks.

[yogi]

Been there. Done that. x1000. I can do it with my eyes closed now. LOL

First of all I want to thank you for the effort you made to help me out. It's pretty much as I predicted. The 12 year old kids look smart, but they don't know what they are doing. Fortunately, you found a fellow who not only knew what to do but was willing and able to explain it. Believe me, that's a rare combination. Plus, you, a third party to this dilemma are carrying the message out of the goodness of your heart. I sincerely appreciate what you did.

I know you understand the process because you were able to explain it to me. I have a few methods of installing a bootable iso onto a USB memory stick. Some are Windows programs and some are Linux. It can be done from either platform. The best of the bunch is a Windows program called BelenaEtcher. It's as simple to use as what you describe, and damn near foolproof. So, you see, I have no problem putting any OS onto a memory stick, making it bootable, and adding persistence. In fact, it is THAT type of USB stick I use to install all the Linux OS's. I was using DVD's, but the reader in the laptop is error prone, so I switched to the etcher program when I want to create something all in a Windows environment. When I want to do the same thing in a Linux environment, I use a little program called mkusb. It does everything you described, but it also has some additional functions, such as wiping a USB stick clean and formatting it FAT. I have the ability to run anything I put on these memory sticks because they are .iso images. Those type of disks will boot from anything; probably even your smartphone. LOL

My efforts are designed to go above and beyond running an .iso image, a.k.a. live CD/DVD. I don't want an image: I want a fully installed operating system that can be updated and modified just like your desktop version. This is not impossible to do. That is exactly what I was doing on my old MBR formatted laptop. The reason why it worked there is because in the old MBR/BIOS firmware there was an option to press a key (F12) and see a menu of devices from which you can boot. The DVD, the Hard Drive, and any USB stick you happen to have plugged in were all listed. I simply would pick one and I'd have a fully operations Linux OS on a memory stick. Persistence was not needed any more than you need it on your workstation.

When it comes to new computers, MBR/BIOS is there only in name. It's all GPT and UEFI. Many will make the firmware look like the old BIOS so that us old farts don't get confused. But since about 7-8 years ago they stopped making computers with true MBR/BIOS boot. It may look like it, but it's not. In my situation that forces me to use UEFI, like it or not. If I did not have Windows running alongside of Linux, I could use the BIOS emulation and get my boot device selection menu back. But, as I have hinted elsewhere, there is no Linux OS I have used which is good enough to take the place of Windows.

So what is MY problem? All Windows 8, and going forward from there, OS's must use UEFI to boot. UEFI requires an efi partition to hold all the boot information. It's no longer part of the OS or MBR. I used to be able to press F12 and get a menu from which device I want to boot, but that is gone. I now must press SHIFT and get Windows' version of a boot device selection menu. OK, it's different, but should do the same thing. Each of my Linux OS's has a spot on the Windows boot menu. No problem, until I decide I want to boot from a random USB stick. The guy you talked to sees a selection in the Windows boot menu called "USB EFT Drive" That is a reference to the USB stick, or anything else you want to plug in externally. I dare that guy to explain how THAT particular selection happens to be there.

I saw it explained a time or two and it involves getting into parts of the Windows system that I'm not comfortable with. There is no program that I know of which will make that "USB EFT Drive" one of the selections. It has to be done manually. If there IS a program that does it, I have yet to see anybody reference it. Universal-USB-Installer, and all the rest of them install iso images onto a USB memory stick. None of them create that elusive general EFI option in the Windows boot menu.


Just to tie all my threads together, and to add to your confusion, I can and have made USB sticks that force Windows to offer something like the "USB EFT Drive" menu selection the guy in the library was describing. When I do that, the UUID of that memory stick is written into the efi boot partition inside the laptop. It's permanent and does not change when I put a new USB stick into the slot, but the UUID on the new USB is not the same - it's "unique" after all. Thus the laptop bootloader can't find the new stick (my dilemma in a nutshell). Apparently the library got around that problem. "How did they do it?" is the $64,000 question.

HINT: The reason why it all works for that guy is because his USB memory stick does not have a full installation of an OS. It has an image, which does not boot the same way as a normal OS. Next time you see him tell him to shut down the computer, plug in his USB memory, and then turn on the computer again without touching it. The USB .iso will boot by itself.

[Kellemora]

Hmm. Looks like I lost my in-depth reply this time.
Normally I can get it back, but for some reason, this time, I can't find it.

[Kellemora]

Basically all I said was the guy is usually there on Tuesdays after he gets off work after lunch. Sometimes he is there on Thursdays, but not always.
I then went on to talk about the computers at the library and how they are in cubbyholes on the desks so you can't get to the backs of them. The USB slots and others are on the front of some computers, or in a box under the computer on others, where the users can get to them.
I also said I think they are now on Fiber Optics. They used to have a T1 connection a while back a few years.
I stop in there to download movies for the frau. On my computers it takes about a half hour, on theirs only about 5 minutes, and I have a Cable Connection that runs downloads between 75 and 100 mbps.
She has four 32gb sticks, formatted Fat32 which is required for our TV to read.
The thing that confuses me about the DVR or the TV using FAT32 is that FAT32 is limited to 4gb.
Yet most of the movie downloads are way over that. 5 to 8gb.
You can set the DVR to continuous record and it will keep recording until the USB Stick is full.
When you open the Menu, like for a movie, it shows several files, so perhaps that's how it's done.
Plus of course the Out-Takes, and other video's are included with a movie.

[yogi]

There are times when I type a long response and lose it all. To be honest I don't know what I do to make it happen. All the text becomes highlighted and hitting the [Enter] key blows it away forever. The browser does not cache the text we type in. You can recover it if you end up on a new page - all that takes is going back in history. But, if you erase something in this text box, it's gone forever. Ticks me off too.

The thing about what I'm trying to do is that I know the theory. I don't know how to implement it. Apparently I'm a rare bird because very little seems to be written about how to install OS's onto a memory stick. There is a lot of information about making bootable .iso disks like the ones your friend in the library has. There is even more about dual booting with Windows; multi-boot not so much. There is even a ton of information about UEFI. But, there is very little about how to make a Windows machine multi-boot from USB.

I'm not sure about how to get around the limits of 32-Bit addressing, but I know I read about it somewhere. LOL I would guess you can download huge files if you put segments of it on different partitions. Each partition would be limited to 4 GB in that case. There is also the possibility of compression. I never got into TV recording so that I don't know much about that.