Hello guys,
It takes ages to boot MATE. A couple of days ago I used my windows laptop and installed MATE alongside it. So now the 17.04 MATE version runs alongside Windows 10. My laptop is a Lenovo T440s with a SSD and 4 gb ram, together with a i7-4600U CPU. While shutting down takes me about 3s, the time after the GRUB selection to the username-pwd-screen is about 2 and a half minutes. Does anyone have a guess what the problem could be?
Thanks in advance.
Suffice
Your startup time really is not all that slow.
Run systemd-analyze blame.
Here is a partial listing of mine.
systemd-analyze blame
4min 7.514s apt-daily.service
2min 14.316s apt-daily-upgrade.service
14.507s [email protected]:00-0000:00:13.2-usb2-2\x2d4.service
10.439s dev-sda1.device
Okay thanks. Thanks for quick reply.
You are most welcome.
I think this needs further review, - at the point where you’re waiting several minutes to boot up, - that is incredibly slow. More so given the fact the OP is running an SSD on an i7.
I wouldn’t take this as “oh that’s just how it is” because, it really isn’t. 
Let’s see if we can get some further analysis done by users to see what specifically could be causing your slow boot issues.
He needs to run systemd-analyze blame to see how long each item is taking.
You are right, a ssd should not be taking that long.
How long does a ssd typically take for a normal startup ?
I’m running a Samsung EVO 840, boot time is approx 14 seconds from machine power up to login. This is on an AMD A6-7400k chipset, which isn’t massively fast compared to the Intel i-series.
That’s impressive.
I thought about getting a ssd but do not like the fact that it has a shorter life than a platter drive.
My T410 with an aged i5 and an SSDHD needs roughly 15 secs to be up and running. I’d say there is something seriously wrong.
I’ve had that happen, but with a message saying “A start job is running for dev-disk-yada-yada-yada.” Turned out I had to re-create the swap partition with GParted.
The lifetime of an SSD, more so for brands like Samsung and Intel, are vastly underrated. My 840 is 1st gen, used every day, and several years later, still going strong.
Those are some good test results.
No, it is really slow. For example, my desktop, running Debian 9 with Openbox (system on hdd) boot really fast.
systemd-analyze shows 10.954s boot up time…
If I add up all elements after running “systemd-analyze blame”, it adds up to roughly 6.5 seconds which really doesn’t explain the 2 minutes it takes my computer to load…
Suffice can you try pressing the “Esc” during that boot up period so that you can see the boot messages, and see if there’s anything specific that it’s hanging on? Often you’ll have more clarity by seeing first-hand what’s going on than relying on systemd to try and work out what’s happening.
(If Esc doesn’t work, check to see if you have GRUB_CMDLINE_LINUX_DEFAULT=“splash” as an option in Grub)
If I press Esc during boot-up, all I see is a blank black screen. Also, it seems like I have GRUB_CMDLINE_LINUX_DEFAULT=“splash” as an option in Grub. Any further suggestions on the matter?
On your grub menu, jump to the OS you want to boot using the arrow keys, press the “e” key, which will allow you to edit your kernel parameters, and remove the lines for quiet and splash, this is only temporary and specific to that session only. It should allow you to see what’s going on, - failing that, it’ll be a dig through your log files for boot.
ISSUE SOLVED:
BrokenCanoe figured out that I had problems with my swap file/partition.
These lines from boot.log pointed towards the issue:
e[0;1;33mDEPENDe[0m] Dependency failed for Cryptography Setup for cryptswap1.
[e[0;1;33mDEPENDe[0m] Dependency failed for dev-mapper-cryptswap1.device.
[e[0;1;33mDEPENDe[0m] Dependency failed for /dev/mapper/cryptswap1.
[e[0;1;33mDEPENDe[0m] Dependency failed for Encrypted Volumes.
To solve the issue this is what I did:
I simply added a “#” to disable the respective lines mentioning crytswap from /etc/crypttab and /etc/fstab so that encrypted swap won’t be created during boot-up.
For those of you who have the same issue here is what you have to write into the terminal:
sudo pluma /etc/crypttab
sudo pluma /etc/fstab
Time for boot-up was then reduced for me from 1.38 minutes to 3 seconds.
Hope this helps and thanks to BrokenCanoe for his help once again!
Actually, I don’t think this is an optimal solution.
Correct me if I’m wrong, but I think you have now lost the ability to suspend your machine.
I have seen this issue in 17.10 Beta 1, and found the related bug report:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1670336
In my case in 17.10 the workaround I used was:
sudo nano /etc/crypttab
Replaced “UUID=XXX” with “/swapfile”, and then rebooted.
Agreed, - fully defer to Ouromov’s solution. I work off a pc and never suspend, just shut down, so this use-case hadn’t occured to me. Apologies.
Suffice, - completely your call on whether you replace the original solution with this one.