I just converted my laptop from an HDD to an SSD, and while I was at it I upgraded from 18.2 to 19.1. But even with the new and much faster benching drive, it doesn't seem to be any faster to boot.
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason:Topic automatically closed 6 months after creation. New replies are no longer allowed.
My Core 2 Duo at 3GHz needs 3.5s for kernel; yes, definitively something wrong there. Browse through dmesg | less and specifically look for the spot where the time stamp at the beginning of the line jumps. I'd expect that would provide for the needed hint. USB perhaps?
No time between the btrfs message and mounting of / for me. No, swap is not the issue for you. Was the SSD you upgraded to completely new? Even if so I once encountered same/similar with a new Intel 120G SSD: it needed a full, "secure" erase to restore it to full working condition and speed.
You can do so with Linux but if you have a possibility to hook it up to a Windows system as a secondary drive you can use the manufacturer tool; will also allow you to check for updated firmware....
The SSD is a brand new Samsung 860 EVO 1TB. System is dual boot Windows/Linux. I'll boot into WIndows and see if there's a firmware update
EDIT: No firmware update, there was something about "rapid mode" in there. Didn't seem to help much. Booting into Windows is mighty quick, though I know how they accomplish that.
Assuming that won't help (good idea regardless...) it does seem your swap partition may be involved. The delay is a bit too neatly 30 seconds; sounds like a possible issue with the initramfs attempting to resume from a non-existing swap device.
Assuming you still have a swap partition, do the UUID's in RESUME= of /etc/initramfs-tools/conf.d/resume and the output of blkid match? If not, try updating the former manually, if yes or if no current swap partition, make it be "RESUME=none". Then run sudo update-initramfs -u -k all and reboot to test.
It seems they don't. I set it to "none" and that sped things up considerably. Since I don't have the option to hibernate, is there a reason to have it look for a swap to resume from?
a.bowers wrote: ⤴Fri Dec 21, 2018 11:04 am
Since I don't have the option to hibernate, is there a reason to have it look for a swap to resume from?
Not having the option is somewhat relative (it's not hard to re-enable) but otherwise, no. Still, seeing as how you do still have a bona fide swap partition I'd plug in the UUID manually anyway even if only so as to have things standard:
When I was testing Mint 19 I noticed that if I booted off the ISO on a USB drive boot time was fast as 18.3 Once I would install the ISO to a harddrive is where I got the long boot times? This is the reason I gave up on Mint 19 (All desktops)
That pared it down a bit: Startup finished in 3.412s (firmware) + 11.749s (loader) + 12.304s (kernel) + 8.471s (userspace) = 35.938s
graphical.target reached after 8.285s in userspace
Yes, that seems a definite further issue. 5 seconds where they should be none. What I'd try first of all is move the receiver to a different port (physically, and if applicable, USB2 to USB3 or vice versa). If nothing, try a different mouse. I nothing, look in the BIOS settings for anything USB related. It's not a common issue at the very least so can't be more to the point directly.
Once those 5 seconds are gone we're at 7 seconds and that would be the point I'd ask for output of inxi -Fxz to decide whether or not it's now looking to be okay...
did it for me. It had a reference to a UUID that didn't exist, possibly because the swap partition on my system existed from when I insalled 18, then I did the fresh install to LM 19.1. I edited the file and changed the UUID to that of my swap partition and boot times reduced from 45s back down to 10s.
Swapping the unifying transceiver to another port sped things up considerably. We're now talking about 4.7 seconds for the kernel. I wonder if I could trim a little more speed off by ditching the transceiver entirely and using the mouse in Bluetooth mode. Not really going to bother though.
I also managed to fix an unrelated problem: When I'm at home, I use this laptop with dual monitors. It's only got one HDMI out port, but I have a DisplayLink USB dock. In 18.2, it seemed to work best with one monitor plugged into the laptop via HDMI, and the other via DVI on the dock. Suddenly in 19.1, if I was multitasking at all (CAD on one monitor, Youtube on another) I got horrendous mouse cursor flicker. Now I've plugged both monitors into the DisplayLink dock, and it's working fine. *shrug* Isn't USB3 astonishing?
