SUN T7-1服务器首次开机上电指南

SUN-T7-1

This guide walks through the very first power-on of an Oracle SPARC server (Sun Server T7-1 and similar T-series / M-series platforms) using the Service Processor (SP) and Oracle ILOM. It covers the physical prerequisites, the console settings you need before the server will talk to you, the exact first-login and power-on sequence, and the follow-up tasks that turn a bare chassis into a manageable, hardened host: static network configuration on the NET MGT port, credential changes, console redirection and OS installation.

Everything below is done out-of-band. The SP is a small always-on computer soldered to the motherboard with its own firmware, its own Ethernet port and its own CLI, independent of whatever the host CPU is doing. That independence is the whole point: even with no OS installed, a hung kernel or a dead boot disk, the SP still answers on the serial port and on the network, which is how remote hands get a server from "in the crate" to "running a workload" without ever touching a keyboard.

What Oracle ILOM Gives You on Day One

Oracle ILOM (Integrated Lights Out Manager) is the firmware running on the SP. It exposes a hierarchical command shell - everything is addressed as a target path such as /SP, /System, /HOST or /SP/network - plus a web interface and an IPMI/SNMP surface for monitoring. On a brand-new server the SP firmware is already flashed at the factory, so the only thing missing is an IP address, a password that is not the default, and an operator who knows the console settings.

The three target trees you will use first:

  • /SP - the management processor itself: network, users, services, firmware, clock. Survives host reboots and OS reinstalls.
  • /System - the host chassis: power state, fault LEDs, boot mode, and the /System/console target that carries the host serial output.
  • /HOST - the host CPU complex from the SP's point of view; used for console redirection and diagnostics such as start /HOST/console.

Commands are read with show and changed with set. Most settings that touch hardware or network are "pending" until you commit them, which is why you will see paired commands - set the pending value, then commit. Tab completion and help <target> work everywhere, and help on its own lists the available command set. If you have used Dell iDRAC, HPE iLO or plain IPMI before, the concepts are the same family of out-of-band controller; the command grammar is ILOM's own.

Before You Start: Cabling, Console and the Default Account

Nothing in this procedure works without a clean console path, so verify these first:

  • Serial console: connect a terminal (laptop with a USB-to-RS232 adapter, a terminal server, or a serial console switch) to the server's serial management port using the supplied RJ-45-to-DB9 or DB-25 adapter. The classic ILOM console settings are 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control. Some newer firmware defaults to a faster rate - if you see garbage, cycle through 9600/19200/115200 before assuming a hardware fault.
  • NET MGT port: patch the dedicated management Ethernet port into a network that has a DHCP server, or plan to assign a static address while sitting at the console. Do not confuse it with the host data ports - the NET MGT port belongs to the SP, not to the OS.
  • Power: both power supplies seated, all power cords in, and the chassis grounded. The SP boots as soon as power is applied, long before you press the front power button.
  • Credentials: factory default is root / changeme for the ILOM Administrator account. If the server is second-hand or came from an integration lab, the default may already have been changed - ask the previous owner or reset the SP to factory defaults before continuing.
  • Documentation and firmware: note your ILOM firmware version (show /SP/firmware/version) because target names changed over time - most famously the /SYS to /System rename in ILOM 3.1.

If you are also racking the server for the first time, do the cable dressing before power-on: serial adapter and NET MGT cable labelled, service tags photographed, and the SP's MAC address recorded for your DHCP reservations or DCIM/NetBox records.

Power on the Server for the First Time

    1. At the terminal device, log in to the SP as root with a password of changeme.
      login: root
      Password: changeme
      . . .
      ->
      

      After a brief delay, the Oracle ILOM prompt is displayed (->).


      Note - The server is provided with a default Administrator account (root) and a default password (changeme) to enable first-time login and access to Oracle ILOM. To build a secure environment, you must change the default password of the default Administrator account as soon as possible after your initial login to Oracle ILOM. If you find this default Administrator account has already been changed, contact your system administrator to obtain an Oracle ILOM user account with Administrator privileges.


      For more information about the administration tasks such as changing passwords, adding accounts, and setting account privileges, refer to the Oracle ILOM documentation.


      Note - By default, the SP is configured to use DHCP to obtain an IP address. If you plan to assign a static IP address to the SP, see Assign a Static IP Address to the NET MGT Port for more instructions.


    1. Power on the server using one of the following methods:
        • Press the power button.

      • At the Oracle ILOM prompt, type:
      -> start /System
      Are you sure you want to start /System (y/n)? y
      

      The server initialization might take several minutes to complete.

      To cancel the initialization, press the #. (Hash+Dot) keys to return to the Oracle ILOM prompt. Then type: stop /System


      Note - In Oracle ILOM 3.1, the name space for /SYS was replaced with /System. You can use the legacy name in a command at any time, but to expose the legacy name in the output, you must enable it with -> set /SP/cli legacy_targets=enabled. For more information, see the Oracle ILOM documentation.


    1. (Optional) Redirect the host output to display on the serial terminal device.
      -> start /HOST/console
      Are you sure you want to start /SP/console (y/n)? y
      Serial console started. 
      . . .
      

    1. (Optional) You can execute other Oracle ILOM commands while the server initializes.
        1. To display the Oracle ILOM prompt, press the #. (Hash+Dot) keys.

        1. To see information about available Oracle ILOM commands, type: helpTo see information about a specific command, type help command-name

      1. To return to displaying host output from the server initialization, type:
        -> start /HOST/console
        

  1. Continue with the installation by installing the OS.See Configure the Preinstalled OS.

