Risoluzione dei problemi

Fedora Kinoite è un nuovo modo di distribuire e gestire il sistema operativo desktop, quindi potresti occasionalmente riscontrare problemi durante l’uso quotidiano. Di seguito sono elencati alcuni dei problemi più comuni segnalati e le eventuali soluzioni alternative per tali problemi.

"Sostituzioni vietate di pacchetti base"

Questo può accadere quando un pacchetto che viene stratificato ha una dipendenza da un pacchetto che si trova nel sistema operativo di base. Nel caso problematico, il pacchetto stratificato richiede una versione più recente del pacchetto dipendente che non è disponibile nel sistema operativo di base.

Nella maggior parte dei casi, attendere una nuova compose OSTree risolverà questo problema. Il pacchetto dipendente verrà aggiornato nella compose e il pacchetto che doveva essere stratificato verrà installato con successo.

Tuttavia, se continui a riscontrare questo problema con una compose più recente, puoi provare a pulire i metadati con rpm-ostree cleanup -m e poi ritentare l'`rpm-ostree install`.

In alternativa, puoi provare a fare un rebase su qualsiasi ref di updates, come fedora/30/updates/x86_64 dopo l’operazione di cleanup.

Per maggiori informazioni, vedere rpm-ostree#415.

Installazione di pacchetti in /opt o /usr/local

L’installazione in /opt è stata comunemente segnalata come un problema quando gli utenti cercavano di installare Google Chrome. Una soluzione parziale è stata implementata e consente agli utenti di stratificare Google Chrome, tuttavia non è una soluzione completa per le applicazioni che scrivono dati mutabili in /opt.

Questo problema è tracciato in rpm-ostree#233.

Utilizzo dei driver NVIDIA

È possibile installare i driver binari ufficiali NVIDIA dai repository RPM Fusion.

I driver binari NVIDIA non sono mantenuti dal Progetto Fedora e talvolta potrebbero non essere disponibili per la versione del kernel inclusa in Fedora Kinoite.
Il progetto Universal Blue crea immagini del sistema operativo per Fedora Kinoite con i driver NVIDIA inclusi. Le immagini Universal Blue si basano sulle immagini ufficiali Fedora con modifiche aggiuntive a loro discrezione. Le immagini Universal Blue non sono ufficialmente approvate dal Progetto Fedora. Usale a tua discrezione.

  1. Innanzitutto, assicurati che il tuo sistema sia completamente aggiornato eseguendo sudo rpm-ostree upgrade e riavviando.

  2. Quindi configura i repository RPM Fusion seguendo la documentazione, inclusi i due riavvii.

  3. Infine, installare i driver:

    # rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
# rpm-ostree kargs --append=rd.driver.blacklist=nouveau --append=modprobe.blacklist=nouveau --append=nvidia-drm.modeset=1 --append=initcall_blacklist=simpledrm_platform_driver_init
# systemctl reboot
Quando si utilizza Secure Boot, i driver NVIDIA installati localmente devono essere firmati con una chiave locale registrata tramite mokutil. Vedere il problema fedora-silverblue#499 per maggiori dettagli.

Potresti anche riscontrare i seguenti problemi durante l’installazione: #286, #331

Grazie a Alex Larsson che ha apportato le modifiche necessarie ai pacchetti akmods e kmodtools. Puoi leggere di più sul lavoro svolto da Alex sul suo blog.

Moduli kernel e driver non inclusi nell’albero sorgente (out of tree) che usano DKMS

Fedora Kinoite attualmente non supporta DKMS. Vedere il problema upstream rpm-ostree#1091.

Invece, ti consigliamo di creare pacchetti kmods per i moduli kernel non inclusi nell’albero sorgente e di inviarli ai repository RPM Fusion. I pacchetti kmods verranno quindi utilizzati da akmods che è supportato su Fedora Kinoite.

Aggiunta di repository di pacchetti esterni

Questa sezione discute di sorgenti software di terze parti non ufficialmente affiliate o approvate dal Progetto Fedora. Usale a tua discrezione.
Se desideri utilizzare i repository RPM Fusion, segui la sezione Abilitazione dei repository RPM Fusion.

Alcuni software potrebbero essere disponibili solo da un repository di terze parti. Puoi aggiungere manualmente un repository esterno su Fedora Kinoite inserendo il file .repo in /etc/yum.repos.d/ e la chiave GPG in /etc/pki/rpm-gpg/. Di seguito è riportato un esempio completo per la configurazione del repository Tailscale:

  1. Recuperare e installare la configurazione del repository:

    $ curl -O https://pkgs.tailscale.com/stable/fedora/tailscale.repo
[tailscale-stable]
name=Tailscale stable
baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch
enabled=1
type=rpm
repo_gpgcheck=1
gpgcheck=0
gpgkey=https://pkgs.tailscale.com/stable/fedora/repo.gpg
$ sudo install -o 0 -g 0 -m644 tailscale.repo /etc/yum.repos.d/tailscale.repo

  2. Recuperare e installare le chiavi GPG:

    $ curl -O https://pkgs.tailscale.com/stable/fedora/repo.gpg
