Ubuntu 20.04 slow boot issue

Question

After experimenting with some suggested remedies to similar boot issues in the forum, my hp pavilion g4 notebook (i5, 4GB RAM) (Windows+Ubuntu 20.04 LTS desktop dual boot) took much longer time to boot.

The following is a result of systemd-analyze critical-chain command.

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @2min 25.876s
└─multi-user.target @2min 25.875s
  └─kerneloops.service @37.747s +55ms
    └─network-online.target @37.711s
      └─NetworkManager-wait-online.service @25.803s +11.905s
        └─NetworkManager.service @20.934s +4.866s
          └─dbus.service @20.928s
            └─basic.target @20.885s
              └─sockets.target @20.885s
                └─snapd.socket @20.884s +973us
                  └─sysinit.target @20.754s
                    └─snapd.apparmor.service @20.096s +657ms
                      └─apparmor.service @19.350s +743ms
                        └─local-fs.target @19.349s
                          └─run-user-125.mount @1min 9.857s
                            └─swap.target @18.940s
                              └─dev-disk-by\x2duuid-a914a306\x2df035\x2d4689\x2>
                                └─dev-sda10.device @18.799s

Another reading after an update gives

graphical.target @4min 41.087s
└─multi-user.target @4min 41.087s
  └─snapd.seeded.service @2min 10.410s +192ms
    └─snapd.service @1min 38.321s +32.083s
      └─basic.target @1min 38.060s
        └─sockets.target @1min 38.060s
          └─snapd.socket @1min 38.058s +1ms
            └─sysinit.target @1min 37.932s
              └─snapd.apparmor.service @1min 35.399s +2.533s
                └─apparmor.service @1min 34.569s +828ms
                  └─local-fs.target @1min 34.568s
                    └─run-user-125.mount @2min 29.511s
                      └─swap.target @1min 32.223s
                        └─dev-disk-by\x2duuid-a914a306\x2df035\x2d4689\x2da00c\>
                          └─dev-disk-by\x2duuid-a914a306\x2df035\x2d4689\x2da00

I suspect a possible graphic card error (hybrid intel+radeon) as I could see many error against [radeon] during startup.

Any suggestion/help in this regard is highly needed. Thanks!

Edits

After disabling snap as suggested by @kanehekili, the boot did better.

graphical.target @58.062s
└─multi-user.target @58.062s
  └─networkd-dispatcher.service @18.226s +13.683s
    └─basic.target @18.167s
      └─sockets.target @18.167s
        └─uuidd.socket @18.167s
          └─sysinit.target @17.777s
            └─systemd-timesyncd.service @17.257s +519ms
              └─systemd-tmpfiles-setup.service @16.868s +322ms
                └─systemd-journal-flush.service @4.667s +12.200s
                  └─systemd-journald.service @3.251s +1.410s
                    └─systemd-journald.socket @3.230s
                      └─-.mount @3.209s
                        └─system.slice @3.209s
                          └─-.slice @3.209s

and $ dmesg gives a lot less red colors than when I did during my post in the comments!

P.S. I recently installed sagemath.

Answer 1

I had a similar problem with Ubuntu 20.04 starting slowly.
In the /etc/fstab file there were invalid entries about the partition, especially SWAP. This was due to, for example, having changed the partition setting after installing a new system.

They need to be corrected so that there is something similar:

# / 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).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on / dev / sdb2 during installation
UUID = f712dfe1-dfa2-48b1-af05-027eedf6j3c / ext4 errors = remount-ro 0 1
# swap was on / dev / sda2 during installation
UUID = 10ff2eec-b9ed-42ff-9ec4-1f534ek692e2 none swap sw 0 0

---

Partition numbers can be found e.g. by running the disk application (gnome-disk-utility).