Newsgroup: it.comp.os.linux.iniziare
Titolo: Simulare operazioni su HD

Vorrei fare una prova su un file immagine vuoto creatto con dd:
0) dd if=/dev/zero of=disk bs=1K count=1K
1) crearvi una partizione
1.1) formattarla
2) montarla e scriverci qualche dato
3) restringre il filesystem
4) restirngere la partizione
5) riallargare il filesystem fino riempire totalmente la
   partizione ristretta
6) creare seconda partizione
7) formattarla
8) copiare dati dall'una all'altra verificando che il filesystem
   ristretto contenga ancora i dati scritti.
Problema, non so come fare il punto 2:
la partizione si chiamer� disk1, ma non so dove andarla a pescare
in quanto non � ovviamente presente tra i devices...non si tratta
di un disco vero ma di un file vuoto da 100 MB.
Avete idee?

JohnnyNewbie wrote:

# dd if=/dev/zero of=disk1 bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.301057 s, 348 MB/s
# mke2fs -j disk1
mke2fs 1.41.9 (22-Aug-2009)
disk1 is not a block special device.
Proceed anyway? (y,n) y
...
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
# mount -o loop -t ext3 disk1 /mnt/temp
# ls /mnt/temp
lost+found
Pero' se vuoi simulare un vero hard disk, con partizioni e tutto, non e' 
cosi' semplice.
-- 
Cio' che si vede, e'.

usare una macchina virtuale, cosi` non puoi far danni!
Ciao
	Ste

 # dd if=/dev/zero of=disk1 bs=1M count=100
No, intendevo che la partizione si chiamer� disk1 perch� il file
immagine del disco l'ho chiamato "disk" vedi sopra.
Quando lo dai in pasto a fdisk questo crea la tabella delle
partizioni nominandole cos�. Analogamente se partizioni il disco
/dev/sda le partizioni saranno /dev/sda1... /dev/sda"N".
Col tuo procedimento posso unicamente creare un file formattato,
non un disco simulato.

 usare una macchina virtuale, cosi` non puoi far danni!
S�, volevo evitarla per�.
Ho chiesto proprio per vedere se c'era qualche sistema pi�
semplice da fare al volo senza mettere in piedi un sistema da
usare in virtuale. Dovrei anche installare qualcosa qemu o
virtualbox...
Insomma cercherei prima una soluzione diversa, pi� terra terra.
Il punto � che se si tratta di un device vero, linux popola la
dir dev con i file speciali associati alle partizioni, per cui
per esempio se creo con fdisk la partizione 1 sul disco /dev/sda,
ecco che linux crea /dev/sda1 appena scrivo la tabella delle
partizioni con fdisk.
Invece quando lavoro sul file tutto ci� non avviene...
cio� chiama la partizione creata "disk1", ma poi non so dove
andarla a pescare...
Dovrei forse crearmi dei dispositivi a mano con mknod o come si
chiamava?
Mah...
Forse hai ragione tu e servirebbe per forza la macchina virtuale.
Tuttavia, lascio aperto il discorso nel caso vi siano idee in
merito... Alla fine posso anche rinunciare, nulla di importantoe
solo una mia curiosit� didattica.
Saluti  :-)

 andarla a pescare...
Quando la mounti con mount -o loop, come nel mio esempio nell'altro post, il 
device viene creato e si trova in /dev/loopX (prende il primo libero). Se 
vuoi essere sicuro, puoi dirgli di usarne uno specifico, ad esempio 
mount -o loop=/dev/loop4 etc.etc.
Ma e' sempre una "partizione"; come dicevo, un intero hard disk simulato in 
quel modo e' complesso, soprattutto per quello che vuoi fare tu (resize).
Molto piu' semplice e veloce installare virtualbox o equivalente.


 quel modo e' complesso, soprattutto per quello che vuoi fare tu (resize).
� complesso o non si pu� proprio fare se non passando per una
macchina virtuale?

 1.1) formattarla
]zac[
Probabilmente il comando che ti serve � ' losetup '.
Con man losetup ti puoi fare una idea del comando, una ricerca con google 
dovrebbe portarti pi� o meno facilmente a un qualche how-to almeno vicino a 
quello che ti server.

 quello che ti server.
http://www.omninerd.com/articles/Installing_GRUB_on_a_Hard_Disk_Image_File
http://web2.clarkson.edu/projects/itl/honeypot/ddtutorial.txt
Passando da l� sono riuscito a formattare la partizione virtuale
del disco virtuale.
serve un loop device per il disco intero, poi si usa fdisk su
quel loop device per partizionare.
A questo punto si aggancia un secondo loop device alla/e singola
partizione specificando il byte di inizio partiizone che si deve
calcolare a mano a partire dal'output di
fdisk -ul /loopdevicedellinterodisco
In ogni caso non entro nel dettaglio perch� � tutto speigato
passo passo nei links che ho trovato sopra.
Non ho ancora provato il resize della partizione.
Per� potrebbe essere un modo piuttosto terra terra per fare dei
piccoli test. Senza necessit� di macchine virtuali o altro.
Grazie Giuseppe dell'indicazione!  :-)

 piccoli test. Senza necessit� di macchine virtuali o altro.
Effettivamente funziona.
Peccato solo che se "stacco" l'immagine del disco e poi la
riattacco, sembra sparirmi tutto il lavoro fatto:
Ricapitolando:
- Creo un file vuoto che sar� la mia immagine del disco
# dd if=/dev/zero of=disk bs=512 count=100K
- Aggancio questo file vuoto da 50MB ad un loop device
# losetup -f disk
poniamo ch ein questo caso finisca in loop0.
- Creo una partizione unica ntfs e la aggancio in loop
# fdisk /dev/loop0
il primo settore � il 63 e il device ha settori da 512 byte
per cui la prima partizione inizia al byte 32256.
Questo numero serve per agganciare la partizione creata ad un
nuovo loop device dandolo in pasto all'opzione "offset":
# losetup -o 32256 /dev/loop1 /dev/loop0
Con questo abbiamo agganciato il byte 32256 del loop0 (il disco)
al loop1 che sar� la nostra partizione.
- La formatto in ntfs, la monto e vi copio dentro qualcosa:
# mkfs.ntfs /dev/loop1
# mkdir mountpoint
# mount -t ntfs-3g /dev/loop1 mountpoint
# cp -a /archive/linux/doc.generic mountpoint
# umount mountpoint
- ok ora passo al resize.
# ntfsresize -i /dev/loop1
in pratica mi dice che posso liberare circa 25 MB cos� decido di
liberare 20 MB lasciandone 30 alla partizione ridimensionata.
# ntfsresize -n -s 30000000 /dev/loop1
Ok, cos� era simulato, pare tutto apposto cos� so il comando in
modo che odifichi realmente il filesystem:
# ntfsresize -s 30000000 /dev/loop1
# ntfsresize -i /dev/loop1
- resize della partizione: bisogna calcolare adesso un valore per
  il resize della partizione in modo che sia un po' pi� grande
  del filesystem ridimensionato. l'importate � che il settore
  iniziale sia il 63 come prima, osservando poi che un settore �
  da 512 byte, il settore finale l'ho calcolato cos�: 63+30000000/512
  Poi sono stato un po' largo magari aggiungendo un settore o due
  in pi�.
fdisk -u /dev/loop0
In questa operazione fdisk si lamenta che i settori finali non
coincidono col la fine di un cilindro. Ad ogni modo proseguo...
Creo una nuova partizione dopo quella ridimensionata e la
aggancio al prossimo loop device libero, specificando l'offset
come prima (settore di inizio partizione 2 * 512 byte):
losetup -o $start_byte /dev/loop2 /dev/loop0
- In ogni caso, alla fine ho provato a montare di nuovo la prima
  partizione /dev/loop1 e ho verificato che i dati erano presenti.
Operazione riuscita quindi?
Sembra di si, almeno fino a questo punto.
Ma se poi sganciassi e riagganciassi i vari loop devices?
# losetup -d /dev/loop2
# losetup -d /dev/loop1
# losetup -d /dev/loop0
poi riaggancio
# losetup -f disk
Ecco, ora controllando con fdiskecco cosa ottengo:
--------------------------------------
Disk /dev/loop0: 52 MB, 52428800 bytes
255 heads, 63 sectors/track, 6 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/loop0 doesn't contain a valid partition table
-------------------------------------------------------
Come se il file nno fosse stato partizionato.
Dove potrebbe stare il problema?
� normale tutto ci�?
Cos eventualmente si potrebbe fare per salvare in qualche modo il
file proprio come una immagine di un disco, senza predere tutto
al rilascio dei vari loop devices?

Tutto molto interessante.
Sei riuscito a fare quasi tutto senza usare una macchina virtuale.
Tieni conto pero` che:
.) l'installazione di un software di virtualizzazione ormai necessita solo di 
pochi minuti di lavoro
.) tu hai creato il secondo loop, quello per la partizione, specificando a mano 
la posizione all'interno del file rappresentante l'intero disco
(losetup -o 32256 /dev/loop1 /dev/loop0),
quindi senza basarsi automaticamente sulla tabella delle partizioni, il che 
cambia totalmente le cose rispetto ad una situazione reale;
.) senza macchina virtuale non potrai mai provare a giocare con le partizioni 
con i vari tool che ci sono a disposizione, gratuiti o a pagamento (tipo 
partition magic e similari).
Io continuo a consigliare una macchina virtuale, oltretutto ci avresti messo meno!
Ma non voglio togliere che la tua esperienza e` stata comunque interessante, 
grazie di aver postato tutto quello che hai fatto in dettaglio, e` comunque utile.
Ciao
	Stefano

 [...]
Vorrei chiedervi qualche parere circa un esempio:
mettiamo di voler creare un immagine di un disco da zero e larga
50 MB.
# dd if=/dev/zero of=disk bs=512 count=100K
# losetup /dev/loop0 disk
Ora, provando a manipolare questa immagine con fdisk in modo da
creare partizioni ecc, ottengo qualcosa del genere:
# fdisk -l /dev/loop0
Disk /dev/loop0: 52 MB, 52428800 bytes
255 heads, 63 sectors/track, 6 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x7f89cf6d
Device Boot      Start         End      Blocks   Id System
#
Ora una domanda, forse banale, perch� fdisk in qualche modo
decide che ci devono essere 6 cilindri?
Da dove salta fuori questo numero?
Chiedo perch� se provo a lavorare in settori come unit� di misura
e faccio per esmpio 2 partizioni, l'ultimo settore della prima e
il primo della seconda vengono piazzati in mezzo ad un cilindro.
Questo fdisk lo fa notare.
Inoltre se poi stacco e riattacco il loop device e rid� fdisk,
ecco che i cilindri non sono pi� 6 ma molti di pi�...
Ora se si trattasse di un disco reale penso che il numero di
cilindri sarebbe un dato di costruzione. Ma in questo caso
partendo da un file vuoto, direi che � fdisk a decidere quali
valori impostare.
Con che criterio lo fa?
So che questi parametri in casi come questo posssono essere
modificati. Nel caso dei miei futili tests a scopo didattico ci
sono dei valori consigliabili ?
(magari un po' pi� comodi dei soli 6 cilindri...)
Grazie in anticipo.

 ci avresti messo meno!
Concordo, con una macchina virtuale si sarebbe potuto fare il
tutto in modo pi� "trasparente", rapido ecc.
Per�, come hai anche affermato tu, passando per la strada che ho
seguito ho forse potuto inciampare in problematiche e aspetti che
altrimenti non avrei mai considerato.

 Potresti spiegare meglio in che senso cambia?
Si`, mi sono spiegato male.
Quello che cambia e` che in una situazione reale la partizione viene trovata 
leggendo la Partition Table, mentre tu scrivi si` la Partition Table, ma poi 
trovi la partizione 'a mano' facendo il losetup con -o.
P.es.: magari un programma che vuoi testare (o tu stesso a mano) fa un errore 
nello scrivere la nuova Partition Table dopo un'operazione su una partizione.
In una situazione reale il Sistema Operativo fa il boot, legge la PT e punta ad 
un posto sbagliato. Nel tuo caso, tu fai il losetup al posto giusto, e non usi 
cio` che c'e` scritto nella PT.
Altro esempio: alcuni Sistemi Operativi (non mi ricordo piu` quali, credo 
qualche MS) non accettano che ci siano partizioni in ordine diverso rispetto ai 
blocchi a cui puntano.
Cioe`, una situazione del genere
Part.	Bl. in.	Bl. fin.
1	1	1024
2	2049	4096
3	1025	2048
potrebbe creare qualche problema a qualche SO, ma col tuo sistema non lo noteresti.
Linux non ha problemi di questo genere.
Ultimo esempio: alcune volte che ho pasticciato con le partizioni e con un SO 
MS, sono diventato matto a rimettere a posto il Master Boot Record. Con il tuo 
sistema manco lo vedi il MBR! Pero` per il boot e` necessarissimo!
Con Linux e` un po' piu` facile.
Ciao
	Stefano

 il losetup con -o.
Sì il punto sta proprio qui.
Però se poi si crea il disco con partizioni e relativi filesystem
coerenti con la tabella si dovrebbe ottenere un risultato analogo
e l'immagine ottenuta dovrebbe essere digerita regolarmente anche
da qualsiasi altro progamma tipo parted, partitio magic e via
dicendo...
losetup come evidenziavi ha un problemino:
l'opzione "-o" praticamente ci permette di agganciare al
loop device non tutto il file ma solo la parte del file oltre il
valore di byte specificato.
Qui sta l'inghippo, almeno così ho riscontrato.
La domanda critica è questa: quanto è estesa la partizione legata
a /dev/loop0 attraverso:
losetup -o $byte_inizio_partizione /dev/loop0 disk.img
???
Il punto è questo, e me ne sono reso conto facendo il resize
automatico del filesystem in modo da fargli raggiungere la fine
di una partizione precedentemente ridotta.
La conclusione a cui sono giunto è che il device /dev/loop0 col
semplice parametro offset si aggancia *solo* all'inizio della
partizione, ma poi come estensione arriva alla fine del file
immagine.
le operazioni che ho fatto sono queste:
0- creazione file immagine con dd
1- creazione partizione unica "linux" con fdisk
2- formattazione in ext3 della stessa con mkfs.ext3
In questo caso il problema non si pone perchè la partizione
arriva fino alla fine del file immagine.
3- copia di alcuni dati dentro la partizione
4- resize a circa metà del filesystem con resize2fs
5- resize della partizione con fdisk in modo da renderla appena
   più grande del filesystem ridotto al punto 5.
6- resize finale del filesystem allargandolo in modo che vada
   a riempire completamente la partizione con resize2fs
	Dal man resize2fs:
	If size parameter is not specified, it will default to the
	size  of the partition.
Il punto 6 sarebbe stato molto comodo per far aderire bene il
filesystem al bordo finale della partizione.
Ma come dicevi il nostro loopdevice non sembra essere coerente
con la partizione ridotta (a meno che non sia l'ultima), lui è
solamente coerente con l'inizio della partizione perchè glielo
diciamo noi specificando l'offset.
Per cui cosa succede al punto 6?
succede che qundo lancio il
resize2fs /dev/loop0
il filesystem ext3 si va a estendere fino alla fine del device
loop0 che non coincide con la partizione ridotta ma raggiunge la
fine del file immagine. Pertanto ottengo un filesystem che si
estende per tutto il file immagine escluso il primo cilindro che
era stato tagliato fuori dall'offset.
Quindi alla fine si ottiene una discrepanza tra tabella
partizioni e reale disposizione del filesystem nel disco.
Quello che manca a losetup è quindi un parametro in grado di
specificare non solo l'offset (quindi lo slittamento dall'inizio
del file immagine) ma anche un taglio finale specifiacto da noi.
Per la cronaca ho fatto un test reale su una scheda SD.
Ho fatto la stessa cosa di cui sopra, m non c'è ovviamente stato
bisogno di losetup.
Sono partito con una partizione unica in ext3.
Alla fine solo con fdisk mkfs.ext3, mkdosfs e resize2fs ho ottenuto
una prima partizione ridotta in ext3 con dati precedentemente
copiati integri e una seconda partizione fat.
Unica cosa è che il filesystem ridotto può essere accorciato dalla
fine, senza cambiarne l'inizio, almeno lavorando con questi soli
strumenti, o sbaglio?

 descritto.
Hai provato kpartx?
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Hai provato kpartx?
No, ma ne ho letto il man in rete, e penso che sia l'unica
soluzione per trattare le partizioni realmente come tali cioč
passando per la tabella presente nel MBR della nostra immagine
del disco.
Con quel tool si dovrebbe avere a disposizione la mappatura del
disco (inteso come immagine ovviamente). Quindi se il nostro
device l'abbiamo agganciato con losetup al /dev/loop0, ecco che
le partizioni create con fdisk saranno realmente accessibili come
normali devices reperibili in /dev/mapper, quindi avremo:
/dev/mapper/loop0p1
...
...
/dev/mapper/loop0pN
-------------------
Ok, quindi direi che con losetup non si puņ accedere realmente
alle partizioni, ma eventualmente puņ tornare utile per l'accesso
ai dati presenti nell'eventuale filesystem presente. Magari se la
tabella delle partizioni fosse corrotta o in altri casi del genere.
Nel thread si č cercato di simulare un'operazione di resizing di
filesystem al fine di riorganizzare per bene anche le partizioni
e senza perdere dati.
Volendo penso sia possibile ancora una volta bypassare la tabella
delle partizioni utilizzandola unicamente per reperirne le
informazioni circa la posizione delle varie partizioni e
utilizzandole per rielaborare manualmente l'intero disco magari
anche con il solo dd.
Si potrebbe per esempio creare un'immagine clone del nostro disco
(che magari potrebbe a sua volta essere anch'esso una immagine).
Rivederne e pianificarne il nuovo partizionamento e poi creare
dei file immagine dei vari filesystems presenti entro ciascuna
partizione pianificata.
Tali immagini si possono montare facilmente in loop e possiamo
anche usare losetup per montare le vecchie partizioni e copiarne
i dati.
Alla fine avremo un file immagine del disco che avremo
partizionato con fdisk e avremo le immagini dei filesystems
presenti in ciascuna partizione, che create precise in
modo che coincidano con i limiti delle varie partizioni.
A quel punto basta appiccicare con dd i vari filesystems al file
immagine del disco nei punti giusti. Il risultato dovrebbe essere
un disco immagine partizionato in modo coerente con la tabella
delle partizioni. E contenente ancora i dati precedentemente
presenti (ai quali potrebbe essere il caso di apportare qualche
modifica...penso a fstab o simili) tra l'altro la copia dei dati
in quel modo dovrebbe anche portarsi dietro la "deframmentazione"
degli stessi.
Chissą se funziona...

 Chissà se funziona...
Forse è perché non ho letto tutto, ma non mi è chiaro perché vuoi
metterti a lavorare con gli offset quando ci sono tool che ti danno
una mano a fare lo stesso lavoro.


 a fare lo stesso lavoro.
Principalmente a fini didattici, per capire cosa bolle in pentola
o il meccanismo sotto il cofano se preferisci...
Il punto però è anche avere a disposizione e sapere come
utilizzare le varie alternative. Un'alternativa è anche lavorare
a basso livello.
dd, fdisk, mkfs, losetup
Sono strumenti in grado di funzionare su qualsiasi macchina e
sono in dotazione di default in gran parte delle distribuzioni.
Ad esempio kpartx sicuramente è quello che mi serve, ma tanto per
dire non è presente tra i pacchetti di slackware. Niente
impedisce di compilarselo probabilmente senza troppe difficoltà
immagino.... ma potrebbe esserci il caso in cui sapere usare gli
strumenti più semplici potrebbe fare la differenza.

 strumenti più semplici potrebbe fare la differenza.
Il problema con le partizioni è che basta il minimo errore in un punto 
qualsiasi della catena di operazioni da fare è quasi certamente bisogna 
ricominciare tutto il lavoro da zero o dal primo backup disponibile.
Poi devi tenere conto che un file di loopback non è un device, per esempio 
non ha giometrie  del disco (quindi fdisk -u ), non ha tutti i meccanismi 
automatici di sgancio dei device dalle partizioni, rilettura della tabella 
partizioni, riaggancio delle nuova posizione delle partizioni con i device, 
ecc. .
Se si vuole sperimentare cosi a basso livello è caldamente consigliabile 
procurarsi un disco apposito (magari di piccole dimensioni, un disco 
dismesso), o crearsi due dischi virtuali con virtualbox, sul primo disco 
installare il sistema operativo, sul secondo fare gli esperimenti sulle 
partizioni.
Se si vuole prendere pratica di intervento di emergenza conviene piuttosto 
imparare a usare da riga di comando tool come gparted, testdisk, ecc. 
Le operazioni che stai facendo richiedono non tanto esperienza e conoscenza 
(non intendo dire che siano inutili), ma precisione, costanza, perseveranza, 
quasi assoluta, visto che ogni più piccolo errore è fatale.
P.S. Se ho letto bene, stai applicando il resize sui device legati alle 
partizioni, mentre, se ricordo bene, l'operazione corretta è sganciare i 
device legati alle partizioni, far agire i tools di gestione delle 
partizioni sul device legato all'intero ''disco'', poi rileggere i nuovi 
inizi delle partizioni e in base a quelli riagganciare i device alle 
partizioni.

 strumenti più semplici potrebbe fare la differenza.
Certo, e può essere utile sapere queste cose, ma resta il fatto che
è preferibile avere la propria distribuzione di rescue preferita a
portata di mano per fare queste cose.
E' improbabile trovarsi a dover lavorare a colpi di offset sul sistema
interessato, piuttosto starai facendo il boot da una live.
A questo punto meglio averne una con tutti i tool utili.
Per quanto riguarda le partizioni su un loop device (ma potresti
dover accedere ad un sistema che ha partizionato un volume lvm,
come un guest xen) l'offset è utile, ma non mi metterei comunque a
fare il resize o amenità del genere. Se proprio devi e non hai
kpartx a portata di mano, non dimenticare di passare a losetup la
dimensione massima della partizione, altrimenti credo te la consideri
fino a fine device.


 partizioni.
Potresti fare una lista dei comandi che daresti? non ho ben
capito...

 fine device.
È proprio quello il problema che ho riscontrato.
Quando faccio il resize per allargare il filesystem in modo che
raggiunga la fine della partizione, questo viene esteso alla fine
dell'intero device (cioè del disco). Ciò porta ad un risultato
non voluto qualora la partizione non sia l'ultima.
Come faccio a passare a losetup la dimensione massima della
partizione?
Dal man non ho visto un'opzione del genere...

 fino a fine device.
]zac[
Da quel poco che ho letto e provato mi risulta che basti il punto di inizio, 
sempre che il punto di inizio sia corretto, sempre che la partizione sia 
correttamente impostata, ecc. .
Però sono cose che non hanno a che fare con i loopback device, ma hanno a 
che fare con i problemi che causano le partizioni danneggiate.

 correttamente impostata, ecc. .
Hai letto nei miei post indietro:
1- creazione partizione unica
2- formattazione
3- riempimento per metà con dati
4- restringimento filesystem
5- restringimento partizione
6- creazione seconda partazione
4- riallargamento filesystem ristretto in modo che vada ad
   aderire al punto finale della prima partizione.
Risultato: il filesystem riallargato si è espanso fino alla fine
del device. In quel momento il device era agganciato come
"prima partizione" ovvero con losetup + offset impostato
all'inizio della primapartizione.
Per cui dalla mia prova l'offset non basta.
E mi sembra anche abbastanza razionale. Infatti la partizione da
quanto ho capito in queste prove, esiste solo nella tabella delle
partizioni. Con losetup invece si apiccica a mano il device loop0
(per es) ad un pezzo di immagine del disco, potendo solo decidere
di appiccicarvene un pezzo a partire dal byte numero tot.
Ma quel loop0 poi arriva comunque alla fine del file immagine...
E il risultato della mia prova sintetizzata sopra sembra
dimostrarlo.

 le partizioni presenti nell'immagine di un disco.
]zac[
Per quanto riguarda il ridimensionamento del filesystem non ho le conoscenze 
minime per fare affermazioni, ma suppongo che i tools non si basino sulla 
singola partizione ma su tutta l'unità per decidere come agire.

 Dal man non ho visto un'opzione del genere...
 --sizelimit limit
              the data end is set to no more than sizelimit bytes after the 
data start

 capito...
Se avessi dei comandi li avresti già avuti (nel 99% dei se rimango sul 
generico è perché non ho informazioni testate o abbastanza conosciute).
Comunque il punto è, credo, che se si modificano le partizioni bisogna 
ricominciare da zero l'aggancio dei loopback device, come se fosse la prima 
volta, evitando tassativamente di usare i vecchi punti di inizio.
P.S. Anche se superassi questo scoglio poi potresti imbatterti in problemi 
di boot (tipicamente delle partizioni NTFS, e anche li c'è da farsi male).
PP.SS. Comunque ribadisco il consiglio di parted, un disco aggiuntivo o un 
paio di dischi virtuali di virtualbox.

 quanto ho capito in queste prove, esiste solo nella tabella delle
]zac[
No perché, da quel mi risulta, questo problema lo hai solo in fase di resize 
del filesystem, mentre se usi le partizioni cosi come sono state create non 
ci sono problemi.
Quindi i casi sono due, o si hanno sempre problemi quando č presente piů di 
una partizione, o c'č qualcosa che il problema lo crea in fase di resize (č 
pura logica).

 Dal man non ho visto un'opzione del genere...
Io lě l'ho trovata, ma non l'ho mai usata.


 partizione sia correttamente impostata, ecc. .
Per accedervi, sicuramente, è il filesystem a sapere dove sono i dati.
Ma se fai il resize (non l'ho mai fatto né mi sono documentato al
riguardo, quindi possibili errori in arrivo) devi anche limitare la
dimensione del device oppure limitare il resize, altrimenti il filesystem
occupa tutto lo spazio disponibile.
E' il comportamento che mi aspetterei.


 Io lě l'ho trovata, ma non l'ho mai usata.
Forse allora stiamo parlando di due versioni di losetup
differenti, infatti:
man losetup
/size
Pattern not found (press RETURN)
Inoltre:
$ losetup -v --help
Usage:
 losetup loop_device                                  # give info
 losetup -a | --all                                   # list all used
 losetup -d | --detach loop_device                    # delete
 losetup -f | --find                                  # find unused
 losetup [ options ] {-f|--find|loop_device} file     # setup
Options:
 -e | --encryption <type> enable data encryption with specified <name/num>
 -h | --help              this help
 -o | --offset <num>      start at offset <num> into file
 -p | --pass-fd <num>     read passphrase from file descriptor <num>
 -r | --read-only         setup read-only loop device
 -s | --show              print device name (with -f <file>)
 -v | --verbose           verbose mode
--------------------------------------------------------------------------
Va bč. Mi documenterň, in ogni caso la versione che ho adesso:
/var/log/packages/util-linux-ng-2.14.1-i486-1
In ogni caso, grazie mille per tutte le risposte. :-)

 /var/log/packages/util-linux-ng-2.14.1-i486-1
Io invece uso util-linux-2.16-4.5.1.x86_64
Che distribuzione stai usando?


 Che distribuzione stai usando?
Slackware-12.1
Ho dato un'occhiata a questo sito che riporta varie pagine man di
diverse distribuzioni:
http://man.sourcentral.org/slack122/8+losetup
A quanto pare nella versione 12.2 quel pacchetto è stato
compilato con più funzionalità...
Anzi no...
Probabilmente ho qualche problemino con le versioni del software
installato, mi risulta installata la versione 2.14, mentre sulla
mia slackware dovrei avere la 2.13, tuttavia il manuale è quello
vecchio... strano. E non pare neanche che si tratti di una patch.
Infatti
slackpkg upgrade-all
mi segnala che ho il pacchetto sbagliato, 2.14, mentre dovrei
avere il util-linux 2.13.
In ogni caso mi pare che non vi fossero differenze tra le
librerie utilizzate per la compilazione tra slack-12.1 e 12.2,
pertanto tutto sembra funzionare senza problemi... manuale a
parte.
Va bè alla fine ho messo quello giusto "2.13" poi l'ho upgradato
a quello per la versione per slack-12.2 funzionare, non è un
operazione da fare in generale, ma in questo caso per questo
software e per la somiglianza tra le due versioni di slackware
sembra funzionare.
Ora ho il manuale nuovo, con anche l'opzione --sizelimit.