For me the icon is not missing, but it is replaced in the dock by what looks like perhaps a fallback: a cogwheel icon. I’m attaching a screenshot.

Hi Vinicius, thanks for looking into this!

I’ll have to postpone further testing until the next time there’s an issue, as my backups rely on the NAS (and it’s now back in operation with the nomodeset workaround). Taking it down is also physically fairly involved, as I prefer to unplug all the data drives, to spare them from repeated powercycling during testing.

However, I’m about 80 % sure I checked the journal for the failed suspends, and it just stopped there, resuming thereafter with just the boot messages from the next boot onward.

Also, I have TTY1 configured to display the journal ”live” (I’ll attach my /etc/systemd/system/getty@tty1.service.d/override.conf below), and I *did* try suspending with that TTY showing the journal (`sleep 5 && systemctl suspend` on TTY2, then switching to TTY1 before the timeout); I’ll attach a photo of that view when the suspend had resulted in this freezing issue.

Unfortunately I don’t have a cable to do debugging over a serial console.

I was able to work around this (in a test VM, after upgrading it from 20.04 to 24.04) with adapted instructions from a blogpost [1], by temporarily installing postgresql-14 from the PGDG repository for doing the 14 -> 16 upgrade:

# apt install postgresql-common
# /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
# apt install postgresql-14
# pg_dropcluster 16 main –stop
# pg_upgradecluster 14 main
# pg_dropcluster 14 main
# apt purge postgresql-14 postgresql-client-14
# rm /etc/apt/sources.list.d/pgdg.sources
# apt update

I have yet to try this on my actual server with actual data. Please be careful if you attempt this with a production database.

*[1] https://www.directedignorance.com/blog/upgrading-postgresql-14-to-16-on-ubuntu

== Summary ==
On my computer with an ancient Nvidia chipset (Geforce 7025/nForce 630a), running `sysctl suspend` (or suspending from the Gnome menu) causes the system to start suspending, but it freezes halfway, leaving fans and hard drives spinning. There’s no way to resume from this frozen state apart from forcing a reboot (with a hardware reset button/poweroff).

== Steps to reproduce ==
* boot with modeset enabled
* run `sysctl suspend`

== What I expect to happen ==
For the system to suspend, shutting down all fans and hard drives.

== What happens ==
The system begins to suspend, but freezes halfway, leaving the display on and fans and hard drives spinning, but the keyboard unresponsive.

== Workaround ==
Disable kernel modesetting by adding ”nomodeset” to the kernel commandline.

== Affected kernels ==
Prior to upgrades the system was running HWE kernel 5.15.0, so I tried the 5.15 series, and found that I could now suspend and wake the machine again just as before. I worked my way up the versions:

* 5.15.50: unaffected
* 5.15.165: unaffected
* 5.19.17: unaffected
* 6.4.0: unaffected
* 6.6.0: unaffected
* 6.6.48: unaffected
* 6.7.0: first to fail

I also tried the current newest mainline kernel 6.10.7, and the issue is still present there.

== Background ==
I have an old desktop machine now functioning as a NAS, and yesterday I upgraded it from Ubuntu 20.04 first to 22.04, and then all the way up to 24.04. The upgrade went smoothly, and this is the only issue I’ve come across since.

In the BIOS settings of the affected machine there are three ”suspend mode” alternatives to choose from: ”S1 (POS) only”, ”S3 only” and ”Auto”. I’ve always had it on ”Auto”, but with this issue I also tested both ”S1 only” and ”S3 only”, with no effect.

The issue is also present when booting from the installation media (USB) into a live environment.

I’ve previously upgraded my laptop to 24.04, and there suspending still works as it did before the ugprade, so this is probably hardware-specific; the laptop is a modern one with all-Intel hardware.

Googling around, I could smelled hints of this being once again related to the troublesome Nvidia chipset, so I tried nomodeset with the stock 6.8.0 kernel (6.8.0-41 currently) and voilà! Suspend and wake were working again.

Well, except for the display, which stayed black. But I couldn’t say if this was the way it was before, because the NAS is normally running headless.

== System information ==
Ubuntu 23.10, up to date before today’s updates.

== Steps to reproduce (WIP) ==
0. have a group of packages that are kept back from updating, plus some that aren’t (screenshot demonstration attached) below
1. open update-manager
2. (try to) open the kept group, click on their (unchecked) checkboxes
3. do the same for some of the other, non-kept packages
4. repeat 2.-3. for a while

== What happens ==
Update-manager becomes unresponsive, then eventually segfaults:

update-manager[3292]: segfault at 30 ip 00007fc0718b4c41 sp 00007ffc2cca6a68 error 4 in libgobject-2.0.so.0.7800.0[7fc071889000+34000] likely on CPU 4 (core 0, socket 0)

== Other info ==
I’ve marked the steps above WIP because these are the conditions under which I found this today, but I haven’t yet tried narrowing them down, because of course I have little control over which updates are available. (For instance, the kept packages might just be a red herring.)

I initially tried to report the crash file with ubuntu-bug, but despite asking preliminary questions, in the end it never opened a browser to complete the report. I’ll try apport-collect next, but if that fails too, I’ll just attach the crash file here manually.

In fact the man page seems to be completely out of sync with reality. None of minage, maxage, minsize and maxsize appear to work at all despite being documented there. Minage is read at least (according to debug output), but then still ignored. Specifying minsize or maxsize has no effect, logs are rotated when they hit 1 M regardless. At least the plain `size` directive does appear to work as documented.

The man page for logrotate says ”Each configuration file can set global options (local definitions override global ones, and later definitions override earlier ones)”. This is inconsistent with how it actually behaves.

== Steps to reproduce ==
$ logrotate –version
logrotate 3.14.0

Default mail command: /usr/bin/mail
Default compress command: /bin/gzip
Default uncompress command: /bin/gunzip
Default compress extension: .gz
Default state file path: /var/lib/logrotate/status
ACL support: yes
SELinux support: yes
$ mkdir /tmp/logrotest
$ cd /tmp/logrotest
$ touch test.log
$ touch other.log
$ cat >logrotate.conf
/tmp/logrotest/*.log {
minsize 5M
}

/tmp/logrotest/test.log {
minsize 1M
}
$ logrotate –state /tmp/logrostate logrotate.conf

== What happens ==
error: logrotate.conf:5 duplicate log entry for /tmp/logrotest/test.log

== What I expect to happen instead ==
No error, test.log being processed with its specific, later-defined directives.

@Julian: I’d argue that if a simple accidental click somewhere can cause this, that’s a loaded gun pointed at the user’s toe, and hence a bug in the installer.

@Brian: I’ll try the 22.04 images. I’ve kept trying with 20.04.5, but have yet to find another instance of this occurring, so it’s obviously not easy to trigger.

I’m not particularly troubled by this issue (and the original reporter doesn’t seem to be either), so feel free to adjust ’Importance’ accordingly.

installer.tar.xz Edit (396.6 KiB, application/x-tar)

@Olivier: Sure. This VM was just for testing purposes, so there shouldn’t be anything confidential here.

Screenshot from 2022-09-26 21-01-16.png Edit (159.6 KiB, image/png)

Looks like the deb line for updates is missing entirely from sources.list in this install; only the deb-src is there.