Comment 25 for bug 553290

fsck ran, then exited successfully.

Sorry, it seems the (current) problem may be with the ply_boot_client_flush() call. Backtrace:

(gdb) thread apply all bt full

Thread 1 (Thread 0x7f20eb6aa700 (LWP 357)):
#0 0x00007f20eac3c920 in __read_nocancel () from /lib/libpthread.so.0
No symbol table info available.
#1 0x00007f20ea81ac6b in read (fd=11, buffer=0x7fff3e7b9780, number_of_bytes=1) at /usr/include/bits/unistd.h:45
No locals.
#2 ply_read_some_bytes (fd=11, buffer=0x7fff3e7b9780, number_of_bytes=1) at ply-utils.c:353
        bytes_read = -512
        total_bytes_read = 0
#3 ply_read (fd=11, buffer=0x7fff3e7b9780, number_of_bytes=1) at ply-utils.c:385
        __PRETTY_FUNCTION__ = "ply_read"
#4 0x00007f20ea608e56 in ply_boot_client_process_incoming_replies (client=0x7f20ecdc2810) at ./ply-boot-client.c:266
        request_node = <value optimized out>
        request = <value optimized out>
        byte = "\000"
        size = <value optimized out>
        __PRETTY_FUNCTION__ = "ply_boot_client_process_incoming_replies"
#5 0x00007f20ea609415 in ply_boot_client_flush (client=0x7f20ecdc2810) at ./ply-boot-client.c:753
        __PRETTY_FUNCTION__ = "ply_boot_client_flush"
#6 0x00007f20eb6d26ba in emit_event (name=0x7f20eb6de964 "mounting", mnt=0x7f20ecdc84a0) at mountall.c:2204
        env = 0x0
        env_len = 0
        __FUNCTION__ = "emit_event"
#7 0x00007f20eb6d6fe7 in try_mount (mnt=0x7f20ecdc84a0, force=0) at mountall.c:1586
        __FUNCTION__ = "try_mount"
#8 0x00007f20eb6d2de2 in spawn_child_handler (proc=0x7f20ecdd0900, pid=840, event=<value optimized out>, status=0) at mountall.c:1717
        __FUNCTION__ = "spawn_child_handler"
<snip>

So the flush call is trying to read from the pipe, because there's an outstanding request to plymouth that *may* result in a response: the "s to skip or m for maintenance shell" key watch.

Since we don't want to cancel that request (we've only gotten as far as "mounting"; something might still go wrong between now and the mount finishing, so the user should still be able to interrupt), ply_boot_client_flush() needs to be made smarter about knowing when there's something to be read (e.g., poll()).

I've confirmed that building from trunk with only revision 314 commented out lets this test system boot again.