Her er en lille drilleopgave til UNIX hajerne:
Antag et UNIX system på niveau med UNIX v7
Opgaven er at lave en sektor-for-sektor sikkerhedskopi af en 20MB harddisk, der kun er tilgængelig som raw-device.
Du har kun de programmer der ligger på en installationsdiskette: cat, cmp, cp, dd, echo, ed, grep, od, sh, i særdeleshed har du ingen C-compiler.
Du har en seriel konsol, max 9600 bps, der kan sættes i raw mode.
Du har en parallel printer port der kan overføre ca. 1700 bytes per sekund, men den oversætter NL til CRNL og TAB til spaces.
Desuden kan printerporten kun åbnes en gang, bagefter kræver det et reboot (= 1 minut)
I den anden ende af serielport og printerporten har du en laptop med en moderne UNIX.
Det tager ca. 2 sekunder at starte en kommando fordi det hele kører på floppydisk.
Pipes er langsomme, fordi de bruger disketten som mellemlager (har ikke målt hastigheden, men "dd ... | od -x" er klart langsommere end serielporten).
od(1) programmet læser 16 bytes af gangen og kan derfor ikke direkte læse en raw-device.
Hvad gør en rigtig UNIX haj ?
phk
Har vi adgang til følgende man sider? http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf
min første indskydelse er cat /rawdevice
Jeg har fornøjelsen af at have en go', gammel Commodore Amiga 3000UX, der kommer med AmigaUNIX (aka AMIX). Og som stadig virker - og fint kan snakke IPv4... omend den næppe er sikkerhedsmæssig forsvarlig at hælde direkte på nettet.
At rode med den er rigeligt til mig, men ja, man bliver vældig god til at finde kreative løsninger med et begrænset kommandoapparat til rådighed. Det minder mig næsten om de gode, gamle SunOS 4.1-dage. Som i øvrigt ikke var SÅ vældigt gode igen :-)
Det er i øvrigt fantastisk at se, hvor meget UNIX der egentlig virker på sådan en fin 25 MHz 68030 med 18 MB RAM. Og endda ganske hurtigt.
Held og lykke med dit gamle hardware :-)
Er det null modem kabel du er omkring?
Spørgsmålet er vel hvor du vil cat'e dit rawdevice hen og det er nok her hunden ligger begravet. Min første indskyldede var at det da bare var at dd'e harddisken til seriel porten. Men når begynder Poul-Henning at snakke om 'dd ... | od -x' er det nok ikke så let.
Så hvis pointen er at vores kommunikation skal være 7bit ren og vi ikke må bruge pipes, så rækker min unix-fu ikke længere. Så jeg er holdt op med at gætte. (Efter at jeg tjekkede dd(1) for om conv argumented kunne hjælpe os på magisk vis)
Må vi pille disken ud og putte den over i en anden maskine??
@Kristian: "cat /dev/rawdevice" virker ikke, cat på denne UNIX læser tilsyneladende et tegn ad gangen. Du er velkommen til manualsider hvis du kan finde dem: Coherent 0.7.3
@Thomas: Kabelproblemer er løst, men vi ved ikke om vi har flowcontrol på serielporten.
@Peter: dd til konsolporten er den direkte vej, men der mangler en eller anden form for fejldetektering synes jeg.
@Ole: Det er ikke en mulighed, formatet er tilsyneladende unikt for denne maskine (CBM900)
Kunne i finde et sted i maskine hvor harddisk data kommer "forbi" og så lave en "dd if=/dev/hd of=/dev/null" og så fysik optage den bit strøm der kommer. Som sagdt, måske lidt langt ude.
Skal du saa ikke sætte serial port til binary mode?
@Peter: dd til konsolporten er den direkte vej, men der mangler en eller anden form for fejldetektering synes jeg.
Og du vil også helst begrænse antallet af læsninger, så harddisken ikke dør yderligere?
Ellers ville jeg nok overveje om der ikke er fejldetektering nok i bare at gøre det tre gange og så sammenligne. Det tager 2 timer, hvis jeg lige regner rigtigt. Så en Rigtig(tm) løsning skal være hurtigere at implementere end det.
Men jeg har ingen praktisk erfaring med den slags begrænsede miljøer.
...kunne man ikke bare smide en ekstra disk i maskinen og klone med dd ? WD1003 kan køre med flere diske...
Som jeg læser artiklen og kommentarer var jeg først ude i en Ole-løsning, dernæst en Steffen-løsning, som vel nærmest er en Chris Fenton-løsning.
Det springende punkt er, hvor meget vil I gøre for at tilgå disse data? Hvad er data værd? Hvad er hardware værd? (På sin vis ubetaleligt, I know...) Med "værd" mener jeg naturligvis ikke "rede penge" men snarere tid, hacking, og for hardwarens del evt. indgriben a la teknisk forandring.
Links: http://chrisfenton.com/cray-1-digital-archeology/ http://www.archive.org/details/2011-cdc-disk-archaeology-fenton Disse forudsætter naturligvis en vis portion mod, tid, og ikke mindst kendskab til diskens bit-allokering, filsystem, etc.
@Maciej: Den har jeg prøvet og jeg kan ikke tilgå en fremmed disk. Jeg er ikke klar over hvorfor, det vil formodentlig kræve en disassemblering af Coherent kernen og det er jeg ikke nået til endnu.
@Jan: Om data er noget værd afhænger af hvad der ligger på disken. Det kan jeg ikke vide før jeg har en kopi.
Men de par timer er vel ikke afgørende; så vidt jeg har forstået er det mere et spørgsmål om tvivlsom fejldetektering (ECC)?
...så du risikerer at der ikke ligger andet end en gammel Space War hi-score liste? Det gør det sværere at estimere "passende" indsats...
Hvad fylder hver sektor og hvor mange er der? Kan du dumpe x antal sektorer på floppy og kopiere disse ind via diskettedrev/station? Det lyder næsten som om du har forsøgt dette, men at det er for langsommelig en process?
Disketter er ikke kompatible med nogen anden maskine i hele verden: Det er en variant af Commodores GCR kodning, men med 512 byte sektorer.
Hvorfor så ikke prøve at se på de metoder som bruges til at rippe en 1541 disk?
Fordi det er en harddisk ?
Jeg kunne forestille mig at man skal ind i WD1003 "BIOS" for at nulstille den anden disk før CBM900 vil se den... som i gamle dage på PC-erne: ind i debug og ind køre fra en bestemt addresse.
Er det fuldstændigt umuligt at lægge et selvskrevet værktøj på disketten?
Helt ærlig PHK. Du ved da at nix behandler alt som filer/stream. Og flowcontrol ved du også godt ligger i både hardware og software alt efter lag.
Er det slet ikke muligt at lave et hex dump og så køre det ud via den serielle konsol eller til printeren? Godt tager det længere tid, men det er nok lettere at fejlsikre og så gør det ikke så meget med f.eks. linjeskift. Ellers må du igang med at fremskaffe/-stille en c-compiler eller en assembler.
@Thomas: Når nu du er færdig med at belære en UNIX kerne-koder om hvordan UNIX virker, så kunne du jo overveje at give et bud på løsningen ?
Noget Coherent source og en manual kan stadig findes
http://unixarchive.tliquest.net/Other/Coherent/kernelsource/
http://www.tenox.tc/docs/coherent_manual.pdf
dd virker som en standard dd inklusive stop på IO fejl.
Coherent brugte COFF format, men kan I få CBM 900 op at køre og har I mulighed for selv at lave disketter? (og så er der lige den med COFF kompatibilitet og held)
Man kan finde Allan Cornish' navn nogle steder i kernesovsen (og i manualen), så han kan måske findes?
Kunne man forestille sig en løsning hvor man bruger 'dd' til at indlæse en passende klump data ind i en shell var, lave noget manuel CRC på data, outputte det med echo til od og overføre det hele via consollen? Det tager unægteligt noget tid og der kommer en del læsninger/seeks på disken.
Lav to dumps med dd hvor der benyttes forskellig conversion. dd if=/dev/hd of=/dev/lp conv=ascii dd if=/dev/hd of=/dev/lp Sammenlign de to dumps for at finde hvor TABS og LF er konverteret af printer driveren.
Er der forskel på nedestående? (rtty referere til raw tty, hvis en sådan findes ... skulle gerne starte med bogstavet r):
cat /dev/rawdisk
cat /dev/rawdisk > /dev/rtty
cat -u /dev/rawdisk
cp /dev/rawdisk /dev/tty
ar rv /terminal /rawdisk
tar c /terminal /rawdisk
compress < /rawdevice
uuencode < /rawdevice
kermit sa /dev/rawdisk diskkopi
Hvad siger stty?
Hvor slemt medtaget er diskene? /etc/badscan -v /rawdisk size /etc/badscan -v /rawdisk /ikkerawdiskx (kan være destruktivt, manualen bruger termologien "scans a disk for bad blocks" ... jeg antager den ikke laver skrivninger)
Er der for mange fejl, kan awk parse uddata fra badscan, og kalde dd så fejl læsninger undgåes.
lpskip, kan den ikke bruges til at genskrive til printeren uden genstart?
Det er ikke så svært at uploade noget. Det gøres bare fra serielporten eller om nødvendigt via konsollen. Spørgsmålet er om der findes en cross-compiler eller assembler?
Se grunden til det her blogindlæg var en ide jeg havde fået, men desværre holdt den kun 15/16 vand.
Bo er inde på samme ide med "dd conv=ascii", men istedet for "ascii" ville jeg bruge "swab" (= swap bytes).
Det virker perfekt i 15/16 del af de mulige tilfælde, hvis man gider skrive den sindsygt komplexe kode til at sammenligne de to dumps og gennemskue hvor der var TABs og hvor mange spaces de var lavet om til.
Men det virker jo selvsagt ikke i den 1/16 hvor en TAB bliver til en enkelt SP i både den ene og den anden kopi.
Æv Bæv, tilbage til start, uden at indkassere 20MB.
Det siger naturligvis sig selv at jeg først opdagede denne svaghed, da jeg havde dumpet hele disken med conv=swab.
For ikke at spilde aftenen totalt startede jeg en dd if=/dev/rhdall0 | od -x > /dev/lp og til min store glæde opdagede jeg at jeg fik ca. 1400 Bps igennem, fordi alle de sektorer på floppyen der blev brugt til pipen havnede i samme cylinder.
Men ingen glæde varer som bekendt ved.
Der kom læsefejl på floppyen, men efter nogle retries kom den videre. Problemet er bare at jeg ved at checksummen på det der skod-format de bruger på floppyen er en simpel en-byte sum, så jeg stoler ikke synderligt på at de 3MB jeg fik hevet igennem er OK.
Man kan ikke sige andet om den CBM900 end at den gør brav modstand.
Ideen med at sniffe med på harddisk-controlleren har jeg overvejet, data passerer, meget bekvemt, en 8-bit parallel bus, men desværre kender jeg ikke handshake på den bus i alle detaljer og da hastigheden er omkring 500kB/s er det heller ikke helt trivielt at fange og få experedet data videre, når man ikke har muligheden for at lave flow-control.
Det med at få lagt et program på floppyen ville kræve at jeg skrev en simulator der kunne køre C-compileren. Formodentlig kunne man nøjes med at simulere userland og emulere systemkaldene, men det er stadig en bid mere arbejde end jeg har lyst til lige nu.
Endelig er der muligheden for at fylde et maskinkodeprogram i RAM via boot-rom'ens debugger og det er nok den vej jeg hælder mest lige for tiden.
Er det muligt at lave en memory mapped file, altså en fil der er i RAM og ikke på disk?
Nej, vi er ca. 10 år forud for VM systemers alt for langsomme gemmenbrud.
Men i tilfældet med to på hinanden følgende TABS eller LF vil conv=swab ikke virke. EBCDIC -> ASCII vil konvertere 0x09 -> 0x8d og 0x0a -> 0x8e.
echo -ne "0123456789\n\t\t\t " > diskdatsim.txt echo -ne "Raw :" od -t x1 diskdatsim.txt dd if=diskdatsim.txt of=ascii_dump.txt conv=ascii echo -ne "Ascii:" od -t x1 ascii_dump.txt dd if=diskdatsim.txt of=swap_dump.txt conv=swab echo -ne "Swap :" od -t x1 swap_dump.txt
Raw :0000000 30 31 32 33 34 35 36 37 38 39 0a 09 09 09 20 20 0000020 20 20 20 20 20 20 0000026 0+1 records in 0+1 records out 22 bytes (22 B) copied, 5.7184e-05 s, 385 kB/s Ascii:0000000 90 91 16 93 94 95 96 04 98 99 8e 8d 8d 8d 80 80 0000020 80 80 80 80 80 80 0000026 0+1 records in 0+1 records out 22 bytes (22 B) copied, 5.6859e-05 s, 387 kB/s Swap :0000000 31 30 33 32 35 34 37 36 39 38 09 0a 09 09 20 20 0000020 20 20 20 20 20 20 0000026
http://hxc2001.free.fr/floppy_drive_emulator/ skulle efter sigende kunne simulere noget nær alle formater (har ikke prøvet én endnu). Hvis sådan én fungerede, kunne man velsagtens med rimelig pålidelighed dumpe harddisken over på flere "disketter" og samle dem igen på en moderne maskine.
Som sagt har CBM-900 sit helt eget unikke floppy format, så det er næppe nemmere.
Ideen med at sniffe med på harddisk-controlleren har jeg overvejet, data passerer, meget bekvemt, en 8-bit parallel bus, men desværre kender jeg ikke handshake på den bus i alle detaljer og da hastigheden er omkring 500kB/s er det heller ikke helt trivielt at fange og få experedet data videre, når man ikke har muligheden for at lave flow-control.
Moderne oscilloskoper med logik probes, har dog mulighed for at logge over tid og til en fil. 500Kb/s på en 8bit bus, svarer så til 64KHz. Med lidt god vilje kan man så benytte rising/lowering edges til at aligne efter i et post-processing job. Det er nok ikke nemmeste løsning, men tilgængæld kan du vælge at crowdsource post-processing jobbet.
Commodore har nok brugt 100tpi drev i dem som i de senere 8050,8250 drev som blev brugt på 8000 serien, de ligger tidmæssig op ad hinanden. Er ikke så mange maskiner som brugt de 100tpi drev, så det bliver ikke meget nemmer af at få det ud på disketter, og med en anden sector size end commodore dos i de drev, tvivler jeg på mine drev kunne læse dem, andet man smed ny kode i et par roms til dem.
hexdump en klump af disken til konsol, webcam på laptop knipser et billede og kører det en tur gennem OCR og gemmer. Synkronisering af skærm-dump og kamera gennem seriel port. Doable?
Der er jo en IEEE-488 udgang på sådan en CBM-900, kan den ikke bruges? Eller den er måske ikke tilgængelig fra Unix siden.
Der er ingen device driver eller dokumentation til den så vidt jeg kan se.
Men i tilfældet med to på hinanden følgende TABS eller LF vil conv=swab ikke virke. EBCDIC -> ASCII vil konvertere 0x09 -> 0x8d og 0x0a -> 0x8e.
Så vidt jeg husker taber de "gamle" conv={ascii,ebcdic} information, ingen af dem er 1:1 mapninger, men du har ret at man burde kunne identificere TAB karakterne på den måde. (CR er ikke noget problem, s/CRNL/NL/ klarer dem.)
hexdump en klump af disken til konsol, webcam på laptop knipser et billede og kører det en tur gennem OCR og gemmer. Synkronisering af skærm-dump og kamera gennem seriel port. Doable?
Hvis PHK alligevel har tænkt over en maskinekode løsning, så kunne han måske generere ascii QR koder på skærmen. Med 21 vertikale linier til rådighed, vil han med 7% redundans, AFAIK kunne gemme ca. 16byte. på en monokron skærm. Ved at benytte rotation af QR markørene som flow kontrol, og med 10 billeder i sekundet, vil det tage ca. 1½ døgn at få de 20MB ud.
Om det kan gøres i realtid er nok tvivlsomt, selv om det bestemt vil være nemmere og mere fejl-frit end ASCII/HEX OCR post-processing.
I gamle dage, når man skulle overføre binære filer over serrielporten, så brugte man at uuencode en fil en mapning, som konverterede 2 oktetter til tre printable ascii tegn
Døde, da alle fik mail med 8 bit integrity
(der fandtes vistnok også en version der kunne overføres på 6 bit teletype)
base64 er en bedre implementering af samme ide, da der kun bruges alphanumeriske tegn samt / og + til at udtrykke det kodede budskab, som således bliver invariant overfor ASCII <-> EBCDIC transformation
Fandt du nogensinde en løsning på dette problem?
Ja, jeg har fået sikkerhedskopieret CBM900 softwaren.
I sidste ende kom det til at foregå via printerporten med en lille ARM controller der lavede det om til en seriel USB port.
Ja, jeg har fået sikkerhedskopieret CBM900 softwaren.
Fint! :) Ellers ville jeg bare anbefale en billig Saleae USB logic analyzer, uendelig logging med seriel->parallel konvertering samt eksport.
Hvad endte du med at gøre i software? Og var der noget interessant på disken?
slettet
