Newsgroup: it.comp.os.linux.iniziare
Titolo: Chiavette USB senza partizioni

Ho visto il thread "problemi chiavetta USB" che si conclude con la risposta
di Roberto a RedWiz:
"Allora (confesso, solo dopo ho visto che parlavi di mac) e' una 
chiavetta NON partizionata, formattata direttamente in HFS sul device,
e non sulla prima partizione.
Insomma, un mkfs /dev/sda e non mkfs /dev/sda1." (17/1/2009 17:06)
Il filesystem presente sulla chiavetta è da montare come /dev/sdb (nel caso
specifico), cioè senza indicare alcuna partizione.
Si tratta del cosiddetto formato "Super-Floppy".
Io mi ci ero imbattuto -- nel senso che avevo dovuto creare appunto un
super-floppy-- quando avevo tentato di installare Puppy come Live USB, cioè
come avviabile da USB e, sulla scorta dei suggerimenti dell'ottimo help di
Barry Kauler (che prevede appunto l'evenienza), interno all'installer della
mini-distro, avevo scelto l'opzione che formatta la chiavetta USB senza
creare partizioni. Infatti il Bios di alcuni desktop o notebook (tra cui il
mio), "non proprio recentissimi", accetta l'avvio da USB solo se riconosce
che la periferica è un floppy: routine evidentemente predisposta per
avviare un computer privo di slot per floppy disk da un flpppy drive
collegato via USB.
Siccome sull'argomento avevo tenuto da parte l'URL seguente, lo metto in
comune:
http://www.linuxjournal.com/article/6867
[...]
Intuition therefore suggested mounting /dev/sda1 (on an otherwise IDE-based
system), but intuition turned out to be dead wrong in the Easy Disk's case.
Making the attempt resulted in this puzzling error:
guido:~# mount -t vfat /dev/sda1 /mnt/fob
mount: block device /dev/sda1 is write-protected,
mounting read-only
mount: /dev/sda1 is not a valid block device
Some other USB flash drives reportedly do mount precisely in that way,
whereas I found out that the Easy Disk mounts as /dev/sda, not /dev/sda1 or
any other partition number?that is, it treats the drive as a device lacking
the ability to house a partition table. The explanation of this curiosity
turns out to lie in the ATAPI Removable Media Device (ARMD) BIOS
Specification, laid down by Compaq and Phoenix in 1997 to generalise how a
floppy-like drive should behave on the ATA bus in anticipation of
traditional floppy drives going the way of the dodo. ARMD devices are
basically big floppy disks, which per the spec have no partition table.
Thus, the Easy Disk happens to be an ARMD (floppy-like) device. Apparently,
many other USB flash disks are, by contrast, treated as regular ATAPI
drives. 
[...]

 che la periferica č un floppy: routine evidentemente predisposta per


 partizioni (o 3 considerando anche lo swap).
  Dipende dall'uso che ne fai e dalla dimensione. Se la chiave è piccola
direi che una partizione va più che bene, se è grande potresti pensare di
ripartizionarla (anche per comodità tua).
  L'unica nota negativa pare sia dovuta all'uso di chiavi partizionate sotto
windows (e non so se è il tuo caso); leggevo che windows riesce a leggere
solo la prima partizione montabile dei device usb, quindi tutte le altre
sarebbero per lui invisibili (potresti sempre mettere i dati prima e il
sistema dopo). La cosa è documentata qui
http://www.fs-driver.org/troubleshoot.html
 (ebbene si, cercavo un sistema
per far leggere il sistema ext a windows) dove parla proprio di dispositivi
con più partizioni.
-- 
Non pretendo che comprendiate il significato di quello che ho scritto senza
averlo riletto un certo numero di volte. Personalmente, vi riterrei degli
stupidi se lo faceste. Io l'ho letto sei volte ed ancora non l'ho capito.

 a windows) dove parla proprio di dispositivi con più partizioni.
Penso che il filesystem ext2/3 sia leggibile anche da windows,
con un apposito programma, probabilmente freeware o simili. Non
ho mai approfondito, però ho letto che non sia il massimo della
vita, ancorchè fat32 sia tutt'altro che perfetto.

JohnnyNewbie ha scritto:
-cut-

