Conference turris::digital_unix

8865.0. "non-Digital disks and DU 4.0 ?" by VAXBOX::NORDSTROM (A Swedish Viking) Tue Feb 18 1997 07:00

	Hi ,

	this note is concerning the same problem as in note 8561 but
	I have a lot more information this time so perhaps You guys that 
        know this stuff can give me an answer without having to do so 
        much research.
    
    
    Question concerning non-Digital system disk in a dUNIX 4.0 system.
    
    A customer reports that in 4.0 he is not able to use a DSP disk as a 
    system disk.
    
    We *know* that DSP disks is not mentioned in the SPD at all (and have 
    also told the customer this), but they have used these disks in dUNIX 
    3.X without problem and he wants to know if they, or we, could do 
    something so that they are able to use them in 4.X versions.
    
   
    Technical details:
    
    Alphastation 255.
    
    When he installs 4.0 from CD he get's an error message when the 
    installation script is about to create a UNIX file system, ufs, on the 
    disk.
    
    'newfs -F /dev/rrz0a dsp3105s, disklabel for /dev/rrz0a could not be 
    updated, quiting'
    
    (Installing on a dUNIX supported disk works fine...)
    
    As said earlier an installation of a 3.X version of Digital Unix was fine
    using the same disk.
    
    It would be a very good thing if someone could explain what has been 
    changed in Digital Unix 4.0 that prevents non-Digital system disks to 
    be used. I did have a look in Comet and found the following that seems
    related:

The case from COMET:

Hi,

We are having problems getting an Iomega Jaz (1GB removable) to
take a disklabel under DU 4.0 (and 4.0a) on our AS255's.  The
disk we are working with is not one of the Jazz Tools disks, so
it does not seem to be a disk lock problem.  We have tried adding
entries to the /etc/disktab but keep getting errors when we try
to do a:

   disklabel -rw /dev/rz6c jaz

   jaz: unknown disk type

The last disktab entry we tried was (from a posting to this group):

   jaz|iomega jaz:\
           :ty=winchester:dt=SCSI:ns#130:nt#5:nc#3217:\
           :oc#0:pc#2091050:bc#8192:fc#1024:

The drive is also not recognized by the GUI disk partitioning
application that came with DU4.0

The drive is seen normally at the console prompt, and we have booted
to genvmunix and rebuilt the kernel to pick-up the new hardware.

We can dd the disklabel off of an rz26f onto the jaz drive and the
drive will then allow itself to be partitioned and work normally.  I
am a little concerned about using a fully populated disklabel with a
disk that may have a wildly divergent configuration.

