Spegnimento su disco e in RAM

salve,
dopo aver smanettato un po’ con le Impostazioni di sistema, non mi ritrovo più le opzioni di cui al titolo del thread, che usavo regolarmente.
Col risultato che ogni volta che smetto di lavorare sul PC per un certo periodo di tempo (chessò, per andare a cena), mi tocca spegnere e riaccendere tutto daccapo, con relativa perdita di tempi morti.

Ho fatto qualche prova e sono in grado di escludere che sia un problema relativo al kernel (sussiste anche con quelli inferiori all’attuale, che è un 4.2.7-200) e al DE (in una sessione con Gnome ci sono ancora, premendo Alt).

Dentro Impostazioni di sistema > Avvio e spegnimento > Sessioni del desktop, nel primo riquadro (Generale) sono attive entrambe le voci: Conferma l’uscita e Offri le opzioni di spegnimento.

Come posso riattivare quelli che una volta si chiamavano Hibernate e Standby?
Grazie

In passato andava? Non è che non le supporta?

Prova ad eseguire questo comando

$ for f in suspend hibernate; do pm-is-supported --$f && echo "$f: supported"; done

sì, come già scritto, entrambe le modalità mi hanno funzionato sempre, almeno dalla F20 (mi pare). Infatti:

[Aiace@new-host ~]$ for f in suspend hibernate; do pm-is-supported --$f && echo "$f: supported"; done suspend: supported hibernate: supported

Ti dirò… Da me da “hibernate: supported”, ma se eseguo “pm-hibernate” l’avvio è standard: forse perché ho il disco cifrato? Detto ciò, cosa succede se provi ad ibernarlo con questo comando?

pare anche a me…
Ho eseguito il comando indicato da amministratore (lo richiedeva) e in parte risulta come a te, cioè:
prima dello spegnimento mostra lo schermo nero ma con una specie di albero di natale in ASCII-art (cioè fatto da a e o accentate e colorate in bianco e nero, mi pare). Ci mette un po’ prima di chiudersi del tutto, ma immagino che sia dovuto al salvataggio.
Poi però il sistema riparte da zero, come se il comando precedente non avesse salvato nulla (già, dove avrà messo i dati salvati? forse il comando è impostato male e non riesce ad agganciarli?).
Ossia, presenta dapprima il menu di GRUB2, poi avvia il caricamento dei vari moduli (avendo le istruzioni rhgb quiet attivate, parte lo scorrimento delle barre di 3 colori diversi in basso), arriva allo splashscreen in cui inserire le credenziali, poi uno schermo intermedio con una piccola barra di caricamento (dei dati utente appenma selezionato, suppongo), infine approda a KDE, ma senza nessuno dei programmi che giravano al momento del power down.

Per curiosità ho provato a lanciare da terminale anche l’altro comando

pm-suspend

che invece funziona!

Bene, l’effetto finale (riparte dopo pochissimi secondi caricandosi tutte le applicazioni attive al momento della chiusura) dovrebbe corrispondere esattamente a quello del Sospendi in RAM, ma perché tale voce è scomparsa dal menu di Esci nel Lanciatore di applicazioni? O meglio, come ripristinarla, dato che subito dopo il passaggio da F21 a F22 e quindi a KDE5 c’era ancora?
Non credo abbia senso supporre che sia stato fatto apposta in KDE5, costringendo così gli utenti ad aprire un terminale e digitare un comando che richiede oltretutto di essere superutente…

Any idea?

Stesso problema in Gnome, non si capisce come mandarlo in ibernazione e se do il comando non funziona.

Ho provato i 2 comandi pure io, pm-suspend funziona benissimo, pm-hibernate lavora un po’ di tempo (suppongo faccia il salvataggio ma senza albero di natale), spegne il portatile ma al riavvio come se avessi spento il portatile, eppure lo scriptino mi da entrambi supportati.

P.S. Sto ancora su F22, aspetto che rpmfusion abbia i repo stabili per aggiornare :slight_smile:

oh, anch’io, evidentemente non mi ero reso conto di aver aperto il thread nella nuova release.
Prego quindi gli amministratori di spostare la discussione in F22>Configurazione.

Grazie

beh, evidentemente il problema NON È di facile soluzione…
Qualcuno è in grado di vedere se ci sia qualche segnalazione ufficiale in merito, bugzilla o roba del genere?
La cosa strana è che, in genere, se non funziona la GUI, si da il comando via CLI, ma qui sembra che ci sia qualcosa proprio a livello di sistema, perché dando

# pm-hibernate

non succede nulla di quello che ci aspetterebbe. :confused:
Ma avranno testato bene la F22?

Vi invito a scrivere su https://bugzilla.redhat.com/show_bug.cgi?id=1224151

ciao, io ho un account su bugzilla, per le rare volte in cui ho inviato segnalazioni di qualche malfunzionamento ‘serio’.
Ora, anche questo relativo a SUspend e Hibernate mi pare serio, però non saprei cosa aggiungere a quello che ci trovo già scritto.
Intendo dire che il thread è stato aperto da persone che, se non proprio sviluppatori Fedora, ne sanno molto più di me, dato che sono in grado di descrivere stati della macchina a me ignoti (mi riferisco in particolare ai Comments 2 e 3).
Francesco, secondo te come potrei contribuire in maniera costruttiva? A me verrebbe soltanto da dire (ok, in inglese, quello non è un problema per me): non funziona neanche a me su F22, KDE, dopo #dnf upgrade… Insomma, a me sembra una segnalazione povera dal punto di vista tecnico, che non aggiunge nulla (se non quantitativamente) alle informazioni ben più dettagliate di chi mi ha preceduto (te compreso).

