Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 04 Mar 2001 09:04:42 -0800
From:      richard childers <fscked@pacbell.net>
To:        Doug Poland <doug@polands.org>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: SCSI disks / disklabel / vinum
Message-ID:  <3AA275AA.988DAC1C@pacbell.net>
References:  <20010303150356.B29412@polands.org>

next in thread | previous in thread | raw e-mail | index | archive | help
I'm just guessing here, because I have no experience with vinum ... but a lot of experience
with entries in /dev.

Note that it is complaining that it cannot open devices '4' and '5'; whereas you complain that seem to be limited to
only 4 devices (which naturally correspond to devices 0, 1, 2, and 3); what you need is to create those corresponding
devices (actually, they aren't devices, they are a handle on major and minor device numbers, which are used to select
the actual device and the appropriate behavioral subset, in the kernel ... or, that's how it was last time I looked
:-).

The way these devices are traditionally created is with a script called MAKEDEV, found in /dev. So you do something
like (DON'T DO THIS WITHOUT READING THE ENTIRE MESSAGE!!):

    # cd /dev
    # ./MAKEDEV passN

... where N equals the actual number of 'passthrough' devices you need; in your case, I think the number would be '6'.
This would create /dev/pass0 .. /dev/pass5.

What's really happening? Well, you can read about it by reading /dev/MAKEDEV; this is a shellscript (or it was last
time I looked) that parses the arguement you pass it and translates it into a sequence of mknod(8) invocations that
create the /dev entry. I won't spoil the ending for you, I'll just refer you to MAKEDEV and mknod(8); but if you have
further questions, this is the place to send 'em.

I'll freely repeat I know nothing about vinum; haven't used it yet. I *do* have experience with a variety of other,
similar software- and hardware-based RAID solutions; the information above is applicable to all of them.

