3

I updated from Ubuntu 20.04 to 22.04 and login went up from almost instantly in Ubuntu 20 to 2.5 minutes in Ubuntu 22!!!

Booting takes longer as well (appr. 50 secs.) Normally all start-up text races by, but now the following text stays on screen for about 20 secs.

Running /scripts/local-premount

It's the user login that takes 2:15 where only my backdrop is visible.

I have a Asus P8Z77-V MB (some 10 yrs old). Processor Intel(R) Core(TM) i3-3225 CPU @ 3.30GHz

Memory 16066MB (3188MB used)

Kernel Linux 5.15.0-37-generic (x86_64) Version #39-Ubuntu SMP Wed Jun 1 19:16:45 UTC 2022

C Library GNU C Library / (Ubuntu GLIBC 2.35-0ubuntu3) 2.35

Distribution Ubuntu 22.04 LTS

Mesa Intel(R) HD Graphics 4000 (IVB GT2) Version 3.1 Mesa 22.0.1

I wanted to check logs, but don't know which and what to look for.

No NVidia card.

Any help appreciated.

Thanks

EDIT1

During 1st upgrade from 20.04 to 22.04 the installer stopped because I didn't have enough space on my / (root) partion (30GB).

I started a Live Linux version from an USB stick and used Gparted to resize the Ext4 root partition with an extra 30 GB. This went all without problems and so did the following update to 22.04.

I have the following partitions on my 128 GB SSD:

sda1 : fat32 /boot/efi 190MB

sda2 : ext4 /boot 572MB

sda3 : ext4 / 58.59GB (was appr. 30GB before resizing)

Furthermore 2 small data partitions:

sda4 : ext4 LUKS encrypted

sda5 : ext4 data

My home directory is on a 1TB standard harddrive (sdb)

Below I've included output from system-analyze

$ systemd-analyze
Startup finished in 2.717s (firmware) + 4.301s (loader) + 34.923s (kernel) + 6.285s (userspace) = 48.228s 
graphical.target reached after 6.278s in userspace

$ systemd-analyze blame 3.579s NetworkManager-wait-online.service 1.531s snapd.service 1.163s dev-sda3.device 998ms udisks2.service 940ms dev-loop12.device 939ms dev-loop13.device 939ms dev-loop11.device 939ms dev-loop10.device 935ms dev-loop8.device 935ms dev-loop9.device 933ms dev-loop15.device 929ms dev-loop14.device 829ms blueman-mechanism.service 762ms dev-loop1.device 761ms dev-loop4.device 760ms dev-loop5.device 760ms dev-loop7.device 742ms dev-loop3.device 730ms dev-loop6.device 710ms dev-loop2.device 687ms dev-loop0.device 672ms snapd.seeded.service 626ms smartmontools.service 574ms cups.service 543ms user@1000.service 502ms accounts-daemon.service 463ms networkd-dispatcher.service 421ms ModemManager.service 290ms systemd-resolved.service 260ms polkit.service 258ms systemd-journal-flush.service 242ms NetworkManager.service 242ms avahi-daemon.service 238ms systemd-timesyncd.service 203ms nginx.service 190ms systemd-rfkill.service 190ms gpu-manager.service 163ms thermald.service 160ms apparmor.service 159ms wpa_supplicant.service 159ms systemd-logind.service 156ms e2scrub_reap.service 150ms apport.service 149ms secureboot-db.service 141ms systemd-udev-trigger.service 135ms systemd-udevd.service 133ms grub-common.service 127ms colord.service 121ms snapd.apparmor.service 119ms alsa-restore.service 108ms rsyslog.service 107ms resolvconf-pull-resolved.service 105ms systemd-fsck@dev-mapper-fedora\x2dhome.service 104ms systemd-journald.service 104ms keyboard-setup.service 102ms lightdm.service 100ms upower.service 86ms lm-sensors.service 85ms lvm2-monitor.service 82ms lvm2-pvscan@8:18.service 82ms systemd-modules-load.service 73ms sys-kernel-tracing.mount 73ms sys-kernel-debug.mount 72ms dev-mqueue.mount 72ms dev-hugepages.mount 69ms modprobe@fuse.service 67ms kmod-static-nodes.service 65ms modprobe@drm.service 65ms modprobe@configfs.service 65ms snap-bare-5.mount 64ms virtualbox.service 62ms WiLiShare.mount 62ms snap-chromium-2000.mount

  • I'd first start with creating a new login and seeing if the problem exists with that login. If it does not, then that might mean that there is some problem with your configuration files that are read when you login with your original ID. My solution is usually to erase them all -- because I don't have the patience to find out which one is the cause... But you can could try figuring out what's causing it. – Ray Jun 13 '22 at 16:53
  • @Ray That did not work. I made a new account/user, logged out of my own account and logged in with the new account. Same story: 2min 15 seconds waiting... – lostinlinux Jun 13 '22 at 17:19
  • To confirm boot. Please copy & paste the pastebin link to the Bootinfo summary report ( do not post report), do not run the auto fix till reviewed.Lets see details, use ppa version with your USB installer (2nd option) or any working install, not Boot-Repair ISO https://help.ubuntu.com/community/Boot-Repair But issue may be after grub loads. Post: systemd-analyze and first page of: systemd-analyze blame Review these settings: https://askubuntu.com/questions/1284302/is-it-possible-to-make-ubuntu-20-04-boot-faster – oldfred Jun 13 '22 at 17:40
  • @oldfred Your remarks are a bit cryptic for noob, but I think I have the info you asked for. https://paste.ubuntu.com/p/tC5WMMQ6w6/ I also editted my question to add info + systemd-analyze output. Thanks for your time – lostinlinux Jun 13 '22 at 18:52
  • It says you get to desktop in 6 sec. Not sure why kernel takes as long as it does, but not familiar with LVM/encryption which may be part of it. You can go thru settings in link in previous comment and maybe improve things slightly. Also mounting NTFS is always a bit slower, since Microsoft format You may want to add noatime to partitions mount in fstab for those on SSD. NTFS example: https://ubuntuforums.org/showthread.php?t=2420861&p=13865822#post13865822 – oldfred Jun 13 '22 at 19:12
  • @oldfred The first time login after upgrading, the encrypted partition wasn't there yet, but the long wait was there. So that can't be the problem. Yes I noticed the various tweeks, but they don't seem substantial (3 sec. for wait for network etc) – lostinlinux Jun 13 '22 at 19:16
  • So is the real question then, why does it take so long to decrypt my encrypted /home partition (or /)? I do not know encryption nor LVM. I might suggest that as a new question, so those that know encryption can offer answers. – oldfred Jun 13 '22 at 22:17
  • @oldfred No, the question is NOT about encrypting, because the slow login also happened before I made this encrypted directory. When I mount this partition, it opens within seconds, no problem there. – lostinlinux Jun 14 '22 at 11:01
  • From Windows did you run chkdsk on the NTFS? – oldfred Jun 14 '22 at 14:18
  • Just saw in another thread a comment on UEFI settings. It reminded me that one of the first settings I change is to turn off network boot. Never will use it and do not want UEFI looking for network. – oldfred Jun 14 '22 at 14:41
  • Windows can not check a disk connected to a network is the msg from chkdsk, because I use the NTFS partition in Virtualbox... – lostinlinux Jun 14 '22 at 16:42
  • I just had this, and it turned out that it was happening because my monitor was plugged into the motherboard HDMI out rather than the GPU HDMI out.

    After swapping the cable, the minutes-long hang after logging in disappeared.

    – afarley Oct 08 '22 at 22:11

0 Answers0