0

Checked on many places, and no solution satisfied me, so giving out the info I believe that should help to know the issue. Thanks in advanced:

$systemd-analyze Startup finished in 4.424s (firmware) + 12.586s (loader) + 5.492s (kernel) + 1min 48.756s (userspace) = 2min 11.260s graphical.target reached after 1min 48.715s in userspace

blkid /dev/sda4: UUID="ae29f117-c886-49b1-93ef-d2a77666ef62" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3bfaca8c-c4ea-4232-bd3f-00cfbc837627"

cat /etc/fstab

/ was on /dev/sda4 during installation UUID=ae29f117-c886-49b1-93ef-d2a77666ef62 / ext4 errors=remount-ro 0 1

/boot/efi was on /dev/nvme0n1p1 during installation UUID=58FA-8640 /boot/efi vfat umask=0077 0 1

swap was on /dev/sda2 during installation UUID=d65012d0-ebd9-4bf9-ae69-9e2ec6978b5a none swap sw 0 0

EDIT

A couple of more information pieces:

$systemd-analyze blame only the services with more than a second time

17.535s plymouth-quit-wait.service
10.743s gpu-manager.service
 4.658s NetworkManager-wait-online.service
 1.744s dev-sda4.device

$systemd-analyze critical-chain

graphical.target @1min 48.618s
└─multi-user.target @1min 48.618s
  └─plymouth-quit-wait.service @1min 31.079s +17.535s
    └─systemd-user-sessions.service @1min 30.975s +44ms
      └─network.target @1min 30.921s
        └─NetworkManager.service @1min 30.564s +350ms
          └─dbus.service @1min 30.560s
            └─basic.target @1min 30.550s
              └─sockets.target @1min 30.550s
                └─snapd.socket @1min 30.549s +790us
                  └─sysinit.target @1min 30.541s
                    └─snapd.apparmor.service @2.137s +511ms
                      └─apparmor.service @1.670s +416ms
                        └─local-fs.target @1.622s
                          └─run-snapd-ns-snapd\x2ddesktop\x2dintegration.mnt.mount @1min 42.792s
                            └─run-snapd-ns.mount @1min 42.333s
                              └─local-fs-pre.target @624ms
                                └─keyboard-setup.service @457ms +166ms
                                  └─systemd-journald.socket @448ms
                                    └─system.slice @444ms
                                      └─-.slice @444ms

6
  • 1min 48.756s (userspace) – Look at systemd-analyze blame and systemd-analyze critical-chain to see what's taking so long. Then use sudo apt purge ... and sudo systemctl disable ... to remove and disable services you don't need or care about. If it's a spinning platter HDD, there's a limit to how much you can speed it up, but 2min is pretty excessive.
    – xiota
    Nov 22, 2022 at 10:43
  • @xiota if it was an hdd, I would understand it, but not a lot. However, it is a ssd, dual boot, though Nov 22, 2022 at 10:58
  • Please sudo systemd-analyze plot > /tmp/bootup.svg and upload it somewhere. Also you could scroll through journalctl -b output and try finding stuff which takes a lot of time. Nov 22, 2022 at 11:56
  • @ArtemS.Tashkinov I don't know what is this, but github.com/chelmi00/shared_files/blob/… Nov 22, 2022 at 12:29
  • Your system seemingly boots in around 7 seconds and then starts waiting for something, only I've no idea what. What does happen if you boot with systemd.unit=multi-user.target? If it boots in ~7 seconds, you might have issues with KDM/SDDM. Nov 22, 2022 at 14:20

1 Answer 1

-1

I checked while booting, pressed F10, and there appeared "A start job is running for /dev/disk/by-uuid/d65012d0... (53s / 1min 30s)"

This meant that it is searching for a disk with the uuid starting with d65012d0, but it isn't there.

Solution

Your uuid will most likely be different. However, I'm giving you my solution, you can apply it by changing the uuid.

Output cat /etc/fstab and check which file system is the one with the uuid d65012d0... Afterwards, check on gparted or disks and find the partition that corresponds with the file system, in my case it was swap. Copy the uuid corresponding with the partition, and paste it instead of the one in /etc/fstab

If a graphical explanation is needed: https://www.youtube.com/watch?v=h23oQr8Nvqc

1
  • Unfortunately, as it stands, your answer will not help other users since you specify a UUID of a file system. The properties of UUIDs include that they are Unique -- which means no one else, all across the world, will have the UUID you are seeing. I suggest specifying the file system more generally, and rephrase the answer to be more generic.
    – jstarek
    Nov 22, 2022 at 20:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .