42 seconds boot time. It seems to have taken maybe 10-15 seconds before.
I think I screwed something up. The time difference changed after I enlarged “/” partition and move swap. Swap was against the root partition, so I moved it first then enlarged the root ("/") partition.
easyt50@8300 ~ $ systemd-analyze
Startup finished in 36.485s (kernel) + 5.513s (userspace) = 41.999s
graphical.target reached after 5.509s in userspace
easyt50@8300 ~ $ systemd-analyze blame
Everything below this was less then 100ms.
I had problems enlarging the root partition using gparted but got it done. Did not doc my steps, so I can not answer details about problems.
This getting a bit long, but other info I can add is fstab
/etc/fstab: static file system information.
‘#’ Use ‘blkid’ to print the universally unique identifier for a
'#'device; this may be used with UUID= as a more robust way to name devices
‘#’ that works even if disks are added and removed. See fstab(5).
‘#’/ was on /dev/sda8 during installation
UUID=da6ec12c-c8bb-4132-8157-bd77d62721d1 / ext4 errors=remount-ro 0 1
‘#’/home was on /dev/sda6 during installation
UUID=0af7ea4c-9721-49b3-afa7-912c27c9d4cc /home ext4 defaults 0 2
'#'swap now on /dev/sda8
UUID=8c42de44-5d68-466e-93e3-9a9b342905b3 none swap sw 0 0
'#'swap was on /dev/sda9 during installation
'#“UUID=455eee28-2ab3-4fc0-895d-4035700b40c4 none swap sw 0 0
Swap was not updated after I did the move, so I updated to the correct /dev/sda. This did seem to help with the boot time. I place ‘’ around '#” b/c it enlarged the print.
I also tried to run fsck. When I got the grub menu, I went into recovery mode and used fsck. I got back.
“fsck from util-linux 2.31.1”
“dev/sda6 is mounted”
“e2fsck: Cannot continue, aborting”
“Finish, please press enter.”
Now the good news - after the boot, everything seems to be running fine.
So I am worry about 3 things.
Why the long boot time?
Why fsck will not run?
Even tho system seems fine, am I sitting on a time bomb? ie: when the system goes to use the expanded area.
without output from systemd-analyze (especially blame) from before your reconfiguration it will be hard to figure out what the difference really is even though it might seem a bit longer. your time is similar to mine (36.982s) on a system with a decent i5 processor, 8 gb of ram and an ssd.
I would speculate that Linux had to get to know and chat with the new partitions, before it felt it was right to boot from them. I can’t tell you for sure, though.
My speculation is based on the fact, that the boot time was mainly influenced by the kernel.
Yes, w/o before boot times documented, it just a feeling I have. Found this neat program while looking up my system info. ‘sudo apt install sysinfo’
My desktop which is taking 42 sec to boot is a i5-3570 CPU @ 3.40GHz, 8 gigs of ram, and running Mint 19.1.
My laptop takes 7 seconds to boot. It is a i5-2520M CPU @ 2.50GHz, 6 gigs of ram, Mint 18.3.
Both system are booting off a SSD. I suppose that as long as the PC is running well, I should not complain about boot time. It just seem so different.
Yes, it looks odd… LOL. They are comment tho.
After the install, I removed 2 partitions by combining them into 2 other partitions and moved swap.
This is how it looks now.
From fdisk -l;
/dev/sda6 275259392 339111935 63852544 30.5G 83 Linux
/dev/sda7 339113984 460470271 121356288 57.9G 83 Linux
/dev/sda8 460472320 468860927 8388608 4G 82 Linux swap / Solaris
if you are concerned about swap, you could run free -m or swapon --show to make sure it is mounting correctly.
dmesg -H --level=err can give you a look at system errors that have been reported. lnav /var/log will give you a very comprehensive view of all of your system logs. i like lnav because it shows errors (you can jump to past errors with shift + e and then forward with just e. same with w for warnings) and warnings in red and yellow (respectively) and makes them easier to spot. i’m pretty sure i had to install that in mint with sudo apt install lnav.
out of curiosity i tried that and got the same “drive is mounted. aborting” message as you. i did notice the following in the instructions which i didn’t follow that might have affected my run:
Running fsck in rescue mode requires few more steps. First prepare your system for reboot . Stop any critical services like MySQL/MariaDB etc and then type.
if you’re still interested in running fsck on your drive, that should be easy enough from a live usb.
Thanks for the info.
Wow! lnav command does provide a lot of information.
I suppose every error (red line) should be looked into. I have a few starting with the boot.
“tpm tpm0: A TPM error (7) occurred attempting to read a pcr value” which seems to happen on every boot. Maybe it is not a critical error.
looks like i didn’t bookmark that find after all a few different fixes popped up when i did a search just now. the arch wiki links it to the trusted platform module which is what i remember from looking into this before.
It happen again! Increasing the size of root (/) and boot time increase 10 fold!
Is this a problem worth reporting to the Linux team?
Has anyone else had this happen to them using Linux Mint Cinnamon 18 or 19?
I moved swap and expanded root. I started down your check list with swapon --show and got no response. So, as you suggested I check the UUID’s and swap was incorrect in fstab. I updated it and re-booted. Now systemd shows 28 seconds boot time!