Consistent Issues Over Years With Linux SOLVED

Alexzee

Well-Known Member
Joined
Jun 1, 2019
Messages
3,649
Reaction score
1,948
Credits
21,640
Over the last 10 years I've enjoyed running Linux and still do today.:)
My friends and family that I've installed Linux for love their Linux too.

However; there are these 2 issues or problems, have you, that have been consistently occuring and I've grown very irritated with the situation. And, quite frankly, I'm pretty much fed up with having to keep editing the same file over and over again and have to explain myself.

It's my hope that someone knows the fix for what I'm about to explain.

OR> at the very least enlighten me on ideas where to dig into to find evidence to support what's happening and find who or what party profits (if any) from these things happening.

Afterall, something always comes before something else.
In other words something was in place before systemd. (just an example:)

Over this 10 year period I've installed various Linux distributions on a lot of people's pc's and the problem starts right after the fresh installation and first update to the system.

What happens is with most of the Debian based or Ubuntu based distro's that I've installed I've gotten:
" A start job is running for /dev/disk/by-uuid <number of device>"
It holds up the system at boot time for 1 minute and 30 seconds looking for something (I think a swap partition) and finally times out and the boot resumes.
-::::-This also creates drama with the /etc/fstab file which when compared to the output of blkid 'doesn't match'.-::::-

When that happens I almost always have to do one of 2 things.
Either edit and fix the uuid in the /etc/fstab file with the correct uuid from the output of blkid <or> comment out the whole partition string that doesn't exist from looking at all partitions in gparted.
Which btw, is even harder to fix on a triple booted Linux box.

I am suspicious that this is something that the installer is not getting right during the installation. The installer appears to somehow mis-configure all of the other swap partitions during a regeneration cycle of the other swaps on a rig that has other Linux os installed.

The other issue is boot times after fresh installs that take up to 3 to 5 min's before log in.
Is systemd to blame?
Is this another Nvidia strikes again issue?

Changing the default timeout that's set to 90 seconds sometimes helps and sometimes not.
I've seen folks disable services that were not necessary at boot time and it still hasn't helped.
Is this a hardware issue?

Looking at my signature line you can see I'm not a fan of fixing what's not broken but clearly something here is not right.

Any help, ideas, insight and assistance is greatly appreciated:-:)

Cheers,
Alex
 
Last edited:


What happens is with most of the Debian based or Ubuntu based distro's that I've installed I've gotten:
" A start job is running for /dev/disk/by-uuid <number of device>"
It holds up the system at boot time for 1 minute and 30 seconds looking for something (I think a swap partition) and finally times out and the boot resumes.
-::::-This also creates drama with the /etc/fstab file which when compared to the output of blkid 'doesn't match'.-::::-
How do you install the system? Using the defaults? Do you customize it a bit? Do you setup different partitions? I install every distro using the defaults so I don't get into trouble but I've seen this too and most of the times it is the swap partition which I guess is not properly detected either because it won't mount at boot or mountpoint changes, at least that's been the case for me, however, I must say that it' hasn't been a recurrent issue but only a couple of times as far as I can remember.
 
How do you install the system? Using the defaults? Do you customize it a bit? Do you setup different partitions? I install every distro using the defaults so I don't get into trouble but I've seen this too and most of the times it is the swap partition which I guess is not properly detected either because it won't mount at boot or mountpoint changes, at least that's been the case for me, however, I must say that it' hasn't been a recurrent issue but only a couple of times as far as I can remember.
Thanks for such a quick response.

I install the system generally with a LIve USB and sometimes a Live CD/DVD +RW.
Yes, I select the defaults and once it's installed yeah, I customize it by changing the fonts and appearance. Than customize FF.

As far as partitioning goes, I always select manual because most of the install's that I've performed have either been dual or multiboot rigs.
Most of the time I just create a ext 4 journaling fs and a swap partition.

Very rarely (unless I'm installing a RH based os) will I create a /home, /boot, /root and swap.

Could the installers be making mountpoint changes?
 
As far as partitioning goes, I always select manual because most of the install's that I've performed have either been dual or multiboot rigs.
Most of the time I just create a ext 4 journaling fs and a swap partition.

I don't dual or multiboot, I used to in the past but not in the last 5-6 years, I think. If I need/want something from some other distro/OS I just create a VM and that's easier. I know it's not the same but it serves my purposes. So, when I said that I use the defaults I meant not choosing manual partition but let the installer do that for me, which I'm aware it's not an option if dual or multibooting.
Could the installers be making mountpoint changes?
Maybe, don't know. When you manually create the partitions, do you create one swap for each OS/distro or do they share the same one? Just curious. I'll try to do some "multiboot VM" to see whether the issue appears or not and let you know how that went.
 
I’ve had Debian on my laptop since before systemd was introduced. As soon as systemd was added, it considerably increased boot times. It used to boot really quickly. Since systemd - startup took up to two or three minutes!

From what I remember the last time I started to look at it - the system was waiting for particular services to start. Some of which were services I wasn’t using and didn’t even have installed. So I hacked my systemd configs to remove all references to things I don’t use. That has helped a bit. Hasn’t sped things up much though.
I just haven’t had the time, or the inclination to try to investigate it properly.

But systemd is definitely a factor. Whether it’s systemd itself, or the way that Debian configures it - IDK.

I’ve just put up with the increased boot times. I don’t often shut down anyway. I normally just close the lid and hibernate/suspend my machine instead nowadays. Then when I open the lid - it comes back in seconds!
 
I’ve had Debian on my laptop since before systemd was introduced. As soon as systemd was added, it considerably increased boot times. It used to boot really quickly. Since systemd - startup took up to two or three minutes!
Interesting.

Boot times using Sparky Linux 5.11 (Nibiru) on my 2013 Dell OptiPlex XE.
Code:
systemd-analyze

cold start
thomas@thomas-pc:~$ systemd-analyze
Startup finished in 5.920s (kernel) + 27.227s (userspace) = 33.147s
graphical.target reached after 25.607s in userspace
thomas@thomas-pc:~$

restart / reboot
thomas@thomas-pc:~$ systemd-analyze
Startup finished in 5.876s (kernel) + 21.525s (userspace) = 27.402s
graphical.target reached after 21.509s in userspace
thomas@thomas-pc:~$


Boot times using Lubuntu 20.04 (Focal Fossa) on my 2010 Dell Optiplex 380.
Code:
systemd-analyze

cold start.
thomas@dell-optiplex380:~$ systemd-analyze
Startup finished in 5.795s (kernel) + 1min 17.855s (userspace) = 1min 23.650s
graphical.target reached after 1min 7.634s in userspace
thomas@dell-optiplex380:~$

restart / reboot.
thomas@dell-optiplex380:~$ systemd-analyze
Startup finished in 5.831s (kernel) + 54.394s (userspace) = 1min 226ms
graphical.target reached after 54.381s in userspace
thomas@dell-optiplex380:~$
 
Last edited by a moderator:
I've installed and used Kubuntu on my primary desktop unit for ~12 years. I don't remember ever having that situation. I've also installed Ubuntu and Debian cousins on my laptop as well as distros from other Linux family tree branches, and same result - no fstab issues.

My install procedure involves the use of the "manual" install option, what has been referred to as "something else" on other distros. If the drive is new or has not been cleaned up in a while, I'll rebuild the partitioning table (GPT over the last few years). I always format the / partition which means that the installer will build a new fstab. If I am retaining the /home on an existing hard drive that was not re-partitioned, I'll just verify the size and filesystem but not select to format, then save the changes, tell it where to place the Grub boot files, and let the installer do its thing. The /etc/fstab file has to be correct, because it is being built with current info. The process for two drives is exactly the same.

The situation you describe iusually happens when one drive is cloned onto another drive where the UUIDs in the fstab of the original drive get retained on the target drive.

I'm not saying you're doing anything wrong, but if your situation occurs all the time - I'm at a loss :confused:
 
I finally took a look at my slow boot related problems this morning. There were a few other services that were either not installed, or not needed by me. So I've removed those packages and ensured that the systemd configs were cleared out properly too.

Finally getting acceptable boot times again!
2020-05-20-140007_746x760_scrot.png

Much better than the 2-3 minutes it took before!
 
I don't dual or multiboot, I used to in the past but not in the last 5-6 years, I think. If I need/want something from some other distro/OS I just create a VM and that's easier. I know it's not the same but it serves my purposes. So, when I said that I use the defaults I meant not choosing manual partition but let the installer do that for me, which I'm aware it's not an option if dual or multibooting.

Maybe, don't know. When you manually create the partitions, do you create one swap for each OS/distro or do they share the same one? Just curious. I'll try to do some "multiboot VM" to see whether the issue appears or not and let you know how that went.
I create a swap partition for each distro.
 
I’ve had Debian on my laptop since before systemd was introduced. As soon as systemd was added, it considerably increased boot times. It used to boot really quickly. Since systemd - startup took up to two or three minutes!

From what I remember the last time I started to look at it - the system was waiting for particular services to start. Some of which were services I wasn’t using and didn’t even have installed. So I hacked my systemd configs to remove all references to things I don’t use. That has helped a bit. Hasn’t sped things up much though.
I just haven’t had the time, or the inclination to try to investigate it properly.

But systemd is definitely a factor. Whether it’s systemd itself, or the way that Debian configures it - IDK.

I’ve just put up with the increased boot times. I don’t often shut down anyway. I normally just close the lid and hibernate/suspend my machine instead nowadays. Then when I open the lid - it comes back in seconds!
Very good information, thanks.

You confirmed what I had thought that systemd is playing a role in the boot up process.
I'll look when I have more time if there is a way to give commands to systemd to stop or slow this down.
 
If a user wants systemd free there's Antix Linux and MX Linux and both are Debian base and rock solid OOTB.
I think Devuan is systemd free too.
I'll check out Antix Linux when I have some time.
Thanks-
 
I finally took a look at my slow boot related problems this morning. There were a few other services that were either not installed, or not needed by me. So I've removed those packages and ensured that the systemd configs were cleared out properly too.

Finally getting acceptable boot times again!
View attachment 6309
Much better than the 2-3 minutes it took before!
I've got a longer boot up in Mint:

~$ systemd-analyze
Startup finished in 4.806s (kernel) + 3min 341ms (userspace) = 3min 5.147s
graphical.target reached after 1min 30.494s in userspace

How do I change that?
 
I've got a longer boot up in Mint:

~$ systemd-analyze
Startup finished in 4.806s (kernel) + 3min 341ms (userspace) = 3min 5.147s
graphical.target reached after 1min 30.494s in userspace

How do I change that?
Wow!

Linux Mint anything from my experience has always and still is a slow booting Linux distro.

I've never seen any OS take 3 minutes to boot up. o_O
 
Wow!

Linux Mint anything from my experience has always and still is a slow booting Linux distro.

I've never seen any OS take 3 minutes to boot up. o_O
I really don't want to get rid of Mint because it's been very stable.

How long does your Mint take to boot?
 
My LM boots in under 40 seconds.......up, running and ready for action

Dont be in too much of a hurry to dispense with Linux Mint

It will still be around when some of the "come latelys" have long disappeared
 
My LM boots in under 40 seconds.......up, running and ready for action

Dont be in too much of a hurry to dispense with Linux Mint

It will still be around when some of the "come latelys" have long disappeared
I'm keeping Mint for sure.
I just wish I knew how to reduce the boot up time.

Any suggestions where to begin?
 
Code:
john@john-desktop:~$ systemd-analyze
Startup finished in 11.614s (firmware) + 5.557s (loader) + 2.708s (kernel) + 9.643s (userspace) = 29.523s
graphical.target reached after 9.636s in userspace
And some will consider that slow.
 
I'm keeping Mint for sure.
I just wish I knew how to reduce the boot up time.

Any suggestions where to begin?
Start with
Code:
systemd-analyze blame
 

Members online


Top