Leap 15 dopo aggiornamento non si avvia

33 risposte [Ultimo messaggio]
Ritratto di Vima1940
Vima1940
(Junior)
Offline
Junior
Iscritto: 10/08/2018
Messaggi: 14

Buongiorno, spulciando su web ho scoperto che non sono il solo ad avere questo problema. Non dipende dai repository ma da due aggiornamenti: Suse 2018-762 e Suse 2018-826. Sono due aggiornamenti si sicurezza. Ecco dove ho trovato quanto sopra descritto:

eap non riesce ad avviarsi dopo gli aggiornamenti di sicurezza del kernel

Mi sono appena spostato su openSUSE Leap dopo molti anni su LinuxMint, quindi sono nuovo qui!

Dopo aver installato due aggiornamenti di sicurezza, il sistema non si avviava. Dopo la schermata iniziale di avvio, tutto è diventato vuoto. Sono stato in grado di avviare da un kernel precedente (e quindi rimuovere il kernel più recente tramite YaST2) ma non è l'ideale per ignorare gli aggiornamenti di sicurezza!

Gli aggiornamenti erano openSUSE-2018-762 e openSUSE-2018-826.

Gli aggiornamenti del kernel PRIMA erano 4.12.14-lp150.12.4.1
Gli aggiornamenti di Kernel AFTER erano 4.12.14-lp150.12.10.1

Ho provato a installare l'aggiornamento 762, ma questo ha avuto lo stesso problema e ho dovuto ripristinare il kernel precedente. Non ho provato solo a installare l'aggiornamento 826, ma ho indovinato che dovrebbero essere fatto in ordine?

Qualsiasi aiuto da parte di chiunque, o posso registrare un bug o qualcosa del genere?

Sono in una installazione molto recente di Leap 15.0 64-bit, con / partition su un SSD (con Btrfs) e / home su un hard-disk (con xfs). Posso aggiungere felicemente più informazioni se mi dici cosa fare Smile

Questa discussione si trova su forum OpenSuse.

Vmancini

Ritratto di Vima1940
Vima1940
(Junior)
Offline
Junior
Iscritto: 10/08/2018
Messaggi: 14

Pare che fosse un bug, esattamente il bug Bugzilla - Bug 1104121 e pare che abbiano risolto.
Spero.
Grazie

Stato : RISOLTO FISSO
Duplicati : 1104152 1104186 1104268 ( visualizza come elenco degli errori )
Classificazione: openSUSE
Prodotto: openSUSE Distribution
Componente: nocciolo
Versione: Salta 15.0
Hardware: Altro Altro
Priorità : P3 - Severità media: maggiore ( votazione )
Pietra miliare obiettivo : ---
Assegnato a : Takashi Iwai
Contatto QA: Elenco e-mail
URL:
Lavagna:
Parole chiave :
Dipende da:
blocchi:
Mostra albero / grafico di dipendenza

Crea un caso di prova

Clona questo bug

Segnalato: 2018-08-07 22:35 UTC di Neil Rickert
Modificata: 2018-08-10 15:14 UTC ( Cronologia )
Lista CC: 7 utenti
Guarda anche:
Trovato da: ---
Priorità dei servizi:
Priorità aziendale:
Blocker: ---

allegati
dattiloscritto dalla sessione ssh mentre GDM è display manager (6.52 KB, text / plain)
2018-08-07 22:36 UTC , Neil Rickert Dettagli
dattiloscritto dalla sessione ssh in cui SDDM è display manager (8.28 KB, testo / plain)
2018-08-07 22:37 UTC , Neil Rickert Dettagli
output "dmesg" con kernel vmlinuz-4.12.14-lp150.12.10-default (43.49 KB, text / plain)
2018-08-08 12:54 UTC , Neil Rickert Dettagli
output "dmesg" con kernel vmlinuz-4.12.14-lp150.12.7-default (39.72 KB, text / plain)
2018-08-08 12:57 UTC , Neil Rickert Dettagli
Visualizza tutto Aggiungi un allegato (patch proposta, testcase, ecc.)

Nota
È necessario accedere prima di poter commentare o apportare modifiche a questo bug.

Descrizione Neil Rickert 2018-08-07 22:35:35 UTC

