Salve,
sono passato senza traumi diretta mente da F26 a F28 (dopo aver superato un problema con SSD e GPT, EFI, bios ecc.) e ci ho lavorato tranquillamente per almeno una decina di giorni.
Ieri sera ho lanciato un aggiornamento di 91 pacchetti e, appena completato, ho spento tutto.
Stasera però non parte con nessuno dei tre kernel presenti in Grub (4.16.10-300, 4.16.9-300 e 4.16.8-300): lo schermo rimane nero, si vede solo il cursore e non succede nulla (neanche dopo mezzora, cronometrata!).
Riesco ad accedere alla console (Ctrl + Alt + F2) ma non so bene che fare da lì, oltre a reboot…
HELP!!
PS: sto scrivendo da un vecchio tablet e il PC mi serve per un lavoro di ricerca che sto faticosamente portando avanti da solo.
Aggiungo che il problema è connesso probabilmente ai driver Nvidia.
Infatti ho provato anche il riavvio (legato ancora a F24), che però si blocca lo stesso, con la scritta di non aver trovato i driver, “falling back to nouveau” e non va più avanti.
Hai provato? Se hai i pacchetti nella cache non dovrebbe essere un problema.[/quote]
Grazie, l’ho eseguito ma si è limitato a cancellare il Kernel più recente (4.16.10-300), anche se poi al riavvio compare ancora nel Grub al primo posto
Intanto ho salvato su una pennetta la directory su cui stavo lavorando, per cui se non posso risolvere rapidamente, reinstallerò il sistema, in quanto i dati sono intatti.
Resta ovviamente da capire cosa sia successo, ma da solo non ci arrivo, anche perché invece mi ero stupito di come funzionasse tutto alla perfezione dopo il passaggio di versione, senza intoppi di sorta.
Credo che il problema sia più ben più serio. Infatti da stamattina ho eseguito le seguenti operazioni:
NON posso seguire la guida del sito “If-not-true-then-false”, perché deriva dall’installazione del driver Nvidia originale.
Però nella pagina più recente dei commenti un tal Moyses scrive di aver risolto installando selinux-policy-3.14.1-29.fc28.noarch.rpm selinux-policy-targeted-3.14.1-29.fc28.noarch.rpm Fatto, ma al riavvio, la mia situazione è purtroppo invariata.
Speravo che ci fosse qualche pacchetto più aggiornato in grado di risolvere il problema, per cui ho aggiornato tutto. Inutile!
Ho letto che F28 fornisce anche un repository specifico: “rpmfusion-nonfree-nvidia-driver”. Installato e abilitato, ma non vi risultano pacchetti più aggiornati di quanto ho già sul PC.
Ho eseguito infine dnf downgrade kernel* che ha installato un kernel 4.6.3-301 (con i vari moduli: headers, devel ecc.) al posto del 4.6.9-300. In Grub adesso ho questo più vecchio al primo posto, ossia “sopra” l’11 (scaricato al punto 2) e il 10, che cioè rimangono sempre lì. Ma anche riavviando daccapo da questo 4.6.3, non cambia proprio nulla.
:-\
Considerazione finale.
Quando parte, non vedo messaggi di errore se visualizzo i comandi che scorrono velocissimi. In modalità grafica si vedono i 3 quadratini che si illuminano progressivamente, ma poi si oscura tutto e rimane il cursore fisso senza altri segni di vita dalla macchina.
Spero nel vostro aiuto prima di procedere alla reinstallazione da zero… Grazie!
vabbè, alzo bandiera bianca.
Sto scaricando KDE, ma la versione 27, sperando che non dia problemi con aggiornamenti. Credo che il problema si sia generato con il cambio di kernel, dato che invece prima era perfetta…
Alla prossima!
Non lo consiglio, perché eseguendo “a mano” l’installer originale, ad ogni aggiornamento del kernel bisognerebbe reinstallarli.
Invece, per verificare se è un problema di Selinux, nel file /etc/selinux/config modifica la riga
SELINUX=enforcing
in
SELINUX=permissive
Riavvia, e vedi se va.
ATTENZIONE!!! In questo modo Selinux rimane, in un certo senso, non abilitato, in quanto manda dei warning, ma non blocca nulla. Una volta verificato se il problema è lui, bisognerebbe controllare questi warning e creare un modulo per far funzionare il tutto anche in “enforcing”.
grazie, marcomotta, proprio sul filo del rasoio: stavo proprio per cominciare a masterizzare Fedora 27!
Tra l’altro, dev’essere la seconda volta che mi salvi… ma come ti è venuto in mente che poteva essere un problema di Selinux?
Ora che è tornato tutto a posto, resta il difficile.
Come scrivevo al post #7, anche avviando in modalità terminale (cioè, mostrando i comandi) non rilevo nessun messaggio di errore.
Forse però dovrei guardare in qualche cartella dove vengono registrati, magari è troppo veloce per il mio occhio. In quale folder potrei consultare?
E soprattutto, non saprei proprio da dove cominciare per creare un’eccezione.
[quote=aiace]
Però nella pagina più recente dei commenti un tal Moyses scrive di aver risolto installando selinux-policy-3.14.1-29.fc28.noarch.rpm selinux-policy-targeted-3.14.1-29.fc28.noarch.rpm[/quote]
[quote=aiace]Ora che è tornato tutto a posto, resta il difficile.
Come scrivevo al post #7, anche avviando in modalità terminale (cioè, mostrando i comandi) non rilevo nessun messaggio di errore.
Forse però dovrei guardare in qualche cartella dove vengono registrati, magari è troppo veloce per il mio occhio. In quale folder potrei consultare?
E soprattutto, non saprei proprio da dove cominciare per creare un’eccezione.[/quote]
Comincerei con
/usr/bin/sealert
cercando se qualche allarme ha a che fare con kmod, nvidia, o altro che ricordi il tuo problema. Controlla cosa ti viene consigliato cliccando su “Risoluzione dei problemi”.
[quote=aiace]
Però nella pagina più recente dei commenti un tal Moyses scrive di aver risolto installando selinux-policy-3.14.1-29.fc28.noarch.rpm selinux-policy-targeted-3.14.1-29.fc28.noarch.rpm[/quote][/quote]
ok, ma in realtà avevo appunto installato anche quei due comandi, senza però risolvere – in realtà oggi, quando (grazie al tuo aiuto) sono finalmente riuscito a superare il blocco, erano anche fra i pacchetti da aggiornare che mi ha segnalato il sistema, quindi forse non li avevo installati correttamente?
[quote=marcomotta]Comincerei con
/usr/bin/sealert
cercando se qualche allarme ha a che fare con kmod, nvidia, o altro che ricordi il tuo problema. Controlla cosa ti viene consigliato cliccando su “Risoluzione dei problemi”.[/quote]
Dunque, il file che indichi non esiste proprio sulla mia macchina (e sì, ho attivato anche la modalità per visualizzare i files nascosti, casomai ci fosse anche quello).
Mistero…
Più in generale, però, volevo sollevare una questione.
Quando mi hai suggerito di mettere in modalità “permissiva” Selinux, mi è anche tornato in mente che fino a qualche Fedora fa (diciamo un paio di anni fa) c’era un comando per ottenere il medesimo risultato senza dover aprire (e modificare) il file da amministratore, forse qualcosa attraverso un config-manager o roba simile. E lo utilizzavo perché ero convinto che non potesse succedere nulla di devastante per una macchina che montava Linux.
Voglio dire: benissimo che gli sviluppatori abbiano pensato a proteggere il sistema con un simile software, ma nel mio caso (che non gestisco server, lavoro files quasi esclusivamente a livello individuale, né ho Windows in dual boot, né utilizzo repo che non siano quelli standard) era meglio lasciarlo sempre in “permissive”.
Detto ancora più chiaramente: quali rischi potrei correre a fare ancora così ?
NB: la domanda è seria, sincera, ossia non prenderla come retorica
Forse li avevi installati da live, senza prima fare un chroot, e quindi erano stati installati nella live, e non nel sistema.
[quote=aiace][quote=marcomotta]
/usr/bin/sealert
cercando se qualche allarme ha a che fare con kmod, nvidia, o altro che ricordi il tuo problema. Controlla cosa ti viene consigliato cliccando su “Risoluzione dei problemi”.[/quote]
Dunque, il file che indichi non esiste proprio sulla mia macchina (e sì, ho attivato anche la modalità per visualizzare i files nascosti, casomai ci fosse anche quello).[/quote]
# dnf install setroubleshoot-server
[quote=aiace]Più in generale, però, volevo sollevare una questione.
Quando mi hai suggerito di mettere in modalità “permissiva” Selinux, mi è anche tornato in mente che fino a qualche Fedora fa (diciamo un paio di anni fa) c’era un comando per ottenere il medesimo risultato senza dover aprire (e modificare) il file da amministratore, forse qualcosa attraverso un config-manager o roba simile. E lo utilizzavo perché ero convinto che non potesse succedere nulla di devastante per una macchina che montava Linux.
Voglio dire: benissimo che gli sviluppatori abbiano pensato a proteggere il sistema con un simile software, ma nel mio caso (che non gestisco server, lavoro files quasi esclusivamente a livello individuale, né ho Windows in dual boot, né utilizzo repo che non siano quelli standard) era meglio lasciarlo sempre in “permissive”.
Detto ancora più chiaramente: quali rischi potrei correre a fare ancora così ?
NB: la domanda è seria, sincera, ossia non prenderla come retorica[/quote]
Due considerazioni:
avere Selinux in permissivo è come non averlo, serve solo a testare i problemi per risolvere, io non lo terrei così definitivamente.
siccome dici che
potresti provare, per prima cosa, a ripristinare nel file /etc/selinux/config la riga
SELINUX=enforcing
al posto di
SELINUX=permissive
e riavviare.
Magari, con l’aggiornamento, hai risolto anche tu, e non serve fare altro.
Forse li avevi installati da live, senza prima fare un chroot, e quindi erano stati installati nella live, e non nel sistema.[/quote]
Beh, in realtà no: la live l’avevo utilizzata unicamente per controllare che i files della HOME ci fossero ancora tutti e integri, nonché per copiarmi alcune cartelle sulle quali stavo lavorando negli ultimi giorni e dovevo quindi salvare ASSOLUTAMENTE, prima di eventuali disastri (un backup completo dei Documenti l’avevo comunque fatto un paio di settimane prima).
Ma lasciamo perdere, questo è un dettaglio poco importante rispetto alle altre questioni qui sotto riportate.
[quote=aiace][quote=marcomotta]
/usr/bin/sealert
cercando se qualche allarme ha a che fare con kmod, nvidia, o altro che ricordi il tuo problema. Controlla cosa ti viene consigliato cliccando su “Risoluzione dei problemi”.[/quote]
Dunque, il file che indichi non esiste proprio sulla mia macchina (e sì, ho attivato anche la modalità per visualizzare i files nascosti, casomai ci fosse anche quello).[/quote]
# dnf install setroubleshoot-server
Questo l’ho fatto, ma intanto sono anche andato a cercare qualche info.
A questa pagina (https://docs-old.fedoraproject.org/it-IT/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html) si suggerisce di installare anche i pacchetti seguenti: selinux-policy-targeted, selinux-policy, libselinux, libselinux-python, libselinux-utils, policycoreutils, setroubleshoot, setroubleshoot-server, setroubleshoot-plugins (opzionali: policycoreutils-gui, setroubleshoot, selinux-policy-devel. mcstrans).
A parte libselinux-python (che non sembra esistere più nei repo ufficiali di F28), gli altri quattro opzionali (setroubleshoot, policycoreutils-gui, selinux-policy-devel e mcstrans) non li ho sul sistema: servono?
Intanto provo a riavviare, come suggerisci qui sotto, e a seconda dell’esito aggiornerò il thread.
[quote=marcomotta]Due considerazioni:
avere Selinux in permissivo è come non averlo, serve solo a testare i problemi per risolvere, io non lo terrei così definitivamente.
siccome dici che
potresti provare, per prima cosa, a ripristinare nel file /etc/selinux/config la riga
SELINUX=enforcing
al posto di
SELINUX=permissive
e riavviare.
Magari, con l’aggiornamento, hai risolto anche tu, e non serve fare altro.[/quote]
avevi ragione: ho modificato la voce da ‘permissive’ a ‘enforcing’, ho riavviato e adesso il problema non si presenta più
Grazie ancora e, se possibile, fatemi sapere se occorre installare anche i pacchetti opzionali che menzionavo nel penultimo post.