$ sudo install -o 0 -g 0 -m644 repo.gpg /etc/pki/rpm-gpg/tailscale.gpg

  3. Sostituire l’URL gpgkey= nella configurazione del repository con il percorso delle chiavi GPG:

    $ sudo $EDITOR /etc/yum.repos.d/tailscale.repo
$ cat /etc/yum.repos.d/tailscale.repo
[tailscale-stable]
name=Tailscale stable
baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch
enabled=1
type=rpm
repo_gpgcheck=1
gpgcheck=0
# Aggiorna questa riga
gpgkey=file:///etc/pki/rpm-gpg/tailscale.gpg
#      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  4. Installare i nuovi pacchetti con:

    $ rpm-ostree install tailscale

Un migliore supporto in rpm-ostree per questo caso d’uso è tracciato in rpm-ostree#4014.

Problemi con SELinux

Durante l’uso quotidiano di Fedora Kinoite, è possibile che gli utenti abbiano modificato la policy SELinux predefinita nel tentativo di risolvere uno o più problemi relativi a SELinux. Questo di solito accade quando un utente visualizza una negazione di SELinux nel journal. Se questo è il caso e si desidera ripristinare la policy SELinux predefinita, è possibile provare questa serie di azioni.

  1. Controllare lo stato della policy SELinux

    $ sudo ostree admin config-diff | grep policy
M    selinux/targeted/active/policy.linked
M    selinux/targeted/active/policy.kern
M    selinux/targeted/policy/policy.31
A    selinux/targeted/policy/policy.30

    Se questo comando restituisce qualcosa, allora la tua policy SELinux è stata modificata rispetto a quella predefinita.

  2. Copiare la policy SELinux predefinita fornita nel compose OSTree

    $ sudo cp -al /etc/selinux{,.bak}
$ sudo rsync -rlv /usr/etc/selinux/ /etc/selinux/

    Dopo aver fatto ciò, l’output di ostree admin config-diff | grep policy non dovrebbe più indicare che la policy è modificata.

    Se la tua policy sembra ancora modificata, puoi provare il seguente approccio.

  3. Rimuovere la policy SELinux; copiare la policy predefinita

    $ sudo rm -rf /etc/selinux
$ sudo cp -aT /usr/etc/selinux /etc/selinux

    Dopo questo, il comando ostree admin config-diff | grep policy non dovrebbe restituire alcuna modifica.

Impossibile aggiungere l’utente a un gruppo

A causa del modo in cui rpm-ostree gestisce le voci utente + gruppo, potrebbe non essere possibile utilizzare usermod -a -G per aggiungere con successo un utente a un gruppo. Fino a quando rpm-ostree non passerà a utilizzare systemd sysusers, gli utenti dovranno popolare il file /etc/group dal file /usr/lib/group prima di potersi aggiungere al gruppo.

Ad esempio, se si desidera aggiungere un utente al gruppo libvirt:

$ grep -E '^libvirt:' /usr/lib/group | sudo tee -a /etc/group
$ sudo usermod -aG libvirt $USER
Sarà necessario disconnettersi e riconnettersi per applicare queste modifiche.

Questo problema è tracciato in rpm-ostree#29 e rpm-ostree#49.

ostree fsck segnala corruzione di file

È possibile trovarsi in una situazione in cui uno o più file sul disco si sono corrotti o sono mancanti. In questo caso, ostree fsck segnalerà errori in determinati commit. La soluzione alternativa in questo caso è marcare l’intero commit OSTree come parzialmente recuperato e quindi scaricare nuovamente il commit.

/boot/efi in sola lettura impedisce qualsiasi aggiornamento

Questo problema si verifica più comunemente quando gli utenti hanno installato Fedora Kinoite su hardware Apple. La partizione /boot/efi su hardware Apple è formattata come HFS+ e non è sempre resiliente a interruzioni di corrente o altri tipi di eventi di alimentazione anomali.

Poiché Fedora Kinoite ora include il pacchetto hfsplus-tools nella compose di base, è diventato relativamente facile per gli utenti risolvere questo tipo di errore.

# umount /boot/efi
# fsck.hfsplus /dev/sda1
# mount -o rw /boot/efi

Vedere il problema GitHub rpm-ostree#1380 per ulteriori dettagli.

Impossibile installare Fedora Kinoite su sistemi EFI

Gli utenti hanno segnalato di non riuscire a installare Fedora Kinoite su un sistema basato su EFI in cui avevano precedentemente installato un altro sistema operativo. L’errore che si osserva spesso è simile a:

ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-workstation', 'fedora-workstation:fedora/28/x86_64/workstation'] exited with code -6`

Esistono un paio di possibili soluzioni alternative:

  • Durante il processo di installazione, selezionare "Partizionamento personalizzato" e creare una partizione EFI aggiuntiva. Assegnare la partizione EFI appena creata a /boot/efi. Sarà quindi possibile avviare i sistemi operativi precedenti insieme a Fedora Kinoite. Se questa soluzione alternativa non ha successo, seguire il passaggio sottostante.

  • Riformattare la partizione EFI sull’host durante il processo di installazione. Questo può essere fatto selezionando "Partizionamento personalizzato" e selezionando la casella Riformatta durante la creazione della partizione /boot/efi.