Give the SP a Static Address on the NET MGT Port

DHCP is fine for a lab bench, but any server you will manage for years deserves a static address you can find in a spreadsheet or an IPAM tool. Assign it from the console (or over SSH once you have any address at all). ILOM uses "pending" values, so a mistyped address never knocks you off the running configuration until you commit it:

-> set /SP/network pendingipdiscovery=static
-> set /SP/network pendingipaddress=192.0.2.50
-> set /SP/network pendingipnetmask=255.255.255.0
-> set /SP/network pendingipgateway=192.0.2.1
-> set /SP/network commitpending=true

Verify the result, then confirm the SP is reachable from the management network:

-> show /SP/network
-> show /SP/network/test

If the management network uses tagged VLANs, remember the NET MGT port on older Oracle SPs trunks as untagged by default - patch it into an access port on the management VLAN rather than guessing at 802.1Q behaviour. Record the SP hostname and address in the same inventory where you track the switch management addresses; the next engineer on call will thank you when the host is down and only the SP answers.

Harden the SP Before You Install Anything

The default account is a known, published credential - treat it as a hole, not a convenience. Change it immediately after the first login, and give each engineer their own account with the privileges they actually need rather than sharing root:

-> set /SP/users/root password
Enter new password: ********
Enter new password again: ********
-> create /SP/users/opsadmin
-> set /SP/users/opsadmin password
-> set /SP/users/opsadmin role=Administrator

Then reduce the attack surface while you are in the SP anyway:

  • set /SP/services/ssh state=disabled if you only ever use the console, or leave SSH on and disable telnet: set /SP/services/telnet state=disabled.
  • set /SP/services/http state=disabled when you prefer HTTPS only, and check show /SP/services/ssl for certificate validity.
  • Enable SNMP v3 or disable SNMP entirely - show /SP/services/snmp - so monitoring uses authenticated polling or traps.
  • Set an NTP server so log timestamps line up with the rest of your estate: set /SP/clients/ntp/server/1 address=<ntp-server>.
  • Point the SP's syslog at your central collector: set /SP/clients/syslog/host/1 address=<syslog-server>.

These last two matter more than they look: the SP log is often the only surviving record of why a server rebooted at 03:00, and an SP clock that has drifted makes correlating it with switch and application logs an exercise in frustration.

Watching the Boot: Power State and Console

Once the server is powered on, two commands tell you nearly everything about its state:

-> show /System/power
-> show /System/processors
-> show /System/faults

show /System/faults is the first thing to run when a server refuses to boot: a failed DIMM, a fan below threshold or a PSU warning is reported here by the SP even when the host deadlocks before POST output. Clear faults with set /System/clear_faults=true only after the physical cause is fixed, so you do not erase the evidence.

Because the SP keeps running while the host reboots, console redirection is the practical way to see POST, the boot loader and any OS installer. Press #. (Hash + Dot) to escape from host output back to the ILOM prompt at any time - this works even mid-install, and returning is a single start /HOST/console. If you expect a long unattended install, confirm the console survives your terminal session: a terminal server or a persistent screen/tmux session on a jump host beats a laptop lid closing at 40% of the way through a two-hour OS deployment.

After the OS: What the SP Still Does for You

Installing the OS is not the end of the management story. The SP remains the out-of-band plane for the life of the server, which is why it is worth wiring into your automation immediately:

  • Power control in scripts: start /System, stop /System and reset /System are the last-resort verbs after a kernel panic. Wrap them in a change ticket, not in a cron job.
  • Console logging: your terminal server or console switch should record the SP and host console to a file so a panic leaves a trace.
  • Monitoring: poll SP sensor state through SNMP or ILOM's REST/Redfish-style interfaces instead of logging in by hand - modern out-of-band APIs are scriptable, as shown in our iDRAC Redfish automation guide.
  • Inventory: keep SP address, hostname, firmware version and platform serial number together. When the platform is retired you will need all four to decommission the record cleanly.

Troubleshooting First Power-On

No console output at all: wrong serial speed or the cable is in the host serial port instead of the SP serial port. Confirm the adapter, then re-check the four console parameters one at a time.

Prompt appears but login fails: the default password was changed by a previous owner. The documented recovery is a physical SP reset to factory defaults, which wipes ILOM users, network settings and logs - so extract what you can first, and expect a maintenance window.

SP answers on console but not on the network: the NET MGT port is patched to the wrong VLAN, DHCP was never offered, or the address conflicts with another host. Check the link LEDs, then show /SP/network and compare with the switch MAC table.

Server powers off seconds after start: look at show /System/faults and the SP event log (show /SP/logs/event/list). Missing fan modules, unseated DIMMs and a single failed PSU in a redundant pair all produce immediate shutdowns, and the SP names the component.

Hash + Dot does nothing: some terminal programs swallow the sequence, or flow control is enabled on the serial port. Disable hardware flow control in the terminal, and if you are on a console server, use its own escape string rather than the ILOM default.

Legacy target names rejected: on ILOM 3.1 and later /SYS became /System. The legacy name still works if you expose it with set /SP/cli legacy_targets=enabled, which is the quickest fix for scripts written against older firmware.

Related Reading

If you are looking for the password recovery path rather than first-time setup, see how to reset or recover an ILOM password. For the wider landscape of out-of-band controllers and their trade-offs, read iDRAC vs iLO vs IPMI, and for the same workflow on an older Oracle midrange platform see our Sun M4000 operation notes.