Wikimania 2024/Report/Valerio Bozzolan

BOZZA

Questo è il report della partecipazione di User:Valerio Bozzolan a Wikimania 2024 come volontario. Il report è condiviso da tutte le persone a cui è stata assegnata una borsa di viaggio (per conoscere la commissione borse vedi Wikimania 2024).

Attività

Lunedì 6 agosto

Risoluzione problema tecnico su computer aziendale di Wikimedia Italia

(Questa sezione segue lo schema dei report degli incidenti tecnici in produzione in uso in Wikimedia Foundation - w:wikitech:Incident status)

Segnalazione:

Il membro dello staff Utente:Dario Crespi si presenta a Wikimania con il suo amato computer portatile aziendale "Tuxedo" che purtroppo ha iniziato a non avviarsi correttamente da circa 1-2 giorni «dopo un aggiornamento di sistema». Ci siamo dati allora appuntamento all'hackaton room in cui c'era sempre dello spazio libero per lavorare in tranquillità.

Sintomo:

Ad ogni avvio del portatile, il computer si fermava sulla ("schermata nera") shell interattiva di emergenza di w:it:GNU GRUB. Il bootloader GRUB non riusciva a lanciare il sistema operativo.

Ipotesi:

Si è escluso fosse un problema noto legato a dual-boot con Windows 10+ perché il computer ne era sprovvisto (mi è noto che Windows 10+ dopo certi aggiornamenti rompe a prescindere il dual-boot, qualsiasi sistema operativo ci metti di fianco).

Ho informato Dario che nella migliore e più verosimile delle ipotesi avremmo risolto in pochi minuti dopo aver a rigenerato i "menù di avvio di GRUB" eventualmente usando strumenti grafici e semplici da usare come Boot Repair. Questa ipotesi deriva dal fatto che l'aggiornamento dei menu di avvio GRUB è effettuata automaticamente proprio dopo ogni installazione di ogni nuova versione minore del kernel inclusa con gli aggiornamenti di sistema (APT), e mi era già capitato che durante questi aggiornamenti non si completasse con successo `update-grub` per varie ragioni. All'Officina Informatica Libera di San Salvario a Torino consiglio di solito di usare tool grafici, poiché spesso funzionano, punto, dando anche alle nuove utenze GNU/Linux un senso di maggiore controllo del proprio computer, invece che affidarsi ciecamente a persone esterne che digitano "comandi a caso sul mio computer". Inoltre questi tool grafici evitano alle utenze inesperte di commettere errori molto più gravi in futuro quando ri-utilizzati.

