On Wed, Jan 24, 2018 at 7:54 PM, InvalidPath <invalid.p...@gmail.com> wrote:
> > > On Wed, Jan 24, 2018 at 7:48 PM, InvalidPath <invalid.p...@gmail.com> > wrote: > >> Aaand this crap just happened again. Suspended for less than 4 hours and >> the damned thing shutdown at some point. Here's the related journalctl >> entries.. >> >> >> >> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5343] >> manager: sleep requested (sleeping: no enabled: yes) >> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5347] >> manager: sleeping... >> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5368] >> device (wlp2s0): state change: activated -> deactivating (reason 'sleeping', >> internal state 'managed') >> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5468] >> device (wlp2s0): state change: deactivating -> disconnected (reason ' >> sleeping', internal state 'managed') >> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.6205] >> device (wlp2s0): state change: disconnected -> unmanaged (reason 'sleeping', >> internal state 'managed') >> Jan 24 14:24:41 Vostok systemd-sleep[30771]: Suspending system... >> Jan 24 14:24:54 Vostok kernel: ACPI: Preparing to enter system sleep >> state S3 >> Jan 24 14:24:54 Vostok kernel: cache: parent cpu1 should not be sleeping >> >> Jan 24 14:24:54 Vostok kernel: cache: parent cpu2 should not be sleeping >> >> Jan 24 14:24:54 Vostok kernel: cache: parent cpu3 should not be sleeping >> >> Jan 24 14:24:54 Vostok kernel: cache: parent cpu4 should not be sleeping >> >> Jan 24 14:24:54 Vostok kernel: cache: parent cpu5 should not be sleeping >> >> Jan 24 14:24:54 Vostok kernel: cache: parent cpu6 should not be sleeping >> >> Jan 24 14:24:54 Vostok kernel: cache: parent cpu7 should not be sleeping >> >> Jan 24 14:24:54 Vostok kernel: ACPI: Waking up from system sleep state >> S3 >> Jan 24 14:24:54 Vostok systemd-sleep[30771]: System resumed. >> Jan 24 14:24:54 Vostok systemd[1]: sleep.target: Unit not needed >> anymore. Stopping. >> Jan 24 14:24:54 Vostok systemd-logind[1313]: Operation 'sleep' finished. >> Jan 24 14:24:54 Vostok NetworkManager[1354]: <info> [1516829094.2648] >> manager: wake requested (sleeping: yes enabled: yes) >> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.3900] >> manager: sleep requested (sleeping: no enabled: yes) >> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.3907] >> manager: sleeping... >> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.3938] >> device (wlp2s0): state change: activated -> deactivating (reason 'sleeping', >> internal state 'managed') >> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.4077] >> device (wlp2s0): state change: deactivating -> disconnected (reason ' >> sleeping', internal state 'managed') >> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.4957] >> device (wlp2s0): state change: disconnected -> unmanaged (reason 'sleeping', >> internal state 'managed') >> Jan 24 17:19:55 Vostok systemd-sleep[28758]: Suspending system... >> >> >> >> On Wed, Jan 24, 2018 at 6:33 PM, Wolfgang Pfeiffer <r...@gmx.net> wrote: >> >>> On Wed, 24 Jan 2018 22:22:59 +0100 >>> Wolfgang Pfeiffer <r...@gmx.net> wrote: >>> >>> > Even better: reboot with X disabled (no idea how to do it) >>> >>> appending this to a kernel boot line should work: >>> systemd.unit=multi-user.target >>> https://docs-old.fedoraproject.org/en-US/Fedora/19/html/Inst >>> allation_Guide/s1-grub-targets.html >>> >>> Good luck! >>> Wolfgang >>> >>> > and then same procedure as before: sleep, then wake up .... >>> _______________________________________________ >>> users mailing list -- users@lists.fedoraproject.org >>> To unsubscribe send an email to users-le...@lists.fedoraproject.org >>> >> >> > Crap sorry, sorry I forgot to scroll to teh bottom. > > Anyway @wolfgang: So correct me if Im wrong but *GDM*.. that stuff is all related to Gnome yes?
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
