[Silvan]

Ciao,
il problema, se corrisponde con quanto già noto, è sorto con l’aggiornamento di libxml2 alla versione 2.14. Il consiglio è di effettuare una-tantum l’aggiornamento da una finestra di terminale con il comando:

sudo dnf update --refresh

in quanto il problema risulta limitato soltanto al sottosistema di gestione degli aggiornamenti nell’ambiente grafico (PackageKit).

[Silvan]

Scusa, dimenticavo che per wine bisogna installare anche libwine.i586:

sudo dnf install libwine.i586

[Silvan]

L’eseguibile wine si riferisce alla versione a 32 bit, comunemente usata, mentre installando il pacchetto wine è stato installato wine64.
Per questo pacchetto particolare in openmamba bisogna installare wine a 32 bit con il seguente comando:

sudo dnf install wine-core.i586

[Silvan]

Ciao,
i pacchetti goverlay, mangohud e gamescope sono ora disponibili nel repository di openmamba.

Per quanto riguarda l’estrazione di pacchetti rpm da GUI mi risulta che si possa già fare con ark.

[Silvan]

Il browser Brave è disponibile come rpm nel repository di openmamba. Fornisce la versione binaria distribuita upstream pertanto il pacchetto da installare si chiama brave-bin (architetture x86_64 e aarch64).

[Silvan]

Ciao,
grazie per i suggerimenti sui pacchetti da aggiungere, quando possibile saranno valutati ed eventualmente aggiunti nei repository di openmamba.

Per quanto riguarda hypnotix e altri pacchetti che forniscono applicazioni per il desktop, si tratta di aggiungere un file di meta informazioni nel formato definito dal progetto AppData, cosa che ho fatto in un aggiornamento di release di hypnotix che sarà presto disponibile.

Discover, secondo l’ottica di essere un “App store”, mostra come installabili soltanto i pacchetti che forniscono applicazioni per il desktop, assumendo che l’installazione di strumenti per la console o librerie ed altro per sviluppatori sia contestualizzabile all’installazione da linea di comando. Un’interfaccia già presente in openmamba che mostra tutti i pacchetti disponibili è dnfdragora, che è lo strumento di installazione e aggiornamento preinstallato sul desktop LXQt al posto di Discover.

Riguardo alla funzione “spoiler”, intendi la possibilità di includere immagini in un post facendo in modo che siano visualizzate solo su interazione dell’utente? Il forum di openmamba si basa sul plugin bbpress e si tratta di vedere se questo tipo di funzionamento sia in qualche modo possibile perché non prevedo al momento disponibilità nel fare sviluppi personalizzati su questo.

[Silvan]

Grazie per le informazioni più precise. Dalla descrizione e dallo screenshoot mi sembra che stai lanciando openmamba dal bootloader di Fedora e che quest’ultimo l’abbia configurato con un errore sintattico, ovvero attaccando i percorsi di /boot/amd_ucode.img con /boot/initramfs con il carattere “^”.

Se questa è la situazione, il grub di openmamba non viene usato, quindi è anche inutile aggiornarlo con update-grub. Il problema sembrerebbe essere nel grub di Fedora. Certo, se rimuovi i file di microcode (magari basta rimuovere quello che non corrisponde con la tua architettura nel caso in cui il problema sia aggiungere più di due file .img) e rilanci lo script su Fedora probabilmente sistemi il boot ma volendo risolvere alla radice il problema penso che bisognerebbe indirizzarsi su Fedora.

Se vuoi, per conferma del problema, puoi postare e guardiamo la sezione di grub.cfg di Fedora riguardante openmamba.

• Questa risposta è stata modificata 3 months, 2 weeks fa da Silvan.

[Silvan]

idran wrote:

Confermo quanto scritto da Silvan. Il comando da terminale ha funzionato. Ma prima di arrivare al login ho avuto un problema. Il grub diceva che *non* trovava /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-6.12.16-1mamba-x86_64.img e si bloccava.

Ho provato l’installazione del livecd e non risulta questo problema, usi la modalità di boot EFI o BIOS? Per gli scopi del supporto di openmamba, che consiste nel risolvere problemi per tutti gli utenti potenziali, sarebbe interessante conoscere con maggiore precisione il messaggio di errore fornito da grub, perché se, come scritto, indicasse che non trova i file di microcode e neanche l’initramfs, il problema sembrerebbe essere altro. Nella cartella /boot ci sono tutti e tre i file immagine e quindi l’errore deve essere specificato e compreso meglio. Potrebbe essere che un file di microcode blocchi l’avvio e ciò sarebbe più comprensibile rispetto a quanto leggo qui sopra.

In un aggiornamento prossimo si farà in modo che i pacchetti di microcode siano impostati come dipendente “deboli” in modo che l’utente possa disisntallarli, ricordavo in realtà che fosse già così, tuttavia l’interesse di dare supporto qui consiste nel capire e risolvere il problema a livello di distribuzione e considerando che tali file non sono forniti giusto per arrecare disturbo ma hanno un’utilità precisa per gli aggiornamenti di sicurezza e funzionali delle CPU.

