Powering Sun M4000/5000 Series Servers Down And Up From The XSCF

Hey There,

Today's post is more beginner-oriented than the last few days' posts on deleted data recovery on Linux and Unix.

Below is a little walkthrough on the very basics of powering on, and powering off, M4000/5000 Series Sun Servers from the XSCF (eXtended System Controller Facility, or something roughly approximate) command line. These instructions should also apply to the M8000/9000 Series servers as well, but, since I'm getting all my output directly from an M4000, I don't want to "assume" anything incorrect about the higher end servers.

The basic steps we're going to walk through are simply logging in, powering down a domain, powering on a domain, and jumping back and forth between the XSCF command line and the M4000 console.

For the purposes of today's post, we're going to assume that the basic XSCF setup has been completed and you have an admin login account on it. You've also set up ssh (naturally) and disabled the web-based interface (because its so insecure... ;) Your admin account is "admin" - Also, in the spirit of keeping this simple, we're going to assume that you've only set up one domain on your M4000, and you've used the default first domain: domain 0.

Connecting to the XSCF is as simple as connecting to any server, assuming you have an account ;)

host # ssh admin@host-xscf
admin@host-xscf's password:
Last login: Sat Mar 28 17:55:52 2009 from fridgehost.beernutz.com

Once you're logged on, if you want to get to the console of your M4000 server, all you need to do is use the "console" command, like so (-d denotes the domain number and I use -y so I don't have to answer the "are you sure?" question every time):

XSCF> console -d 0 -y
Connect to DomainID 0?[y|n] :y

host console login: user
Password:
-bash-3.00$ exit

To get back to the XSCF prompt from the console, just type "pound dot" (literally #.) and it will kick you back to the XSCF from the console.

host console login: #.
XSCF>

Powering off the M4000 from the XSCF prompt is even more trivial ;) It should be noted that running "poweroff" at the XSCF command line is equal to running "init 5" at the command line, as root. "poweroff" will not tell you if your command was successful or not (neither will "poweron"), but you can find out the status of your request easily, by using the "showlogs" command. Also, just running "poweroff" again will let you know the status. If your previous invocation worked, you'll get an error that the machine is already powered off:

XSCF> poweroff -d 0 -y
DomainIDs to power off:00
Continue? [y|n] :y
....
XSCF> showlogs power
Example: Jan 08 16:47:45 EST 2009 Domain Power Off Operator 00 Locked
XSCF> exit

Powering on the server from the XSCF prompt is pretty much the same rigmarole :)

XSCF> poweron -d 0 -y
DomainIDs to power on:00
Continue? [y|n] :y
....
XSCF> showlogs power
Example: Jan 08 16:47:45 EST 2009 Domain Power On Operator 00 Locked
XSCF>

And that will, eventually, bring you right back to up. You can log into the console, from the XSCF prompt, before POST begins, if you want to see everything that happens on the console when you boot:

XSCF> console -d 0 -y
Connect to DomainID 0?[y|n] :y

b0939db-s console login: user
Password:
Last login: Sun Apr 5 16:57:14 from host
-bash-3.00$ exit

host console login: #.
XSCF> exit

And that's pretty much all there is to powering on and off your M4000/5000 Series server using the XSCF :)

Enjoy, but (as always) use caution if you're not sure what you're doing. As one last hint. If you get stuck at the XSCF prompt and need to know what to type next (There are no obvious hints), just type:

XSCF> man intro

or

XSCF> [tab][tab]
do you want to see all .... entries

That's literally hitting the tab key twice, above. Then it will ask you if you want to see all the available commands listed out. If you know what you want to do and you just can't remember the command name, [tab][tab] is your friend. If you think you know the name, and you also need to know a little bit about the command, then the man page for "intro" is your best bet.

Enjoy and cheers

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Changing Solaris Run Levels And Clearing Up Some Common Misconceptions

Hey there,

