Local System Update for PRIMERGY Servers -...

User Guide - English

FUJITSU Software ServerView Suite Local System Update for PRIMERGY Servers

Edition Februar 2018

Copyright und Handelsmarken

Kritik… Anregungen… Korrekturen…Die Redaktion ist interessiert an Ihren Kommentaren zu diesem Handbuch. Ihre Rückmeldungen helfen uns, die Dokumentation zu optimieren und auf Ihre Wünsche und Bedürfnisse abzustimmen.

Sie können uns Ihre Kommentare per E-Mail an [email protected] senden.

Zertifizierte Dokumentation nach DIN EN ISO 9001:2008Um eine gleichbleibend hohe Qualität und Anwenderfreundlichkeit zu gewährleisten, wurde diese Dokumentation nach den Vorgaben eines Qualitätsmanagementsystems erstellt, welches die Forderungen der DIN EN ISO 9001:2008 erfüllt.

cognitas. Gesellschaft für Technik-Dokumentation mbHwww.cognitas.de

Copyright 2015 FUJITSU LIMITED

All rights reserved.Delivery subject to availability; right of technical modifications reserved.

All hardware and software names used are trademarks of their respective manufacturers.

mailto:[email protected]

http://www.cognitas.de

Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1 Local update management on PRIMERGY servers . . . . . . 8

1.2 Update Manager Express, ASPs and PSPs . . . . . . . . . . 12

1.3 Target groups and objectives . . . . . . . . . . . . . . . . . 12

1.4 Changes since the previous versions of the manual . . . . 13

1.5 ServerView Suite link collection . . . . . . . . . . . . . . . . 14

1.6 Documentation for ServerView Suite . . . . . . . . . . . . . 15

1.7 Notational conventions . . . . . . . . . . . . . . . . . . . . 16

2 ServerView Update Manager Express . . . . . . . . . . . . 17

2.1 Current BIOS/firmware/driver versions and Update DVD . . 19

2.2 Usage of Update DVD and Update Manager Express . . . . 202.2.1 Using the Update DVD ISO image

(UPDATE_DVD_<version>.iso) . . . . . . . . . . . . . . . . . 202.2.2 Creating a bootable USB stick from the Update DVD . . . . . . 202.2.3 Booting the server from the Update DVD / USB stick in

Legacy mode and starting Update Manager Express . . . . . . 242.2.4 Booting the server from the Update DVD / USB stick in

UEFI mode and starting Update Manager Express . . . . . . . 26

2.3 Installing BIOS/firmware/drivers under Windows . . . . . . 282.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.2 Starting Update Manager Express under Windows Server

2008/2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4 Installing BIOS/firmware under Linux . . . . . . . . . . . . . 302.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.2 Starting Update Manager Express under Linux . . . . . . . . . 302.4.2.1 Starting Update Manager Express via the Linux CLI . . . . 302.4.2.2 Starting Update Manager Express via the Linux GUI . . . . 31

Local System Update for PRIMERGY Servers

Contents

2.5 PXE-based mass update in an environment without ServerView Deployment Manager . . . . . . . . . . . . . . . 32

2.5.1 Starting Update Manager Express via PXE (overview and prerequisites) . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5.2 Integrating the PXE functions provided on the Update DVD . . . 342.5.2.1 Setting up the <TFTP Root >/UME_<version> directory

on the PXE server . . . . . . . . . . . . . . . . . . . . . . . 352.5.2.2 Setting up the directory on the data TFTP server . . . . . . 372.5.3 Creating the server type-specific XML control files . . . . . . . . 382.5.3.1 Copying additional program files from the Update DVD . . . . 382.5.3.2 Calling the XML Converter for creating server

type-specific xml control files . . . . . . . . . . . . . . . . . 392.5.3.3 Assigning the profiles to the individual PRIMERGY servers . 412.5.4 Adapting the start.sh script . . . . . . . . . . . . . . . . . . . . 412.5.5 Initiating and monitoring the PXE-based update process . . . . . 42

2.6 PXE-based mass update using ServerView Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.7 Update Manager Express GUI . . . . . . . . . . . . . . . . . 482.7.1 Quick Mode / Normal Mode . . . . . . . . . . . . . . . . . . . . 502.7.2 Expert Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.7.2.1 Updating BIOS/firmware/driver . . . . . . . . . . . . . . . . 562.7.2.2 Updating Hard Disk Drive firmware via HDD Flash . . . . . . 592.7.3 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2.8 Update Manager Express CLI . . . . . . . . . . . . . . . . . . 652.8.1 Requirements and first steps . . . . . . . . . . . . . . . . . . . 662.8.2 Writing a start script for the CLI . . . . . . . . . . . . . . . . . . 672.8.3 Calling Update Manager Express via CLI -

Syntax and commands . . . . . . . . . . . . . . . . . . . . . . 682.8.3.1 Calling Update Manager Express via CLI . . . . . . . . . . . 682.8.3.2 CLI commands . . . . . . . . . . . . . . . . . . . . . . . . 69

3 PRIMERGY Support Packages (PSP) . . . . . . . . . . . . . . 77

3.1 Current versions of PrimeUp and PSPs . . . . . . . . . . . . 78

3.2 PSPs (overview) . . . . . . . . . . . . . . . . . . . . . . . . . 793.2.1 Structure of a PSP . . . . . . . . . . . . . . . . . . . . . . . . 793.2.2 Tree structure of a PSP repository . . . . . . . . . . . . . . . . 813.2.3 Scan PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.2.4 PSP versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 84


Contents

3.3 PrimeUp installation tool . . . . . . . . . . . . . . . . . . . 853.3.1 PrimeUp functionality . . . . . . . . . . . . . . . . . . . . . . 853.3.2 Installing PSPs using PrimeUp (overview) . . . . . . . . . . . . 863.3.2.1 Starting PSP installation . . . . . . . . . . . . . . . . . . . 873.3.2.2 PrimeUp version handling . . . . . . . . . . . . . . . . . . 873.3.2.3 How PrimeUp detects the chassis ID, system board ID,

and model ID of your server . . . . . . . . . . . . . . . . . 893.3.2.4 How PrimeUp works . . . . . . . . . . . . . . . . . . . . . 893.3.2.5 How PrimeUp interacts with the Windows registry . . . . . . 913.3.3 Requirements for PrimeUp . . . . . . . . . . . . . . . . . . . 963.3.3.1 Supported servers . . . . . . . . . . . . . . . . . . . . . . 963.3.3.2 Software requirements . . . . . . . . . . . . . . . . . . . . 963.3.3.3 Supported drivers . . . . . . . . . . . . . . . . . . . . . . 963.3.4 Installing / uninstalling PrimeUp . . . . . . . . . . . . . . . . . 973.3.4.1 Installing PrimeUp . . . . . . . . . . . . . . . . . . . . . . 973.3.4.2 Uninstalling PrimeUp . . . . . . . . . . . . . . . . . . . . 983.3.5 Starting PrimeUp . . . . . . . . . . . . . . . . . . . . . . . . 993.3.6 PrimeUp - Parameters and options . . . . . . . . . . . . . . . 1003.3.7 Return codes . . . . . . . . . . . . . . . . . . . . . . . . . . 1073.3.8 Evaluating the installation process . . . . . . . . . . . . . . . 1093.3.9 Important notes . . . . . . . . . . . . . . . . . . . . . . . . . 112

3.4 PrimeUp usage variants . . . . . . . . . . . . . . . . . . . . 1133.4.1 Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133.4.2 Manual calling . . . . . . . . . . . . . . . . . . . . . . . . . . 114

3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.5.1 Parameter -installed . . . . . . . . . . . . . . . . . . . . . . . 1153.5.2 Parameter -list . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.5.3 Parameter -reginit . . . . . . . . . . . . . . . . . . . . . . . . 1173.5.4 Parameter -simulate . . . . . . . . . . . . . . . . . . . . . . . 1203.5.5 Parameter -update . . . . . . . . . . . . . . . . . . . . . . . . 121

3.6 How to get help . . . . . . . . . . . . . . . . . . . . . . . . . 122

4 Autonomous Support Packages (ASP) . . . . . . . . . . . . 123

4.1 Current BIOS/firmware versions . . . . . . . . . . . . . . . 124

4.2 ASPs for Windows . . . . . . . . . . . . . . . . . . . . . . . 1254.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 1264.2.2 Accessing the ASPs . . . . . . . . . . . . . . . . . . . . . . 127


Contents

4.2.3 Starting the ASP in Windows Explorer . . . . . . . . . . . . . 1294.2.3.1 Displaying the release notes . . . . . . . . . . . . . . . . 1314.2.3.2 Extracting the data . . . . . . . . . . . . . . . . . . . . . 1324.2.3.3 Starting the BIOS/firmware installation . . . . . . . . . . . 1334.2.4 Calling ASPs via the command line interface (CLI) . . . . . . . 1354.2.5 Calling an ASP via the Windows PowerShell . . . . . . . . . . 1404.2.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424.2.6.1 Displaying help texts . . . . . . . . . . . . . . . . . . . . 1424.2.6.2 Extracting ASP data . . . . . . . . . . . . . . . . . . . . . 1434.2.6.3 Firmware update with return code . . . . . . . . . . . . . 1444.2.6.4 Firmware update with return code (using Windows

PowerShell) . . . . . . . . . . . . . . . . . . . . . . . . . 1444.2.6.5 Keeping the contents of the ASP target directory . . . . . 146

4.3 ASPs for Linux . . . . . . . . . . . . . . . . . . . . . . . . . 1474.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 1474.3.2 Accessing the ASPs . . . . . . . . . . . . . . . . . . . . . . 1474.3.3 Calling ASPs via the command line interface (CLI) . . . . . . . 1494.3.4 Installation procedure . . . . . . . . . . . . . . . . . . . . . . 1554.3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584.3.5.1 Displaying help texts . . . . . . . . . . . . . . . . . . . . 1584.3.5.2 Extracting ASP user data . . . . . . . . . . . . . . . . . . 1594.3.5.3 Performing the installation in the background . . . . . . . . 1604.3.5.4 Keeping the contents of the ASP target directory . . . . . 161

4.4 ASP return codes . . . . . . . . . . . . . . . . . . . . . . . 162

4.5 Log file Setup.log (ASPs for Windows only) . . . . . . . . . 166


1 IntroductionFor local system updates on PRIMERGY servers the following tools are available:

– ServerView Update Manager Express (GUI-based, CLI, and no interaction in case PXE)

– Self-extracting and self-installing software packages, so-called Autonomous Support Packages (ASPs)

– PRIMERGY Support Packages (PSPs) and the PrimeUp installation tool

With Update Manager Express from the ServerView Suite or by executing ASPs, you can install firmware and BIOS of the various server components on the current PRIMERGY servers.

On Windows Server 2008/2012 operating systems, Update Manager Express also allows you to update drivers of your PRIMERGY server. For this purpose, a separate installation package (PSP) is available for each component of the server. To update drivers using PSPs, you can alternatively use the PrimeUp installation tool.

The present manual "Local System Update of PRIMERGY Servers" incorporates the former "ServerView Update Manager Express" and "PrimeUp" manuals, which are no longer available.

I For updating firmware, BIOS and drivers, we recommend that you use Update Manager Express.

I To allow safe resetting in the case of errors, you should perform an appropriate backup of your system before doing any updates.

Local System Update for PRIMERGY Servers 7

Local update management on PRIMERGY servers

1.1 Local update management on PRIMERGY servers

In contrast to Update Manager from the ServerView Suite, which can supply entire data centers with firmware, Update Manager Express, PrimeUp and ASPs are ideally suited for local updates of individual systems.

I An overview of which PRIMERGY servers or which server components can be installed via ASPs is provided in the Update Manager Express data sheet.

Offline / online update procedures

A distinction is made between offline and online update procedures:

– Offline update mode

Update Manager Express is started either from a booted DVD image (e.g. ServerView Update DVD) or via PXE boot. In offline mode, only firmware can be updated. On the other hand, more updates are available than in online update mode (e.g. HDD flash).

– Online update mode

Update Manager Express, ASPs, PrimeUp (PSPs) are executed under a running supported operating system. In online mode, you have to ensure that the prerequisites required for performing the update are met (e.g. Update Manager Express requires that ServerView Agents are installed). Only online mode allows you to update devices drivers and ServerView Agents software. On the other hand, some firmware updates might not be possible due to lack of operating system support.

8 Local System Update for PRIMERGY Servers


Local update management on PRIMERGY servers (Windows)

On PRIMERGY servers running under Windows Server operating systems, you have the following installation options:

– Via the graphical user interface (GUI) of Update Manager Express or via the Update Manager Express command line interface (CLI) you can install BIOS/firmware/drivers for all server components jointly, or selectively for individual components (see chapter "ServerView Update Manager Express" on page 17).

– With the PrimeUp installation tool you can install drivers for all server components jointly, or selectively for individual components (see chapter "PRIMERGY Support Packages (PSP)" on page 77)

– In Windows Explorer you can start the individual ASPs by clicking the *.exe file of the relevant ASP. You then install the ASP via its GUI with the help of a wizard (see section "ASPs for Windows" on page 125).

– Under the Windows input prompt you can use the commands of the ASP command line interface (CLI).You can choose to use the wizard or run the installation in the background (see section "Calling ASPs via the command line interface (CLI)" on page 149).

I Please note:

– For virtual machines, BIOS/firmware/driver updates are not possible.

– For PRIMERGY servers running Microsoft Hyper-V, BIOS/firmware/driver updates are possible with restrictions.



Local update management on PRIMERGY servers (Linux)

On PRIMERGY servers running under Linux operating systems, you have the following installation options:

– Via the graphical user interface (GUI) of Update Manager Express or via the Update Manager Express command line interface (CLI) you can install BIOS/firmware for all server components jointly, or selectively for individual components (see chapter "ServerView Update Manager Express" on page 17).

– You start the individual ASPs via the respective self-extracting *.scexe files (see section "ASPs for Linux" on page 147).

I Please note:

– For virtual machines, BIOS/firmware/driver updates are not possible.

– For PRIMERGY servers running Xen/KVM, BIOS, updates are possible with restriction: Some ASPs, BIOS ASPs in particular, are not executable on Red Hat Linux systems with XEN. A respective return code (offline update) or message (online update) is output in such cases. On the FUJITSU Web Server (support.ts.fujitsu.com), no Red Hat Linux operating systems with XEN are listed for the ASPs concerned.

– For updating BIOS/ firmware on ESX 5 systems, please use the ServerView Update Manager Express offline mode.

PXE-based mass update of PRIMERGY servers

PXE-based mass update allows unattended and massive parallel processing when updating PRIMERGY servers and is therefore primarily designed for updating huge server farms.



BitLocker detection

For updates concerning the system board BIOS, BitLocker detection works as follows:

– On Windows Server operating systems as of Windows Server 2008 R2, a BitLocker detection script is automatically executed to test whether a BitLocker is active (Status = PRESENT) or not (Status = NONE). Possible BitLocker conditions are: NONE, MAYBE (not on Windows systems), PRESENT.

– When booting from the ServerView Update DVD, ServerView update management cannot know whether the operating system running on the managed server uses BitLocker encryption. It is therefore checked whether a TrustedPlatform Module (TPM) is enabled, which is required for using BitLocker encryption. If a TPM module is enabled, BitLocker may be active and thus BitLocker status is set to MAYBE.

In case of BitLocker status MAYBE, which is set by default, and if you are using a GUI, you will be asked whether your system is protected by the BitLocker:

YesBitLocker status is set to PRESENT and you will receive the following message:

BitLocker forbids the update.

I If you are unsure about BitLocker, please click Yes.

NoBitLocker status is set to NONE. The system board can be updated.

I If BitLocker status is set to NONE, it is always possible to update the system board.


Update Manager Express, ASPs and PSPs

1.2 Update Manager Express, ASPs and PSPs

Update Manager Express, ASPs and PSPs are available from the Download section for system-specific ASPs and PSPs from FUJITSU at http://support.ts.fujitsu.com.

I ASPs and PSPs are used in the ServerView Suite by all update management components (including ServerView Update Manager and Download Manager).

1.3 Target groups and objectives

For more recent PRIMERGY servers, this manual describes:

– The various options for installing BIOS and firmware with the help of Update Manager Express and ASPs.

– How to install PSPs (driver software) with the help of Update Manager Express and PrimeUp (on Windows Server operating systems).

The manual is aimed at system administrators, network administrators and service specialists with a sound knowledge of hardware and software.


http://support.ts.fujitsu.com

Changes compared with the previous version

1.4 Changes since the previous versions of the manual

This manual replaces the following online manual: "Local System Update for PRIMERGY Servers", August 2013 edition.

The manual includes the following updates:

● Chapter "2 Update Manager Express":

– New Maintenance Mode in the Update Manager Express GUI

– New Java XML-Converter options -architecture and -operatingsystem.

● Chapter "3 PRIMERGY Support Packages (PSP)":

– In addition to the already available (component-specific) packages, PSPs now may also contain MainPackages which define global cross-package dependencies relevant for all subsequent component-specific packages.

– New XML converter options.

– Extended PrimeUp version handling due to MainPackages.

● Chapter "4 Autonomous Support Packages (ASP)":

Additional commands for calling ASPs via the command line interface (CLI) on Windows and Linux systems.



1.5 ServerView Suite link collection

Via the ServerView Suite link collection, FUJITSU provides you with numerous downloads and further information on the ServerView Suite and PRIMERGY servers.

For ServerView Suite, links are offered on the following topics:

● Forum

● Service Desk

● Manuals

● Product information

● Security information

● Software downloads

● Training

I The downloads include the following:

– Current software versions for the ServerView Suite as well as additional Readme files.

– Information files and update sets for system software components (BIOS, firmware, drivers, ServerView agents and ServerView update agents) for updating the PRIMERGY servers via ServerView Update Manager or for locally updating individual servers via ServerView Update Manager Express.

– The current versions of all documentation on the ServerView Suite.

You can retrieve the downloads free of charge from the FUJITSU web server.

For PRIMERGY servers, links are offered on the following topics:

● Service Desk

● Manuals

● Product information

● Spare parts catalogue



Access to the ServerView Suite link collection

You can reach the link collection of the ServerView Suite in various ways:

1. Via ServerView Operations Manager.

Ê Select Help – Links on the start page or on the menu bar.

This opens the start page of the ServerView Suite link collection.

2. Via the start page of the online documentation for the ServerView Suite on the FUJITSU manual server.

I You access the start page of the online documentation via the following link:

http://manuals.ts.fujitsu.com

Ê In the selection list on the left, select x86 Servers.

Ê On the right, click PRIMERGY ServerView Links under Selected documents.


3. Via the ServerView Suite DVD 2.

Ê In the start window of the ServerView Suite DVD 2, select the option ServerView Software Products.

Ê On the menu bar select Links.


1.6 Documentation for ServerView Suite

The documentation can be downloaded free of charge from the Internet. You will find the online documentation at http://manuals.ts.fujitsu.com under the link x86 Servers.

For an overview of the documentation to be found under ServerView Suite as well as the filing structure, see the ServerView Suite sitemap (ServerView Suite - Site Overview).





1.7 Notational conventions

The following notational conventions are used in this manual:

References

If there are references to text or sections of text in this manual, the chapter or section heading is given in the reference, and the page stated refers to the page on which the chapter or section begins.

Screen outputs

Please note that the screen output is dependent in part on the system used and therefore some details may not correspond exactly to the output you will see on your system. You may also see system-dependent differences in the menu items available.

V Caution This symbol points out hazards that can lead to personal injury, loss of data or damage to equipment.

I This symbol highlights important information and tips.

Ê This symbol indicates a step that you must carry out in order to continue with the procedure.

bold Commands, menu items, names of buttons, options, variables, file names and path names are written in bold letters in the text.

fixed font System output is written using a fixed font.

semi-bold fixed font

Commands to be entered via the keyboard are written in a semi-bold fixed font.

<abc> Angle brackets are used to enclose variables which are to be replaced by actual values.

[Key symbols] Keys are displayed as they appear on the keyboard. If capital letters are to be entered explicitly, then the Shift key is shown, e.g. [SHIFT] - [A] for A.

If two keys need to be pressed at the same time, this is indicated by a hyphen between the two key symbols.

Table 1: Notational conventions


2 ServerView Update Manager Express

Using Update Manager Express, you can install firmware or BIOS for the following server components:

– LAN controller: Firmware– Management controller (e.g. iRMC S4): Firmware– Microcontroller: Firmware– System board: BIOS– SCSI controller: Firmware– FibreChannel controller: Firmware

Beyond that, Update Manager Express allows you to update Hard Disk Drive firmware via HDD Flash.

On Windows Server 2008/2012 operating systems, Update Manager Express also allows you to update drivers of your PRIMERGY server. For this purpose, a separate installation package (PRIMERGY Support Package, PSP) is available for each component of the server.

I For updating installations of BIOS, firmware and drivers, we recommend that you use Update Manager Express because it takes care of dependencies and sequence.

I For installing BIOS and firmware Update Manager Express internally uses self-extracting and self-installing software packages (Autonomous Support Packages, ASPs).

For installing drivers (PSPs), Update Manager Express internally uses the PrimeUp installation tool.

When updating installations of BIOS, firmware and drivers, Update Manager Express proceeds according to the following installation sequence:

1. Update Manager Express installs/updates drivers and software kits (PSPs) using PrimeUp (on Windows Server 2008/2012 only).

2. Update Manager Express installs ASPs in an order that takes account of dependencies.



Supported device classes

Update Manager Express can be used to update devices of the classes shown in table 2.

Update scenario

Online Offline

Component type Windows Linux CentOS

iRMC firmware X X X

BIOS X X X

Microcontroller X X X

SAS controller X X X

RAID controller X X X

LAN controller X X X

FC controller X X X

GPGPU (Intel)

GPGPU (NVIDIA)

Intel Infiniband

Mellanox Infiniband

HDD firmware X

SSD firmware X

Windows driver (PSP) X

ServerView agents X X

MMB firmware

Switch firmware

Table 2: Devices that can be updated using Update Manager Express


BIOS/firmware/drivers and Update DVD

2.1 Current BIOS/firmware/driver versions and Update DVD

BIOS, firmware and drivers (and Update Manager Express) for your PRIMERGY server are available for download as follows:

● DVD ISO image UPDATE_DVD_<version>.iso (ServerView Update DVD)

You can update your server’s BIOS/firmware/drivers by downloading the DVD ISO image UPDATE_DVD_<version>.iso of the latest version from http://support.ts.fujitsu.com/Download, creating an Update DVD from it, and then using this for the BIOS/firmware/driver update. For details, see section "Booting the server from the Update DVD / USB stick in Legacy mode and starting Update Manager Express" on page 24.

● Latest BIOS/firmware/drivers available for downloading

Also in the period between two successive editions of the ServerView Update DVD FUJITSU offers constantly updated versions of BIOS/firmware/drivers, and ASPs for downloading at http://support.ts.fujitsu.com/globalflash.

Therefore, if you need a BIOS/firmware/driver version even newer than the BIOS/firmware/driver version provided on the most recent Update DVD, please check http://support.ts.fujitsu.com/globalflash to see whether such a version exists.

I Because these BIOS/firmware/drivers are not contained on the Update DVD, you cannot use Update Manager Express to install them:

– For how to install BIOS/firmware, see chapter "Autonomous Support Packages (ASP)" on page 123).

– For how to install drivers and software kits, see chapter "PRIMERGY Support Packages (PSP)" on page 77).

Alternative for the manual download of ASPs is using Content Collector. The tool offers wizard GUI to step by step select systems and components for which the newest ASPs should be downloaded. It also offers download of PSPs. For further details, see http://manuals.ts.fujitsu.com.


ftp://ftp.ts.fujitsu.com/images/serverview/


http://support.ts.fujitsu.com/globalflash




2.2 Usage of Update DVD and Update Manager Express

2.2.1 Using the Update DVD ISO image (UPDATE_DVD_<version>.iso)

You can download the DVD ISO image UPDATE_DVD_<version>.iso of the latest version from http://support.ts.fujitsu.com/Download, create a physical Update DVD or a bootable USB stick from it, and then use this for the BIOS/firmware/driver update.

There are the following options for mounting the Update DVD ISO image UPDATE_DVD_<version>.iso:

– Burning a physical DVD from it (in the following called Update DVD for short)

– Creating a bootable USB stick from it.

– Making it available via the Remote Storage function of the iRMCS2/S3 or via the Virtual Media function of the iRMC S4.

2.2.2 Creating a bootable USB stick from the Update DVD

For creating a bootable USB stick, you have the option to use the Update DVD ISO image UPDATE_DVD_<version>.iso or a (physical) Update DVD burned from it. The USB stick is mostly a simple copy of the Update DVD. Differences can only be found in those parts which make the DVD / stick bootable. Therefore, you can use the stick and the Update DVD in the same way.

System requirements

– PC running a supported / released Windows operating system (e.g. Windows 7 or Windows 8).

I A USB stick built on a Windows system can be used on both Windows and Linux systems.

– Administrator rights on this PC.




The USB stick must meet the following requirements:

USB stick requirements

– Storage capacity of 8 GB or higher

– USB 2.0 (Recommended: USB 3.0)

– The USB stick must be bootable.

I As large amounts of data are to be copied to the USB stick, it is recommended to use a high speed USB stick.

Software requirements

All the software needed for creating the USB stick is contained in the DVD ISO image UPDATE_DVD_<version>.iso / Update DVD. You will find the main script createUSBStick.bat in the directory Tools\General\UMEtoStick.

To use the script from the Update DVD, you must make the Update DVD visible in the file system of your PC.

You can achieve this as follows:

– If you have burned the DVD ISO image UPDATE_DVD_<version>.iso on a physical DVD, insert this media and mount it.

– If only the DVD ISO image UPDATE_DVD_<version>.iso is available, there exists usually no Windows built-in program that can be used for mounting the ISO image. However, there is a wide range of third-party tools you can use for this purpose.

Preparing the USB stick

I Preparing the USB stick is required only once. If you already formatted the USB stick according to requirements proceed to "Creating the USB stick" on page 23.

Before you can start the createUSBStick.bat script, you first have to prepare the USB stick in a way that the following requirements are met:

– The USB stick must be empty.

– The USB stick must be formatted as a normal disk with a partition table.

– On the USB stick, there must be exactly one primary partition formatted as FAT32 file system. FAT32 is chosen because both Windows and Linux can handle this file system type.



To prepare your USB stick, proceed as follows:

1. Connect the USB stick to your PC.

2. In the command line start the diskpart tool with administrator rights (cmd.exe).

I Different from usual notation, drive letters in diskpart are not followed by a ":". Example: In diskpart, the notation "D" is used instead of "D:".

Enter the following diskpart commands:

a) Enter list disk to get a list of all disks.

Identify the line representing your USB stick.

I Normally, you can identify the line representing your USB stick via the Size field of the line. Otherwise, compare the output lists the list disks command provides when the USB stick is connected and when the USB stick disconnected.

I Please be sure to correctly identify the USB stick because all data will be removed from the selected device.

b) Enter select disk <No> to change to your USB stick. For <nr>, enter the number displayed in the first field of your selected line.

c) Enter clean to remove all data and the complete partition structure from the stick.

d) Enter create partition primary to create the one partition required on the stick. A drive letter will be automatically assigned to this partition.

e) Enter list partition to detect the partition number assigned by the create partition primary command.

I Note that there must be only one single line in the output list of the list partition command.

f) Enter select partition partition <No> to define the partition as the current partition. <No> is the number displayed in the output list of the list partition command.

g) Enter detail partition to display all details of the new partition. The drive letter can be seen in the second output field.



h) Enter exit to exit the diskpart tool.

I The new partition is in raw format, i.e. the partition does not yet have a file system set up. As the partition cannot be used in this state, it must be formatted into a FAT32 file system as described below.

3. Enter the format command to format the new drive into a FAT32 file system:

I In the following, for drive letters the usual notation (e.g. "D:") is mandatory.

format <drive letter> /FS:FAT32 /Q

Answer any questions asked by the program with [Enter].

Creating the USB stick

After having prepared the USB stick as described above you can run the createUSBStick.bat script that copies contents from the Update DVD to USB stick.

I You need to know the drive letter the system uses to refer to the USB stick. You have already got the drive letter in the preparation phase. This drive letter is still valid if the USB stick has not been removed since then.

Proceed as follows:

1. Change to the directory Tools/GENERAL/UMEtoStick on the Update DVD.

2. Start the createUSBStick.bat script with administrative rights:

createUSBStick.bat <drive letter>

(e.g createUSBStick.bat d:)

The execution of the script will take some time because the files are copied from the Update DVD to the USB stick. To keep you updated, the script outputs the following information in the order listed below:

– Formatting information

– Names of the files being copied to the USB stick

I Normally, the names will be displayed one after another without delay. In the case of large files, however, it may take some time before the name of the next file is displayed.



– The following message is shown once the script has successfully completed:

USBStick sucessfully created

I If this message is not displayed, the execution of the createUSBStick.bat script has failed. Look at the output which may contain the problem description. To locate the problem, you can additionally investigate the createUSBStick.bat, which is a pure text file.

3. After the createUSBStick.bat script has successfully completed, disconnect the USB stick from your PC using the "safe hardware remove" function.

2.2.3 Booting the server from the Update DVD / USB stick in Legacy mode and starting Update Manager Express

I Using Update Manager Express to install PSPs is not possible if the server has been booted from the Update DVD or USB stick.

I If your system does not reboot automatically after BIOS/firmware installation is completed, please terminate Update Manager Express explicitly to reboot your system.

I When booting the server from the Update DVD / USB stick, please use a separate USB stick to save the UME log file in case any errors occurred.

Starting Update Manager Express from the physical Update DVD or from the USB stick

To start Update Manager Express from the (physical) Update DVD or from a USB stick, proceed as follows:

Ê Switch on the server.

Ê Insert the current Update DVD in the server’s DVD-ROM drive or connect the USB stick to your server.

Ê Reboot the server, e.g. by pressing the reset button on the front or switching the server off and then on again after a few seconds.

Ê Once the server is started, press [F2] (BIOS setup) or [F12] (Boot Menu).



Ê In the BIOS setup / in the boot menu, change the boot sequence to “Boot from CD” / "Booting from USB device".

While booting the server from the Update DVD / USB stick, you will be asked to select your preferred GUI language:

Figure 1: Booting Update Manager Express from Update DVD/USB stick: Select Language

Ê Select your preferred GUI language.

The Update Manager Express main window is displayed, see section "Update Manager Express GUI" on page 48.

I In this case Update Manager Express is only able to update BIOS/firmware versions that are provided on the Update DVD / USB stick.



2.2.4 Booting the server from the Update DVD / USB stick in UEFI mode and starting Update Manager Express

It is possible to run Update DVD / USB stick in UEFI mode beginning from Update DVD 11.15.07 version.

You can enable UEFI support:

Ê During booting press [F2].

Ê Enter to BIOS menu.

Ê Choose Advanced tab.

Ê Choose CSM Configuration.

Ê Set Launch CSM to enabled.

Ê Set BOOT option filter to UEFI only.

Ê Save settings.

Ê Reboot the system.

Ê Press [F12].

Ê Select boot device UEFI DVD / USB.



The only difference between Legacy and UEFI modes for booting from DVD / USB stick is bootloader output:

Figure 2: Bootloader output by booting from DVD / USB stick in UEFI mode

It has the same functionality as Legacy mode.


Installing updates under Windows

2.3 Installing BIOS/firmware/drivers under Windows

Via the graphical user interface (GUI) of Update Manager Express you can install BIOS/firmware/drivers for all server components jointly or selectively for individual components.

Normally you will install the BIOS/firmware/drivers on your PRIMERGY server under Windows Server 2008/2012 in Update Manager Express offline mode. If the server does not run Windows Server 2008/2012, you can boot the system from the Update DVD and then install the BIOS/firmware with the help of Update Manager Express in offline mode.

BIOS/firmware/drivers are installed locally on the server on which Update Manager Express is started.

2.3.1 Requirements

Installing BIOS/firmware/drivers via Update Manager Express and installing BIOS/firmware via ASPs requires the following:

– For system identification, Update Manager Express requires that the ServerView agents are installed and running on the PRIMERGY server.

– To start Update Manager Express or to execute the ASPs, you require administrator rights.

– You must have sufficient space (> 1 GB) on the hard disk.

– To start Update Manager Express, a running Java Runtime Environment of at least Java version 7 is required. The environment variable for Java must be set.


Installing updates under Windows

2.3.2 Starting Update Manager Express under Windows Server 2008/2012

You start ServerView Update Manager Express from the Update DVD (see "Using the Update DVD ISO image (UPDATE_DVD_<version>.iso)" on page 20) or from a USB stick created from it (see "Creating a bootable USB stick from the Update DVD" on page 20). Depending on the server status, you have the following alternatives:

– Start Update Manager Express under Windows Server 2008/2012.

I If Windows Server 2008/2012 is running on your PRIMERGY server, you should normally use this procedure.

– Start Update Manager Express after booting the server from the Update DVD / USB stick.

I Choose this procedure if there is no operating system or no supported operating system on your server.

I Using Update Manager Express to install PSPs is only possible if Update Manager Express has been started on Windows Server 2008/2012.

I Starting Update Manager Express automatically installs the PrimeUp installation tool (see page 85) if no PrimeUp version or only an older one is currently installed on your system.

Under Windows Server 2008/2012 you start Update Manager Express as follows:

Ê Insert the Update DVD in the drive of your PRIMERGY server or connect the USB stick to your PRIMERGY server.

Ê Double-click the file UpdateMgrExpress.bat in the root directory of the Update DVD / USB stick.

The Update Manager Express main window is displayed, see section "Update Manager Express GUI" on page 48.


Installing updates under Linux

2.4 Installing BIOS/firmware under Linux

Via the graphical user interface (GUI) of Update Manager Express you can install BIOS/firmware for all server components jointly, or selectively for individual components.

BIOS/firmware are installed locally on the server on which Update Manager Express is started.

2.4.1 Requirements

Installing BIOS/firmware via Update Manager Express requires the following:

– For system identification, Update Manager Express requires that the ServerView agents are installed and running on the PRIMERGY server.

– To start Update Manager Express or to execute the ASPs, you require root privileges.


– The dmidecode command must be available on the target system.

– To start Update Manager Express, a running Java Runtime Environment of at least Java version 7 is required. The environment variable for Java must be set.

2.4.2 Starting Update Manager Express under Linux

You start Update Manager Express either via the CLI or via the GUI of your Linux system.

2.4.2.1 Starting Update Manager Express via the Linux CLI

Proceed as follows:

Ê Place the Update DVD in the drive of your PRIMERGY server or connect the USB stick to your PRIMERGY server.

Ê Create a directory of your choice:

mkdir <directory>


Starting Update Manager Express

Ê Mount the DVD or USB stick at the directory:

In case of the Update DVD, proceed as follows:

Ê mount /dev/cdrom <directory>

In case of a USB stick, proceed as follows:

Ê Identify the label of the USB stick:

ls -l /dev/disk/by-label/UPD_*

This command outputs UPD_<version>, e.g. UPD_111501.

Ê Mount the USB stick

mount LABEL=UPD_<version> <directory>

Ê Switch to the directory:

cd <directory>

Ê Start Update Manager Express with the following command:

sh UpdateMgrExpress.sh

Once Update Manager Express is started, the main window is displayed (see section "Update Manager Express GUI" on page 48).

2.4.2.2 Starting Update Manager Express via the Linux GUI

I Depending on the Linux distribution and version, the procedure for starting Update Manager Express from the Linux GUI may differ slightly from the one described here.

General procedure

To start Update Manager Express via the Linux GUI, proceed as follows:

Ê Insert the Update DVD in the drive of the PRIMERGY server or connect the USB stick to your PRIMERGY server.

Linux then mounts the DVD / USB stick automatically.

Ê Click UpdateMgrExpress.sh in the root directory of the DVD / USB stick to start Update Manager Express.



PXE-based mass update (without Deployment Manager)

System-specific features (e.g. with Red Hat Linux version 5)

Some Linux systems (e.g. Red Hat Linux version 5) use the noexec option for automatic mounting of the DVD, thus preventing you from starting Update Manager Express by clicking UpdateMgrExpress.sh.

In this case, proceed as follows:

Ê Place the Update DVD in the drive of your PRIMERGY server.

Linux then mounts the DVD automatically (with the -noexec option).

Ê Remount the DVD with the -exec option:

mount -o remount,exec /dev/cdrom <directory>

Ê Click UpdateMgrExpress.sh in the root directory of the DVD to start Update Manager Express.


2.5 PXE-based mass update in an environment without ServerView Deployment Manager

PXE-based update is primarily designed for huge server farms because, on the one hand, this solution involves more prerequisites but, on the other hand, enables unattended and massive parallel processing.

You have the following options for performing a PXE-based update:

– In a customized environment without ServerView Deployment Manager.

In this case, which is described in detail below, you have to integrate the PXE functions provided on the Update DVD into your already existing PXE environment.

– In an environment using the ServerView Deployment Manager.

ServerView Deployment Manager supports Mass Update Group Handling to perform a remote update of multiple servers. Both the ServerView Deployment Manager V6.40 and the Fujitsu ServerView PXE Mass Update Tools package must be installed for this purpose.

For details on Mass Update Group Handling, see the manual "ServerView Suite Deployment Manager."



For details on how to install the Fujitsu ServerView PXE Mass Update Tools package, see section "PXE-based mass update using ServerView Deployment Manager" on page 43.

I On the ServerView Deployment Manager server side, PXE booting is currently only supported for Windows systems.

2.5.1 Starting Update Manager Express via PXE (overview and prerequisites)

