升级Ubuntu 23.10后登录界面用户名列表延迟显示及GNOME Shell GC报错问题求助

大家好，我刚把Ubuntu从23.04升级到23.10，遇到了一个非常头疼的问题：登录界面的用户名列表要等足足五分钟才会显示出来，而且这段时间里按Ctrl+Alt+功能键也没法调出终端，完全没法操作。

等系统终于能登录后，我查看系统日志，发现里面塞满了几十万条一模一样的错误信息，内容如下：

okt 16 19:28:29 mba-ubuntu gnome-shell[2255]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused >
The offending signal was g-properties-changed on GDBusProxy 0x559a9b5b4b10.

== Stack trace for context 0x559a98c843f0 ==

#0   559a98d4b8f8 i   resource:///org/gnome/shell/ui/init.js:21 (35b912170ba0 @ 48)

我不确定是什么原因导致了这个延迟，虽然隐约有个猜测但没法确定。现在想问问大家，我该怎么解决这个问题？我已经检查过了，系统没有待更新的内容，是不是需要重装某些组件？如果是的话，应该重装哪些呢？

更新1：systemd-analyze 输出 #

按照建议，我运行了systemd-analyze blame，输出结果如下：

38.918s plymouth-quit-wait.service
4.081s systemd-udev-settle.service
3.504s NetworkManager-wait-online.service
2.600s zfs-load-module.service
2.091s fwupd.service
1.826s docker.service
1.380s dev-sda3.device
1.067s NetworkManager.service
894ms snapd.service
867ms apport.service
782ms udisks2.service
688ms accounts-daemon.service
626ms iio-sensor-proxy.service
620ms boot-efi.mount
612ms power-profiles-daemon.service
585ms polkit.service
473ms e2scrub_reap.service
459ms bluetooth.service
455ms systemd-logind.service
423ms upower.service
407ms smbd.service
365ms switcheroo-control.service
351ms systemd-udev-trigger.service
337ms nmbd.service
335ms user@1000.service
334ms containerd.service
302ms gpu-manager.service
290ms systemd-resolved.service
282ms ModemManager.service
274ms rsyslog.service
268ms apparmor.service
263ms systemd-udevd.service
238ms snapd.seeded.service
234ms keyboard-setup.service
231ms systemd-journald.service
223ms packagekit.service
223ms systemd-backlight@backlight:acpi_video0.service
212ms avahi-daemon.service
210ms systemd-timesyncd.service
209ms systemd-oomd.service
201ms bolt.service
181ms smartmontools.service
161ms samba-ad-dc.service
159ms update-notifier-download.service
158ms dbus.service
155ms systemd-modules-load.service
153ms gdm.service
140ms zfs-volume-wait.service
135ms cups.service
134ms modprobe@drm.service
129ms thermald.service
128ms snap-bare-5.mount
126ms snap-code-142.mount
124ms snap-code-143.mount
121ms snap-core-16091.mount
120ms systemd-fsck@dev-disk-by\x2duuid-67E3\x2d17ED.service
119ms snap-core-16202.mount
116ms snap-core18-2785.mount
114ms snap-core18-2790.mount
111ms snap-core20-1974.mount
110ms systemd-journal-flush.service
110ms snap-core20-2015.mount
107ms snap-core22-817.mount
105ms snap-core22-864.mount
102ms grub-common.service
101ms snap-firefox-3252.mount
99ms snap-gnome\x2d3\x2d38\x2d2004-140.mount
96ms snap-gnome\x2d3\x2d38\x2d2004-143.mount
96ms snapd.apparmor.service
94ms snap-gnome\x2d42\x2d2204-132.mount
91ms snap-gnome\x2d42\x2d2204-141.mount
88ms snap-gtk\x2dcommon\x2dthemes-1534.mount
86ms snap-gtk\x2dcommon\x2dthemes-1535.mount
83ms snap-snap\x2dstore-1046.mount
80ms snap-snap\x2dstore-959.mount
78ms snap-snapd-20092.mount
75ms snap-snapd-20290.mount
72ms snap-youtube\x2ddl-4630.mount
66ms systemd-sysusers.service
65ms snap-youtube\x2ddl-4806.mount
64ms systemd-rfkill.service
64ms kerneloops.service
61ms mnt-Windows.mount
59ms systemd-tmpfiles-setup.service
57ms ubuntu-fan.service
54ms systemd-binfmt.service
54ms var-snap-firefox-common-host\x2dhunspell.mount
53ms systemd-remount-fs.service
50ms systemd-random-seed.service
50ms systemd-tmpfiles-setup-dev.service
46ms dev-loop10.device
44ms dev-hugepages.mount
43ms dev-mqueue.mount
42ms sys-kernel-debug.mount
40ms sys-kernel-tracing.mount
39ms docker.socket
39ms colord.service
39ms dev-loop13.device
39ms dev-loop18.device
39ms dev-loop12.device
36ms dev-loop21.device
36ms dev-loop14.device
36ms dev-loop20.device
36ms dev-loop17.device
35ms dev-loop9.device
35ms dev-loop8.device
34ms kmod-static-nodes.service
34ms modprobe@configfs.service
34ms dev-loop11.device
34ms dev-loop15.device
33ms user-runtime-dir@1000.service
32ms systemd-sysctl.service
32ms flatpak-system-helper.service
31ms dev-loop16.device
30ms systemd-update-utmp.service
28ms dev-loop23.device
28ms dev-loop19.device
28ms modprobe@fuse.service
26ms console-setup.service
26ms proc-sys-fs-binfmt_misc.mount
26ms systemd-backlight@leds:smc::kbd_backlight.service
25ms plymouth-read-write.service
24ms plymouth-start.service
24ms dev-loop22.device
24ms alsa-restore.service
21ms wpa_supplicant.service
18ms ufw.service
16ms systemd-user-sessions.service
15ms snap.mount
13ms grub-initrd-fallback.service
12ms openvpn.service
11ms systemd-update-utmp-runlevel.service
10ms zfs-mount.service
10ms zfs-share.service
10ms sys-kernel-config.mount
6ms modprobe@dm_mod.service
6ms snapd.socket
6ms modprobe@loop.service
5ms modprobe@efi_pstore.service
5ms rtkit-daemon.service
4ms sys-fs-fuse-connections.mount
4ms setvtrgb.service

