I discovered the answers to all my questions, or more correctly, I re-discovered them. During the course of this project I collected a lot of information and stashed it into a folder on my desktop. Among my souvenirs is a page from an Ubuntu Wiki entry explaining in great detail how to go about doing exactly what I'm aspiring to do. I am certain that I read this Wiki early on but didn't understand most of it. I promptly forgot about it and moved on to other paths of exploration, which turned out to be a good thing. Those other paths enlightened me to the point that I now understand what is being said in the Wiki.
Here's the link, if you want to be overwhelmed: https://ubuntuforums.org/showthread.php?t=2338836
First of all I want to comment that I can't believe those library street urchins are doing this. As stated earlier they must be doing something else that is a whole lot easier to do. The shop keeper and the smart person you interviewed at the library may know about all this, and they may be doing it. But, it's not obvious from the descriptions you were kind enough to post. I now have a better understanding of the ideas behind both methods. But, alas, they are incomplete as posted.
Also, the Wiki I cite is for Ubuntu. The instructions you compiled use Lubuntu, but claim any distribution will do. There are definite flaws and shortcomings in the Ubuntu procedure, and I can't say with certainty that they apply to any other version of Linux. It seems as if they might.
The #1 problem all along has been that the Ubuntu installer modifies the Windows bootloader. The authority writing the Wiki claims that is done on purpose, but even he can't figure out why. He accepts that flaw and describes what is needed to fix it. There is a well known utility package called boot-repair, and that needs to be loaded into the live OS at installation time. When installation of Ubuntu to USB is complete, the Windows bootloader is broken and needs to be fixed. That's when boot-repair is fired up to do its thing. So, the strategy up to this point is to deliberately break the HDD bootloader with the intent of fixing it after the fact.
Another certainty is that a EFI partition is required on the target USB device. This is where GRUB would go if the Ubuntu installer would put it there. BUT IT DOES NOT. It leaves the EFI partition empty and boogers up the Windows EFI partition instead. That happens because Ubuntu's installer does not recognize the existence of USB memory devices. They assume all installations will be alongside Windows on the HDD. Period. It is the responsibility of the person trying to install Ubuntu to populate that EFI boot partition with GRUB, and not just any generic GRUB. It must be composed with the correct UUID's and device names and grub.cfg files, not to mention editing fstab.cfg along the way. Of course you know how to get all that information, right?
If one is fortunate enough to make it to this point without destroying the entire computer system, a bootable copy of Ubuntu will now be working on a USB memory device. HOWEVER (and there is always a however), this USB is dedicated and not portable. To make a portable version (my goal) one needs to copy a working version of Ubuntu from a HDD over to the USB device. Be careful about ownership. Some things need root and some things need user ownership in order to get the permissions right. Yes, of course, we all know how to do that. And, when GRUB is migrated that too needs to be changed so that it's not pointing to the HDD but pointing to the specific USB memory hardware you are working with. The good news is that if you happen to do it all flawlessly, you will have a fully functional portable USB pendrive that can be updated.
This Wiki is definitive. It describes what must be done in one fashion or another. The author claims it's not so bad once you know what has to be done. Really?
Let Me Count The Ways
Re: Let Me Count The Ways
I wish I could find the one who used partition 3 for root, he explained why he did that on gpt/efi USB sticks.
I'll keep hunting.
We have to take all three pooches to the vet for the shot they need for the groomer.
They forgot that one when we had them in individually for their rabies shots, etc.
Their excuse was, we knew you did not board your dogs, so didn't give them the shot for kennel cough.
I guess they didn't think we had the short hair dogs going to the groomers, hi hi.
We take them in all the time for a bath and flea dip, plus we have our back yard treated by the exterminator.
Even so, we have one dog that always has fleas, but none of the other ones. And she stays inside almost all the time, only goes out long enough to tinkle, so we wonder where and how she always has fleas, hi hi.
I'll keep hunting.
We have to take all three pooches to the vet for the shot they need for the groomer.
They forgot that one when we had them in individually for their rabies shots, etc.
Their excuse was, we knew you did not board your dogs, so didn't give them the shot for kennel cough.
I guess they didn't think we had the short hair dogs going to the groomers, hi hi.
We take them in all the time for a bath and flea dip, plus we have our back yard treated by the exterminator.
Even so, we have one dog that always has fleas, but none of the other ones. And she stays inside almost all the time, only goes out long enough to tinkle, so we wonder where and how she always has fleas, hi hi.
Re: Let Me Count The Ways
Forgot to add, there is a computer service center right near them, and I will stop in and ask them if they know about bootable USB sticks with an Installed OS on them, to see what they say.
Re: Let Me Count The Ways
One of the two methods you researched is similar to what I found in that lengthy article. Basically it's very simple to make a bootable USB that is portable. Start with a working system that is installed somewhere. Then that working system is copied (cloned?) to a partition on the USB stick. That stick must have an EFI partition which is formatted FAT32. That is where the GRUB bootloader goes. When you copy a whole system like that to another device all the UUIDs change so that it is necessary to go into the correct files and change those UUID's. Once that is done the stick is bootable and portable.
The fellow who talked about three USB stick partitions and copies of of OS's to a hard drive was most likely doing all the above. The hard drive simply had a working copy of the ISO image, which would be the same as just copying something already working on your regular computer. His method, of course, assures a clean install. When you copy your own existing system you are also cloning any bugs residing in it.
It's pretty simple finding the current UUID's but, as I found out, one must be very careful when copying things over. Some files need to be owned by root and others cannot. While the concept is simple, implementing it can be done any number of ways. That's where the confusion arises.
When we first moved down here we knew nothing about the local businesses. When the pooch needed grooming we took it to the closest shop, which seemed to have done a pretty good job. However, the dog picked up kennel cough and eventually died from it. She was old and fragile, but still. The vets we had up in Chicago happen to have two offices down here in O'Fallon. They are a franchise but we were very surprised to see them here. One of the good things about that vet is they were able to get all the records from their Chicago location. I thought that was amazing. They are the ones who explained how fleas need to be exterminated by interrupting their reproduction cycle. They nest and have babies in the most convenient places, such as the carpeting under where the dog sleeps. You can spray the dog and everything else in the house, but you got to kill them eggs in order to stop the cycle. The same should be done to the outside environment, but that's harder to control and keep flea free. It's odd how one dog would have the problem and others not. My wife is like that. She attracts all the mosquitoes so that they leave me alone.
The fellow who talked about three USB stick partitions and copies of of OS's to a hard drive was most likely doing all the above. The hard drive simply had a working copy of the ISO image, which would be the same as just copying something already working on your regular computer. His method, of course, assures a clean install. When you copy your own existing system you are also cloning any bugs residing in it.
It's pretty simple finding the current UUID's but, as I found out, one must be very careful when copying things over. Some files need to be owned by root and others cannot. While the concept is simple, implementing it can be done any number of ways. That's where the confusion arises.
When we first moved down here we knew nothing about the local businesses. When the pooch needed grooming we took it to the closest shop, which seemed to have done a pretty good job. However, the dog picked up kennel cough and eventually died from it. She was old and fragile, but still. The vets we had up in Chicago happen to have two offices down here in O'Fallon. They are a franchise but we were very surprised to see them here. One of the good things about that vet is they were able to get all the records from their Chicago location. I thought that was amazing. They are the ones who explained how fleas need to be exterminated by interrupting their reproduction cycle. They nest and have babies in the most convenient places, such as the carpeting under where the dog sleeps. You can spray the dog and everything else in the house, but you got to kill them eggs in order to stop the cycle. The same should be done to the outside environment, but that's harder to control and keep flea free. It's odd how one dog would have the problem and others not. My wife is like that. She attracts all the mosquitoes so that they leave me alone.
Re: Let Me Count The Ways
My dad drank a lot of beer, so he attracted all of the mosquito's so they left everyone else alone, hi hi.
I guess because I smoke, mosquito's never bother me either, hi hi.
I did stop by the computer shop, but the guys there knew nothing about installing an OS on a USB stick, other than Live Distro's. They also mainly deal with Windows Laptops and not much of anything else. They didn't have a single desktop anywhere in the store, new, used, or otherwise. I thought that strange. The last time I was there he had a whole row of used ones for sale.
During lunch I'm going over to the library again, and hopefully the older fellow I talked with a couple of times will be there. Almost everyone said he is there ever Tuesday during his lunch hour, so I'm hoping.
I guess because I smoke, mosquito's never bother me either, hi hi.
I did stop by the computer shop, but the guys there knew nothing about installing an OS on a USB stick, other than Live Distro's. They also mainly deal with Windows Laptops and not much of anything else. They didn't have a single desktop anywhere in the store, new, used, or otherwise. I thought that strange. The last time I was there he had a whole row of used ones for sale.
During lunch I'm going over to the library again, and hopefully the older fellow I talked with a couple of times will be there. Almost everyone said he is there ever Tuesday during his lunch hour, so I'm hoping.
Re: Let Me Count The Ways
I don't recall exactly what it is, probably a Pheromone, but mosquitoes are attracted to that particular aroma. Some folks have more of it than others, and that is what explains the attraction being heavy for certain people. Those insect repellents neutralize whatever it is.
Having an operating system on a USB memory stick would only appeal to somebody obsessed with being pro active about preventing disasters. I spent a lot of time in my career doing just that. If all else fails, having a bootable OS on a stick would be the ultimate recovery tool. Or, as in my case, it provided me with a method of experimenting without doing damage to my working system. It was so freaking easy to do before EFI entered the picture. But, the world is changing rapidly and nothing is easy anymore.
Finding somebody who's interests parallel mine would be a trick and a half. But, there are a lot of Linux gurus out there who should at least know what is involved even if they don't have a need to do it. That last wiki article I linked you to is just such a guy. He goes into great detail explaining what is needed to create a Linux installation on a Windows box. Like the overwhelming majority of articles on the subject, it's aimed at a dedicated installation on a remote memory device. Very few talk about that device being portable. The author of that article devotes one paragraph to the portable concept saying outright that he never did it, but it should work. I like a guy with that kind of confidence, even if his ideas are flawed.
After all the experimenting and reading I've done, I've come to the conclusion that it's not a mysterious process. Simply copy a working system to a USB stick and change GRUB so that it boots. Done. Getting good instructions on how to make those changes is the trick.
Having an operating system on a USB memory stick would only appeal to somebody obsessed with being pro active about preventing disasters. I spent a lot of time in my career doing just that. If all else fails, having a bootable OS on a stick would be the ultimate recovery tool. Or, as in my case, it provided me with a method of experimenting without doing damage to my working system. It was so freaking easy to do before EFI entered the picture. But, the world is changing rapidly and nothing is easy anymore.
Finding somebody who's interests parallel mine would be a trick and a half. But, there are a lot of Linux gurus out there who should at least know what is involved even if they don't have a need to do it. That last wiki article I linked you to is just such a guy. He goes into great detail explaining what is needed to create a Linux installation on a Windows box. Like the overwhelming majority of articles on the subject, it's aimed at a dedicated installation on a remote memory device. Very few talk about that device being portable. The author of that article devotes one paragraph to the portable concept saying outright that he never did it, but it should work. I like a guy with that kind of confidence, even if his ideas are flawed.
After all the experimenting and reading I've done, I've come to the conclusion that it's not a mysterious process. Simply copy a working system to a USB stick and change GRUB so that it boots. Done. Getting good instructions on how to make those changes is the trick.
Re: Let Me Count The Ways
I spent 5 minutes short of 2 hours sitting around the library watching the folks using the computers.
The frau went down to Planet Fitness to use the message chairs and stayed longer than I expected.
Not a single person who came in to use the computers during that time did so with a Linux stick.
They all had sticks to save their work to though, but nobody using Linux.
The guy I was looking for apparently has not been in for a few weeks now.
One man did come in who works for the Library, and I talked to him while he was replacing a scanner used at the checkout. He didn't know much about the computers. "If one is broke, I take it back to the shop to be fixed." He did know a user cannot get into the operating system, everything is locked down so they can't mess them up.
I keep hoping to get a chance to get out to the other computer service center, but it is quite a ways from here and I'm not out that way often since the original owner turned it over to a couple of fellows who promptly moved across the street to a bigger place. At least they know Linux and suggest it to nearly everyone. Even so, almost all of their work is on Windoze computers and a lot of business accounts is what keeps them afloat. The other store closer in relies on the college kids to keep him swamped with laptop repairs.
I do have a question to ask you, which might shed some light on the problem you are having.
There has to be a reason WHY they ALL SAY to create a LIVE OS USB Stick First for it to boot.
When you boot into a Live CD, DVD, or USB Stick, it does not change anything on the host computer, unless you Install the OS onto that computer.
You can boot a LIVE USB stick on nearly any computer, even the new EFI computers.
So, once you have the LIVE OS up and running, why would anything you do, even installing to another partition on that USB stick, have anything to do with the computers own settings, namely the boot sector of the computer?
I guess I'm missing something about how LIVE OS's work, since they are not supposed to change anything on your computer.
The frau went down to Planet Fitness to use the message chairs and stayed longer than I expected.
Not a single person who came in to use the computers during that time did so with a Linux stick.
They all had sticks to save their work to though, but nobody using Linux.
The guy I was looking for apparently has not been in for a few weeks now.
One man did come in who works for the Library, and I talked to him while he was replacing a scanner used at the checkout. He didn't know much about the computers. "If one is broke, I take it back to the shop to be fixed." He did know a user cannot get into the operating system, everything is locked down so they can't mess them up.
I keep hoping to get a chance to get out to the other computer service center, but it is quite a ways from here and I'm not out that way often since the original owner turned it over to a couple of fellows who promptly moved across the street to a bigger place. At least they know Linux and suggest it to nearly everyone. Even so, almost all of their work is on Windoze computers and a lot of business accounts is what keeps them afloat. The other store closer in relies on the college kids to keep him swamped with laptop repairs.
I do have a question to ask you, which might shed some light on the problem you are having.
There has to be a reason WHY they ALL SAY to create a LIVE OS USB Stick First for it to boot.
When you boot into a Live CD, DVD, or USB Stick, it does not change anything on the host computer, unless you Install the OS onto that computer.
You can boot a LIVE USB stick on nearly any computer, even the new EFI computers.
So, once you have the LIVE OS up and running, why would anything you do, even installing to another partition on that USB stick, have anything to do with the computers own settings, namely the boot sector of the computer?
I guess I'm missing something about how LIVE OS's work, since they are not supposed to change anything on your computer.
Re: Let Me Count The Ways
I do not know enough about MBR, EFI, or bootloaders, to be able to give you a definitive answer. If I was THAT smart, I'd not be having the difficulties I'm experiencing. I can tell you what I do know.
First of all what I'm trying to accomplish needs to be understood. I am trying to install a fully functional operating system onto a USB memory stick so that it would be portable. By portable I mean that I want this memory stick with the installed operating system to be able to work on any computer in which I happen to plug it into. That's the goal.
It is possible and easy to do such a thing in a disc environment that boots from a Master Boot Record (MBR). Just about any Linux distro has the capability of being installed to a USB memory stick. That's true because a memory stick is just another possible installation partition as far as its installer is concerned. You get a list of partitions connected to the machine and need to pick one for the installation. There is a standard function in BIOS (the original one) that allows the user to select which device they want to boot from. If your USB stick is plugged into the computer at the time, it will be among the options. After you select which device, BIOS then turns control over to the bootloader which is GRUB in the case of Linux. GRUB, in turn, loads a copy of the kernel which is stored in the /boot directory of every Linux OS.
In the case of EFI booting, the disc must be formatted GPT. That's because the old MBR format is basically DOS, and DOS has reached its limits. A few other things besides disc format changed in EFI. It does not allow selection of a boot device from BIOS as did the old MBR system. instead the EFI partition has a list of known and secure boot devices and hands off booting to GRUB or Windows or anything else you are using. EFI also has a secure boot mode wherein it needs an encrypted key before it will hand off the booting process, but I'm not interested in that. It can all be done without secure boot.
So, if you read the above carefully, and if I explained it correctly, the old way to boot an OS was to allow BIOS to select a boot device by default, or to let the user select a boot device manually. The new EFI way does not allow that manual selection.
EFI is in absolute control of the boot process. Thus, when I add a device to the computer, EFI has to scrutinize it first before it hands off booting. This scrutiny is intimately related to UUID's of the bootable devices on the system. Each partition has a UUID in fact. So, on my laptop with Windows and three versions of Linux installed on the hard drive, there are a ton of partitions and their UUID's for EFI to peruse.
You still with me? LOL
Ubuntu identifies itself to Windows EFI correctly, but it writes a copy of the device's UUID to the WINDOWS EFI partition. According to Ubuntu this is done deliberately because the installer assumes the OS will be on the same hard drive as is Windows. Thus the Windows bootloader is assumed to be the master controller of all boot devices. Unfortunately, my portable USB stick is a special case. It is not a permanent device; that is to say it's not a hard drive or an attached USB drive. It is a memory stick that will be removed and put into some other computer at a later date. Thus, the Windows bootloader needs an instruction (chainload) to force it to pass on booting to the GRUB on the portable USB memory stick. That assumes a GRUB will actually be there. I've learned that Ubuntu doesn't put one there under any circumstance and I must do it manually.
So, what about these "live" CD's and memory sticks? What's going on there? Why do they boot just about anywhere? They do that because they are read-only images and do not violate any EFI security in that regard. EFI knows what an ISO (read-only) device is and gives it a pass. Thus putting a copy of an ISO image on a USB stick allows it to boot anywhere. But, it is read-only. If you can get that ISO to pass the boot to an OS installed on the same USB stick, then you are using the ISO to boot into a fully installed Linux OS. Sounds reasonable, doesn't it? It is unless you are installing Ubuntu, which says it's going to put all its boot information in the master Windows EFI partition and f**k you if you want to do something else.
Well, Dennis, if Ubuntu is so screwed up, why not try some other distribution, such as Lubuntu? This is the OS recommended by the people who are doing what I have yet to accomplish. As documented further up this thread, I installed an ISO of Lubuntu onto a memory stick and used it to install a copy of itself on the same stick but a different partition. The theory is that doing this will replace the GRUB from the ISO with the GRUB from the working version. Good theory, but it didn't pan out that way. The ISO cannot be changed nor can it's GRUB. The second method suggests installing to a hard drive instead of onto the USB stick. Then "clone" the working hard drive version onto the USB stick. Well, that would work if the permissions were right after the cloning, but they weren't. And, even if I did get the clone to be owned by root, what about GRUB? No mention was made of how to force the ISO GRUB to recognize the cloned working system.
Addressing your question: Because a Linux installer program is what it is, it must write to and alter the target device. In addition to copying system files, it also identifies itself (Ubuntu, Lubuntu, Debian ...) and registers the UUID of the target device with the master EFI bootloader. GRUB would normally be written to the target device so that it knows how to boot the kernel. Ubuntu is writing GRUB to the wrong place in my case. Other Linux distros won't boot even if installed side by side with the live ISO image.
There you have it. Everything I understand about the problem. Or, more correctly, everything I do not understand.
First of all what I'm trying to accomplish needs to be understood. I am trying to install a fully functional operating system onto a USB memory stick so that it would be portable. By portable I mean that I want this memory stick with the installed operating system to be able to work on any computer in which I happen to plug it into. That's the goal.
It is possible and easy to do such a thing in a disc environment that boots from a Master Boot Record (MBR). Just about any Linux distro has the capability of being installed to a USB memory stick. That's true because a memory stick is just another possible installation partition as far as its installer is concerned. You get a list of partitions connected to the machine and need to pick one for the installation. There is a standard function in BIOS (the original one) that allows the user to select which device they want to boot from. If your USB stick is plugged into the computer at the time, it will be among the options. After you select which device, BIOS then turns control over to the bootloader which is GRUB in the case of Linux. GRUB, in turn, loads a copy of the kernel which is stored in the /boot directory of every Linux OS.
In the case of EFI booting, the disc must be formatted GPT. That's because the old MBR format is basically DOS, and DOS has reached its limits. A few other things besides disc format changed in EFI. It does not allow selection of a boot device from BIOS as did the old MBR system. instead the EFI partition has a list of known and secure boot devices and hands off booting to GRUB or Windows or anything else you are using. EFI also has a secure boot mode wherein it needs an encrypted key before it will hand off the booting process, but I'm not interested in that. It can all be done without secure boot.
So, if you read the above carefully, and if I explained it correctly, the old way to boot an OS was to allow BIOS to select a boot device by default, or to let the user select a boot device manually. The new EFI way does not allow that manual selection.
EFI is in absolute control of the boot process. Thus, when I add a device to the computer, EFI has to scrutinize it first before it hands off booting. This scrutiny is intimately related to UUID's of the bootable devices on the system. Each partition has a UUID in fact. So, on my laptop with Windows and three versions of Linux installed on the hard drive, there are a ton of partitions and their UUID's for EFI to peruse.
You still with me? LOL
Ubuntu identifies itself to Windows EFI correctly, but it writes a copy of the device's UUID to the WINDOWS EFI partition. According to Ubuntu this is done deliberately because the installer assumes the OS will be on the same hard drive as is Windows. Thus the Windows bootloader is assumed to be the master controller of all boot devices. Unfortunately, my portable USB stick is a special case. It is not a permanent device; that is to say it's not a hard drive or an attached USB drive. It is a memory stick that will be removed and put into some other computer at a later date. Thus, the Windows bootloader needs an instruction (chainload) to force it to pass on booting to the GRUB on the portable USB memory stick. That assumes a GRUB will actually be there. I've learned that Ubuntu doesn't put one there under any circumstance and I must do it manually.
So, what about these "live" CD's and memory sticks? What's going on there? Why do they boot just about anywhere? They do that because they are read-only images and do not violate any EFI security in that regard. EFI knows what an ISO (read-only) device is and gives it a pass. Thus putting a copy of an ISO image on a USB stick allows it to boot anywhere. But, it is read-only. If you can get that ISO to pass the boot to an OS installed on the same USB stick, then you are using the ISO to boot into a fully installed Linux OS. Sounds reasonable, doesn't it? It is unless you are installing Ubuntu, which says it's going to put all its boot information in the master Windows EFI partition and f**k you if you want to do something else.
Well, Dennis, if Ubuntu is so screwed up, why not try some other distribution, such as Lubuntu? This is the OS recommended by the people who are doing what I have yet to accomplish. As documented further up this thread, I installed an ISO of Lubuntu onto a memory stick and used it to install a copy of itself on the same stick but a different partition. The theory is that doing this will replace the GRUB from the ISO with the GRUB from the working version. Good theory, but it didn't pan out that way. The ISO cannot be changed nor can it's GRUB. The second method suggests installing to a hard drive instead of onto the USB stick. Then "clone" the working hard drive version onto the USB stick. Well, that would work if the permissions were right after the cloning, but they weren't. And, even if I did get the clone to be owned by root, what about GRUB? No mention was made of how to force the ISO GRUB to recognize the cloned working system.
Addressing your question: Because a Linux installer program is what it is, it must write to and alter the target device. In addition to copying system files, it also identifies itself (Ubuntu, Lubuntu, Debian ...) and registers the UUID of the target device with the master EFI bootloader. GRUB would normally be written to the target device so that it knows how to boot the kernel. Ubuntu is writing GRUB to the wrong place in my case. Other Linux distros won't boot even if installed side by side with the live ISO image.
There you have it. Everything I understand about the problem. Or, more correctly, everything I do not understand.
Re: Let Me Count The Ways
You explained very clearly what the problem seems to be.
Seems you figured out WHY it won't work, and gave the reasons it won't work.
Those reasons make perfectly good sense. An ISO is read-only so EFI allows it to be read.
So I guess, EFI is not as secure as they claim. Virus, Malware, and Ransomware can all be seen as Read-Only if presented as an ISO. Then run itself the same way a LIVE Distro does when it brings up the splash and user screen.
There has got to be a way these guys at the library are doing it.
Could it be the LIVE OS has persistence, and the bootloader is in the read/write area of the USB drive?
Or could it be they only think they have an installed version and are actually running from the LIVE OS instead?
No that's not it, because he has Lubuntu as the LIVE OS and regular Ubuntu or another OS as the installed OS.
I wish I had time to try it myself to see what is going on, but it is probably way over my head for sure.
Since the kids have USB Sticks that are working for them, there must be a way to do it.
I'll keep digging myself to see if I can find out what the trick is.
Seems you figured out WHY it won't work, and gave the reasons it won't work.
Those reasons make perfectly good sense. An ISO is read-only so EFI allows it to be read.
So I guess, EFI is not as secure as they claim. Virus, Malware, and Ransomware can all be seen as Read-Only if presented as an ISO. Then run itself the same way a LIVE Distro does when it brings up the splash and user screen.
There has got to be a way these guys at the library are doing it.
Could it be the LIVE OS has persistence, and the bootloader is in the read/write area of the USB drive?
Or could it be they only think they have an installed version and are actually running from the LIVE OS instead?
No that's not it, because he has Lubuntu as the LIVE OS and regular Ubuntu or another OS as the installed OS.
I wish I had time to try it myself to see what is going on, but it is probably way over my head for sure.
Since the kids have USB Sticks that are working for them, there must be a way to do it.
I'll keep digging myself to see if I can find out what the trick is.
Re: Let Me Count The Ways
The disclaimer for my last commentary is that I told you all l know. I don't know enough to solve the problem, which means there is more to know than what is crammed into my head. For one thing I don't know much about EFI or UEFI theory. I can see what it's doing, but I don't know what it is supposed to be doing. Likewise with GRUB. I've seen more GRUB than all the cowboys in Wyoming ate last year. When it crashes and I get the recovery screen, I have no clue what to do or what can be done. I'm sure if I were well versed in both EFI and GRUB the Windows bootloader would be a no brainer.
Then, there is the logical reasoning. If those kids in the library have the kind of USB I want to make, and if you can go to the right computer store and buy one pre-made, there must be a relatively easy way to do it. I'd go so far as to assume you were told how, but some critical details got lost in the translation.
For example, what exactly does "cloning" mean? When I tried to "clone" a working OS and write it to a USB stick it looked perfect. However, the permissions were not correct. The system files need to be owned by root and "sudo dd" (the Linux root copy command) didn't do it. I agree that if I can clone a working system onto a USB stick, that would be the first step in creating a portable device.
I'm having conflicting thoughts about GRUB too. The live OS has a GRUB that calls the kernel from the ISO. That's the scenario that allows it to boot anywhere. How does installing a working OS change the live OS GRUB? It doesn't because it's read-only. Yet, I do not recall anywhere in the descriptions you gave where it says to change the ISO GRUB file. The only reference to that is a comment stating by installing a working OS, a copy of GRUB will also be installed. I've not seen any hint of where it will be installed, and as I stated many times already, Ubuntu puts it in the Windows EFI partition regardless of the choice I make to the contrary. So, instead of installing GRUB, maybe I should "clone" Grub? Doing that messes up the UUID's and will require deep dive editing to fix. Again, I've not seen any instructions about editing GRUB. Well, not in the methods you describe anyway.
I have read about editing EFI files and editing GRUB in forums with self-appointed experts answering questions similar to but not exactly like mine. I've linked you to articles discussing those edits. It's not a nightmare, but it's not the kind of thing a library kid would be doing either. I doubt a store owner would sell a memory stick for any price the kids could afford if he did similar editing. So, I'm guessing along with you, there has got to be a better way. But damn. Nobody is writing about it.
Then, there is that nagging thought about those library kids telling me that maybe they aren't doing what I am trying to do. A live OS with persistence looks a hella lot like an installed system. In fact it is identical until you try to update the kernel. I doubt the homework bound students are into messing with Linux kernels, but who knows?
And, since you brought it up, how secure is a computer running a live OS? You are correct about anybody being able to make their own ISO, bootable anywhere and full of malicious code. It is a vulnerability which isn't a big secret. It was very simple to break into any computer back in the MBR days. Hit F12 and boot from your USB. Steal all you want and remove the USB without a trace. The same thing can be done in EFI too. But, secure boot is indeed secure. Your Linux live OS will not be able to access Windows files if Windows is installed using secure boot techniques. You will need that access key that nobody else but Microsoft has, and possibly one from the system's owner too. Thus, only people who work for Micorsoft and know what that key is can break into your computer ... ... ... oh oohhhh
Then, there is the logical reasoning. If those kids in the library have the kind of USB I want to make, and if you can go to the right computer store and buy one pre-made, there must be a relatively easy way to do it. I'd go so far as to assume you were told how, but some critical details got lost in the translation.
For example, what exactly does "cloning" mean? When I tried to "clone" a working OS and write it to a USB stick it looked perfect. However, the permissions were not correct. The system files need to be owned by root and "sudo dd" (the Linux root copy command) didn't do it. I agree that if I can clone a working system onto a USB stick, that would be the first step in creating a portable device.
I'm having conflicting thoughts about GRUB too. The live OS has a GRUB that calls the kernel from the ISO. That's the scenario that allows it to boot anywhere. How does installing a working OS change the live OS GRUB? It doesn't because it's read-only. Yet, I do not recall anywhere in the descriptions you gave where it says to change the ISO GRUB file. The only reference to that is a comment stating by installing a working OS, a copy of GRUB will also be installed. I've not seen any hint of where it will be installed, and as I stated many times already, Ubuntu puts it in the Windows EFI partition regardless of the choice I make to the contrary. So, instead of installing GRUB, maybe I should "clone" Grub? Doing that messes up the UUID's and will require deep dive editing to fix. Again, I've not seen any instructions about editing GRUB. Well, not in the methods you describe anyway.
I have read about editing EFI files and editing GRUB in forums with self-appointed experts answering questions similar to but not exactly like mine. I've linked you to articles discussing those edits. It's not a nightmare, but it's not the kind of thing a library kid would be doing either. I doubt a store owner would sell a memory stick for any price the kids could afford if he did similar editing. So, I'm guessing along with you, there has got to be a better way. But damn. Nobody is writing about it.
Then, there is that nagging thought about those library kids telling me that maybe they aren't doing what I am trying to do. A live OS with persistence looks a hella lot like an installed system. In fact it is identical until you try to update the kernel. I doubt the homework bound students are into messing with Linux kernels, but who knows?
And, since you brought it up, how secure is a computer running a live OS? You are correct about anybody being able to make their own ISO, bootable anywhere and full of malicious code. It is a vulnerability which isn't a big secret. It was very simple to break into any computer back in the MBR days. Hit F12 and boot from your USB. Steal all you want and remove the USB without a trace. The same thing can be done in EFI too. But, secure boot is indeed secure. Your Linux live OS will not be able to access Windows files if Windows is installed using secure boot techniques. You will need that access key that nobody else but Microsoft has, and possibly one from the system's owner too. Thus, only people who work for Micorsoft and know what that key is can break into your computer ... ... ... oh oohhhh
Re: Let Me Count The Ways
I mentioned your problem to my neighbor across the street while he was washing his van.
He said after he got his laptop loaded up with all the programs he uses and it was working the way he wanted. He copied the OS over to a USB drive, creating his own Ubuntu ISO. He did this using Clonezilla, but did so so he had a backup.
Said he made a second copy to try something. All he had to do was run Boot Repair to make the USB drive bootable.
However, this might not boot on a UEFI machine. Although said he never tried it, but adding a single small FAT32 partition containing
\EFI\BOOT\BOOTx64.EFI
should work and be recognized by the computer and boot the USB drive.
He did not know why they would install a Live OS and an Installed OS on the same USB drive, when you can Install an OS to removable drives just as easily as internal drives. But getting them to boot on any machine means they have to be an ISO of a working program. I asked if that meant it was then read only and he said yes, but you can have a partition to save data. Also said, maybe that is why they have both a LIVE OS and an Installed OS, although it didn't make sense to him.
I told him about the kids at the library using Linux on USB sticks on the Windows10 computers. None of them really remember how they made their USB stick for me to pass the info along to someone else.
All he could say is a lot of kids carry their own OS on USB sticks, and can save their homework to them.
And perhaps it is something he might look into if he can find time to do so.
I asked him if ever found out to let me know. He said he would. But I won't wait for the cows to come home, hi hi.
He said after he got his laptop loaded up with all the programs he uses and it was working the way he wanted. He copied the OS over to a USB drive, creating his own Ubuntu ISO. He did this using Clonezilla, but did so so he had a backup.
Said he made a second copy to try something. All he had to do was run Boot Repair to make the USB drive bootable.
However, this might not boot on a UEFI machine. Although said he never tried it, but adding a single small FAT32 partition containing
\EFI\BOOT\BOOTx64.EFI
should work and be recognized by the computer and boot the USB drive.
He did not know why they would install a Live OS and an Installed OS on the same USB drive, when you can Install an OS to removable drives just as easily as internal drives. But getting them to boot on any machine means they have to be an ISO of a working program. I asked if that meant it was then read only and he said yes, but you can have a partition to save data. Also said, maybe that is why they have both a LIVE OS and an Installed OS, although it didn't make sense to him.
I told him about the kids at the library using Linux on USB sticks on the Windows10 computers. None of them really remember how they made their USB stick for me to pass the info along to someone else.
All he could say is a lot of kids carry their own OS on USB sticks, and can save their homework to them.
And perhaps it is something he might look into if he can find time to do so.
I asked him if ever found out to let me know. He said he would. But I won't wait for the cows to come home, hi hi.
Closing In
If I read that right, your neighbor creates an ISO of a working operating system and then copies that image onto a USB memory stick. That's exactly the same as downloading a copy of some Linux distro for the purpose of installing it elsewhere. Your neighbor, however, is not using his ISO to install anything. He is using it as a backup. Because it is an ISO image it cannot be altered. Storage can be added in the form a partition, namely /casper-rw. While that gives you storage space, or persistence, it does not allow for the ISO to be modified, or updated.
The process of copying/cloning can be accomplished in several ways. Clonezilla is very popular, although I must confess to never have used it. I did use something from Acronis to copy the contents of my laptop hard drive onto the replacement SSD. Amazingly the original drive was 1-TB in size while the SSD was only 500GB. I did nothing but copy one to the other, then swapped the hardware. Windows never knew anything happened. LOL Then, too, all this can be done from the Linux command line. The dd command can make an ISO. I've done that already. I've also seen partition management programs that have the feature allowing a copy of one drive to another. They usually charge for that much functionality, but the point is making a copy, or an ISO, is not the problem I'm battling.
I'm very impressed to read that your neighbor claims using BootRepair will enable a USB to boot. I've read that same instruction elsewhere but never tried it out. I have used BootRepair to, well, repair my Windows 7 MBR. It works great in that capacity. I suppose it can be used to for a USB stick to boot as well. Testing it out is on my To-Do list.
None of the above mentioned copy/clone techniques will work for EFI without additional intervention. To boot in the EFI mode, as your neighbor confirmed, a small FAT32 formatted partition must be present on the same drive as the OS. This is the EFI partition and must have two flags set, esp and boot. Nobody I read was very clear about what should be in that partition, but the guy who wrote that Ubuntu wiki I cited says in no uncertain terms that the Ubuntu installer doesn't touch it when it's on a USB memory stick. Folks who claim they know, say the Windows EFI bootloader has exactly what your neighbor describes for each OS that is installed. It's what is required to boot. However, \EFI\BOOT\BOOTx64.EFI is generic. What is in that file? My educated guess is that it's different for each OS installed. That BOOTx64.EFI file has directions in it telling the system where to look for the bootloader (GRUB) being called, and that changes for each installed OS. All this works fine in a fixed system. When a crazed user (me) wants to change the external drive (or USB memory stick), the fixed EFI boot instructions fail.
I know the solution to this dilemma. A working OS- not an ISO image - must be installed to USB. Be it EFI or not, GRUB must also exist with instructions for loading the kernel of the installed OS. These two things make the USB stick portable. The trick is getting the host computer to recognize my portable USB stick. Up to now the only solution I've seen is to use an ISO image instead.
Strangely, both your neighbor and the guy who wrote that Ubuntu wiki claim they never tried it, but it should work.
I have two tricks left. One is to remove the hard drive from the laptop. Then, sans the Windows HDD, install an OS onto a memory stick. That would be reasonable if I didn't have to physically remove the drive. The other trick is to follow your neighbor's advice and copy a working OS to a USB memory stick (even though he said to make it an ISO image). Then run BootRepair to get it to boot. Whether it will boot on any other computer is the big question.
The process of copying/cloning can be accomplished in several ways. Clonezilla is very popular, although I must confess to never have used it. I did use something from Acronis to copy the contents of my laptop hard drive onto the replacement SSD. Amazingly the original drive was 1-TB in size while the SSD was only 500GB. I did nothing but copy one to the other, then swapped the hardware. Windows never knew anything happened. LOL Then, too, all this can be done from the Linux command line. The dd command can make an ISO. I've done that already. I've also seen partition management programs that have the feature allowing a copy of one drive to another. They usually charge for that much functionality, but the point is making a copy, or an ISO, is not the problem I'm battling.
I'm very impressed to read that your neighbor claims using BootRepair will enable a USB to boot. I've read that same instruction elsewhere but never tried it out. I have used BootRepair to, well, repair my Windows 7 MBR. It works great in that capacity. I suppose it can be used to for a USB stick to boot as well. Testing it out is on my To-Do list.
None of the above mentioned copy/clone techniques will work for EFI without additional intervention. To boot in the EFI mode, as your neighbor confirmed, a small FAT32 formatted partition must be present on the same drive as the OS. This is the EFI partition and must have two flags set, esp and boot. Nobody I read was very clear about what should be in that partition, but the guy who wrote that Ubuntu wiki I cited says in no uncertain terms that the Ubuntu installer doesn't touch it when it's on a USB memory stick. Folks who claim they know, say the Windows EFI bootloader has exactly what your neighbor describes for each OS that is installed. It's what is required to boot. However, \EFI\BOOT\BOOTx64.EFI is generic. What is in that file? My educated guess is that it's different for each OS installed. That BOOTx64.EFI file has directions in it telling the system where to look for the bootloader (GRUB) being called, and that changes for each installed OS. All this works fine in a fixed system. When a crazed user (me) wants to change the external drive (or USB memory stick), the fixed EFI boot instructions fail.
I know the solution to this dilemma. A working OS- not an ISO image - must be installed to USB. Be it EFI or not, GRUB must also exist with instructions for loading the kernel of the installed OS. These two things make the USB stick portable. The trick is getting the host computer to recognize my portable USB stick. Up to now the only solution I've seen is to use an ISO image instead.
Strangely, both your neighbor and the guy who wrote that Ubuntu wiki claim they never tried it, but it should work.
I have two tricks left. One is to remove the hard drive from the laptop. Then, sans the Windows HDD, install an OS onto a memory stick. That would be reasonable if I didn't have to physically remove the drive. The other trick is to follow your neighbor's advice and copy a working OS to a USB memory stick (even though he said to make it an ISO image). Then run BootRepair to get it to boot. Whether it will boot on any other computer is the big question.
UEFI Explained
Since EFI seems to be an integral point in this thread, I thought it was about time I did some specific EFI research. The usual Google search produced the usual list of interesting titles. One stood out from the rest and I am passing the link on to you simply as an FYI. It's a VERY lengthy blog, but it is well written and best of all it is understandable. I learned a few things reading this article, but I still have a long way to go before I can say I understand UEFI completely. The blog is entertaining as well as informative, all of which will make it a worthy read. So, if you care to know a bit more about UEFI than you currently know, READ THIS: https://www.happyassassin.net/2014/01/2 ... work-then/
Re: Let Me Count The Ways
Yes that was a mighty long read, but quite informative and fairly clear.
At the end he made a few comments that one should keep their OSs on separate drives to keep from having headaches over problems. But prior to that he talked about multi-boot and a few other ways of booting up a computer.
A couple of things did stand out so I copied them below as I was reading.
And the way they read, it appears making hot pluggable USB sticks, either Live or Installed OSs.
He gave examples of what the UEFI looks like for drives that do not have a UUID associated with them.
I'm sure you looked at those images he posted, and read what those lines meant.
Read the couple of paragraphs I posted below from his article and see if they will help you get the USB sticks working.
Just copying a couple of things I found reading that long article.
What the firmware will actually do when trying to boot in this way is reasonably simple. The firmware will look through each EFI system partition on the disk in the order they exist on the disk. Within the ESP, it will look for a file with a specific name and location. On an x86-64 PC, it will look for the file \EFI\BOOT\BOOTx64.EFI. What it actually looks for is \EFI\BOOT\BOOT{machine type short-name}.EFI – ‘x64’ is the “machine type short-name” for x86-64 PCs. The other possibilities are BOOTIA32.EFI (x86-32), BOOTIA64.EFI (Itanium), BOOTARM.EFI (AArch32 – that is, 32-bit ARM) and BOOTAA64.EFI (AArch64 – that is, 64-bit ARM). It will then execute the first qualifying file it finds (obviously, the file needs to be in the executable format defined in the UEFI specification).
This mechanism is not designed for booting permanently-installed OSes. It’s more designed for booting hotpluggable, device-agnostic media, like live images and OS install media. And this is indeed what it’s usually used for. If you look at a UEFI-capable live or install medium for a Linux distribution or other OS, you’ll find it has a GPT partition table and contains a FAT-formatted partition at or near the start of the device, with the GPT partition type that identifies it as an EFI system partition. Within that partition there will be a \EFI\BOOT directory with at least one of the specially-named files above. When you boot a Fedora live or install medium in UEFI-native mode, this is the mechanism that is used. The BOOTx64.EFI (or whatever) file handles the rest of the boot process from there, booting the actual operating system contained on the medium.
If you’re using UEFI native booting, and you don’t tend to build your own kernels or kernel modules or use the NVIDIA or ATI proprietary drivers on Linux, you might want to leave Secure Boot on. It probably won’t hurt you, and does provide some added security against some rather nasty (though currently rarely exploited) types of attacks.
If you do build your own kernels or kernel modules or use NVIDIA/ATI proprietary drivers, you’re going to want to turn Secure Boot off. Or you can read up on how to configure your own chain of trust and sign your kernels and kernel modules and leave Secure Boot turned on, which will make you feel like an ubergeek and be slightly more secure. But it’s going to take you a good solid weekend at least.
At the end he made a few comments that one should keep their OSs on separate drives to keep from having headaches over problems. But prior to that he talked about multi-boot and a few other ways of booting up a computer.
A couple of things did stand out so I copied them below as I was reading.
And the way they read, it appears making hot pluggable USB sticks, either Live or Installed OSs.
He gave examples of what the UEFI looks like for drives that do not have a UUID associated with them.
I'm sure you looked at those images he posted, and read what those lines meant.
Read the couple of paragraphs I posted below from his article and see if they will help you get the USB sticks working.
Just copying a couple of things I found reading that long article.
What the firmware will actually do when trying to boot in this way is reasonably simple. The firmware will look through each EFI system partition on the disk in the order they exist on the disk. Within the ESP, it will look for a file with a specific name and location. On an x86-64 PC, it will look for the file \EFI\BOOT\BOOTx64.EFI. What it actually looks for is \EFI\BOOT\BOOT{machine type short-name}.EFI – ‘x64’ is the “machine type short-name” for x86-64 PCs. The other possibilities are BOOTIA32.EFI (x86-32), BOOTIA64.EFI (Itanium), BOOTARM.EFI (AArch32 – that is, 32-bit ARM) and BOOTAA64.EFI (AArch64 – that is, 64-bit ARM). It will then execute the first qualifying file it finds (obviously, the file needs to be in the executable format defined in the UEFI specification).
This mechanism is not designed for booting permanently-installed OSes. It’s more designed for booting hotpluggable, device-agnostic media, like live images and OS install media. And this is indeed what it’s usually used for. If you look at a UEFI-capable live or install medium for a Linux distribution or other OS, you’ll find it has a GPT partition table and contains a FAT-formatted partition at or near the start of the device, with the GPT partition type that identifies it as an EFI system partition. Within that partition there will be a \EFI\BOOT directory with at least one of the specially-named files above. When you boot a Fedora live or install medium in UEFI-native mode, this is the mechanism that is used. The BOOTx64.EFI (or whatever) file handles the rest of the boot process from there, booting the actual operating system contained on the medium.
If you’re using UEFI native booting, and you don’t tend to build your own kernels or kernel modules or use the NVIDIA or ATI proprietary drivers on Linux, you might want to leave Secure Boot on. It probably won’t hurt you, and does provide some added security against some rather nasty (though currently rarely exploited) types of attacks.
If you do build your own kernels or kernel modules or use NVIDIA/ATI proprietary drivers, you’re going to want to turn Secure Boot off. Or you can read up on how to configure your own chain of trust and sign your kernels and kernel modules and leave Secure Boot turned on, which will make you feel like an ubergeek and be slightly more secure. But it’s going to take you a good solid weekend at least.
Re: Let Me Count The Ways
I don't know how helpful that blog will be to you, but it certainly is a good explanation of EFI, and BIOS.
The key element of EFI booting from a USB memory stick is that ESP partition. All the information needed to boot should be inside that partition. Your neighbor is not the first person who recognizes the importance of \EFI\BOOT\BOOTx64.EFI, or it's kin. I've read in a few places about how it must be present. Some explained how to add it, if it is missing. I also read that each OS installed on a hard drive has it's own \EFI\BOOT\BOOTx64.EFI and subsequent code. Modifying these directories is one way to edit what comes up as a candidate for booting. The Wiki article I cited earlier goes one step further and describes what other coding must follow the above entry. I have yet to do that to see if it works, but it sounds reasonable because in my case with Ubuntu that ESP partition ends up empty. I must put something in there.
And, that brings up another point. How do you put stuff into that ESP directory? Apparently there are a few tricks but the only sure way is to manually put in the needed code. That requires an editor, which Linux happens to have built in. I looked into the Windows version of a boot manager editor and it's just as convoluted. I found an editor I could use and then pay for after it expires. EasyEFI is it's name, and I've seen references to THAT program in several places. So, I downloaded it and tried to install it. I get an error message telling me it can only be installed in a Windows system set up for UEFI. That's what I have. So much for popular editors.
Indeed, there is a "mechanism" (fallback) in EFI boot that seems made for my purpose. It's an entry in the boot manager list that simply says, boot this device. It doesn't even know what the device is. All that instruction does is send the boot sequence over to the unspecified device and lets it take over. The target in my case would be the GRUB of the installed OS on the USB stick. Ubuntu refuses to put its GRUB in the ESP partition of the USB memory, which is why I'm having problems.
I read those recommendations with a smile on my face: "Keep each OS on a disc of it's own." I know I've mentioned it in other discussions, and it works really well on the Windows 7 machine. Actually, I only keep Windows 7 in isolation. All the Linux boys seem to play well together. I don't have that option in the laptop because there is only one hard drive. Besides, I'm not having problems with the Linux installed next to Windows on the SSD. However, I am trying to isolate an OS to a drive of it's own by using USB memory. The unusual caveat is that the drive in my case must be portable and not permanent. Judging by everything I've read lately, EFI doesn't care. It is designed to do that ... somehow.
The key element of EFI booting from a USB memory stick is that ESP partition. All the information needed to boot should be inside that partition. Your neighbor is not the first person who recognizes the importance of \EFI\BOOT\BOOTx64.EFI, or it's kin. I've read in a few places about how it must be present. Some explained how to add it, if it is missing. I also read that each OS installed on a hard drive has it's own \EFI\BOOT\BOOTx64.EFI and subsequent code. Modifying these directories is one way to edit what comes up as a candidate for booting. The Wiki article I cited earlier goes one step further and describes what other coding must follow the above entry. I have yet to do that to see if it works, but it sounds reasonable because in my case with Ubuntu that ESP partition ends up empty. I must put something in there.
And, that brings up another point. How do you put stuff into that ESP directory? Apparently there are a few tricks but the only sure way is to manually put in the needed code. That requires an editor, which Linux happens to have built in. I looked into the Windows version of a boot manager editor and it's just as convoluted. I found an editor I could use and then pay for after it expires. EasyEFI is it's name, and I've seen references to THAT program in several places. So, I downloaded it and tried to install it. I get an error message telling me it can only be installed in a Windows system set up for UEFI. That's what I have. So much for popular editors.
Indeed, there is a "mechanism" (fallback) in EFI boot that seems made for my purpose. It's an entry in the boot manager list that simply says, boot this device. It doesn't even know what the device is. All that instruction does is send the boot sequence over to the unspecified device and lets it take over. The target in my case would be the GRUB of the installed OS on the USB stick. Ubuntu refuses to put its GRUB in the ESP partition of the USB memory, which is why I'm having problems.
I read those recommendations with a smile on my face: "Keep each OS on a disc of it's own." I know I've mentioned it in other discussions, and it works really well on the Windows 7 machine. Actually, I only keep Windows 7 in isolation. All the Linux boys seem to play well together. I don't have that option in the laptop because there is only one hard drive. Besides, I'm not having problems with the Linux installed next to Windows on the SSD. However, I am trying to isolate an OS to a drive of it's own by using USB memory. The unusual caveat is that the drive in my case must be portable and not permanent. Judging by everything I've read lately, EFI doesn't care. It is designed to do that ... somehow.
Re: Let Me Count The Ways
Well I can say one thing with certainty. The computer service company will not disclose exactly how they make the USB Sticks so that all they have to do is clone new ones to sell each time someone wants to buy one.
If they told exactly how they did it, no one would buy them.
But he did say, how they do it was gleaned from on-line forums, so keep hunting, the method that works is out there, but it is done using all command line instructions. It really is easy to do, but with so much misinformation out there, it is keeping us in business.
One hint, a USB stick is no different than your HD, but everything must be on the USB stick, so it is treated like your HD by the computer. Nothing is installed on your computer when running a USB stick, unless you save something to the desktop, which I don't think you can do on the Library computers, but it is saved in the desktop folder on the USB stick in an installed OS, so there ya go, run with it.
I had to ask also why it is so popular among the kids.
For school kids, it is the programs they need to do their work. What most of them need is not on library computers.
For others, it is the crap they are getting off the Internet that is blocked by the library computers, hi hi.
If they told exactly how they did it, no one would buy them.
But he did say, how they do it was gleaned from on-line forums, so keep hunting, the method that works is out there, but it is done using all command line instructions. It really is easy to do, but with so much misinformation out there, it is keeping us in business.
One hint, a USB stick is no different than your HD, but everything must be on the USB stick, so it is treated like your HD by the computer. Nothing is installed on your computer when running a USB stick, unless you save something to the desktop, which I don't think you can do on the Library computers, but it is saved in the desktop folder on the USB stick in an installed OS, so there ya go, run with it.
I had to ask also why it is so popular among the kids.
For school kids, it is the programs they need to do their work. What most of them need is not on library computers.
For others, it is the crap they are getting off the Internet that is blocked by the library computers, hi hi.
Re: Let Me Count The Ways
After all these weeks of research, trial, and error, I truly believe that making a portable USB operating system for EFI booting could be simple. Simple in theory. You said it clearly. The USB stick has to appear as a fully independent bootable device. The Windows UEFI boot manager simply has to recognize it, and then it will provide the option to select it.
How could something so simple be so difficult? You answered that question too. It has to be done manually from the command line. No average person would know how to do that. I think I have all the information necessary to create what I'm aspiring to create. It's not just tedious. Getting the job done right requires some skills and knowledge that go beyond "it just works." So, for those people who have that kind of resumé it's easy. Once the first USB stick is made, cloning it is a no-brainer. There are machines out there where you can stick in a master USB and clone 8/16/32 all at one time. The hard part is making the first one.
The manual copying of files method presumes that a working installation already exists. At that point it becomes a matter of copying from the working system to the USB stick. But the man from the shop said it was simple and implied anyone who knew how could do it. I can think of two possible ways to accomplish that simplicity.
One would be to remove the hard drive from the laptop and replace it with a liveUSB. Perform an install to a second USB in the usual manner. This eliminates a lot of copying and need to be careful about permissions. The downside is the requirement to physically remove the HDD each time a new USB stick OS is created.
The second method is one I ran across a couple times and have been ignoring. That is, to create this portable USB OS inside a Virtual Machine. Physical removal of the hard drive would be unnecessary in that method. The downside is that it would have to be run under Virtual Box software which is not as portable or high performance as I would like it to be.
As a side note I want to emphasize how much I appreciate the research you are doing on my behalf. I've gone over some the the notes you left and am at this point in my understanding convinced that not all the people you talked to are doing the same thing. It may look the same in the end, but there are some show stopping differences in implementation.
For example, in a post you made in this thread on 21 Aug 2019, you cite a procedure given to you by a person who appears to be very knowledgeable. The gist of his technique is to copy a previously installed and working OS onto a USB stick. He does it all from the command line "and said he has syslinux-utils installed and from that uses isohybrid --partok flag." I did some reading about syslinux-utils and was amazed to learn that it's a bootloader. Apparently it can be attached to an ISO image and take the place of GRUB. This reeks of intelligence that is involved with building their own kernels and codifying them into an ISO. The flags attached to that syslinux, isohybrid --partok, make it all work in MBR. There are some comments in the isohybrid Wiki suggesting it can be applied to UEFI, but the design of the software to for use in a Master Boot Record via BIOS firmware. This approach is exactly opposite of what I'm trying to create, but it is revealing to discover somebody is doing this manually. My guess is this guy has a PhD in Linux-ology and comes to the library only to remind himself os what mere mortals look like.
The good news is this mental giant adds to the consensus thinking that copying a working system onto a USB stick is the definitive method. That bad news is only he is capable of understanding how to do it in a technology that died a decade or two ago.
How could something so simple be so difficult? You answered that question too. It has to be done manually from the command line. No average person would know how to do that. I think I have all the information necessary to create what I'm aspiring to create. It's not just tedious. Getting the job done right requires some skills and knowledge that go beyond "it just works." So, for those people who have that kind of resumé it's easy. Once the first USB stick is made, cloning it is a no-brainer. There are machines out there where you can stick in a master USB and clone 8/16/32 all at one time. The hard part is making the first one.
The manual copying of files method presumes that a working installation already exists. At that point it becomes a matter of copying from the working system to the USB stick. But the man from the shop said it was simple and implied anyone who knew how could do it. I can think of two possible ways to accomplish that simplicity.
One would be to remove the hard drive from the laptop and replace it with a liveUSB. Perform an install to a second USB in the usual manner. This eliminates a lot of copying and need to be careful about permissions. The downside is the requirement to physically remove the HDD each time a new USB stick OS is created.
The second method is one I ran across a couple times and have been ignoring. That is, to create this portable USB OS inside a Virtual Machine. Physical removal of the hard drive would be unnecessary in that method. The downside is that it would have to be run under Virtual Box software which is not as portable or high performance as I would like it to be.
As a side note I want to emphasize how much I appreciate the research you are doing on my behalf. I've gone over some the the notes you left and am at this point in my understanding convinced that not all the people you talked to are doing the same thing. It may look the same in the end, but there are some show stopping differences in implementation.
For example, in a post you made in this thread on 21 Aug 2019, you cite a procedure given to you by a person who appears to be very knowledgeable. The gist of his technique is to copy a previously installed and working OS onto a USB stick. He does it all from the command line "and said he has syslinux-utils installed and from that uses isohybrid --partok flag." I did some reading about syslinux-utils and was amazed to learn that it's a bootloader. Apparently it can be attached to an ISO image and take the place of GRUB. This reeks of intelligence that is involved with building their own kernels and codifying them into an ISO. The flags attached to that syslinux, isohybrid --partok, make it all work in MBR. There are some comments in the isohybrid Wiki suggesting it can be applied to UEFI, but the design of the software to for use in a Master Boot Record via BIOS firmware. This approach is exactly opposite of what I'm trying to create, but it is revealing to discover somebody is doing this manually. My guess is this guy has a PhD in Linux-ology and comes to the library only to remind himself os what mere mortals look like.
The good news is this mental giant adds to the consensus thinking that copying a working system onto a USB stick is the definitive method. That bad news is only he is capable of understanding how to do it in a technology that died a decade or two ago.
Re: Let Me Count The Ways
I'm sure these kids making them have no idea how to do command line stuff.
The few who said they made their own simply used GUI programs and theirs just worked for them.
Although, I'm starting to wonder if there is something about the library computers themselves that allow them to run.
Maybe they really won't on just any computer. The only thing I really know about the library computers is that you cannot change anything on them. And the only place you can save something is to the desktop, and that is only temporary. You must save your work to a USB stick before you log off.
That being said, I'm sure they must be able to save some things, else the web browsers would not work, nor the msOffice program, which saves it's set-up for each user. Like on a spreadsheet, how many columns you select, etc. Now this could only be in RAM for all I know, I've never used their computers.
Well, I did a couple of times to look up the name of a book on-line, because the card catalog is not searchable that way.
I do know when you open a web browser, there is NO HISTORY for you to look back at, not even while you are using it.
Somebody, somewhere, has to know something, hi hi.
The few who said they made their own simply used GUI programs and theirs just worked for them.
Although, I'm starting to wonder if there is something about the library computers themselves that allow them to run.
Maybe they really won't on just any computer. The only thing I really know about the library computers is that you cannot change anything on them. And the only place you can save something is to the desktop, and that is only temporary. You must save your work to a USB stick before you log off.
That being said, I'm sure they must be able to save some things, else the web browsers would not work, nor the msOffice program, which saves it's set-up for each user. Like on a spreadsheet, how many columns you select, etc. Now this could only be in RAM for all I know, I've never used their computers.
Well, I did a couple of times to look up the name of a book on-line, because the card catalog is not searchable that way.
I do know when you open a web browser, there is NO HISTORY for you to look back at, not even while you are using it.
Somebody, somewhere, has to know something, hi hi.
Re: Let Me Count The Ways
The computers in a library would be an interesting environment to administer. It's not so hard to lock them down with Windows Group Policies, which is similar to groups and permissions in Linux/Unix. But that would only affect the performance and features. Security would be the greatest concern. There are a number of ways to go about it. I would make each login session temporary. Once the user logged off the entire environment would be deleted. This is a kind of sandboxing that would keep the kids out of the operating system and provide security against malware and viruses. If some dumb kid downloaded ransomeware and it shut down his session, he might lose what was saved to the desktop, but that's all. The computer and the network it's on would be isolated because the session is kind of a virtual machine that gets recreated with each login. For all we know those library computers are glorified dumb terminals running a remote desktop in a cloud somewhere. In that case there would be no need for an admin to visit the library. It could all be done from a central location.
Judging by the notes you left for me, I think I know enough about the problem now to say all the people you interviewed were not doing the same thing. I'm reasonably certain that when people plug in a USB stick on the library computers they are working with a liveUSB of some OS. Some, as you point out, are just using the memory for storage, but those who use it to run Linux are more than likely not doing what I am attempting.
I've learned quite a bit with your help and guidance. I have a simple understanding of how UEFI works which is something I did not have when I began this adventure. I've yet to determine how rare my aspiration is. I want a portable OS that I can run on any PC, but it turns out that such portability can be accomplished in more than one way. The easiest way is the liveUSB route, but that has some shortcomings I would prefer not to deal with. Creating a fully functional OS and copying it over to USB is the general idea, but actually doing that is a nightmare fraught with many pitfalls. Copying and pasting sounds simple, and it is when you do it in a word processor. When doing it with operating systems, simplicity vanishes. I guess I've been spoiled by the old way of doing things. There wasn't much to consider in the BIOS days. UEFI offers a whole new world of possibilities, but the price one pays for that flexibility is a need to learn about that world in advance. One mistake could be fatal.
I believe the answer to creating a portable USB resident OS is the manual copying of a existing OS and it's bootloader to the target. Last night I discovered what is necessary to access and view the bootloader partitions so that now it's just a matter of copying them. But do I want to? I need to fully install a given OS first, and then copy that to a removable memory device. That's a bit more complicated than making an ISO and installing from there. Almost every method I've run across claims that installing an OS from liveUSB to a working USB will automatically configure the bootloader, i.e., GRUB. Every time I try that, it does not happen. The OS installer modifies the existing Windows boot manager instead. Although I have read a couple times in Ubuntu support forums that what I'm seeing is the way Ubuntu is intended to work, there are many more people who claim it doesn't happen to them. If I could determine the truth to that claim, half the difficulty of making a portable USB OS would be eliminated.
Judging by the notes you left for me, I think I know enough about the problem now to say all the people you interviewed were not doing the same thing. I'm reasonably certain that when people plug in a USB stick on the library computers they are working with a liveUSB of some OS. Some, as you point out, are just using the memory for storage, but those who use it to run Linux are more than likely not doing what I am attempting.
I've learned quite a bit with your help and guidance. I have a simple understanding of how UEFI works which is something I did not have when I began this adventure. I've yet to determine how rare my aspiration is. I want a portable OS that I can run on any PC, but it turns out that such portability can be accomplished in more than one way. The easiest way is the liveUSB route, but that has some shortcomings I would prefer not to deal with. Creating a fully functional OS and copying it over to USB is the general idea, but actually doing that is a nightmare fraught with many pitfalls. Copying and pasting sounds simple, and it is when you do it in a word processor. When doing it with operating systems, simplicity vanishes. I guess I've been spoiled by the old way of doing things. There wasn't much to consider in the BIOS days. UEFI offers a whole new world of possibilities, but the price one pays for that flexibility is a need to learn about that world in advance. One mistake could be fatal.
I believe the answer to creating a portable USB resident OS is the manual copying of a existing OS and it's bootloader to the target. Last night I discovered what is necessary to access and view the bootloader partitions so that now it's just a matter of copying them. But do I want to? I need to fully install a given OS first, and then copy that to a removable memory device. That's a bit more complicated than making an ISO and installing from there. Almost every method I've run across claims that installing an OS from liveUSB to a working USB will automatically configure the bootloader, i.e., GRUB. Every time I try that, it does not happen. The OS installer modifies the existing Windows boot manager instead. Although I have read a couple times in Ubuntu support forums that what I'm seeing is the way Ubuntu is intended to work, there are many more people who claim it doesn't happen to them. If I could determine the truth to that claim, half the difficulty of making a portable USB OS would be eliminated.
Re: Let Me Count The Ways
All the computers at the branches are controlled from the main library downtown, including the ones the librarians use behind the desk. But they are on two totally separate systems. They do have timeout timers on them, but the librarian can over-ride these if no one is waiting to use a computer, or shorten the time too I think.
I'll be going to the Library in about an hour, whenever the frau says "let's go" hi hi.
In the interim, have you seen this website?
https://www.pendrivelinux.com/
It shows how to install either Live OSs or INSTALL OSs to thumb drives.
I read through a few of them and it sure seems simple.
But as you've learned, maybe not quite as simple as they make it sound, hi hi.
I'll be going to the Library in about an hour, whenever the frau says "let's go" hi hi.
In the interim, have you seen this website?
https://www.pendrivelinux.com/
It shows how to install either Live OSs or INSTALL OSs to thumb drives.
I read through a few of them and it sure seems simple.
But as you've learned, maybe not quite as simple as they make it sound, hi hi.