Ubuntu 20.04 LTS long boot time

I have a dual boot machine with Windows10 and Ubuntu 20.04 LTS 64bit

While my Windows’ 10 boot time is less than 40 seconds (and I am VERY satisfied since the machine has not SSD), Ubuntu takes 1:30min or 1:40…

Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz 8GB RAM
NVIDIA GTX 1050 (or 1060?)

Boot times:
Startup finished in 3.530s (firmware) + 5.219s (loader) + 5.936s (kernel) + 1min 34.092s (userspace) = 1min 48.778s
graphical.target reached after 1min 34.018s in userspace

1min 603ms plymouth-quit-wait.service
48.235s apt-daily.service
47.469s man-db.service
24.745s logrotate.service
22.798s snapd.service
18.610s systemd-journal-flush.service
14.783s udisks2.service
14.622s dev-sda4.device
11.743s accounts-daemon.service
10.018s user@125.service
9.829s apache2.service
8.215s snapd.seeded.service
6.938s avahi-daemon.service
6.928s bluetooth.service
6.921s NetworkManager.service
6.626s polkit.service
5.736s apport.service
5.705s dev-loop6.device
5.439s dev-loop5.device
5.073s dev-loop1.device
5.039s preload.service
4.878s grub-common.service
4.752s dev-loop2.device

graphical.target @1min 34.018s
└─multi-user.target @1min 34.018s
  └─snapd.seeded.service @50.488s +8.215s
    └─snapd.service @27.678s +22.798s
      └─basic.target @26.354s
        └─sockets.target @26.353s
          └─snapd.socket @26.348s +2ms
            └─sysinit.target @26.212s
              └─systemd-timesyncd.service @26.025s +187ms
                └─systemd-tmpfiles-setup.service @22.965s +2.913s
                  └─systemd-journal-flush.service @4.351s +18.610s
                    └─systemd-journald.service @3.610s +740ms
                      └─systemd-journald.socket @3.597s
                        └─system.slice @3.589s
                          └─-.slice @3.589s

About Snap… I need it because of Opera Browser. Only the Snap version is able to play some stream videos (there’s some issue about ffmpeg lib on deb version, and I have tried several workarounds without success).

This boot time is very frustrating… despite it’s not a SSD machine, I think it shouldn’t take this long since it is not a weak spec…

Edit: hope some UUID info helps

/dev/sda4: UUID="ac857efc-dd9f-460c-9097-a091798f1cc7" TYPE="ext4" PARTUUID="e5e4ec11-0286-4388-a8ac-08ae68725048"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/sda1: LABEL="SYSTEM" UUID="707B-9FD6" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="0db15783-b68f-4ae0-ad84-0f5e1d6219f3"
/dev/sda3: UUID="38CA7C5DCA7C1978" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="30d33950-ec3e-4054-a5c9-820d0f5bf11a"
/dev/sda5: UUID="f120d333-e539-4819-a178-65d55c80a8a0" TYPE="swap" PARTUUID="49378ee0-5d4d-4d6e-82b8-b4fd733567ad"
/dev/sda7: LABEL="SAMSUNG_REC2" UUID="2642CA7242CA45F1" TYPE="ntfs" PARTLABEL="M-fM-^UM-^RM-fM-=M-#M-fM-^UM-6M-gM-%M-2M-dM-^PM- M-gM-^QM-!a" PARTUUID="90b0ad13-0d1d-445c-b0b3-441ac8a73256"
/dev/sda8: LABEL="SAMSUNG_REC" UUID="9A80-070B" TYPE="vfat" PARTLABEL="M-fM-%M-^WM-fM-^QM-.M-gM-^)M-/M-bM-^AM-3M-dM-^UM-^P" PARTUUID="33e4ea88-a0af-41a5-4173-636c65706975"
/dev/sda2: PARTLABEL="Microsoft reserved partition" PARTUUID="cf98a95a-c00e-4f21-bf40-bb997f38d88d"
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=ac857efc-dd9f-460c-9097-a091798f1cc7 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=f120d333-e539-4819-a178-65d55c80a8a0  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0

Could it be some swap issue?