Universally Unique IDentifier(s)

[yogi]

Since I know you love to read my rants, typically about Linux but not always, I'll just add this to the list for your reading enjoyment.

It's not a big problem, but the Ubuntu installed on my laptop takes several minutes to boot up. It's been that way for a several days but I've been busy with other Linux projects and had no time to look into this issue. This morning I looked.

The first place I looked was on Google. To my amazement an article by Dedoimedo came up near the top. I recognize this name from the days Glenn was around to help me through my Linux adventures. He loved this guy. While there are many possible reasons for a slow boot Dedoimedo showed me a couple new commands wherein I can list the time it took to boot various processes (systemd-analyze critical-chain works like magic). Then there is also the boot log. Between the two I discovered that the system was hanging while looking for SWAP. I thought this to be odd but sure enough. When I opened Gparted to check things out, SWAP was not enabled. I could have enabled it, but don't really need it at this point., I need it to be identifiable during the boot process.

The Dedo man went through an example where his SWAP was hanging up the boot process due to a mismatch of UUID's for that partition. He claims to have fixed the slow boot by changing the UUID in /etc/fstab. Sounded reasonable to me. So I looked at the information block for the SWAP space listed with Gparted and got the UUID. It was not the same as the UUID specified in fstab so that I figured this was going to be a quick cure. But Dedoimedo didn't use Gparted to get his UUID. He used the blkid command instead. Well I got a list of devices and their UUID but the one for SWAP was not the same as the other two. The really confusing part is that all three UUID listings came from the correct partition: /dev/sda5. Gparted looked at it, fstab looked at it, and blkid looked at it; they all came up with different "unique" identifiers.

I'm scratching my head to try and understand how this could happen. The only possible explanation is that things got messed up while I was trying to install Linux MINT on that infamous USB memory stick. This doesn't make sense given that the hard disk with SWAP only was used to access the efi partition where all the GRUBs are installed, but who knows for sure? So, the question I have at the moment is how do I know which UUID is the right one? The one in fstab is obviously wrong, and the other two methods supposedly access the partition directly to get their info. It's just that different info is coming back. And once I get the correct UUID, is editing fstab really so simple? Change the UUID and I'm done??

I"m REALLY getting suspicious of that Ubuntu installer program.

[yogi]

Just a little update here.

I held my breath. made copies of fstab. and then altered the original one. The Swap space UUID obtained by using the blkid command did not work. The UUID obtained while using Gparted did work. It cut my boot time down by more than 50%. Then I blacklisted the native nVidia driver, updated initramfs, rebooted, and cut the boot time by at least another 50%. It's not booting as fast as Windows 10, but now it is looking more like a Linux OS than it used to.

[Kellemora]

I've hit that problem a couple of times myself.
How I fixed it was to delete the Swap File Partition, and then created a new Swap File partition.
What I don't remember is if I had to change anything in any other file or not.
I did this using GParted, so perhaps it rewrote whatever file I needed changed.

My computers, all of them, always hang for a minute saying No UTF-8 found, or something like that.
After a really long pause, it finally moves on and finishes booting up.
The strange thing is, I do have UTF-8 it's the standard text file letters.

I'm either super lucky, or things just work for me, most of the time.
When they don't, I sometimes spend a long time trying things mentioned on-line to try.
When I do find something that fixes the problem, I never remember which thing it was that did it.
And even if I did, it probably wouldn't work the next time, which is normal for my problems.

Debian was much harder to install than Ubuntu or Linux Mint because it is not a turn-key system.
If you want some bells and whistles, you have to find them, figure out if they are compatible, then build them yourself.
Now I usually don't build anything myself. If I can't find it as a .deb file, installable by GDebi, I do without it, hi hi.

I'm beginning to think you are learning more about Linux than I've forgotten in 15 years.

[yogi]

I like the challenge of finding a solution. It keeps my brain in working order. I don't like Linux in the sense that it's not intuitively obvious how to use it. It looks that way in the beginning, but if anything, and I do mean ANYTHING, goes wrong it'a a pain in the drain to fix it.

