Newsgroup: it.comp.retrocomputing
Titolo: Tapes ! Help !

Ho iniziato l'allenamento in vista della "Missione Apollo" :)
Mi sono munito di lettore esterno IBM 7202-001 (Tanderberg TDC 3600) e 
nastri QIC-150.
Qualche domanda per gli esperti :)
1) Ogni volta che inserisco un nastro, l'unità lo manda avanti e dietro 
un paio di volte. È un comportamento normale ? Serve per ritensionarlo ?
2) Il formato di uscita di tapedump, è ascii, a quanto sembra. Non è, 
allora, direttamente scrivibile su nastro.
3) ho provato a scrivere sul nastro.
sudo tapecopy domainos-sr10.3-1of9.tap  /dev/st0
file 0 record length 8192: 1 record (0)
end of file 0, 8192 bytes
?Failed writing tape mark: Input/output error
dmesg
=====
st0: Sense Key : Illegal Request [current] 
st0: Add. Sense: Access denied - no access rights
st0: Sense Key : Illegal Request [current] 
st0: Add. Sense: Access denied - no access rights
st0: Sense Key : Medium Error [current] 
Info fld=0x0
st0: ASC=0x11 ASCQ=0x20
Tre nastri mi danno questo risultato.
Il quarto sembrava scriversi quando 
supervinx@supervinx:~/Apollo/Tapes/t$ sudo tapecopy -v domainos-
sr10.3-1of9.tap  /dev/st0
file 0 record length 8192: 1 record (0)
end of file 0, 8192 bytes
file 1 record length 2560: 1 record (0)
end of file 1, 2560 bytes
file 2 record length 32768: ?65535 byte tape record too long for 32768 
byte buffer
Dov'è che sbaglio ?
La prima esperienza è alquanto disastrosa :P


e in generale cambia drive, cambia scsi, cambia _sistema_, finche non 
trovi la combinazione giusta.
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
www.unsupported.info
 - 
img.unixantichrist.net

 trovi la combinazione giusta.
Ipotizzo anche qualche problema con la scheda SCSI (la solita Adaptec 2 
2940 UW). Quando collego il cavo esterno, "sparisce" la scheda audio :(
Altri dispositivi, però, quali HD e lettori CD esterni funzionano 
tranquillamente.
Non è, però, che nastri e lettori abbondino ...

 Non è, però, che nastri e lettori abbondino ...
Direi che hai problemi piu' grossi da risolvere (vedi sopra) :)


Le notizie sono buone :)
Tar funzione bene in entrambi i sensi.
Ho archiviato e ripristinato un paio di cartelle (è vero, è 
lentissimo ...) senza errori di sorta.
Dopodiché, ho provato a scrivere la prima immagine di DomainOS con dd, 
senza tapecopy.
È un bel po' che gira, senza segnalare errori ...
mt -f /dev/st0 rewind; dd if=domainos-sr10.3-1of9.tap of=/dev/st0
Riepilogando ...
1) Posso scrivere le immagini
2) Non so se riesco a creare l'immagine di un nastro.
Il punto 2), allo stato attuale, non è urgente. 
Mi interessa ricreare i nastri per l'Apollo :) e per un paio di sistemi 
AIX.
A proposito: ho tre QIC (almeno come formato esterno) diversi: da 525, da 
1GB da 8GB (SLR5). Che lettore serve ?

C'è stato un errore, nella scrittura con dd, ma non sembra hardware
dd: scrittura di "/dev/st0": Argomento non valido
98932+1 record dentro
98932+0 record fuori
50653184 byte (51 MB) copiati, 649,134 s, 78,0 kB/s
50653336 2011-03-19 12:40 domainos-sr10.3-1of9.tap
Non ha scritto gli ultimi 152 bytes
dmesg:
=====
st0: Write not multiple of tape block size.
Sembra connesso con la dimensione dell'immagine.
È un errore grave ?

 ha scritto nel messaggio 
news:Fu1hp.9490$%g.1...@twister1.libero.it...


