puglia@cunixf.cc.columbia.edu (Paul Puglia) (03/02/90)
On monday I was involved in upgrading a pair of MicroVAX IIs to Ultrix 3.1. Each Microvax has an Emulex disk drive and controller hooked to them, and I did an Advanced install to edited in the controller when I was setting up. Once the new kernel had compiled and the system had rebooted I logged in and added the disktab entry for the drive--this disktab entry has worked since 1.2. The installation worked fine on one system, I was able to create the special files and newfs the partitions I wanted filesystems on. On the other system when I went to newfs the first filesystem, I got an error message saying that there was no partition table in the superblock!! And when I went to check the what the partition table was with chpt I got an error message saying that there was no superblock at all. Every chpt option you can use returns with the no superblock error. At this point I grabbed the Emulex diags tested the controller and the drive. The diags reported that both where fine. I then reformated the hard drive figuring that this would replace the partition table. I rebooted ultrix and tried chpt. I got the same error as before. I have talked to Emulex and they claimed that if the drive passed the diags and reformatted without errors then it should be fine, they advised me to call DEC. Which I have done, and I am still waiting for the call back from Atlanta. I am posting this on the off chance that someone may know how to replace the partition table on this drive, or give can me some idea why Ultrix is munging the partition table after the first time it accesses the drive. Thanks in advance Paul Puglia Dept. of Civil Engineering Columbia University puglia@cucevx.civil.columbia.edu puglia@cunixf.cc.columbia.edu : Internet PUGLIA@CUCEVX :BITNET
alan@shodha.dec.com ( Alan's Home for Wayward Notes File.) (03/02/90)
In article <1990Mar1.180652.13910@cunixf.cc.columbia.edu>, puglia@cunixf.cc.columbia.edu (Paul Puglia) writes: > > The installation worked fine on one system, I was able to create the > special files and newfs the partitions I wanted filesystems on. > [ and didn't work on the other... ] The first question to find the answer for is: What is different between the two systems? > I got an error message saying that there was no partition table in > the superblock!! And when I went to check the what the partition > table was with chpt I got an error message saying that there was > no superblock at all. The ULTRIX partition table lives somewhere after the interesting data in the superblock. To have a super- block you must have a file system. To have a file system, newfs(8) or mkfs(8) must be run. On the other hand, chpt(8) should merely give a warning that there isn't one on the disk and get it from the device driver (from an RA81): /dev/rra24c No partition table found in superblock... using default table from device driver. Current partition table: partition bottom top size overlap a 0 15883 15884 c b 15884 49323 33440 c c 0 891071 891072 a,b,d,e,f,g,h d 131404 254396 122993 c,h e 254397 377389 122993 c,h f 377390 891071 513682 c,h g 49324 131403 82080 c h 131404 891071 759668 c,d,e,f If there isn't one in the driver, then chpt(8) won't know where to get it. Actually the same should true of newfs(8). The lack of a partition table on the disk should not be fatal error. Newfs was run on the previous disk which complained of no partition table. Newfs should also get the one from the driver if there isn't one on the disk. Warning: 550 sector(s) in last cylinder unallocated /dev/rra24a: 15872 sectors in 23 cylinders of 14 tracks, 51 sectors 8.1Mb in 2 cyl groups (16 c/g, 5.85Mb/g, 1856 i/g) super-block backups (for fsck -b#) at: 32, 11520, > > At this point I grabbed the Emulex diags tested the controller and the drive. > The diags reported that both where fine. I then reformated the hard drive > figuring that this would replace the partition table. See what I said earlier about the partition table being part of a file system. > > I am posting this on the off chance that someone > may know how to replace the partition table on this drive, or give can > me some idea why Ultrix is munging the partition table after the > first time it accesses the drive. Did the drive previously have a partition table on it? It really should still be there; the file system hasn't changed *that* much since V1.2 (the value of the clean bit/byte has changed a couple of times). Some things to consider and look at. 1. You mentioned that it worked on one system. Why is that system different than the other? 2. To have a partition table you must have a file system on the A or C partition. If the disk doesn't have a partition table on it, a default one is taken from the driver. 3. Does the Emulex drive look like one of ours? Or is it a completely different beast? In V3.x devices are identified by type when the system is configued when they can be determined. My ra24 in the previous examples will be listed as "ra24 at hsc15 slave 24 (RA81)". If your disk is an emulation and the emulation is good enough is should be correctly identified and the default table used. On the other hand, if it isn't an emulation or a good enough emulation, then you'll probably need to modify the driver data tables by hand. If the system are the same, then you must have succeeded for the first and missed something on the 2nd. > > Thanks in advance > > Paul Puglia -- Alan Rollow alan@nabeth.enet.dec.com
grr@cbmvax.commodore.com (George Robbins) (03/03/90)
In article <1990Mar1.180652.13910@cunixf.cc.columbia.edu> puglia@cunixf.cc.columbia.edu (Paul Puglia) writes: > since 1.2. > > The installation worked fine on one system, I was able to create the > special files and newfs the partitions I wanted filesystems on. On the other > system when I went to newfs the first filesystem, I got an error message > saying that there was no partition table in the superblock!! And when > I went to check the what the partition table was with chpt I got an > error message saying that there was no superblock at all. Every chpt option Well, doing a newfs of the a or c partition creates a superblock w/parition table. If there's already something that "looks like" a super-block then it might refrain from doing this. I case of doubt the simple thing to do is just trash the beginning of the drive which should force the newfs to recreate both superblock and parition table - "dd if=/etc/termcap of=/dev/r??a" (where ?? = drive name) is usually pretty effective. I wouldn't be too surprised though if it turns out there is actually some kind of controller or drive related problem - wrong switch settings or wrong geometry. Diagnostics aren't to be trusted... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
wyatt@cfa.HARVARD.EDU (Bill Wyatt) (03/04/90)
> and added the disktab entry for the drive--this disktab entry has worked > since 1.2. > > The installation worked fine on one system, I was able to create the > special files and newfs the partitions I wanted filesystems on. On the other > system when I went to newfs the first filesystem, I got an error message > saying that there was no partition table in the superblock!! And when I'm suprised the 3.1 install munged your superblock, but I've always been able to get newfs to write a partition table out by first doing a newfs on the a partition but telling it the drive is a DEC disk (e.g. RA81). The newfs program sees there's no partition table and, since it's a known DEC disk, installs a partition table and makes a filesystem. I then alter the partitions to the correct layout using chpt and finally remake the filesystems with the correct disktab entry. I've done this using several 3rd-party controllers, among them Emulex. Bill Wyatt, Smithsonian Astrophysical Observatory (Cambridge, MA, USA) UUCP : {husc6,cmcl2,mit-eddie}!harvard!cfa!wyatt Internet: wyatt@cfa.harvard.edu SPAN: cfa::wyatt BITNET: wyatt@cfa Bill Wyatt, Smithsonian Astrophysical Observatory (Cambridge, MA, USA) UUCP : {husc6,cmcl2,mit-eddie}!harvard!cfa!wyatt Internet: wyatt@cfa.harvard.edu SPAN: cfa::wyatt BITNET: wyatt@cfa
stefan@wheaton.UUCP (Stefan Brandle ) (03/07/90)
In article <9947@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: >I wouldn't be too surprised though if it turns out there is actually some >kind of controller or drive related problem - wrong switch settings or wrong >geometry. Diagnostics aren't to be trusted... Closely related, I was reading recently in a book on ethernet implementation by Bill [Something] that according to Bill's law: Diagnostic programs lie. with the corellary (SP?--ran this through `spell' in 4 variants: all rejected) Different diagnostic programs lie differently. My addition is that "The manual is also known to lie." I once went bananas trying to get something working on an RQDX2 only to have somebody point out that the binary jumper settings from the manual were all off by 3 positions. -stefan -- ---------------------------------------------- MA Bell: (708) 260-5019 --------- Stefan Brandle UUCP: ...!{obdient,uunet!tellab5}!wheaton!stefan Wheaton College or stefan@wheaton.UUCP Wheaton, IL 60187 "But I never claimed to be sane!"