Blocco al bootstrap

Vincenzo_Antonuccio · September 23, 2025, 11:32am

Salve!

Ho appena trovato il vs. indirizzo, sono residentte a perugia e da diversi giorni il mio laptop si blocca durante le prime fasi del bootstrap.
Ecco alcune specifiche tecniche:

Hardware: Lenovo Thinkpad P15

Graphics: Intel UHD Graphics, NVIDIA Quadro T2000 (4GB GDDR6), LAN, WLAN, WebcamProcessor Intel(R) Core™ i7-10875H CPU @ 2.30GHz (2.30 GHz)

Installed RAM 32.0 GB (31.8 GB usable)

System type 64-bit operating system, x64-based processor

Distro installata (ultima versione): Fedora Core 42, kernel 6.16.7

Il sistema lo aggiorno regolarmente, accettando gli upgrades ogni giorno. Il 14/9 dopo l’ultimo update completo, al momento del bootstrap, il sistema si blocca (la ruotina della schermata Lenovo si blocca). Sono costretto a spegnerlo manualmente e quando l’ho riacceso ho cercato di far bootstrappare due versioni precedenti del kernel (6.16.4, 6.16.4), ma senza successo.

Sono infine riuscito ad accedere al sistema dalla partizione “rescue”, e ho verificato che i filesystems di sistema e dell’unico utente che c’è sono visibili, quindi apparentemente integri. Ho lanciato journalctl -xb e alcuni screenshots li ho resi disponibili qui’:

Thinkpad troubles - Google Drive

Mille grazie per l’attenzione fino ad ora! Sono abitualmente residente a Perugia, ma in questi giorni sono fuori ad un congresso (sono un fisico). Nn sono uno sviluppatore, come avrete capito, non ho grandi conoscenze su come funzioni Linux ed il boot, sono solo un utente.

Ancora grazie in anticipo, a presto (spero).

amreo · September 24, 2025, 9:10am

Mhm da quello che vedo nelle foto non sono sicuro che sia così.

Puoi provare a lanciare sudo fsck -y /dev/sda1 e anche sulle altre partizioni/dischi(/dev/sda2`, /dev/sda3, /dev/sdb1, /dev/sdb2, …)? Il comando controlla l’integrità delle partizioni, e eventualmente corregge gli eventuali errori.

Fai anche un altro controllo: quando il sistema si sta avviando e c’è la ruotina che sta girando, premi spazio o le freccette per vedere cosa sta facendo e dicci dove fallisce o ci impiega troppo.

Vincenzo_Antonuccio · September 24, 2025, 10:44am

Grazie per i suggerimenti amreo. Posso già darti l’output del controllo su dove si blocca: h provato a fare un boot fa un live usb image su un pendrive (FC 41), allego la schermata. Il primo problema sembra essere quel messaggio in rosso: “lspcon init failed on port d”.

Vincenzo_Antonuccio · September 24, 2025, 12:48pm

Puoi provare a lanciare sudo fsck -y /dev/sda1 e anche sulle altre partizioni/dischi(/dev/sda2, /dev/sda3, /dev/sdb1, /dev/sdb2`, …)? Il comando controlla l’integrità delle partizioni, e eventualmente corregge gli eventuali errori.

Ho effettuato una ricerca di bad sectors da BIOS sull’HD: il disco è integro. Poi ho messo una live image di Fedora Core 43beta su una penna e questa l’ha bootstrappata, anche se con qualche rallentamento. L’output di “journalctl -xb” l’ho messo quì : https://drive.google.com/drive/folders/1b8p8jI4ENV3592TH2zmPYwaTxBqtUjYa?usp=drive_link , file: jctl* .

amreo · September 25, 2025, 7:46am

Prova anche con fsck come ti ho detto. Potrebbe anche essere che il bios non si sia accorto che qualche bug si è corrotto.

