test-drb May 2002

test-drb@ccmp.vtda.org

246 participants
947 discussions

by rmoyers＠nop.org

cat /dev/floppy > /test1 cat: /dev/floppy: Input/output error -rw-r--r-- 1 root root 18432 May 3 02:09 test1 Bad floppy right ? So time for dd, noerror tells it not to quit sync tells it not to aggregate a short read with the good ones, but to fill the remainder of the short read with zeros so ... dd conv=sync,noerror if=/dev/floppy of=/test2 ( bs=defaults to 512) -rw-r--r-- 1 root root 1474560 May 3 02:18 test2 and we have the whole image of the proper size but including bad sectors filled in with zeros Raymond

22 years, 3 months

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 14:08:41 -0500 > In-Reply-To: <20020502200530.E35218(a)MissSophie.unixag-kl.fh-kl.de> > > On Thursday 02 May 2002 13:05, you wrote: > > On 2002.05.02 18:25 Raymond Moyers wrote: > > > Whats wrong with cat ? > > [...] > > > I see most are using dd when cat is all they need > > cat(1) and dd(1) do not read / recognize the _physical_ block size of > > the tape. > > At the portion of the work where you just want to get the stuff > spooled to a file, you dont care about "block size" yet, you > just need to get it pulled off. > > Unix will treat any device as a stream of bytes > > On my old sony, mkboot is broken, you cant use the OS to > create a bootable volume of itself > > so ... you hang the old scsi disk off your linux box and > cat /dev/sdb > /files/sonyhdimage.img > > hang the new scsi disk off your linux box > > cat files/sonyhdimage.img > /dev/sdb > > Put new disk in sony, look mom it boots !! > > Now you redo the disklabel and shove everything > except root up to a new volume above the footprint of the old disk > redo the middle volumes to suit ... move the stuff back down > mount the new space as /usr/local whatever > > Now you have a 1g bootable disk in a machine that cannot create > one for itself... > > Do you see what im getting at here ? hello ? > > and guess what ... i never even bother to involve myself with > any "block sizes" even as the multiple volumes on > that image uses a mix of logical block sizes. Guess what. You aren't dealing with structured magtapes. And it's a very rare disk drive that has a mixture of block sizes. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

22 years, 3 months

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 11:25:19 -0500 > In-Reply-To: <5.0.0.25.0.20020502090947.02f88e30@pc> > > > > At 02:01 AM 5/2/2002 -0700, Ethan Dicks wrote: > >I can use dd to slurp > >stuff off of tape, but it's tedious. What tools are people using for > >tape archiving under Linux or Solaris? AIX seems to come with "tcopy" > >that essentially pulls everything off the tape until logical or physical > >EOT. I'm looking for something similar - point it at the drive and > >siphon it on down. > > Whats wrong with cat ? > > use the /dev/nst0 device, its the one that dont rewind > ( use mt commands for that kind of stuff ) > > cat /dev/nst0 > file1.tap > cat /dev/nst0 > file2.tap > > and so on You have just thrown away all of the data structure on the tape. No more clues about block lengths, file marks, etc. Some original software is going to need that information to work properly with whatever else is on the tape. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

22 years, 3 months

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> Date: Thu, 2 May 2002 06:25:24 -0700 (PDT) > From: Ethan Dicks <erd_6502(a)yahoo.com> > Subject: Re: Tape dumping programs for Unix/Linux... > To: classiccmp(a)classiccmp.org > In-Reply-To: <Pine.LNX.4.44.0205021957030.15892-100000(a)floodland.tved.net.au> > Sender: owner-classiccmp(a)classiccmp.org > Reply-To: classiccmp(a)classiccmp.org > > > --- cvisors(a)carnagevisors.net wrote: > > there is also dump & restore, if the Sparc is running solaris there is > > ufsdump and ufsrestore, and finally if all else fails tar > > these programs should allready be (dump and restore) on the redhat box. > > You misunderstand the direction I'm going. I have magtape with data > already on it. I want to extract that data into a file or set of > files on the disk that I can then burn to CD-R. I can use dd to move > raw records, but I would like to also know what the block size was > for a particular file so I could reconsitute the tape later if > necessary. I'm not so worried about the VMS BACKUP tapes I need to > spin off - I want one saveset per file. If I want to dup any install > tapes (non-VAX), the blocking becomes more critical. > > Essentially, a physical backup that is primarily for data recovery, > but secondarily for later restoration. Yes, that is what "copytape" was written for. Works quite well, especially now that disks are (again) much larger than tapes. The balance keeps shifting back and forth over the decades. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