Significa che negli ultimi 66 byte del primo settore della partizione
( del device, in questo caso) non c'e' la tavola delle partizioni, ma
il primo settore effettivo del file system.
Fdsik cerca di interpretare quei dati come una partition table, e non
ci capisce una beata mazza.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 ci capisce una beata mazza.
Scusa roberto, _dimmi_ per favore _se_ _sei_ _d'_ _accordo_ _con_ _quanto_
_segue_ , perché nel quoting qui sopra non mi torna una cosa, che credo sia
semplicemente un'ambiguità espressiva.
Probabilmente era più chiaro dire che negli ultimi 66 byte del primo settore
del device c'è l'inizio del file system (cioè quello che diversamente di
troverebbe nel primo settore di una partizione), invece che la tabella
delle partizioni (che è quel che cerca fdisk).
La tabella delle partizioni si trova _sempre_ nel primo settore _del_
_device_ cioè si trova negli ultimi 66 byte (sappiamo che, per essere
precisi, si trova nei primi 64 byte, perché gli ultimi due sono dedicati
alla marcatura dell'MBR) del primo settore (cioè dei primi 512 byte) della
traccia 0 del device.
Quando ci sono partizioni, nel primo settore di una partizione si trovano le
strutture dati del file system e gli ultimi 66 byte del primo settore della
partizione possono contenere codice di boot della partizione (quando la
partizione contiene un sistema operativo), oppure dati.
La prima partizione parte dall'inizio della seconda traccia del disco,
perché la prima traccia (ossia la traccia 0, ovvero i primi 62 settori del
device) tradizionalmente viene ritenuta poco affidabile (molti dischi la
adoperano per le operazioni di parking e spin-up). L'inizio della prima
partizione si trova in realtà al 64_esimo settore, perché il 63_esimo è il
boot sector della partizione. Il boot sector della prima partizione (ovvero
il primo settore della partizione, ovvero il 63_esimo del device) conterrà
la descrizione completa del file system che lo contiene.
Quando _non_ ci sono partizioni, le strutture dati del file system iniziano
invece subito dopo lo spazio riservato al loader, cioè subito dopo i primi
_446_ byte.
Questo, _come_ _hai_ _già_ _detto_ _tu_ , è ciò che ha ingannato fdisk.
Semmai può essere aggiunto che un software come " _testdisk_ " avrebbe
analizzato il supporto indicando ciò che occorreva sapere. Usare testdisk,
quindi può essere una soluzione per capire come sia strutturata una
chiavetta USB (se ci sono o meno partizioni e che tipi di file systems
contiene.
Ti torna?
Aggiungerei che, in assenza di partizioni, la sovrascrittura dei primi 512
byte produce danni, al contrario di quanto avviene con un disco
partizionato, dove si possono tranquillamente sostituire l'MBR o il boot
sector della partizione con uno diverso senza intaccare i dati.
Quando una chiavetta USB è in formato _superfloppy_ , quindi, occhio a non
fare cavolate come è successo a me, che avevo sovrascritto i primi 512 byte
per sostituire un loader con un boot manager (cioè con smart boot manager),
perché, nel caso di specie, un'operazione del genere sovrascrive _anche_ le
strutture dati del file system, che, diversamente, inizierebbero nel
64_esimo settore, quindi ben oltre. Io ho velocemente ripristinato il file
system usando testdisk, che --se non ricordo male-- ha individuato la
presenza di una "FAT area" di backup (evidentemente quella ridondante che
il file system crea) e l'ha usata per riscriverla nel posto giusto (cioè a
ridosso dei primi 446 byte).
Infine, volevo segnalarvi quello che mi pare essere un errore qui:
http://guide.debianizzati.org/index.php/MBR
La spiegazione è corretta, ma i comandi sono sbagliati dove si trova
scritto "466" invece che "446".
Se mi confermi / confermate che è un errore, varrebbe la pena segnalarlo,
perché il comando che si trova ivi indicato:
dd if=/dev/zero of=/dev/hda bs=466 count=1
non cancella selettivamente il solo boot loader, come si vorrebbe, bensì
anche parte della tabella delle partizioni, mandando quindi al macero i
dati del disco (ok, si possono recuperare abbastanza facilmente per esempio
con testdisk , ma è comunque un guaio).

 
Esatto.
La mia frase si è arrotolata più del dovuto. :-(
Il concetto lo hai capito: il primo settore del device, invece di
contenere il boot record e la tavola delle partizioni, contiene il
primo settore della partizione unica (e non del file system).
Fdisk tenta di interpretarlo come boot record + tavola partizioni,
e si incarta.
Per il 446 al posto di 466 hai ragione, avvisali, se non lo hai già
fatto.


 Mi pare strano francamente.
Continuando a sembrarmi strano penso che la chiavetta comunque
possa essere organizzata appunto mettendo i dati nella prima
partizione.
Il discorso però è: posso partizionarla con fdisk come un comune
HD?
E il fatto che non abbia tabella delle partizioni cosa implica?
Voglio dire per quale motivo è stata fatta dal produttore questa
scelta? e ciò comporta qualche problema nell'ottica di adibirla
all'utilizzo che ho descritto sopra?

 =====================================================   
Per curiosità cosa significa quel Novell Netware 386?
Da dove salta fuori?
Perdo qualche funzionalità rasandola con fdisk o qualche tool
simile?

 simile?
No, non direi, ma e' inutile.
Se la monti con:
  mount /dev/sdb /puntodimount
invece che con
  mount /dev/sdb1 /puntodimount
Dovresti trovarti un file system vfat coerente.


JohnnyNewbie wrote:

Le informazioni che ti fornisce fdisk sono frutto di una
sua "allucinazione", nel senso che usa l'algoritmo idoneo ad interpretare i
dati di una partition table su dei dati CHE NON SONO di una partition table
(vedi precedenti messaggi nel thread).
Tu hai una chiavetta USB senza partizioni e formattata FAT32, no?
Se la vuoi partizionare, devi prima salvare da qualche parte i dati che vuoi
conservare, montandola come /dev/sdb , dopodiché puoi procedere a creare la
tabella delle partizioni che al momento non esiste.

 avvisali, se non lo hai già fatto.
Fatto.
Vediamo se saranno rapidi a correggere: quella guida è on-line già da
parecchio tempo... speriamo non abbia fatto troppi danni.

 3- swap 1 GB
direi che è OK.
Il boot del sistema operativo contenuto nella chiavetta come lo faresti?
Dall'hard disk del pc, immagino.
Ricorda che le partizioni che si trovano della chiavetta devono essere
montate in modo da minimizzarne l'usura, cioè in modo che le scritture
avvengano in modo più sporadico del normale (anche se oggigiorno le memorie
a stato solido sopportano un numero estremamente elevato di riscritture).
Tutto chiaro su questo?

 Tutto chiaro su questo?
Per nulla, mi informerò, se comunwu ti va di spendere due parole
in merito benvenga.
Grazie del supporto ;-) 

 Dovresti trovarti un file system vfat coerente.
Come storage in effetti cosě funziona senza problemi, almeno mi
sembra.

 scopo. Mi sbaglio
Ti sbagli limitatamente al fatto che esiste un tipo di installazione
detto "frugal installation" o "poor man installation" che permette di avere
l'albero delle directory di un sistema Linux all'interno di un singolo
file, detto "squash"; altre tecnologie di layering (FUSE, ecc.) fanno poi
il resto.
Teoricamente è possibile installare in questo modo qualsiasi distro e,
quanto meno, la possibilità è offerta out of the box da Puppy e,
storicamente, dalla Knoppix.
Hai davanti a te almeno due opzioni, secondo me:
- installare Puppy Linux sulla chiavetta lasciando questa così com'è:
l'installer di Puppy ti fa una fugal installation, cioè ti mette 4 file che
contengono tutto l'occorrente sulla chiavetta, copia il suo loader
all'interno del primo settore della chiavetta (per la precisione nei primi
446 byte) e il gioco è fatto (per lasciare in pace la chiavetta, devi
scegliere l'opzione specifica fatta per i Superfloppy);
- installare qualsiasi altra distro (ma anche la stessa Puppy, se vuoi)
partizionando la chiavetta (facendo la partizione al momento
dell'installazione, oppure preparandola prima); anche in questo caso la
procedura di installazione sulla chiavetta memorizzerà il boot loader
all'interno del primo settore (sempre i primi 446 byte, per il loader), ma
nei restanti 66 byte (quelli che mancano alla fine del primo settore) avrai
la tabella delle partizioni invece che una parte delle strutture dati del
file system; in questo caso puoi benissimo optare per una partizione di
swap più una ext3 per il sistema e una FAT32 per i dati all'interno della
chiavetta.
Se non hai preferenze e se non conosci Puppy, visto che ci sei, perché non
la provi con l'installazione per Superfloppy? Non c'è alcuna
controindicazione.
Anzi, se puoi, fai per cortesia una cosa prima di tutto: fai un check
dell'attuale file system nella chiavetta non partizionata, in modo che
possa servire (a me) come controprova di quel che dicevo nel messaggio di
ieri intitolato "Chiavetta USB senza partizioni e con filesystem FAT32 :
dosfsck /dev/sda", cioè digita questo comando:
dosfsck -v -n /dev/sdb
che fa il check del dispositivo in modalità verbose ( -v ) e senza apportare
comunque variazioni ( -n ).
Dimmi, quindi, se ti risponde che "There are differences between boot
sector and its backup"...
Ah, ma la tua è (ancora) una chiavetta non bootabile... è vero.
Allora: se per caso ti va di installarci Puppy laciandola così com'è, cioè
senza partizionarla, dopo che hai fatto l'installazione (che poi, come ho
accennato, è la frugal installation, ossia la copia di solo 4 file + la
scrittura del loader), eventualmente controlla il filesustem della
chiavetta col comando di cui sopra e, nel caso, fammi sapere.

 Mmmmm...Questo punto mi interessa particolarmente.
Ora non ho tempo per affrontare l'argomento, ma io opterei per il boot
loader all'interno della chiavetta stessa.
Qualora tu invece scegliessi di partizionarla, poi, potresti addirittura
installare un boot manager come Smart Boot Manager, o anche GAG, nel primo
settore della chiavetta e installare nel primo settore della partizione
ext3 il loader della distro ospitata nella chiavetta.
Ma procedi per affinamenti progressivi: perchè (visto che hai una chiavetta
che allo stato è priva di partizioni) non provi (prima di tutto) a fare una
frugal installation di Puppy scegliendo l'opzione Superfloppy?
Certo, se Puppy già la conosci e non ti piace, allora è un altro discorso.
Riguardo al limitare il flushing dei dati nella chiavetta per non consumare
il tetto massimo di scritture ammesse dalla tecnologia flash (a maggior
ragione se la chiavetta è di un po' di tempo fa, quando il tetto era più
basso di quello attuale, ma non mi pare sia il tuo caso, visto che se non
sbaglio ne possiedi una di 8 Giga), se scegli di installare una distro con
la relativa procedura di installazione fatta apposta per chiavette USB, il
settaggio viene fatto in automatico nell'ambito della procedura stessa.
Comunque, in buona sostanza, si tratta di un flag per il mounting della
partizione di root, cioè il flag " -o async ".
Considera che lo squash file system della Puppy installata in modalità
frugal è un file system ext3 e quindi può beneficiare di questa opzione di
mount che funziona solo per ext2 o ext3.
Il discorso "sync" vs "async" è la ragione per cui le chiavette prima di
staccarle fisicamente bisogna prima smontarle (procedura che fa un flushing
dei dati).
Infine, va detto che per limitare il numero di scritture (anche se ciò
valeva soprattutto un po' di tempo fa, mentre ora ha meno importanza, anche
se ne ha ugualmente) su una una chiavetta andrebbe installata una distro
che può funzionare bene anche senza swap su memoria di massa (in tal caso,
potrebbe benissimo beneficiare della partizione di swap eventualmente già
presente sul disco del PC: si accorgerebbe da sola della sua presenza al
momento del boot) e che possa eventualmente anche girare totalmente in RAM
(come può fare Puppy con l'opzione di boot pfix=ram, ma lo possono fare
anche tutte le distro live), necessitando di limitate risorse hardware.

 come storage classico.
E' quello che ho fatto io (dietro suggerimento di TRK):
prima si fa un partizione e la si numera come 4 delle dimensioni
sufficienti a contenere il sistema da avviare, la si segna come
partizione attiva.
Poi si fa la partizione numero 1 nello spazio restante, e così si
ottiene la moglie piena e la botte ubriaca: la 4 partizione [*]
fa il boot, sono comunque i primi settori, e quasi tutti i PC la
avvieranno, se non fai il boot, il 99.99% dei PC troverà la prima
partizione come mass storage.
Un esempio di fdisk della chiavetta che uso io:
poggirpc:/home/poggir# fdisk -l /dev/sdb
Disk /dev/sdb: 2032 MB, 
2032664576
 bytes
64 heads, 32 sectors/track, 1938 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Disk identifier: 0x78558c9d
    Device Boot      Start         End      Blocks   Id  System
/dev/sdb1             257        1938     1722368    6  FAT16
/dev/sdb4   *           1         256      262128    6  FAT16
Partition table entries are not in disk order
-- 


 Allora: se per caso ti va di installarci Puppy laciandola così com'è, cioè
Ma il comando sopra va lanciato dal SO installato sulla chiavetta
o non importa?
Va bè spero sia possibile installare frugalmente anche slax, nel
caso, ti faccio sapere.

 e si incarta.
Ho una chiavetta simile anch'io che usa quel formato superfloppy e viene letta
1 volta si e 10 no, debbo pistolarci un po' poi sembra fungere.
Da me viene vista come /dev/sde (perche' ho gia' 4 posti occupati).
Ci ho dato una scorciatina con il disk editor "lde", ed effettivamente il primo
blocco assomigia in tutto al classico primo blocco di un floppy, solo che nel
mio caso, viene definito come sistema MSDOS 5.0 e come formato FAT32.
For my real address use the X-SPAM header
-- 
+---------------------------------------------------------------------------+
|Il Pascal è un linguaggio giocattolo fatto per insegnare la programmazione |
|ai matematici.                                                             |
+-----#20--------------------Campagna contro le pubblicita` idiote.---------+

JohnnyNewbie wrote:

Hai ragione a chiedermelo, sono io che ho fatto confusione.
Qui mi spiego (da visualizzare con un font a spazio fisso).
La copia del boot sector viene fatta comunque, anche se questo non contiene
alcun loader e alcuna tabella delle partizioni, cioè: _al_ _momento_
_della_ _formattazione_ _FAT32_ la procedura copia automaticamente i primi
512 byte del device e li colloca nel 6_to settore.
Ciò _a_ _prescindere_ dal fatto che il boot sector contenga qualcosa e _a_
_prescindere_ dal fatto che il file system sia all'interno di una
partizione.
Se il file system non si trova all'interno di una partizione, invece di
iniziare dopo i primi 512 byte inizia dopo i primi 446 byte, cioè dopo lo
spazio che dev'essere riservato a un eventuale loader.
Di conseguenza si ha la seguente situazione:
|         primi 512 byte      |
|_____________________________|
|_____________________|_______|______________ .... |______________| ...
  primi 446 byte       66 byte                      6_to settore
                       |                             contenente copia
                       |                            dei primi 512 byte
                      \/
                      qui iniziano le strutture dati del file system
Per spiegare il motivo del messaggio che mi restituisce dosfsck, la mia
ipotesi è la seguente.
Al modificarsi del contenuto del device (aggiuta, modifica e cancellazione
di file) si modifica ovviamente il contenuto delle strutture dati del file
system, cioè cambia il contenuto dei 66 byte che precedono la fine dei
primi 512 byte.
Di conseguenza, un programma che, come fa dosfsck, controlla la
corrispondenza fra il contenuto del 6_to settore e il contenuto dei primi
512 byte, rileverà che esiste una differenza.

 partizionamento.
E' la soluzione più pratica perché consta di 4 file che puoi mettere dove
vuoi in un file system, a patto che non li metti all'interno di una
subdirectory: il file system può trovarsi in una partizione già esistente,
_ma_ _anche_ _non_ (caso appunto del device in formato super floppy) ; può
contenere altri dati (per esempio Windows installato in FAT32), così come
non contenerli.

 Ecco l'output:
L'output che mi hai fornito a seguito del check del file system [*] mi pare
idoneo a _non_ _convalidare_ la mia ipotesi.
A questo punto, chiederei a un esperto come roberto, lumi in merito alla
procedura di backup automatico del boot sector (e di conseguente
allocazione del backup del 6_to settore) che viene fatto da una
formattazione FAT32 (vedi mio precedente messaggio di oggi).
[*]
Come ho appena scritto nel precedente messaggio, per verificare la mia
ipotesi non occorre che il boot sector contenga un loader, perché la
procedura di formattazione ha fatto comunque copia del primi 512 byte della
chiavetta e l'ha memorizzata all'interno del 6_to settore.

 partizione attiva.
Aiutami a capire:
- il fatto di numerarla come 4 serve soltanto a non averla fra i piedi
quando non si fa il boot, o c'è un altro motivo?
- quando parli di 99.99% dei PC intendi dire quelli che hanno un bios che
può fare il boot da un USB device partizionato?
Perché se è così, secondo me la percentuale è attualmente inferiore: io
posseggo un notebook Asus della serie M3, acquistato nel marzo de 2004, che
ha appunto un Bios che si rifiuta di fare il boot da device USB che _non_
_siano_ _in_ _formato_ _super_ _floppy_ .
Ovviamente i device USB partizionati li vede benissimo, ma possono essere
usati solo per storage, perché se voglio usarli come device di boot devono
essere privi di partizioni.
Preciso, però, che _non_ _ho_ _mai_ _fatto_ _un_ _aggiornamento_ _del_
_Bios_ e può darsi che facendolo il mio notebook rientri in quel 99.99% che
accetta il boot da un device partizionato.

 e si incarta.
Un attimo solo: il primo settore del device (ossia l'MBR) contiene quindi
quello che se ci fossero state partizioni sarebbe stato il boot sector
della partizione contenente il file system (ovvero il 63_esimo settore del
device)... giusto?
Inoltre, mi resta ancora un dubbio riguardo proprio al boot sector di una
partizione: il file system inizia comunque subito dopo lo _spazio_
_riservato_ _all'eventuale_ _loader_ _interno_ _alla_ _partizione_, cioè
dopo 446 byte dall'inizio della partizione, oppure inizia comunque dopo 512
byte? Mi pare corretto dire che il file syste (la strutture dati del file
system) inizia dopo i primi 446 byte come nello schema seguente:
Device _privo_ _di_ _partizioni_ :
| primi 512 byte del device   |
|_____________________________|
|_____________________|_______|______________ .... |______________| ...
  primi 446 byte       66 byte                      6_to settore
                       |                             contenente copia
                       |                            dei primi 512 byte
                      \/
                      qui iniziano le strutture dati del file system
Device _con_ _partizioni_ :
| primi 512 byte del device   |boot sector della partizione
|_____________________________|____________________________|
|_____________________|_______|____________________|_______| ...
  primi 446 byte       66 byte  primi 446 byte      66 byte
                       |                           |
                       |                           \/
                      \/                  qui iniziano le strutture
                 qui inizia la               dati del file system
             tavola delle partizioni
E' corretto?

 
Direi che (non ho nessuna voglia di andare a spulciare qualche sorgente)
la logica dice che sfruttare quei 66 byte ha un rapporto costi/benefici
piuttosto altino, e si parte dal primo settore successivo.
Oltretutto, nelle partizioni logiche c'è un intero settore buttato via,
un MBR vuoto, e ciò fortifica la mia convinzione.


 essere privi di partizioni.
Per la scienza: Prova a scaricarti trk
http://trinityhome.org/Home/index.php?wpid=1&front_id=12
brucia un cd, fai il boot, riversalo su chiavetta (lo mette nella quarta
partizione, e poi tenta un boot da lì.
Potresti avere delle sorprese. (oppure no, ma ci hai rimesso un CD e un
pochino di tempo).


 formattazione FAT32 (vedi mio precedente messaggio di oggi).
Microsoft la spiega così:
http://support.microsoft.com/kb/247575
E parla sempre di fat32, e di settore intero.
Il fatto che preveda come disaster recovery la riscrittura del sesto
(che poi è il settimo: 0,1,2,3,4,5,6) settore sul settore zero, porta
come conseguenza che sia un settore _statico_, creato alla
formattazione, e di sicuro non contenente dati variabili come i primi
byte della struttura di un file system.


 byte della struttura di un file system.
Ah benissimo: ok, grazie.
Non è il sesto settore, ma il settore numero 6 (quindi come hai precisato tu
il settimo della partizione).
Quindi, quando il filesystem FAT32 si trova nella prima partizione, la copia
del settore di boot si trova nel settore numero 6 della partizione, che
corrisponde al numero 68 dall'inizio del disco:
|___________| ... qui altri ... |___________|___________| ... |___
                   62 settori
  settore 0                      settore 63   settore 64      settore 68
    MBR                          (64_esimo)   (65_esimo)      (69_esimo)
                                 Boot sector  Inizio del      Contiene il
                                 della parti  file system     backup del
                                 zione                        boot sector
                                 settore 0    settore 1       settore 6
                                 della parti  della parti     della parti
                                 zione        zione           zione
                                 1_mo setto   2_do set        7_mo settore
                                 re della par tore della      della parti
                                 tizione      partizione      zione
|_______________________________|______________________________ ...  
        traccia 0                  traccia 1
        63 settori
         in tutto                 

 un MBR vuoto, e ciò fortifica la mia convinzione.
Dunque, funziona come segue.
Quando ci sono partizioni il file system inizia al 65_esimo settore (il
settore numero 64), mentre il 64_simo (il settore numero 63, ovvero quello
di inizio della partizione) è quello che può contenere un loader.
Se nel settore di inizio della partizione (settore numero 63) viene messo un
loader (o vengono messi un gestore di boot + un loader), questo avrà
ovviamente a sua disposizione lo stesso spazio che avrebbe avuto se si
fosse trovato nel settore 0 del device (cioè se fosse stato installato
nell'MBR), cioè gli sono riservati 446 byte.
Con buona pace di quei 66 byte precedono la fine del settore e che nel
settore 0 del disco sono riservati alla tavola delle partizioni, mentre nel
settore 64 (ovvero il 65_simo) restano inutilizzati.
Quindi, mi correggo riguado al punto del precedente mio messaggio dove,
riferendomi al boot sector interno a una partizione, ho detto che...
"Mi pare corretto dire che il file syste (la strutture dati del file
system) inizia dopo i primi 446 byte".
L'inizio del file system "funziona" diversamente a seconda che il device
contenga, o meno, partizioni.
Direi che, a questo punto, gli schemi corretti sono i seguenti:
Device privo di partizioni :
-----------------------------
| primi 512 byte del device   |
|_____________________________|
|_____________________|_______|______________ .... |______________| ...
  primi 446 byte       66 byte                      7_mo settore del
                       |                            file system:
                       |                            contenente copia
                       |                            dei primi 512 byte
                      \/
                      qui iniziano le strutture dati del file system
Device con partizioni :
-----------------------
| settore 0, ovvero MBR             |settore 63, ovvero:         |settore 64
| (primi 512 byte del device) |     |boot sector della partizione|
|_____________________________|     |____________________________|
|_____________________|_______| ... |____________________|_______|__________
  primi 446 byte       66 byte      primi 446 byte        66 byte  |
                       |                                   |       |
                       |                                   \/      \/
                      \/                           questi restano  qui
                 qui inizia la                     inutilizzati    inizia
             tavola delle partizioni                               il
                                                                  filesystem

 contenga, o meno, partizioni.
... e questo spiegherebbe il motivo della risposta che JonnyNewbie riceve
facendo "fdisk -l" su una chiavetta non partizionata:
quando non ci sono partizioni il file system inizia subito dopo i 446 byte
riservati al loader, cioè inizia dove fdisk si aspetta invece di trovare la
tavola delle partizioni e quindi fdisk legge dei dati appartenenti al file
system invece che dei dati appartenenti alla tavola delle partizioni.
Però... e qui mi rivolgo a roberto: non potrebbe darsi che invece il file
system inizi SEMPRE dopo il primo settore, cioè dopo i primi 512 byte, come
sarebbe se ci fossero partizioni?
Mi pare che la risposta sballata di fdisk si potrebbe giustificare
ugualmente, perché fdisk leggendo gli ultimi 66 byte del primo settore NON
troverebbe ugualmente delle informazioni sulle partizioni (e quindi
interpreterebbe ciò che trova con risultati altrettanto allucinati).
Cioè, roberto, ripeto: sei proprio sicuro che il file system non inizi
comunque dopo i primi 512 byte anche quando non ci sono partizioni?
Se così fosse, il "funzionamento" dell'inizio del file system sarebbe più
coerente: a prescindere dal fatto che il disco abbia partizioni o non ne
abbia, il file system inizierebbe sempre subito dopo il primo settore
(dellla partizione o del disco, a seconda dei casi).

 byte della struttura di un file system.
E siccome i primi byte della struttura del file system sono --appunto--
variabili, io avevo fatto l'ipotesi che in presenza di un file system che
inizia PRIMA di dove dosfsck si aspetterebbe, dosfsck restituisca un
messaggio di non corrispondenza fra il boot sector e il settore numero 6
del file system: al termine della formattazione, la procedura farebbe copia
del settore 0 (ovvero i primi 512 byte) nel proprio settore 6.
In questo caso, in cui il file system inizia subito dopo i 446 byte del
loader (invece di iniziare DOPO il settore 0), la copia del settore 0
conterrebbe anche dati che appartengono al file system e questi sarebbero
dati variabili (provocando il messaggio di dosfck).
E allora perché, INVECE, a JonnyNewbie dosfsck NON ha rilevato alcuna
incoerenza fra boot sector e copia di backup ?
Non sarà, allora, che, anche quando non ci sono partizioni, il filesystem
inizia comunque sempre DOPO il settore 0 ? (vedi mi precedente messaggio di
oggi in cui avanzo questo dubbio).

 sarebbe se ci fossero partizioni?
Guarda che è quello che io sostengo da sempre. ;-)
Non avrebbe senso il contrario.
Solo complicazioni, e tutto per guadagnare una manciata di byte.


Propongo due schemi di struttura.
Ditemi, per favore, se secondo voi sono corretti.
Chiavetta (o disco) con partizioni
----------------------------------
|___|___| ... ... ... |___|___|___|___|___|___|___|
  0   1 settori         0   1   2   3   4   5   6
        inutiliz       /|\                      |
        zati            |                      \|/
                        |                      settore
                        |                      col backup
                        |                      del boot
                        |----------------------sector
                       n.63 del disco
                       inizio traccia 1
                       inizio prima partizione
                       boot sector della partizione
Chiavetta (o disco) senza partizioni
------------------------------------
|___|___|___|___|___|___|___|
  0   1   2   3   4   5   6
/|\/|\                    |
 |  |                    \|/
 |  |                     settore
 |  |                     col backup
 |  inizio del            del boot
 |  file system           sector
 |                        |
 |------------------------|
Domando:
--------
==> siamo sicuri che il file system non inizi anche quando NON ci sono
partizioni sempre nel settore numero 63 ?
(i settori della traccia 0 vengono tradizionalmente considerati come non
affidabili)
(il settore n.63, in tal caso, invece di essere il boot sector di una
partizione conterrebbe l'inizio del file system)
==> In altre parole: siamo sicuri che quando NON ci sono partizioni l'inizio
del file system si collochi subito dopo il settore 0 della traccia 0 e non
nel settore 0 della traccia 1 ?
(in modo da lasciare intonsi i primi 63 settori)

 Solo complicazioni, e tutto per guadagnare una manciata di byte.
Ah... ma allora resettiamo il thread, nel senso che:
sia quando il disco ha partizioni, sia quando non ne ha, il file system
inizia sempre nel secondo settore (della partizione o del disco o), ovvero
nel settore numero 1 del disco o nel settore numero 64 della partizione.
((( parentesi
ma scusa... parlando del disco di JohnnyNewbie, quello senza partizioni, non
avevi detto che...
    "Significa che negli ultimi 66 byte del primo settore della partizione 
    ( del device, in questo caso) non c'e' la tavola delle partizioni, ma
    il primo settore effettivo del file system.
    Fdsik cerca di interpretare quei dati come una partition table, e non
    ci capisce una beata mazza."
?
Se ho compreso bene le conclusioni di questo dialogo, in quei 66 byte non
c'è la tavola delle partizioni --ok-- ma non c'è neppure l'inizio del file
system, come invece mi pare dica tu.
fine parentesi )))
Quindi, quando non ci sono partizioni il file system inizia all'interno
della traccia 0, cioè non vengono lasciati liberi i settori che vanno dal
settore 0 alla fine della traccia come avviene quando ci sono partizioni ?
Vedi, se puoi, il messaggio seguente.

     ci capisce una beata mazza."
Eh, hai ragione.
Pensavo alla partizione, e ho detto file system. Mea culpa.


 
Diamine roberto :-) : dicendo così è facile fare confusione.
Controlla, se puoi, se ti tornano le seguenti affermazioni :-/
1)
Negli ultimi 66 byte del primo settore del disco c'è la tabella delle
partizioni, altrimenti, se il disco non ha partizioni, non c'è niente
perché il file system inizia comunque dopo i primi 512 byte (cioè nel
secondo settore, cioè nel settore 1 del disco: vedi punto 4) ).
2)
Negli ultimi 66 byte del primo settore della partizione (il settore 0 della
partizione, ovvero il boot sector della partizione) non c'è niente, perché
il loader termina entro i primi 446 byte e il file system inizia dopo i
primi 512 byte (cioè nel secondo settore, cioè nel settore 1 della
partizione).
3)
Quando ci sono partizioni, il primo settore della partizione (il settore 0
della partizione, ovvero il boot sector della partizione), inizia con la
seconda traccia del disco (la traccia 1 del disco), cioè inizia al settore
numero 63.
4)
Quando non ci sono partizioni il primo settore della partizione inizia,
invece, già all'interno della prima traccia del disco, perché inizia subito
dopo il primo settore (quello che contiene l'MBR).
(penso sia così perché il fatto che il file system sia situato 63 settori
dopo l'inizio mi pare uno spreco eccessivo e probabilmente inutile:
pensiamo ai floppy disk)

 
Diamine roberto :-) : dicendo così è facile fare confusione.
Controlla, se puoi, se ti tornano le seguenti affermazioni :-/
1)
Negli ultimi 66 byte del primo settore del disco c'è la tabella delle
partizioni, altrimenti, se il disco non ha partizioni, non c'è niente
perché il file system inizia comunque dopo i primi 512 byte (cioè nel
secondo settore, cioè nel settore 1 del disco: vedi punto 4) ).
2)
Negli ultimi 66 byte del primo settore della partizione (il settore 0 della
partizione, ovvero il boot sector della partizione) non c'è niente, perché
il loader termina entro i primi 446 byte e il file system inizia dopo i
primi 512 byte (cioè nel secondo settore, cioè nel settore 1 della
partizione).
3)
Quando ci sono partizioni, il primo settore della prima partizione (il
settore 0 della partizione, ovvero il boot sector della partizione), inizia
con la seconda traccia del disco (la traccia 1 del disco), cioè inizia al
settore numero 63. Il file system inizia poi al settore numero 64.
4)
Quando non ci sono partizioni il primo settore del file system inizia,
invece, già all'interno della prima traccia del disco, perché inizia subito
dopo il primo settore (cioè subito dopo quello che contiene l'MBR).


Risposte solo nel Newsgroup -- grazie wrote:
Diavolo... sto facendo confusione anch'io...
Ho corretto (supersede) i punti 3) e 4) 
3)
Quando ci sono partizioni, il primo settore della _prima_ partizione (il
settore 0 della partizione, ovvero il boot sector della partizione), inizia
con la seconda traccia del disco (la traccia 1 del disco), cioè inizia al
settore numero 63. _Il_ _file_ _system_ _inizia_ _poi_ _al_ _settore_
_numero_ _64_ .
4)
Quando non ci sono partizioni il primo settore _del_ _file_ _system_ inizia,
invece, già all'interno della prima traccia del disco, perché inizia
subito dopo il primo settore ( _cioè_ _subito_ _dopo_ quello che contiene
