Boot hangs at: /scripts/local-premount/uswsusp

Bug #1568341 reported by Christopher M. Penalver on 2016-04-09
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Unassigned

Bug Description

When booting Ubuntu kernels 4.4.0-16 through 4.4.0-18 (either by default or upstart), it hangs during boot noting as per the attached screenshot:
Begin: Running /scripts/local-premount ...

With debug=y kernel parameter it hangs at:
/scripts/local-premount/uswsusp

This doesn't happen via 4.4.0-15.

Git bisect revealed:
# first bad commit: [746a312bf960810a7ccfb16eefeec68a335392b4] UBUNTU: Start new release

WORKAROUND: Uninstall package:
uswsusp

---
ApportVersion: 2.20.1-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: moniker 1927 F.... pulseaudio
 /dev/snd/controlC1: moniker 1927 F.... pulseaudio
CurrentDesktop: GNOME-Flashback:Unity
DistroRelease: Ubuntu 16.04
HibernationDevice: RESUME=UUID=c099059e-62ee-4a3a-8dc7-64bf4eb0c960
InstallationDate: Installed on 2015-12-18 (112 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
MachineType: TOSHIBA Satellite S55-C
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-15-generic root=/dev/mapper/ubuntu--vg-root ro ipv6.disable=1
ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-15-generic N/A
 linux-backports-modules-4.4.0-15-generic N/A
 linux-firmware 1.157
Tags: xenial
Uname: Linux 4.4.0-15-generic x86_64
UpgradeStatus: Upgraded to xenial on 2016-01-20 (80 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 10/14/2015
dmi.bios.vendor: INSYDE Corp.
dmi.bios.version: 5.10
dmi.board.name: 06F1
dmi.board.vendor: FF50
dmi.board.version: Type2 - Board Version
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: OEM Chassis ManuFacturer
dmi.chassis.version: OEM Chassis Version
dmi.modalias: dmi:bvnINSYDECorp.:bvr5.10:bd10/14/2015:svnTOSHIBA:pnSatelliteS55-C:pvrPSPTJU-006005:rvnFF50:rn06F1:rvrType2-BoardVersion:cvnOEMChassisManuFacturer:ct10:cvrOEMChassisVersion:
dmi.product.name: Satellite S55-C
dmi.product.version: PSPTJU-006005
dmi.sys.vendor: TOSHIBA

tags: added: apport-collected xenial
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

tags: added: latest-bios-5.10

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-4.6-rc2

With debug=y kernel parameter enabled.

description: updated
Changed in linux (Ubuntu):
importance: Medium → High
description: updated
Changed in linux (Ubuntu):
status: Confirmed → Triaged
tags: added: bisect-done
summary: - Begin: Running /scripts/local-premount ...
+ Boot hangs at: /scripts/local-premount/uswsusp
description: updated

Toggling to Low as uswsusp is not installed by default (I think?!). I must have accidentally installed it at some point in the past. Given uninstalling it is a perfectly fine WORKAROUND I'll leave it as is for now.

Changed in linux (Ubuntu):
importance: High → Low

It is indeed not installed by default (at least I manually installed it just now and broke my system. However I'm not sure I agree with this being low, since installing it made my system completely unable to boot (has kernels 4.4.0.21 and .22 only) at least with any of the recovery modes available in grub. At least the workaround for me was not that simple, since it required making and booting from a rescue media to be able to actually get into a situation where it was possible to remove the package again.

If anyone else runs into this here were my steps for solving this:
1. Make a 16.04 installation disk (any live CD really)
2. Boot this in the try/livecd mode
3. Create somewhere to mount the real root partition (e.g. "sudo mkdir /media/root")
4. Mount the root partition (e.g. "sudo mount /dev/sdaX /media/root")
5. chmod into the root partition (e.g. "sudo chmod /media/root")
6. Remove the package (e.g. "sudo apt-get remove uswsusp" )
7. Reboot

John Fremlin (john-fremlin) wrote :

The system cannot boot in recovery mode either.

While fixing the specific bug in the uswsusp package might not be very urgent, the experience I had was that doing an Ubuntu upgrade to Xenial LTS edition caused my machine to be unbootable. If this issue is not going to be addressed then perhaps we should look into making the recovery mode more resilient to apparently unsupported scripts.

Shouldn't the uswsusp script be disabled until the issue is resolved? Who can accept a patch for that?

Apple J. Kiss (applejuicekiss) wrote :

same thing here with Ubuntu Mate 16.04. just installed package 'hibernate' which i guess pulled in uswusp.

i didnt see this mentioned previously but if i wait out the script it eventually returns:

resume: could not stat the resume device file '/dev/disk/by-uuid/(some uuid hex)' please type in the full path name to try again or press enter to boot the system:

so was able to get into the system eventually by pressing enter. this happened to be when i had selected recovery mode in grub. but other times the script never ended before i gave up and reset machine.

I probably had the same problem. It got stuck at local-premount and got fixed when I uninstalled uswsusp (which I probably installed in the past trying to fix the non-working suspend). Although in my case I could always wait for local-premount/uswsusp to fail on recovery mode, it always ended up failing after some minutes, meanwhile normal boot would never end up there no matter how many minutes I waited (like, half an hour once).

Also got some ACPI messages when running normal boot without quiet and splash.

Acpi error messages

I have the same issue on a Thinkpad E580 with 18.04 alpha release: installed package hibernate and system hangs on boot. For some reason, uninstalling uswsusp did not solve the problem for me.

Sebastiaan Breedveld, you likely have a different root cause if uninstalling uswsusp didn't help.

Hence, , it will help immensely if you don't install the package hibernate so you can boot, and provide necessary debugging logs by filing a new report with Ubuntu via a terminal:
ubuntu-bug linux

As an alternative you may use https://bugs.launchpad.net/ubuntu/+source/linux/+filebug .

Please feel free to subscribe me to it.

@Christopher: perhaps. My system became somewhat convoluted while trying to get hibernation to work somehow.

Clean test:
- disabled Secure Boot, just to be sure
- installed Xubuntu 18.04 alpha 2, most recent daily image
- updated and installed only uswsusp
- reboot

Boot hangs at the exact same point as with the OP. However, after a 5-10 minutes wait, the system informs me that it cannot find the resume device, and I could press [Enter] to boot normally.

It seems that uswsusp is installed without proper (forced) configuration:
1) The UUID displayed it not part of my system
2) I found this reference in /etc/uswsusp.conf
3) I disabled cryptoswap, and set resume_device to my swap partition (just to make things easy)
4) I used s2disk, and see a progress bar that the session is written to disk
5) After booting, still the long wait, and uswsusp is still looking at the wrong device (why?)
6) I manually enter my swap partition on request, and see that the system is being loaded from disk
7) Screen stays black

So I am not sure what problem I am running into. I think uswsusp is not configured, and some configuration should be forced before enabling it after installation. Also, the wait could be reduced.

The black screen problem may be related to kernel 4.13 (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1743094 ), a behavior I also encountered with 16.04.3 LTS and pm-hibernate on the same system (downgrading to 4.10 helped).

Closing this report, as not reproducible on my hardware. All others please file a new report.

Changed in linux (Ubuntu):
importance: Low → Undecided
status: Triaged → Invalid
ipatrol (ipatrol6010) on 2018-04-17
Changed in linux (Ubuntu):
status: Invalid → Confirmed
ipatrol (ipatrol6010) wrote :

Appears to be a "thing" with Toshiba laptops.

Changed in linux (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers