I can't understand, why there is so long time delay between these two lines in my dmesg log.

[    2.089039] hid-generic 0003:1EA7:2001.0003: input,hiddev0,hidraw2: USB HID v1.10 Mouse [WFDZ Gaming Keyboard] on usb-0000:00:14.0-14/input1
[    2.752704] clocksource: Switched to clocksource tsc
[   33.501004] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[   34.350611] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.

The whole log is here: dmesg.log.txt

My system: Debian GNU/Linux 9, 4.9.0-3-amd64

Can you help me understand it or solve it? Thank you.

  • There are a number of bug reports for older Debian based systems with similar issues. Are you using Debian 9 testing for any particular reason? If this is a problem for you on a regular system and you aren't trying to help test the next Debian release, you may wish to consider switching to the current stable release.
    – 0xSheepdog
    Commented May 23, 2017 at 17:36
  • @0xSheepdog Yes, thank you. I use Debian 9 for a long time without any problems. These issues occurred in last time. Previously system started quickly. Maybe there is some problem with new kernel, but this is really strange.
    – BlueManCZ
    Commented May 23, 2017 at 17:51
  • 1
    Is it possible you need to set RESUME=none like anonscm.debian.org/cgit/kernel/initramfs-tools.git/tree/debian/… mentions? (If you have apt-listchanges installed, that NEWS entry should have been presented to you when upgrading the package) That 30s timeout is suspiciously similar to the delay you're seeing.
    – derobert
    Commented May 23, 2017 at 18:05
  • @derobert Thank you! Thats maybe it! Sometimes I see during startup text like "waiting for suspended/resumed devices". Ok, I will try to change settings and give you echo.
    – BlueManCZ
    Commented May 23, 2017 at 21:51
  • @derobert I should recreate my disk partitions, becose there are some errors with sectors. But thank you and if you write it as answer, I will accept it.
    – BlueManCZ
    Commented May 24, 2017 at 18:58

1 Answer 1


Debian initramfs-tools version 0.129 (and later) added a 30s wait for the resume device (used for suspend-to-disk aka hibernate) to appear. Previously, it'd check once and if it didn't find it, continue. Now instead it keeps trying to 30s. That is in general a good thing; it makes resume from suspend-to-disk much more reliable, especially on systems that take time to probe disks (e.g., USB).

However, if when building the initramfs, initramfs-tools (mistakenly) detects a resume device that'll never appear, it means boot gets delayed by 30s. I've seen that on one of my systems with encrypted swap.

To fix, override the autodetected resume device by putting RESUME=«something» in either /etc/initramfs-tools/conf.d/resume or /etc/initramfs-tools/initramfs.conf. That «something» can be one of auto (the default, autodetect), none (disable entirely—do not attempt to resume from suspend to disk); UUID=«uuid» (specify explicitly by UUID), /dev/whatever (specify explicitly by device node).

If your system doesn't support suspend to disk (or you don't use it), set to none.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .