ROME(rolling) upgrade should be safe to proceed (2024-11-24)

Hello,

  • OpenMandriva Lx version:

ROME(rolling)

  • Desktop environment (KDE, LXQT…):

Plasma5, Plasma6, LXQt

  • Description of the issue (screenshots if relevant):

Safe to upgrade since most recent major upgrade if you read the article below.
User should use sudo dnf --refresh dsync from terminal (Konsole) or maybe better sudo dnf clean all ; sudo dnf dsync.

  • Relevant informations (hardware involved, software version, logs or output…):

WARNING Pay attention to this article.

You have been warned! However if you don’t read that article it does show how to correct the problem. But you will have to read the article then so go ahead and read it now.

1 Like

Rock users may want to pay attention to this or better yet test this as this is close to what will be the next Rock/5.1/6.0 release.

Upgraded with no problems at all.

1 Like

Mi correggo:
2 problemi si sono evidenziati lanciando la Virtual Box.

  1. Quando lancio il gestore VirtualBox mi esce la schermata (fig. 1), e devo premere più volre il pulsante annulla, per vedere far partire l’applicazione. Va da sé che né la password di utente né quella di root vengono accettate.
  2. Quando provo ad aggiornare la extension Pack nella versione ultima corrispondente, mi esce la stessa schermata (fig1), devo premere due vota annullla, e quando tento di aggiornare mi segnala errore (fig.2).

fig.1

Spesso e volentieri, inotre, nel tentare queste operazioni mi chiude la sessione.

Ho provato a reinstallare ma il problema si ripresenta.
Posso rimediare in qualche modo?

Digita la password e fai eseguire. Quale sarebbe il problema?
Postedit: potrebbe presentarti più finestre di dialogo, inserisci la password ogni volta.
Se non funziona in quel modo si prova a dare il comando da console.
Per favore spiega meglio, perchè se c’è un malfunzionamento è bene saperlo :wink:

Forse dopo dovrai riavviare.

Non accetta la password: dice autenticazione non riuscitasi con password utente, si root.

Fatto, stessi problemi, con questo avviso:

[alangea@alangea-systemproductname ~]$ VirtualBox
Error executing command as another user: Not authorized

This incident has been reported.

punto 1. La diagnostica mi ha suggerito di provare col comando sudo VirtualBox.
In questo modo mi è comparsa un finestra del gestore VirtualBox nuova di zecca, che non vedeva i dischi virtuali. Io li ho importati poi ho chiuso, e ho provato a far ripartire normalmente il gestore, sia da comando console, sia cliccando sull’icona da menu, e tutto pare si sia normalizzato.
punto 2. Poiché il problema nell’extension pack si presentava ancora, ho aggiornato l’extension pack col comando sudo VirtualBox “extension pack” e son riuscito ad aggiornarlo.
Poi ho chiuso, ed ho riprovato nel modo standard: chiedeva di reinstallare l’extension ultima, segno che anche in questa modalità l’estensione era stata aggiornata. Tuttavia, se provavo a reinstallare, dava ancora errore. Poco male, l’importante è che funzioni.
Ma si tratta di anomalie, che comunque segnalano qualche problema; forse nell’aggiornamento di questo pacchetto VirtualBox si sono sporcati i parametri di autorizzazione, o qualcosa dl genere.
Sputno comunque il problema come risolto, ma penso sia opportuno che qualcuno bravo indaghi.
Se serve qualche ulteriore informazione da parte mia, chiedete pure, cercherò di esser più chiaro.

Change in VirtualBox behavior (2024-11-27)

Questo avviso di solito spunta quando dai un comando da utente mentre dovrebbe essere dato come amministratore. Hai messo sudo (oppure aperto una console di root)?
Esempio:
sudo rmmod kvm

sudo rmmod kvm_intel
e/o
sudo rmmod kvm_amd

Non mi sembra un buon suggerimento avviare i programmi come root.

Ho lanciato il comando VirtualBox da konsole come utente, e mi è uscito quello.

Ho solo provato a vedere che succedeva. Aprendo VirtualBox da root riuscii ad installare la nuova versione di Extension Pack. Inoltre, lanciando da utente normalmente, ora non escono più le finestre che chiedono la passwd root per avviare kvm, e risulta installata la extension pack ultima. Dava ancora errore nella reinstallazione di Extension Pack, oltre a chiedere ancora di aprire kvm.
Ho rimosso kvm_intel e kvm , e stavolta mi chiede solo la passwd supeuser, ma accetta solo quella utente: penso ci sia qualche pasticcio, perché pur essendo la password del superutente diversa da quella utente (come si vede se entro con su) diverse applicazioni che richiedono la passwd superuser accettano solo quella utente.
In ogni caso, dopo la rimozione dei kvm la re-installazione ha proceduto senza errori.

Do I need to remind that this is an English language forum? If I can use a translator when I use other language forums I expect that people that don’t write in English can do the same here.

The following is from my limited, user level, knowledge:

When users install OMLx and use separate passwords for user and administrator here is what I think happens. The administrator password is the root or superuser password. The first user created is declared as the sudoer or sudo. When opening applications some require no password, some require root password, and some require sudo password.

I do not see this because I use the same password when installing for user and administrator. If other people use your computer it is very easy to create a user account for them which by default will have limited permissions.

Should this be more consistent in Linux or OMLx? Probably.
Is this because upstream projects are not consistent? Not sure but my guess is probably.
Will OMLx “fix” this any time soon. Unlikely unless we attract a few more developers. Besides this is not something that is “broken” it is users not understanding something.

I doubt that when OM devs are building packages that they are changing how upstream projects “call” or open packages.

Finally as I recall most dialog windows tell us if they are asing for admin or sudo password but I will be keeping an eye on this for a while now that the issue has come up. It certainly seems like they should specify which.

Funziona, ma al reboot mi ritrovo ancora installato kvm e /o kvm_intel.
Potrei metterlo in *sudo rmmod kvM2 in *.bash ?

Here, in /etc/modprobe.d/blacklist-omv.conf
added:

# aggiunto 2024.12.04
blacklist kvm
blacklist kvm_amd
blacklist kvm_intel

Sembra che funzioni, al momento non ravvedo anomalie di altro genere.
Grazie.

Come puoi vedere, io l’ho aggiunto il 4 dicembre e non mi ha dato più problemi.
Prego, di nulla.