Starting Update Manager Express via PXE requires the following steps:

1. Integrating the PXE functions provided on the Update DVD into your already existing PXE environment

2. Creating the server-specific XML control files

3. Adapting the Start script

4. Initiating and monitoring the update process

I Important note!

Each time you use a new version of the Update DVD, you have to perform the above steps all over again.

Prerequisites

The target system that is to be booted must be within the reach of a PXE server and a DHCP server. Both the PXE server and the DHCP server must be located within the same subnet as the target system.

PXE-based server update is processed in two phases

PXE boot is processed in two phases:

1. In the first phase, the PXE server also acts as a TFTP server: The data needed for the PXE boot itself (e.g. the bootloader) is fetched from this TFTP server.

2. In the second phase, the application (Update Manager Express) and the Update Repository are fetched from a TFTP server. In this case, you have the option of either using the PXE server as the TFTP server or using a separate TFTP server.



After the target system has been booted in the PXE boot mode, the CentOS is loaded. Finally the start.sh script is loaded from the data TFTP server.

PRIMERGY type-specific update via XML profiles

System-specific control is done using XML profiles. Such an XML profile may contain either generic settings applying to all PRIMERGY servers of a group or exactly one update list for a specific PRIMERGY server type (see section "Creating the server type-specific XML control files" on page 38).

2.5.2 Integrating the PXE functions provided on the Update DVD

PXE boot is processed in two phases:

1. In the first phase of the PXE boot, in which the PXE server also acts as a TFTP server, the data needed for the PXE boot itself (e.g. the bootloader) is fetched from this TFTP server.

On the PXE server, you have therefore to create the following directory structure:

<TFTP Root >/UME_<version> providing the data for the PXE boot itself (phase 1).

I Although the name of directory is arbitrary, we suggest to use UME_<version> as directory name. This will make it easy for you to mentally associate the name with the contents of the directory.

2. In the second phase, the application (Update Manager Express) and the Update Repository are fetched from a TFTP server. You have the option of either using the PXE server as the TFTP server or using a separate TFTP server. In the following, the TFTP server used in the second phase of the PXE boot process is called "data TFTP server" for short.

On the data TFTP server, you have to create the following directories under <relative TFTP path> (e.g. Fujitsu):

– /Firmware– /Tools

The required files can be copied from the Update DVD as described in the sections below.



2.5.2.1 Setting up the <TFTP Root >/UME_<version> directory on the PXE server

<TFTP Root >/UME_<version> provides the data needed for the PXE boot itself (phase 1).

I Although the name of the directory is arbitrary, we suggest to use UME_<version> as directory name. This will make it easy for you to mentally associate the name with the contents of the directory.

Proceed as follows:

Ê Copy the following files as well as the pxelinux.cfg directory with its contents from the Tools/GENERAL/UMEpxeBoot directory on the Update DVD into the UME_<version> directory:

– Files linux, linux.0 (bootloader), and initrd

– Directory pxelinux.cfg with its contents

The complete UME_<version> directory is shown in figure 3.

Figure 3: Directory structure on the PXE server and PXE features on the Update DVD

I Normally, the boot loader (linux.0) is the only file that must be registered via PXE boot administration (dhcpd.conf). All other files can simply be copied or created.



Defining the data TFTP server by adapting the pxelinux.cfg file

In the last line of the pxelinux.cfg ASCII file configure the following:

– TFTP server that is used as the data TFTP server.

– Relative path name for the application files (Update Manager Express and the Update Repository) on the data TFTP server.

– Add the noFirewall parameter (optional).

Defining a separate data TFTP server

I By default, the PXE server is used as the data TFTP server.

If you want to use a separate data TFTP server, you have to modify the parameter root=tftp://$tftpserver$/<relativeTFTPpath> in the last line of the pxelinux.cfg file as follows:

Ê Replace the string $tftpserver$ by the IP address of the data TFTP server. The IP address must be in dotted decimal notation (e.g. 121.145.12.6).

I Both $-signs must be deleted.

Defining the relative path name for the application files on the TFTP server

To define the relative path name for the application files, you have to modify the parameter root=tftp://$tftpserver$/<relativeTFTPpath> in the last line of the pxelinux.cfg file as follows:

Ê Replace the string <relativeTFTPpath> by the path name where the application files (i.e. Update Manager Express and the Update Repository) are located on the data TFTP server. The empty string is allowed if the root directory of the TFTP server is used as path name.

Adding the noFirewall option

Firewall configuration sometimes causes problems while executing updates in PXE mode. To disable the firewall, add the noFirewall parameter between the initrd and mac parameters in the last line of the of the pxelinux.cfg file:

Append initrd=initrd noFirewall mac=901b0e310236 root=tftp://<ip-address>/Fujitsu



2.5.2.2 Setting up the directory on the data TFTP server

I Depending on the settings you have made in the pxelinux.cfg file, you create this directory on the PXE server or on the separate data TFTP server (see page 36).

In both cases you can arbitrarily choose the relative path name (e.g. Fujitsu) of the target folder into which you copy the application (Update Manager Express) and the Update Repository from the Update DVD. In the following, this path name is referred to as <relativeTFTPpath>.

The complete directory is shown in figure 4.

Figure 4: Directory structure on the data TFTP server and data sources on the Update DVD

In detail, proceed as follows:

1. Under <relativeTFTPpath>, create the folders Tools and Firmware.

2. Copy the complete Firmware folder from the Update DVD into the <relativeTFTPpath>/Firmware folder.

3. Under <relativeTFTPpath>/Tools, create a folder GENERAL.

4. In the GENERAL folder, create the folders UpdateMgrExpress and lib.

5. From folder Tools/GENERAL/UpdateMgrExpress/lib on the Update DVD, copy the files jdom-2.02.jar, SVCommonSwing.jar, and SVCommonUtil.jar into the folder <relativeTFTFpath>/Tools/GENERAL/lib.



6. From folder Tools/GENERAL/UpdateMgrExpress on the Update DVD, copy the ume.jar file into the folder <relativeTFTFpath>/Tools/GENERAL/UpdateMgrExpress.

7. From folder Tools/GENERAL/UMEpxeBoot on the Update DVD, copy the files squashfs.img and start.sh into the folder <relativeTFTFpath>/Tools/GENERAL/UpdateMgrExpress.

I squashfs.img contains the adapted CentOS. start.sh establishes the connection for starting Update Manager Express.

2.5.3 Creating the server type-specific XML control files

The following steps are required to create the server type-specific xml control files:

1. Copying additional program files from the Update DVD into an arbitrary folder on the data TFTP server.

2. Calling the XML-Converter to create the server type-specific control profiles.

3. Assigning the profiles to the individual server instances (i.e. PRIMERGY servers participating in the PXE-based update).

2.5.3.1 Copying additional program files from the Update DVD

Proceed as follows:

Ê Copy the following program files from the Tools/GENERAL/UMEpxeTools directory on the Update DVD into an arbitrary directory on the data TFTP server:

– XML-Converter.jar, which allows you to create the server type-specific control file

– BuildLabelFile.jar, which is needed by the XML Converter

– lib/jdom-2.0.2.jar

– genericProfile.xml (generic xml control file)



2.5.3.2 Calling the XML Converter for creating server type-specific xml control files

Proceed as follows:

1. Find out which types of PRIMERGY servers are involved in the PXE-based update.

2. For each affected PRIMERGY type, start the xml converter with the appropriate -system parameter as described below:

java –jar XMLConverter.jar –F|-f|-firmware|-firmware [...\]Firmware –nxml genericProfile.xml –system|-s|-S Dnnnn-XXnnnSn –output|-o UserProfile.xml [-architecture|-arch x86|x64] [-operatingsystem|-os|-OS <operatingSystem> ]

I The parameters -arch and -OS are optional (default: Not available).

DnnnnD number of the PRIMERGY system board type (e.g. D3249)

XXnnnSn (or XXnnnnMn)PRIMERGY type (e.g. TX300S7, TX1310M1)

XX stands for BX, RX, or TX.

n: 0 .. 9

<operating system>Possible values (Windows):

– Windows Server 2008– Windows Server 2008 R2– Windows Server 2012– Windows Server 2012 R2



Possible values (Linux):

– RedHat 5.11 – RedHat 6.4 – RedHat 6.5– RedHat 6.6 – RedHat 7.0– RedHat 7.1 – SuSE 10.0 – SuSE 11.0– SuSE 11.2– SuSE 11.3– SuSE 11.4– SuSE 12

I As the UserProfile.xml will be overwritten by the next execution of the XML-Converter, save the UserProfile.xml from the XML-Converter’s output directory into a directory of your choice.

I Each call of XML-Converter.jar will generate a separate UserProfile.xml file (i.e. the profile) for the corresponding PRIMERGY type. You can use each profile for updating an arbitrary number of PRIMERGY servers of the corresponding type.

I Parameters -architecture and -operatingsystem are optional. Default values are “Not available”.

3. Modify the UserProfile.xml files in order to save logging informations concerning the update process.

For each UserProfile.xml file, proceed as follows:

In the <postsequence> field of the <Control Settings> container, enter the access data of the FTP server on which the logging files are to be stored:

<command>,<ip-address>,<folder>,<username>,<password>

<command>Enter get-trace to save trace information.

Enter get-log to save logging information.

<ip address>IP address of the FTP server

<folder>Folder on the FTP server where the logging / trace information will be saved.



<username>User name of the account on the FTP server.

<password>Password for <username>

Example:

<postsequence>get-trace,172.0.0.1,UMERX600S4,Administrator,PASSWORD</postsequence>

2.5.3.3 Assigning the profiles to the individual PRIMERGY servers

Proceed as follows:

1. For each PRIMERGY server to be updated, create a folder UME<mac> in the root directory of the data TFTP server.

<mac>MAC address of the PRIMERGY server. The MAC address is represented by a string containing six groups of two hexadecimal digits without separators in between (e.g. A0B1C2D3E4F5).

2. Assign the appropriate profile to each PRIMERGY server by copying the corresponding UserProfile.xml into the UME<mac> folder of this server.

2.5.4 Adapting the start.sh script

To control on how the updated PRIMERGY servers behave once the update has completed, you can modify the start.sh script.

The last command in the start.sh script is as follows:

java -jar ume.jar -L trace.txt -bitlocker 0 -MAC $1 -F tftp://$2 -D 6 -progress -R -relpath $3

Modify this command as follows:

1. Remove the -progress parameter, which is only needed for PXE boot in connection with ServerView Deployment Manager.



2. Use exactly one of the following parameters to control how the target system will behave once the update has successfully completed:

-RThe -R parameter is preset in the start.sh script.

The target system will reboot and subsequently evaluate whether additional updates are to be made (e.g. in case of firmware dependencies).

-shutdownThe target system will shutdown if -shutdown is used instead of the -R parameter.

-stayThe target system will remain in the "CentOS booted" state if -stay is used instead of the -R parameter.

I The settings in the start.sh script apply to all systems. For more sophisticated settings (e.g. for tailoring the settings to fit each individual target system), you can configure your settings in the <postsequence> field of the <Control Settings> container in the related XML control files (UserProfile.xml):

<postsequence>{reboot | shutdown | | stay}</postsequence>

I In case both are configured, settings from UserProfile.xml overwrite settings from start.sh.

2.5.5 Initiating and monitoring the PXE-based update process

Initiating the PXE-based update process

Ê To initiate the PXE-based update, press [F12] on a PXE client (i.e. a managed server that is registered at the PXE server).


PXE-based mass update (using Update Manager)

Managing the updated PRIMERGY server

You can login on any of the managed servers during the update (after CentOS has booted) as well as once the update has completed. Logging information concerning the update process is displayed on the monitor.

Proceed as follows:

1. Press [ALT]+[F2] to access the second monitor.

2. On the second monitor, login with user "root" and password "ServerView".

in the directory /tmp/srcUME, you will find the Update Manager Express and all of its logging files and trace files.

3. For debugging and/or troubleshooting purposes, save the *.txt files from the /tmp/srcUME directory.

2.6 PXE-based mass update using ServerView Deployment Manager

ServerView Deployment Manager supports Mass Update Group Handling to perform a remote update of multiple servers. Both ServerView Deployment Manager as of V6.40 and the Fujitsu ServerView PXE Mass Update Tools package must be installed for this purpose.

If you want to use Mass Update Group Handling, you must install the ServerView PXE Mass Update Tools package. This package is available on the ServerView Suite DVD 2, which is a component of the ServerView Suite.

You will find the installer of the Fujitsu ServerView PXE Mass Update Tools package on the ServerView Suite DVD 2 under \SVSSoftware\Software\Deployment\UpdateManager Express Tools\

To install the ServerView PXE Mass Update Tools package, proceed as follows:

1. On the ServerView Suite DVD 2, change to the directory \SVSSoftware\Software\Deployment\UpdateManager Express Tools and double-click PXEMass.exe.



The welcome screen of the Installation Wizard for installing the Fujitsu ServerView PXE Mass Update Tools package opens:

Figure 5: Installing the Fujitsu ServerView PXE Mass Update Tool - Welcome Screen

2. Click Next. The License Agreement dialog box opens:

Figure 6: Installing the Fujitsu ServerView PXE Mass Update Tool - License Agreement

Accept the Licence agreement.



3. Click Next. The Destination Folder dialog box opens.

Figure 7: Installing the Fujitsu ServerView PXE Mass Update Tool - Destination Folder

Select the destination folder in which the Fujitsu ServerView PXE Mass Update Tools package is to be installed.

4. Click Next. The Update Repository dialog box opens.

Figure 8: Installing the Fujitsu ServerView PXE Mass Update Tool - Update Repository



Ê Select the source of the Update Repository and the Update Tools (Update DVD or local directory).

Ê Select the destination folder in which the Update Repository and the Update Tools are to be installed.

I The destination folder (e.g. Fujitsu) must be located under C:\Program files (x86)\Fujitsu\ServerView Suite\DeploymentService\TFtp

5. Click Next to start the installation.

The installation wizard indicates how the installation is progressing ...

Figure 9: Installing the Fujitsu ServerView PXE Mass Update Tool - Updating System...



... and informs you when the installation has been successfully completed:

Figure 10: Installing the Fujitsu ServerView PXE Mass Update Tool - Installation completed

6. Click Finish to complete the installation.


User interface

2.7 Update Manager Express GUI

The graphical user interface (GUI) of Update Manager Express looks nearly identical under Windows and Linux. In this section, the figures show the Update Manager Express user interface for the case that Update Manager Express has been started has been started in offline mode under CentOS 7.0.

When you start Update Manager Express, the System Type tab is displayed in the main window:

Figure 11: Update Manager Express - main window

Update Manager Express distinguishes between the operating modes Quick Mode, Normal Mode, and Expert Mode, each of which has a separate tab. Depending on which mode you choose, you will have different functionalities and options available to you when installing the BIOS/firmware/drivers (under Windows) or BIOS/firmware (under Linux).


User interface

You can choose from the following tabs:

System TypeIndicates the type of the PRIMERGY server, which is automatically determined when Update Manager Express is started.

ExitAllows you to exit Update Manager Express.

Quick ModeIn this mode the BIOS/firmware/driver installation (update) on the server components runs fully automatically.

Normal ModeIn this mode you can specifically select the individual server components whose BIOS/firmware/drivers you want to update.

Expert ModeThis mode gives you the option not only of updating the BIOS/firmware/drivers but also of resetting to an older BIOS/firmware/drivers version. Beyond that, the Expert Mode allows to update Hard Disk Drive firmware via HDD Flash - only in offline mode.

MaintenanceThe Maintenance tab, which is only shown in offline mode, allows you to run the PrimeCollect tool, which collects and stores system diagnostic information.

HelpDisplays the online help for Update Manager Express.

The following sections describe in detail the individual tabs.

I PSPs can only be installed when Update Manager Express is running under Windows Server 2008 or Windows Server 2012. PSP entries are of category PrimSupportPack-Win.

No PSP entries will be displayed in any of the individual modes if

– Update Manager Express is running on a Linux server.

– Update Manager Express is running on a server that was booted from the Update DVD / USB stick.


User interface - Quick/Normal Mode

2.7.1 Quick Mode / Normal Mode

In Quick Mode and Normal Mode, Update Manager Express automatically identifies all server components for which newer versions of BIOS/firmware images or drivers exist in the repository.

I It may be that Update Manager Express does not display all available updates within the first run. In this case, additional updates will be displayed in additional runs. It may therefore be necessary to start Update Manager Express several times to ensure that all available updates are installed.

Quick Mode

In the Quick Mode tab, Update Manager Express shows a table with the automatically identified server components together with the BIOS/firmware/driver versions to be installed. Clicking an entry in the Version column displays the associated release information.

Figure 12: Quick Mode (example: RX2560 M1)



StartStarts the BIOS/firmware/driver update for all displayed components.

AbortAborts the installation process. This button is only enabled after the update has begun.

Normal Mode

In the Normal Mode tab, Update Manager Express shows a table with the automatically identified server components together with the BIOS/firmware/driver versions to be installed. Clicking an entry in the Version column displays the associated release information.

Unlike in Quick Mode, in Normal Mode you can choose the server components whose BIOS/firmware/drivers you want to update, by selecting the options in front of the relevant component.

Figure 13: Normal Mode (example: RX2560 M1)



StartStarts the BIOS/firmware/driver update for all selected components.

AbortAborts the installation process. This button is only enabled after the update has begun.

Installation procedure

When you click the Start button in the Quick Mode or Normal Mode window, the updates are installed one by one.

Update Manager Express performs the entire installation in the background, produces little output and does not require any user input. The activities which arise during the update installations for the individual server components are logged by Update Manager Express in a temporary log file.

I Once the installation is started, the Quick Mode and Normal Mode tabs change as follows:

– Normal Mode tab: Shows an updated list of the selected updates and an additional Status column (layout is the same as the Quick Mode tab).

– Quick Mode and Normal Mode tabs: The Abort button is activated.



Also, the following information dialog advises you of the installation process (under Linux only):

Figure 14: Update Manager Express info

You have the following options:

– By clicking Abort you can cancel the installation process. In this case the installation process currently running on the relevant server component is completed first, but no further update installations are performed.

– By clicking a field in the Status column, you can find out about the logged installation steps for the relevant server component. You can tell when there is log data available for a component because the status in the corresponding status field is written in blue and the mouse pointer becomes a hand symbol when you move it over the field.



The Status field gives you the following information on the updates of the individual components:

I The status aborting/aborted only occurs if you cancel the installation with the Abort button.

The status component not present or found: already updated rarely occurs. In this case, Update Manager Express did not uniquely identify the component and therefore called the ASP, which either establishes that a component is not even present or that a newer version is already present.

Status Description

update necessary Update required (a new version has been found).

update in progress Update is running.

done Update successfully completed.

done; reboot required Update successfully completed. System must be explicitly restarted.

failed Update failed.

component not present Update failed because the system does not have the necessary hardware.