更新2：日志细节 #

我进一步查看日志，发现问题似乎和背光OSD（屏幕显示）有关——日志里几十万条GNOME Shell警告的第一条就提到了背光相关内容。之前我就遇到过调整背光到60%以下时，OSD会冻结的问题，现在看来这两个问题可能有关联？即使我没调整背光，日志里还是不断出现背光相关的报错。部分日志内容如下：

okt 23 12:44:38 mba-ubuntu gnome-shell[1098]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.

The offending signal was notify on Gjs_status_backlight_SliderItem 0x55faf54481a0.

== Stack trace for context 0x55faf3327670 ==

#0   7ffe7f1ec450 I   resource:///org/gnome/shell/ui/status/backlight.js:57 (1b0e2428e70 @ 131)
#1   7ffe7f1ecfa0 b   resource:///org/gnome/gjs/modules/core/overrides/GObject.js:687 (2ff9c29bec0 @ 25)
#2   7ffe7f1ecfe0 I   resource:///org/gnome/shell/ui/status/backlight.js:197 (1b0e242c420 @ 199)
#3   7ffe7f1ed010 I   resource:///org/gnome/shell/ui/status/backlight.js:157 (1b0e242c2e0 @ 12)
#4   55faf33ef898 i   resource:///org/gnome/shell/ui/init.js:21 (2ff9c270ba0 @ 48)

okt 23 12:44:38 mba-ubuntu gnome-shell[1098]: Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destroy signal connected, or using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked.

The offending callback was AsyncReadyCallback().

== Stack trace for context 0x55faf3327670 ==

#0   55faf33ef898 i   resource:///org/gnome/shell/ui/init.js:21 (2ff9c270ba0 @ 48)

okt 23 12:44:38 mba-ubuntu gnome-shell[1098]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.

The offending signal was g-properties-changed on GDBusProxy 0x55faf54439f0.

== Stack trace for context 0x55faf3327670 ==

#0   55faf33ef898 i   resource:///org/gnome/shell/ui/init.js:21 (2ff9c270ba0 @ 48)

...

现在还是希望能找到解决这个登录延迟和GC报错的办法，麻烦大家给点建议！

备注：内容来源于stack exchange，提问作者Andreas