User-Agent: Mozilla / 5.0 (X11; Linux x86_64; rv: 60.0) Gecko / 20100101 Firefox / 60.0
Build Identifier:

Questo è basato sull'esecuzione di Leap 15.0 in una macchina virtuale KVM dopo gli aggiornamenti applicati oggi.

L'avvio con il kernel precedente 4.12.14-lp150.12.7 va bene. Ma con il kernel più recente, non ottengo mai una schermata di accesso. Ho provato questo con GDM e SDDM come display manager. In entrambi i casi, non ho una schermata di accesso.

Sono in grado di accedere in remoto con 'ssh' a una shell di root (autenticazione publickey). Ho raccolto una piccola quantità di informazioni con GDM come display manager (file "typescript") e con SDDM come display manager (file "typescript.0"). Allegherò quei file.

Non riesco a spegnere la macchina dalla riga di comando ssh. Il tentativo di spegnersi si blocca. Ho dovuto forzare via lo spettatore da virt-manager.

Riproducibile: sempre

Commento 1 Neil Rickert 2018-08-07 22:36:34 UTC

Creato allegato 779145 [dettagli]
dattiloscritto dalla sessione ssh mentre GDM è display manager

Commento 2 Neil Rickert 2018-08-07 22:37:19 UTC

Creato allegato 779146 [dettagli]
dattiloscritto dalla sessione ssh in cui SDDM è display manager

Commento 3 Neil Rickert 2018-08-07 22:41:42 UTC

Avrei dovuto aggiungere:

Sono in grado di avviare una riga di comando, aggiungendo "3" alla linea di avvio del kernel.

Di solito uso "plymouth.enable = 0". Ma ho anche provato a sostituirlo con "splash = silent". Il risultato è lo stesso: non ho una schermata di accesso. In quest'ultimo caso, lo splash screen di plymouth si affievolisce, quasi a suggerire che è finito. Ma lo schermo sbiadito di Plymouth rimane lì.

Commento 4 Takashi Iwai 2018-08-08 06:30:10 UTC

Quale back-end grafico viene utilizzato? bochsdrm, cirro, qxl o virtio?
E se cambi il backend, il problema persiste?

In ogni caso, si prega di fornire l'output di dmesg da entrambi i kernel di lavoro buoni e cattivi.

Commento 5 Takashi Iwai 2018-08-08 09:34:14 UTC