Riepiloghiamo.
Con dd riesco a scrivere le immagini .tap di DomainOS.
Mi sono chiesto, però, se stia facendo la cosa giusta.
Ho provato a rileggere il tutto con tapecopy che, miracolosamente, 
funziona bene in lettura.
Confrontando i due files, essi differiscono.
Ma non sono errori di lettura.
Ogni 32768 bytes (dimensioni del record) tapecopy inserisce dei bytes. Se 
li elimino manualmente, le due immagini coincidono.
Abbiamo appurato, almeno, che dal punto di vista hardware funziona tutto.
Le immagini .tap di cui dispongo, non sembrano possedere headers, per cui 
credo di poterle scrivere correttamente con dd.
Ma, per converso, se creo un'immagine con tapecopy, dovrò riscriverla con 
tapecopy.
Dev'essere questo il motivo del fallimento della precedente scrittura.
tapecopy si aspetta gli extra bytes, che non trova.
Tant'è che, essendo un'unico records il file immagine di DomainOS, se lo 
rileggo con dd ottengo la stessa immagine di partenza.
L'unico ad aver problemi, qui, è tapecopy :P
Mi chiedo però, come fare a creare un'immagine se il nastro possiede più 
record (anche di differenti dimensioni).
Pensavo ad una cosa di questo genere, utilizzando il dispositivo non 
rewinding nst0
dd if=/dev/nst0 of=01.tap
dd if=/dev/nst0 of=02.tap
...
dd if=/dev/nst0 of=0n.tap
cat 01.tap 02.tap ... 0n.tap > image.tap
Fattibile o non ho capito nulla della struttura dei nastri ?

Trovato il mistero dei nastri che non si leggono e non si scrivono.
Due di essi recano l'etichetta 6150, ma è fasulla :)
Sul retro (parte metallica) è riportata la scritta 600A, mentre sugli 
altri c'è 6150.
Ergo, sono dei DC600A e non dei 6150.
Mi sono fidato dell'etichetta che qualcuno prima di me aveva attaccato 
(il venditore ebay dello stock ...)

 L'unico ad aver problemi, qui, è tapecopy :P
come dissi tapecopy e' molto schizzinoso ma fa' il suo lavoro, meglio di
dd, quindi ti consiglierei di insistere perche ti sara' necessario.


È rimasto un ultimo problemino.
dd non scrive gli ultimi bytes, lamentandosi che la dimensione del file 
non è un multiplo della dimensione del record del nastro.
1) Devo utilizzare dd con l'opzione bs=1 forzando ibs ed obs ad 1 byte ?
oppure
2) Aggiungo degli zeri in coda alle immagini da scrivere ?
Da un primo conteggio, se effettuo
filesize-int(filesize/512)*512 ottengo proprio i bytes che mancano 
all'appello.
Dev'essere che dd ha assunto implicitamente ibs=obs=512.

 saggia)
Ed allora ho bisogno di un chiarimento, perlomeno con la mia copia di 
tapeutils, che ho compilato localmente.
I dieci nastri .tap (che sono quelli tuoi, erano .gz)
domainos-sr10.3-1of9.tap
...
domainos-sr10.3-9of9.tap
li ho esaminati con un editor esadecimale.
Sono un continuum, non presentano headers o bytes extra.
Quando ho riletto l'immagine scritta con dd mediante tapecopy, ha 
aggiunto dei bytes ogni 32768, una specie di header, contente valori 0x0 
e 0x80 (se ben ricordo).
Eliminati quelli, le due immagini coincidevano.
Ho riprovato tapecopy, ma si lamenta non del nastro, ma della struttura 
dell'immagine.

 Eliminati quelli, le due immagini coincidevano.