Ho informato anche Dario che nella peggiore delle ipotesi aveva perso irrimediabilmente tutti i dati presenti a bordo nella partizione principale, per un problema irreversibile al disco o al filesystem... magari per un precedente impatto al computer o cose del genere che solitamente le utenze non ammettono mai. asd. Questa seconda ipotesi deriva sempre da diverse esperienze dirette (che non c'entrano niente con Dario asd).

Preparazione:

Siccome non mi trovo a mio agio ad operare dal terminale di emergenza di GRUB senza poter aprire neanche un browser di fianco per documentarmi, e siccome risolvere i problemi senza interfaccia grafica spesso fa sollevare il panico nelle utenze che osservano vicino; ho riavviato il computer da una mia chiavetta USB esterna che tengo per queste occasioni per analizzare la situazione da un sistema operativo funzionante. Per avviare il sistema dalla periferica esterna ho dovuto riavviare il computer premendo ripetutamente il pulsante F2 (ho impiegato circa tre tentativi - se ricordo correttamente F12 non avviava il menu di selezione che mi aspettavo, e F1 avviava il boot via rete PXE).

Analisi:

Una volta avviato il sistema live dalla mia chiavetta, ho potuto lanciare w:it:gparted per analizzare le partizioni. La partizione di boot in formato FAT32 risultava - in effetti - danneggiata.

Azioni:

Ho applicato la risoluzione automatica della partizione danneggiata usando gparted stesso (onestamente senza sperare troppo in una risoluzione, poiché il formato FAT32 è un formato proprietario di Microsoft e mi era capitato che `parted` si lamentasse dell'impossibilità di auto-correggere la partizione. Invece....) gparted ha risolto il problema segnalato nella partizione di boot. Ho allora riavviato il computer, constatando però che il problema originario non era ancora rientrato.

Ho allora investito altri 10 minuti sull'attivazione di un ambiente `chroot` funzionante (https://superuser.com/a/111215/390314) con l'intenzione di lanciare `update-grub` come faccio di solito. Nonostante avessi montato tutti i dispositivi speciali come al solito, ho avuto questo problema nel lancio di `update-grub`:

/usr/sbin/grub-probe:error:failed to get canonical path of /cow

Mi sono documentato (https://unix.stackexchange.com/q/96977) senza però risolvere, neanche creando il file vuoto come suggerito in https://unix.stackexchange.com/a/659712 o altro.

Ho allora utilizzato semplicemente Boot Repair come proposto fin dall'inizio. È stato come sempre sufficiente installarlo come da guida. Si avvia da solo dopo l'installazione. Si pigia "OK OK OK avanti avanti avanti OK" a caso spegnendo il cervello, e di solito il problema rientra. Così è stato. asd.

Ho informato Dario che il suo problema era stato risolto magicamente da Boot Repair - e che se proprio ci teneva potevo leggergli a voce 2K righe di report tecnico di Boot Repair per capire quale fosse davvero il problema originario. Dario ha sorriso e ha rimesso nello zainetto il suo portatile aziendale - ora funzionante - e ci siamo salutati cordialmente. Ho scorso velocemente il report di Boot Repair per vedere se qualche cosa assurda saltava all'occhio. Non ho notato niente di particolarmente interessante, quindi ho buttato il report nell'immondizia. asd

Cosa è andato bene:

Per Dario è andata bene che un membro volontario della commissione tecnica (e quindi con NDA firmata) avesse tempo per prestare assistenza e avesse con sè una chiavetta USB pronta e avesse già incontrato quel problema in precedenza. In generale è andata bene che Dario ha potuto tornare operativo durante l'evento.

Per Wikimedia Italia è andata bene perché non è stato necessario disturbare l'assistenza tecnica di Tuxedo, cosa che ha fatto risparmiare tempo all'amministrazione e denaro all'organizzazione.

(Attenzione a non fraintendermi: in altri contesti NON raccomando a Wikimedia Italia di affidarsi a persone volontarie tecniche "a caso" in una stanza di un hackaton ma di affidarsi sempre all'assistenza ufficiale come prima opzione, o, a persone con una NDA firmata - siccome durante questo tipo di assistenza tecnica si ha ovviamente totale accesso ai dati della persona coinvolta)

Per Valerio è andata bene che Boot Repair nel 2024 sia ancora un tool decisamente semplice e funzionale e lo consiglierei ancora per risparmiare tempo.

Con tutto il rispetto per il nostro movimento, è anche andata bene che era il primo giorno, quindi, l'aria nell'hackaton room non profumava ancora di "80 calzini di 40 Wikipediani molto operosi" - come spesso irrimediabilmente capita quando metti così tante persone a produrre codice per tre giorni di fila. asd (cosa che comunque si è puntualmente verificata al terzo giorno di hackaton - inutile tentare di negarlo in questo report in cui ho dovuto giurare di non omettere alcuna verità asd)

Cosa è andato male:

Se avesse funzionato la multi-selezione di avvio che si attiva solitamente con F12 avrei avviato prima la mia chiavetta, risparmiando 5 minuti.

Se avesse funzionato il primo tentativo di `update-grub` da `chroot` avrei risparmiato altri 10 minuti.

Dove abbiamo avuto fortuna:

Dario ha avuto fortuna di poter risolvere in pochi minuti un problema che era potenzialmente legato a corruzione del filesystem / problemi hardware / perdita irreversibile di dati.

Valerio ha avuto fortuna che la chiavetta live-USB Ventoy in tasca fosse ancora perfettamente funzionante. Cosa che ha fatto risparmiare ulteriori 10-15 minuti.

Tempo totale:

20-30 minuti saluti compresi.