A livello di utente che si autoaggiusta la propria installazione, prima dell’aggiornamento di cui sopra, per adesso puoi cancellare i file /boot/amd-ucode.img e /boot/intel-ucode.img e lanciare:
sudo update-grub

• Questa risposta è stata modificata 3 months, 2 weeks fa da Silvan.
• Questa risposta è stata modificata 3 months, 2 weeks fa da Silvan.

[Silvan]

Come principale alternativa a Firefox nel repository è disponibile e mantenuto Chromium. Per quanto riguarda Brave,  metto in programma di verificare e possibilmente aggiungerlo tra i pacchetti di openmamba nel prossimo futuro.

[Silvan]

Ciao,
ho verificato che il problema è sorto nell’ultima versione dei supporti live di installazione (livecd 20250313). Ho effettuato una correzione e programmerò al più presto un rilascio delle immagini ISO aggiornate.

Nel frattempo è possibile bypassare il problema senza aspettare l’aggiornamento aprendo una finestra di terminale (konsole) ed eseguendo il seguente comando:
sudo mv /usr/lib/calamares/modules/openmamba-postinstall /usr/lib64/calamares/modules/

Grazie per la segnalazione.

• Questa risposta è stata modificata 3 months, 2 weeks fa da Silvan.

[Silvan]

Buonasera,
ho creato il pacchetto strawberry ma sarà rilasciato nel repository base entro qualche giorno perché dipende dall’aggiornamento di Qt6 alla versione 6.8.2 che è in fase di completamento.

[Silvan]

Ciao,

dovrebbe servire il plugin per NetworkManager, che ho appena creato, si installa con:

sudo dnf install networkmanager-l2tp

Non ho l’accesso ad un endpoint per fare un test, se ci fossero problemi consiglio di guardare i messaggi che compaiono nel journal di sistema quando si tenta di attivare la connessione:

sudo journalctl -f

 

[Silvan]

Il problema mi risulta che dovrebbe essere risolto dall’aggiornamento dei componenti di ffmpeg (in particolare libavcodec) che dovrebbe essere disponibile per tutti gli utenti nelle prossime ore.

[Silvan]

Ciao,
bene che sia riuscito a ripristinare in parte l’avvio del sistema.

Nel caso di un PC “troppo” recente si poteva ipotizzare che il crash potesse dipendere con maggiore probabilità da un bug del kernel LTS su questo hardware ma non mi sembra il caso se il PC ha 5-6 anni. Quindi al momento per sperare di trovare una spiegazione a questo evento bisogna attendere che succeda di nuovo e tanto meglio se non ricapita.

Invece è chiaro il motivo per cui il sistema non ripartiva dopo il crash avvenuto durante gli aggiornamenti e come risolverlo, anche se andare a reinstallare tutti i pacchetti che erano in fase di aggiornamento non è una procedura proprio comoda, in particolare se non è disponibile l’elenco dei pacchetti che erano in corso di aggiornamento, la cronologia di dnf potrebbe riportare l’elenco solo se salvato su disco prima del crash. Inoltre i files relativi agli aggiornamenti interrotti in corso d’opera saranno rimasti nel filesystem con un nome temporaneo con l’aggiunta di un hash (es. /usr/lib64/libsystemd.so.0.39.0.xasffdsa) e sarebbero da cancellare, l’unica cosa positiva è che rilevare questi file può aiutare a individuare i pacchetti che necessitano di reinstallazione.

[Silvan]

Dalla seconda immagine noto la versione del BIOS che potrebbe denotare un hardware relativamente recente a meno che non sia recente l’aggiornamento del BIOS stesso.
Il problema si verifica durante lo switch del filesystem dal quale dovrebbero essere caricati ed eseguiti lo stesso systemd ed altri componenti che potrebbero essere stati corrotti durante l’aggiornamento.
Se il problema sembra evidentemente conseguenza dell’aggiornamento potrebbe essere utile capire la portata di questo aggiornamento, ovvero potrebbe aver aggiornato i componenti di un certo giorno, dell’ultima settimana, mese o più, a seconda di questa informazione si definisce la misura del campo delle possibili cause, se dipende dall’aggiornamento di qualche componente.
Tra i vari metodi di debugging ci sono anche:
1) invece di avviare systemd, dopo lo switch del filesystem di root si può provare ad avviare una shell aggiungendo init=/bin/bash alla riga di comando del kernel, questo semplificherebbe la diagnostica e possibilità di intervenire sul filesystem
2) si può attivare un maggiore logging di debug aggiungendo parametri alla riga di comando del kernel, ad esempio per systemd: systemd.log_level=debug, per dracut: rd.debug

• Questa risposta è stata modificata 6 months, 2 weeks fa da Silvan.
• Questa risposta è stata modificata 6 months, 2 weeks fa da Silvan.
• Questa risposta è stata modificata 6 months, 2 weeks fa da Silvan.
• Questa risposta è stata modificata 6 months, 2 weeks fa da Silvan.

[Autore]

Articoli