La storia che andremo a raccontare ha del paradossale, un misto tra “Blu notte, misteri irrisolti” ed una barzelletta de “La sai l’ultima?”.
La storia in questione, che è tutt’altro che una bufala, vista l’esasperazione dell’utente vittima dello scherzetto di Linux, riguarda un notebook MSI “distrutto da un comando di questo sistema operativo”. L’utente di Arch Linux ha scritto in altri diversi forum specializzati per raccontare la sua esperienza e cercando di trovare una soluzione.
Il problema nasce dal seguente comando: “rm-rf -no-conservare-root /”, capace di mandare in tilt un intero computer.
Bisogna considerare un fattore: ogni qualvolta si esegue un aggiornamento del BIOS o del firmware del notebook, si deve incrociare le dita e sperare che l’operazione non danneggi irrimediabilmente il sistema. Qualsiasi cambiamento interno al BIOS, infatti, potrebbe causare seri danni al notebook, che così diventerebbe inutilizzabile e sarebbe impossibile ripristinarlo o recuperare il vecchio sistema, a maggior ragione nel caso di PC vecchi che hanno schede madri mono BIOS (a differenza di quelli recenti che lo hanno doppio, di cui uno aggiornabile).
Linux: di chi è la colpa?
Tornando al problema in questione, l’utente di Arch Linux ha scritto, in un suo post, di aver deciso di rimuovere l’installazione dello stesso Arch Linux sul suo notebook MSI GP60 2PE Leopard per avere un pc con OS pulito, ma invece della normale formattazione che noi conosciamo ha utilizzato il comando “rm-rf -no-conservare-root /”.
E’ un comando che viene lanciato per disinstallare il sistema del pinguino, che in alcuni notebook vulnerabili potrebbe addirittura cancellare la partizione di boot EFI dall’interno di Linux, cosa seriamente avvenuta.
E’ vero, l’utente – come conferma egli stesso – non sapeva di questa particolarità. Infatti, questo comando ha eliminato la directory “/sys/firmware/efi/efivars/”, che contiene gli script e i dati per avviare correttamente un notebook con UEFI BIOS. In assenza di questi file, il notebook MSI non si è riacceso.
Linux ha fatto ciò che l’utente ha chiesto, ma è altrettanto vero che la cartella “/sys/firmware/efi/efivars/ ” dovrebbe essere limitata alla sola lettura delle informazioni contenute, senza possibilità di scrittura.
Alla fine della fiera, l’assenza di informazioni e il buco di Linux hanno causato questo concorso di colpa.