Giusto che ci sei, con gnome disk (penso che Fedora Core utilizzi gnome) puoi mostrarci lo stato dell’hdd?

Vincenzo_Antonuccio · September 25, 2025, 9:48am

Giusto che ci sei, con gnome disk (penso che Fedora Core utilizzi gnome) puoi mostrarci lo stato dell’hdd?

Allego lo screenshot

Riflettendo sulla situazione, vedo che al momento riesco a fare il bootstrap solo con la Fedora Core 43beta, che usa il kernel 6.17.0. Ne deduco che se installo un nuovo kernel dal 6.17.0, dovrei riuscire a fare il boot. Vedo quindi due possibili strade:

Installare la FC 43beta da live USB image. Non sono pero’ certo che il processo sia un upgrade della precedente FC 42, lasciando i contenuti delle aree-utenti dalla precedente verdsione, o se invece non mi “pialli” tutto. Per questo sto facendo un backup della aree-utenti.
Abilitare in GRUB la modalità terminale: questo dovrebbe disabilitare il controllo della scheda grafica e superare l’ostacolo che impedisce il boot (sempre che sia questo il problema). A questo punto posso entrare in uno dei kernel che non bootstrappano in modalita’ terminale, attivare il wifi, scaricare il kernel 6.17.x, installarlo e riattivare la modalità grafica in grub.

La 2) mi permetterebbe di non correre il rischio di vedere cancellate le vecchie aree-utenti.

Che ne pensi/pensate?

Vincenzo_Antonuccio · September 25, 2025, 1:12pm

La soluzione 2) non ha funzionato. Ho eliminato “quiet” e “rhgb” dai parameri del kernele 6.16.7, la seconda per accedere al login in modalità terminale, ma anche cosi’ il boot si pianta.

Ho quindi deciso di seguire la strada 1: aggiornare il sistema alla FC 43 beta, che usa il kernel 6.16.7 e che mi funziona da live USB. Il backup pero’ è lento (ho molto lavoro da salvare…). In questa maniera pero’ il problema resterà irrisolto.

amreo · September 27, 2025, 8:09am

Non hai messo la schermata smart. Lo trovi cliccando i tre puntini in alto a dx.

TE LO RIPETO DI NUOVO: HAI PROVATO AD USARE fsck -y /dev/nvme0n1p1, fsck -y /dev/nvme0n1p2, … per tutte le partizionioni? fsck fa il controllo a livello di filesystem e non si limita solo alle informazioni sullo stato dei blocchi secondo l’hdd.

Vincenzo_Antonuccio · September 27, 2025, 9:45am

Buongiorno, e grazie per il supporto. Premetto che continuo ad usare un live USB di FC 43 bis, la sola che riesca a fare il boosttrap, ma adess per KDE e non piu’ gnome.

Ecco cosa vedo:

$ lsblk -f
NAME        FSTYPE FSVER LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       erofs                              48a38732-8cfa-4f9a-b697-b69a577bf0e1       0   100% /run/rootfsbase
sda         iso966 Jolie Fedora-KDE-Live-43    2025-09-10-22-29-31-00                              
├─sda1      iso966 Jolie Fedora-KDE-Live-43    2025-09-10-22-29-31-00                     0   100% /run/initramfs/live
└─sda2      vfat   FAT16 BOOT                  9FC8-DDAC                                           
zram0       swap   1     zram0                 8efae505-fa6a-4b92-9cda-d8a6379aff3f                [SWAP]
nvme0n1                                                                                            
├─nvme0n1p1 vfat   FAT32                       FE52-E574                                           
├─nvme0n1p2                                                                                        
├─nvme0n1p3 ntfs         antonuccio            528653CF8653B269                                    
├─nvme0n1p4 ntfs                               0E50C89450C883C5                                    
├─nvme0n1p5 vfat   FAT32                       BE34-7325                                           
├─nvme0n1p6 swap   1                           7983f01f-fde7-4f51-a05f-7afeb49a96f5                
└─nvme0n1p7 btrfs        fedora_localhost-live 47991e02-cba5-44a6-881e-1aabd3ed31d0

