Adding a second hard drive SCO Xenix, Open Desktop, Openserver

This article references SCO SCO Xenix, Open Desktop, Openserver specifically. See Linux/adddrive.html for adding a Linux drive.

You add a hard drive, and configure the file systems on it, by running "mkdev hd".

People used to older Unices may expect more complications, and may expect to have to use "mkfs" after hand editing kernel configuration files to add the appropriate block and character devices. You certainly can do all that if you want, but "mkdev hd" is a front end that makes it much easier. If you are curious as to what goes on behind the scenes, look in /usr/lib/mkdev. The "hd" command there is a shell script, and is fairly self-explanatory.

You generally have to run 'mkdev hd' twice. If I remember correctly, the kernel already has the code for the second IDE drives, so in that case it's only once. But for SCSI drives, the first invocation puts the driver code in, and the second (after a reboot) allows the partitioning and division of the drive.

For SCSI drives, the first pass asks you the name of the SCSI controller. If you don't know, and if your primary drive already is SCSI, look in /etc/conf/cf.d/mscsi. The end of the file might look something like:

wd      Srom    1       0       0       0
asc     Sdsk    0       0       0       0
asc     Sdsk    0       4       0       0
 

(This happens to be a machine with an EIDE cdrom and a scsi disk using an "asc" controller, plus a second scsi disk at ID 4). You'll also be asked about which controller (if you have only one, it's "0"), what bus (probably 0) and the target ID. and the lun (almost always "0").

There are twin-channel controllers: for these, one is controller "0", the other is "1". You can follow the internal cables to see which one your drive is connected to.

If you aren't sure what SCSI devices are present, the "sconf" command can help you on modern systems. Prior to OSR5.0.5, this existed but could crash your system in multiuser mode, but now is safe. Here's the output of "sconf -v" on one of my machines:

Sdsk    alad    0       0       0       0
Sdsk    alad    0       0       1       0
Stp     alad    0       0       3       0
Sdsk    alad    0       0       4       0
Srom    alad    0       0       6       0
 

For example, this tells me that a tape drive (the Stp line) is attached to an alad controller, and (reading left to right), it's alad unit 0, on bus 0, at id 3 and lun 0.