It's always a pain to fix something. My antidote is to be pro-active whenever I can instead of reactive. That means I rather use a mature and stable operating system than spend half my life fixing up one that is prone to breaking. I really would hate to abandon Linux at this point, but it's making it VERY difficult for me to be proactive and avoid problems. This UUID problem has revealed what I consider to be a major flaw. Let me explain what happened today.

Since you've been reading my other threads you know that I'm battling head to head with a version of Linux called Kali. Making nVidia work in that environment has been quite a challenge. It looks like it's going the path of Linux Mint wherein I decided it can't be done in a UEFI/GPT disk environment. That's not the point I'm trying to make, however. I decided to reinstall Kali one more time from a fresh download and new iso installer disk. The installation was flawless and I paid particular attention to the part where the installer was adding the existing SWAP partition to the disk configuration for Kali. I saw nothing unusual. The install completed and Kali still does not work.

Sooo ... I decided to boot up Ubuntu and see if I can break into Kali and snoop around for a hole in the wall. When I selected Ubuntu from its version of GRUB, it took a full three minutes and then some to boot. I was right back to where I was the other day. I checked all those UUID declarations again, and like the first time they were all different. The act of installing Kali changed the UUID of the Swap partition and broke my other two Linux installs.

The good news is that now I know what is causing my Linux OS's to slow boot. I'm not certain that the changing of UUID is confined to Kali. It could be that other Linux installers do the same thing. They can't just use the UUID that exists because that information is in the other OS's fstab file. So, when I install a new copy of Linux along side the others, it just makes up it's own version of a UUID for Swap. There is no consideration of the fact that there may be other Linux OS's depending on it. Whether this happens only in Kali or it is a general Linux installer protocol, it sucks.

Windows does not have this problem. The reason they don't is because as Microsoft is wont to do, they changed the device designations from UUID to GUID. It does the same thing as Linux, but it's a system onto its own. So, no matter what Linux decides to do, the GUID stays the same inside all Windows installs. Linux hasn't figured out how to do that yet.

I'm now thinking of those other Linux boxes I have scattered about my Command and Control Center. As you and I have observed from time to time the System Resource Monitor (almost) never shows Swap to be in use. My now educated guess is that the UUID specifying Swap in the /etc/fstab file does not match reality. System boot time may or may not be affected. Also, when I corrected the UUID this last time, I ran an update of initramfs one more time. Ubuntu now boots up in a flash. Even faster than when I fixed it the first time.

[Kellemora]

I really don't know why things are changing on your computer.
I've installed as many as six different OSs on the same computer and have never hit that problem.
All of them use the same Swap File, and in most cases, boot up fairly fast from a cold boot.

Right now on the Silver Yogi I have:
Windows XP Home,
Debian 9,
Debian 8,
Ubuntu 14 (the one you installed),
Ubuntu 15, and
Linux Mint Mate 17.
I only use Debian 9, but occasionally boot into the others looking for something from when I gave them a test drive.
I deleted one of the first I installed, Linux Mint Cinnamon 17 to have a partition for data storage.
I didn't like Cinnamon, but thought I would check it out. I prefer the Mate desktop.

When I boot up cold, the Grub II file shows all of them, with Debian 9 at the top, then Ubuntu 14, then Windows XP, Debian 8, Linux Mint, and finally Ubuntu 15. Plus the recover boot selection for each of those.

Now, whether one boots up slow or not don't usually bother me, because I rarely shut down the computer, only when their is a power outage, then I will boot up, check for updates, and finally load all the programs I keep running 24/7.

[yogi]

Let me take a wild guess and say that the Silver Yogi, the one which gives you no problems with Linux, has nothing but MBR and BIOS formatted storage in it. My ASUS tower is like that and I have no trouble with boot times, nVidia drivers (other than they need to be installed), or GRUB failures. I'm not saying the system is perfect, but it seldom gives me any problems. It wasn't until I moved it all over to GPT and UEFI that life got complicated. I don't know who is to blame, but I am learning a lot about how to fix unanticipated problems.

[Kellemora]

I've not changed anything on the Silver Yogi other than adding Debian right away, and then the other Distro's.
I just checked, yes it is MBR.

I have another HD on here that has Windows and several distro's as well, but although the HD checks out OK, it gives me problems so I don't put anything on it. It came out of the NAS that was hit by lightning so may have a problem because of that.