AMD 64 Suse 11.1
Has anyone come across this ? During boot the system actually stops at the prompt.(see end) I then type in exit. Boot then proceeds to fully operational system. The background to this may have been caused by changing kernels on this system. I have been diagnosing my Virtualbox set up. This has been resolved but I am left with the below problem.
===================================
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.
Boot logging started on /dev/char/…/tty1(/dev/console) at Tue Feb 24
07:42:54 2009
Trying manual resume from
/dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
Invoking userspace resume from
//dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
resume: libgcrypt version: 1.4.1
Trying manual resume from
/dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
Invoking in-kernel resume from
//dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
Waiting for device
/dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part7 to appear: ok
invalid root filesystem – exiting to /bin/sh
$ exit
This log shows more detail
=========================================
7>Ending clean XFS mount for filesystem: sdb4
<4>fuse init (API version 7.9)
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.
Boot logging started on /dev/char/…/tty1(/dev/console) at Tue Feb 24
07:42:54 2009
Trying manual resume from
/dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
Invoking userspace resume from
//dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
resume: libgcrypt version: 1.4.1
Trying manual resume from
/dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
Invoking in-kernel resume from
//dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part1
Waiting for device
/dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part7 to appear: ok
invalid root filesystem – exiting to /bin/sh
$ exit
exit
Mounting root /dev/disk/by-id/ata-WDC_WD1600JD-55HBB0_WD-WMAL92550378-part7
Boot logging started on /dev/char/…/tty1(/dev/console (deleted)) at Tue Feb
24 18:13:19 2009
done
Starting udevd: done
Loading drivers, configuring devices: done
Loading required kernel modules
Since you got no (better) answer, I’d risk a guess that your system is trying to resume from a previous suspend-to-disk supposedly in /dev/disk/…-part 1. As it can’t find the suspend image that should have been written to ram it trows you at a command prompt.
So, maybe there is a setting somewhere that is erroneously telling your system to resume, while it should make a clean boot instead, and this setting is persistent.
If that is so (and I may be completely wrong), you should try to identify where the suspend routines write their flags and check permissions, etc.