AIX update visszaleptetese

Bevezetes: AIX fix management

• Az AIX-en a csomag neve fileset, amely altalaban .bff (backup file format) formatumu.
• Ezenkivul van rajta nativ RPM es ISMP (InstallShield Multiplatform) tamogatas is.
• A csomagkezelo neve installp, de a listazashoz az lslpp-t hasznaljuk.
• Az installp-nek tobb frontendje is van, a kedvencem az install_all_updates.
• A geninstall hasznalhato mindharom csomagformatum kezelesere.

Evente ketszer jonnek ki a TL-nek (Technology Level) nevezett nagyobb frissitesek, amelyek altalaban 200-300 filesetet erintenek (egy atlagos default telepitesben kb 600 fileset van). Ezek kozt szukseg szerint tobb SP (Service Pack) is megjelenik, amik rendszerint a kritikus hibakat javitjak. Ezenkivul surgos esetekben binaris fixeket (efix) is kiadnak.

Az alabbi iras alapja az, hogy az AIX minden csomag eseten meg tudja tartani az elozo verziot, igy van lehetoseg a visszaallasra. Azok a csomagok, amik nem lettek 'veglegesitve' (commit), APPLIED allapotban vannak az lslpp kimeneteben. Sajnos arra nincsen kulon utility, hogy egy TL-t egyetlen paranccsal visszaleptessunk, de igy sem tul bonyolult a feladat.

Termeszetesen az egesz 'true story', a mai napon elvegzett munkan alapul!

---

Feltetelek:

- az upgrade elott az elozo TL legyen konzisztens
- az upgrade elott csinaljunk egy commit-ot (azaz veglegesitsuk az osszes korabbi upgrade-et)

Generaljuk le a nem commitolt filesetek listajat:

# lslpp -lcq | awk -F\: '/APPLIED/ {print $2}'  | sort -u > filesets_to_reject

A sort -u (vagy siman csak uniq) azert kell, mert szinte minden fileset-nek van ugynevezett ROOT es USR resze, igy ketszer szerepelnek az lslpp kimeneteben:

 # lslpp -lcq
/usr/lib/objrepos:ICU4C.rte:6.1.4.0::COMMITTED:I:International Components for Unicode :
/usr/lib/objrepos:Java5.sdk:5.0.0.235::APPLIED:F:Java SDK 32-bit:
/usr/lib/objrepos:Java5_64.sdk:5.0.0.150::COMMITTED:I:Java SDK 64-bit :
...

Futtassuk le a reject (-r) muveletet preview (-p) modban (nyilvan az elobbivel egybe is fuzhetjuk):

# installp -pr $(< filesets_to_reject)

Ez hibakat is eredmenyezhet, ugyanis az uj TL-ben lehetnek uj, korabban nem telepitett filesetek is, amik - mivel elso installrol van szo - rogton COMMITTED statuszba kerulnek, ahonnan csak uninstallalni lehet oket.

A hiba ebben az esetben igy nez ki:

  SELECTED FILESETS:  The following is a list of filesets that you asked to
  reject.  They cannot be rejected until all of their dependent filesets
  are also rejected.  See subsequent lists for details of dependents.

    bos.net.tcp.client 6.1.4.2                # TCP/IP Client Support
...

  COMMITTED DEPENDENTS:  The following filesets depend upon one or more of
  the selected filesets listed above.  These dependents must be rejected
  before the selected filesets.  Since these dependents are in a COMMITTED
  state, they cannot be rejected.  Therefore, the selected filesets cannot
  be rejected.  (Committed software can be removed with the deinstall
  facility, i.e., "Remove Software Products" or -u flag.  NOTE:  This
  will remove an entire fileset.)


    devices.pciex.771000801410b003.diag 6.1.4.0 # 10 Gb FCoE PCI Express Dual Port Adapter Diagnostics
    devices.pciex.771000801410b003.rte 6.1.4.0 # 10 Gb Ethernet-SR PCI Express Dual Port Adapter Software
    devices.pciex.7710008077108001.diag 6.1.4.0 # 10 Gb FCoE PCI Express Dual Port Adapter Diagnostics
...

Hogy ezek valoban az utolso TL upgradekor kerultek fel, igy ellenorizheto:

# lslpp -h devices.pciex.771000801410b003.diag
  Fileset         Level     Action       Status       Date         Time
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  devices.pciex.771000801410b003.diag
                  6.1.4.0   COMMIT       COMPLETE     02/23/10     19:03:04

Mint lathatjatok, tegnapelott este kerult fel ez a fileset,es mint a history (-h) mutatja, nem volt korabban telepitve. A COMMIT egyben azt is jelzi, hogy innen nincs downgrade, csak uninstall - erre utal a fenti hiba is.

Kaptunk egy listat, amiben vannak:

• leszedheto filesetek APPLIED allapotban
• legutobb felkerult, leszedendo fuggosegekkel rendelkezo uj filesetek COMMITTED allapotban
• a fenti 'reverse fuggosegek' miatt le nem szedheto filesetek APPLIED allapotban

Eloszor tehat szedjuk le a masodik csoportot (ezek a mi esetunkben foleg az uj TL-ben tamogatast nyert uj hardverek miatt felkerult egzotikus driverek voltak), utana mar menni fog a reject az osszes tobbire. Persze ha az uj TL eppen valami hardvertamogatas miatt kellett, akkor oboa van...

A reject utan ellenorizzuk, hogy visszakerultunk-e az elozo TL-re, illetve rendben van-e minden fileset:

# oslevel -s
# lppchk -v

A sikeres reject utan kell egy bosboot (boot logical volume ujrageneralasa), majd reboot.