Link alla notizia: http://www.hwupgrade.it/news/sistemi-operativi/il-comando-linux-che-mette-ko-alcuni-portatili_60691.html

Il comando rm -rf –no-preserve-root / può determinare la cancellazione di file necessari per avviare alcuni portatili Linux. Diverse segnalazioni diffuse in rete in relazione ai modelli MSI

Click sul link per visualizzare la notizia.

Anche Format C: in DOS non faceva più avviare il PC. Non mi ricordo una News a tal proposito

è leggermente diverso.....
qui sembra che sia possibile cancellare parte del bios e quindi la macchina non si avvierebbe più (non permettendo di reinstallare un sistema operativo)

errore di msi o di chi ha scritto il bios o di chi ha montato in read-write la partizione ?

mi sa che questo caso è diverso: una parte del BIOS efi viene cancellata ed il portatile non mostrerà più nulla a schermo.
con format C: reinstallavi tutto e non c'erano problemi, il BIOS non veniva intaccato

+ che altro è grave che venga esposta la partizione efi sulla rom interna o_O

Veramente parla di una cartellaTra il materiale cancellato figura anche il contenuto della cartella /sys/firmware/efi/efivars/
non del bios stesso che è scritto su una EEPROM rescrvibile
E poi viene completamente cancellata anche la partizione di boot EFI dall'interno di Linux si parla di partizione. Dove stanno per voi le partizioni? Certo non sul BIOS
E cmq il mio commento era sarcastico, non si doveva neanche prendermi sul serio

Veramente parla di una cartella
non del bios stesso che è scritto su una EEPROM rescrvibile
E poi si parla di partizione. Dove stanno per voi le partizioni? Certo non sul BIOS
E cmq il mio commento era sarcastico, non si doveva neanche prendermi sul serio

il problema è che la eeprom è montanta nella cartella /Sys/firmware etc etc, come fosse una "chivetta usb"... peccato che in questo caso non fosse montata in una cartellain sola lettura, ma anche giustamente: di solito è una cartella di proprietà di Root, quindi da utente non la puoi toccare

nel momento in cui spegni il pc (e/o formatti blablabla.... quel che vuoi) la cartella è smontata quindi non esposta

si è una coincidenza bizzarra, come è una bizzarra coincidenza che uno lanci un comando del genere per dio!

il che fà anche capire l'onnipotenza assoluta di Root, che quindi và usato con cognizione di causa (dopo è pur vero che con UEFI son nati piu casini che problemi risolti rispetto i vecchi bios... :doh: ma tant'è)

è un comando patchabilissimo (banalmente bastava aggiungere di smontare tutto prima di formattare) e la reale esigenza di usare normalmente questo comando è -ZERO-... quindi boh, è un caso, sfortunato, un semplice bug dato anche dalla relativa "novità" di UEFI
e non è nemmeno da escludere la responsabilità di MSI a lasciare i firmware così accessibili al software, in maniera trasparente...


E' corretto precisare che il problema, documentato in maniera abbastanza ampia in relazione ai portatili MSI, potrebbe riguardare anche prodotti di altri brand. Non si dispone di una casistica estesa
ma và? chi è il fesso che darebbe un comando del genere? 1 su 1 milione..

tuttavia, né si può procedere con prove empiriche visto il potenziale danno che si può causare al portatile. Alla luce dei potenziali rischi legati all'operazione, utilizzare una più innocua procedura di formattazione è un'operazione maggiormente consigliata.
anyway, credo sia possibile ripristinare con un aggiornamento del bios/uefi, quello dovrebbe ripristinare tutto

In realtà in una macchina (U)EFI una parte del BIOS e file per permettere il boot sono sul disco primario nella prima partizione che è di solito di pochi MB; partizione che un sistema operativo come si deve non dovrebbe mai esporre all'utente... soprattutto NON in scrittura!

Poi diciamolo a fare "rm -rf /" un po' se la sono cercata :Prrr:

Veramente parla di una cartella
non del bios stesso che è scritto su una EEPROM rescrvibile
E poi si parla di partizione. Dove stanno per voi le partizioni? Certo non sul BIOS
E cmq il mio commento era sarcastico, non si doveva neanche prendermi sul serio

Usi Linux? cosi per sapere. /sys come /proc non sono vere cartelle ma virtuali. Sono ramfs con informazioni su hw e sistema montate per esportare strutture dati del kernel in userspace (oltre a ogni dato di ogni singolo hw installato tra cui anche la struttura delle partizioni, etc)

In realtà in una macchina (U)EFI una parte del BIOS e file per permettere il boot sono sul disco primario nella prima partizione che è di solito di pochi MB; partizione che un sistema operativo come si deve non dovrebbe mai esporre all'utente... soprattutto NON in scrittura!

Poi diciamolo a fare "rm -rf /" un po' se la sono cercata :Prrr:

poettering commented Feb 1, 2016

To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.
https://github.com/systemd/systemd/issues/2402

In realtà in una macchina (U)EFI una parte del BIOS e file per permettere il boot sono sul disco primario nella prima partizione che è di solito di pochi MB; partizione che un sistema operativo come si deve non dovrebbe mai esporre all'utente... soprattutto NON in scrittura!

no quella è una partizione (credo una copia) che si crea in fase di installazione del sistema operativo (tutti i sistemi che usano efi e GPT... win e osx pure la creano), altrimenti se si rompesse il disco rimarresti senza pc no? :D quindi quella è esponibilissima all'utente (se vuole far danni, ma non irreparabili)

in questo caso è diverso, e in ogni caso /sys non è per nulla esposta agli utenti (pippo, paperino etc etc) ma è solo di root, non a caso


Poi diciamolo a fare "rm -rf /" un po' se la sono cercata :Prrr:
su questo non c'è dubbio

Beh certo, ma reinstallando torna tutto.
Dal titolo senzazionalistico sembra ceh il PC venga compromesso per sempre

non ho capito... UEFI (o comunque dei suoi pezzi) stanno in una partizione del disco?!? non è in una eprom? che stronzata ciclopica!
e se si scassa il disco non avvii più la macchina?

BIOS per sempre!

Certo che anche loro sono proprio delle volpi a lanciare un comando del genere.

Formattare una partizione è passato di moda? :mbe:

non ho capito... UEFI (o comunque dei suoi pezzi) stanno in una partizione del disco?!? non è in una eprom? che stronzata ciclopica!
e se si scassa il disco non avvii più la macchina?

No, stanno su una eprom che viene montata in quel percorso in /sys

Certo che anche loro sono proprio delle volpi a lanciare un comando del genere.

e figurati alla MSI che volpe il tipo che non ha previsto una
if EEPROM==sputtanata then reload EEPROM from backup;

