Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!elroy.jpl.nasa.gov!ames!haven!decuac!shlump.nac.dec.com!shodha.dec.com!alan From: alan@shodha.dec.com ( Alan's Home for Wayward Notes File.) Newsgroups: comp.unix.ultrix Subject: Re: How to replace a partition table Summary: There are two partition tables. Message-ID: <793@shodha.dec.com> Date: 2 Mar 90 07:21:45 GMT References: <1990Mar1.180652.13910@cunixf.cc.columbia.edu> Organization: Digital Equipment Corp. - Colorado Springs, CO. Lines: 98 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