found: already updated Update failed. A newer version than the one in the update repository is installed on the system. Installing an older version is only possible in Expert Mode.

aborting The installation process has been cancelled with Abort and the system is waiting for the end of the current update.

aborted The installation process was cancelled with Abort and the indicated updates were not performed.

inapplicable update For some reasons update of a component cannot be executed. Click hyperlink in status field to obtain more information.

Table 3: Status of the updates


User interface - Expert Mode

2.7.2 Expert Mode

I Expert Mode should only be used by experts who have experience with BIOS/firmware/driver installation and know exactly the current hardware configuration (including installed BIOS/firmware/driver versions) of your server.

Figure 15: Expert Mode

Expert Mode allows you to perform the following updates:

– Updating BIOS/firmware/driver

– Updating Hard Disk Drive firmware via HDD Flash

I This feature is only supported if your target system was booted from the Update DVD or the USB stick.



2.7.2.1 Updating BIOS/firmware/driver

Unlike in Quick Mode or Normal Mode, in Expert Mode Update Manager Express does not create a list of the BIOS/firmware/driver installations to be performed. Instead, you must select and start each BIOS/firmware image individually in the Expert Mode tab.

I In Expert Mode you can only perform the BIOS/firmware/driver installation on one server component per installation process.

The Expert Mode tab has the following structure:

Figure 16: Expert Mode (example: RX200 S8)

The navigation section on the left shows entries for the various categories of server components: LanController, ManagementController, ScsiController, FibreChannelController, and SystemBoard.

Double-clicking an entry (e.g. SystemBoard) gives you a list of all BIOS/firmware/driver components of the corresponding category and enables the Install button.



To select a component, proceed as follows:

Ê Double-click the category you want (e.g. SystemBoard).

This displays all components of this category - distinguished by server and system board - for which the repository contains firmware images.

I The names of the BIOS/firmware images listed under SystemBoard and ManagementController show the server type as well as the D number or type of the management controller to which the relevant image can be applied.

Ê Click the component which is installed on your server. (In figure 16 on page 56 this is the system board for PRIMERGY servers of type RX200 S8.)

In the right-hand section of the Expert Mode tab, one or more BIOS/firmware images are offered for the installation (in figure 16 on page 56: BIOS image).

Clicking an entry in the Version column displays the associated release information.

Ê Select the option to the left of the BIOS/firmware image or driver (PSP) you want to use for the installation. The selected image or PSP can also have an older version status than the BIOS/firmware or driver (PSP) currently installed on the server component.

Ê In the Downgrade column, specify whether you want to allow a reset to an older version.

I If you have selected an older version than the currently installed one for the installation but you do not activate the Downgrade option, this will lead to an error during installation.



Ê Click the Install button to begin the installation.

I Update Manager Express performs the installation in the foreground and shows the status.

During the installation, Update Manager Express performs compatibility and dependency checks and in the case of discrepancies, aborts the installation process with an error message.

Compatibility/dependency checks normally comprise checking for example the system ID, chassis ID/board ID, operating system, availability of hardware and dependencies between installed and offered firmware versions.

Update Manager Express signals the end of an installation process with a dialog box containing the message Operation finished.

You can view the log file for the BIOS/firmware/driver installation by clicking the Logfile button. When booting the server from the Update DVD the Logfile button is deactivated.



2.7.2.2 Updating Hard Disk Drive firmware via HDD Flash

I Updating Hard Disk Drive firmware via HDD Flash is only supported if your target system was booted from the Update DVD / USB stick.

Figure 17: Expert Mode



To update Hard Disk Drive firmware via HDD Flash, proceed as follows:

1. Click on HDD Flash.

This opens the FIXdisk window displaying the hard disks:

– If updates are available, the following window is shown:

Figure 18: HDD Flash: FIXdisk window



– If no updates are available (i.e. all hard disks are up-to-date), the following window is shown:

Figure 19: HDD Flash: FIXdisk window: No updates are available.

2. Select the hard disk(s) whose firmware is to be updated via HDD Flash or click Select all to select all hard disks.

3. Click Flash to initiate the HDD Flash if updates are available.

A popup windows informs you that the update process may take several minutes:

Ê Click OK to confirm.



In the Status column, the string "Processing" is displayed for the corresponding hard disks, thus indicating that the HDD Flash is currently in process. Simultaneously, the status indicator across from the Select all button signals operational status.

Once the HDD Flash is complete, the result of flashing the selected hard disks is displayed in the Status column:

– "SUCCESS" if the HDD Flash has completed successfully.

– "FAILED" if the HDD Flash failed.

I If the HDD Flash failed, additional information is written to the corresponding log file. The log file is usually stored in the /tmp directory with the designation UME*.log, where the asterisk (*) stands for any sequence number. The additional log information from the FIXdisk tool will be copied into the log file.

4. Click Finish to close the FIXdisk window.



2.7.3 Maintenance

I The Maintenance functionality is only available if Update Manager Express is in the offline mode i.e. when Update Manager was started from the (physical) Update DVD or from a USB stick.

The Maintenance tab allows you to run the PrimeCollect tool, which collects and stores information on the hardware and software of your PRIMERGY server. This can be useful for the diagnosis of server problems.

Figure 20: Maintenance: Starting data collection (example: RX200 S8)



Figure 21: Maintenance: Data collection has finished (example: RX200 S8)

Current progress: ...%Progress bar indicating the data collection progress.

MessagesDisplays messages output by the PrimeCollect tool.

Save Clicking Save results in the following:

– If at least one USB device with a vfat file system is mounted, a file browser is opened allowing you to select a folder and save the archive.

– If no proper device could be found, an information is displayed prompting you to plug a properly formatted USB stick. You should save collected archive on external drive because booted file system is read-only.


Update Manager Express CLI

If no proper device could be found, an information is displayed prompting you to plug a properly formatted USB stick. You should save collected archive on external drive because booted file system is read-only.

Collect DataStarts the PrimeCollect tool

AbortAborts the PrimeCollect tool.

2.8 Update Manager Express CLI

You can also start Update Manager Express via the command line interface (CLI). Using the CLI allows you to run Update Manager Express in the background.

I You will find CLI sample scripts for Windows and Linux on the Update DVD.

I When started from the CLI, Update Manager Express outputs only Unicode text to the standard output (stdout). To save the output for later analysis and debugging, you should redirect standard output to a file.

Update Manager Express CLI does not output anything to stderr. Therefore it is not necessary to redirect output to stderr.

When started from the CLI, Update Manager Express returns a valid return code:

– Return code = 0: Execution was successful.

– Return code î 0: At least one error occurred.

This allows you to start Update Manager Express CLI from within a script.



2.8.1 Requirements and first steps

You cannot use the Update Manager Express CLI directly with the Update DVD because all start scripts contained on the Update DVD will start the GUI.

This requires you to write a new start script that uses the CLI.

I As it is not possible to add the new start script if Update Manager Express was booted from the Update DVD, you cannot use the CLI in this case.

Because Update Manager Express on the Update DVD includes all the software that is required for using the CLI, all you need to do is to write a new script that starts Update Manager Express. You provide this start script as a .bat file (under Windows) or as a .sh file (under Linux).

For first tests, we recommend to use the CLI this way. For details on how to write a start script please refer to section "Writing a start script for the CLI" on page 67.

Alternatively, you can proceed as follows:

1. Copy all components required for Update Manager Express to the hard disk or to a USB device.

2. Add an appropriate start script.

3. Use the CLI from the hard disk or from the USB device respectively.

The latter has the advantage of better performance and additionally allows you update remote systems that support a shared file system.



2.8.2 Writing a start script for the CLI

To write a start script for the CLI, proceed as follows:

1. Copy the script UpdateMgrExpress.bat (Windows) or UpdateMgrExpress.sh (Linux) from the root directory of the Update DVD to the hard disk of your server.

2. To find the Java Runtime Environment, the ume.jar archive and the Firmware directory, the script uses an environmental variable for the java executable and the relative path names. Therefore, you have to edit the script as follows:

Change the relative path names to absolute path names by prefixing each path name with the drive letter of the DVD drive containing the Update DVD.

3. Run the script to test your changes. If you have specified the appropriate absolute path names, the Update Manager Express GUI is started.

4. Add the CLI parameters to the script as shown in section "Calling Update Manager Express via CLI - Syntax and commands" on page 68.



2.8.3 Calling Update Manager Express via CLI - Syntax and commands

2.8.3.1 Calling Update Manager Express via CLI

To call Update Manager Express via CLI enter the following command line:

<path-to-java> -jar <path-to-ume.jar> -F <fw-tree> -cli <cli-command>

<path-to-java>Specifies the environmental variable / pathname to the java executable of the Java Runtime Environment (JRE) on the local system.

<path-to-ume.jar>Path to the archive UME.jar on the Update DVD.

<fw-tree>Specifies the path name of the directory containing the Firmware directory.

<cli-command>Specifies one of the commands described below.

I If ume.jar and/or <fw-tree> are not contained in the directory from which you start the command line, you must specify the corresponding path names and drives. E.g., this is the case when using the ume.jar and/or the Firmware directory from the Update DVD and using a new start script on the hard disk.



2.8.3.2 CLI commands

The Update Manager Express CLI comprises the following commands:

– list: Lists the updates that are available in Quick Mode.

– update: Installs all updates that are available in Quick Mode.

– updateList: Executes all updates specified in the component file (page 74).

list

The list command outputs to stdout the list of updates that are available in Quick Mode. Apart from the PrimeUp.msi file, which Update Manager Express might install on Windows Server systems, nothing is updated or installed.

<path-to-java> -jar <path-to-ume.jar> -F <fw-tree> -cli list

The output list is in table form and corresponds to the table provided by the Quick Mode tab of the Update Manager Express GUI (see figure 12 on page 50).

For every component proposed for installation the table contains a separate row. The columns of the table provide details of the individual components:

– Category: e.g. SCSIController

– Component: Name of the component

– Version: New version that Update Manager Express proposes to update/install.

– Installed Version: Currently installed version

I Update Manager Express does not output the list in the following cases:

– If Update Manager Express cannot recognize the system, the error message "system type not recognized" is output to stdout. Unlike the GUI, the CLI does not allow you to change the system type name.

– If Update Manager Express cannot find any components that need to be updated, the message "all components are updated" is output to stdout.

Example

In figure 22 an example is given for the output the list command writes to stdout.



Figure 22: Output of the list command (example)

update

The update command installs all updates that Update Manager Express suggests for the system.

<path-to-java> -jar <path-to-ume.jar> -F <fw-tree> -cli update

Using the update command is the same as clicking on Start in the Quick Mode tab of the Update Manager Express GUI (see figure 12 on page 50).

In addition to installing updates, the update command outputs a result list to stdout, which ends with an installation summary in table form.

For every component to be installed the table contains a separate row. The columns of the table provide details of the individual components:

– Category: e.g. SCSIController

– Component: Name of the component

– Version: New version that Update Manager Express tried to update/install

– Installed Version: Previously installed version

– Installation status:

If successful: "done" or "done;reboot"

If not successful:"component not present", "found: already updated", or "failed"



For every update / installation that did not succeed, Update Manager Express displays the corresponding log file.

I Update Manager Express does not install anything in the following cases:

– If Update Manager Express cannot recognize the system, the error message "system type not recognized" will be output to stdout. Unlike the GUI, the CLI does not allow you to change the system type name.

– If Update Manager Express cannot find any components that need to be updated, the message "all components are updated" will be output to stdout.

Example

The log file shown in figure 23 on page 72 refers to a situation where the third update has failed.



Figure 23: Log file of the update command: The third update has failed.



updatelist

Additionally to the commands list and update, which display/install all updates that Update Manager Express suggests for your system, the updatelist command allows you to explicitly specify the components you want to install. Unlike when using the Update Manager Express GUI in Expert Mode, you can update several components within the same run.

The result list provided by the updatelist command has the same format as the result list of the update command.

<path-to-java> -jar <path-to-ume.jar> -F <fw-tree> -cli updatelist -f <component-file>

<component-file>The component file is a text file in which you specify the components you want to install. For details see page 74.

Using the updatelist command is the same as clicking on Start in the Normal Mode tab or in the Expert Mode tab of the Update Manager Express GUI (see figure 13 on page 51 or figure 15 on page 55, respectively):

● To simulate Normal Mode, proceed as follows:

1. Use the list command to create a list of all updates suggested by Update Manager Express.

2. Get a properly formatted component file (see page 74) by editing the result file of the list command.

3. Call the updatelist command to install all updates.

● To simulate Expert Mode, proceed as follows:

1. Create a component file (see page 74) that specifies all components you want to install. The component file must contain at least one row.

2. Call the updatelist command with this component file to install all updates.

For every update / installation that did not succeed, Update Manager Express displays the corresponding log file.

I Only the statuses that are displayed as "Done" or "Done;reboot" in the GUI are considered successful.



Component file

For input, the updatelist command (see page 73) requires a component file (text file) that specifies all components you want to install or update. The individual components must be described in separate lines.

Each line has the following syntax:

<category>|<name>|[[<version>]|[down]]

I The vertical bar "|" is a terminal symbol that must be specified to separate the individual items described below. To improve readability, you may insert one or more blanks before and/or after each "|".

<category> Specifies the category of the component.

<name>Specifies the component name.

<version>Specifies the version of the component.Default: Highest version available in the firmware tree.

downAllows a downgrade. Default: No downgrade allowed.

I Specifying the "down" string only makes sense if <version> is specified. Otherwise nothing is installed, and the "found: already updated" error message is output.

I An empty component file results in the error message "empty component file".

I If Update Manager Express detected an incorrect line in the component file (spelling error, syntax error, specified component not found in the firmware tree), Update Manager Express starts the output list with an extra section. For each incorrect line, this section provides information on the reason for the incorrectness and also lists the incorrect line. These lines are ignored in the remaining output list as well as in the summary at the end of the output list.



The way Update Manager Express handles the individual lines of the component file differs depending on whether or not he associated component’s version is explicitly specified in this line:

● If Update Manager Express cannot recognize the system type, the following applies:

– For each line that contains no version number, Update Manager Express outputs an "Update not possible because System Type unknown" error message.

– For each line that contains a version number, Update Manager Express initiates the installation of the associated component.

● If Update Manager Express can recognize the system type, the following applies:

– For each line that contains no version number, Update Manager Express investigates the currently installed version of the associated component. If no update is necessary, Update Manager Express refuses an update outputting the "Update not necessary" error message.

– For each line that contains a version number, Update Manager Express initiates the installation of the associated component. However, this update will normally fail, unless the line contains the "down" string.

The behavior described above is due to the fact that lines without version number model Quick Mode and Normal Mode while lines including the version number model the Expert Mode.

Example

An example of a component file is shown in figure 24.

Figure 24: Contents of a component file (example)



runhddupdates

The runhddupdates command installs all available HDD updates.

<path-to-java> -jar <path-to-ume.jar> -cli runhddupdates

Using the runhddupdates command is the same as first clicking Select all and then Flash in the FIXdisk tab of the Update Manager Express GUI (see figure 18 on page 60).

I Important note!

On each of the system’s hard disk, the runhddupdates command installs all HDD updates available for this disk.

Return codes of runhddupdates:

The log file is usually stored in the /tmp directory with the designation UME*.wrk, where the asterisk (*) stands for any sequence number. The additional log information from the FIXdisk tool will be copied into the log file.

Value Description

0 Successful

1 Error

2 Up-to-date

Table 4: Return codes of the runhddupdates command


3 PRIMERGY Support Packages (PSP)

A PRIMERGY Support Package (referred to here as PSP for short) is the basic element for installing or updating drivers and software kits on your PRIMERGY server running a Windows Server operating system. PSPs are processed by the PrimeUp software tool, which you use to install or update drivers and software kits on the server components.

A PSP contains several packages, each of which incorporates a driver or software kit.

This chapter provides information on the following topics:

– Current versions of PrimeUp and PSPs

– PSPs (overview)

– Installing PSPs using the PrimeUp installation tool

– PrimeUp usage variants

– Examples

– How to get help

I Alternatively, you can use the ServerView Update Manager Express to install PSPs on your PRIMERGY server. Both ServerView Update Manager and ServerView Update Manager Express use the PrimeUp tool internally.

I For installing PSPs, we recommend that you use Update Manager Express because it takes care of dependencies and sequence.



Current versions of PrimeUp and PSPs

3.1 Current versions of PrimeUp and PSPs

The current versions of PrimeUp and the PSPs are available for download as follows:

● DVD ISO image UPDATE_DVD_<version>.iso (Update DVD)

You can update your server’s BIOS/firmware/drivers as follows:

1. Visit http://support.ts.fujitsu.com/Download/.

2. Select the appropriate PRIMERGY server type and model.

3. Under Select your operating system, select OS Independent (BIOS, Firmware, etc.).

4. Under Server Management Software - ServerView Update DVD, select ServerView Update DVD.

5. Download the DVD ISO image UPDATE_DVD_<version>.iso of the latest version from: http://support.ts.fujitsu.com/Download/ and create an Update DVD from it.

6. Use the Update DVD for the BIOS/firmware/driver update.

You will find PrimeUp and PSPs under Firmware/Tools (PrimeUp) and Firmware/PrimSupportPack-Win (PSPs).

For details, see section "Booting the server from the Update DVD / USB stick in Legacy mode and starting Update Manager Express" on page 24.

● Latest versions of PrimeUp and PSPs

In the update repository (Firmware) of Update DVD under Tools (PrimeUp) and PrimSupportPack-Win (PSPs).

You access this repository via Update Repository in the link collection (ServerView Suite – Software Downloads) or via http://support.ts.fujitsu.com/globalflash where FUJITSU offers constantly updated versions of PrimeUp and PSPs for downloading.

I An overview of the components and server models supported by the currently released PSPs is provided in the readme file for PSPs, which is also provided on the Update DVD.



PSPs (overview)

3.2 PSPs (overview)

A PSP consists of a zip archive containing the software, driver, installation tools and an xml description file. You can use a PSP to install the driver of a certain hardware component (e.g. Intel LAN controller) or to install software products (e.g. Intel Proset, ServerView RAID, ServerView agents). PSPs are processed by the PrimeUp installation tool (see section "PrimeUp installation tool" on page 85).

I PSPs are used in the ServerView Suite by all update management components (including ServerView Update Manager and ServerView Update Manager Express).

3.2.1 Structure of a PSP

Each PSP consists of two basic components:

– PSP description file (xml file)

– ZIP archive containing the directory structure containing the driver/software kit, installation tools.

An example of a PSP for ServerView agent software on the Update DVD is shown in figure 25 on page 82.

PSPs may contain a MainPackage

A MainPackage defines global cross-package dependencies that are relevant for all subsequent component-specific packages. Cross-package dependencies may include hardware/software dependencies concerning chassis ID, systemboard ID, model ID, PCI ID, firmware version, operating system version, and required software and software version. Therefore, the cross-component dependencies are automatically checked to be fulfilled before any of the subsequent component-specific packages will be checked e.g. for an installed incompatible (rivaling) software package.