After answering these questions, the kernel is relinked. Be sure to answer "Y" to "Rebuild the Kernel Environment", and be sure you understand what that question means (if you don't, make a copy of /etc/inittab before you begin this process). You do have to reboot before proceeding to the next step. You then run 'mkdev hd' again, and answer the same questions.

If you got it wrong:

If you guessed wrong about the controller, bus, or ID, you won't get the screens that ask about the partitions. If that's the case, don't use mkdev hd, simply go directly to /etc/conf/cf.d/mscsi, make the corrections, and link a new kernel. The controller is the first column after Sdsk, the ID is the second, then lun and bus. Simply change the appropriate column, and then relink.

If you don't feel comfortable with that, at least vi mscsi to remove the line that represents the error. Once you've got that correct, 'mkdev hd' will proceed to the second phase, where you create the Unix partition and then divide it into one or more filesystems.

During that second phase, you are asked if you want "block by block control". If you answer that affirmatively, you get to control everything about the division(s) created, including the name(s).

If you have existing data

You may want to transfer an existing disk to another system, as for an upgrade. The procedure is the same, but do NOT change the partition info, do NOT change the bad track table, and do NOT create new filesystems. You'll see your divisions; all you need to do is (n)ame them and proceed from there.

If you don't, an arbitrary (e.g. "d1150" ) name is generated. It's not actually completely arbitrary: it is related to the drive number and its id if scsi. I think it's been documented somewhere, but I never pay attention to it because:

• You can name the divisions sensibly
• You can always find out what someone else named them

The "finding out" can be accomplished by using 'divvy' on the appropriate device. "man HW hd" gives tables of drive names, and from that it's easy to find out /dev/hd1a will represent the second physical disk. Therefor, 'divvy -P -N /dev/hd1a' will print out info about the divisions, including the names.

Or, you can use divvy interactively, leaving out the -N and -P. By doing this, you can even change the name to something more sensible. I like to use names that are reminiscent of the mount points, so my Jaz drive has a division 'jaz', which creates a /dev/jaz, which I mount at /jaz.

Note here that the second pass of "mkdev hd" will have invoked divvy for you: you don't need these commands unless you need to get back to the divvy tables after this. Note also that if you already know the name of the division (such as /dev/u), you can get there with "divvy /dev/u"

You may want to creat multiple partitions. See Adding disk space for suggestions.

Mount

For some reason, there is no mention of 'fs' in the man page for 'mkdev', but it's been in /usr/lib/mkdev for a very long time. It asks the appropriate questions, and if you give it appropriate answers, it will create the appropriate entry in /etc/default/filesys.

You get asked for the device name. Answer that with the name of the division. You are then asked for a mount point, and finally you are asked if you want to always mount this filesystem. Generally, you'll answer yes to that.

If you told it to "always mount", you can then mount it by any of "mountall", "mount /mount_point", or by rebooting.

For ideas about what to do with this extra space see Adding disk space.

See also:

• Filesystems
• 
  

  
  

  © 1998 A.P. Lawrence. All rights reserved
  
  
  
  

  
  Click here to add your comments
  
  Wen we needed to transfer data from one hard drive to the other we consulted with these guys and they helped. http://www.dataleach.com
  
  
  
  
  
  
  
  Tue Nov 17 11:02:40 2009: Subject:   JohnPierpoint
  
  
  Thanks for the article. Tried to use it to mount an existing data drive back onto a server that has had to have a new OS drive and SCO re-installed.
  All appeared to go reasonably OK, but somewhere along the line, despite taking every precaution, it seems to have wiped the whole lot.
  I hate UNIX. . .
  
  
  
  Tue Nov 17 11:46:26 2009: Subject:   TonyLawrence
  
  
  I'm sorry that happened.
  
  The article that fully deals with that is http://aplawrence.com/SCOFAQ/FAQ_scotec6recoverdrive.html. It's possible that your drive really is not wiped; I suggest reviewing that article,
  
  
  
  Tue Nov 17 12:52:11 2009: Subject:   JohnPierpoint
  
  
  Tony,
  Thanks for (quick!) response and the link to the other article at http://aplawrence.com/SCOFAQ/FAQ_scotec6recoverdrive.html.
  I'm reading through that now. . .
  I had already given up and started a restore of data from the last backup tape, but that failed with error "No space left on device (error 28)", which suggests that somehow I've managed to mount a FS on the wrong physical disk (presumably the smaller boot HDD), so you are probably right: the data may still be intact on the original data disk. I just need to figure out how to get SCO to see it!
  I've practised restores like this during assisted DR sessions on clean servers with very large single HDDs, but this one is on the original hardware with a 2GB boot HDD (which was failing - now replaced) and a 9GB data HDD, both on the same SCSI controller, one on ID 0, the other on 1. All other SCSI settings are 0.
  During the OS reinstall to the new boot HDD, I deferred the setup of the 2nd HDD, afraid that it would just wipe the whole lot.
  After reading the article, I then ran mkdev hd and quit out of the options to change the partitions. The 2nd disk reported as having a division called hd1a.
  mkdev fs didn't succeed (couldn't find /dev/hd1a), and neither did the similar process in SCOadmin, but I found the target mount point (/user/MENTOR) in the filesystem anyway. Not sure how that happened!
  mkdev didn't prompt for a kernel re-link (although it did when I put the tape drive on later), so I'm obviously
  I might go back to square one and re-install SCO from scratch on the boot HDD. If I did that, are there any settings I could use in the SCO install process to make sure it picks up the data HDD painlessly without overwriting the data?
  I still hate UNIX, but at least with sites like this around, us UNIX newbies stand a fighting chance of fixing things!
  
  
  
  Tue Nov 17 13:10:51 2009: Subject:   TonyLawrence
  
  
  It's not going to wipe it out unless you tell it to, so don't worry about that.
  
  You may be seeing geometry issues - pay attention to that part.
  
  
  I am on my way out to a customer so won't be able to respond again until late today or tomorrow.
  
  Don't miss responses! Subscribe to Comments by RSS or by Email
  
  Click here to add your comments
  
  If you want a picture to show with your comment, go get a Gravatar
  
  
  
  Why no "Digg this!" etc.?
  
  
  
  

  Learn Mac OS X Command Line

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.