anche fare firmware decente è passato di moda :D

Non viene cancellata nessuna parte del bios! Linux (systemd) monta in una partizione virtuale "/sys/firmware/efi/efivars/" le variabili necessarie alla configurazione del bios EFI da parte del sistema operativo (si possono configurare una serie di sistemi operativi da selezionare dal menu di boot del bios) come se sarebbero una serie di file di testo (nomi delle variabili) con scritto al loro interno i valori. Si linux si fa funzionare un po' tutto in questo modo (cartelle, file virtuali). Con il comando "rm -rf –no-preserve-root /" quando incontra le EFIVAR i valori di queste variabili vengono cancellati. Purtroppo come potete leggere su github per questo caso, oppure per altri casi, sempre inerenti al bios EFI, alcuni produttori tendono a pasticciare con le specifiche EFI. Difatti in avendo i valori cancellati, è non per specifiche, ma per puro buon senso i valori dovrebbero venire automaticamente ripristinati ad un valore di default. Cosa che con EFI di MSI non avviene ritrovandosi con un mattone HI-TECH.

Un paio di precisazioni per meglio spiegare la natura del problema:
- Linux "monta" in un percorso virtuale del file-system le variabili di configurazione UEFI, che sono accessibili sia in lettura che in scrittura "by design". Di per se' non e' un problema: sono le implementazioni UEFI a doversi proteggere da operazioni non consentite.
- Il problema non e' solo di Linux: le variabili UEFI sono accessibili, con relativamente poche righe di codice, da qualunque sistema operativo. Non sarebbe difficile sviluppare virus in grado di trasformare numerosi PC in costosi fermacarte.
- Con "costosi fermacarte" intendo che il PC non prova nemmeno a partire una volta che queste variabili sono state rimosse. Non c'e' modo di installare il sistema operativo, ne' di avviare il PC da dispositivi rimovibili. E' il "bios" stesso a inchiodarsi, ergo il computer va mandato in garanzia.
- Il problema non e' limitato ad MSI. Numerosi brand sono affetti da questo problema o problemi simili. Il passo, con UEFI, e' stato grande... e in gran parte mal gestito.


Il problema, ad ogni modo, non e' limitato alle variabili. Le implementazioni UEFI stanno incontrando notevoli problemi di sicurezza, al punto da cominciare ad essere l'obbiettivo di chi sviluppa determinate categorie di virus/rootkit. Virus del genere, al momento, il consumatore semplicemente NON e' in grado di rimuoverli.

Il problema verra' risolto alla radice dai produttori solo nel momento in cui gli interventi in garanzia diventeranno troppo costosi da gestire, un po' come e' successo con le richieste di reinstallazione, che alla lunga hanno indotto i produttori a inserire partizioni di recovery nascoste.
Con UEFI avverra' probabilmente la stessa cosa. Nel frattempo, purtroppo, sono affari nostri.

Scusate eh, a me non è chiaro.
Intanto per quale motivo, diverso dall'autodistruzione, qualcuno dovrebbe eseguire quel comando?
Perché sarebbe necessario per rimuovere Arch ?

Io ho sempre saputo che il BIOS è in una EEPROM, la quale ha una sezione flash, e una sezione CMOS volatile.
Tutte le variabili stanno sulla CMOS, diversamente sarebbe da idioti :stordita:
Allora, siccome non penso proprio che quel comando esegua un flash sulla ROM, anche perché la ROM partirebbe in poco tempo se ogni volta deve flashare per il cambio di una variabile, cambierà qualcosa a livello di OS/disco, o al massimo di CMOS.
Un reset CMOS non risolve?

Cosa mi sfugge?

Scusate eh, a me non è chiaro.
Intanto per quale motivo, diverso dall'autodistruzione, qualcuno dovrebbe eseguire quel comando?
Perché sarebbe necessario per rimuovere Arch ?

Io ho sempre saputo che il BIOS è in una EEPROM, la quale ha una sezione flash, e una sezione CMOS volatile.
Tutte le variabili stanno sulla CMOS, diversamente sarebbe da idioti :stordita:
Allora, siccome non penso proprio che quel comando esegua un flash sulla ROM, anche perché la ROM partirebbe in poco tempo se ogni volta deve flashare per il cambio di una variabile, cambierà qualcosa a livello di OS/disco, o al massimo di CMOS.
Un reset CMOS non risolve?

Cosa mi sfugge?

non c'e' un vero motivo, lo han fatto per "vedere l'affetto che fa". Ti sfugge il come perche' forse ti e' poco chiaro il meccanismo e non hai letto l'intervento poco sopra che spiega perfettamente il problema :) quoto

Non viene cancellata nessuna parte del bios! Linux (systemd) monta in una partizione virtuale "/sys/firmware/efi/efivars/" le variabili necessarie alla configurazione del bios EFI da parte del sistema operativo (si possono configurare una serie di sistemi operativi da selezionare dal menu di boot del bios) come se sarebbero una serie di file di testo (nomi delle variabili) con scritto al loro interno i valori. Si linux si fa funzionare un po' tutto in questo modo (cartelle, file virtuali). Con il comando "rm -rf –no-preserve-root /" quando incontra le EFIVAR i valori di queste variabili vengono cancellati. Purtroppo come potete leggere su github per questo caso, oppure per altri casi, sempre inerenti al bios EFI, alcuni produttori tendono a pasticciare con le specifiche EFI. Difatti in avendo i valori cancellati, è non per specifiche, ma per puro buon senso i valori dovrebbero venire automaticamente ripristinati ad un valore di default. Cosa che con EFI di MSI non avviene ritrovandosi con un mattone HI-TECH.

