Risposte al Forum Create
-
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 aggiungendoinit=/bin/bashalla 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.debugCiao,
se è avvenuto un crash del sistema mentre l’aggiornamento era in corso molti files dei pacchetti che erano in fase di aggiornamento potrebbero risultare mancanti o troncati, in particolare delle librerie o eseguibili importanti per l’avvio del sistema.
Un modo per diagnosticare e provare a correggere il problema è1) avviare il sistema live di openmamba ed effettuare il mount del root filesystem con i bind mount necessari. Il codice seguente tratto da
/usr/bin/sb-setupfornisce un suggerimento sui comandi da eseguire assumendo che il root filesystem sia il devie/dev/sda2:`
# Sample chroot mount:
# sudo mkdir /mnt/sda2
# sudo mount /dev/sda2 /mnt/sda2
# sudo mount -o bind /dev /mnt/sda2/dev
# sudo mount -o bind /sys /mnt/sda2/sys
# sudo mount -o bind /proc /mnt/sda2/proc
# sudo mount -o bind /run /mnt/sda2/run
# sudo mount -o bind /mnt/sda1 /mnt/sda2/boot/efi
# sudo mount -o bind /sys/firmware/efi/efivars /mnt/sda2/sys/firmware/efi/efivars/
`2) eseguire
chrootnel sistema:`
sudo chroot /mnt/sda2
`Si dovrebbe avviare una shell nell’ambiente chroot ma già a questo punto potrebbero verificarsi degli errori che danno indicazione di file e librerie che sono rimasti corrotti nel sistema.
3) devono essere reinstallati gli rpm cui si riferiscono i problemi, dall’esterno se il comando chroot di cui sopra, o il comando dnf, non funziona, altrimenti si può usare
sudo dnf reinstall ..da dentro chroot con la rete funzionante, questa procedura può essere più o meno complessa a seconda del grado di corruzione del filesystem.Riguardo al crash durante l’aggiornamento, come si capisce che si sia trattato di un kernel panic? L’ambiente desktop è switchato sulla console nera che ha fornito la segnalazione di KERNEL PANIC? Non vedo succedere questo tipo di problema da molto tempo con i kernel recenti e normalmente dovrebbe riferirsi ad un grave problema hardware.
Ciao,
da me anche una condivisione di cui non sia specificato il punto di mount viene montata con il seguente percorso e permessi:$ ls /media/sf_Shared/ -ld drwxrwx--- 1 root vboxsf 4096 28 ott 19.01 /media/sf_Shared/Sicuramente quello che non viene fatto automaticamente è che l’utente sia inserito nel gruppo
vboxfs, per cui ciò può essere fatto eseguendo questo comando:
sudo usermod --append --groups vboxsf nomeutenteNon so spiegare i problemi che riscontri nel tuo setup ma siccome mi sembra che tu abbia scritto che hai fatto modifiche tra cui disinstallare e reinstallare VirtualBox-guest potrebbe essere che questa operazione abbia creato un funzionamento inatteso ed il test da una nuova installazione che hai in programma potrebbe essere utile.
Ciao,
riscontro problemi simili e dubbi eseguendo openmamba da VirtualBox per openmamba.
Sembra che VirtualBox raccomandi l’emulazione VMSVGA, laddove questa rappresenta l’emulazione di VMWare ed a logica sembrerebbe più indicato usare VBoxSVGA e questo è un primo dubbio.
In entrambi i casi però al boot viene caricato il driver del kernel vmwgfx (quello di VMWare) che restituisce questi messaggi:[ 4.531450] vmwgfx 0000:00:02.0: [drm] *ERROR* vmwgfx seems to be running on an unsupported hypervisor. [ 4.531460] vmwgfx 0000:00:02.0: [drm] *ERROR* This configuration is likely broken. [ 4.531462] vmwgfx 0000:00:02.0: [drm] *ERROR* Please switch to a supported graphics device to avoid problem s.Questo permette di fare una ricerca che riconduce ad esempio a questo post. Qui si dice che il problema potrebbe risolversi disattivando Hyper-V sulla macchina host, che potrebbe avere senso, ma non ho provato.
Su openmamba è installato VirtualBox-guest che attiva il servizio vboxdrmclient, che tuttavia dovrebbe servire più che altro per le integrazioni del display con l’host, ad esempio il ridimensionamento automatico.
Questo è quanto, al momento non so se e cosa ci possa essere da modificare nei client di openmamba.
