All'avvio sistema rallenta quando "reached target initrd root device"

Fedora Linux Varie
#1

Ciao a tutti, ho un poertatile con FC34 con installato un SSD, quindi con avvio veloce (pochi secondi).
Recentemente mi si è spento all’esaurimento della batteria (non mi ero accorto che non veniva alimentato).
Da quella volta, l’avvio è diventato molto più lento (anche un minuto) e il punto in cui il boot si “blocca” per un bel po’ è alla voce reached target initrd root device. Lo spegnimento anche è un po’ rognosetto, tanto da doverlo forzare tenendo premuto il tasto di accensione.

Se avvio il computer con una precedente versione del kernel tutto va veloce come sempre.

Si può risolvere? Grazie!

PS: caricata la versione lenta, ho provato un dnf update, il quale ha anche aggiornato ulteriormente il kernel (che ora è 5.12.13-300.fc34.x86_64), ma avviando di nuovo stesso problema…

#2

ciao,
guarda che il comando per aggiornare il sistema è

sudo dnf upgrade

perché update è stato “deprecato” anni fa…

Per il resto, cedo la parola ai più esperti…

#3

Sì hai ragione, dnf update è ormai un retaggio che mi porto dietro da Fedora 9 :innocent:

Grazie comunque della risposta e come dici tu aspettiamo eventuale risposta da chi conosce questo tipo di problema…

#4

Ciao @twsfedora @aiace fai così :

sudo dnf clean all   
sudo dnf upgrade 
sudo dracut -f -v 
sudo fixfiles -F onboot

riavvia è aspetta che il processo di selinux finisca dopo che si è riavviato posta :

systemctl --failed

che vediamo che non ci sia qualche servizio che non parte :slightly_smiling_face:

#5

Ciao @edmondo , grazie. Questo il risultato:

[master@hp-15bs136nl ~]$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● postgresql.service loaded failed failed PostgreSQL database server

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed.

#6

Ciao @twsfedora aggiungi la @ al mio nome , so nò non mi arrivano i messaggi guarda come ho fatto adesso io :slightly_smiling_face: allora tempo di partenza hai notato dei miglioramenti o è rimasto invariato , per caso ci sono stati aggiornamenti a livello kernel ? :slightly_smiling_face: poi posta anche :

sudo systemctl status postgresql.service

che vediamo meglio l’errore :slightly_smiling_face:

#7

Ciao @admondo, no non è cambiato niente. Nessun aggiornamento del kernel (avevo già aggiornato poco prima…). Per il comando:

[master@hp-15bs136nl ~]$ sudo systemctl status postgresql.service
× postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2021-07-03 06:39:53 CEST; 12min ago
Process: 1163 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=1/FAILURE)
CPU: 10ms

lug 03 06:39:53 hp-15bs136nl systemd[1]: Starting PostgreSQL database server…
lug 03 06:39:53 hp-15bs136nl postgresql-check-db-dir[1163]: An old version ‘10’ of the database format was found.
lug 03 06:39:53 hp-15bs136nl postgresql-check-db-dir[1163]: You need to dump and reload before using PostgreSQL 13.3.
lug 03 06:39:53 hp-15bs136nl postgresql-check-db-dir[1163]: See /usr/share/doc/postgresql/README.rpm-dist for more information.
lug 03 06:39:53 hp-15bs136nl systemd[1]: postgresql.service: Control process exited, code=exited, status=1/FAILURE
lug 03 06:39:53 hp-15bs136nl systemd[1]: postgresql.service: Failed with result ‘exit-code’.
lug 03 06:39:53 hp-15bs136nl systemd[1]: Failed to start PostgreSQL database server.

#8

Ciao

A quanto pare è un problema che stanno affrontando
https://bugzilla.redhat.com/show_bug.cgi?id=1976621
Vedo che ci sono degli italiani nella discussione, potresti essere tu uno di quelli 8<)

Qui
https://bugzilla.redhat.com/show_bug.cgi?id=1976653
descrivono un workaround.

Ciao Ciao, Moreno

#9

Grazie @Moreno, ma il problema non si è presentato dopo un aggiornamento, ma dopo uno spegnimento (per batteria scarica senza che me ne accorgessi). Da quel momento ha cominciato a fare così. Solo dopo che questo problema si è presentato ho fatto gli ultimi aggiornamenti. Però le due cose potrebbero essere non correlate ed essere una coincidenza…

#10

Ciao

Lo so ma la sintomatologia e la stessa, tentare il workaround non costa nulla.

Ciao Ciao, Moreno

#11

@Moreno se non ho capito male si propone temporaneamente di modificare il file

/usr/lib/systemd/system/dbus-broker.service e rimuovere “sysinit.target” dopo “After=” alla riga corrispondente.
L’ho fatto, ma non cambia nulla… forse c’è altro da fare?

#12

Ciao

Eh, non saprei dirti.
Prova comunque a seguire i passaggi usati dagli altri utenti come:

$ sudo systemd-analyze blame | head -1

Magari li le storie si separano.

Ciao Ciao, Moreno

#13

Ciao @Moreno per il momento pare risolto settando notify_dbus=0 in /etc/lvm/lvm.conf e poi, da root, con dracut -f, come indicato in https://bugzilla.redhat.com/show_bug.cgi?id=1976653 commento 10…

Grazie ancora!

#14

Ciao

Ottimo, sono contento che perlomeno il problema sia stato tamponato.

Ciao Ciao, Moreno