Usplash timeout too low in script/local_premount/resume : stop usplash

[Florent Mertens]

Binary package hint: initramfs-tools

In script/local_premount/resume, while waiting
for the resume device, usplash timeout is set to
the delay time.
In theory this could work, but in practice, if the script
wait the full delay time (device don't appear), usplash
timeout is often reached, making it disappear.

I suggest the following path to fix the issue :

--- scripts/local-premount/resume 2008-03-01 03:31:26.000000000 +0100
+++ scripts/local-premount/resume2 2008-04-09 00:32:11.000000000 +0200
@@ -38,7 +38,7 @@
   slumber=${RESUMEDELAY}
  fi
  if [ -x /sbin/usplash_write ]; then
- /sbin/usplash_write "TIMEOUT ${slumber}" || true
+ /sbin/usplash_write "TIMEOUT $(( ${slumber} + 2 ))" || true
  fi

  slumber=$(( ${slumber} * 10 ))
@@ -47,6 +47,10 @@
   slumber=$(( ${slumber} - 1 ))
   [ ${slumber} -gt 0 ] || break
  done
+
+ if [ -x /sbin/usplash_write ]; then
+ /sbin/usplash_write "TIMEOUT 15" || true
+ fi

  if [ ${slumber} -gt 0 ]; then
   log_end_msg 0

[u-foka (ufooka)]

Hy!

I had exactly the same problem, and made the same solution :) So This is absolutley configmed ;)

[Avery Fay (averycfay)]

I had the same problem after converting my filesystem to lvm and this patch fixes it.

[Andrew Radke (andrew-radke)]

Before finding this bug report I had also determined that the timeout set in /usr/share/initramfs-tools/scripts/local-premount/resume was at fault.

The patch above corrects the behaviour completely.

[Alexander Sashnov (sashnov)]

I found this bug too. And on my system, when usplash gone, system boot hangs on "Checking root filesystem".
Not reproduced on virtual system- fsck works fine.

 slumber=$(( ${slumber} * 10 ))
 while [ ! -e "${resume}" ] || ! /lib/udev/vol_id "${resume}" >/dev/null 2>&1; do
  /bin/sleep 0.1
  slumber=$(( ${slumber} - 1 ))
  [ ${slumber} -gt 0 ] || break
 done

At least, sleep 0.1 executed 50 times takes 5 sec. Whole loop takes 5.13 sec in my measurement.
And also usplash need to wait some thing other usplash_write command from another script.

[Alexander Sashnov (sashnov)]

How to reproduce this bug:

  a) delete swap partition

  b) or
      $ sudo nano /etc/initramfs-tools/conf.d/resume
          (do random edit in UUID)
       $ sudo update-initramfs -u

  c) or change UUID of swap partition:
       $ sudo swapoff /dev/sda5
       $ sudo mkswap /dev/sda5
    (it re-create swap with new UUID, where sda5 is swap partition)

[Paolo Bernardi (bernarpa)]

I dealt with the same problem on Ubuntu 9.04; since I use an random key encrypted swap, mkswap is executed at every boot and the condition c) from Alexander Stephanov's post happens accordingly. The patch from Florent Mertens gets two hunks but the concept is still valid; in particular I had just to edit /usr/share/initramfs-tools/scripts/local-premount changing the line

/sbin/usplash_write "TIMEOUT ${slumber}" || true

with

/sbin/usplash_write "TIMEOUT $(( ${slumber} + 2 ))" || true

I couldn't find where to apply the second part of the patch; anyway with the only modification above now usplash doesn't go timeout anymore.

I also wrote a blog post about this:
http://paolobernardi.wordpress.com/2009/10/02/fix-ubuntu-usplash-stops-waiting-for-resume-device/

[u-foka (ufooka)]

Well...

Recently I found that commenting the RESUME= line out from /etc/initramfs-tools/conf.d/resume (or set it to a right usable swap partition) and regenerate the initrd is solve the problem

(my usplash disappeared after I set up an encrypted swap replacing the original one...)

[Evan Broder (broder)]

At this point, Ubuntu Dapper and Hardy are the only releases which use usplash and are still supported. In Karmic we switched briefly to xsplash, and then in Lucid we switched to plymouth.

If I'm reading this bug (and Paolo's blog post) correctly, this sounds like purely a cosmetic issue, rather than one that actually affects your ability to boot in any way. Is that correct? At this point in the release cycle, I don't think that a purely cosmetic bug would qualify for a Stable Release Update, so I'm closing this bug as "Won't Fix".

However, if I'm wrong about it just being cosmetic, please feel free to re-open the bug with an explanation of the impact.