Rileggere mediante tapecopy roba fatta da dd — o viceversa — non è mai cosa
buona e giusta. Tapecopy tiene conto di eventuali tape mark e cambiamenti di
struttura del nastro, dd no. Nel tuo caso credo che dd abbia creato dei
blocchi da 32768 byte (cioè probabilmente il massimo che riesce a gestire) e
quindi tapecopy rilevando questo fatto abbia inserito un gap nell'immagine
(IBG, Inter Block Gap) per poter poi riprodurre esattamente il nastro.
Se poi il nastro originale avesse avuto qualche tipo di labeling più o meno
standard, come succede ad esempio per i nastri di VMS e di vari sistemi
operativi IBM non di tipo Unix, magari OS/400 o MVS, allora con dd avresti
praticamente distrutto e/o perso informazioni fondamentali.
I dati su nastro non sono mai un vero e proprio continuum dall'inizio alla
fine: poco poco che ci sia, c'è un IBG ogni tanto, corrispondente alla
dimensione del buffer allocato dall'OS per la scrittura/lettura. Se poi l'OS
ha il concetto di record con tutto quel che ne deriva, allora la cosa si
complica a livelli più alti, ma a livello base rimangono comunque sequenze
di byte intervallate da spazi ogni tanto.
Evidentemente tapecopy — che è nato per fare copie fedelissime dei nastri —
rileva anche queste cose e ne tiene traccia nell'immagine che crea. :-)
Ciao,
G.
-- 
  «Al tavolo di comando e' connessa una Telescrivente, che ha l'ufficio di
prelevare il contenuto delle posizioni di Memoria che si desidera indagare
dandone la trascrizione a stampa su di un foglio di carta».
            Olivetti ELEA 9003 — Manuale base di programmazione — ca. 1955



Riassumiamo di nuovo...
Utilizzando dd, perdo delle informazioni contenute nell'immagine, se 
questa è stata creata con tapecopy.
(La creazione con tapecopy e la presenza di bytes extra mi 
giustificherebbe la dimensione non divisibile per 512)
Ma se uso tapecopy per ripristinare le immagini, tapecopy si lamenta di 
qualcosa, che sembra legato al formato dell'immagine stessa.
Non vorrei che mi stia dannando l'anima per un immagine errata a 
priori ...
L'hw funziona, dd e tar scrivono senza intoppi.
Quando parlavo di continuum è perche, soprattutto nelle zone ASCII, le 
immagini nastro non sembra avere altri bytes nelle zone di 
"confine" (512, 1024, 2048 ...).
La riprova potrei averla avviando dal nastro ricreato con dd.
Dovrei avere dei problemi ...