It's possible that MAKEDEV does not yet support the 'pass' device, in which case you would have to create the
corresponding entries by hand. Judicious study of the output from an `ls -ld` of the corresponding /dev/pass* entries,
combined with a careful reading of the mknod(8) manual page, should provide you with everything you need to be
dangerous.  (-;

(Great, mutter the adminuistrative masses, now we have to look for surreptitious /dev entries. But weren't you doing
so, already? No? Good thing I brought it up.)


(Separately, we predict that someone will discover this "vulnerability" and use it to leverage their sagging reputation
as a UNIX administrator, some time in the next few weeks; but remember you read it here first ... and, who knows, maybe
this paragraph will cause them to pause. :-)


-- richard


Doug Poland wrote:

> Hi,
>
> I'm putting together a vinum disk subsystem.
> For testing I started out with 4 SCSI disks
> and built a stripped plex and everything
> worked great.  This config had 2 drives
> in the chassis and 2 drives in an external
> case.
>
> So I get a 4-connector SCSI cable for the
> chassis and add two more SCSI drives (that
> I've previously formatted and put ufs on).
> FreeBSD 4.2-STABLE boots and recognizes
> all the drives (see dmesg at end).
>
> When I edited the disklabel (disklabel -e da4)
> I didn't see the
>         (e: ....  4.2BSD  ...)
> setting under "unused".  I thought that odd
> because I've previously formatted, partitioned,
> labeled, mounted, and tested every drive.
>
> So I thought I'd let sysinstall have at it
> put ufs on again, just to make sure.  So
> I redo the partitioning and labeling and
> I still have vinum running on 4 disks and
> the two new ones are mounted separately.
> I went to disklabel again and still no
> 4.2BSD setting.
>
> So now I think it must need to be re-
> formatted.  So I fire off camcontrol
>
>         #camcontrol format da4; camcontrol format da5
>
> and see:
>
> camcontrol: cam_real_open_device: couldn't open passthrough device /dev/pass4
> cam_real_open_device: No such file or directory
> camcontrol: cam_real_open_device: couldn't open passthrough device /dev/pass5
> cam_real_open_device: No such file or directory
>
> Now I'm really confused!  Why can I not see the
> 4.2BSD disklabel?  Until I can set that, I won't
> be able to create a vinum volume.  Ultimately
> I want a 7 drive vinum volume but cannot get past
> 4 drives.
>
> Your help is greatly appreciated...
>
> --
> Regards,
> Doug
>
> dmsg snippits:
> FreeBSD 4.2-STABLE #0: Sat Mar  3 08:57:02 CST 2001
>     root@judeah.polands.org:/usr/obj/usr/src/sys/GENERIC
> Timecounter "i8254"  frequency 1193182 Hz
> CPU: Overdrive Pentium/P55C (180.00-MHz 586-class CPU)
>   Origin = "GenuineIntel"  Id = 0x1543  Stepping = 3
>   Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
> ...
> ahc0: <Adaptec 2940A Ultra SCSI adapter> port 0xf800-0xf8ff mem 0xfedfe000-0xfedfefff irq 10 at device 13.0 on pci0
> aic7860: Single Channel A, SCSI Id=7, 3/255 SCBs
> ...
> (ahc0:A:0:0): refuses synchronous negotiation. Using asynchronous transfers
> (ahc0:A:1:0): refuses synchronous negotiation. Using asynchronous transfers
> (ahc0:A:2:0): refuses synchronous negotiation. Using asynchronous transfers
> (ahc0:A:3:0): refuses synchronous negotiation. Using asynchronous transfers
> (ahc0:A:4:0): refuses synchronous negotiation. Using asynchronous transfers
> (ahc0:A:5:0): refuses synchronous negotiation. Using asynchronous transfers
> da0 at ahc0 bus 0 target 0 lun 0
> da0: <IBMRAID 0664M1H9337 5 58> Fixed Direct Access SCSI-2 device
> da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
> da0: 1920MB (3933040 512 byte sectors: 255H 63S/T 244C)
> da1 at ahc0 bus 0 target 1 lun 0
> da1: <IBMRAID 0664M1H9337 5 58> Fixed Direct Access SCSI-2 device
> da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
> da1: 1920MB (3933040 512 byte sectors: 255H 63S/T 244C)
> da2 at ahc0 bus 0 target 2 lun 0
> da2: <IBMRAID 0664M1H9337 5 58> Fixed Direct Access SCSI-2 device
> da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
> da2: 1920MB (3933040 512 byte sectors: 255H 63S/T 244C)
> da3 at ahc0 bus 0 target 3 lun 0
> da3: <IBMRAID 0664M1H9337 5 58> Fixed Direct Access SCSI-2 device
> da3: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
> da3: 1920MB (3933040 512 byte sectors: 255H 63S/T 244C)
> da5 at ahc0 bus 0 target 5 lun 0
> da5: <IBMRAID 0664M1H9337 5 58> Fixed Direct Access SCSI-2 device
> da5: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
> da5: 1920MB (3933040 512 byte sectors: 255H 63S/T 244C)
> da4 at ahc0 bus 0 target 4 lun 0
> da4: <IBMRAID 0664M1H9337 5 58> Fixed Direct Access SCSI-2 device
> da4: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
> da4: 1920MB (3933040 512 byte sectors: 255H 63S/T 244C)
>
> camcontrol:
> #camcontrol devlist -v
> scbus0 on ahc0 bus 0:
> <IBMRAID 0664M1H9337 5 58>         at scbus0 target 0 lun 0 (pass0,da0)
> <IBMRAID 0664M1H9337 5 58>         at scbus0 target 1 lun 0 (pass1,da1)
> <IBMRAID 0664M1H9337 5 58>         at scbus0 target 2 lun 0 (pass2,da2)
> <IBMRAID 0664M1H9337 5 58>         at scbus0 target 3 lun 0 (pass3,da3)
> <IBMRAID 0664M1H9337 5 58>         at scbus0 target 4 lun 0 (pass4,da4)
> <IBMRAID 0664M1H9337 5 58>         at scbus0 target 5 lun 0 (pass5,da5)
> <  >                               at scbus0 target -1 lun -1 ()
> scbus-1 on xpt0 bus 0:
> <  >                               at scbus-1 target -1 lun -1 (xpt0)
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message

--
Richard A. Childers
Senor UNIX Administrator
fscked@pacbell.net (email)
203.556.8471 (voice/msgs)

# Providing administrative expertise (not 'damage control') since 1986.
# PGP fingerprint: 7EFF 164A E878 7B04 8E9F  32B6 72C2 D8A2 582C 4AFA



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AA275AA.988DAC1C>