Grazie (anche a qualcun altro che potrà suggerire qualcosa)!

Aggiungi il tuo utente in CC (vedi in alto a destra), così fai vedere che ci sei e rimani aggiornato. Magari con l’aiuto di Arkanoid/JuliuxPigFace riusciamo a riportare alla luce questo problema in QA (vedo che era già stato proposto per un release freeze).

ok, fatto - speriamo bene.
Stasera ho scaricato un bel po’ di aggiornamenti al sistema, tra cui vari pacchetti relativi a Plasma 5.
Ora chiudo tutto per bene (no suspend né hibernate) e vediamo se domani è cambiato qualcosa.
Caso mai aggiorno la discussione.

salve a tutti

ho appena controllato https://bugzilla.redhat.com/show_bug.cgi?id=1224151 e non ci sono state altre segnalazioni dopo la mia del 30 dicembre.
Ho aggiornato tutto il mio sistema pochi giorni fa, ma non mi pare ci fossero pacchetti relativi alla questione, che quindi non è ancora risolta.
Da parte mia posso aggiungere che probabilmente anche la cura nella realizzazione di suspend non è stata somma: in due occasioni, infatti, al riavvio un’applicazione è risultata inutilizzabile.
Si tratta di Libre Office (di cui utilizzo peraltro la versione pacchettizzata da Fedora, non quella, più avanzata, disponibile sul sito degli sviluppatori): ovviamente avevo salvato il file prima di chiudere, ma alla riapertura è comparsa la solita notifica di errore

o roba del genere (ma perché non è stato tradotto in italiano…?), anche se apparentemente il programma era ancora “su”.
In realtà l’ho dovuto rilanciare e riaprire il file come se non fosse rimasto salvato in memoria.

Non ho pensato a guardare dentro qualche log, ma dove avrei dovuto dare un’occhiata?

Per quanto riguarda la problematica generale, riguardante l’ibernazione… Mea culpa… Onestamente me n’ero accorto, durante gli ultimi due cicli di testing, ma credevo che il tutto fosse legato ad un problema con KVM (https://bugzilla.redhat.com/show_bug.cgi?id=1223541). È certamente un blocker; me lo segno a caratteri cubitali e lo propongo per la F24.

Per KDE, il problema è molto strano: aiace, hai provato con un nuovo utente a vedere se le due opzioni in questione vengono proposte?

Grazie per l’altra questione, anche se F 24 è piuttosto lontana…

Invece interessante la tua proposta:

Infatti se clicco sul Lanciatore > Esci, dove vedo solamente 5 voci (Blocca, Chiudi sessione, Nuova sessione, Riavvia, Spegni) e seleziono Nuova, anzitutto mi dice (in inglese e con una grafica un po’ spartana, quella del caricamento dopo lo splashscreen) che non è attiva nessuna nuova sessione (ok, è vero) e mi propone l’alternativa fra annullare il comando oppure avviare una nuova sessione. Ma se clicco il bottone con la scritta “Nuova sessione”, non succede nulla: cioè il PC non fa nulla e torno esattamente da dov’ero partito.
Ovviamente avevo già creato un secondo utente, anche se in pratica non l’ho usato mai, salvo questi casi di controlli incrociati.

Che dire? Devo forse crearne uno tutto nuovo e vedere che succede? Non è già abbastanza strano un (mal)funzionamento del genere?

È sicuramente strano, ma l’impossibilità nell’aprire una nuova sessione, è un problema differente (magari la natura è la stessa, ma non necessariamente).

Questi cosa dicono?

$ free -h

$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanHibernate

$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspend

ah, pensavo dipendesse dallo stesso malfunzionamento di fondo…

[quote=arkanoid]Questi cosa dicono?

[code]
$ free -h

$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanHibernate

$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspend
[/code][/quote]

[code][Aiace@new-host ~]$ free -h
total used free shared buff/cache available
Mem: 7,8G 3,9G 64M 63M 3,8G 3,7G
Swap: 3,9G 93M 3,8G

[Aiace@new-host ~]$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanHibernate
method return sender=:1.1 -> dest=:1.814 reply_serial=2
string "yes

[Aiace@new-host ~]$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1
Usage: dbus-send --help] --system | --session | --bus=ADDRESS | --peer=ADDRESS] --dest=NAME] --type=TYPE] --print-reply=literal]] --reply-timeout=MSEC] [contents …][/code]

Vedo che nel terzo comando c’è qualcosa che non va, perlomeno sintatticamente…

[quote=arkanoid]$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspend [/quote]

[quote=aiace]$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1
[/quote]
Scusa aiace, forse manca un pezzo?

@andreamal
ma certo, grazie dell’osservazione: avevo sbagliato io a copiare, senza rendermene conto.
Ecco l’output:

[Aiace@new-host ~]$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspend method return sender=:1.5 -> dest=:1.59 reply_serial=2 string "yes"

Dunque mi pare che entrambi i comandi siano a posto.
Da cosa dipenderà, allora. il malfunzionamento?