tapecopy sembra scrivere correttamente le altre immagini.
Il problema è sulla prima .. segnala un non meglio identificato problema 
di buffer :(

supervinx@supervinx:~/Apollo/Tapes/t$ sudo tapecopy -v domainos-
sr10.3-1of9.tap /dev/st0
file 0 record length 8192: 1 record (0)
end of file 0, 8192 bytes
file 1 record length 2560: 1 record (0)
end of file 1, 2560 bytes
file 2 record length 32768: ?65535 byte tape record too long for 32768 
byte buffer    <==
Allora ho modificato il file tapecopy.c, aumentando il buffer a 65536 e 
trasformando le opportune variabili da int a long.
Ricompilato, eseguito: nello stesso punto, adesso, mi segnala
supervinx@supervinx:~/Apollo/Tapes/t$ sudo tapecopy2 -v domainos-
sr10.3-1of9.tap /dev/st0
[sudo] password for supervinx: 
file 0 record length 8192: 1 record (0)
end of file 0, 8192 bytes
file 1 record length 2560: 1 record (0)
end of file 1, 2560 bytes
file 2 record length 32768: ?Corrupt tape image  <==
Tapecopy ha funzionato in tuti gli altri casi.

Il problema è proprio la prima immagine.
Tutte le altre si scrivono correttamente, e mostrano una variegata 
formattazione del nastro (almeno per le informazioni fornite da tapecopy).
Ho provato a scaricarla nuovamente... non è, purtroppo,un errore di 
trasmissione.

Allora...
Non so per DomainOS, ma posso parlare per altri unix più vecchi, come
Ultrix per PDP11.
All'inizio del nastro c'e' un file scritto con blocchi da 512 bytes
per il boot della macchina da nastro,
poi seguono una serie di files con blocchi da 2048 bytes contenenti le
utility di installazione,
ovvero avviabili dopo il boot direttamente da nastro.
Infine ci sono tutti i tar contenenti tutti i files del sistema
operativo da installare, a blocchi di 10240 bytes.
La preparazione del nastro si può eseguire tranquillamente con dd su
linux, tuttavia bisogna avere i files sorgenti separati,
opportunamente ordinati,
e l'informazione relativa alle dimensioni del blocco destinazione.
Questo perchè l'unità nastro in generale scrive separatamente i
singoli blocchi, con dimensione uguale per lo stesso file, e per ogni
blocco aggiunge
dei dati destinati alla correzione d'errore, etc.
Una sequenza di blocchi costituisce il file. Ogni file viene separato
dagli altri tramite un opportuni mark scritto sul file,
ovvero un blocco particolare nel quale si specifica nell'header
dimesione nulla.
L'utility tapecopy, guardando anche nei sorgenti si capisce, crea un
singolo file, contenente tutti i dati del nastro. Per ogni blocco
scrive, se non ricordo male,
un intero a 32bit all'inizio per specificare la dimensione del blocco,
ed uno uguale alla fine.
Insomma se i dati di un blocco da 512 bytes sono D0-D511, lui sul file
mette 00,00,02,00,D0,D1,....,D511,00,00,02,00. Occhio che dipende
dall'endianità della macchina.
Per il mark di file non ricordo se scrive 00,00,00,00,00,00,00,00
(blocco nullo) o FF,FF,FF,FF,FF,FF,FF,FF.
In ogni caso è possibile fare un'applicazioncina che estrae i files
dal tap, indicando anche la dimensione di blocco usata.
Certamente tapecopy alla lettura di un'immagine controlla se la
dimensione di blocco scritta prima e dopo i dati coincide (l'immagine
è sana).
Mi erano capitate immagini danneggiate o ricavate da nastri
danneggiati, in cui al posto di alcuni blocchi erano inseriti una
serie di FF,FF,FF,FF,FF,FF piuttosto lunga.
Questo perchè l'hardware in caso di errore riporta sia per la
dimensione del blocco che per i dati stessi il valore invalido FF, che
ovviamente però non è la vera dimensione del blocco, anche se questo è
rovinato. Tapecopy non gestisce questa eventualità, anzi scrive
esattamente quello che legge dall'hardware, e di fatto crea
un'immagine illeggibile.
Tapecopy scorrendo l'immagine trovava un FF,FF,FF,FF che considerava
come dimensione di blocco, che a parte essere invalida per l'hardware,
mandava fuori sincro la lettura...
Avevo risolto patchando l'immagine a mano e riallineando il tutto,
ovviamente il file "bucato" era poi danneggiato ed illeggibile, in
quanto i CRC non passano e gli errori non possono essere corretti
(errore hard).
Consiglio di fare un'utilitina che scorre il file analizzando le
dimensioni di blocco, le corrispondenze e i marcatori di files,
printando quanto rilevato.
In questo modo riesci a ricavare l'info sul punto esatto ove sta
l'errore, e forse a mettere a posto il tutto.



Grazie dell'idea !
Dal momento che conosco, più o meno, la posizione dell'errore, darò 
un'occhiata ...



Ora che ci penso ... anche correggendo, rimarrà un'errore, e quello è il 
primo nastro dell'installazione ... :(

 primo nastro dell'installazione ... :(
Fermi tutti. :-)
Stanotte e oggi pomeriggio, con la collaborazione di Vampire che mi ha anche
messo a disposizione una macchina con un tape drive, ho indagato e siamo
giunti a varie conclusioni abbastanza interessanti e utili.
Innanzitutto il formato del nastro e come viene memorizzato da tapecopy:
un nastro di boot di Domain/OS evidentemente inizia con un boot loader di
8192 byte (16 blocchi da 512) all'interno del quale è chiaramente visibile
fra le altre cose la stringa SYSBOOT e altre che non lasciano dubbi.
Dopodiché inizia un volume in formato standard ANSI, cosa che trovo molto
utile e che molti altri Unix non utilizzano (purtroppo).
Nel caso specifico, il volume si chiama "PSKQ3_" e contiene un unico file di
dati "PSKQ3_91 Boot Vol".
Lo standard ANSI prevede che ogni sequenza di blocchi dati sia preceduta e
seguita da alcuni record (tape label) che identifichino i dati in questione.
Questi label sono costituiti da vari record di 80 caratteri in formato ASCII
che all'atto pratico sono due piccoli tapefile che "incorniciano" i dati.
Inoltre, lo stesso standard prevede che all'inizio del nastro ci siano altri
specifici record di identificazione del volume nel suo complesso.
Ognuno di questi record inizia con un identificativo di quattro caratteri,
ad esempio VOL1, HDR1, EOF1, EOV1 etc.
Per quanto riguarda i nastri QIC, poiché hanno un blocco fisico fisso di 512
byte, i label vengono inseriti ciascuno all'inizio di un blocco, lasciando
il resto nello stato in cui si trova (vuoto o con dati random).
Quindi riguardo al nastro di boot di Domain/OS di cui parliamo avremo:
Oggetto                   Lung.
-------------------       -----
boot loader                8192   (senza nome, prima del primo label)
                                  (tm, tape mark)
