On Fri, 17.04.15 02:25, Felix Miata (mrma...@earthlink.net) wrote: > Lennart Poettering composed on 2015-04-16 12:16 (UTC+0200): > > > Felix Miata wrote: > > >> Zbigniew JÄdrzejewski-Szmek composed on 2015-04-15 18:11 (UTC): > > >> > On Wed, Apr 15, 2015 at 13:31:38 -0400, Felix Miata wrote: > > >> >> This isn't the first time or the only system. This particular one is an > >> >> old > >> >> Athlon booted to F22 just updated last night. In order to try some > >> >> follow-up > >> >> on a bug, I booted with drm.debug=14 log_buf_len=16M on cmdline. Somehow > >> >> after exiting IceWM back into KDM, the system quit responding. After > >> >> some > >> >> waiting, I was switched to a tty full of systemd-journal failed to write > >> >> readonly filesystem messages. How the system got / into a readonly > >> >> state I > >> >> have no idea, but my complaint is $SUBJECT, the time it takes, or the > >> >> complete failure, trying to reboot when there is a problem, often seeing > >> >> failed to store sound card state or failing boot *start* jobs. Why has > >> >> rebooting to get out of trouble gotten to be so nearly impossible? > > >> > Did you try to press CAD more than 7 times within 2s? This should > >> > result in immedate reboot. > > I don't normally count, but what I usually do is just hold the three keys > down until the reboot process becomes apparent.
Also, let me add, that tHis is a bad idea. THis will queue additional boot requests each time. THis is effectively coalesced in the state engine, but you will possibly get confused logs, including audit and utmp reboot records and suchlike. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