22 years, 3 months

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> Date: Thu, 2 May 2002 05:34:09 -0500 (CDT) > From: Doc <doc(a)mdrconsult.com> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > In-Reply-To: <Pine.LNX.4.44.0205021957030.15892-100000(a)floodland.tved.net.au> > > On Thu, 2 May 2002 cvisors(a)carnagevisors.net wrote: > > > there is also dump & restore, if the Sparc is running solaris there is > > ufsdump and ufsrestore, and finally if all else fails tar > > these programs should allready be (dump and restore) on the redhat box. > > I'd be very interested to know if RedHat dump/restore will fly on > those magtapes. Linux' version only works on ext2 filesystems on the > dump side, but since the tape archive (_IF_ it was generated by unix > dump) isn't exactly a filesystem.... My bet would be a big no go, but > now I'm curious. > BTW, Jochen turned me on to the maketape utility from PUPS a while > back. It works very well. By their nature, dump and restore (or ufsdump and ufsrestore) are operating-system specific. Dump in particular works on the raw disk image and must have intimate knowledge of the way the operating system constructs a file system. On the other hand, I was once successful at restoring a dump tape made on a MicroVax Ultrix system using "restore.old" on a NeXT. I was rather astonished that it worked. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

22 years, 3 months

APPLEVISION Monitor

by acme_ent＠bellsouth.net

> From: Richard Erlacher <edick(a)idcomm.com> > What's always annoyed me with "brand-name" PC's is that the packaging ALWAYS > deviates from the "norm" established by the DIY market. Consquently, your > DELL, Gateway, or Compaq was never upgradable, because the CPU or hard disk > wasn't supported by the BIOS, or some peripheral wouldn't fit in the system > because of address conflicts. Simple things like the on-board video caused > problems when they failed because one couldn't disable them, or, if one did, > the now-broken native video interfered with the replacement. Even printer > ports posed such problems. Many times the packaging itself was the problem. > Have you ever tried to replace or upgrade the CDROM drive in an HP PC? Actually I've found that CD-ROM drives are among the easiest components to replace in HPs. Often the floppy disk drives and power supplies have a weird form factor, and when it comes to motherboards, forget it. I have found HP and Compaq units where, in order to replace the CD-ROM drive (or *any* drive) I had to pull the motherboard, which seems pretty bizarre in itself. Glen 0/0

22 years, 3 months

Googling and "egg-sucking" (was Re: "Toy" computers...)

by cdl＠proxima.ucsd.edu

> Date: Wed, 1 May 2002 19:52:05 -0500 (CDT) > From: Doc <doc(a)mdrconsult.com> > To: classiccmp(a)classiccmp.org > Subject: Re: Googling and "egg-sucking" (was Re: "Toy" computers...) > In-Reply-To: <3CD004D7.3282.A8CC01B@localhost> > > On Wed, 1 May 2002, Stan Sieler wrote: > > and, re: > > > Hey, guys. Simplify. A Google search on the phrase "suck eggs" leads > > > to a clear explanation of the historical use of the phrase, dating > > > back to the 16th century in English, and older in other languages. > > > > > > < http://www.quinion.com/words/qa/qa-tea1.htm > > > > > Nice try, but it doesn't address what I think most people are interested > > in learning about (for that phrase, anyway :) ... sucking eggs. > > It address, instead, the concept of teaching people something they > > already know. > > Well, I dunno what most people are interested in learning about, but I > know that referral to "teaching people something they already know" was > the point of my original use of the phrase. I thought people on this list were interested in historical stuff. An investigation into the antiquity of the expression seemed appropriate. On the same Web page one finds a much more antique version of the same idea in Latin, which can be translated as "Don't teach a fish to swim". carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