Non ho montato fedora-localhost-live, dove ci sono aree root e utenti, per poterle ispezionare con fsck e badblocks:

$ df -k
Filesystem     1K-blocks    Used Available Use% Mounted on
LiveOS_rootfs    6519280  354256   6165024   6% /
devtmpfs        16162740       0  16162740   0% /dev
tmpfs           16298192      12  16298180   1% /dev/shm
efivarfs             246     112       130  47% /sys/firmware/efi/efivars
tmpfs            6519280  354256   6165024   6% /run
/dev/sda1        3165388 3165388         0 100% /run/initramfs/live
/dev/loop0       2848976 2848976         0 100% /run/rootfsbase
tmpfs               1024       0      1024   0% /run/credentials/systemd-journald.service
tmpfs           16298192       4  16298188   1% /tmp
tmpfs               1024       0      1024   0% /run/credentials/systemd-resolved.service
tmpfs            3259636    3736   3255900   1% /run/user/1000
liveuser@localhost-live:~$

Ecco i 7 outputs dei fsck:

$ sudo fsck /dev/nvme0n1p1
fsck from util-linux 2.41.1
fsck.fat 4.2 (2021-01-31)
/dev/nvme0n1p1: 195 files, 34291/98304 clusters

$ sudo fsck /dev/nvme0n1p2
fsck from util-linux 2.41.1
e2fsck 1.47.3 (8-Jul-2025)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/nvme0n1p2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

$ sudo fsck /dev/nvme0n1p3
fsck from util-linux 2.41.1
Unsupported: replay_log()
Unsupported: check_volume()
Checking 1205248 MFT records
..... (lunga serie di errori)
Error getting bit value for record 85465
..... 

$ sudo fsck /dev/nvme0n1p4
fsck from util-linux 2.41.1
Unsupported: replay_log()
Unsupported: check_volume()
Checking 256 MFT records.
Unsupported cases found.
ntfsck was unable to run properly.

$ sudo fsck /dev/nvme0n1p5
fsck from util-linux 2.41.1
fsck.fat 4.2 (2021-01-31)
/dev/nvme0n1p5: 27 files, 4954/261628 clusters

$ sudo fsck /dev/nvme0n1p6
fsck from util-linux 2.41.1
fsck: fsck.swap not found; ignore /dev/nvme0n1p6

$ sudo fsck /dev/nvme0n1p7
fsck from util-linux 2.41.1
If you wish to check the consistency of a BTRFS filesystem or
repair a damaged filesystem, see btrfs(8) subcommand 'check'.

Insospettito dagli errori su n*p3 ho ispezionato con badblocks:

$ sudo badblocks -s /dev/nvme0n1p3
Checking for bad blocks (read-only test): done

Mi sembra che non ci sia nulla di anomalo su /dev/nvme0n1p3. Ti sarei grato di sapere cosa ne pensi, e se vuoi che faccia altri tests.

Vincenzo_Antonuccio · September 28, 2025, 10:22pm

La soluzione consisteva nel disattivare plymouth. Ho aggiunto la stringa: “nomodeset plymouth.enable=0” coma parametro nel grub, interattivamente.
Per rendere permanente il parametro (in FC 43 beta):

Aggiungere il parametro alla relativa linea del file /etc/default/grub che contiene i parametri del kernel:
…
GRUB_CMDLINE_LINUX=“resume=UUID=7983f01f-fde7-4f51-a05f-7afeb49a96f5 rhgb quiet nomodeset”
…
Rigenerare il file aggiornato di GRUB eseguendo: “sudo grub2-mkconfig -o /boot/grub2/grub.cfg”

amreo · October 7, 2025, 8:22am

Devo dire di essere sorpreso. Ero convinto che fosse un problema a livello di hard disk.