13.1 crashes on boot as journal/plymouth trying to install non existent hdds

Opensuse 13.1 kernel from last june. i2600-k 16gb ram, ssd boot and raid5 for data and those ghost hdd in the photo are old raid drives. Not attached atm but somehow they are listed somewhere and cant boot as they are not there. System just tries to find them and gets stuck in everlasting loop.

The one hdd marked with red arrows times surprisingly out as it is not attached. The ones in green square are neither attached. They from old raid.

So boot gets stuck on the msg shown last in pic and dunno how to login from there. It just keeps repeatin that every few mins. I booted into rescue system, but couldt figure what to do there if anything.

Picture tells more:

Here is the CORRECT link. Dropbox gave wrong one.


I think I finally figured this out after week of trying. Got boot and backup hdds mounted in rescue system and copied most dirs from backup to boot hdd.

Now boots up nicely. Was maybe some funny hickup. Dunno.

First of all, this had nothing to do with either journal or plymouth.
systemd starts services in parallel, so just because those “Expected device xxx” messages come right after “Started Journal Service”, it doesn’t mean that they are in any way related to “Journal Service” (if they were, they would probably come before that anyway).

OTOH, those “Expecting Device xxx” messages are no errors anyway. Systemd just tells you that it is waiting for that device to appear, which is perfectly normal.

What definitely is a problem in your screenshot is that xxx-part6.device timed out, and /200gb could not be mounted therefore (which makes the “Local Filesystems Service” fail).
If a required partition fails, systemd jumps into emergency mode (this was actually the same with sysvinit). Unfortunately there is a bug in 13.1 that emergency mode does not work if rsyslog is installed, which it is by default.

Anyway, you probably have an entry in /etc/fstab to mount a partition on a disconnected drive, or a non-existing partition on a connected drive.
You should either remove/comment that entry, or set the mount option “nofail” (makes sense especially for external drives, obviously). Booting will continue even when that partition cannot be mounted then.

The question now is whether copying back files from the backup has really fixed anything, or it is fixed now because those missing drive(s) is/are connected now. In the latter case the boot will fail again as soon as you disconnect it/them again.


I found the reason why everything froze and after reboot started getting that error

From apache log:
[core:error] [pid 7056] [client] AH00126: Invalid URI in request ]\xf7K\xd4-M\xa0-\xbd\x1amn\xd1\xdb\xe3{\xcb\r\xac\x15\xcaB|.
[mpm_prefork:notice] [pid 6114] AH00170: caught SIGWINCH, shutting down gracefully

Just after when that hex code was inserted in apache pc froze. Just found that few mins ago from logs. I noticed that was lookin for answer in wrong place…also wonder if there is a way to filter out those hex codes in apache?

How was that hex code inserted in apache?

You mean somebody sent this as request to your Apache server and this crashed it (and your system)?
Would sound like a severe bug or even security issue to me.

I suppose you should file a bug report then: Bug Reporting - The Apache HTTP Server Project .

also wonder if there is a way to filter out those hex codes in apache?

Well, maybe there’s some module that would allow this.
But I have to admit I cannot really help you there.