Today's post hearkens back to an earlier time, when I was administrating Solaris 2.4 and figured Sun had big plans for run level 4. It was, after all "reserved for future use." I don't know about you, but (to this day) when I see terminology like that, I tend to shy away from getting too comfortable with working in a cheap hack. My thinking was that, at some point (given Sun's policy at the time) they'd come up with a unique use for run level 4 and I'd have a whole lot of stuff set up to launch from there and my world would be thrown into chaos ;)

I no longer worry too much about the chaos (something, somewhere is going to break or I'll eventually be out of a job ;), but I still like to keep tabs on Solaris' "level 4" status updates and their command run-level policies. So, today, we'll take a brief look at "run level 4" and then look at a few commands, used to change run levels, that may not act as you would expect.

1. Run level 4: It is still, technically, reserved for future use on Solaris. However, the subtle difference in meaning over time has been stated more clearly with the last few releases. Now, about half of the places you look (on Sun's Documentation Site) list "run level 4" as being "user-defined." What this means, aside from the fact that any admin can make use of it if he or she deems it worthwhile, is that I spent a lot of time worrying about nothing. Of course, I'm willing to forgive, since I never had any use for "run level 4" anyway.

On most Linux and Unix distro's, run level 4 is considered open and user-definable. In a few instances, on HP-UX and Slakware, among others, run level 4 is the default run level for the X-Windows display manager. Generally, this is found on run level 5. But, before I go crazy over-explaining, check out Wikipedia's entry on run levels for virtually every system known to man :)

The only thing you have to make sure of, for the most part, if you want to use Solaris' run level 4 is that you create an entry for it in /etc/inittab. Something like:

s4:4:wait:/sbin/rc4                     >/dev/msglog 2<>/dev/msglog </dev/console

would probably suffice for distributions up to, and including Solaris 9. If there are minor differences in your distribution, you can simply copy the line for "s3," paste it below and change all the 3's to 4's. Fairly simplistic, but without it, Solaris' init will never know to look there and will not know what you mean when you try to change to run level 4.

On Solaris 10, things are a little goofier, but in a good way. You can mess around with the inittab and set things up that way, but if you use the "out-of-the-box" configuration and stick with the Service Management Facility (SMF), you won't need to worry about that. SMF has no concept of run levels and doesn't need /etc/inittab. Since SMF handles the order of starting services (with dependencies), you don't need to have a "separate" run level to accomplish whatever end you were shooting for. You can add new services with SMF and then goof around, to your heart's content, with svcadm, svccfg, svc.configd, etc. You may find yourself longing for the "old ways" until you get used to it.

2. Some command run level changing commands and what they're limited to: Some of this stuff still surprises me, since it seems counter-intuitive, but I guess I've always been lucky in the way I start stuff up and shut it down (my apologies to Clint Eastwood for bastardizing his famous quote from "Unforgiven" ;) Plus, I'm a big fan of "init" :) We're going to forget run level 4 exists for most of this part since it rarely matters... technically...

a. init: This command can be used to bring Solaris to any run level you specify (0, 1, s, S, 2, 3, 4, 5 and 6). This is a bone of contention, if you ever have to get certified, but Sun says there are only 8 run levels, of which only 7 are used. If you count "s" and "S" as separate (even though they both do the same thing) I would back you up if your answer was 9.

b. reboot: This command can only bring the system to run level 6. However, you can make reboot take you to other places by terminating the getopts routine and adding a flag afterward, so that:

host # reboot -- -s

would allow you to use the reboot command to get into single user mode. Also, another reason this perplexes me as much as it does is that, technically, bringing the machine to run level 6 entails the system going through a series of run levels leading all the way to the default run level (which is 3, if you left it alone). Sun's answer is technically true, but somewhat misleading. The only thing you really "can't" do with reboot is stop at run levels 0, 1, 2 and 5 (unless you make one of them your default run level in /etc/inittab - not a good idea, especially for 0 and 5 ;)

c. shutdown: This command can only bring the system to run levels 0, 1, s/S, 5 or 6. This makes sense to a degree, since run level 6 is reboot, 5 is power-off and 0 is PROM. I don't understand why it can shut the system down to run level 1 (single user with all local filesystems mounted read-write) and s/S (single user with only / mounted read-only) and not shut it down to run level 2 (basic multi-user with network) from run level 3 (same multi-user with nfs and some additional network services) straight up. As noted above, regarding reboot, you can actually make this command take you to any run level except 2 (unless you set that as your default run level in /etc/inittab)

d. poweroff: This command can only bring the system to run level 5. Perfectly sensible.

e. halt: This command can only bring the system to run level 0. This makes sense, too.

f. uadmin: This command can only bring the system to run levels 0, 5 and 6 (see above regarding why run level 6 means you can also use this command to get to run level 3, or your system default run level, as well). This command is restricted to super-user access by default. For the longest time I thought it could get you to any run level straight off, although I never needed to use it except to dump the system. An interesting fact about uadmin is that it can accept arguments. Which means, if you're feeling moderately clever, you can make it go places Mother won't let it go, by fudging it a little. Consider the following, understanding that uadmin converts arguments into integers as such, and is invoked as "uadmin command function optarg":

commands:

1 = No Disk Sync
2 = Sync Disks

functions:

1 = A_REBOOT <-- Run level 6
2 = A_SHUTDOWN <-- Run level 0
5 = A_DUMP <-- Run level 5

optional arguments:

Try whatever you want out, if you can afford to. Be sure to enclose an argument with spaces in double quotes.

host # uadmin 1 1 "-s kernel/unix" <-- Basically any option you can pass to the PROM "boot" command, you can sneak in here!

also, there are multiple versions of uadmin available, depending on your Solaris release, so you may be looking at these set of options, which will get you to run levels 0, s/S, 1, 2, 5 and 6 (which gives you run level 3) as well as allowing you the optional argument:

uadmin 2 0: sync the filesystems and drops system to ok prompt
uadmin 2 1: sync the filesystems and reboots to multi-user mode
uadmin 2 2: sync the filesystems and reboots interactively
uadmin 2 3: sync the filesystems and reboots to single-user mode
uadmin 2 6: sync the filesystems and powers off the system

uadmin 1 0: do not sync filesystems and drops system to ok prompt
uadmin 1 1: do not sync filesystems and reboots to multi-user mode
uadmin 1 2: do not sync filesystems and reboots interactively
uadmin 1 3: do not sync filesystems and reboots to single-user mode
uadmin 1 6: do not sync filesystems and powers off the system

Now, let's kick back and let the raging debate about OS version-and-release accuracy begin ;)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Shutting Down Domains on Sun 6800/6900 Servers

Here's a little information that comes in handy every once in a while. As you get used to working with Sun's larger machines, the convenience of some of the more advanced features becomes almost trivial. It's common (at least for me) to forget, from time to time, that ServerA and ServerB actually reside on the same physical server (Server1, for example).

That's one thing you get reminded of very quickly when, say, ServerB has a hardware related problem and you need to fix it. When you're dealing with DataCenter class machines, you generally don't want to make a mistake and accidentally pull a card that belongs to ServerA in your attempts to fix ServerB. The headache-multiplication theory is taken for granted, not to mention that company's generally throw lots of money at humongous hardware so they can house systems of "greater importance" on them. ServerA and ServerB, almost literally, translate into lost-revenue when they go down. When you're stuck in this sort of situation, taking your time and doing things right (even if you need to take a gut-punch and "read the manual" ;) is always more important than trying to blast your way through it and hoping for the best.

Luckily, when you're dealing with the 6800/6900 server series from Sun, dealing with domains and working on a "single" machine on a multi-domain system is pretty simple as long as you take the necessary precautions (never be embarrased to type "help"). Also, just so I can start typing 6800 instead of 6800/6900 from now on; the only real difference between the two is the internal architecture. The 6800's are SCSI-based, while the 6900's are fiber. You'll note that this is the difference with almost all of Sun's server series that relate closely (the v480 and v490, or the v880 and v890 - All of them are just slightly different). The 900's and 90's were released because internal fiber disk is much faster than internal scsi-connected disk. To keep it simple ;)

As a for instance, let's say that ServerB is suffering terrible failures (even Sun can't readily explain them). A number of HBA's on the I/O boards have failed and there's a problem with one of the System Boards. Also, your root mirror disk is giving off errors left and right. This is a potentially horrible scenario for which no resolution will be given. We're just using it to make it so we can walk through the process of bringing ServerB down completely and replacing parts.

The first thing you'll want to do is to connect to the System Controller. This can be done any number of ways. Your site should have documentation related to how they've set it up. Generally it will be an SSH or Telnet connection to the SC. You can also set up direct connects for the Domain Consoles, but, even when we have them, I prefer to connect to the SC, as you can get to all of the Domain Consoles from there, as well as the "Platform Shell"! Assuming you've connected, you'll be at a terminal screen that looks something like this.

System Controller 'Server1':

    Type  0  for Platform Shell

    Type  1  for domain A console
    Type  2  for domain B console
    Type  3  for domain C console
    Type  4  for domain D console

Since this is also very specific to how your machine was set up, we'll go with the assumption that ServerA is on the "Domain A" console and ServerB is on the "Domain B" console. Since we want to work on ServerB, and leave ServerA up and running while we do, we'll type in the following (This may seem counter-intuitive at first, but the fact that I'm logging into the "Platform Shell" rather than the "Domain B" console can offer some enhanced control (when you get around to playing with it) and allows you to connect to any domain directly from it):

Input: 0

Platform Shell

Server1:SC> 

Now we're at the SC prompt, at the Platform Shell level -- Remember, at almost any point along the way you can type "help" to get a list of all available commands. When you get a chance, do so, and you'll see what I mean about the enhanced flexibility that starting off at the Platform Shell offers. To continue, we'll connect directly to the "Domain B" console, which is just like logging into a regular machine serial console:

Server1:SC> console b

Connected to Domain B

ServerB console login: root
Password: ******

And, just like on any other machine, we'll bring it down to an ok> prompt as if it weren't a part of a larger physical organism (Server1 - the big 6800)

ServerB# init 0

You'll get the regular system messages and whatever else gets spit to the screen when you normally shut down, and you're there. Now, we'll want to switch from the "Domain Console" to the "Domain Shell." We can do that like so:

{c} ok

<---------- Here type a literal [ctl]+] (the control key and the right bracket (]) simultaneously) - this will get you to a Telnet or SSH prompt - depending on your setup. Then, you'll send a "break" signal to make the switch from Console to Shell.

telnet> send break

Domain Shell for Domain B - ServerB

ServerB:B> setkeyswitch off <-- This command is the one that will "turn off" ServerB. Note that, if you've looked at the "help" output, you don't want to run "poweroff" - That could seriously ruin your day ;) The "poweroff" command is used for powering off the physical grids. Generally, on a two domain 6800, you'll only have one, so running "poweroff" might bring down both ServerB and ServerA. Sun only requires you to split your 6800 into 2 grids if you want to have 3 or 4 domains!

Powering boards off ...
ServerB:B>

Now your "virtual" server (ServerB) is off, and ServerA is still up and running as if nothing were going on. You're ready to begin replacing parts.

As a quick note; before you completely disconnect from the "Domain Shell," I always find it's good practice to run the following comand:

ServerB:B> showboards

Slot     Pwr Component Type                 State      Status     Domain
----     --- --------------                 -----      ------     ------
/N0/SB1  Off CPU Board                      Assigned   Not tested B
/N0/SB2  Off CPU Board                      Assigned   Not tested B
/N0/SB3  Off CPU Board                      Assigned   Not tested B
/N0/IB7  Off PCI I/O Board                  Assigned   Not tested B
/N0/IB9  Off PCI I/O Board                  Assigned   Not tested B

Write down the left-most column (Slot) and glance over the entries to make sure that they're all in the correct Domain (B, here) and that the "Pwr" (power) column lists them all as off. This will help make doubly sure you don't accidentally affect ServerA, as the CPU Board and I/O Board numbers are listed on the outsides of the devices and, if you've written this information down, you can refer to it and easily locate what part of the system you can safely work with.

And, of course (very quickly) for those of you who want to know how to get everything back up and running, just do the following (A very quick summary of commands and output here, as the concepts are all the same, but done in a logical reverse order; with the exception of the rarely needed "resume" command noted below)

System Controller 'Server1':

    Type  0  for "Platform Shell"

    Type  1  for domain A console
    Type  2  for domain B console
    Type  3  for domain C console
    Type  4  for domain D console

    Input: 0
    
    Platform Shell

Server1:SC> 

Server1:SC> console b

Connected to Domain B

<---------- Here type a literal [ctl]+ ]

telnet> send break

Domain Shell for Domain B - ServerB

ServerB:B> setkeyswitch on
Powering boards on ...
ServerB:B>resume

<--- Note that this command and the following are not usually necessary. Once you power on your system by doing the "setkeyswitch on," the 6800 will run through extensive system tests and boot the OS directly.

ok> boot

Hopefully the amount of time spent reading this will save you much much more in the future :)

Cheers,

, Mike

linux unix internet technology