On Mon, 10 Oct 2011 09:42:44 -0400, AJ (Adam) wrote: > On Sun, 2011-10-09 at 17:26 +0200, Michael Schwendt wrote: > > > Shortly before the Plymouth LUKS passphrase prompt, the screen turns black, > > the monitor reports "No signal" and enters power-saving mode. The system > > hasn't crashed, because instead of pressing Ctrl+Alt+Del I can also enter > > the passphrase blindly for the boot procedure to continue. However, > > nothing "wakes up" the monitor afterwards. Switching to a virtual console > > causes the signal to return, and what is displayed on the screen is not > > GDM but the gray background with the central animation having reached > > 100% or nearly that. There is no virtual console available, and one cannot > > return to GDM either. > > Plymouth is just a KMS client like the X server. Normally it tries to > avoid setting a video mode if it can (so boot flickers less) but it will > do in some cases. So this sounds like it's a bug in the kernel driver. > > Much of the info from the Xorg debugging guide: > > http://fedoraproject.org/wiki/How_to_debug_Xorg_problems > > is relevant here, although obviously the X log and etc aren't. In > addition, booting with "plymouth:debug" on the kernel command line will > dump debugging output to /var/log/plymouth-debug.log, which should show > the mode setup that plymouth is trying for. Boot with that flag set > once, then either boot again without plymouth.debug or rhgb set, or > simply ssh into the machine and copy the log file aside. Thanks. This sounded promising, but funnily since I've added plymouth:debug permanently, I haven't managed to reproduce the issue. Instead, I've encountered a few different issues. Once only: 1) The GDM background picture was divided into a few big rectangular areas which were shifted by 1/5 screen width. Looked like an unfinished slider puzzle. ;) 2) A completely corrupted GDM background picture. Red/white/black noise, but a working login. 3) The boot not continueing after the LUKS passphrase prompt. The saved plymouth-debug.log files don't contain any obviously dangerous errors. Just lots of ply-event-loop.c debug msgs including (always) many [ply-event-loop.c] ply_event_loop_remove_source_node:failed to delete fd 11 from epoll watch list: Bad file descriptor ... [ply-boot-server.c] ply_boot_connection_on_request:could not finish writing update reply: Broken pipe Now, this morning I've taken out the option again to find out whether the primary issue would return. Perhaps it is influenced by interrupting the GRUB timeout with key presses (although I think I haven't done that with F-15 often). Or my earlier GRUB chainloading. Recently I've stored GRUB 2 in MBR. It's a tough case, but any idea might help in collecting data *if* it will happen again or if a test-case is found. -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc9.git0.0.fc16.x86_64 loadavg: 0.13 0.06 0.05 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