I A main package is not necessarily available. If no main package is available, PrimeUp as of version 1.17.03 automatically selects "PRIMERGY" and "PRIMEQUEST" as default model-IDs. Older of PrimeUp versions ignore main packages completely.


PSPs (overview)

PSPs contain component-specific packages

A PSP provides a set of packages, each referring to a corresponding section in the PSP description file (see below). A package represents the actual product (driver or software kit) that is to be installed (e.g. driver for Windows Server 2008 R2). Within the same PSP the individual packages contain the different versions of the same type of driver or software kit.

PSP description file (xml file)

The description file (xml file) is the basic component of the update mechanism used by PrimeUp for updating drivers and software kits.

For each PSP the corresponding xml file contains the following information:

– Purpose of the PSP (i.e. PSP name), e.g. PCI_Express_Driver K for Intel(R) Gigabit Ethernet LAN Adapter 82578DM

– Current PSP version and its contents, e.g. Version 3.00.01: Drv 11.2.19.0 (SW-Kit 14.7), W2K[3|8](x64)(R2)

– In many cases: Installation priority

– Description of the MainPackage, if available, of the PSP. The description provides information on overall cross-package dependencies between the individual component-specific packages.

– Description of all component-specific packages contained in the PSP. For every component-specific package, information is provided on the package version and on hardware/software dependencies such as model ID, chassis ID, system board ID, PCI ID, firmware version, operating system version, and required software and software version.

– Checking instructions that evaluate hardware and software dependencies and check the availability of the required hardware and software.

– Control instructions that control the processing of the PSP by PrimeUp.


PSPs (overview)

This information allows PrimeUp to perform the following tasks:

– Evaluate whether the hardware (model, chassis and system board, or PCI ID) for which the driver is valid is present in the system,

– Check hardware / software requirements and dependencies (e.g. Windows version), and,

– If applicable, perform the installation, update or removal of the driver or software kit.

PSP zip archive

The PSP ZIP archive includes a directory structure containing all files that are needed for installing the PSP, i.e. driver/software kit, installation tools.

Release notes

The relnotes.txt file contains the release notes on the PSP.

3.2.2 Tree structure of a PSP repository

A PSP is provided in a directory that has the name of the PSP. Different PSP versions (if available) are located in the corresponding version-specific subdirectories. Each PSP folder of each of the version-specific subdirectories comprises two basic PSP components, among others:

– PSP description file (xml file)

– ZIP archive containing the directory structure containing the driver/software kit and installation tools.

To be processed by PrimeUp, PSPs can be provided as follows:

– Within a flat directory

– In a tree structure (e.g. on the Update DVD)


PSPs (overview)

The example shown in figure 25 uses the NTAgents PSP to explain the tree structure.

Figure 25: Example of a repository view and the PSP contained

Package (here: for i386 systems)

PSP of version 3.01

represents the actual product.


PSPs (overview)

3.2.3 Scan PSP

Besides "normal" PSPs, which you use to update driver or software kits on your PRIMERGY server, there is a special PSP called the Scan PSP (FSC_SCAN). The Scan PSP includes a set of distinct xml files that are dedicated to normal PSPs.

Figure 26: Scan PSP and PSP.xml content

The contents of Scan PSPs are used to create initial PSP registry entries (see "Creating initial ("faked") PSP registry entries" on page 93).


PSPs (overview)

3.2.4 PSP versioning

PSP versioning distinguishes two different types of version numbers, both of which are part of the PSP description file (xml file). The PrimeUp installation tool uses these version numbers to decide whether a PSP is to be installed or not (see section "PrimeUp version handling" on page 87):

● PSP version number

The PSP version number has the following form:

<major-version>.<minor-version>.<major-build>.<minor-build>

I PrimeUp only checks the <major-version>.<minor-version> part of the PSP version number. The <major-build>.<minor-build> part is ignored.

The semantics are as follows:

– A change of <major-version> reflects changes in the list of supported Windows operating systems (e.g. a new Windows version was added).

– A change in <minor-version> reflects changes to the software contained by a PSP (e.g. a new driver / software-kit version was implemented or added).

– Changes to the <major-build> indicate that the PSP supports a new server system or controller device (e.g. RX100 S7 and/or LSI controllerLSI SAS 3442E-R).

● Package version number of the MainPackage and the component-specific packages.

The package version number indicates the version of a driver or software kit.

I In the case of device drivers, there is also a number specifying the driver date (e.g. Date="12/04/2015"), which is used to check how up-to-date the driver is.

I MainPackages may not have a version or date.


PrimeUp installation tool

3.3 PrimeUp installation tool

The PrimeUp installation tool is a component of the Update Management of the ServerView Suite.

PrimeUp allows you to easily update the drivers and software kits of your PRIMERGY servers. For this purpose, a separate installation package (PRIMERGY Support Package, PSP, see page 79) is available for each component of the server, containing the driver / software kit and a description file necessary for the installation.

An overview of the components and server models supported by the current PrimeUp version can be found in the readme file for PSPs.

3.3.1 PrimeUp functionality

With PrimeUp you can:

– Handle PSPs within a plain directory, even if the directory contains more than one PSP.

– Handle PSPs within a directory structure that features a well-defined tree structure.

– Find out the system board, chassis, and model information even if no ServerView agents are installed.

I If PrimeUp cannot automatically find out system board, chassis, and model information, or if you prefer to overwrite the automatically detected values, three options (-b, -c, -m see page 100) allow you to specify system-board, chassis, and model information explicitly.

– Generate a detailed list of PSPs that can be used for installing or updating drivers and/or software kits.

– Display all currently installed PSPs.

– Perform a simulated installation for testing purposes.

– Install or update using PSPs.

– Display the order for installing applicable PSPs.

– Check whether the currently installed PrimeUp version is sufficient for handling new PSP elements and/or attributes.

– Discover device drivers and software kits on a PRIMERGY server.


Installing PSPs using PrimeUp

– Check for installed incompatible (rivaling) software packages.

– Check whether an appropriate PSP already exists for the driver or software kit.

– Create initial registry entries for applicable PSPs, i.e. the following is written into the registry for each of the PSPs: version data of an installed driver / software kit, version of a corresponding PSP.

3.3.2 Installing PSPs using PrimeUp (overview)

This section provides general information on how PrimeUp proceeds when processing PSPs. While it may not be needed for routinely updating drivers and software kits, this information may be useful for more sophisticated update scenarios using PrimeUp.

I To use PrimeUp, you need administrator rights.


I PrimeUp must be started on the server which is to be updated.

I Use of PrimeUp via Terminal Services Session or Telnet Session is not allowed.

In detail, this section explains the following:

– How to start PSP installation.

– How PrimeUp handles PSP versions.

– How PrimeUp detects the chassis ID, systemboard ID, and model ID of the server to be updated.

– How PrimeUp works in approximate steps.

– How PrimeUp interacts with the Windows registry.



3.3.2.1 Starting PSP installation

The installation of PSPs with the PrimeUp tool is controlled on one server via command line interface using parameters and the associated options. You can also create scripts to update more than one system.

In both cases installation only occurs if the integrated control mechanism in the PrimeUp tool recognizes that installation is possible and permitted based on the detected hardware and software components.

I PSPs must be accessible for PrimeUp via network. If this applies, updating drivers and software kits does not require the PSPs to be available locally on the system.

Updates can be installed which are located locally on the server, on the Update DVD, or in a storage location in your internal network which PrimeUp can reach via the network. Please also read the section "Important notes" on page 112.

3.3.2.2 PrimeUp version handling

I PrimeUp uses an internal version-handling algorithm based on the PSP version number (see page 84) to decide whether or not to install a PSP. PrimeUp version handling may lead to different results depending on the parameters (-update, -force, -reginit) you specify when calling PrimeUp (see section "PrimeUp - Parameters and options" on page 100).

To decide whether or not to install a PSP, PrimeUp proceeds as follows:

● PrimeUp ignores the <major-build>.<minor-build> part of the PSP version number.

● PrimeUp checks dependencies in a MainPackage first. These dependencies must be fulfilled because otherwise normal packages will not be considered and PrimeUp treats the PSP as "not applicable".

● PrimeUp checks for hardware and software dependencies.

– At first, PrimeUP checks the cross-package dependencies defined in the MainPackage. If not all cross-package dependencies are met, PrimeUp treats the PSP as "not applicable" without considering the component-specific packages.

– Only if all cross-package dependencies are met, PrimeUp checks the individual component-specific packages for dependencies.



● If the -force parameter is specified, PrimeUp will reinstall / update the PSP, even if the version of the new PSP is older than the version of the already installed PSP.

● If the -update parameter is specified, PrimeUp compares the PSP version number of the new PSP with the version number of the already installed PSP. Depending on the result of the version check, PrimeUp proceeds as follows:

– If the already installed PSP has a newer version than the new PSP: No installation will be done.

– If the already installed PSP has the same version as the new PSP: PrimeUp checks whether the new PSP provides a new package (driver / software kit). For each package contained in both the new and the already installed PSP, PrimeUp compares the corresponding package versions (package dates in the case of drivers).

PrimeUp will only install new packages and packages whose version/date differs from the new to the already installed version.

– If the already installed PSP has an older version than the new PSP: PrimeUp checks whether the new PSP provides a new package (driver / software kit). For each package contained in both the new and the already installed PSP, PrimeUp compares the corresponding package versions (package dates in the case of drivers).

PrimeUp will only install new packages and packages whose version/date differs from the new to the already installed PSP.

● If the -reginit parameter is specified, PrimeUp performs the version check as described in the case of -update.

I However, PrimeUp will not install packages, but only create corresponding initial ("faked") entries in the registry.



3.3.2.3 How PrimeUp detects the chassis ID, system board ID, and model ID of your server

You can use the parameters -b and/or -c and/or -m to explicitly inform PrimeUp of the chassis ID, board ID, and model ID of the server to be updated (see section "PrimeUp - Parameters and options" on page 100). Otherwise, PrimeUp tries to automatically detect chassis ID, board ID, and model ID as described below:

I An explicitly specified chassis ID and/or board ID and/or model ID (parameter -c and/or -b and/or -m) has a higher priority than corresponding values that are automatically detected by PrimeUp.

1. PrimeUp queries WMI (Windows Management Instrumentation).

2. If step 1) fails, PrimeUp queries the ServerView agents (if running) for the server type.

3. If step 1) and step 2) fail, parameters -b and/or -c and/or -m must be specified.

3.3.2.4 How PrimeUp works

PrimeUp can handle PSPs that are provided in a plain directory or in a well-defined tree structure. The following describes how PrimeUp works in approximate steps:

1. PrimeUp generates an internal list of available PSPs that reside in a plain directory or in a directory tree structure, or are specified in the PrimeUp command line. To do this, PrimeUp scans for the corresponding description files (xml).

2. PrimeUp defines the PSP installation sequence for updating or installing drivers and/or software kits. The installation sequence is predetermined by the value of the Priority attribute specified in the description files (xml) of the individual PSPs.

I At first, PrimeUp processes all PSPs of priority class 1, then all PSPs of priority class 2 are processed, and so on.

Within the same priority class, PSPs that require an immediate system reboot after installation are put to the end.

3. PrimeUp scans the current PSP registry entries and generates an internal list of registered PSPs.



4. PrimeUp processes the list of available PSPs (see step 1) by checking each PSP’s suitability for the current system environment. To do this, PrimeUp checks the main packages and all other packages within each PSP by applying a set of dependency checks.

To perform the dependency checks on the individual PSPs, PrimeUp proceeds as follows for each PSP:

a) First, PrimeUp checks whether the description file (xml) of the PSP is valid for the current system environment (system identification).

b) If step a) is successful and a main package is available, PrimeUp performs dependency checks defined in the MainPackage (e.g. checking for rivaling installed software package, availability of a device, etc.).

c) If step a) and/or step b) is/are successful, PrimeUp performs some additional checks defined in normal packages (e.g. checking for rivaling installed software packages, checking availability of the device, operating system, availability of another PSP):

– If none of the packages passes the check, PrimeUp skips (ignores) the PSP.

– If at least one of the packages passes the check, PrimeUp initiates the desired package update/installation.

5. If the parameter -force or -update is specified, PrimeUp installs/updates drivers and/or software kits according to PrimeUp version handling (see page 87) and the rules specified in the description file (xml).

For drivers and software kits that are actually installed/updated by calling PrimeUp with -update or -force, PrimeUp modifies/creates the corresponding registry entries and sets authenticity to "real".

6. If the parameter -reginit is specified, PrimeUp creates initial PSP registry entries (see page 93).

7. During processing, PrimeUp creates a log file in the directory where PrimeUp normally extracts and processes PSPs (e.g. \Documents and Settings\<user name>\LocalSettings\Temp\PrimeUp).

8. To detect already installed drivers and software kits, PrimeUp scans the description file (xml) for software-kit identification data (e.g. upgrade key for MSI packages, driver date) and searches the currently installed Windows operating system for the corresponding data.

PrimeUp uses Windows functions to automatically detect the corresponding driver data for each hardware device.



3.3.2.5 How PrimeUp interacts with the Windows registry

PrimeUp can create PSP entries in the Windows registry.

By default, PrimeUp scans the Windows registry for PSP registry entries before installing a driver or software kit. If it does not find any PSP registry entries, PrimeUp assumes that PSPs and associated drivers and/or software kits are not yet installed on your server.

However, there may already be drivers and software kits on your server that have been previously installed via another installation tool. These drivers / software kits may have an older, equal, or newer version than the corresponding drivers / software kits that PrimeUp is due to install.

I The behavior described above may result in unintended downgrades or updates. To avoid this problem you can call PrimeUp with the -reginit parameter (see page 92.)

Attributes of a PSP registry entry

PrimeUp writes the following data into a registry entry:

Name Meaning

authenticity Indicates whether the PSP entry is an initial ("fake") or a "real" one.

UpgradeCode For MSI products.

ProductCode For MSI and IS products (if available).

UninstallKey For products with "uninstall command" in registry

Package_Flag_String This flag indicates the product type.

Certified Indicates whether the driver / software kit is certified.

VVID Software pool ID

driverVersion / SoftwareVersion

Version of an installed driver / software kit; otherwise "0.0.0.0"

packageDate Date of an installed driver / software kit; otherwise "0/0/0"

PSP version(versionMajBuild,versionMajor,versionMinBuild,versionMinor)

Matched PSP version



The authenticity attribute indicates the status of a new PSP. Possible authenticity values are shown in table 5:

Calling PrimeUp using the -reginit parameter

To prevent unintended downgrades or updates, you can specify the -reginit parameter when calling PrimeUp:

Primeup -reginit <xml file> [-v]

This causes PrimeUp to initially perform an inventory of all of your server’s hardware components and associated drivers. PrimeUp then checks the detected hardware/driver components against the list of PSPs to be processed (i.e. new PSPs).

For each hardware/driver component and software kit that is already installed on the server, PrimeUp scans the list of new PSPs for a corresponding PSP.

I In the case of a software kit, the description file (xml) of the corresponding PSP provides identifying features (e.g. upgrade or product code of MSI packages) that allow PrimeUp to check the system for an already installed version of the software kit.

Authenticity value Meaning

real New driver /software kit installed.

fake,- Installed driver / software kit is older.

fake, Installed driver / software kit matches.

fake,+ Installed driver / software kit is newer.

fake,unknown driver / software kit is not installed.

Table 5: Possible authenticity values of a PSP registry entry



Creating initial ("faked") PSP registry entries

Each time PrimeUp detects a PSP corresponding to or matching an already installed driver or software kit, it creates a special PSP registry entry known as as an initial ("faked") registry entry.

PrimeUp proceeds as follows:

1. PrimeUp writes the actually installed component’s version (date in the case of drivers) into the initial registry entry.

2. In addition, PrimeUp writes the PSP version into the initial registry entry. Depending on the situation, PrimeUp inserts the following version value:

– If the data (e.g. version) of an already installed driver / software kit matches the data of the corresponding driver / software kit provided by the (new) PSP, PrimeUp passes the PSP version unchanged into the initial registry entry.

– If the data (e.g. version) of the installed driver / software kit is newer than the data of the driver / software kit provided by the new PSP, PrimeUp adjusts the PSP version to:

99.99.99.99

– If the data (e.g. version) of the installed driver / software kit is older than the data of the driver / software kit provided by the new PSP, PrimeUp adjusts the PSP version to:

<majorVersion>.<minorVersion>-1.99.99

I If a PSP description file (xml) provides no identifying feature for the associated software kit, even PrimeUp -reginit cannot find the software kit. Provided that all dependencies documented in the description file are fulfilled, PrimeUp creates a ZeroVersion entry for this PSP in the registry (see "ZeroVersion registry entries" on page 94).



Creating initial registry entries using a Scan PSP

You can also use the contents of a Scan PSP (see page 83) to create initial PSP registry entries.

Proceed as follows:

1. Call PrimeUp to install a Scan PSP, e.g.:

PrimeUp -update FSC_SCAN

2. Call PrimeUp with the -mappsp parameter:

PrimeUp -reginit -mappsp

This causes PrimeUp to take all PSPs from the installed Scan PSP and check them. PrimeUp creates adequate initial registry entries for applicable PSPs.

ZeroVersion registry entries

If during processing of PrimeUp -reginit a PSP passes all dependency checks, but no appropriate / corresponding driver or software kit is already installed, PrimeUp creates a new PSP registry entry known as a ZeroVersion registry entry. A ZeroVersion entry is an initial ("faked") registry entry whose version and date attributes are all set to "0.0.0.0" and "0/0/0" respectively.

How "PrimeUp -reginit" works

The following describes in detail how PrimeUp proceeds when called with the -reginit parameter.

1. PrimeUp scans for all hardware components available on the server (especially PCI controllers and associated device drivers), and stores the detected data in a PrimeUp-internal list.

2. PrimeUp scans the registry for all available PSP registry entries and inserts them in a PrimeUp internal list.

3. PrimeUp deletes all ZeroVersion entries from the registry.

4. PrimeUp deletes all PSPs (registry entries, current PSP data) whose installation requirements are no longer met. This, e.g., applies if the corresponding hardware has been removed.



5. For every newly received PSP made available via CLI, via directory (parameter -D), or via the -gftree or -tree parameter, PrimeUp checks whether the PSP’s dependencies are fulfilled:

– If a PSP fulfills all software dependencies, but no corresponding driver or software kit is installed on the server, PrimeUp creates a ZeroVersion entry for the PSP (see page 94).

I If a PSP description file (xml) provides no identifying features for the associated software kit, even PrimeUp -reginit cannot find the software kit.

– If a valid PSP registry entry already exists for the PSP(i.e. authenticity="real"), PrimeUp proceeds as follows:

– The PSP entry is deleted from the registry if the following applies:

All PSP dependencies are fulfilled but at least one associated component (driver or software kit) is no longer available on the server.

– Both the PSP registry entry and the PSP data are deleted if at least one prerequisite required for installing the PSP is no longer met (e.g. if the corresponding controller is no longer available on the system).