label                      2560   (VOL1, UVL1, HDR1, HDR2, UHL1 da 512 byte)
                                  (tm)
"PSKQ3_91 Boot Vol"    50714624   (99052 blocchi * 512, da EOF1)
                                  (tm)
label                      1024   (EOF1, EOF2)
                                  (tm)
                                  (tm doppio...)
                                  (tm ... di fine nastro)
I tape mark, sono segnalazioni "fisiche" e out-of-band che il drive rileva
sul nastro e segnala al sistema operativo insieme al proprio stato interno,
cioè non sono dati leggibili dai programmi utente.
Tapecopy memorizza su file nello stesso formato utilizzato da E11 (emulatore
per PDP11) che ha anche ispirato il formato utilizzato da Simh, il quale — a
parte qualche byte di padding — è identico all'originale. [1]
Tapecopy non distingue tra label ANSI e dati veri e propri (del resto sul
nastro sono memorizzati allo stesso modo ed è il sistema operativo che
esegue la lettura che eventualmente sa come interpretare ciò che legge),
quindi per lui tutto quello che c'è tra un tape mark e l'altro sono dati da
memorizzare. Deve però anche memorizzare i tape mark in modo da poterli
riprodurre al bisogno, quindi adotta una tecnica semplice, ma efficace: ogni
flusso di dati viene scritto su file così com'è, preceduto e seguito da un
contatore di quattro byte che indica la lunghezza dei dati medesimi, mentre
i tape mark vengono rappresentati da una singola istanza del counter,
impostata sempre a zero: una specie di file nullo. [1]
Se il flusso dati supera i 32768 byte, viene spezzettato in tanti blocchi
consequenziali da 32768 o frazioni, fino a coprirne la lunghezza totale.
Quindi, tornando al nastro di boot di Domain/OS, avremo:
8192,bootloader,8192,0,2560,label,2560,0,32768,dati,32768,32768,dati,32768,
... ,0,1024,label,1024,0,0,0.
Detto tutto ciò, vediamo cos'è successo (e come rimediare). :-)
Con l'aiuto di gdb, vi, hexdump e dd ho scoperto che in ben tre punti di
questa famigerata immagine ci sono dei buchi, probabilmente causati da un
problema nel nastro originale (anche se non ci spieghiamo come mai tapecopy
abbia proseguito invece di fermarsi). I buchi sono tutti all'interno del
grosso file contenuto nel volume ANSI, apparentemente sempre al confine tra
un blocco da 32768 byte e il successivo.
In esadecimale, invece di avere
	xx xx xx xx - 00 80 00 00 - 00 80 00 00 - xx xx xx xx 
c'è un meraviglioso
	00 80 00 00 - FF FF 00 00 - FF FF 00 00 - 00 80 00 00