quindi la colpa e' di chi non ha pensato al refresh a default di queste variabili, ne' di linux ne' dell'utente (beh in realta' poteva andarci con cautela eh) quindi nello specifico di msi e compagnia cantante. Le moderne eeprom non hanno problemi di riscrittura, sono comunque cicli limitati.

[...]
Il problema, ad ogni modo, non e' limitato alle variabili. Le implementazioni UEFI stanno incontrando notevoli problemi di sicurezza, al punto da cominciare ad essere l'obbiettivo di chi sviluppa determinate categorie di virus/rootkit. Virus del genere, al momento, il consumatore semplicemente NON e' in grado di rimuoverli.

Il problema verra' risolto alla radice dai produttori solo nel momento in cui gli interventi in garanzia diventeranno troppo costosi da gestire, un po' come e' successo con le richieste di reinstallazione, che alla lunga hanno indotto i produttori a inserire partizioni di recovery nascoste.
Con UEFI avverra' probabilmente la stessa cosa. Nel frattempo, purtroppo, sono affari nostri.

vero, ma la verita' e' anche un'altra. Ci hanno rifilato uefi con la scusa del "vedrete che non serviranno piu' driver (ve li ricordate i primi proclama?), tutto su uefi, e sara' tutto sicurissimo e certificato" e questo e' il risultato, con uefi sfruttato solo per rendere piu' complicato aggirare le licenze e che spalanca portoni a utilizzi malevoli di vario genere. Ridateci i vecchi bios.

è da mò che c'è questo problema. Anche io ho avuto enormi problemi col dual boot, sempre derivati da sto cavolo di grub2 che è troppo ciccione per alcune efi e sconfina su read/write e quindi è facile che venga parzialmente danneggiato.

Ora ci sono dei tool di recupero del boot, se lo stesso viene parzialmente danneggiato (non so in questo caso cosa intendano).

Ho sputato sangue su un portatile Lenovo...

Ci hanno rifilato uefi con la scusa del "vedrete che non serviranno piu' driver (ve li ricordate i primi proclama?), tutto su uefi, e sara' tutto sicurissimo e certificato" e questo e' il risultato, con uefi sfruttato solo per rendere piu' complicato aggirare le licenze e che spalanca portoni a utilizzi malevoli di vario genere. Ridateci i vecchi bios.

Questa è la cosa che mi fa incazzare di più!

Ridateci i vecchi BIOS! (vecchi?)

A quando una versione di Win10 LTSB (ossia defuffata) disponibile per tutti che non pretenda UEFI? Se ciò non avverrà Wn10 non avrà il mio scalpo, haugghhh...

Ma, un momento, perchè non passare a Linux?

Questa è la cosa che mi fa incazzare di più!

Ridateci i vecchi BIOS! (vecchi?)

A quando una versione di Win10 LTSB (ossia defuffata) disponibile per tutti che non pretenda UEFI? Se ciò non avverrà Wn10 non avrà il mio scalpo, haugghhh...

Ma, un momento, perchè non passare a Linux?

Da quando win 10 pretende UEFI? :confused: :mbe:

Da quando win 10 pretende UEFI? :confused: :mbe:This. Installato (per prova) allegramente sulla mia macchina principale, scheda madre del 2009, totalmente sprovvista di UEFI.
Non so se in questo modo venga a mancare qualche funzionalità aggiuntiva, ma sicuramente il sistema funziona (che poi sia confinato su un disco a parte e quindi praticamente inutilizzato è un altro conto).
A meno che la LTSB specificatamente necessiti dell'UEFI. In questo caso non saprei, perché non l'ho mai usata. Quella che ho usato io è una volgare Professional.

This. Installato (per prova) allegramente sulla mia macchina principale, scheda madre del 2009, totalmente sprovvista di UEFI.
Non so se in questo modo venga a mancare qualche funzionalità aggiuntiva, ma sicuramente il sistema funziona (che poi sia confinato su un disco a parte e quindi praticamente inutilizzato è un altro conto).

Io lo uso praticamente dall'uscita su una mobo con solo bios.

Tecnicamente comunque un sistema che sta girando dovrebbe impedire di essere cancellato da un "rm -rf /", OK che sei root però è un operazione che oggettivamente non ha senso! Dovrebbe almeno lockare file / directory necessarie per il suo funzionamento... il tool per disinstallare un SO è il comando format!
(La directory di UEFI che non è nemmeno una directory reale ha ancora meno senso che si possa cancellare non dovrebbe nemmeno supportare il comando!)

Non ho mai provato, ma, secondo me, Windows non mi fa cancellare C: o perlomeno il contenuto della directory "System". Su Linux c'è sta idea bislacca che se l'utente sbaglia sono c*zzi suoi; siate onesti quante volte vi è capitato un "*" per sbaglio dopo "rm"? Io ogni volta che uso il comando "rm" sono terrorizzato... costerebbe tanto avere il concetto di cestino? [1]

Ahh ovviamente per fare cose serie tipo una cosa banale come accedere alle porte di rete su Linux si deve essere root quindi sulle macchine di produzione l'unica utenza che ha senso è root :eek:
(Io sulla mia CentOS che ho come desktop manco l'orologio posso cambiare con la mia utenza figuratevi!)

[1] Il fatto che '*' venga "esploso" dalla shell e che quindi il comando non possa nemmeno dire "ehi cretino vuoi davvero cancellare tutto il contenuto della directory?" è un errore progettuale che proviene da Unix. Non so oggettivamente se anche la shell del DOS faccia così il sistema operativo che sto scrivendo io (sì sto scrivendo un SO) di sicuro non ripeterà questa c*zzata!

Tecnicamente comunque un sistema che sta girando dovrebbe impedire di essere cancellato da un "rm -rf /", OK che sei root però è un operazione che oggettivamente non ha senso! Dovrebbe almeno lockare file / directory necessarie per il suo funzionamento... il tool per disinstallare un SO è il comando format!
(La directory di UEFI che non è nemmeno una directory reale ha ancora meno senso che si possa cancellare non dovrebbe nemmeno supportare il comando!)

Ok, ma ha ancora meno senso scrivere "rm -rf /".
Tra l'altro, di solito questi comandi li usa chi sa cosa sta facendo, spero...


Non ho mai provato, ma, secondo me, Windows non mi fa cancellare C: o perlomeno il contenuto della directory "System". Su Linux c'è sta idea bislacca che se l'utente sbaglia sono c*zzi suoi; siate onesti quante volte vi è capitato un "*" per sbaglio dopo "rm"? Io ogni volta che uso il comando "rm" sono terrorizzato... costerebbe tanto avere il concetto di cestino? [1]

Sul concetto di "cestino" concordo con te. Effettivamente, il fatto che rm sia irreversibile è un po' una stronzata.

[1] Il fatto che '*' venga "esploso" dalla shell e che quindi il comando non possa nemmeno dire "ehi cretino vuoi davvero cancellare tutto il contenuto della directory?" è un errore progettuale che proviene da Unix. Non so oggettivamente se anche la shell del DOS faccia così il sistema operativo che sto scrivendo io (sì sto scrivendo un SO) di sicuro non ripeterà questa c*zzata!

Stai scrivendo un S.O. da solo? Buona fortuna...

Tecnicamente comunque un sistema che sta girando dovrebbe impedire di essere cancellato da un "rm -rf /", OK che sei root però è un operazione che oggettivamente non ha senso!
Infatti quel comando è impedito, non fa nulla, dovreste saperlo
per cancellare la root devi aggiungere no-preserve-root.
Ma allora che facciamo ? sarò libero di fare quello che voglio sulla mia macchina, oppure dobbiamo stilare la lista dei comandi che hanno senso, e li compiliamo nel codice di rm, chmod, chown, ecc, nelle shell sh bash csh ecc ecc ? :D
Fare i paragoni con Windows se fa cancellare C: o no, per piacere fa rabbrividire, almeno i paragoni facciamoli con un Sistema Operativo degno di questo nome.

Sul concetto di "cestino" concordo con te. Effettivamente, il fatto che rm sia irreversibile è un po' una stronzata.

ma qui stiamo parlando di sistemi operativi, o di sistemi desktop con interfaccia grafica che vanno in mano all'utente ?

ma qui stiamo parlando di sistemi operativi, o di sistemi desktop con interfaccia grafica che vanno in mano all'utente ?

Che c'entra? Non hai mai commesso errori al terminale? Io, sinceramente, una volta per sbaglio ho cancellato cose che non volevo con "rm". Forse ero rimbambito, ma è successo. Ci vuole tanto, in certi casi (ad esempio quando usi "*"), a chiedere:"Vuoi davvero fare 'sta cosa?"

Quante righe di codice sono? 3?

Tecnicamente comunque un sistema che sta girando dovrebbe impedire di essere cancellato da un "rm -rf /", OK che sei root però è un operazione che oggettivamente non ha senso! Dovrebbe almeno lockare file / directory necessarie per il suo funzionamento... il tool per disinstallare un SO è il comando format!
(La directory di UEFI che non è nemmeno una directory reale ha ancora meno senso che si possa cancellare non dovrebbe nemmeno supportare il comando!)

Già l'essere e usare root implica l'accettazione di poter fare danni più o meno estesi più o meno per sbaglio.
È un tipo di account da usare cum grano salis, come ti ricorda la shell quando lo attivi per la prima volta.
Root ha potere illimitato sul sistema... e da grandi poteri derivano grandi responsabilità (cit.)

Se poi tu fa la cazzata di usare quel comando, se sai cosa stai facendo ne conosci anche le eventuali conseguenze. Se non sai cosa stai facendo, 'azzi tuoi, ti serva da lezione.



Non ho mai provato, ma, secondo me, Windows non mi fa cancellare C: o perlomeno il contenuto della directory "System". Su Linux c'è sta idea bislacca che se l'utente sbaglia sono c*zzi suoi; siate onesti quante volte vi è capitato un "*" per sbaglio dopo "rm"? Io ogni volta che uso il comando "rm" sono terrorizzato... costerebbe tanto avere il concetto di cestino? [1]


Non è un'idea bislacca. In primo luogo l'utente root è fatto apposta per avere il controllo totale sul sistema. In secondo luogo, proprio per il primo punto, non andrebbe usato con leggerezza.

Se ti connetti come root anche per le peggio cazzate, sono fatti tuoi.


Ahh ovviamente per fare cose serie tipo una cosa banale come accedere alle porte di rete su Linux si deve essere root quindi sulle macchine di produzione l'unica utenza che ha senso è root :eek:
(Io sulla mia CentOS che ho come desktop manco l'orologio posso cambiare con la mia utenza figuratevi!)


Puoi abilitare il tuo utente a fare certe azioni facendolo entrare nel relativo gruppo.
Oppure usare root SOLO per quella specifica azione e poi tornare all'utente normale.

[1] Il fatto che '*' venga "esploso" dalla shell e che quindi il comando non possa nemmeno dire "ehi cretino vuoi davvero cancellare tutto il contenuto della directory?" è un errore progettuale che proviene da Unix. Non so oggettivamente se anche la shell del DOS faccia così il sistema operativo che sto scrivendo io (sì sto scrivendo un SO) di sicuro non ripeterà questa c*zzata!

No, non è un errore. L'errore in quel caso sta tra il monitor e la tastiera.
Root è l'account "zitto ed esegui senza scassare i cogli*ni. Se ti dico "sparati" devi solo chiedermi "dove?" ". Questo significa essere root ed è per questo che solitamente è disabilitato di default e va usato sapendo quello che si fa.

da linuxaro convinto mi chiedo a cosa serva un comando simile.

Che c'entra? Non hai mai commesso errori al terminale? Io, sinceramente, una volta per sbaglio ho cancellato cose che non volevo con "rm". Forse ero rimbambito, ma è successo. Ci vuole tanto, in certi casi (ad esempio quando usi "*"), a chiedere:"Vuoi davvero fare 'sta cosa?"

Quante righe di codice sono? 3?
minkia abbiamo scoperto l'america, l'opzione -i oppure --interactive[=WHEN]
vedi "man rm"

>touch pippo.txt
>ls
pippo.txt
>rm -i pippo.txt
rm: remove regular empty file ‘pippo.txt’? y

fico eh ? puoi farti un alias con rm che usa sempre -i e sei a posto
del tipo alias rm='rm -i'
e poi tutte le volte che lo usi, ti rompe i cojoni e devi mettere "y", sai che comodità :D

da linuxaro convinto mi chiedo a cosa serva un comando simile.
perchè rm /dev/* o altro del genere, avrebbe senso ?
oppure ti aspetti che un comando abbia sempre la stessa funzione, e poi la semantica saranno caxxi di chi lo usa ?
se devi mettere nel codice ogni caso particolare, buonanotte

comunque mi sembra che il preserve-root l'hanno dovuto mettere apposta :D
sai che simpatia ed ilarità generale quando sul terminale metti "rm -rf /" senza battere "return", poi parte il salvaschermo, e il pollo di turno per svegliare dal salvaschermo schiaccia "return" ?

Infatti così comodo che poi ci metti -f e se d'accapo :D
Invece se avesse un concetto di "cestino" (questo vorrebbe dire che "rm" sarebbe in realtà una sorta di mv) uno in caso di errori potrebbe restorare il file.

@battilei
OK sei uno di quelli che pensa che Windows sia un giocattolo, rilancio con BeOS / Haiku quando si tenta di cancellare le directory in cui sono contenuti i file di sistema appare una alert di errore con 2 tasti uno che dice "Lascia Stare" e l'altro che dice "Esegui" il tasto esegui è pure grigio e bisogna premere SHIFT o altro tasto per abilitarlo! Certo quella è una GUI, ma volendo anche da linea di comando si potrebbe farlo...

Non dovrebbe essere "rm" ad essere cambiato, ma semplicemente directory / file essenziali al funzionamento del sistema dovrebbero essere o locked o in casi estremi (come quello in esempio visto che parliamo di parti essenziale per il funzionamento della macchina!) in sola lettura... semplicemente quelle operazioni dovrebbero dare errore.

@GTKM
Purtroppo come dicevo nel mio post rm quando riceve '*' come argomento (ma vale per anche comandi più innocui come ls per dire) non lo può mica sapere è la shell che quando vede '*' esplode la wildcard ciò che rm riceve è 'rm <lista file della directory>' e quindi esegue e buona notte suonatori! Quella di far esplodere '*' alla shell sembrava una buona idea, ma col senno di poi è evidente che non lo è.
Il caso di '/' invece è gestito visto che riceve proprio '/', l'esistenza del flag no-preserve-root è un po' una nerdata sai che è un'operazione che non andrebbe mai fatta, ma mi dai il modo di farla lo stesso? Che senso ha?

P.S. Il sistema basato su C# non l'ho scrivendo da solo siamo ben in 3! Probabilmente sarà un "gioco" però ricordatevi che anche Linux era partito un po' come un gioco e l'aveva sviluppato una persona tutto da sola quindi... :p
In ogni caso imparerò qualcosa quindi male non farà in ogni caso!

P.P.S. Se il PC era in garanzia i furboni con questo comando l'avranno pure invalidata ben gli sta!

minkia abbiamo scoperto l'america, l'opzione -i oppure --interactive[=WHEN]
vedi "man rm"

>touch pippo.txt
>ls
pippo.txt
>rm -i pippo.txt
rm: remove regular empty file ‘pippo.txt’? y

fico eh ? puoi farti un alias con rm che usa sempre -i e sei a posto
del tipo alias rm='rm -i'
e poi tutte le volte che lo usi, ti rompe i cojoni e devi mettere "y", sai che comodità :D

Ammetto che non avevo minimamente pensato all'opzione -i (sì, è una comodità)

Invece se avesse un concetto di "cestino" (questo vorrebbe dire che "rm" sarebbe in realtà una sorta di mv) uno in caso di errori potrebbe restorare il file.

e allora fatti un
alias rm='mv /trash'
e sei già a posto :D


@battilei
OK sei uno di quelli che pensa che Windows sia un giocattolo
mah sai Unix è nato cresciuto ed insegnato nelle università fin dalla notte dei tempi
il Colabrodo invece negli uffici delle segretarie e nelle case dei gamers

Ma scusa, se usi in maniera incosciente 'rm -f' sono 'azzi' tuoi. E' lo stesso discorso di root. Io non voglio un sistema compromesso nella sua struttura perchè ci sono alcuni che non pensano quando lanciano i comandi.

E comunque leggi prima. Un programma che fa quello che dici(eliminazione + cestino) c'è sicuramente e al limite fai un alias. Non lo prescrive il dottore di usare rm

Concordo.
Linux è un sistema che va bene così com'è.
Se volete un giocattolo per bimbi da 0 a 3 mesi, c'è OSX.

e allora fatti un
alias rm='mv /trash'
e sei già a posto :D


Esatto, potrebbe essere una soluzione per avere un cestino rudimentale :D .

...
...
Siamo su un forum, non su twitter/facebook/altro. Utilizzate il quote per cortesia, cosi non si capisce nulla. :doh:

Simpatia portami via. Francamente se uso @ invece che quote non vedo il problema, basta far capire chi è il destinatario.

Ni.

Perché in quel modo "costringi" altri interessati alla discussione ad andare a rileggere cosa aveva scritto l'utente. Con il quote è tutto lì, nello stesso posto.

Questo ha senso, grazie. Correggo i miei messaggi.

Sia chiaro, io non avevo problemi nemmeno prima, ma l'utilità del QUOTE, fondamentalmente, sta in quello. :D

Ma scusa, se usi in maniera incosciente 'rm -f' sono 'azzi' tuoi. E' lo stesso discorso di root. Io non voglio un sistema compromesso nella sua struttura perchè ci sono alcuni che non pensano quando lanciano i comandi.

E comunque leggi prima. Un programma che fa quello che dici(eliminazione + cestino) c'è sicuramente e al limite fai un alias. Non lo prescrive il dottore di usare rm

comunque il fatto di dover porre attenzione ai comandi da dare quando si usa l'account di root non giustifica questo problema

Ok che bisogna fare attenzione ma su una macchina come un pc il sistema (inteso come hw) deve essere sempre recuperabile.
faccio danni con rm e distruggo il sistema operativo bene, sono cavoli miei e riparto da zero il problema è che con questo baco questo non è possibile.
se io lavoro a livello di sistema operativo non devo essere in grado di causare danni HW (software per il flash a parte ma questi sono tool che si installano e si utilizzano solo per quello specifico ambito non comandi base del sistema operativo utilizzati anche nel comune uso)

quello che mi fà strano è che non esiste un'impostazione, una combinazione da tastiera, un rito vodoo:D in grado di attivare un recovery dell'uefi da una rom secondaria in sola lettura (magari anche una versione minimale giusto un bootloader di emergenza in grado di scaricare dalla rete la versione corretta dell'uefi )

pure sull'elettronica embedded (molto meno raffinata di un pc) c'è sempre un modo per tornare indietro, più o meno complicata per riflashare il bootloader

Questo discorso non vale secondo me in ottica linux. La filosofia è che se hai i permessi di root hai la libertà di fare tutto quello che ti pare macchina(e con libertà intendo proprio il concetto politico).
Il che implica che puoi anche accedere direttamente alle risorse hw del sistema senza intermediari e di avere la possibilità potenziale di danneggiare lo stesso (e non solo cancellando uefi).

D'altro canto tutta questa libertà permette di fare cose che su altri sistemi non sono possibili e un ciclo di sviluppo più rapido.

Se uno non vuole fare danni hw fa un utente admin senza permessi hw.

E giusto questo sistema? Dipende dalle esigenze. Se uno vuole qualcosa di più 'sicuro' si orienta verso altri SO. Ma chiedere di snaturare un sistema per la disattenzione di alcuni utenti non penso sia la soluzione.



This!

Sicuramente il sistema è scritto con i piedi e tra l'altro a quanto pare l'implementazione uefi in questione era pure fuori standard.


sulla prima parte non sono d'accordo, se io ho i privilegi di root su un sistema operativo il sistema mi deve permettere di fare quello che voglio, anche incasinare, solo quel sistema operativo non l'intero sistema senza possibilità di recupero e non si snatura minimamente la natura di linux e dell'utente di root

io lavoro tantissimo con sistemi embedded (come penso si capisca da molti dei miei interventi) e spesso lavoro direttamente senza sistemi operativi di nessun tipo direttamente bare to metal ma anche in questo caso ho sempre la possibilità di tornare indietro sia sul fw del mcu (che controllo direttamente) sia sul fw di altre periferiche eventualmente a bordo
faccio qualche danno e distruggo il sistema--> via seriale ricarico l'applicazione precedente e continuo
faccio qualche danno di livello atomico e distruggo l'intero contenuto della eeprom--> apro il cassetto estraggo il programmatore e riflasho direttamente un bootloader base --> sistemo il danno--> applico le patch che mi servono---> ricarico l'applicazione.

ed è così da anni il numero di hw brickati in laboratorio si contano sulle dita di una mano monca e le cause sono tutte da imputare a problemi hw mai software (mi ricordo ancora certe sfiammate da cortocircuito degne della festa di capodanno di Londra :D:D:D

Si, però se ho l'accesso alle risorse hw acquisisco automaticamente il potere di danneggiare lo stesso. L'altra faccia della medaglia è che se voglio portare il sistema su un'altra architettura, voglio scrivere un driver più o meno esotico, voglio modificare i firmware del sistema, anche solo per risolvere bug o migliorarli, oppure voglio vedere cosa viene eseguito dal SO a basso livello, lo posso fare.

non proprio

con linux non hai accesso diretto alle risorse hw, hai accesso ad una serie di interfacce di basso livello con cui dialoghi con l'hw e puoi impostare una serie di parametri delle periferiche ma non puoi mai arrivare al danneggiamento dello stesso anche se fai cose esotiche. (classico esempio se modifichi le impostazioni del sistema di raffreddamento rallentando o spegnendo le ventole modificando anche il thermal throttling il massimo che puoi ottenere è uno spegnimento di emergenza del sistema non la fusione della cpu.

i firmware che gestiscono le varie periferiche non sono accessibili al sistema operativo, il massimo che il sistema operativo ti permette è di utilizzare un protocollo di comunicazione per aggiornare il firmware delle periferiche partendo da un binario.
un fw sbagliato si che può fare danni all'hw proprio perchè la maggior parte dei sistemi di protezioni sono gestiti dal fw ma non è il sistema operativo a fare direttamente danni . Comunque anche in questo caso a meno di guasto catastrofico causato dal fw prima del downgrade c'è sempre il modo di tornare indietro caricando un fw corretto.

se ci pensi l'unico modo quasi sicuro per fare danni all'hw è interrompere a metà un aggiornamento fw staccando la corrente ma anche in questo caso spesso i produttori si cautelano mettendo appropriate protezioni HW (vedi schede madri con doppio bios di cui uno in sola lettura e totalmente fail safe, mobo con bios zoccolato ecc ecc ).

ps se hai le competenze per scrivere un fw per una periferica allora significa che conosci benissimo la periferica, conosci lo schema circuitale e conosci come riuscire a tornare indietro ma si parla di competenze veramente specifiche e inoltre totalmente indipendenti dal sistema operativo

In linux se vuoi puoi scrivere un modulo da caricare on the fly nel kernel. A quel punto potenzialmente puoi fare qualsiasi cosa.



Mi sono spiegato male. Il senso del discorso era che potenzialmente puoi fare danni irreparabili quando hai il controllo totale dell' hardware via software.



Figurati non ho mai detto il contrario. Certo è che se su linux hai la possibilità di agire sugli stessi caricandone di nuovi, questo, per mia ignoranza, non so se vale su altri sistemi operativi, in particolare quelli che richiedono moduli firmati (a meno che tu non sia il produttore dell'HW o del SO)

Sul tornare indietro non sono propriamente d'accordo. Provo a fare un esempio.

Supponiamo che tu dovessi sviluppare un driver per il risparmio energetico di un dispositivo embedded. Potresti avere la necessità di agire sui regolatori di tensione e sul generatore di clock. Potenzialmente impostando valori errati potresti rompere la scheda. D'altro canto questo è l'unico modo per scrivere il driver.

mi dispiace ma non è così anche con un modulo nel kernel tu confondi driver con fw

Scusami tanto, e dove avrei scritto questo?

Magari sei te che non sai che si può caricare un firmware con un driver scritto allo scopo(sono ironico eh!)

se io parlo di fw e tu mi parli di moduli kernel module io che dovrei pensare?
parli come se un driver di qualunque tipo abbia accesso diretto alla componentistica e ciò non è assolutamente vero visto che quanto meno esiste un protocollo di comunicazione che viene gestito da un microcontrollore su una periferica

nel tuo esempio parli di modifica dei valori del vrm come se fosse possibile costringere via sw la scheda a generare una tensione in grado di distruggere l'elettronica e questo non è possibile a meno di errori nella progettazione hw della scheda.

se imposti con un fw o driver + firmware una tensione troppo alta accade una delle seguenti 2 cose
1) il sistema ignora il tuo comando (il fw filtra la richiesta in quanto riconosciuta errata e non pilota le uscite digitali che comandano il vrm)
2) il fw non fà nessun controllo, comanda le uscite e il vrm si setta alla massima tensione decisa dal progettista hw direttamente con un riferimento sul circuito

comunque il flashing di un fw è una cosa che esula completamente dal contesto nel caso in questione il notebook si comporta come se fosse l'equivalente di due pc in rete dove la root dell'efi viene condivisa in rw nella root del sistema operativo senza nessun bkp



per tornare nei binari. Quello che vorresti è che il MODULO che mappa il contenuto della uefi nel VFS di linux non fosse caricato di default? In ogni caso se uno vuole spararsi nei piedi può caricare da root un modulo che scrive sul contenuto della uefi e siamo a punto e a capo.
quello che sarebbe utile è che la root dell'uefi sia montata in solo lettura o che sia montata una copia e che la scrittura della flash della uefi venga autorizzata mediante uno specifico protocollo e che non sia possibile agire direttamente sulla memoria della uefi mediante il solo uso file system

Che qui si stanno confondendo le cose scrivere un driver di kernel per spaccare l'hardware (che come !fazz fa notare anche con il miracoloso Linux non dovrebbe avere alcun effetto) con una cosa apparentemente innocua come una directory con dentro un file... è come se io facessi "rm -rf /dev/cpu" e la CPU si autodistruggesse, dai!

La verità è che su Linux / Unix c'è sta cosa che tutto è un file anche cose che non sono file (!), per leggere / scrivere quelle chiavi dovevano fare una API decente e un tool anche a linea di comando se ci tenevano (anche se uno ha un desktop un tool per smanettarci sarebbe stato d'uopo) per leggerle / scriverle nella maniera corretta. Per dire si potevano far danni anche aprendo quel "file" e scrivendoci valori non validi dentro... è accettabile?
IMHO no...

Va bene difendere Linux perché ci siete affezionati, ma che colpa ne ha MSI se espone parti "sensibili" del BIOS? Su Windows e Mac OSX ste cose non possono capitare non almeno così "per distrazione" se parliamo di virus scritto ad hoc è, ovviamente, un altro discorso.

Cosa credete farà il produttore? "Se installate un O.S. non certificato la garanzia decade" ed è corretto se Linux permette di branzare una parte del BIOS...

Scusate però, io devo ripetermi...

Io ho sempre saputo che il BIOS è in una EEPROM, la quale ha una sezione flash, e una sezione CMOS volatile.
Tutte le variabili stanno sulla CMOS, diversamente sarebbe da idioti :stordita:
Allora, siccome non penso proprio che quel comando esegua un flash sulla ROM, anche perché la ROM partirebbe in poco tempo se ogni volta dovesse ri-flashare per il cambio di una variabile ...
Insomma per fare danni al BIOS irreparabili, occorre, o almeno dovrebbe occorrere di flashare la parte ROM.
Per farlo in modo "safe" serve un utility apposita.
Che io sappia è così da sempre, sia senza EFI che con EFI.

Perché con un CLEAR CMOS e la riparazione dell'OS (compreso eventualmente bootloader, settori di avvio ecc.) non si può riparare al danno?

Che qui si stanno confondendo le cose scrivere un driver di kernel per spaccare l'hardware (che come !fazz fa notare anche con il miracoloso Linux non dovrebbe avere alcun effetto) con una cosa apparentemente innocua come una directory con dentro un file... è come se io facessi "rm -rf /dev/cpu" e la CPU si autodistruggesse, dai!

La verità è che su Linux / Unix c'è sta cosa che tutto è un file anche cose che non sono file (!), per leggere / scrivere quelle chiavi dovevano fare una API decente e un tool anche a linea di comando se ci tenevano (anche se uno ha un desktop un tool per smanettarci sarebbe stato d'uopo) per leggerle / scriverle nella maniera corretta. Per dire si potevano far danni anche aprendo quel "file" e scrivendoci valori non validi dentro... è accettabile?
IMHO no...

Va bene difendere Linux perché ci siete affezionati, ma che colpa ne ha MSI se espone parti "sensibili" del BIOS? Su Windows e Mac OSX ste cose non possono capitare non almeno così "per distrazione" se parliamo di virus scritto ad hoc è, ovviamente, un altro discorso.

Cosa credete farà il produttore? "Se installate un O.S. non certificato la garanzia decade" ed è corretto se Linux permette di branzare una parte del BIOS...

Non branza una parte del bios. Grosso modo per farti un esempio, sarebbe l'equivalente di entrare nel bios e impostare tutti i valori a zero. Ma il firmware uefi della scheda madre dovrebbe accorgersi del malfunzionamento è riportare tutti i valori a quelli di fabbrica. Se non altro farlo tramite un reset (cosa che mi pare non sia disponibile nei portatili) oppure rimuovendo la batteria di backup. Cosa che non accade.

perchè rm /dev/* o altro del genere, avrebbe senso ?
oppure ti aspetti che un comando abbia sempre la stessa funzione, e poi la semantica saranno caxxi di chi lo usa ?
se devi mettere nel codice ogni caso particolare, buonanotte


mi sa che non hai capito quello che intendevo.
se da root dai un rm -fr e quello ti cancella il mondo, sono cazzi tuoi ed e' giusto cosi'.
pero' che senso ha dare consciamente un comando simile, a meno che non si voglia dare un rm /miadir
e invece si scrive
rm / miadir.

per il resto sono d'accordo con !fazz.
quei file non dovrebbero manco esistere su filesystem. il kernel di serie nelle distro, dovrebbe non avere quel cazzo di driver.
e il portatile dovrebbe avere un modo per ripristinarlo senza mandarlo in assistenza.

il succo del discorso non e' linux o non linux. e' colpa di quel cretino che ha avuto l'idea di inserire di default nel kernel un driver che da' problemi.
ora che e' saltata fuori sta storia, spero che i responsabili delle varie distro rimuovano dal kernel di default quel driver.

Scusate, ma mi pare che ci sia un po' di confusione.
Come ho detto la EEPROM del BIOS ha DUE sezioni.
Una è la ROM.
Una è la CMOS.

Quale delle due viene intaccata da quel comando?
Se entri nel BIOS e imposti tutti i valori a zero, nell'ipotesi che fosse permesso dall'interfaccia, staresti modificando la CMOS, e in quel caso sarebbe sufficiente un clear CMOS.

Mi sembra strano che l'OS possa nativamente flashare nella ROM, servirebbe l'utility apposita del tipo di BIOS, che supportasse il chipset ecc..

Tra l'altro non si possono cancellare/modificare solo alcuni moduli dalla ROM, perché sono compressi e protetti. È ridicolo che sia vista come una partizione r/w, semplicemente perché non la si può scrivere, perché l'OS non può sapere cosa e come farlo, è diverso per ogni piattaforma.
Tra l'altro il BIOS viene messo in cache sulla RAM, l'OS non può accedere direttamente alla ROM.
Provate a modificare un BIOS recente, è un casino, roba quasi da crittografia con protezioni CRC ecc..
Va ricompilato a partire dal sorgente, poi cancellata la ROM, flashata e verificata.
È una procedura particolare, che tra l'altro necessita tempo.

C'è qualcosa che non mi torna.

Forse semplicemente trattandosi di un portatile, non è stata presa in considerazione l'ipotesi di agire dall'hardware per fare un clear CMOS.

EDIT: al massimo forse il ponticello potrebbe non essere sufficiente, e bisogna togliere la batteria per forza. Il ponticello a volte non cancella tutto.
In effetti per un notebook in garanzia è un bel problema, anche se tecnicamente sarebbe una sciocchezza.

Uso spesso /sys per programmare l'hardware;
non penso che siano stati cancellati files o bios, ma che alcune variabili non volatifi efi siano state scritte rendendo impossibile l'esecuziono delle normali procedure;
m ispiego meglio; se si distrugge il filesystem i files vegono persi, ma qui no nsi distrugge nulla, semplicemente vengono inserite informazioni in una posizione che di per se e' strutturalmente valida, ha un checksum valido e una formattazione valida del contenuto.
In questo caso il bios uefi non e' in grado di capire che le informazioni contenute non sono adatte all'avvio e non usa dei default, ad esempio il file potrebbe contenere qualcosa sulla risoluzione del tipo:
hres=0 vres=0 i quali hanno sintassi e formattazione corretta e non viene fatta la verifica che il display non supporta una risoluzione 0x0 quindi il modulo sucessivo del bios che riceve questi dati puo' malfunzionare.
figuriamoci per le imnformazioni di avvio......
Se comunque la shell uefi si avvio a livello cpu dovrebbe esserci un metodo per accederci e avviare mano i files necessari; spesso si tratta di una uart sulla cpu stessa a cui l'utente medio non ha accesso fisico...........
L'unica speranza e' che questi dati si trovino in un filesystem overlay sorretto dalla ram dell''orologio (la cosidetta memoria cmos) per cui l'eventuale distacco della batteria tampone ne renderebbe invalido il contenuto e il bios caricherebbe impostazioni predefinite se presenti.

Mah, comunque bisognerebbe capire bene come mai è stata fatta questa scelta. A suo tempo era già stato aperta una segnalazione in merito che poi è stata chiusa. Quindi questo comportamento è una cosa voluta non una 'distrazione' o una scelta poco oculata. E dalle dichiarazioni degli sviluppatori questa interfaccia è attualmente utilizzata da alcuni programmi sia in scrittura che in lettura.

Resta il fatto che una scelta che rompe i principi con cui è stato sviluppato un software a causa della pigrizia o della superficialità di alcuni utenti, non può che essere una scelta sbagliata che costringe a scrivere codice di bassa qualità.

Che c'entra la qualità del codice, adesso?

Tra l'altro, mi sa che nella "storia" del Kernel Linux ci sono già fulgidi esempi di cose strane: ALSA? OSS?

mi sa che non hai capito quello che intendevo.
se da root dai un rm -fr e quello ti cancella il mondo, sono cazzi tuoi ed e' giusto cosi'.
pero' che senso ha dare consciamente un comando simile, a meno che non si voglia dare un rm /miadir
e invece si scrive
rm / miadir.

per il resto sono d'accordo con !fazz.
quei file non dovrebbero manco esistere su filesystem. il kernel di serie nelle distro, dovrebbe non avere quel cazzo di driver.
e il portatile dovrebbe avere un modo per ripristinarlo senza mandarlo in assistenza.

il succo del discorso non e' linux o non linux. e' colpa di quel cretino che ha avuto l'idea di inserire di default nel kernel un driver che da' problemi.
ora che e' saltata fuori sta storia, spero che i responsabili delle varie distro rimuovano dal kernel di default quel driver.

io rm -rf / lo uso e anche abbastanza spesso :D

nel senso che a lavoro ho di solito necessità di provare e riprovare diversi sistemi operativi / sistemi vari e abbiamo una serie di hdd / chiavette / ssd ecc ecc di spare che si usano per le prove + un'altra serie con le configurazioni definitive e abbiamo l'usanza di piallare completamente i supporti di prova dopo l'uso così quando un altro ha bisogno di un disco per prima cosa controlla che sia vuoto poi lo usa, tutto questo per evitare di perdere accidentalmente ore di lavoro nel caso qualcuno sbagli scaffale :D

per il resto sono d'accordo con te a parte che non è che il driver dia problemi, il driver funziona benissimo e fà esattamente quello che la mente ingenua del programmatore ha implementato: montare il scrittura l'uefi senza nessun controllo

Ma almeno questa "caratteristica" è spiegata bene nella documentazione di linux?
Ma c'è una documentazione che spieghi che su quella "cartella" è montata una parte del BIOS?
Forse anche questo da parte di linux potrebbe essere migliorato, ma questo è un discorso che vale per ogni singola distribuzione.

Per quanto riguarda il BIOS UEFI invece, ho l'impressione che sia dato per scontato che venga fatto un controllo lato software, anzi senza essere generici, ho l'impressione che sia dato per scontato che ci sia un OS microsoft, che tanto non permette l'accesso a quell'area del BIOS.
Insomma viene lasciata la responsabilità della manipolazione dei dati all'OS.
Solo che linux per definizione lascia la responsabilità all'utente root, come filosofia.

D'altronde UEFI non era stato progettato da Intel? O ricordo male?

Quando accadono queste cose, la colpa non è mai solo di una parte.
Però implementare un avviso per ogni scrittura su quella cartella, mi sembra un workaround più che una soluzione, poi la vedo come una cosa un po' complicata lato tecnico.

https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface
https://wiki.debian.org/UEFI
Grazie, avevo fatto una rapida ricerca, ma sono un po' scarso :D
Beh direi che la documentazione parla chiaro :read:

Spero che a nessuno venga mai in mente di lanciare questo comando in presenza di una seconda chiavetta montata nel filesystem in cui magari ci sono dati importanti...

(Ma non puoi fare un alias a 'dd if=/dev/null of=/dev/sdX'?)

no perchè il mio scopo è quello di ripulire completamente la memoria da qualsiasi traccia di file relativi all'applicazione precedente e nel mio caso è più pericoloso avere una configurazione sbagliata che non avere la configurazione nel primo caso si potrebbe casuare un funzionamento improvviso di una macchina con possibili danni da parecchi K€ e/o possibili problemi di infortuni nel secondo caso la macchina non parte.

e anche se dimentichi una chiavetta su una macchina di test prendi e riscarichi quello che ti serve dalle macchine e server di sviluppo. quando si lavora non si lavora come si dice da me "tat al toc" ovvero così per fare ma ci sono una serie di regole da rispettare e una delle più importanti è separare gli ambienti di sviluppo test e produzione

I nuovi hardware comunque mi lasciano sempre piu' perplesso:

http://arstechnica.com/gadgets/2016/02/google-engineer-finds-usb-type-c-cable-thats-so-bad-it-fried-his-chromebook-pixel/

A parte il caso del guasto argomento dell'articolo, il fatto che un chip sia fuori uso e il bios non ne rilevi la presenza fa si che il bios uefi fallisca la verifica del sistema e parta sempre in modalita' emergenza; significa che se si guasta un componente stupido di cui spesso puoi fare a meno potresti trovarti nell'impossibilita' di usare l'apparecchio.
Capisco la necessita' di sicurezza, ma mi sembra che ultimamente in campo tecnologico gli effetti collaterali delle protezion isiano peggiori delle malattie.

Per tagliare la testa al toro ho letto la parte incriminata della

Revisione 2.0 dello standard UEFI (corretta) (http://www.uefi.org/sites/default/files/resources/UEFI_Specification_2_and_Errata_Sept16_08.pdf)

Pagina 61:



Gli sviluppatori del sistema gnu/linux e compagnia bella quindi non sono quindi colpevoli di una implementazione non conforme dello standard UEFI da parte del produttore HW

Se poi si da un'occhiata all'overview della specifica si capisce benissimo perche' l'hanno montata e l'hanno fatto RW...
bel lavoro, ma se guardi a pag.1 non avevamo dubbi già 2 giorni fa :D