– The PSP registry entry will persist if PrimeUp could actually detect the associated driver or software kit and all installation requirements (dependencies) are still met.

– Otherwise, PrimeUp writes the corresponding version (in the case of software kits) or date (in the case of drivers) to the registry. The PSP version (modified if necessary) is also written to the registry (see "Creating initial ("faked") PSP registry entries" on page 93).

6. If a PSP description file (xml) provides no identifying features for the associated software kit, even PrimeUp -reginit cannot find the software kit. Provided that all dependencies documented in the description file are fulfilled, PrimeUp creates a ZeroVersion entry for the PSP in the registry.


Requirements for PrimeUp

3.3.3 Requirements for PrimeUp

PrimeUp and the PSPs are available for the Microsoft server operating systems Windows Server 2008 / 2008 R2 and Windows Server 2012 / 2012 R2.

In particular, the requirements described below should be noted.

I For detailed information about the supported servers, software requirements and supported drivers, please refer to the Readme file that you will find on the Update DVD.

3.3.3.1 Supported servers

PrimeUp is available for the server families TXnnn, RXnnn, ECnnn, BXnnn, CXnnn, and PQnnn. Exact specifications can be found in the readme file for PSPs.

3.3.3.2 Software requirements

To use PrimeUp you need Windows Server 2008 or Windows Server 2012. See also the notes in the readme file for PSPs.

I Use of PrimeUp via Terminal Services Session or Telnet Session is not allowed.

3.3.3.3 Supported drivers

A table showing the supported drivers can be found in the current readme file for PSPs. By default only certified driver software is updated.


Installing / uninstalling PrimeUp

3.3.4 Installing / uninstalling PrimeUp

PrimeUp is provided on the Update DVD as both the PrimeUp.msi MSI package and the PrimeSetUp.exe InstallShield package.

I The PrimeUp.msi and PrimeSetUp.exe packages can be found under Firmware/Tools on the Update DVD or under Tools in the Update Repository of ServerView Update Manager. You access this repository via Update Repository in the link collection (ServerView Suite – Software Downloads) or via download at http://support.ts.fujitsu.com/globalflash.

I Important note:

Please use the MSI package PrimeUp.msi only for a new installation of PrimUp. For upgrading from an older, already installed PrimeUp version, please use PrimeSetUp.exe.

3.3.4.1 Installing PrimeUp

As the administrator, you install PrimeUp locally on your server with the adequate installer.

I To use PrimeUp, you need a knowledge of the system and administrator rights. To allow safe resetting in the event of errors, you should perform a backup beforehand.

Use of PrimeUp via Terminal Services Session or Telnet Session is not allowed.

You start the installation process by

– selecting the PrimeUp MSI package, opening the pop-up menu with the right mouse button, and selecting from it the Install function,

or

– selecting the PrimeSetup package, opening the pop-up menu with the right mouse button, and selecting from it the Run as Administrator function,

or

– double-clicking PrimeUp.msi or PrimeSetUp.exe.



Installing / uninstalling PrimeUp

You will be guided through the installation with a dialog which begins with a welcome screen and ends with an installation message.

I The default installation path is \ProgramFiles\Fujitsu\ServerView Suite\PrimeUp.

It is recommended that you always use the same installation directory for the installation.

3.3.4.2 Uninstalling PrimeUp

PrimeUp is uninstalled via the Windows menu. Proceed as follows:

You can remove PrimeUp via the Windows menu:

Ê Select Start - Control Panel - Add or Remove Software.

Ê Select Fujitsu ServerView Suite - PrimeUp.

Ê Click Remove.

I PrimeUp is updatable, i.e. to install a new version you do not need to uninstall the existing one.


Starting PrimeUp

3.3.5 Starting PrimeUp

Following successful installation, as the administrator you can start PrimeUp via the input prompt without specifying the installation directory. The entry for the system path is created during the installation.

I You cannot start the program by double-clicking PrimeUp.exe because it is a command-line tool.

Example

Starting PrimeUp with the -? parameter without specifying the installation directory.

Figure 27: Starting PrimeUp with the -? parameter


Parameters and options

3.3.6 PrimeUp - Parameters and options

Syntax

I You may specify the parameters in any order.

The following explanation of the parameters is arranged with regard to functional aspects.

PrimeUp [-? | -b <board> | -c <chassis> | -m <model> | -d <infolevel> |-D <dir> | -force | -gftree [gfroot_path] | -help | -installed | -list | -noreboot | -reginit | -simulate | -tree [pathname] | -uncertified | -update | -v | -vv | -vvv | -version | <xml>]

Parameters

-?, -helpDefault.Outputs a list of all parameters and options with brief descriptions .(See example in section "Starting PrimeUp" on page 99.)

-c <chassis> -b <board> - m <model>Sets or changes chassis, system board and/or model information, depending on whether PrimeUp could automatically detect the corresponding information (see section "How PrimeUp detects the chassis ID, system board ID, and model ID of your server" on page 89).

I Parameters -b, -c and -m must be specified together. However, for some systems you need not explicitly specify the chassis ID (parameter -c) and system board ID (parameter -b) and model ID (parameter -m). If this applies and only the chassis ID is available, you can specify <board> and / or <model> as "unknown" and vice versa.

I Explicitly specified -b, -c, and -m parameters have a higher priority than any chassis and/or system board and/or model information automatically detected by PrimeUp.

-c <chassis> sets or changes the chassis information (e.g. RX2540 M1).

-b <board> sets or changes the system board information (e.g. D3289).

-m <model> sets or changes the model information (e.g. CELSIUS).

Example

For RX2540 M1, you must enter D3289.



-file <pathname> Processes a list of PSPs that are provided in the file specified by <pathname>. PSPs must be specified using the complete path name.

-D <dir>Sets the (flat) directory containing the PSPs.This parameter must be specified if the PSPs are not in the directory from which PrimeUp is called (default installation source).

-tree <pathname>Searches for PSPs in a directory that is compliant with ServerView Update Manager. In contrast to the -gftree parameter, you must explicitly specify the root directory of the tree that contains the PSPs. The root directory can have any name.

-gftree [gfroot_path]Searches for PSPs in a directory that is compliant with ServerView Update Manager. PrimeUp automatically appends the directory name PrimSupportPack-Win to the end of the path name.

-setfile <root_path> Searches for PSPs in a directory that is compliant with ServerView Update Manager. PrimeUp automatically appends the directory name PrimSupportPack-Win to the end of the path name.

I The directory PrimSupportPack-Win must contain a file ELEMENTS_OF_SET.txt. Each line in ELEMENTS_OF_SET.txt must specify a PSP using the complete path name (like with the -file parameter, see above).

That way, you can define a PSP set that represents a subset of all PSPs contained in the tree. This may be useful if you do not want to always use the most recent version (unlike in case of the -tree parameter, see above).



-listCreates a list of all PSPs with version numbers which would be installed.PrimeUp does not install the PSPs.

Each entry contains one of the following labels:

-simulatePerforms a simulated installation for each PSP. The processing of the packages ends before the installation command is called. It can therefore be checked for each PSP whether an installation is possible.

Each entry contains one of the following labels:

-uncertifiedEnforces the installation of non-certified PSPs. The parameter works in combination with -update, -force, or -reginit.

-updateDefault if both -update and -force are not specified.Installs updates using the currently available PSPs.Only certified drivers are installed. (Default)To also install non-certified drivers the parameter -uncertified is required.

-forceForces the installation. The specified PSP is installed even if a later or same version of the package already exists on the system.Only certified drivers are installed. (Default)To also install non-certified drivers the parameter -uncertified is required.

DO PSP will be installed.

SKIP PSP is skipped.

N/C PSP is not certified.

DO PSP will be installed.

SKIP PSP is skipped.

N/C PSP is not certified.

N/A PSP is not applicable.



-reginitCreates initial PSP entries in the registry. No PSPs will be installed. Only certified drivers are considered. (Default) To also consider non-certified drivers the parameter -uncertified is required.

PrimeUp detects drivers and software kits and creates the appropriate version entries. For details of calling PrimeUp with the -reginit parameter, see "How "PrimeUp -reginit" works" on page 94.

If you use the -reginit parameter in combination with the -mappsp parameter, PrimeUp will take PSPs from an installed Scan PSP (see page 83), check them, and create the corresponding registry entries.

-mappspCan only be used in combination with the -reginit parameter.Takes PSPs from an installed Scan PSP (see page 83) and checks them. PrimeUp then processes these PSPs according to the -reginit parameter.

-norebootPrevents the immediate reboot called for in the description file (PSP.XML). PrimeUp outputs return code 2 and makes an entry in the OS event log file. Using this parameter only makes sense in a script with which the return code is evaluated and the reboot is script-controlled. If the parameter is not specified, PrimeUp performs the reboot itself and, once the system has restarted, continues the PrimeUp task. Which PSPs require immediate reboot can be found in the PSP list in the current readme file.



-d <infoLevel> Determines the debugging / logging level (info level) using a hexadecimal number. Calling PrimeUp -hh lists the available debug options.

The following debug options are available for <infoLevel>.

I You can specify several debug options at the same time by connecting the corresponding hex values by the bitwise OR operand. Useful combinations result in e.g. -d 1, -d 20, -d 120, -d 338.

For detailed information on evaluating the PSP installation process and debugging, see section "Evaluating the installation process" on page 109.

-hhOutputs a list of all debug options (together with the corresponding hex values) and the list of valid return codes (see page 107).

Hex value Name Meaning

1 General Comprehensively logs the progress of PSP installation.

2 Memalloc Logs the memory allocation steps (not relevant for normal PrimeUp users).

4 FormatXML Informs how XML files are lowercased and formatted (not relevant for normal PrimeUp users).

8 XMLinfo Shows the information extracted from the XML files.

10 Registry Shows the information extracted from or written to the registry.

20 WorkSteps Provides a detailed protocol of the individual work steps.

40 FWcheck Logs the activities of the firmware check tools.

80 Resume Logs the resume actions after immediate reboot.

100 Commands Logs all commands that PrimeUp itself calls.

200 KeepFiles Keeps temporary files (e.g. extracted PSP files, log files of commands)

400 Scan Logs PrimeUp’s activities concerning system detection and detection of installed hardware/drivers/software kits.

800 List Not implemented.

Table 6: Debug options



-helpOutputs a list of all parameters and options with brief descriptions (default).

-installedOutputs a list of all currently installed PSPs with version numbers.

-vOutputs the PSP name and purpose. Only valid for the parameters -list and -simulate.

-vvOutputs the current contents of the PSPs, i.e. drivers and/or software kit version, in addition to the PSP name and purpose.Only valid for the parameters -list and -simulate.

-vvvOutputs all version numbers in addition to the PSP name and purpose. This allows you to trace the history of a PSP. Only valid for the parameters -list and -simulate.

-versionOutputs the version number of the PrimeUp tool.

<xml>Specifies one or more XML description files.

I Only the specified PSPs are installed or viewed. All other PSPs contained in the specified/default installation source are ignored. If the specified XML description files are not contained in the installation source, nothing will be installed.

An example is shown in figure 34 on page 116.



Examples

For further examples with outputs, see section "Examples".

Statement Description

PrimeUp -update NTAgents.xml

Installs the packages located in the PSP NTAgents.

PrimeUp -list Outputs a list of drivers / software kits to be installed for the PRIMERGY server. No installation occurs.

PrimeUp -simulate The simulation generates a list of PSPs whose drivers and software kits can be installed without errors.The simulation ends before the drivers and software kits are installed.

PrimeUp -update -D driversDir

Updates applicable PSPs located in the driversDir directory.

PrimeUp -update Updates applicable PSPs located in the directory from which PrimeUp was started.

Table 7: Sample statements


Return codes

3.3.7 Return codes

I PrimeUp -hh displays the list of return codes.

The following return codes are output to the PrimeUp log file (%TEMP%\PrimeUp\PrimeUp_DBGlog.txt) and to the Windows shell for checking scripts. A query in the script is also possible.

Return code Description

0 The installation was successful.

1 Based on the information in the description file(s), the installation must be completed with a reboot (see call option -noreboot).

2 Based on the information in the description file(s), a reboot is required immediately (see call option -noreboot).

3 Invalid call options.

4 A syntax error was discovered in the description file of the PSP.

5 Registry access error. Registry data corrupt, or registry access failed.

6 Incorrect path specified for the directory, wrong file name, or no files in the specified directory.

7 Installation is not possible due to a lack of information on the system board/chassis. Install the current ServerView agents or use the parameters -b and -c.

8 Errors occurred during installation of one or more PSPs.

9 The specified PSP(s) cannot be used on this system. No suitable hardware was found for the PSP, or other dependencies are not fulfilled.

10 Undefined. Note: Do not respond to it!

11 Internal return code; please ignore. Note: Do not respond to it!

12 The PrimeUp version currently used is out of date. Newer PrimeUp version required.

13 XML version error

14 PrimeUp (primeup.exe) already running.

15 Missing file.

55 Fatal error.

57 PSPs cannot be installed on a virtual machine (VM).

61 Invalid repository path.

Table 8: Return codes


Return codes

Important notes

I When installing several PSPs in the same PrimeUp call:

In many cases the return codes provided by PrimeUp reflect the overall result of the PrimeUp run. E.g. if at least one of the PSPs is not installable or not applicable (return code 8 or 9, respectively), PrimeUp provides returns code 8 or 9 as the overall return code.

For detailed information concerning installation of a specific PSP, transmit a PrimeUp call that installs only this PSP.

I PrimeUp returns only one return code per call. When installing several PSPs within the same PrimeUp call please note:

– Reboot is required for return codes 1 and 2 to complete the installation correctly.

– The log file should always be checked if return code 8 or 9 occurs. Please analyze the log file to localize the PSP(s) that caused the error.

– The installation should be executed with reboot if a reboot is required for individual PSPs.

– When installing more than one PSP, return code 9 indicates that at least one of the PSPs is not applicable due to internal dependency checks by PrimeUp.

– No activity is required if return code 9 occurs because return codes 1, 2 and 8 have higher priority.


Evaluating the installation process

3.3.8 Evaluating the installation process

The following files provide you with information about the installation process:

– PrimeUp log file– OS event log file

I When installing several PSPs in the same PrimeUp call:

If code 1 and/or return code 2 are reported, a restart of your server is required.

PrimeUp log file

With each call, PrimeUp generates the log file%TEMP%\PrimeUp\PrimeUp_DBGlog.txt, which is used to log the steps and is overwritten each time the tool is called. If the file is to be used to log the updates, you will need to save it, e.g. under C:\Users\Administrator\Appdata\Local\Temp\PrimeUp (Windows Server 2008)

OS event log file

PrimeUp writes the following messages to the OS event log file:

– PrimeUp successfully installed PSP ’%1’ %2.%3.%4.%5

– PrimeUp successfully installed PSP ’%1’ %2.%3.%4.%5; Reboot required

– PrimeUp successfully installed PSP ’%1’ %2.%3.%4.%5; Immediate reboot required

– PrimeUp skipped PSP ’%1’ %2.%3.%4.%5

– PrimeUp failed to install PSP ’%1’ %2.%3.%4.%5

The following substitutions apply for the messages:

– %1: PSP name

– %2 ... %5: PSP version



Generating debug information

For diagnostic purposes you should use the debug option -d <infolevel> with an appropriate info level (see section "PrimeUp - Parameters and options" on page 100). Useful info levels include -d 1, -d 20, -d 120, -d 338 or -d 420.

To receive comprehensive diagnostic information, it is recommended to proceed as follows:

Ê Use the -d 338 info level, which comprises the debug options -d 200, -d 100, -d 20, -d 10, and -d 8. Thus, -d 338 provides detailed debugging information on the following:

– Information extracted from the xml files (-d 8)

– Information on the registry (-d 10)

– Detailed protocol of the work steps performed (-d 20)

– Logs of all shell commands called by PrimeUp internally (-d 100)

– The -d 200 info level causes PrimeUp to keep temporary files, in particular PrimeUp_DBGlog.txt.

Ê Combine stderr and stdout into the stdout stream, and redirect the stdout stream to file primeup_trace.out.

Ê Send the zipped log files to your responsible Support Partner at FUJITSU if necessary.

You will find the current telephone number at:

http://ts.fujitsu.com/support/helpdesk.html



Example

The following example combines stderr and stdout into the stdout stream, and redirects the stdout stream to file primeup_trace.out:

Figure 28: Calling PrimeUp to provide debugging information and to redirect stdout

Figure 29: File containing debugging information


Important notes

3.3.9 Important notes

V IMPORTANT!

When installing PSPs using PrimeUp please note:

– To decompress the PSPs, a temporary directory (%Temp%\PrimeUp\<PSP-name>\...) is created. This directory is deleted when the program ends.

Calling PrimeUp with option -d 200 prevents the directory from being deleted.

– Installing LAN drivers via a network connection can have unexpected effects because of the short-term interruption of the current LAN connection. You can avoid this problem by first identifying the PSPs to be installed with the call PrimeUp -list. You should then install the packages containing the letter combination LAN locally and individually, e.g. PrimeUp -update localdrive:BroadCom_LAN_BCM570x.xml.

– Description files must not be renamed or changed.


PrimeUp usage variants

3.4 PrimeUp usage variants

The PrimeUp Tool gives you two possibilities for updating drivers and software kits. You can use the parameters and options either in a script or manually at the input prompt. Both variants are explained briefly below, followed by a section with outputs for the various parameters and options.

3.4.1 Scripting

The most convenient way to perform a new installation or an update is to use a script. For an optimum and comprehensible process, it is recommended that you execute a PrimeUp call for each PSP. The switch -noreboot is mandatory in a script environment because otherwise PrimeUp performs the reboot and the script environment is no longer available after the system is restarted.

The following procedure is recommended for the scripting:

– Call PrimeUp: PrimeUp -update -noreboot <name_of_PSP>.xml

– Evaluate the return codes

Return code 2 A reboot must be executed immediately in the script.

Return code 1 The processing can continue in the script; the reboot must occur at the end of the script processing.

Return code 0 or 9 The processing can continue in the script; the next PSP is being processed.

Other return codes An error response must occur in the script.


PrimeUp usage variants

Figure 30: Sample script

3.4.2 Manual calling

To call PrimeUp manually at the input prompt, the following procedure is recommended:

– Enter PrimeUp -simulate or PrimeUp -list.

The list on the screen should then be evaluated.

– Enter PrimeUp -update.

The return codes from the log file must then be evaluated:

Return code 8 (BAD_INSTALL) requires analysis of the log files.

Return code 1 indicates that the installation will not become effective until after the next reboot.


Examples

3.5 Examples

The following examples show the outputs of PrimeUp with various parameters.

3.5.1 Parameter -installed

Example using the parameter -installed

Figure 31: Example of parameter -installed

3.5.2 Parameter -list

Parameter -list

Figure 32: Example of parameter -list


Examples

Parameter -list in combination with the option -v

