Score:0

I/O error while resuming from disk (hibernate) on Kubuntu booted from an external USB SSD

md flag

I installed and booted a Kubuntu 22.04 installation (Linux 5.19.0-41-generic) on an external NVME SSD drive. This is the USB device, according to lsusb:

Bus 002 Device 002: ID 0bda:9210 Realtek Semiconductor Corp. RTL9210 M.2 NVME Adapter

The laptop I'm using has an Intel CPU and a dedicated Nvidia GPU (as well as an integrated Intel GPU). The v525 non-free driver was installed with ubuntu-drivers install nvidia:525. It has 8GiB of RAM.

I can boot into the OS just fine, even suspend to RAM (sleep) works, but suspend to disk (hibernate) does not seem to work. The OS was installed on an encrypted LVM partition set up like this:

$ lsblk
sdb                    8:16   0 119.2G  0 disk  
├─sdb1                 8:17   0   512M  0 part  /boot/efi
├─sdb2                 8:18   0   1.7G  0 part  /boot
└─sdb3                 8:19   0  67.1G  0 part  
  └─sda3_crypt       253:0    0  67.1G  0 crypt 
    ├─vgkubuntu-root 253:1    0    50G  0 lvm   /var/snap/firefox/common/host-hunspell
    │                                           /
    ├─vgkubuntu-home 253:2    0     4G  0 lvm   /home
    └─vgkubuntu-swap 253:3    0    11G  0 lvm   [SWAP]

$ cat /etc/crypttab
sda3_crypt UUID=7e297f18-38c5-4a2f-b5fc-a46f42b5418a none luks,discard

I enabled hibernate by following this guide:

  • Configured a swap partition on /dev/vgkubuntu/swap, added it to fstab
  • Added resume=UUID=fc1fc4b9-09c9-4198-bb11-b13846491b4f to GRUB_CMDLINE_LINUX_DEFAULT= in /etc/default/grub
  • Created the /etc/initramfs-tools/conf.d/resume file with RESUME=UUID=fc1fc4b9-09c9-4198-bb11-b13846491b4f as its content
  • Ran update-grub and update-initramfs -c -k all, and then reboot

The laptop can power off just fine when I pressed the hibernate button on KDE's start menu, but I was shown a black screen with a mouse cursor when resuming (this is after I was prompted the LUKS password). Occasionally, this error line appears briefly before disappearing:

[  159.380884] I/O error, dev sdb, sector 25607104 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

I had to power off the machine forcefully to boot normally. The disk does not seem to be writable when resumed. This is the last journalctl logs I could find:

May 05 22:16:20 HOSTNAME ModemManager[996]: <info>  [sleep-monitor] system is about to suspend
May 05 22:16:20 HOSTNAME NetworkManager[889]: <info>  [1683299780.9345] manager: sleep: sleep requested (sleeping: no  enabled: yes)
May 05 22:16:20 HOSTNAME NetworkManager[889]: <info>  [1683299780.9347] device (enp3s0): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 05 22:16:20 HOSTNAME NetworkManager[889]: <info>  [1683299780.9379] device (p2p-dev-wlp2s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 05 22:16:20 HOSTNAME NetworkManager[889]: <info>  [1683299780.9385] manager: NetworkManager state is now ASLEEP
May 05 22:16:20 HOSTNAME NetworkManager[889]: <info>  [1683299780.9389] device (wlp2s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
May 05 22:16:20 HOSTNAME dbus-daemon[887]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.12' (uid=0 pid=889 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
May 05 22:16:20 HOSTNAME systemd[1]: Starting Network Manager Script Dispatcher Service...
May 05 22:16:20 HOSTNAME dbus-daemon[887]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
May 05 22:16:20 HOSTNAME systemd[1]: Started Network Manager Script Dispatcher Service.
May 05 22:16:20 HOSTNAME kernel: wlp2s0: deauthenticating from 1c:3b:f3:2f:d3:08 by local choice (Reason: 3=DEAUTH_LEAVING)
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: wlp2s0: CTRL-EVENT-DISCONNECTED bssid=1c:3b:f3:2f:d3:08 reason=3 locally_generated=1
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: wlp2s0: CTRL-EVENT-DSCP-POLICY clear_all
May 05 22:16:21 HOSTNAME NetworkManager[889]: <info>  [1683299781.0595] device (wlp2s0): supplicant interface state: completed -> disconnected
May 05 22:16:21 HOSTNAME NetworkManager[889]: <info>  [1683299781.0597] device (wlp2s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
May 05 22:16:21 HOSTNAME avahi-daemon[884]: Withdrawing address record for fe80::765c:abc2:2e9:d572 on wlp2s0.
May 05 22:16:21 HOSTNAME avahi-daemon[884]: Leaving mDNS multicast group on interface wlp2s0.IPv6 with address fe80::765c:abc2:2e9:d572.
May 05 22:16:21 HOSTNAME avahi-daemon[884]: Interface wlp2s0.IPv6 no longer relevant for mDNS.
May 05 22:16:21 HOSTNAME NetworkManager[889]: <info>  [1683299781.0748] dhcp4 (wlp2s0): canceled DHCP transaction
May 05 22:16:21 HOSTNAME NetworkManager[889]: <info>  [1683299781.0748] dhcp4 (wlp2s0): activation: beginning transaction (timeout in 45 seconds)
May 05 22:16:21 HOSTNAME NetworkManager[889]: <info>  [1683299781.0748] dhcp4 (wlp2s0): state changed no lease
May 05 22:16:21 HOSTNAME avahi-daemon[884]: Withdrawing address record for 192.168.0.159 on wlp2s0.
May 05 22:16:21 HOSTNAME avahi-daemon[884]: Leaving mDNS multicast group on interface wlp2s0.IPv4 with address 192.168.0.159.
May 05 22:16:21 HOSTNAME avahi-daemon[884]: Interface wlp2s0.IPv4 no longer relevant for mDNS.
May 05 22:16:21 HOSTNAME systemd-resolved[822]: wlp2s0: Bus client set default route setting: no
May 05 22:16:21 HOSTNAME systemd-resolved[822]: wlp2s0: Bus client reset DNS server list.
May 05 22:16:21 HOSTNAME NetworkManager[889]: <info>  [1683299781.1436] device (wlp2s0): set-hw-addr: reset MAC address to B4:D5:BD:DD:EA:D7 (scanning)
May 05 22:16:21 HOSTNAME NetworkManager[889]: <info>  [1683299781.1464] device (wlp2s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: p2p-dev-wlp2s0: CTRL-EVENT-DSCP-POLICY clear_all
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: p2p-dev-wlp2s0: CTRL-EVENT-DSCP-POLICY clear_all
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: nl80211: deinit ifname=p2p-dev-wlp2s0 disabled_11b_rates=0
May 05 22:16:21 HOSTNAME systemd[1]: Reached target Sleep.
May 05 22:16:21 HOSTNAME systemd[1]: Starting Record successful boot for GRUB...
May 05 22:16:21 HOSTNAME systemd[1]: Starting NVIDIA system hibernate actions...
May 05 22:16:21 HOSTNAME hibernate[2041]: nvidia-hibernate.service
May 05 22:16:21 HOSTNAME logger[2041]: <13>May  5 22:16:21 hibernate: nvidia-hibernate.service
May 05 22:16:21 HOSTNAME systemd[1]: grub-common.service: Deactivated successfully.
May 05 22:16:21 HOSTNAME systemd[1]: Finished Record successful boot for GRUB.
May 05 22:16:21 HOSTNAME systemd[1]: Starting GRUB failed boot detection...
May 05 22:16:21 HOSTNAME systemd[1]: grub-initrd-fallback.service: Deactivated successfully.
May 05 22:16:21 HOSTNAME systemd[1]: Finished GRUB failed boot detection.
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: wlp2s0: CTRL-EVENT-DSCP-POLICY clear_all
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: wlp2s0: CTRL-EVENT-DSCP-POLICY clear_all
May 05 22:16:21 HOSTNAME wpa_supplicant[923]: nl80211: deinit ifname=wlp2s0 disabled_11b_rates=0
May 05 22:16:21 HOSTNAME systemd[1]: nvidia-hibernate.service: Deactivated successfully.
May 05 22:16:21 HOSTNAME systemd[1]: Finished NVIDIA system hibernate actions.
May 05 22:16:21 HOSTNAME systemd[1]: Starting Hibernate...
May 05 22:16:21 HOSTNAME kernel: PM: Image not found (code -16)
May 05 22:16:21 HOSTNAME systemd-sleep[2061]: Entering sleep state 'hibernate'...
May 05 22:16:21 HOSTNAME kernel: PM: hibernation: hibernation entry

Does anyone know what went wrong? The SSD itself seems to be healthy, according to SMART. I suspect this has something to do with the drive not being powered/connected/enabled correctly during the resume process, but currently I don't know how to troubleshoot this further.

Score:0
md flag

Managed to solve the issue myself -- seems like a kernel issue. I managed to make hibernate work by downgrading kernel-related packages to 5.15.0-71-generic (which is/was the latest LTS version available for 22.04).

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.