0MLx4: impossibile aggiornare

so che Calamares è l’installer. E per provarlo bisogna reinstallare…

Ma qui non stiamo parlando di re-installare… Perchè dovresti?
Hai già la Beta, prova ad aggiornarla.
Vuoi provare con i comandi suggeriti? o vuoi rifare tutto daccapo?

1 Like

Accidenti: pensavo che l’emoticon bastasse.
Sto già eseguendo i comandi suggeriti.
La prima parte è identica

Failed to synchronize cache for repo 'openmandriva-x86_64'
OpenMandriva 4.0 - x86_64 - Updates                          145  B/s | 169  B     00:01    
Failed to synchronize cache for repo 'updates-x86_64'
Ignoring repositories: openmandriva-x86_64, updates-x86_64

e si è bloccato su

Dimensione totale dello scaricamento: 169 M
Procedere [s/N]: s
Scaricamento dei pacchetti:root     

In attesa che il processo con pid 8903 finisca.

.

8903   /usr/bin/python3 /usr/bin/dnf-automatic /etc/dnf/automatic.conf --timer

Ma ti arrivano i messaggi del forum in tempo reale??
I comandi sono questi, per il momento:

1 Like

In effetti si: mi sembra di essere in una chat.
Ho già dato questi comandi appena me l’hai suggerito.
Nel post precedente c’è il log del successivo

dnf --refresh update

e di

ps -aux

L’errore che hai riportato sembra essere causato da un’istanza di dnf già in esecuzione. Infatti dnf permette l’aggiornamento automatico in background tramite il processo dnf-automatic, perciò il consiglio è quello di aspettare che il processo finisca e riprovare in seguito.

1 Like

:astonished:
Ma l’aggiornamento automatico è stato disabilitato già da un pezzo…

il problema è che il comando sembra non avanzare: la CPU lavora ma il comando non termina. Sembra bloccato circa a metà pacchetti.
Aspetto ancora un po’.

Bloccato il comando, l’ho rilanciato e tutto è andato a buon fine.
Non proverò Calamares… :expressionless:

1 Like

Bene.
Calamares è fantastico quando serve, ma è preferibile evitarlo se se ne può fare a meno :grin:

1 Like

Mi era capitato qualche settimana fa, pensavo fosse ancora attivo. Dal file /etc/dnf/automatic.conf:

# Whether updates should be downloaded when they are available, by
# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
download_updates = yes
1 Like

Io ho un
download_updates = yes

e un
apply_updates = no

Per quanto download_updates = yes mi lasci un dubbio su cosa faccia in realtà, mi tranquillizza il apply_updates = no.

Cmq dopo il baco degli aggiornamenti automatici a insaputa dell’admin, che risiedeva nell’applet di dragora, controllo saltuariamente e non ho mai trovato aggiornamenti che non ho deciso io.

2 Likes

Idem qui. A quanto pare dnf aggiorna le liste e scarica i pacchetti ma non li installa. Poiché installo e rimuovo pacchetti continuamente non ci fatto caso più di tanto.

1 Like

Questo non ha importanza, non ha nulla a che fare con nulla, ti sta dicendo che non può raggiungere quei repository che non possono perché non esistono ancora. Potresti disabilitarli.
This does not matter, has nothing to do with anything, it is telling you that it can’t reach those repos which it can’t because they do not exist yet. You could disable them.

Ti sta dicendo semplicemente che il processo 8903 non è finito.
Is telling you simply that process 8903 has not finished.

Questo sta dicendo che dnf-automatic è il processo 8903. Non uso dnf-automatic quindi non so perché sarebbe in esecuzione. Ma a prescindere da ciò, è necessario finire prima di poter fare qualsiasi altra cosa. O se è bloccato puoi uccidere il processo con il comando kill. Penso che sia:
This is telling that dnf-automatic is process 8903. I don’t use dnf-automatic so don’t know why it would be running. But regardless this needs to finish before you can do anything else. Or if it is stuck you can kill the process with the kill command. I think that’s:

$ sudo kill -9 8903

Post-edit: Intendevo dire che non uso consapevolmente dnf-automatic. L’aggiornamento probabilmente lo fa, ma l’aggiornamento sembra interrotto. FWIW per quanto ne so l’aggiornamento è ‘plasma-pk-updates’ non ‘dnfdragora-updater’, ma questo potrebbe essere cambiato, di nuovo.
Post-edit: I meant that I don’t knowingly use dnf-automatic. The updater probably does but the updater seems broken. FWIW as far as I know the updater is ‘plasma-pk-updates’ not ‘dnfdragora-updater’ but this could have changed, again.

i log dnf sono:
dnf logs are:

/var/log/dnf.log

/var/log/dnf.rpm.log

Penso che il dnf.log abbia tutte le uscite delle transazioni dnf. Non sono sicuro di cosa sia il dnf.rpm.log ma sono sicuro che gli sviluppatori lo troveranno utile in caso di problemi.
I think the dnf.log has all the output of dnf transactions. Not sure what the dnf.rpm.log is but I’m sure developers will find it useful in the event of a problem.

Anche riguardo all’aggiornamento questo da IRC # openmandriva-cooker:
Also about the updater this from IRC #openmandriva-cooker:

ben79: next iso will switch back to dragora’s one , only one working … pk based ones seems to have problems with scriptlets

1 Like

Questa potrebbe essere una buona idea dato che plasma-pk-updates non esegue correttamente gli scriptlet.
This may be a good idea given that plasma-pk-updates does not run scriptlets properly.

$ sudo dnf remove plasma-pk-updates

$ sudo dnf install dnfdragora-updater

Inoltre da quando passeremo a dnfdragora-updater sul prossimo ISO.
Also since we will be switching to dnfdragora-updater on next ISO.

Il problema si è ripresentato; ho aspettato 10 minuti prima di riprovare ad aggiornare e tutto è filato liscio.
Allora ho sostituito plasma-pk-updates con dnfdragora-updater e domani farò un altro test.

/var/log/dnf.log
&
/var/log/dnf.rpm.log

Per aiutare con questi registri, l’errore nel tuo primo post ci dice solo che “Transazione in corso Impossibile ottenere il blocco della transazione (login effettuato come: root)” non ci dice perché non può ottenere il blocco della transazione. Quindi, se stai riscontrando lo stesso errore, guardi in quei log alla data e all’ora del tuo errore e vedi se entrambi ti dicono il perché. Inoltre potresti trovare qualcosa nei log di journalctl. Per rendere l’analisi più rapida, è necessario conoscere la data e l’ora dell’errore se si sta cercando nei registri o in journalctl.

To help with those logs the error in your first post only tells us that “Transaction in progress Unable to get the transaction lock (login made as: root)” it does not tell us why it can not get the transaction lock. So if you are having the same error you would look in those logs at the date and time of your error and see if either tells you the why. Also you may find something in journalctl logs. To make looking go quicker you need the date and time of your error whether looking in logs or journalctl.

1 Like

Problema risolto con l’eliminazione di plasma-pk-updates.
Ora gli update filano lisci come l’olio

Sto imparando mentre procediamo. Lx 4 sarà abbastanza diverso da farci imparare alcune cose mentre andiamo avanti.

I’m learning as we go along. Lx 4 is going to be enough different that we all will be learning some things as we go along with it.