22 years, 3 months

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> > The emulator community is vigorously using a tape image container > > format known as TAP for precisely this purpose. ... > Darn...sounds like a subset of what I use. I'd be interested > in knowing more about TAP (with an eye towards adopting use of it), > and would suggest some possibly missing features might be: > > - ability to flag if the current tape record had a recovered read > error (obviously, not all hardware/OS's support getting that information) No. And I see no useful purpose in including that in the format. If the read was recovered, you have the data; surely you would *not* want to recreate a tape and make a previously marginal block, marginal again on a clone? > - ability to flag if a particular tape record had a hard error > while reading it No (I can say this even though I'm about to ask): do you mean an unrecoverable error, or one that was corrected by the hardware (as opposed to being corrected by software)? Either way, if the error was corrected, see my response above. > - ability to flag if an End-of-tape marker/indicator was seen > while reading the the current record (again, not all > hardware/OS's support getting that information) No, and again, I can't see how this data would be used to recreate the tape or would be needed by an emulator. It's kind of like asking if a particular hardware emulator also emulates memory parity errors so that you can see memory parity errors in the logs. Why?? > - overall header at start of file, recording information about the tape No, although I did consider suggesting some extensions like this. One problem I have encountered with some old CDC tape formats dealt with how blocking got handled. But my current feeling on this is that if its blocked on taped, then the records will come off the taoe with their proper lengths (I encountered this not trying to read a tape, but trying to create an image of a tape that no longer exists by a desctiption of its contents). Anyway, I encode that kins of descriptive information (what kind of computer, encoding, #tracks, etc) in the filename, or in the name of the directory containing the file, or in a README. > I have a program called "tapedisk", which reads an arbitrary tape > and "copies" it to a single disk file (or set of files, if the size of the > output file exceeds the maximum disk file size). The purpose of > tapedisk is to allow a future exact copy of the tape to be recreated > on another tape (of equal or larger size). (That future copy would be > made with the companion program, disktape.) Additionally, most of > my other tape-reading utilities know how to read a tapedisk format > disk file as though it were a tape. This sounds familiar... is it on the web somewhere? > This is what I store on a per-tape-record basis: ... So you really do want to recreate bad tapes as bad tapes... Why? > This is some what I store as a "header" at the start of the > overall output: ... Yeah, this info is README fodder... why on earth program that? > As you can see...a lot of info, but all necessary to faithfully > reproduce the tape later and/or to understand *why* the file might > (or can't) be used to completely reproduce the tape. Uh, again, can't understand why you'd need to recreate bad tapes. As to the understanding, README.DOC... etc... > This is part of a product we sell on MPE/iX systems, but I'd be happy > to document the structures and/or work with other people on standards > in this area. > > There's room for potential improvement. For example, is it worthwhile > to have a table at the front of the output file that specifies where > the first N EOFs are? You just used that nasty, bad word "standard"... TAP is a convention, not a standard. ;) However, I'm not King of this Kingdom, we're a collective (right out of Monty Python's Search for the Holy Grail). You might try hooking up with the emulator community and ask your questions there. Regards, -doug q

22 years, 3 months

Anyone need 2112 RAMs?

by acme_ent＠bellsouth.net

> From: Lawrence LeMay <lemay(a)cs.umn.edu> > I could use some 2114's and C2109-4's. These are used in Teraks for Video > memory and System memory. Just in case anyone knows of a source ;) Jameco sells the 2114N for $1.49. Glen 0/0

22 years, 3 months

MP/M was CP/M-86

by acme_ent＠bellsouth.net

> From: Freek Heite <f.heite(a)hccnet.nl> > On what kind of hardware is this MPM (86?) running? Newbies that want to > experiment with MPM, would most likely want an implementation of MPM for > the IBM PC hardware - but is that available somewhere? The downloads that > were mentioned a week ago (mpm8621i.zip etc.) are for some compupro hardware. Actually, I'd like to get MP/M for my Zenith Z-100s. Anybody know if this is available?? Glen 0/0

22 years, 3 months

← Newer
1
...
81
82
83
84
85
86
87
...
95
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb May 2002