A prima vista sembrano problemi su sostituzione dei vecchi pacchetti con i nuovi di plasma6, mi pare siano relativamente pochi, io proverei la rimozione con opzione nodeps, se usi dnfdrake la trovi in extra, altrimenti da console usa il comando:
sudo rpm -evh --nodeps nomepacchetto
se usi la console prendi nota di quello che rimuovi per reinstallarlo con i nuovi pacchetti equivalenti ad aggiornamento finito, probabilmente non sarà necessario perchè tirato dietro da qualche dipendenza. Con dnfdrake il log viene creato in automatico.
Chiaramente essendo una procedura non standard comporta qualche rischio da valutare in corso d’opera
Io ho seri problemi: stamattina ho acceso il pc e dopo essermi loggato ottengo una bella schermata nera. Avviando in console mode riesco poi ad avviare x, ma il sistema funziona male e non permette di fare aggiornamenti. Ho reinstallato e per prima cosa ho aggiornato: a metà aggiornamento lo schermo è ridiventato nero. Ho tentato altre 2 volte, ma niente da fare. Per adesso mi tengo un sistema non aggiornato, ma l’idea non mi piace. Non posso fornire alcun log perchè semplicemente il computer non si riavvia.
Alla fine dopo un po’ di rimozioni di pacchetti e aggiornamenti parziali usando dnfdragora sono riuscito ad aggiornare il sistema. Devo però ammettere che finora non ho mai riscontrato così tante difficoltà come questa volta.
Ho dovuto installare dnfdrake al posto di dragora e, per quanto più completo, ha mostrato problemi nel riconoscere la differenza tra il nuovo e il vecchio kernel: dopo aver selezionato le voci del 6.14.2.3 per rimuoverlo, mi ha risposto che l’operazione non era possibile perché avrebbe eliminato quello in uso, che però è il 6.17.7.1
Ciao, credo che il problema sia dovuto al nome dei due kernel che vengono identificati entrambi come kernel-desktop.x86_64 e dnf seleziona di default quello più recente.
Per ovviare basta usare uno di questi due metodi:
scrivere il nome completo del pacchetto del kernel nel box di ricerca e senza avviare la ricerca cliccare su disinstalla
usare la funziona nodeps attivabile in extra e poi nel box che compare
A seconda dei casi uso l’una o l’altra soluzione.
Effettivamente la cosa non è proprio intuitiva, ma anche disinstallare un kernel non è un’operazione così comune.
Ok, pensavo fosse un bug, invece è solo un problema (credo) di regexp.
Per il resto, molto semplicemente ho rimosso il vecchio kernel da riga di comando.
Su altri sistemi l’autoremove oltre ai paccketti obsoleti elimina anche i vecchi kernel non più in uso: non sarebbe male inserirlo anche su dnfdrake, magari come opzione (forse qualcuno li tiene, ma per quanto mi riguarda trovo che mantenerli sia un’inutile spreco di spazio).
In ogni caso, in generale il sistema funziona bene: mi resta da risolvere qualche problema con il mouse che non risponde a dovere in alcune situazioni e c’è “adb” che continua ad andare in crash all’avvio
Adesso sembra funzionare. Noto qualche stranezza, come il link a Calamares per installare il sistema (come nella live).
Suggerirei anch’io una modifica a dnfdrake: dnfdragora permetteva di fare ricerche non solo per nome, ma anche per spiegazioni, file o riassunti. Adesso se non ricordo il nome di un file, ma solo la sua funzione, non so come cercarlo.
ho provato una ISO con wailand e sembra funzionare. Credo che il problema sia proprio la combinazione xlibre con gpu AMD a creare problemi, perch[ su un pc con Intel fuzionano tutte le ISO che hp provato.
Ho avuto parecchi problemi e blocco del sistema come riportati in questa discussione. Il sistema che avevo prima dell’aggiornameno di novembre 2025 usava x11. La soluzione al problema l’ho ottenuta riparando il sistema con le istruzioni dei seguenti post:
Ora funziona quasi tutto avendo ripristinando Openmandriva aggiornato. Il ripristino ha mantenuto tutte le vecchie impostazioni. Il sistema parte con Wayland, con X11 non parte, ci sono ancora errori che non ho ancora avuto il tempo di verificare e correggere.
Mi aggiungo: ho notevoli problemi con determinati pacchetti che pur presenti nei repo, non si possono installare poiche’ mancano alcune dipendenze fondamentali, altri (ad esempio Kexi) si installano ma non funzionano per mancanza di certe dipendenze.
Quanto a DnfDragora, questo e’ cio’ che restituisce dnf:
____________________________________________________
sudo dnf install dnfdragora.x86_64 | tee /dev/null
Aggiornamento e caricamento dei repository:
Repository caricati.
Impossibile risolvere la transazione:
Problema: il pacchetto dnfdragora-2.99.1-1.x86_64 da rolling-x86_64 richiede lib64yui-qt, ma nessuno dei fornitori può essere installato
- richieste in conflitto
- nessun pacchetto fornisce libcgraph.so.6()(64bit) richiesto da lib64yui-qt-4.6.2-8.x86_64 da rolling-x86_64
- nessun pacchetto fornisce libgvc.so.6()(64bit) richiesto da lib64yui-qt-4.6.2-8.x86_64 da rolling-x86_64
____________________________________________________
Ora, al di la del fatto che DNFDragora x me sarebbe piu’ comodo x vari motivi (suddivisione dei pacchetti per funzione, ricerca piu’ completa nelle informazioni ecc.) il problema affligge molti altri pacchetti, e’ generalizzato, in modo casuale credo.