Sto costruendo un kernel con il ripristino delle recenti correzioni atomiche di drm.
È in fase di costruzione in casa OBS: tiwai: os15.0-regressione regressione drm.
Ci vorrà del tempo (per circa un'ora). Si prega di fare un tentativo più tardi.

Commento 6 Takashi Iwai 2018-08-08 11:00:58 UTC

Potrei vedere un Oops con qxl usando anche l'ultimo kernel di aggiornamento.
Ma il problema sembra finito con l'ultimissima versione git, disponibile in OBS Kernel: openSUSE-15.0 repo.
Potresti fare un tentativo all'inizio?
http://download.opensuse.org/repositories/Kernel:/openSUSE-15.0/standard/

Commento 7 Neil Rickert 2018-08-08 12:54:58 UTC

Creato allegato 779206 [dettagli]
output "dmesg" con kernel vmlinuz-4.12.14-lp150.12.10-predefinito

Commento 8 Neil Rickert 2018-08-08 12:57:02 UTC

Creato allegato 779207 [dettagli]
output "dmesg" con kernel vmlinuz-4.12.14-lp150.12.7-default

Commento 9 Neil Rickert 2018-08-08 13:01:10 UTC

Usando QXL per la grafica. Non ho provato a cambiare, perché sembrava più importante testare prima il nuovo kernel.

Ho caricato "dmesg.good" e "dmesg.bad"

Ho installato "vmlinuz-4.12.14-lp150.100.g332f08c-default". Questo mi ha dato una violazione di sicurezza. Con secure-boot disabilitato, si avvia correttamente e ora sta funzionando.

Grazie per la risposta rapida.

Commento 10 Takashi Iwai 2018-08-08 13:04:34 UTC

OK, quindi sembra già stato risolto nel recente git branch. Buono a sapersi.

Proverò a inviare il kernel di aggiornamento poco dopo, poiché questo bug può colpire molte macchine.

Commento 11 Andreas Stieger 2018-08-08 18:22:58 UTC

*** Il bug 1104186 è stato contrassegnato come un duplicato di questo bug. ***

Commento 12 Andreas Stieger 2018-08-09 06:18:06 UTC

*** Il bug 1104268 è stato contrassegnato come un duplicato di questo bug. ***

Commento 13 Andreas Stieger 2018-08-09 06:25:35 UTC

*** Il bug 1104152 è stato contrassegnato come un duplicato di questo bug. ***

Commento 14 Swamp Workflow Management 2018-08-09 09:51:30 UTC

Questo è un messaggio generato automaticamente per l'integrazione di OBS:
Questo bug (1104121) è stato menzionato in
https://build.opensuse.org/request/show/628360 15.0 / kernel-source

Commento 15 Takashi Iwai 2018-08-09 13:00:26 UTC

Il prossimo aggiornamento del kernel che include la correzione per questo bug è in arrivo.

Commento 16 Marcelo Borro 2018-08-10 13:33:53 UTC

Dopo l'aggiornamento al kernel 4.12.14-lp150.12.13.1, non ho ancora un desktop funzionante. L'ultimo kernel funzionante è 4.12.14-lp150.12.7.1.

Questo ultimo aggiornamento era la "correzione" che doveva essere rilasciata? Se lo fosse, non funzionerebbe per me Sad

Commento 17 Takashi Iwai 2018-08-10 13:35:37 UTC

Per favore controlla il kernel nel kernel OBS: openSUSE-15.0: invia repo. Questa è la fonte del prossimo aggiornamento del kernel.

Se questo non aiuta il tuo computer, significa che hai riscontrato un bug diverso.

Commento 18 Marcelo Borro 2018-08-10 14:16:04 UTC

Il kernel nel kernel: openSUSE-15.0: Submit non funziona anche per me. Sto usando driver proprietari nvidia, dovrei aprire un nuovo bug?

Commento 19 Takashi Iwai 2018-08-10 14:17:46 UTC

(In risposta a Marcelo Borro dal commento n. 18 )
> Il kernel nel kernel: openSUSE-15.0: Submit non funziona anche per me. sono
> usando i driver proprietari nvidia, dovrei aprire un nuovo bug?

Sì grazie. Questo deve essere un bug totalmente diverso.

I problemi che sono stati gestiti in questo bug report riguardano la regressione atomica drm e che avrebbero dovuto essere risolti dall'aggiornamento. Ma questo è irrilevante con il materiale binario di Nvidia.

Commento 20 Marcelo Borro 2018-08-10 14:32:01 UTC

Ho aperto una nuova segnalazione di bug https://bugzilla.opensuse.org/show_bug.cgi?id=1104512

Commento 21 Michael di Offenbach Germania 2018-08-10 15:14:26 UTC

Ho aperto l' errore 1104268 , duplicato, non ho trovato questo errore anche se cercato.

Oggi ho la patch, installata, funziona ancora bene, RISOLTO Smile

GRAZIE MILLE !!!

Formato per la stampa - XML - Clona questo bug - Inizio pagina

Vmancini

Ritratto di Kff_ffK
Kff_ffK
(Monster)
Offline
Monster
Iscritto: 22/12/2004
Messaggi: 235

Salve a tutti.
Dopo gli aggiornamenti fatti ieri, che mi hanno portato al Kernel 4.12.14-lp150.12.16-default, ho avuto anch'io lo stesso problema descritto da Vima1940 nel primo post, ossia il blocco dell'avvio alla scritta "Started locale Service".
Io ho risolto così:
1) riavvio con il vecchio Kernel (il PC è partito regolarmente);
2) reinstallazione forzata di tutti i pacchetti relativi ai driver nVidia, da Yast2, scegliendo l'opzione "Aggiorna incondizionatamente".
A questo punto ho riavviato normalmente ed il PC è partito senza problemi.

Ciao a tutti.

OpenSuse Leap 15.0 64-bit
- Versione di KDE/Plasma: 5.12.6 - Versione di KDE Frameworks: 5.45.0
- Versione di Qt: 5.9.4 - Versione del Kernel: 4.12.14-lp150.12.16-default