Figure 33: Example of parameter -list with option -v

Parameter -list; PSPs are specified in the command line

PrimeUp ignores all PSPs provided in the installation source (here: directory from which PrimeUp is called) with the exception of the PSPs that are explicitly specified in the command line (here: ATI_Radeon.xml, NTAgents.xml and FSC_SCAN.xml).

Figure 34: Example of parameter -list with a list of explicitly specified PSPs


Examples

3.5.3 Parameter -reginit

Examples using the parameter -reginit.

I PrimeUp used with parameter -reginit creates only initial ("faked") registry entries. "Real" entries will only be created by callingPrimeUp -update or PrimeUp -force.

Parameter -reginit in combination with parameter -gftree.

Figure 35: Example of parameter -reginit in combination with parameter -gftree

Parameter -reginit in combination with parameter -tree.

Figure 36: Example of parameter -reginit in combination with parameter -tree

"ZeroVersion" entry

"ZeroVersion" entry


Examples

Registry before and after execution of PrimeUp -reginit NTAgents.xml

The example starts with the PrimeUp registry shown in figure 37.

Figure 37: PrimeUp registry before calling PrimeUp -reginit

When PrimeUp -reginit NTAgents.xml is finished executing, the PrimeUp registry entry is as shown in figure 38 on page 119.

I The authenticity attribute is set to "fake" because the PSP has not been installed.


Examples

Figure 38: PrimeUp registry after PrimeUp -reginit NTAgents.xml is finished

I Calling PrimeUp -reginit creates an initial ("faked") PSP registry entry. This entry refers to an already installed driver or software kit.


Examples

3.5.4 Parameter -simulate

Example using the parameter -simulate.

Figure 39: Example of parameter -simulate


Examples

3.5.5 Parameter -update

Example using the parameter -update.

Figure 40: Example of parameter -update

Registry entry before and after execution of PrimeUp -update

The example starts with the PrimeUp registry shown in figure 41.

Figure 41: PrimeUp registry before calling PrimeUp -update


Examples

When PrimeUp -update NTAgents.xml has finished executing, the PrimeUp registry entry is as shown in figure 42.

I The authenticity attribute is set to "real" because the PSP has been installed.

Figure 42: PrimeUp registry after PrimeUp -update NTAgents.xml is finished

I Calling PrimeUp -update creates a "real" PSP registry entry. This entry refers to the driver or software kit that was installed during execution of this PrimeUp call.

3.6 How to get help

Please contact your responsible FTS Support Partner or helpdesk. You will find the current telephone number at:

http://ts.fujitsu.com/support/helpdesk.html


4 Autonomous Support Packages (ASP)

Autonomous Support Packages (ASPs) are self-extracting and self-installing software packages that allow you to install BIOS or firmware on your server.

To install BIOS or firmware on a server component, you can call up the appropriate ASP directly.

V Important!

Before performing any BIOS update: Ensure that BitLocker drive encryption is disabled.

If BitLocker drive encryption is enabled when updating the BIOS, your system normally will no longer be bootable.

I Alternatively, you can use ServerView Update Manager Express to install BIOS and/or firmware on your PRIMERGY server. Both ServerView Update Manager and ServerView Update Manager Express internally use ASPs.


I For PRIMERGY servers running Microsoft Hyper-V, Xen or VMware ESX, updating BIOS/firmware may be possible with restrictions. For more details refer to ASP release notes.

Updating BIOS/firmware on virtual machines (virtual guest systems) is generally not possible.


Current BIOS/firmware versions

4.1 Current BIOS/firmware versions

The current versions of BIOS and firmware and of the ASPs for your PRIMERGY server are available on the Update DVD, the latest version of which is issued approximately every two months. The Update DVD is bootable.

For details, see section "Current BIOS/firmware/driver versions and Update DVD" on page 19.

Creating the Update DVD from an appropriate DVD ISO image

If you do not own the current Update DVD, you can update your server’s BIOS/firmware by downloading the Update DVD ISO image UPDATE_DVD_<version>.iso of the latest version from http://support.ts.fujitsu.com/Download/ and create a physical DVD or a bootable USB stick from it.

In detail, proceed as follows:

1. Visit http://support.ts.fujitsu.com/Download/.

2. Select the appropriate PRIMERGY server type and model.

3. Under Select your operating system, select OS Independent (BIOS, Firmware, etc.).

4. Under Server Management Software - ServerView Update DVD, select ServerView Update DVD.

5. Download the DVD ISO image UPDATE_DVD_<version>.iso of the latest version from: http://support.ts.fujitsu.com/Download/ and create an Update DVD from it.

6. Use the Update DVD for the BIOS/firmware update.


ASPs for Windows

Latest BIOS/firmware/drivers and ASPs are available for downloading

Also in the period between two successive editions of the Update DVD, FUJITSU offers constantly updated versions of BIOS/firmware, and ASPs for downloading at http://support.ts.fujitsu.com/globalflash.

Therefore, if you need a BIOS/firmware version even newer than the BIOS/firmware version provided on the most recent Update DVD, please check http://support.ts.fujitsu.com/globalflash to see whether such a version exists.

4.2 ASPs for Windows

Under Windows you can call up an ASP directly as follows:

– In Windows Explorer: by double-clicking the *.exe file of the ASP.

If you call the ASP in Windows Explorer, a wizard in the GUI of the ASP takes you through a standard installation.

V CAUTION!

When started in Windows Explorer, an ASP forces BIOS/firmware installation regardless of the corresponding BIOS/firmware version currently installed on your system. Please treat with caution if you start an ASP in Windows Explorer.

– At the Windows input prompt: via command in the ASP CLI.

Calling the ASP via the command line interface offers you not only wizard-guided standard installation but also additional options for tailoring the installation to your specific needs.




ASPs for Windows

4.2.1 Requirements

Installing BIOS/firmware via ASPs requires the following:

V Important!

When updating a network component (e.g. LAN controller), network connections may be lost after a BIOS/firmware/driver update.

V Important!

Before performing any BIOS update: Ensure that BitLocker drive encryption is disabled.

If BitLocker drive encryption is enabled when updating the BIOS, your system normally will no longer be bootable.

– To execute an ASP, you require administrator rights.

– To extract and execute the installation / flash routines, you must have sufficient space (> 1GB) on the hard disk.

– When explicitly calling an ASP via the GUI or CLI, you must perform a version check for BIOS/firmware or software kit. Make sure that all requirements for executing the ASP are fulfilled (Required drivers or software packages installed, etc.)


ASPs for Windows

4.2.2 Accessing the ASPs

You can access the ASPs for the individual server components as follows:

● In the directory of the Update DVD (e.g. created by means of the current DVD ISO image UPDATE_DVD_<version>.iso, see page 19), the ASPs can be found under Firmware in the following folders (see figure 43 on page 128):

– Agent-Lx – Agent-Win – BladeSystem – FibreChannelController – LanController – ManagementController – MicroController – SystemBoard – ScsiController

