sommers@topaz.ARPA (Mamaliz @ The Soup Kitchen) (05/13/85)
(This line wants to be a Tech writer at Micromush.)
Has anyone got backup/restore working under Xenix on their AT? After I get
beyond the pretty shell script restore just gives me
cannot allocate physio buffer (or something like that).
Sometimes it seems that Microsoft never tested the utilities on an AT.
--
liz sommers
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!sommers
arpa: sommers@rutgerscaf@omen.UUCP (Chuck Forsberg WA7KGX) (05/16/85)
>Has anyone got backup/restore working under Xenix on their AT? After I get >beyond the pretty shell script restore just gives me >cannot allocate physio buffer (or something like that). > >Sometimes it seems that Microsoft never tested the utilities on an AT. I reported the same information to the IBM Xenix hotline in December, both verbally and in written form. I have also given this information to Microsoft at Unicom in Janurary. The "maintenance disk" Microsoft shipped in early May did not contian new versions of these programs. Perhaps Microsoft will get around to fixing it on their SYS V version. Perhaps Microsoft's quality assurance personnel are all committed to their applications programs. -- Chuck Forsberg WA7KGX ..!tektronix!reed!omen!caf Omen Technology Inc 17505-V NW Sauvie IS RD Portland OR 97231 Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect)
caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/17/85)
My previous followup failed to mention that I had tried to use dump and restor directly (as I have on V7 and a Plexus V7 and SYS III). To clarify things, I'm including a portion of the report I sent to IBM in December and gave to Microsoft in Janurary. Normal floppy disk writes do not appear to be checked either. The best advice is to completely read the floppies you have just written to make sure they are readable. Unfortunately this makes multi volume floppy disk backups incredibly cumbersome. Xenix desperately needs a "VERIFY" switch `ala DOS. Speaking of disk backups raises a sore point. ... The documentation on restore(1) notes that "It is not possible to successfully restore an entire active root file system." No such warning is made in the documentation on backup(1) (`aka dump(1)). The implication is that these programs will operate properly on an inactive root file system, such as when Xenix is in system maintenance mode. When I made a level 0 backup, backup cheerfully wrote out out five HD diskettes. Unfortunately, dumpdir coredumps when trying to read this archive, and restor wouldn't restore a good file system from these disks. Life was slightly better with the /usr file system, except that backup skipped all files and subdirectories to /usr/lib. The resulting filesystem ended up with a cyclical data structure, a directory that is indirectly linked back to itself. After discovering (the hard way!) about backup/restor\'s problems dealing with a root file system, I tried dd. A first dry run (dd if=/dev/root of=/dev/null bs=10k) seemed to work normally, but succeeding dd commands resulted in a variable, smaller number of records transferred and eventually core dumps. By this time things had gotten so far out of hand that the shell itself was tossing cookies. (The revised disk driver on the maintenance disk seems to have cured the core dump syndrome but not the other problem.) OOOPS - No It didn't !!! Just took a little longer to start tossing cookies. -- Chuck Forsberg WA7KGX ..!tektronix!reed!omen!caf Omen Technology Inc 17505-V NW Sauvie IS RD Portland OR 97231 Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect)