Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 May 1996 17:58:21 +0200 (MET DST)
From:      grog@lemis.de (Greg Lehey)
To:        bde@zeta.org.au (Bruce Evans)
Subject:   Re: New disks on 2.1-RELEASE: help
Message-ID:  <199605031724.TAA13099@allegro.lemis.de>
In-Reply-To: <199605030442.OAA15889@godzilla.zeta.org.au> from "Bruce Evans" at May 3, 96 02:42:16 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans writes:
>> So: my question.  Would some kind soul please try this with a SCSI
>> disk they don't mind overwriting.  Please stick very closely to the
>> sequence (or tell me why it's broken :-), since that's what I'm going
>> to write.  Obviously the disk doesn't have to be sd1.
>
>> 1.  Format:
>
>> scsiformat sd1
>
> `cp somejunk /dev/sd1' would be faster.  sd1 should probably be /dev/rsd1.

Yes.  As Joerg pointed out, scsiformat isn't part of the 2.1 release.

>> 2.  fdisk -u sd1
>
> sd1 should certainly be /dev/rsd1.

Works fine as sd1, and that's the way it's documented:

     The final disk name can be provided as a `bare' disk name only,
     e.g.  `sd0', or as a fully qualified device node under /dev. If
     omitted, the disks `wd0', `sd0', and `od0' are being searched in
     that order, until one is being found responding.

>> Put at least 2 partitions in.
>                 ^^^^^^^^^^ slices :-)

OK :-)

> Including at least one FreeBSD one.  Otherwise the device used in step 3
> won't exist.  Step 3 would still work if you give the slice name (sd1s1,
> sd1s2, ...) in step 3.

Correct.

>> 3.  disklabel -w -r sd1 <tag>
>
>> <tag> is a tag in /etc/disktab.  If you don't have one for your disk,
>
> Use `disklabel -R -r sd1 <file>' to avoid mucking with /etc/disktab.

There's small choice in rotten apples.  I'll describe both ways, if I
ever get either one to work reliably.

> <file> can be created by editing the output of `disklabel /dev/rsd1'.

OK.  I've tried both ways, I've installed 2.1-RELEASE, and it just
plain does not work.  There's every possibility I've made an incorrect
turn in the minefield, but this isn't the first time I've done this
(the first time was about 4 years ago with BSD/386 0.3.1).  I believe
we have multiple breakages here.  But first to your next point:

>> Back to the problem:  disklabel issues an ioctl (DIOCSDINFO) against
>> the raw disk, and then checks the return value.  disklabel.c:408:
>
>> 		if (ioctl(f, DIOCSDINFO, lp) < 0 &&
>> 		    errno != ENODEV && errno != ENOTTY) {
>> 			l_perror("ioctl DIOCSDINFO");
>> 			return (1);
>> 		}
>
>> In the -current kernel, this ioctl returns an EINVAL when issued
>> against a disk with an invalid label.  I changed this to:
>
>> 		if (ioctl(f, DIOCSDINFO, lp) < 0 &&
>> 		    errno != ENODEV && errno != ENOTTY && errno != EINVAL) {
>> 			l_perror("ioctl DIOCSDINFO");
>> 			return (1);
>> 		}
>
> This is wrong.  EINVAL usually means that the supplied label is invalid.
> It sometimes means that the wrong device is being labelled, but this case
> should be rare because `disklabel sd1' always uses the correct partition
> (sd1c).

Why is this wrong?  At this point, the label *is* invalid.  The point
of the exercise is to make a valid one.

> I'd better change some ENODEV's to EINVAL's to stop disklabel from ignoring
> fatal errors :-(.  DIOCSDINFO /dev/rsd1 doesn't make sense, so it seemed like
> a good idea to return ENODEV for it.  (You have to label the logically
> different device /dev/rsd1c even if you want to use the whole disk for BSD.)

I don't understand this.  We're currently getting EINVAL, not ENODEV.
Did you mean to say this the other way round?  And the way I see it,
sd1, sd1c and /dev/rsd1c are the same thing: if I do a

  # ktrace disklabel -w -r sd1c cdc94161
  # kdump
  ... lots of junk
  230 disklabel RET   execve 0
  230 disklabel CALL  open(0x1c368,0x2,0xefbfd464)
  230 disklabel NAMI  "/dev/rsd1cc"
  230 disklabel RET   open -1 errno 2 No such file or directory
  230 disklabel CALL  open(0x1c368,0x2,0x1c368)
  230 disklabel NAMI  "/dev/rsd1c"
  230 disklabel RET   open 3
  ... lots more junk

Evidently disklabel prepends a /dev/r and first tries to postpend a c
to the name.

----------------------------------------------------------------------

OK, back to my problems.  First, I don't see that /etc/disktab or
~/mydiskinfo have much in the way of advantages against each other.
I'm trying to (and occasionally succeeding in) adding a "CDC 94161-9
6226" type 0 fixed SCSI 1 as /dev/sd1 shared between DOG and FreeBSD.
I have no problems (apart from this damn interactive business) making
the partition table, which has two valid entries:

Partition     Type   Offset
1	      DOG    1
2	      BSD   99540

fdisk says:

   The data for partition 0 is:
   sysid 6,(Primary 'big' DOS (> 32MB))
       start 1, size 99539 (48 Meg), flag 0
           beg: cyl 0/ sector 2/ head 0;
           end: cyl 315/ sector 35/ head 8
   The data for partition 1 is:
   sysid 165,(FreeBSD/NetBSD/386BSD)
       start 99540, size 205065 (100 Meg), flag 80
           beg: cyl 316/ sector 1/ head 0;
           end: cyl 966/ sector 35/ head 8

Let's look at the problems with /etc/disktab first.  I created an
entry

   cdc94161|CDC 94161-9: \
	:ty=winchester:dt=SCSI:se#512:nt#9:ns#35:nc#967:rm#3600:\
	:ob#99540:pb#40950:tb=swap:\
	:oc#99540:pc#205065:\
	:oh#140490:ph#164115:tb=4.2BSD:

After formatting or copying /dev/zero, I fdisk as shown above.  Then I
do:

    # disklabel -w -r /dev/sd1c cdc94161
    disklabel: ioctl DIOCSDINFO: Label magic number or checksum is wrong!
    (disklabel or kernel is out of date?)

This is what I reported yesterday under 2.2-current.  It's just the
same under 2.1-release.  My fixed version works under either version.
So I did that:

    # disklabel-fixed -w -r sd1c cdc94161
    # disklabel-fixed -w -r sd1c cdc94161
    disklabel: ioctl DIOCSDINFO: Open partition would move or shrink

The only way I have found to get this problem to go away is to
overwrite the beginning of the partition:

    # dd if=/dev/zero of=/dev/rsd1 seek=99540 obs=512 count=100
    100+0 records in
    100+0 records out
    51200 bytes transferred in 1 secs (51200 bytes/sec)
    # disklabel-fixed -w -r sd1c cdc94161
    # disklabel-fixed -w -r sd1c cdc94161
    disklabel: ioctl DIOCSDINFO: Open partition would move or shrink

There's obviously something broken here.

OK, you wanted me to use the proto version.  So let's look at that.  I
did:

    # disklabel /dev/rsd1 >diskproto
    Warning, revolutions/minute 0
    boot block size 0
    super block size 0
    # cat diskproto
    # /dev/rsd1:
    type: unknown
    disk: 
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 35
    tracks/cylinder: 9
    sectors/cylinder: 315
    cylinders: 967
    sectors/unit: 304605
    rpm: 0
    interleave: 0
    trackskew: 0
    cylinderskew: 0
    headswitch: 0           # milliseconds
    track-to-track seek: 0  # milliseconds
    drivedata: 0 
    
    3 partitions:
    #        size   offset    fstype   [fsize bsize bps/cpg]
      c:   304605        0    unused        0     0         # (Cyl.    0 - 966)

I'd say this is broken, too.  From the various complaints I've seen
from disklabel, slice c needs to be inside the FreeBSD slice.  Here,
it's given the whole disk.  OK, I modified this, and created:

    8 partitions:
    #        size   offset    fstype   [fsize bsize bps/cpg]
      b:    40950    99540    swap          0     0       	# (Cyl.  316 - 445)
      c:   205065    99540    unused        0     0       	# (Cyl.  316 - 966)
      h:   164115	140490    4.2BSD        0     0       	# (Cyl.  446 - 966)

When I try to create the file system, I get (sing along with me)

    # dd if=/dev/zero of=/dev/rsd1 seek=99540 obs=512 count=100
    100+0 records in
    100+0 records out
    51200 bytes transferred in 2 secs (25600 bytes/sec)
    # disklabel -R -r sd1 diskproto
    disklabel: ioctl DIOCSDINFO: Label magic number or checksum is wrong!
    (disklabel or kernel is out of date?)
    # disklabel-fixed -R -r sd1 diskproto
    # disklabel-fixed -R -r sd1 diskproto
    disklabel: ioctl DIOCSDINFO: Open partition would move or shrink

In summary, I'd say that disklabel is broken, whichever way you want
to look at it.  OK, it's also not exactly a good tool, but it's all we
have on the 2.1 CD-ROM.  I think we can get by with my version (and,
as I said before, I think that disklabel is broken, not the return
codes from the drives), but that doesn't help much: I'm describing
this for people using the 2.1 CD, and they need to be able to do it
with the software on the CD.  If you have any bright ideas, I'd be
very grateful.

----------------------------------------

Other problems encountered along the way:  if I make a partition too
large, I get:

   # disklabel -R -r sd1 diskproto
   write: Read-only file system

At the same time, the console claims:

   May  3 19:10:48 daemon /kernel: fixlabel: raw partition size > slice size
   May  3 19:10:48 daemon /kernel: fixlabel: raw partition offset != slice offset

Greg




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605031724.TAA13099>