[comp.unix.ultrix] How to replace a partition table

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!"