While messing about, we tried dd'ing an rz26f disklabel to the disk
and then zeroing it out (on the assumption that there may have been
(random) data in the disklabel area that was giving us grief.  After
zeroing the label, the drive goes back to being unlabelable.  We have
also tried doing a reformat of the disk with scu, but nothing changed.

A querry on the alpha-managers mailing list turned up two confirmations
of this problem under 4.0 and an explanation of what the the problem
is belived to be:

        There is (what I think is) a bug in the V4.0 disklabel
        that prevents it from using a disktab entry from over-
        riding the geometry and capacity information returned
        from the DEVGETGEOM I/O control.  Or more precisly, not
        letting disktab override what isn't returned from
        DEVGETGEOM.  For well behaved SCSI devices, DEVGETGEOM
        will get the geometry from the device.  The JAZ drives
        do not seem to be well behaved and don't put their
        geometry in the expected place (if at all).

        Before V4.0, DEVGETGEOM would have only been used when
        a disktab entry didn't exist, but that was switched and
        the bug added along the way.

Is there a patch to fix this yet?  It would be nice to be able
to use /etc/disktab rather than rolling disklabels by hand and
dd'ing them to the disk.

Tom
N:0002
\+-----------------------  Beginning of Screener's Text -----------------------+


I am not sure that the Jaz drives are even supported under dU vs 4.0 and
4.0a, but have you tried issuing a "disklabel -rw rz? rzxx", where rz? is
the entry appropriate for the slot the Jaz drive occupies?  The rzxx tells
disklabel to autodetect the geometry of the disk.

Alexander

===================================================


N:0003

Please enter your information :

Alexander,

Yes we have tried auto-detecting the geometry and even trying
to write known DEC labels (i.e. rz26f) to the disk (in addition
to our added entry for the jazz disk).

The problem is that the Jazz drive either does not return any
geometry at all or returns it in a manner that DU disklabel
can't parse.  With the older version of disklabel, which
shipped w/ 3.2x, disklabel would blindly label the disk when
given a drive type.  The new version apparently does a
check of the drive geometry, I would guess to prevent you
from accidently writing an rz29 label to an rz28.

This isn't a bad feature in itself, but it drastically limits
disklabel's usefulness with a lot of the 'not-quite-supported'
devices that are in use in computer rooms around the world
-- esp. Iomega's Zip and Jaz drives.  These drives come in
VERY handy for data exchange and places where you need
removable drives, like storing tripwire databases in a secure
location beteen runs, which are too big for floppies and
don't justify the cost of of an RWZ52.

(The RWZ52 and floppies were the closest things to removable
drives, other than tape, that I could find in my last
Systems and Options Catalog (Nov 96).)

I'm not trying to say that DEC needs to 'support' these drives,
but the change to the disklabel utility makes it darn-near
impossible for sites to use these drives.  What I would like
to see is either a patch that restores the old behavior, applied
at the SysAdmin's own risk, or an over-ride flag that can be
passed to disklabel.  I'm really just looking for the same
functionality we had in prior versions of DU.

In the meantime, the only way to label these disks is to:

* dd the first meg or so (just to be safe) of another disk to
  the Jazz drive.  We happen to have some rz26's which are
  smaller (~50mb) than the Jazz drive but the label seems to
  work without any modifications.  Disklabel will then allow
  you to bring the label up for editing.

* Save a copy of a label from another disk, modify it to fit
  the Jazz drive, and write it to the Jazz disk with
  "disklabel -R".  (I haven't tried it myself, but an Admin
  at another site claims it works.)

* Label the disk on a DU 3.2x system.

The first two 'solutions' go totally against the idea of
/etc/disktab and are a lot more error prone.  The third
would require keeping a 3.2x system around and purchasing
extra drives for that system (taking two systems down to
disconnect and transfer drives, just to label disk is a
little silly).

Making UNIX a little safer for the general public is a nice
goal, but not when it gets in the way of getting things done.

Tom
N:0004


x31511
N:0005
===
Yes we have tried auto-detecting the geometry and even trying
to write known DEC labels (i.e. rz26f) to the disk (in addition
to our added entry for the jazz disk).
===

I've done some research on the subject over the past bit and it doesn't
look like the Jazz drives are supported under dU 4.0+.  I can elevate the
call to Engineering, but its most likely they'll refer you to the
Jazz-drive folks for a driver or offer to write a custom driver for the
device for a fee.

Alexander

The questions are, do You think the above case from Comet is the same 
problem that my customer has ?

Is the problem in the case from Comet being addressed ?

	All info provided is MUCH appreciated, regards Richard    

My guess based on this information is that the device does
NOT supply any geometry information.  We broke disklabel in
V4.0 when it comes to using disktab to override the devices
default geometry.  That is why a new disktab entry isn't
working.

The workaround is just what was explained.  Use dd to copy
the first 16-32k off of a working disk; then use disklabel -e
to fix the label to what it should be.  Once there is a label
there, you can fix it, you just can't put one there in the
first place.

The other change we made was to add kernel code to fake some
device geometry if the device doesn't have any to report to
us.  This fix also prevents the problem in disklabel, since
all scsi devices now have geometry (either real, or fake).

This last change (faking the geometry) could be made available
as a patch if you want to submit an IPMT case.  The disklabel
change can't be easily done as a patch (since it impacts libc
and therefore MANY other utilities).

One other point, is that no patch will impact what installation
can do until we release a new kit with these corrections.
Sorry.

	Fred Knight

Hi Fred !

Thank You for responding to my note. You gave an very 
informative answer. There is one statement I am wondering 
about though. 

First You say:

> The other change we made was to add kernel code to fake some
> device geometry if the device doesn't have any to report to
> us.  This fix also prevents the problem in disklabel, since
> all scsi devices now have geometry (either real, or fake).

I interpret the above like this was a change done in DU4.0 but
then You say:

> This last change (faking the geometry) could be made available
> as a patch if you want to submit an IPMT case.  The disklabel
> change can't be easily done as a patch (since it impacts libc
> and therefore MANY other utilities).

Wasn't it in DU4.0 ? Is the patch already available ?
And then You say:

> One other point, is that no patch will impact what installation
> can do until we release a new kit with these corrections.
> Sorry.

Does this mean that You are working on a correction ? And in that 
case, do You know in what release it will appear ?

Regards, Richard

    A software partner reports that after using dd to copy a label to the
    jazz disk he then runs newfs. newfs seems to to be able to get info
    from the disk and correct the label without editing.
    
    Marvin Davis
    

The fake geometry code was added to what is known as the
PTmin release (V4.0D).

The disklabel/libc change to allow disktab to override a
devices physical geometry is in steel.

	Fred Knight

    Hi !
    
    Thanks a lot for your information, I will talk to the customer 
    and see where it leads us.
    
    Regards, Richard