La scelta di riformattare /boot/efi comporterà probabilmente l’impossibilità di avviare qualsiasi altro sistema operativo precedentemente installato. Assicurati di aver eseguito il backup di tutti i dati importanti prima di utilizzare questa soluzione alternativa.

Questo problema è tracciato in Bugzilla #1575957.

toolbox: failed to list images with com.redhat.component=fedora-toolbox

A partire dalla versione 1.4.0 di podman, questa soluzione alternativa non è necessaria. Assicurati che podman sia aggiornato eseguendo rpm-ostree upgrade prima di tentare questa soluzione alternativa.

Quando si esegue il comando toolbox list, i sistemi che utilizzano versioni di podman più recenti di 1.2.0 genereranno il seguente errore:

toolbox: failed to list images with com.redhat.component=fedora-toolbox
La seguente soluzione alternativa potrebbe essere utile per altri errori di toolbox causati da versioni di podman superiori a 1.2.0. Vedere Repository Github di Toolbox

Come soluzione alternativa, è possibile sovrascrivere i pacchetti podman più recenti della versione 1.2.0 eseguendo:

$ rpm-ostree override --remove=podman-manpages replace https://kojipkgs.fedoraproject.org//packages/podman/1.2.0/2.git3bd528e.fc30/x86_64/podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm

Riavviare il sistema per applicare le modifiche.

Per riferimento, è anche possibile sovrascrivere il pacchetto seguendo questi passaggi:

  1. Scaricare podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm da Koji

  2. Rimuovere podman-manpages eseguendo: rpm-ostree override remove podman-manpages

  3. Sovrascrivere il pacchetto podman attualmente installato (utilizzando il pacchetto scaricato nel primo passaggio) con: rpm-ostree override replace podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm

È ora possibile riavviare il sistema affinché la modifica abbia effetto.

Per annullare questa soluzione alternativa, eseguire il seguente comando:

$ rpm-ostree override reset podman; rpm-ostree override reset podman-manpages

Impossibile accedere a un toolbox a causa di errori di autorizzazione

Con alcune versioni di podman, il tentativo di accedere a un toolbox provocherà errori. È possibile risolvere questo problema reimpostando le autorizzazioni sui container overlay con il seguente comando.

$ sudo chown -R $USER ~/.local/share/containers/storage/overlay-containers

Questo reimposterà le autorizzazioni sui tuoi container e ti permetterà di accedervi di nuovo.

Vedere il problema upstream di podman: podman#3187.

Esecuzione di restorecon

Non dovresti mai eseguire restorecon su un host Fedora Kinoite. Vedere il seguente bug per i dettagli - https://bugzilla.redhat.com/show_bug.cgi?id=1259018

Tuttavia, se ti è capitato di farlo, è possibile recuperare.

  1. Avviare con enforcing=0 sulla riga di comando del kernel

  2. Creare un nuovo commit "corretto" localmente

  3. Distribuire il nuovo commit "corretto"

  4. Eseguire restorecon

  5. Riavviare

  6. Pulizia

$ rpm-ostree status -b | grep BaseCommit
                BaseCommit: 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee
$ sudo ostree checkout -H 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee /ostree/repo/tmp/selinux-fix
$ sudo ostree fsck --delete
$ sudo ostree commit --consume --link-checkout-speedup --orphan --selinux-policy=/ /ostree/repo/tmp/selinux-fix
$ sudo restorecon -Rv /var
$ sudo restorecon -Rv /etc
$ sudo ostree admin deploy fedora:fedora/41/x86_64/kinoite
$ sudo reboot

L’avvertenza di questo recupero è che i tuoi pacchetti stratificati verranno rimossi; dovrai stratificarli nuovamente dopo il recupero.

Vedere questo commento upstream per ulteriori dettagli: ostree#1265.

Reimpostazione delle password in modalità di ripristino

Nel caso in cui non si riesca a ricordare la password utente o la password di root, è possibile reimpostare la password seguendo i seguenti passaggi.

  1. Mentre il sistema si sta avviando, interrompere la sequenza di avvio al menu GRUB2 utilizzando il tasto Esc.

  2. Selezionare la voce di avvio che si desidera modificare usando i tasti freccia.

  3. Modificare la voce selezionata con il tasto e.

  4. Usare i tasti freccia per selezionare la riga che inizia con linux, linux16 o linuxefi.

  5. Andare alla fine di quella riga e aggiungere init=/bin/bash alla fine della riga.

  6. Premere Ctrl-x o F10 per avviare la voce.

  7. Al prompt bash risultante, eseguire i seguenti comandi:

# mount -t selinuxfs selinuxfs /sys/fs/selinux
# /sbin/load_policy
# passwd
# sync
# /sbin/reboot -ff

Se si desidera cambiare la password per un account utente, sostituire il comando passwd con passwd <nomeutente>.

Dopo che il sistema ha terminato il riavvio, dovresti essere in grado di accedere con il nome utente e la nuova password.

Want to help? Learn how to contribute to Fedora Docs ›