Noob here, I managed to install 20.04 to an SSD, a Samsung 850 EVO 250Gb (mz-n5e250) however, I am getting a fairly long boot time compared to a standard ssd install. First of all, noticed that during install it detected the m.2 as /dev/sdd instead of /dev/nvme...probably nothing, installation proceeded without issue. Now this is dual boot setup alongside Windows 10. Grub works fine and then it's a long wait...When I get to Ubuntu desktop I notice that in favourites I can see that root, efi and home are mounted as media, I haven't seen this before. Anyway, digging deeper the culprit appears to be udisks2:
sudo systemd-analyze blame:
32.803s udisks2.service 6.452s NetworkManager-wait-online.service 5.296s plymouth-quit-wait.service 563ms systemd-logind.service 559ms snap-gnome\x2d3\x2d34\x2d1804-33.mount 558ms snap-gtk\x2dcommon\x2dthemes-1506.mount 557ms snap-gnome\x2d3\x2d34\x2d1804-27.mount
and critical-chain:
graphical.target @34.045s
└─udisks2.service @1.241s +32.803s
└─basic.target @1.189s
└─sockets.target @1.189s
└─snapd.socket @1.188s +478us
└─sysinit.target @1.185s
└─systemd-timesyncd.service @894ms +290ms
└─systemd-tmpfiles-setup.service @867ms +25ms
└─local-fs.target @863ms
└─run-user-1000-gvfs.mount @22.329s
└─run-user-1000.mount @22.182s
└─swap.target @815ms
└─dev-disk-by\x2duuid-3f951984\x2d35cf\x2d4e0d\x2d8dee\x2d072d2f4c8d66.swap @767ms +47ms
└─dev-disk-by\x2duuid-3f951984\x2d35cf\x2d4e0d\x2d8dee\x2d072d2f4c8d66.device @759ms
So, I checked fstab thinking something might be amiss:
# <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sdd1 during installation UUID=2ac96265-f633-42a7-8ab4-5f3f4a9065ec / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/sda2 during installation UUID=6AE9-5D89 /boot/efi vfat umask=0077 0 1 # /home was on /dev/sdd3 during installation UUID=8e1a5a66-e062-42cd-bf93-2042e61dd9ba /home ext4 defaults 0 2 # swap was on /dev/sdd2 during installation UUID=3f951984-35cf-4e0d-8dee-072d2f4c8d66 none swap sw 0 0
compared it to blkid:
/dev/sdd2: UUID="3f951984-35cf-4e0d-8dee-072d2f4c8d66" TYPE="swap" PARTUUID="90c89aee-5a06-4d7b-b292-45ea9a1bf90b" /dev/sdd1: UUID="2ac96265-f633-42a7-8ab4-5f3f4a9065ec" TYPE="ext4" PARTUUID="6a78d7fe-ebdf-44c4-9839-58bd1d3435a2" /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/loop7: TYPE="squashfs" /dev/sda1: LABEL="Recovery" UUID="0294E89394E88A8D" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="166342dd-a166-4598-b639-ac44b12e1ffe" /dev/sda2: UUID="6AE9-5D89" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="9218c53d-42bd-4ca3-b222-e6fa7d52378f" /dev/sda4: UUID="84C2F292C2F28826" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="5889556a-909f-4410-a177-30cb5b843280" /dev/sdc2: LABEL="Data" UUID="ACF4143FF4140DE8" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="981bc30b-aedb-4269-814b-b768667d4dde" /dev/sdd3: UUID="8e1a5a66-e062-42cd-bf93-2042e61dd9ba" TYPE="ext4" PARTUUID="ff33cea9-5f9a-476a-b2b4-a3d2da50e67e" /dev/loop8: TYPE="squashfs" /dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="b488c487-f54f-4f7f-a144-18e91e01efbc" /dev/sdc1: PARTLABEL="Microsoft reserved partition" PARTUUID="1b884629-3787-4cab-a008-1f3de408c226"
So, everything looks okay (as far as I can tell).
I ran 'sudo cat /var/log/syslog | grep -i udisks2':
May 7 10:56:51 ollie-MS-7B87 dbus-daemon[1103]: [session uid=125 pid=1103] Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' unit='gvfs-udisks2-volume-monitor.service' requested by ':1.2' (uid=125 pid=1097 comm="/usr/libexec/tracker-miner-fs " label="unconfined") May 7 10:56:51 ollie-MS-7B87 dbus-daemon[900]: [system] Activating via systemd: service name='org.freedesktop.UDisks2' unit='udisks2.service' requested by ':1.27' (uid=125 pid=1119 comm="/usr/libexec/gvfs-udisks2-volume-monitor " label="unconfined") May 7 10:57:11 ollie-MS-7B87 dbus-daemon[1472]: [session uid=1000 pid=1472] Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' unit='gvfs-udisks2-volume-monitor.service' requested by ':1.1' (uid=1000 pid=1467 comm="/usr/libexec/tracker-miner-fs " label="unconfined") May 7 10:57:16 ollie-MS-7B87 gvfs-udisks2-vo[1517]: monitor says it's not supported May 7 10:57:16 ollie-MS-7B87 gvfs-udisks2-vo[1119]: monitor says it's not supported May 7 10:57:16 ollie-MS-7B87 dbus-daemon[1472]: [session uid=1000 pid=1472] Successfully activated service 'org.gtk.vfs.UDisks2VolumeMonitor' May 7 10:57:16 ollie-MS-7B87 dbus-daemon[1103]: [session uid=125 pid=1103] Successfully activated service 'org.gtk.vfs.UDisks2VolumeMonitor' May 7 10:57:16 ollie-MS-7B87 gvfs-udisks2-vo[1517]: monitor says it's not supported May 7 10:57:16 ollie-MS-7B87 gvfs-udisks2-vo[1517]: monitor says it's not supported May 7 10:57:16 ollie-MS-7B87 gvfs-udisks2-vo[1119]: monitor says it's not supported May 7 10:57:16 ollie-MS-7B87 tracker-miner-f[1467]: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported May 7 10:57:16 ollie-MS-7B87 gvfs-udisks2-vo[1119]: monitor says it's not supported May 7 10:57:16 ollie-MS-7B87 tracker-extract[1096]: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported May 7 10:57:16 ollie-MS-7B87 tracker-extract[1466]: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported May 7 10:57:16 ollie-MS-7B87 tracker-miner-f[1097]: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported May 7 10:57:23 ollie-MS-7B87 udisksd[942]: Acquired the name org.freedesktop.UDisks2 on the system message bus
I can confirm that issue is not confined to the m.2 but also an external ssd on a fresh install. udisks2 is freaking out again mounting /efi , /root and /home as media in the favourites bar. Guessing there is something in my system setup that Ubuntu doesn't particularly like.