Cioè praticamente un file nullo di lunghezza infinita... :-\ in cui FF FF
viene ovviamente interpretato come 65535, cioè proprio l'errore mostrato da
tapecopy sia a Supervinx sia a noi mentre facevamo le nostre prove.
Fosse solo lì il problema, sarebbe sufficiente togliere via quegli otto byte
di troppo e tutto dovrebbe funzionare. Il guaio è che in ognuno di quei
buchi sono spariti N blocchi di dati originali, cosa che ho scoperto con un
po' di studio di quel che viene subito prima e subito dopo ogni buco.
Cercando in rete, ho scoperto che i dati di quel file sono stati scritti da
un programma di backup per Domain/OS che si chiama wbak (write backup), per
il quale esiste il relativo programma di lettura rbak (read backup), portato
anche su altre piattaforme da chi ebbe bisogno di migrare dei dati. [2]
Ebbene, quei dati furono scritti su nastro QIC, con il suo blocco fisso da
512 byte, quindi anche i dati sono suddivisi così, e ogni 512 byte c'è un
piccolo header numerato sequenzialmente, il che mi ha permesso di scoprire
che nei tre buchi sono spariti rispettivamente 60, 52, e 55 blocchi da 512.
Ne fossero mancati un paio, avrei suggerito di provare a far finta di
niente, sperando che l'accoppiata wbak/rbak avesse un qualche metodo di
recupero come ce l'ha per esempio BACKUP su VMS (il quale inserisce un
blocco di ridondanza XOR ogni N, 10 di default), ma così penso siano troppi.
Si può comunque tentare, ma le probabilità che manchi qualcosa di importante
sono piuttosto alte, considerando anche lo scopo del nastro.
Poi però ho notato domainos-crtg-std-sfw-boot-1-sr10.3-018847-001.tap.gz e
ho visto che è praticamente identico a quello danneggiato. È di un anno più
vecchio, ma sembra non presentare il problema. Inoltre — come l'altro —
sembra essere un nastro di solo boot, mentre il resto dell'installazione
pare che avvenga dai nastri successivi, quindi si potrebbe provare ad
avviare la macchina con quello e poi installare con gli altri, dal 2 al 9.
Il volume alternativo si chiama "SR10.0" e il file al suo interno, l'unico,
si chiama "SR10.03.a Boot Vo", quindi tentar non nuoce. Pensiamo che in un
modo o nell'altro possano esserci buone possibilità di riuscita.
Dato che c'ero ho dato un'occhiata anche al secondo nastro (dei nove):
Volume "ST0157"
Label              lung.
-----------------  -----
force              23255
ri.apollo.os.v.10   5296
/base_sysboot         24
/base_sysboot.m68     93
/base_install_uti   1715
/base_install       3012
/base_domain_exam   5881
/base_closed_etc   15856
/base_etc_tcp       1230
/base_open_lib     16205
/base_open_sau2     4098
/base_open_sau3     3959
/base_open_sau4     4969
/base_open_sau5     4420
/base_open_sau6     4957
/base_open_sau7     7268
/base_open_sau8     5058
/base_open_sau9     5802
/base_open_sau12    6682
È tutto, :-)
G.
[1] 
http://www.avanthar.com/~healyzh/klh10/doc/vtape.txt
[2] 
http://www.umich.edu/~archive/apollo/
 (cfr. rbak-2.0b.tar.gz)


A conferma di tutto ciò (visto che anch'io ho condotto le mie analisi ... 
non pensiate che me ne stia con i ... bit in mano ! :) )
Ho usato solo hexedit ed una piccola modifica ai sorgenti di tapecopy, 
così che mi dicesse dove si fermava, ed ho notato gli FF di troppo.
Non conoscevo, però, l'esatta struttura del nastro.
L'altra immagine di boot l'ho vista anch'io, e mi girava l'ideuzza di 
provarla, visto che la prima immagine è sicuramente non usabile :P
Male non farà, al limite non funziona ...
Peccato che il primo nastro sia danneggiato.
Non è che quelli del museo proverebbero a ricrearla ?
Non credo si trovi da nessun'altra parte DomainOS ...

 da nessun'altra parte DomainOS ...
Ho gia' chiesto ad asbesto (propio mentre facevamo prove con gerry per
identificare il problema) di effettuare un altro dump del nastro 
incriminato, cosa che fara' tempo permettendo (il che implica un attesa
discretamente lunga), per il momento la cosa migliore e' tentare 
l'installazione usando il secondo nastro di boot (e/o il nastro
danneggiato).


 danneggiato).
Mi sembra d'avervi impegnato, nel fine settimana ;)