● Via the download section of the FUJITSU website (http://support.ts.fujitsu.com/globalflash) you can download the ASPs into a directory on your PRIMERGY server via the following links:




ASPs for Windows

The names of the ASPs for Windows consist of the following name elements:

[<server_name>_][<D_no.>_]<component>_<version>.exe

I The server name and D-number are part of the name whenever the ASP provides server-specific firmware or BIOS.

Example: ASPs on the Update DVD

Figure 43: ASPs for Windows on the Update DVD (example)


ASPs for Windows

4.2.3 Starting the ASP in Windows Explorer

I During the installation, ASPs perform compatibility and dependency checks. Compatibility/dependency checks normally comprise checking e.g. system ID, chassis ID / board ID, model ID, operating system, availability of hardware, availability of required software.

In the case of unfulfilled dependencies and other discrepancies the installation process aborts with an error message and the related return code.

V CAUTION!

When started in Windows Explorer, an ASP forces BIOS/firmware installation regardless of the corresponding BIOS/firmware version currently installed on your system. Please treat with caution if you start an ASP in Windows Explorer.

To start the ASP, proceed as follows:

Ê In Windows Explorer, switch to the folder of your Update DVD which contains the *.exe file for the ASP you want.


ASPs for Windows

Ê Start the ASP by double-clicking this *.exe file.

Once the ASP is started, the following welcome screen is displayed:

I If you are executing the ASP on a server which is not supported, a corresponding error message is displayed.

Figure 44: Welcome screen

The welcome screen shows the descriptive and version information according to the download portal (support.ts.fujitsu.com).

Release NotesShows the release notes belonging to the BIOS/firmware.

Extract onlyCopies the ASP data into a (selectable) directory.

InstallStarts the installation process.

I Clicking Install always performs a forced update. Thus installation will be executed even it results in a downgrade.


ASPs for Windows

4.2.3.1 Displaying the release notes

To display the release notes, click the Release Notes button in the welcome screen. The Release Notes window is displayed:

Figure 45: Release Notes window


ASPs for Windows

4.2.3.2 Extracting the data

You can extract the ASP data for the installation process into a selected directory. Proceed as follows:

Ê In the welcome screen, click the Extract only button.

The Choose Destination Location window is displayed, in which you define the target directory for the extracted data:

Figure 46: Choose Destination Location window

Ê A default directory is offered under Destination Directory. You can change this directory via the Browse button.

Ê Click Next to extract the data. A message tells you the result of the extraction:

Figure 47: Extraction successful

Ê Click OK to complete the extraction.


ASPs for Windows

4.2.3.3 Starting the BIOS/firmware installation

V CAUTION!

The installation process does not distinguish between an update and a force/downgrade. The installation is performed in any case (forced), even if the version to be installed is already on the server. This distinction is only possible if you call the ASP via the CLI.

V CAUTION!

The installation process must not be interrupted under any circumstances!

To install the BIOS/firmware, proceed as follows:

Ê In the welcome screen, click the Install button to start the BIOS/firmware installation.

If the ASP cannot identify your PRIMERGY server using the D-number (system board) or cabinet number, you will be told this and prompted to confirm the start of the installation.

V CAUTION!

To avoid damage to your server, only confirm the start of the installation process with Continue if you are sure that your server allows the use of ASPs.

Figure 48: Confirmation dialog after failed server identification


ASPs for Windows

Ê Click Continue to start the installation. The following window tells you that the installation is under way:

Figure 49: BIOS/firmware installation in progress

Ê You can close the window with Close. This does not interrupt the installation process.

V CAUTION!

The BIOS/firmware installation can take a while (10 - 15 minutes). Make sure that the installation process is not interrupted under any circumstances!

Once the installation process is complete, you are informed of the result. A message shows the status of the installation and tells you if you need to restart the server.

Figure 50: Installation process complete

Ê Click OK to confirm the message.


ASPs for Windows

Ê Following successful BIOS/firmware installation, restart your PRIMERGY server if this is necessary to activate the BIOS/firmware (see final status message from ASP).

I Once the installation is complete, all files in the extraction directory (ASP target directory) except for the log file Setup.log are deleted. Experts in handling ASPs can use this log file to analyze the executed ASP in the event of an error.

4.2.4 Calling ASPs via the command line interface (CLI)

Firmware and BIOS can also be installed via the CLI. In this case, as well as using the Windows PowerShell or the wizard-guided standard installation, you can access additional options for tailoring the installation to your specific needs.

Proceed as follows:

Ê Start the command line (cmd.exe).

Ê Switch to the directory (on your Update DVD or hard disk) containing the *.exe file for the ASP you require.

Ê Start the ASP command using the syntax described below.

I To evaluate the return code, see section "ASP return codes" on page 162.

Syntax

<ASP_name>.exe [/<option>] ...

For <option> you can specify:

I Square brackets [ and ] in the options listed below are part of the option names and not metasymbols (option brackets).

/silentExecutes the ASP without user input. Dialog boxes are displayed, but normally close by themselves. Only the "installation completed" message requires explicit confirmation.

I As the "installation completed" message requires explicit confirmation, do not use the /silent option for unattended installation. For unattended installation, use the /hide option instead.


ASPs for Windows

/hideExecutes the ASP in the background. No dialog boxes are displayed. The /hide option is required for unattended installation.

/InstallDir=“<directory_path>\<target-directory>” Only in conjunction with the option /[Extract]=yes, /[Update]=yes, or /[Force]=yes: ASP user data is extracted to the specified directory. Both <directory_path> and <target-directory> must be specified.

I Installation may fail if <directory_path> denotes the relative path from the current directory to the <target directory>. If you want to set a relative path, apply the following format using the CD environment variable:

/InstallDir %CD%\<target-directory>

/[Update]={yes | no}Default value in hidden mode: [Update]=yes

Default value in GUI mode: [Update]=no

Only newer BIOS/firmware versions may be installed. This option must be used in conjunction with one of the options /silent or /hide. This function is only performed if it is supported by the actual internal flash program.

I A real version check can be performed in most cases.

/[Force]={yes | no}Default value in hidden mode: [Force]=no

Default value in GUI mode: [Force]=yes

Forces BIOS/firmware installation. Allows older BIOS/firmware versions to be installed.

/[Extract]={yes | no}Default value: [Extract]=noASP user data is extracted to the directory specified by the option /InstallDir. If you do not specify the option /InstallDir, the ASP user data will automatically be extracted to the directory where the ASP is stored.

I The option /[Extract]=yes cannot be combined with other extraction options (e.g. [ExtractReleaseNotes]) or with the options /[Force] and /[Update].


ASPs for Windows

/[ExtractReleaseNotes]={yes | no}Default value: [ExtractReleaseNotes]=noThe file rel_note.txt (release notes) is extracted to the directory specified by the option /[TargetReleaseNotesPath]. If you do not specify the option /[TargetReleaseNotesPath], the release notes will automatically be extracted to the calling directory (e.g. D2119_RX300S3_FLASH_DATA) in the Windows Temp directory.

I The option /[ExtractReleaseNotes]=yes cannot be combined with other extraction options (e.g. [Extract]) or with the options /[Force] and /[Update].

/[TargetReleaseNotesPath]="<directory_path>\<file_name>"Only in conjunction with the option /[ExtractReleaseNotes]=yes: The release notes are extracted to the specified directory. Both <directory_path> and <file_name> must be specified.

/[KeepFiles]={yes | no}Default value: [KeepFiles]=no

Data will be deleted / not deleted from the ASP target directory after completion of the installation or update process. The kept data can be used e.g. for evaluating logging data or testing commands etc.

I In the case of a failure, please save the contents of the ASP target directory and send the zipped directory to your responsible Support Partner at FUJITSU for further analysis.

/[Help]={yes | no}Default value: [Help]=noOutputs a brief description of the options. Within an ASP call, this option cannot be combined with other options.

I In the output text, the information under Build tells you the build of the ASP, not the version of the BIOS/firmware it contains.

/[ExpertHelp]={yes | no}Default value: /[ExpertHelp]=noOutputs a brief description of additional options meant for experts. Within an ASP call, this option cannot be combined with other options.



ASPs for Windows

/[ExternalVariable]= "<special_product_options>" <special_product_options> denotes a string including product-specific options and the related parameters.

I Once an ASP command has been submitted, the ASP internally calls the underlying installation tool (e.g. FTASetup.exe) that performs the actual installation. ASP options and parameters are passed automatically to the installation tool.

For some ASPs, you can additionally specify the /[ExternalVariable] option, which allows you to define software/product-specific options. These options enable you to control the installation of the software related to the ASP, e.g. in the case of a non-standard installation

I For details on the product-specific options and parameters available for the ASP considered, please refer to the help text displayed with the /[ExpertHelp] option.

Examples:

When installing the ServerView update agent via ASP (i.e. SVUpdateAgent-Win_ASP<Version>.exe), you can use the /[ExternalVariable] option to specify additional control parameters that are relevant for installing the ServerView update agent.

Initial silent installation (with default parameters)

SVUpdateAgent-Win_ASP<Version>.exe /hide

(Default: noaccountcheck=0, -flashusergroup=GFUSER)

Initial silent installation (with non-default parameters)

SVUpdateAgent-Win_ASP<Version>.exe /hide /[ExternalVariable]=\"-noaccountcheck=1\"

SVUpdateAgent-Win_ASP<Version>.exe /hide /[ExternalVariable]=\"-FlashGroup <usergroup>\"

/[NoAdminCheck]={yes / no}Default value: [NoAdminCheck]=no

No check for administrator rights.

/[NoSystemCheck]={yes / no}Default value: [NoSystemCheck]=no. (This applies to most ASPs.)

No system check.


ASPs for Windows

/[NoAgentCheck]={yes / no}Default value: [NoAgentCheck]=yes

No check for ServerView agents. Currently, no ASP performs an agent check.

/[NoBladeCheck]={yes / no}Default value: [NoBladeCheck]=yes

No check for blade systems.

I Currently, only the ServerView update agent ASP can perform a blade check.

/[NoVirtualCheck]={yes / no}Default value: [NoVirtualCheck]=no

No check for virtual machines.

/[NoUpdateBlock]={yes / no}Default value: [NoUpdateBlock]=no

No abortion if option /[Update]=yes was set. Some ASPs may not support option /[Update]=yes, thus possibly aborting without performing the update. If in such cases the option /[NoUpdateBlock]=yes is set, a forced flash - even a downgrade - will be performed.

Some ASPs may not support the --update option, thus aborting without performing the update. If in such cases the option --no-update-block is set, a forced flash - even a downgrade - will be performed

/[NoReset]={yes / no}Default value: [NoReset]=no

Suppresses the sending of a final "reset" request to the target device (e.g. no separate reset (reboot) of an iRMC S4 will be performed after a firmware update has successfully completed.)

/[NoRivalCheck]={yes / no}Default value: [NoRivalCheck]=no

Suppresses the check for rivaling software.

Some ASPs may check whether rivaling software packages are already installed (e.g. ServerView Management Agents vs. ServerView Agentless Service). Rivaling software packages cannot be installed simultaneously.


ASPs for Windows

/[ExtractParFile]={yes / no}Default value: [ExtractParFile]=no

Extracts the parameter file.

/[TargetParFilePath]="<path_name_of_the_target_file>" Only in conjunction with the option /[ExtractParFile]=yes: The parameter file is extracted to the specified directory. Both <directory_path> and <file_name> must be specified.

For examples see section "ASPs for Windows" on page 125.

Return codes

To evaluate return codes, you must start the ASPs with the following call:

start /wait <ASP_name>.exe [/<option>] ...

The return code is displayed by entering the following command:

echo %errorlevel%

For a list of the return codes, see section "ASP return codes" on page 162.

4.2.5 Calling an ASP via the Windows PowerShell

Firmware and BIOS can be installed via the Windows PowerShell. In this case, as well as using the CLI or the wizard-guided standard installation, you can access additional options for tailoring the installation to your specific needs.

In the Windows PowerShell, you start an ASP via the start command.

Proceed as follows:

Ê Start the Windows PowerShell prompt.

Ê Switch to the directory (on your Update DVD or hard disk) containing the *.exe file for the ASP you require.

Ê Start the ASP command using the syntax described below.

I The return code is displayed by entering the following command:

echo $listexitcode

To evaluate the return code, see section "ASP return codes" on page 162.


ASPs for Windows

Syntax

start –Wait <ASP_name>.exe –ArgumentList " <option> [<option>] ... "

I It is very important to correctly set quotation marks, blanks, and inverted commas.

For a detailed description of the options, see section "Calling ASPs via the command line interface (CLI)" on page 135.

For an example of calling an ASP via the Windows PowerShell, see section "Firmware update with return code (using Windows PowerShell)" on page 144


ASPs for Windows

4.2.6 Examples

4.2.6.1 Displaying help texts

To display help texts, enter the following command:

<ASP_name>.exe /[Help]=yes

This opens the following window:

Figure 51: Displaying help texts

To display help texts meant for experts, enter the following command:

<ASP_name>.exe /[ExpertHelp]=yes


ASPs for Windows

4.2.6.2 Extracting ASP data

To extract ASP data, enter the following command:

<ASP_name>.exe /[Extract]=yes /silent

Successful extraction is indicated by the following message:

Figure 52: Extracting ASP data

I If no /InstallDir option is specified, the ASP data will be extracted into the default directory (see figure 61). The /InstallDir option allows you to extract the ASP data into a directory of your choice.

I Extraction may fail if the option /InstallDir=<directory-path><target-directory> is specified with <directory-path> denoting a relative path from the current directory to the <target directory>.

If you want to set a relative path, apply the following format using the CD environment variable:

/InstallDir %CD%\<target-directory>


ASPs for Windows

4.2.6.3 Firmware update with return code

You start a firmware update with the following command:

start /wait <ASP_name>.exe /[Update]=yes /silent

When you enter this command, the ASP starts the update process without any further dialogs or user input. A successful update is indicated by the following message:

Figure 53: Firmware update successfully finished

Click OK to confirm the message. Following successful firmware/BIOS installation, restart your PRIMERGY if this is necessary to activate the BIOS/firmware.

I Once the installation is complete, all files in the extraction directory (ASP target directory) except for the log file Setup.log are deleted. Experts can use this log file to analyze the executed ASP in the event of an error.

After the reboot, check whether the relevant installation is also present on the server. You can do this by calling the BIOS setup or using ServerView Operations Manager or ServerView Update Manager.

I You can use the option /[KeepFiles]=yes to prevent data from being deleted from the ASP target directory after completion of the installation or update process (see section "Keeping the contents of the ASP target directory" on page 146).

4.2.6.4 Firmware update with return code (using Windows PowerShell)

In the Windows PowerShell, you start a firmware update with the following command:

start –Wait <ASP-NAME>.exe –ArgumentList ‘‘ Argument_1 [Argument_2 [Argument_3]] ‘‘


ASPs for Windows

Example

start –Wait .\SVUpdateAgent_Win_ASP_61000.exe -ArgumentList “ /[Update]=yes /silent /InstallDir=C:\tmp\ASP/[ExternalVariable]=`-noaccountcheck=0 –FlashGroup Users` /[KeepFiles]=yes “

I It is very important to correctly set quotation marks, blanks and inverted commas correctly. This especially concerns the backquote (‘) characters enclosing the string (argument) of the /[ExternalVariable] option.

When you enter this command, the ASP starts the update process without any further dialogs or user input. A successful update is indicated by the following message:

Figure 54: Firmware update successfully finished

Click OK to confirm the message. Following successful firmware/BIOS installation, restart your PRIMERGY if this is necessary to activate the BIOS/firmware.

I Once the installation is complete, all files in the extraction directory (ASP target directory) except for the log file Setup.log are deleted. You can use this log file to analyze the executed ASP in the event of an error.

After the reboot, check whether the relevant installation is also present on the server. You can do this by calling the BIOS setup or using ServerView Operations Manager or ServerView Update Manager.

I You can use the option /[KeepFiles]=yes to prevent data from being deleted from the ASP target directory after completion of the installation or update process (see section "Keeping the contents of the ASP target directory" on page 146).


ASPs for Windows

4.2.6.5 Keeping the contents of the ASP target directory

By default, all files in the extraction directory (ASP target directory) except for the log file Setup.log are deleted once the installation is complete.

The option /[KeepFiles]=yes allows you to prevent data from being deleted from the ASP target directory after completion of the installation or update process. The kept data can be used e.g. for evaluating logging data or testing commands etc.


Figure 55: Preventing data from being deleted from the ASP target directory

The contents of the ASP target directory is shown in figure 56:

Figure 56: Option /[KeepFiles]=yes: Keeping the contents of the ASP target directory


ASPs for Linux

4.3 ASPs for Linux

Under Linux, you can call up an ASP directly via the command line interface (CLI).

4.3.1 Requirements

V CAUTION!

When updating a network component (e.g. LAN controller), network connections may be lost after a BIOS/firmware/driver update.

Installing BIOS/firmware via ASPs requires the following:

– To execute the ASPs, you require root privileges.


4.3.2 Accessing the ASPs

You can access the ASPs for the individual server components as follows:

● In the directory of the Update DVD (e.g. created by means of the current DVD ISO image UPDATE_DVD_<version>.iso, see page 19), the ASPs can be found under Firmware in the following folders (see figure 57 on page 148):


● Via the download section of the FUJITSU website (http://support.ts.fujitsu.com/globalflash) you can download the ASPs into a directory on your PRIMERGY server via the following links:

– Agent-Lx – Agent-Win



ASPs for Linux

– BladeSystem – FibreChannelController – LanController – ManagementController – MicroController – SystemBoard – ScsiController

The names of the ASPs for Linux consist of the following name elements:

[<server_name>_][<D_no.>_]<component>_<version>.scexe

I The server name and D-number are part of the name whenever the ASP provides server-specific firmware or BIOS.

Example: ASPs on the Update DVD

Figure 57: ASPs for Linux on the Update DVD (example)


ASPs for Linux

4.3.3 Calling ASPs via the command line interface (CLI)

Start the installation as follows:

Ê Open a terminal.

Ê Switch to the directory (on the Update DVD or hard disk) containing the *.scexe file for the ASP you require.

Ê Start the installation with the following command:

sh <ASP_name>.scexe <option>

I Bear in mind that the options are case-sensitive.

For <option> you can specify:

-s | --silent Executes the ASP without user input. Logging information, notes and progress information are displayed.

-h | --hide Executes the ASP in the background without user input and does not output any messages.

I If using in a scripting, Update Manager or SMS environment, you must use the option --hide.

-I | --install-dir <directory> Only in conjunction with the option --extract, --update, or --force: ASP user data is extracted to the specified directory.

-e | --extract ASP user data is copied to the directory specified by the option --install-dir.

I The option --extract cannot be combined with other extraction options (e.g. --extract-release-note) or with the options --force or --update.

If you do not specify the option --install-dir, the ASP will extract the user data to a temporary ASP-specific directory (e.g. sctmp<process_ID> under <$TempDir>).


ASPs for Linux

-r | --extract-release-note By default, the file rel_note.txt (release notes) is extracted to the calling directory of the ASP. You can specify a different target directory with the option --target-file.

I The option --extract-release-note cannot be combined with other extraction options (e.g. --extract) or with the options --force or --update.

-t | --target-file [<path_name>/]<file_name>Only in conjunction with the option --extract-release-note or the option --extract-par-file. The release notes / parameters are extracted to the file <file_name> of the specified directory.

-u | --update Default value.Only newer firmware versions are installed. This function is only performed if it is supported by the actual internal flash program.

-f | --forceForces BIOS/firmware installation. Older BIOS/firmware versions are also installed (downgrade).

-k | --keepfilesDefault value: --keepfiles is not enabled. Data will be deleted / not deleted from the ASP target directory after completion of the installation or update process. The kept data can be used e.g. for evaluating logging data or testing commands etc.


-nub | --no-update-blockDefault value: --no-update-block is not enabled. No abortion if option --update is set.

Some ASPs may not support the --update option, thus possibly aborting without performing the update. If in such cases the option --no-update-block is set, a forced flash - even a downgrade - will be performed.


ASPs for Linux

-nrst | --no-resetDefault value: --no-reset is not enabled. (i.e. a "reset" request is sent if the option is not specified.)Suppresses the sending of a final "reset" request to the target device (e.g. no separate reset (reboot) of an iRMC S4 will be performed after a firmware update has successfully completed).

-nrivpkg | --no-rival-pkg-checkDefault value: --no-rival-package-check is not enabled.

Suppresses the check for rivaling software packages.

Some ASPs may check whether rivaling software packages are already installed (e.g. ServerView Management Agents vs. ServerView Agentless Service). Rivaling software packages cannot be installed simultaneously.

-n3264c | --no-3264-bit-checkDefault value: --no-3264-bit-check is not enabled.

Suppresses the check for 32 Bit or 64 Bit operating system. Some ASPs may not support 32 or 64 Bit operating systems.

-v<level> | --verbose-<level>Default value: --verbose-0 (no trace) is enabled.

In case of problems you can activate trace by setting a verbose level (trace level) 1..6. Trace level 6 outputs maximum amount of trace data.

-sr | --show-return-codesDefault value: --show-return-codes is not enabled.Displays a list of possible return codes and their meanings.


ASPs for Linux

-? | --helpOutputs a brief description. This option cannot be combined with other options.


-H | --expert-helpOutputs a brief description of additional options meant for experts. Within an ASP call, this option cannot be combined with other options.


-ev| --external-variable " <special_product_options>"<special_product_options> denotes a string including product-specific options and the related parameters.

I Once an ASP command has been submitted, the ASP internally calls the underlying installation tool (e.g. FTASetup.scexe) that performs the actual installation. ASP options and parameters are passed automatically to the installation tool.

For some ASPs, you can additionally specify the external-variable option, which allows you to define software/product-specific options. These options enable you to control the installation of the software related to the ASP, e.g. in the case of a non-standard installation

I For details on the product-specific options and parameters available for the ASP considered, please refer to the help text displayed with the --expert-help option.


ASPs for Linux

Examples:

When installing the ServerView update agent via ASP (i.e. SVUpdateAgent_LX_<Version>.scexe), you can use the --external-variable option to specify additional control parameters that are relevant for installing the ServerView update agent.

Initial silent installation (with default parameters)

SSVUpdateAgent_LX_<Version>.scexe

(Default: --noaccountcheck=0, --flashgroup globalflash, -l 2, -t /opt/SMAW/SMAWgfa/data/gf_agent.log)

SVUpdateAgent

Initial silent installation (with non-default parameters)

SVUpdateAgent_LX_<Version>.scexe --external-variable "--noaccountcheck=1"

_LX_<Version>.scexe --external-variable "--FlashGroup <usergroup>"

-nr | --no-admin-checkDefault value: --no-admin-check is not enabled. No check for administrator rights.

-ns | --no-system-checkDefault value: --no-system-check is not enabled.No system check.

-na | --no-agent-checkDefault value. No check for ServerView agents.

-nxen | --no-xen-checkDefault value. No check for Linux XEN host.

-nesx | --no-esx-checkDefault value. No check for VMware ESX host.

-npkg | --no-pkg-checkNo check for installed software packages.


ASPs for Linux

-nos | --no-os-checkDefault value: --no-os-check is not enabledNo operating system check.

-nb | --no-blade-checkDefault value. No check for a blade system.

-nv | --no-virtual-checkDefault value: --no-virtual-check is not enabled.No check for a virtual machine running on a Hyper-V-, XEN, or VMware host.

--p | --extract-par-fileDefault value. Extracts the parameter file.

For examples see section "Examples" on page 158.


ASPs for Linux

4.3.4 Installation procedure

Once you have started the installation, the ASP informs you of its progress and status.

I If you called the ASP with the option --silent, it will be executed without user input. Logging information, notes and progress information are displayed.

If you called the ASP with the option --hide, it will be executed in the background without user input and no messages will be output.

Server identification

Before the actual installation, the ASP attempts to identify the server. If the server is not supported, the ASP outputs a corresponding error message:

Figure 58: Server identification: Server is not supported

In addition, the return code returned by the ASP (“wrong system“, echo $?, 17) indicates the reason why the system identification failed (see section "ASP return codes" on page 162).


ASPs for Linux

Welcome screen

Once the system is successfully identified, the ASP opens the welcome screen, in which you can follow the installation process.

I If you called the ASP with the option --silent, it will be executed without user input. Logging information, notes and progress information are displayed.

If you called the ASP with the option --hide, it will be executed in the background without user input and no messages will be output.

Figure 59: Following the installation process on the terminal

2

3

4

1

3


ASPs for Linux

1. Before the actual installation, the ASP gives you details of the packaged firmware.

2. The ASP asks you to confirm that you want to continue with the installation. (No confirmation dialog with the options --silent or --hide!)

3. The ASP starts the actual BIOS/firmware installation.

V CAUTION!

The BIOS/firmware installation can take a while (10 - 15 minutes). Make sure that the installation process is not interrupted under any circumstances!

4. The ASP reports status of the completion of the installation and asks you to restart the server if this is necessary to activate the new BIOS/firmware version.

Return codes

The ASP also provides a return code, which you can display with the following command:

echo $?

For a list of the return codes, see section "ASP return codes" on page 162.


ASPs for Linux

4.3.5 Examples

4.3.5.1 Displaying help texts

To display help texts, enter the following command:

<ASP_name>.scexe --help

Figure 60: Help on the ASPs


ASPs for Linux

4.3.5.2 Extracting ASP user data

Extracting ASP user data to the default ASP target directory

To extract ASP user data to the default ASP target directory, enter the following command:

<ASP_name>.scexe --extract

The user data packaged in an ASP (firmware, Flash tools, control files etc.) is then extracted to a directory preset by the ASP. The extraction path is composed of the contents of the environment variable $TMPDIR and the process ID of the ASP: <$TMPDIR>\sctmpdir<process_ID>.

Figure 61: Extracting ASP user data to the default directory

Extracting ASP user data to a specific target directory

To extract ASP user data to the directory <directory>, enter the following command:

<ASP_name>.scexe --extract --install-dir <directory>


ASPs for Linux

4.3.5.3 Performing the installation in the background

To execute the ASP for the BIOS/firmware update in the background, enter the following command:

<ASP_name>.scexe --update --hide

Figure 62: Executing the ASP for the firmware update in the background


ASPs for Linux

4.3.5.4 Keeping the contents of the ASP target directory

By default, all files in the extraction directory (ASP target directory) are deleted once the installation is complete.

The option --keepfiles allows you to prevent data from being deleted from the ASP target directory after completion of the installation / update process. The kept data can be used e.g. for evaluating logging data or testing commands etc.


Figure 63: Preventing data from being deleted from the ASP target directory

The contents of the ASP target directory is shown in figure 64:

Figure 64: Option --keepfiles: Keeping the contents of the ASP target directory


ASP return codes

4.4 ASP return codes

Error value No. Meaning Remarks Solution Proposal

_RET_OK 0 Process completed successfully.

_RET_REBOOT 1 Process completed successfully, reboot required.

_RET_REBOOTATONCE 2 Process completed successfully, immediate reboot required

Linux only

_RET_BADCALL 3 Incorrect option(s) or missing parameter(s).

Linux only

_RET_BADFILES 6 At least one file is not applicable.

Linux only

_RET_INFOMISSING 7 Missing information

Linux only

_RET_BADINSTALL 8 Installation process failed.

_RET_AC_CYCLE 10 Process completed successfully, ac-cycle required.

Unplug power cable for at least a minute.

_RET_NO_COMPONENT 16 Target hardware not found.

_RET_WRONG_SYSTEM 17 Wrong target system.

_RET_NO_OVERWRITE_PERMISSION

18 Not sufficient permissions.

_RET_NOT_TERMINALSERVER_CAPABLE

19

Table 9: ASP return codes


ASP return codes

_RET_SV_AGENTS_NOT_INSTALLED

20 ServerView agents are not installed.

Install ServerView Agents first.

_RET_PKG_NOT_INSTALLED 21 At least one required software package is not installed.

Install needed software packages first.

_RET_KERNEL_MODULE_MISSING

22 Required kernel module is not installed (ex. driver module)

Linux only

Check log-files for getting more information about missing modules (ex. tooltrace.txt).

_RET_BITLOCKER_BLOCKED 23 Execution prohibited due to active BitLocker.

Windows only

Disable BitLocker.

_RET_TRUSTEXETEC_BLOCKED

24 Execution prohibited due to active Trusted Execution Technology

Disable Trusted Execution Technology.

_RET_COMPETING_APPLICATION 25 Competing application is already installed.

Uninstall competing application.

_RET_FATAL_ERROR 55 Fatal error occurred.

Linux only

_RET_NO_ADMIN_RIGHTS 56 Admin rights not sufficient.

Linux only

Try again with "root" privileges.

_RET_NOT_ON_VIRTUAL_MACHINE

57 Cannot be executed on a virtual machine.

_RET_NOT_VMMS_CAPABLE 58 ASPs cannot be used - on PRIMERGY servers running Hyper V, Xen or

VMware ESX,- on virtual machines.

Start Update Manager Express by booting your PRIMERGY server from the Update DVD.




ASP return codes

_RET_NOT_SUPPORTED_OS 59 Operating system not supported.

Linux only

Start Update Manager Express by booting your PRIMERGY server from the Update DVD.

_RET_NOT_SUPPORTED_SUBSYS

60 A not-supported subsystem is attached with target controller

Please detach the storage subsystem and try again. Please note that only storage subsystems released by FTS can be attached to your host system.

_RET_NOT_SUFFICIENT_DISK_SPACE

61 Not enough disk space.

Please assure that sufficient disk space is available for extracting the ASP.

_RET_SHUTDOWN_VIRTUAL_SYSTEMS

62 Please shut down all virtual systems.

Please assure that no virtual system is active on the target server.

_RET_DOWNGRADE_PROHIBITED

63 Downgrade prohibited.

Due to incompatibili-ties, downgrading BIOS or firmware is not allowed.




ASP return codes

_RET_HIGHER_VERSION_INSTALLED

64 A higher version is already installed.

Take a higher version than the one currently installed, or set option "force" instead of "update".

_RET_UNFULFILLED_PREREQUISITE

65 At least one unfulfilled prerequisite prohibits successful execution.

Check all conditions that must be fulfilled for successful execution.

_RET_WRONG_PRIOR_VERSION_INSTALLED

66 Wrong prior version installed.

Updating from currently installed version is not possible. Please check whether an interim version must be installed prior to the desired version

_RET_ONLY_FORCED_FIRMWARE_EXCHANGE

67 The Update option is not supported. No protection against unintended downgrades.

Use the Force option instead.




Log file Setup.log

4.5 Log file Setup.log (ASPs for Windows only)

After the installation, all ASP components except for the log file Setup.log are deleted. You can use this log file to analyze the processes within the executed ASP in the event of an error or sent it to a service partner.


Local System Update for PRIMERGY Servers -...

Documents

Transcript of Local System Update for PRIMERGY Servers -...