Andy's Unix FAQ

Solaris Devices

The console, Hard disks


Unix FAQ Menu
Contents
Basic commands
Cron
Creating CDs
Device Files
DHCP server (Solaris)
Filesystem explained
Fsck
grub/lilo vanished!
Linux applications?
Linux databases?
Linux distributions
Serial Console
Solaris devices
Solaris disks - Intro
Solaris disks - Adding
Solaris x86 install
SQL/Shell script
Syslog/Monitoring
Time Synchronisation.
Virtual Memory
Web Multi-Language
Web Server Errors
Humour
Unix a Prank



 

The Console

Under Solaris the console is refered to by the generic device /dev/console. The physical devices(s) this actually relates to varies according to whether the keyboard was attached when the system was last switched on. It is NOT possible to change this whilst the system is running. Under no circumstances attach a keyboard whilst the system is switched on - the PS/2 connector carries power and thus such action may cause physical damage and will crash the system.

If the keyboard was attached then input to /dev/console comes from /dev/kb, this is the PS/2 style connector on the main system board. Output is to the the framebuffer (/dev/fb)

If there was no keyboard attached input and output is via the first on-board serial (RS232) port - /dev/term/a. Physically this usually consists of a 25-pin D-type female connector on the main system board and is marked 'Serial A'. The serial configuration can be changed using Openboot commands but is usually 9600 Baud, 1 stop bit, and no parity.

Solaris will react to a RS232 break signal on it's console port by suspending the Unix kernel and dropping to an Openboot 'ok' prompt. The signal is typically sent when an RS232 device is powered up. Thus it is wise to power such a device on BEFORE connecting the serial cable. There is no power carried by a standard 3 or 5 wire RS232 cable. If you forget to do this and find yourself with a halted system and an 'ok' prompt, type 'go' to the OpenBoot 'ok' prompt and your system should continue running, thus;
    ok go

Advice and tips


Solaris will generally boot and run quite happily without any console device at all. The temptation thus is not provide or connect any console device. I urge caution on this point.

One day you will need a console on your Solaris system, one day the power will fail, or someone will accidently disconnect the power. When this happens you may well be left with a Solaris system in single user mode most likely waiting at an fsck prompt and no way to interact with it. Most likely also will be a constantly ringing telephone with irrate users on the other end.

I advise you therefore to always keep some serial device permanently in the vicinty of your Solaris system(s). This should be accompanied by a serial cable and a power cord, and possibly a notice warning of dire consequences should anyone remove them. A laptop PC even a PDA may suit the task, but by far the best device is a simple old dumb terminal - a DEC VT100 is perfect. The temptation to remove a laptop in times of need is great, a dumb terminal is however of little use elsewhere.

Large sites with many Solaris system to administer often connect the serial console port to a terminal server. This allow remote access to the console via the network. This is a convenient approach but does have its hazards;

Security:
Solaris by default allows direct 'root' logins to the console, but not elsewhere. This behaviour is controlled by the CONSOLE variable in /etc/default/login.
Power failures:
Terminal servers will send a break signal down ALL their serial ports at power up. So if for example your Solaris servers are connected to a UPS then you should ensure that the terminal server is similarly protected.


Disk Devices

Disk device files are probably the most involved and difficult to understand of all Unix devices. Understanding a few key points will help a lot;

  • A disk device file usually refers to a particular partition (aka "slice") of a disk, and not the whole physical device. There are device files which refer to the entire physical device, but they are rarely used.
  • There are usually TWO device files for every disk device - the Block device and the Character ("raw") device. Generally the block device is used for filesystem type access (e.g mount(1m)) and the character device for everything else - fsck(1m), newfs(1m), etc..
  • Discs are usually attached to a controller / bus which can handle multiple devices - SCSI and IDE are common attach methods. This fact tends to make disk device filename more complex than other types of devices.

Consider this /etc/vfstab entry for a single filesystem on a Solaris machine;
    /dev/dsk/c0t1d0s6 /dev/rdsk/c0t1d0s6 /opt ufs 3 yes -

The first 2 fields list the same disk device as both a block device ("dsk") and character device ("rdsk"). The block device is used by mount(1m) when mounting the filesystem, the character device by fsck when checking it. Both must be present in vfstab.

The final portion of both device files identify the controller, target, LUN and slice/partition;

Solaris: Breaking down c0t1d0s6
c0 This device is attached to controller #0
Under Solaris this is usually the on-board scsi controller.
On PC hardware it refers to the first IDE controller on the motherboard.
t1 The device is target #1 - i.e. the second device on this controller.
On a SCSI controller this is the SCSI target ID and is usually set via a switch on any external enclosure or by jumpers on the disk itself.
On an IDE controller target#1 refers to the second IDE disk. With IDE this is generally determined by the device's position on the IDE cable.
d0 The device is Logical Unit / "LUN" #0 (the first) on this target.
Under SCSI a single target can support up-to eight devices. This is rarely seen in practice, but some hardware raid controllers use LUNs.
s6 Slice or Partition number 6.
Under Solaris this relates to the partition number as set in Format.

/etc/vfstab is covered in more details in Installing a new Disk under Solaris - /etc/vfstab



Home Thai Guide   Great Circle Calculator WorldClock AMS Services Contact us