EPIC moments - Avagy miért születetthetett meg a pokoli operátor?

Az ember néha tényleg azt hinné, hogy a hülyeségnek azért valahol csak van határa, de időről időre rá kell döbbenjek, hogy az ami még tegnap tényleg jó viccnek tűnt, ma már lehet komor valóságként materializálódik a szemem előtt.

Álljon hát itt néhány kis szösszenet azokból az "URAM ISTEN" pillanatokból, amiket az elmúlt időszakban sikerült megtapasztalnom.

1) - "Van e elég hely a /dev/null alatt?"

Anno volt ez egy elszólása egy némileg távoli kollégámnak, amin sikerült jót vigadni. A dolog apropója annyi volt, hogy az egyik logfile-t átirányítottuk a /dev/null alá (mondván, hogy úgy se használjuk, csak ha debugolni kell) erre ő -féltve, hogy az FS megtelik- megkérdezte, hogy van e elég hely alatta.. Ez anno tényleg vicces volt, viszont amikor az ember ilyet lát, de most már kezdem azt hinni, hogy ilyen felszólalásokat Murphy felhívásnak érzi, hogy megcáfolja őket ; főleg amikor ilyesmi issue jön az emberrel szembe:

server@root:/ # df -m /
Filesystem    MB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4         192.00      0.00  100%     3694    85% /
server@root:/ # du -axk / |sort -rn |head -5
193860  /
109992  /dev
109956  /dev/null
27160   /etc
24272   /lpp
server@root:/ # ls -l /dev/null
-rw-------    1 root     system    112590848 Aug 23 19:55 /dev/null
server@root:/ # du -m /dev/null
107.38  /dev/null
server@root:/ # file /dev/null
/dev/null: commands text

Hogy az a jó élet.. WTF?? A /dev/null nem egy character file-nak kéne lennie? Dehogynem.. Akkor miért nem az?? A válasz: Mert valaki letörölte.. Az első jött ment process meg nyomban létre is hozta a file-t egy átirányítás révén ($command 2>/dev/null - szerintem mindenki látott már hasonlót :)), ami aztán lassan meg is telítette a / filerendszert..

* facepalm * ... Aztán akkor meg a gyógyszer:

rm /dev/null; mknod /dev/null c 2 2; chmod 666 /dev/null

Ha azt hiszitek, itt vége a sztorinak tévedtek!! Murphy úgy gondolta, hogy lesz 2. felvonás is:

server@root:/ # ls -l /dev/null*
crw-rw-rw-    1 root     system        2,  2 Aug 23 15:09 /dev/null
-rw-r--r--    1 root     system     20057274 Aug 23 13:54 /dev/null 2>&1

*sigh* Ez meg mi a lóturó...

Kis turkálás, majd az oka is megvan: http://www-01.ibm.com/support/docview.wss?uid=nas74d33539b559cc0308625792900533a8f
Igen.. A programozók ilyet is tudnak...

2) - Forkbomb sudo-val

A szituáció a következő: Megpróbálsz belépni a rendszerre, de a belépés sikertelen. HMC-ről látod, hogy a gép megy, de a gépet a virtuális terminálon át se sikerül elérni (a terminál megnyílik, de login screen-t nem kapsz). A gép lényegében vegetál, úgy hogy nincs más mint előre - force restart HMC-ről. A gép vissza is jön az életbe, persze az okot ekkor még nem tudjuk, tehát elkezdünk nézegelődni a logokban, hogy mi a fene van.. Rövid vizsgálódás után a shell közli velem, hogy "unable to fork"..
Őőő... Mi van??? És a gép tényleg ismét elkezdi azt amit előtte is: nem lehet vele semmit se kezdeni..
Újabb újraindítás, svmon-al nézzük, hogy mi zabálja a memóriát, de semmi különöset nem látok.. topas.. detto semmi.. ps lista.... állj..

server@user:/ # ps -ef
     UID      PID     PPID   C    STIME    TTY  TIME CMD
    root        1        0   0   Jul 05      -  0:06 /etc/init
    root  1441896        1   0   Jul 05      - 21:51 /usr/sbin/syncd 60
    root  1638488        1   0   Jul 05      -  0:00 /usr/ccs/bin/shlap64
    root  1769656        1   0   Jul 05      -  0:00 /usr/lib/errdemon
    root  2359508  8192170   0 17:57:36  pts/0  0:00 -ksh
    root  2424966  3145848   0   Jul 05      -  0:00 /usr/sbin/biod 6
    root  2556062  3145848   0   Jul 05      -  0:01 /usr/sbin/hostmibd
    root  2752642  3145848   0   Jul 05      -  0:02 /usr/sbin/syslogd
    root  2818192  3145848   0   Jul 05      -  1:35 sendmail: accepting connections
    root  2883696  3145848   0   Jul 05      -  0:02 /usr/sbin/snmpmibd
    root  2949226  3145848   0   Jul 05      -  0:26 /usr/sbin/aixmibd
    root  3014786 15335476   0 17:57:32  pts/0  0:00 -ksh
    root  3080398  4391120   0 17:57:29  pts/0  0:00 -ksh
    root  3145848        1   0   Jul 05      -  0:00 /usr/sbin/srcmstr
    root  3211378  3145848   0   Jul 05      -  0:00 /usr/sbin/snmpd
    root  3342544  4194544   0 17:57:33  pts/0  0:00 -ksh
    root  3407976  3145848   0   Jul 05      -  0:00 /usr/sbin/portmap
    root  3473514  3145848   0   Jul 05      -  0:00 /usr/sbin/inetd
    root  3539066  7864376   0 17:57:32  pts/0  0:00 -ksh
    root  3604658 10420352   0 17:57:33  pts/0  0:00 -ksh
    root  3735804  7536670   0 17:57:34  pts/0  0:00 -ksh
    root  3801268  7340182   0 17:57:32  pts/0  0:00 -ksh
    root  3866832  9044146   0 17:57:31  pts/0  0:00 -ksh
    root  3932166  7667938   0 17:57:34  pts/0  0:00 -ksh
    root  3997750  9764978   0 17:57:30  pts/0  0:00 -ksh
    root  4063286  4259944   0 17:57:31  pts/0  0:00 -ksh
    root  4128854 12910818   0 17:57:34  pts/0  0:00 -ksh
    root  4194544 12320872   0 17:57:33  pts/0  0:00 -ksh
    root  4259944  8978666   0 17:57:31  pts/0  0:00 -ksh
    root  4325470 13041670   0 17:57:35  pts/0  0:00 -ksh
    root  4391120 10223744   0 17:57:29  pts/0  0:00 -ksh
    root  4456662  3604658   0 17:57:34  pts/0  0:00 -ksh
...
    root 15335476 11337968   0 17:57:32  pts/0  0:00 -ksh
    root 15401026 12648676   0 17:57:36  pts/0  0:00 -ksh
    root 15532266 15204356   0 17:57:37  pts/0  0:00 -ksh
server@user:/ # ps -ef |grep -c ksh
245

őő.. ez kicsit sok nem?? Plusz mi a fenétől jöttek ezek elő??? Közben persze telik az idő, és ismét beüt a krach ; újabb restart, de most már sejtem, hogy mi a probléma , valamiért túl sok ksh forkolódik és sok kicsi sokra megy alapon mindegyik lefoglal magának egy kis memóriát, ami azért ekkora léptékben már képes megzabálni a gépet.. Úgy hogy az újraindítás után nyomban proctree-vel kezdem a játékot, s mit látok?

server@user:/ # ps -ef |grep ksh |tail -1
    root 1478878 1466588   0 18:20:10  pts/0  0:00 -ksh
server@user:/ # proctree 1478878
434214    /bin/ksh /etc/rc.itm1
   389164    -ksh -c /opt/IBM/ITM/bin/itmcmd agent start ul >/dev/null 2>&1
      462944    -ksh
         385246    -ksh
            405732    -ksh
               176296    -ksh
                  442614    -ksh
                     381148    -ksh
                        94260    -ksh

És innen meg végtelen sorokban ksh hegyek..

Na nézzük mi jön le ebből: Van egy 434214 PID-ű process-ünk ami épp egy ITM6-os indító script, ami meghívja az UL agent startupját, ami meg aztán hegyekben szórja a ksh-s forkokat.. Ahogy a hívásból látjuk egy ksh futtatja magában a /opt/IBM/ITM/bin/itmcmd file-t is (ergo az is script), ami meg init-ből indul..
Scriptet megnéztem - semmi különös - a szokásos hívások vannak csak benne.. Fejvakarás, wattafák.. Majd megpróbálok én is felmenni root szintre sudo-val, és furcsa módon tapasztalom, hogy bizony, shell-t azt nem kapok... Ctrl+C hegyekben, aztán csak kaptam shell-t..
Ez volt az a pillanat amikor már kezdtem azt hinni, hogy a root user-el van csak gond ( a user shellem gond nélkül ment), ergo belekukkantottam a root profile file-jába, és ezt a gyönyörűséget láttam:

server@root:/ # cat .profile
export ENV=.kshrc
# Define initial prompt to include hostname
export PS1=`hostname`@$USER':$PWD # '
sudo su -

ŐŐ.. Álj.. 'sudo su -' a root profiljában???? KI VOLT AZ A MARHA???? Profil átír, 'sudo su -' sor eltávolít, rendszer ujraindít, minden működik szépen.

Na de mi is történt? - valamelyik ökör belerakta a root profiljába a 'sudo su -' sort.. Miért is gond ez? Mert a 'sudo su -' a root user alatt kérdés (meg jelszó kérés) nélkül lefut, és egy újabb shell-t nyit, ami meg megint beolvassa a root .profile-ját, ami így megint lefuttatja a 'sudo su -'-t és így tovább amíg a szerver bírta...
Ergo valaki ügyesen fork bomb-á alakította a sudo-t root alatt :)

3) - Az öngyilkos java alkalmazás

Anno még írtam is az egyik szép kis kamikáze kódról, ami sikeresen szembe jött velem.. Most újra elő kell vegyem a témát, mert az amit láttam az nem hogy ennek egy emeltebb formája volt, mintsem egy komplett seppuku :)
Na szóval... Van egy szerver, egy rajta futó Websphere (Web's Fear) alkalmazással rajta, amin belül meg fut egy valaki által írt applikáció jópár éve..
Egyik nap megszólal a vészharang, ügyfél sikoltozik, hogy a hőn szeretett alkalmazása nem működik.. Jó, rendben nézzünk utána.. Kis nyomozás, közös munka az application support group-al, majd kiderül, hogy hiányzik az alkalmazás "magja". Pontosabban ott van, csak nem úgy működik, ahogy kéne (azaz sehogy).
Az elején még nem értettem miről van szó, de aztán lassacsakán megvilágosodtam.. Íme egy röpke összefoglaló arról, hogy mi történt (időrendi sorrendben)
- Jópár éve már, hogy valami fejlesztő palánta megírta az alkalmazás core modulját
- Ez a modul jópár évig gond nélkül, aztán beütött a krach - Az applikáció összeomlott, majd nem volt képes újraindulni.
- Az applikáció HOME könyvtárában lévő core file elemzése után kiderült, hogy az alkalmazás egy verem hiba miatt esett össze, majd a szokásos módon dobott egy java core-t. Mindezt egy olyan applikációs almodul játszotta el, amit közvetlenül a fő mag hívott
- Aki még nem találta ki, annak itt a csattanó - Igen, az applikáció magját 'core'-nak hívták.. Ezt volt a file neve..

Tehát mi is történt: Volt egy core nevű alkalmazásunk, ami szépen futott, míg az egyik almodulja (ugyan abból a HOME-ból futtatva) nem dobott egy coredumpot, ezzel szimplán felülvágva az eredeti 'core' file-t, innentől meg az alkalmazás központi magja nem volt elérhető, ergo persze, hogy nem is indult el ez után.

És egyesek még csodálkoznak, hogy az IT-sok néha "kicsit" idegesek.. El nem tudom képzelni miért..

Murphy és a "jó" design

Elég mozgalmas volt ez az április, így nem sok időm volt blogolni bármiről is, de azért egy "emlékezetes" issue úgy érzem megérdemel annyit, hogy megmaradjon az utókornak.

Hol volt, hol nem volt (az óperenciás rendszeren is túl) volt egy szerver, aminek a design-ját okos emberek kialakították, és megítélendék jónak. Persze az okos emberek teljesen másra szánták a gépet mint amire azt később a customer nevű állatfaj elképzelte. Így alakulnak ki a természetben az olyan félvér állatfajok, amik inkább csak a hibáikkal tűnnek ki, mint sem a használhatóságukkal, és tuti biztos, hogy a lelkes adminisztrátorok előbb utóbb rájönnek, hogy az ilyen szerverek is inkább csak elrettentő példának jók, min tsem produktív dolgok futtatására, de hát a customert ez a legkisebb mértékben se szokta érdekelni, neki csak az a fontos, hogy az über-fontos dolgok menjenek a gépen..

Na most.. Ha még vannak olvasók akik nálam jobb emlékezettel vannak megáldva, akkor nekik lehet dereng valami a múltból, amikor a design hibákat ecsetelgettem, és már akkor is elmondtam, hogy az adott architect-nek jó rejszolást kívánok egy sajtreszelő társaságában, hogy ezt a design-t képes volt megálmodni

Hogy, hogy nem, most Áprilisban jött el az ideje annak, hogy Murphy ismét szórakozni akarjon, és kitalálta, hogy ez az igen fontos gép amúgy is billeg a szakadék szélén, hát miért ne lökjön rajta egy kicsit.. Persze ha már ott van, akkor a mentőalakulatok útjába is felállít 1-2 csapdát, mert az úgy még is csak nagyobb a FUN faktor.

A valóságban mindez a következőképp realizálódott:
Első körben a fenti design-ban szereplő RAID 5 tömb alól 2 diszk úgy gondolta, hogy őt már nem becsülik meg eléggé, így Seppuku-t hajt végre. "Mázlira" csak az Egyik diszk volt aktív, a másik csak Hotspare, így elméletben még itt nem kéne nagy problémának lennie. Így hát új diszk beszerez, hotplug manager elő, aztán cseréljük on-the-fly a temetőbe szánt Hotplug diszket, ahogy az a nagykönyvben is meg van írva.

Sajna azonban a Nagykönyvekkel mindig az a baj, hogy az emberek elfogadják a benne leírtakat egyfajta axiómának, ami -ha Murphy is a képben van- általában nem teljesen szokta lefedni a valóságot: Így hát persze így se minden úgy működött ahogy kellett volna.. Történt ugyan is, hogy a teljesen szabályosan kicserélt új diszket a rendszer nem volt képes lekezelni, mivel a régi konnekciós azonosítót valamiért nem akarta felszámolni.
Hogy szemléletesebb legyen a dolog, kb ezt látja a szerencsétlen adminisztrátor:

# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Degraded    RAID 5 Array            1135GB                 
 pdisk0   00000200  Failed      Array Member           283.8GB                 
 pdisk1   00000300  Active      Array Member           283.8GB                 
 pdisk3   00000500  Active      Array Member           283.8GB                 
 pdisk2   00000400  Active      Array Member           283.8GB                 
 pdisk4   00000600  Active      Array Member           283.8GB                 

*unknwn*  00000700  RWProtected Array Candidate            N/A                 
pdisk5    00000700  Missing     Disk                   283.8GB

Na szóval.. Vagy egy hdisk3 néven létező RAID 5 tömbünk, ami épp Degrad állapotban leledzik, mindez a sissas5 adapteren. Van 2 halott diszkünk (pdisk0,pdisk5), ami közül pdisk5-öt igyekszünk épp kicserélni, ami jelenleg épp Missing státuszban leledzik. A pdisk5 kapcsolati címén (00000700) azonban van még egy diszk, ami épp RWProtected, amúgy meg unknown (tehát a rendszer nem tud róla semmit). Így meg persze még neki se lehet állni új Hotspare-t definiálni (hogy aztán azt majd bedobjuk a pdisk0 helyére)

Na ez az a rész, amiről a nagykönyv nem ír semmit (Murphy viszont a Pop-corn egy részét már elfogyasztotta).. Ergo akkor nincs más, csak kidobni a vak hitet, és menni az ember saját feje után.
Első körben az előzőleg kicserélt diszk-et kivéve a slotból lehetőség nyílt az unknown device "elvesztésére" ám a rendszer pofátlan módon ragaszkodott a pdisk5 jelenlétéhez, attól függetlenül, hogy az már közel, s távol nem volt a gépben. Külön poénként ezt a meggyőződését még akkor se volt hajlandó elfelejteni amikor a pdisk5-öt 'rmdev -dl'-el lelőttem, majd a config managert (cfgmgr) futtattam, mivelhogy az rendkívül ragaszkodóan visszahozta a pdisk5-öt "Available" státuszban (a RAID vezérlő persze még mindig Missing-nek látta).

Na akkor itt álljunk meg egy picit.. Felmerül a kérdés -gondolom- az olvasóban, hogy biztosan a jó diszk lett kihúzva? Igen, ez volt az első felmerülő kérdés bennem is, de többszöri vizsgálat után is csak az jött ki, hogy valóban a jó diszket piszkálom és az AIX (VIO, de a lényegen semmit nem változtat) az aki foggal körömmel ragaszkodik ahhoz a diszkhez.

Fejvakarás, cseresznyefák, és wattafák.. Avagy csak fák.. Kinek mi esik jól.. Murphy közben a Pop-corn mellett már elindította a háttérben a Kokaku Kidotai (Ghost in the Shell) OST-t is, mert ehhez a jelenethez ez illik a legjobban..

Adminisztrátor részről persze teljes értetlenség, keresés, látott e már valaki valami ilyesmit? Aztán szembejön ez a bug, és fény gyúlik a katakombákban : IZ72353 - SAS PDISK DISPLAYED AS *UNKNWN* AFTER REPLACE/REBUILD APPLIES TO AIX 6100-03

Jah hogy úgy... Hát úgy.. A gáz csak annyi, hogy a patch magában nem elérhető (mivel VIO-ról beszélünk, így csak VIO frissítéssel együtt oldható meg a csótányirtás), így (mivel már mindenki a hátunk mögött van, és a messzeségben már a mesterlövészek is a mi monitorunkat lesik a fejünk mellett) a leggyorsabb megoldás a restart marad. Persze előtte minden kliens azonnal állj, addig a VIO se mozduljon semerre..

Restart, öröm és boduttá.. A pdisk5 végre defined-ban jön fel, sőt az újonnan beletett vinyót is már látja a rendszer.. Sínen vagyunk mint József Attila..
HotPlug diszk megformáz 528 Byte Szektor mérettel, majd a pdisk0 kipöccintése után nyomban be is áll a helyére az immár hamvaiból feltámadt pdisk5 Főnix madár, indulhat az Array Rebuild, semmi ok a pánikra, minden a Ctrl billentyű alatt van

Hátradőlünk, és szépen várjuk, hogy a tömb újjáépítése befejeződjön. A háttérben viszont Murphy ráadást követel, így hát újabb szám zendül fel a hangszórókból.

A moziban ilyenkor kezdenének el villogni a piros villogók, felharsognának a szirénák, és valami kis rangú emberke kétségbe esve megszólalna, hogy "Sir, Something is wrong!" (Thank you, Caption obvious). A valóságban azonban az embert csak egy ilyen hibaüzenet fogadja a fekete putty ablak mögött:

# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Failed      RAID 5 Array            1135GB Rebuild Failed 04
 pdisk5   00000700  Failed      Array Member           283.8GB                 
 pdisk4   00000600  RWProtected Array Member           283.8GB                 
 pdisk3   00000500  RWProtected Array Member           283.8GB                 
 pdisk2   00000400  RWProtected Array Member           283.8GB                 
 pdisk1   00000300  Failed      Array Member           283.8GB                 

pdisk0    00000200  RWProtected Array Candidate        283.8GB

Őőő.. 'nyádat... Újratervezés..
- A pdisk5 most lett kicserélve, leformázva, leellenőrizve, így az garantáltan nem lehet halott (hacsak nem a vezérlő halt meg, de akkor már az ima is édeskevés lesz)
- A pdisk1re eddig nem jött egy hibajelentés se, így azt vessük górcső alá.
- Az errpt entry-jeit elnézegetve (54E8A127 error code (DEVICE OR MEDIA ERROR), ha valakit érdekel) az összes hibajegy a pdisk1-el megegyező Serial ID-ra jön, így tételezzük fel, hogy a pdisk5 Failed státusza az újraépítés során tapasztalt pdisk1 hibájának mellékhatása csak.

Ezzel viszont egy újabb probléma üti fel a fejét: A RAID5 tömb egyszerre csak 1 aktív diszk halált bír ki, kettőt már nem. Amennyiben a pdisk1-et is ki kell cserélni, akkor kalap,kabát, búcsút lehet mondani az adatainknak, mert 3 diszkből már nem engedi a vezérlő se helyreállítani a tömböt (Én megpróbáltam, de hát ez nem linux).
Egy mázli volt - amennyiben az ember újraindítja ebben a fázisban a VIO-t, akkor a SAS RAID vezérlő újra megpróbálja a tömböt össze-eszkábálni, ami viszont kitűnő alkalmat teremt arra, hogy az ember megpróbálja menteni ami menthető.

És itt most álljunk meg ismét egy pillanatra.
- Adott egy fél lábbal már a sírban lévő RAID5 tömb
- A tömbön lévő adatok egy része már garantáltan nem elérhető, tehát a disaster recovery elkerülhetetlen (ugye van disaster recovery plan? :) Megsúgom, az ilyen rendszereknél rendszerint nincs.. Itt a remek alkalom, hogy most fejben összeüss egyet, és imádkozz, hogy az a minimális backup process ami eddig volt elégséges legyen :D )
- Ha mindenképpen kell DR, akkor minek akarok én menteni bármit is?

Nos, a válasz némileg komikus: Az egyik kliens egy Linux rendszer (SLES 10), amely system VG-je 1 VIO-n található LV-re lett ráhúzva (az LVM kell, ha az ember normálisan akarja skálázni a meglévő erőforrásokat, szóval ez még érthető is). Ahhoz, hogy ezt visszaimádkozzuk 3 út maradt:
- Csinálni egy low level mentést byte szinten a "Guest" System VG-jét tartalmazó PV-ről (azaz a VIO-n lévő LV-ről) valahova a RAID tömbön kívűl, és azt megpróbálni visszatölteni amint az új RAID tömbünket kénytelenek voltunk újra kreálni
- Csinálni egy FS szintű backupot (SLES gyárilag tud ilyet), a RAID tömb 0ról való építése után pedig felhúzni egy alap SLES rendszert, és arra visszatölteni az itt készült backup-ot
- Megpróbálni csinálni egy bootolható ISO file-t, azt odaadni a VIO-nak, majd mint CD/DVD-t kiallokálni a kliens felé, és arról visszatölteni az adatokat (Standard Linux környezetben ez szépen megy is, de amúgy vannak direkt erre a célra elkészített programok is, mint pl a Mondo Rescue)

A baj csak az volt, hogy mind3 út buktatókkal volt kikövezve:
- Bootolható ISO készítés: Az elmélet jó, de az egyik verzióban fel kéne raknom a Mondo Rescue (vagy azzal egyenértékű) progit, ami sajna PPC-re nem elérhető. A Debian féle módszer még működne is, de sajna a pSeries gépeken a boot loader nem grub, hanem Yaboot, ami meg nyomban úgy kezdi, hogy külön FAT16 típusú partíció neki, ami az ISO image-em szempontjából így nem járható.
- Az FS szintű backup azért necces, mert egy teljesen új rendszer felinstallálása szükséges hozzá, ami meg iszonyat nagy macera.
- A low-level (dd) szintű backup tűnt a legjobbnak (és akkor még az LVM struktúra is megmarad), ám amennyiben a RAID5 tömb ezen belül hibásodott meg, akkor meg megint ott vagyok ahol a part szakad..

Nem volt mit tenni: Úgy döntöttem, hogy amit lehet menteni kell (lehetőleg minél többféle képen), mivel a jelenlegi állapotot tutira újra is kell építeni. Tehát csináltam egy dd szintű mentést (LPAR lekapcsolva természetesen), meg egy FS szintűt is, felkészülve a legrosszabbra (az applikációs adatokért nem tudtam semmit se tenni, azt majd remélhetőleg a standard backup process által készített backup lefedi az adat visszaállítás során)

Ez után jött a másik 2 diszk cseréje (pdisk0, pdisk1), majd a halott RAID tömb törlése, és egy új készítése. Mindeközben sűrű miatyánk Mekka irányába..
Amint az új RAID tömb elkészült (immár hiba nélkül) lehetett visszahozni a régi LVM struktúrát, majd nekilendülni az adat visszaállításnak..
És igen.. Mázlim volt.. nettó 40 perc alatt a ~100 GB-os system VG-ről készített dd backup visszatöltődött (yaboot-al együtt), és az LPAR képes volt felbootolni (igaz RC 2ig nem jutott el, de ezen már lehetett segíteni), ergo már csak a tényleges applikációs adatok visszatöltése maradt vissza (meglepő módon azok visszatöltése közben nem nagyon akadt probléma)

Tapasztalatok a jövőre nézve:
- Ha tényleg über fontos adatról/alkalmazásról beszélünk, akkor erőltessük már meg magunkat, és a környezetet tényleg redundánsan alakítsuk már ki
- A RAID 5 addig jó, amíg kevés diszk van alatta. A tömb növekedésével együtt növekszik a teljes tömb meghalásának esélye is (mivel nagyobb az esélye, hogy 1 időn belül 2 aktív diszk hal ki, ahogy itt is történt (nagy eséllyel a használt diszkek ugyan abból a sorozatból valóak, ergo közel ugyan annyi idő alatt is halnak meg))
- Disaster recovery plan még akkor se árt ha van, ha amúgy a rendszer nem indokolja azt meg. A probléma a jelen setuppal az, hogy nem nagyon lehet rá 100%-os plan-t készíteni (ami effektíven használható lenne), a bootolható backup hiánya miatt (személyes véleményem szerint SLES pSeries-re nem való)
- Nagykönyv lehet, hogy létezik, de inkább tekintsünk rá amolyan "Kalóz Kódexként" ami inkább csak útmutatás, mintsem sérthetetlen szabály.. Valami úgy is valamikor el fog romlani, amire persze hogy nem leszünk felkészülve
- A szokásos halandzsa - update, update, update. Tudom, hogy az überfontos applikáció überfontos uptime-al kell üzemeljen, de kalkuláljunk már maintenance window-t is a rendszerhez, hogy az ilyen hülye önszopatásoktól megkíméljük magunkat.
- Murphy sose alszik, és mindig pörgős zenét hallgat :)

AIX mounting issue

Kicsit régebbi eset(2009.08), de gondoltam inkább lebloggolom, mintsem az enyészeté legyen, mert annál azért többet ér :)

Nos hát.. Alapvető probléma a következő: A rendszer indulásakor egy csomó filerendszer nem jön fel normálisan, holott a /etc/filesystems alatt szépen be van állítva, hogy azoknak bizony fel kell jönniük. A Volume Group szépen aktiválódik, de az alatta lévő FS-ek a rendszer indulásakor nem jönnek fel (Ha manuálisan mountoljuk őket, akkor viszont igen)

Kiegészítő információk:
- Az AIX kicsit régi a gépen (5300-10-01-0921) de ez nem indokolja a rendszer hibáját.
- A bootolás után a console log ilyen randaságokat tartalmaz:

0 Sun Aug 16 16:43:35 BST 2009 mount: 0506-324 Cannot mount /dev/lv_ap02n8log on /vfs=jfs2log=/dev/loglv27: A file or directory in the path name does not exist.
0 Sun Aug 16 16:43:35 BST 2009 mount: 0506-324 Cannot mount /dev/lv_ap02n2temp01 on /dev=/dev/lv_ap02n2data02log=/dev/loglv20: A file or directory in the path name does not exist.
0 Sun Aug 16 16:43:35 BST 2009 mount: 0506-324 Cannot mount /dev/lv_ap02n3data02 on /dev=/dev/lv_ap02n2temp02log=/dev/loglv20check=false: A file or directory in the path name does not exist.
0 Sun Aug 16 16:43:35 BST 2009 mount: 0506-324 Cannot mount /dev/lv_ap03n9log on /vfs=jfs2: A file or directory in the path name does not exist.

Mint az látszik a console logból a rendszer össze vissza kavarva próbál valami mount félét össze hozni, de nagyon kevés sikerrel.
Na de a kérdés.. Miért, és hogy?
Ehhez első körben vizsgáljuk meg, hogy mi (és hogy) is lenne a felelős ennek folyamatnak a lezongorázásáért:

A folyamat alapvetően egyszerű: a rendszer IPL-je során amint átvált a rendszer rc2-be nyomban elkezdi a /etc/inittab-ot feldolgozni, illetve az ott feltüntetett parancsokat/scripteket végrehajtani. Az egyik ilyen alap script a /etc/rc, ami a mountolásért is felel. Az akkor rendszeren az alábbi kód volt ezért a felelős (megjegyzés - a kód verziószáma 1.20.1.7 - ez még később fontos lesz)

# Perform file system checks
# The -f flag skips the check if the log has been replayed successfully
fsck -fp

# Perform all auto mounts
dspmsg rc.cat 4 ' Performing all automatic mounts \n'

cat /etc/filesystems | tr -d ' ' | tr -d '\t' | grep -vp "vfs=nfs" | grep -vp "vfs=cachefs"> /tmp/fs1.$$

# Collecting entries except nfs
lines=`wc -l /tmp/fs1.$$ | awk '{print $1}'`

# Calculate the number of lines
cnt=1

# Remove the file 'fs2.$$' if it already exists
if [ -f /tmp/fs2.$$ ]
then
        rm -f /tmp/fs2.$$
fi

# Compare each line in the file '/tmp/fs1.$$'
# If it is a comment line or just having the filesystem name,
# just write it to '/tmp/fs2.$$'
# Otherwise, add a tab before that line and write it to '/tmp/fs2.$$'

while [ $cnt -le $lines ]
do
        cat /tmp/fs1.$$ | head -$cnt | tail -1 | grep "^[\*/]"  1> /dev/null
        if [ $? -eq 0 ]
        then
                cat /tmp/fs1.$$ | head -$cnt | tail -1 >> /tmp/fs2.$$
        else
                param=`cat /tmp/fs1.$$ | head -$cnt | tail -1`
                echo "\t"$param >> /tmp/fs2.$$
        fi
        cnt=`expr $cnt + 1`
done
mount /tmp/fs2.$$ /etc/filesystems
mount all
umount /etc/filesystems
rm -f /tmp/fs1.$$ /tmp/fs2.$$

Nah.. mit is látunk itt...
- Első körben a rendszer létrehoz egy /tmp/fs1.$$ file-t ($$ a PID szám, amivel maga a /etc/rc fut), amit aztán majd alapnak fog használni. A file-ból minden tab és szóköz hiányzik, illetve a cachefs-eket is kikapja belőle a grep -vp.
- Aztán egy $lines változót használva a rendszer megnézi, hogy az így keletkezett file hány soros (bár sztem kicsit undorítóan csinálja, de hát ízlés kérdése).
- Mindezek után egy counter-t használva ($lines értékéig) egy teljes while ciklus indul, ami egy (szerintem szintén undorító módon) sorról-sorra végigmegy, és megnézi, hogy az adott sor '*'-al, avagy '/'-el kezdődik e (grep visszatérési értéke). Amennyiben igen, úgy az adott sor átkerül egy /tmp/fs2.$$ file-ba. Amennyiben mégse így történne akkor is, csak az adott sor kap maga elé egy tabulátort.
- Amint a ciklus lefut egy meglehetősen furcsa módszerrel a /tmp/fs2.$$-ban lévő FS-eket mountolja a rendszer (figyelem - a /etc/filesystems helyére felülmountolódik a /tmp/fs2.$$ ), majd a standard mount all parancsal minden a file-ban szereplő FS mountolódik (aminek a mount paramétere nem 'false').
- Amint ezzel is kész feloldja az előző mountot, majd törli a temporary file-okat.

A módszer kicsit tényleg furcsán néz ki (nekem főleg a sorról-sorra végigmenős módszertől borsódzik a hátam), viszont elméletben működnie kellett volna.. Akkor hol volt a probléma?? Nos.. végeztem pár tesztet, majd a szemem fennakadt, amikor nem az általam várt eredmények jöttek ki:

A használt script a következő volt:

#!/bin/ksh
set -x
lines=`wc -l /tmp/fs1.temp | awk '{print $1}'`
cnt=1

while [ $cnt -le $lines ]
do
        cat /tmp/fs1.temp | head -$cnt | tail -1 | grep "^[\*/]"  1> /dev/null
        if [ $? -eq 0 ]
        then
                cat /tmp/fs1.temp | head -$cnt | tail -1 >> /tmp/fs2.temp
        else
                param=`cat /tmp/fs1.temp | head -$cnt | tail -1`
                echo "\t"$param >> /tmp/fs2.temp
        fi
        cnt=`expr $cnt + 1`
done

Lényegében azonos a standard scriptel, az eredmény (/tmp/fs2.temp) viszont nem az volt amit vártam:

/var:
dev=/dev/hd9var
vfs=jfs2
    log=/dev/hd8
    mount=automatic
check=false
type=bootfs
    vol=/var
    free=false
quota=no

/tmp:
    dev=/dev/hd3
    vfs=jfs2
log=/dev/hd8
mount=automatic
check=false
vol=/tmp
free=false
quota=no

/proc:
    dev=/proc
    vol="/proc"
    mount=true
    check=false
    free=false
    vfs=procfs

Mit látható.. A TAB-ok egy csomó helyen nem kerültek a helyükre.. Na akkor nézzük meg azt az elágazást kicsit közelebbről:

cat /tmp/fs1.temp | head -$cnt | tail -1 | grep "^[\*/]"  1> /dev/null
if [ $? -eq 0 ]
then
        cat /tmp/fs1.temp | head -$cnt | tail -1 >> /tmp/fs2.temp
else
        param=`cat /tmp/fs1.temp | head -$cnt | tail -1`
        echo "\t"$param >> /tmp/fs2.temp
fi

Tehát.. Ha a $? (előző parancs (grep) Return Code-ja) 0 akkor csak rakja bele, ha meg nem akkor toldja meg egy tabbal.. Hát jó. csináljunk egy kis tesztet:

server:root # while true;do cat /tmp/fs1.temp | head -172| tail -1 | grep "^[\*/]"  1>/dev/null;echo $?;done
1
2
13
13
13
13
13
13

És kb itt nyomtam Ctrl+C-t..

Mit is csináltam? - egy végelenített ciklust, amikor is folyamatosan ugyan azt az adatot kértem ki (head+tail) majd megnéztem a grep return code-ját.. Az viszont azonos adat esetén (172. sor) különböző eredményt produkált! Wattafák???

Nos.. Mint kiderült sikerült belefutni egy meglehetősen érdekes issue-ba. Ennek az issue-nak neve is volt: IZ43276: KSH MAY RETURN INCORRECT RETURN CODE FOR PIPED COMMANDS APPLIES TO AIX 5300-11

Aha... Hogy úgy... Én is üdvözöllek.. A problémámon ez a tudás akkor viszont még nem segített.. A patch-et csak 2010ben adták ki, ami azt jelentette, hogy én 2009ben még csak feliratkozhattam a fix "hírlevél mondóra" és várhattam, hogy javítják a hibát..

Viszont mint kiderült azért volt kerülőút: Az AIX 5.3 TL6-tól (TL10-en van a rendszer, emlékeztek? :) a /etc/rc file már a 1.20.1.9 verzión volt, ami ugyen ezt a problémát (FS-ek mountolása) sokkal szebben oldotta meg:

# Remove the file 'fs1.$$' if it already exists
rm -f /tmp/fs1.$$

# handle the egrep line carefully: between each pair of brackets is a tab
# followed by a space, and the tab may get lost if you copy and paste the line
egrep -vp "^[ ]*vfs[ ]*=[ ]*(cachefs|nfs|cifs)[ ]*$" \
/etc/filesystems > /tmp/fs1.$$

mount /tmp/fs1.$$ /etc/filesystems
mount all
umount /etc/filesystems
rm -f /tmp/fs1.$$

Éljenek a Reguláris kifejezések.. Ennek a kódnak köszönhetően pedig (mivel nem használ hülye visszatérési értékeket) a mount problémám megoldódott (persze a rendszeren lévő további scriptek amik erre támaszkodtak ettől még szívhatták).

Egy kérdés maradt csak nyitva - Ha ez TL6tól elérhető volt, akkor miért nem ez a verzió volt elérhető a TL10-es AIX alatt is?

A válasz persze "prózai" - A fejlesztők szerint a /etc/rc file-t a customer (ha nem is nyugodtan, de.. ) bármikor szerkesztheti, így úgy gondolták, hogy az upgrade során ezt a file-t inkább ne piszkálják (hisz új funkciót amúgy se hoz) upgrade során. Ergo ha a rendszer egy régebbi szintről ( < TL6 ) lett felhúzva TL10-re, akkor az upgrade véletlenül se fogja a frissebb file-t a helyére pakolni. Max akkor ha a rendszert már az elejétől fogva TL6, vagy afölötti verzióval telepítették (ergo az újabb /etc/rc már alapból része a telepítő csomagnak)..

Igen.. Én is örültem amikor megtudtam :)

Halott diszk, halott paging.. Mit is kezdjek veled..

Úgy nézem ez a Július tele lesz finomságokkal..
Mai nap például pont ez jött szembe:

server # errpt |head
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
16F35C72 0714150111 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714150111 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714145911 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714145911 P H hdisk1 DISK OPERATION ERROR

Ohh, hát ezt ismerjük... Nézzük használjuk e:

server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c psvg1 active

Használjuk.. szupi.. Akkor nézzük a szokásos mókát: Lebontom a tükröt, kiveszem a diszket a VG alól, aztán majd valamikor cseréljük a diszket.. De ehhez persze tudnom kell, hogy a tükör ép e.. Hát nézzük:

server # lsvg -p psvg1
0516-062 : Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics

őőő.. állj.. ez így már nem vicces..

server # lspv |grep -w psvg1
hdisk1 0050db3a8c87dd2c psvg1 active

Ja hogy nincs tükör??? Extra mód nem vicces.. Nézzük mi volt alatta, ha ne adj isten restore-olni kéne:

server # odmget -q parent=psvg1 CuDv

CuDv:
name = "paging00"
status = 0
chgstatus = 1
ddins = ""
location = ""
parent = "psvg1"
connwhere = ""
PdDvLn = "logical_volume/lvsubclass/lvtype"

Ohh.. mázli.. szal csak egy paging.. Szívroham el, de attól még él a probléma.. Nézzük akkor hogy is állunk:

server # lslv paging00
LOGICAL VOLUME: paging00 VOLUME GROUP: psvg1
LV IDENTIFIER: 0050db3a00004c00000000fc2d691d85.1 PERMISSION: ?
VG STATE: active/complete LV STATE: ?
TYPE: paging WRITE VERIFY: ?
MAX LPs: ? PP SIZE: ?
COPIES: ? SCHED POLICY: ?
LPs: ? PPs: ?
STALE PPs: ? BB POLICY: ?
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: center UPPER BOUND: 32
MOUNT POINT: N/A LABEL: None
MIRROR WRITE CONSISTENCY: ?
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: ?

server # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging01 hdisk2 psvg2 17344MB 1 yes yes lv
0516-062 : Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
hd6 hdisk0 rootvg 3072MB 1 yes yes lv

Na erre szoktam mondani, hogy annyira nem biztató.. Na mind1.. tudjuk az LV (innentől fogva a Paging nevét) nevét, szedjük le róla a paginget..

server # chps -a n paging00
server # rmps paging00
0517-062 rmps: Paging space paging00 is active.
0517-061 rmps: Cannot remove paging space paging00.

server # swapoff /dev/paging00
server # rmps paging00
0516-062 lqueryvg: Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
0516-912 rmlv: Unable to remove logical volume paging00.
0517-061 rmps: Cannot remove paging space paging00.

Ilyenkor jön az, hogy elevenítsük fel az "I love to say fuck" c. számot, mert bizony ez kibaxás...

Na mind1.. Ha nincs más, akkor csak az előre: Elő a hegesztő pákát, és hegesszük ki a rendszer alól az LV-t:

server # odmdelete -q name=paging00 -o CuAt
0518-307 odmdelete: 5 objects deleted.
server # odmdelete -q dependency=paging00 -o CuDep
0518-307 odmdelete: 1 objects deleted.
server # odmdelete -q name=paging00 -o CuDv
0518-307 odmdelete: 1 objects deleted.
server # odmdelete -q value3=paging00 -o CuDvDr
0518-307 odmdelete: 1 objects deleted.

Majd próbáljuk meg varyoffolni a VG-t:

server # varyoffvg psvg1
0516-062 lqueryvg: Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics

Na most akkor ment, vagy nem ment?

server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c psvg1

Hoppá!! Nem aktív.. Fény az alagút végén :))

server # exportvg psvg1
server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c None

Szuper :) Akkor nézzük a paginget is :

server # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging01 hdisk2 psvg2 17344MB 1 yes yes lv
hd6 hdisk0 rootvg 3072MB 1 yes yes lv

Éljen a magyar :)) Megy minden szépen tovább :) No outage, no issue :))

Linux - "Full" disk encryption

Úgy esett, hogy a hétvégémet rászántam, hogy a Thinkpadomon lévő Ubuntu alapú rendszert átpatkoljam, hogy a rajta lévő összes adat encrypted legyen (éljen a security).. Hát.. Valahogy nem úgy ment, ahogy vártam :)

A terv a következő volt:
- LiveUSB alól készítek egy backupot a futó rendszeremről
- Alternate install bebootol, majd az alól újrahúzom a rendszerem immár Encrypted LVM-el (LUKS), majd az LVM-en belül létrehozom az LV-ket, amiket meg aztán mountolgatok a megfelelő pontokra
- Backupból visszahozok minden fontosabb adatot, illetve az összes telepített programomat is, ha már ott tartok
- Profit..

Csak hát Murphy (plusz az én felkészületlenségem is részben) nem így gondolta.. nézzük mi is történt a valóságban.

- Backup:
A kiszemelt 40 GB-os USB-s vinyó (amit a backup céljára kiszemeltem) sajna csak 1 USB csatlakozóval rendelkezett, a hozzá illő tápcsatalakozót nem mellékelték. Ettől függetlenül persze a gép szépen látta az eszközt, sőt írni is hajlandó volt rá.. A probléma onnan indult, amikor random időközönként leszakadozott, így téve lehetetlenné, hogy backupot csinálhassak rá. Ez azért is volt problémás, mert hogy a közelben már csak egy gép volt, az is Windows.. Sebaj mondom, csinálok egy SMB megosztást, oda meg áttolok mindent.. Persze ahhoz, hogy a file attribútumokat megtartsam ezt úgy tudtam csak levezényelni, hogy mindent egy tar-ba toltam bele.. Így lett a végén egy közel 37 GB-os tar file-om.. De legalább volt backup.. De persze úgy voltam vele, hogy 1 backup nem backup (főleg nem ha tar), így biztosra mentem, és csináltam egy teljes dd mentést is a diszkről, ami szintén a Win-es gépen foglalt helyet a művelet végeztével. Így már úgy éreztem, hogy bármi történjék, nem lehet baj (max visszahúzok mindent bitre pontosan ahogy volt a dd backupból)

- Telepítés
Mivel a rendszer ubuntu alapú, így az elképzelésem a következő volt: leszedem az alternate install-t (a grafikus telepítő nem támogat se LUKS-ot, se LVM-et), majd azzal megcsinálom. Tekintve, hogy a művelet végén amúgy is vissza akarok pakolni minden applikációt ami eredetileg fent volt, így lényegében csak az alapok érdekeltek. Így hát fogtam magam, leszedtem az alternate telepítőt, majd unetbootin-al felpakoltam USB-re (optikai lemezt már jó ideje nem szeretek ilyenre használni). Az első probléma ott volt, amikor a rendszer jelezte, hogy nem találja a CD meghajtót.. Néztem is nagyokat, hogy akkor most wattafák..
A problémára az első talált megoldás az lett, hogy a pendrive-on lévő Lucid mappát át kell nevezni stable-re (ami amúgy egy symlink lenne, csak persze FAT32-őn ez így nem megy), az majd megoldja a problémát. Szóval át TTY2-re, átnevez, "CD" újrainicializálás, és ment tovább.. Éljen..
A következő dilemma ott jött amikor particionálni kellett a rendszert.. A régi partíciós kiosztásom a régebbi migrálások miatt amúgy is elég kusza volt, így úgy gondoltam, hogy most már kicsit rendszerezünk is. Először viszont el kellett döntsem milyen filerendszert használjak az LVM miatt..

Szivem szerint Reiser4-et raktam volna majdnem mindenhova, de az sajna nem része a telepítőnek (ahogy a Brtfs és a ZFS se), így az alábbi lehetőségeim maradtak
- A 10.4es Lucid alatt támogatott modern filerendszerek, amelyeket növelni is lehet az alábbiak:
- ext4 - ezt személy szerint kerülöm, mint a rossz pénzt - az egyetlen filerendszer, amely fsck-ja képes a teljes FS-t a lost+found alá száműzni
- XFS - Ezt sajna csak növelni lehet (azt legalább online), csökkenteni nem
- ReiserFS - Lehet növelni, és csökkenteni is (ezt sajna csak offline), viszont a tapasztalatok alapján XFS jobban teljesít notebook-on.

Mivel az XFS-el vagyok a legjobban megelégedve, így úgy gondoltam, hogy ahol lehet (és nem számítok FS csökkentésre) úgy ott azt használom, máshol marad a Reiser.. Ergo az az alábbi stratégiával álltam elő:
/dev/sda1 - /boot (ext2) - 120 MB ( Ugye a GRUB 2 se tud encryptált kötetről bootolni, szal a /boot kénytelen a LUKS-on kívül lenni)
/dev/sda2 - Encrypted Volume (LUKS)
Az encrypted Volume-on belül pedig fogtam magam, és létrehoztam egy LVM-et, azon belül egy rootvg nevű VG-t, alatta pedig az alábbi LV-ket:
- datalv - /data (ReiserFS) - 20 GB
- homelv - /home (XFS) - 20 GB
- rootlv - / (ReiserFS) - 12 GB
- swaplv - SWAP (2 GB)

A biztonság kedvéért azért még hagytam 5 GB-ot a VG-ben kiosztatlanul, hogy ha kell akkor ne adj isten valakinek oda tudjam majd adni.
Miután ezt megcsináltam a telepítő közölte, hogy márpedig neki ezeket az adatokat fel kell írnia a diszk-re, és tuti biztos vagyok e abban, hogy én ezt komolyan akarom.. Magamban még1x átgondoltam a helyzetet, megbizonyosodtam, hogy minden szükséges óvintézkedést megtettem (backup!!!), majd úgy éreztem, hogy üsse kavics, a Vasárnap 13 óra pont alkalmas arra, hogy szeretett gépem OS-ét végérvényesen kibelezzem...
Ubuntu fel is írta az adatokat, majd váratlanul egy olyat szólt, hogy:
"Couldn't detect codename for release."
Ahogy nézem azért nem csak nekem kedveskedett már ez az üzenet..
Innen pedig a telepítő úgy gondolta, hogy nem is érdemes továbbmenni.

Na akkor vissza a kályhához... Újabb keresés, miközben az öröm a plafonon, hogy a partíciós tábláim is a levesben vannak már.. Aztán a megoldás is szembejött: A 'cdrom-detect/try-usb=true' bejegyzést is be kell szúrni az unetbootin által létrehozott menü entry-k közé.

Miután ez megvan irány vissza a telepítő, majd ismét a particionálás , majd vártam, hogy most már azért tovább is menjen.. Mázlimra tovább is ment, és a rendszer nagyja fel is ment.. Aztán valamiért ismét elhasalt, de itt már nem nagyon érdekelt ez az apró részlet - felraktam a GRUB2-t is az MBR-re (illetve a /boot alá), és restartoltam..
És lőn csoda- működik.. Igaz nincs se grafikus környezet, se wifi, se hasonlók, de legalább az alap rendszer működött, és ez volt ami nekem számított.. Innen már azt hittem sima dolog lesz minden: Nagy erőkkel neki is szaladtam a restore-nak a backupból.. Pontosabban szaladtam volna, mert a CIFS-et a mount itt még nem ismerte (nem voltak fent a szükséges csomagok).. És itt ütött (nagyon) vissza a 37 GB-os tar file.. Win alól tudtam olvasni, de úgy nem tudtam használni, hogy az attribútumokat is megtartsa a file..
Ergo ismét vissza a tervező asztalhoz...
A dolog vége az lett, hogy a Win-es gépen létrehoztam egy Virtuális gépet (Virtualbox), azt a rendszert felbootoltam egy Live USB image-el (ott már volt SM támogatás), bemountoltam a Win-en kiosztott SMB megosztást, kicsomagoltam a /etc-t (mc), majd ismét összetaroltam, visszaraktam a másik tar file mellé, azt átvittem pendrive-on, és figyelve, hogy az fstab-ot véletlenül se írjam felül visszaállítottam a /etc tartalmát.. Innentől már megvoltak a régi repository-jaim, ergo simán ment az apt-get update is, és fel tudtam rakni a szükséges csomagokat. Ez után már be tudtam mountolni a távoli SMB megosztásom, és láttam is a backupom..
Újult erővel indultam neki a restore-nak, ám ismét utamat álta egy  rendkívül idegesítő dolog: az mc nem volt képes lekezelni ekkora tar file-t (folyamatosan I/O error-ra panaszkodott), én meg nem akartam a teljes tar-t kibontani a filerendszerekre 2 oknál fogva:
- Nem akartam felülírni semmiféle olyan file-t ami esetleg a kernelhez köthető, vagy a grubhoz, esetleg bármi máshoz ami az új rendszer részeként fontos lehet..
- Mint előbb is mondtam a mountokat kicsit átalakítottam, így most már 1-2 FS nem is volt elérhető ott ahol régen voltak, az újak alatt meg nem volt ennyi szabad hely..
180 fok, vissza a fő géphez, és a Virtualbox-ban futó linuxhoz: Hozzácsaptam ehhez a géphez egy 60 GB-os kötetet, majd a teljes backupomat kicsomagoltattam ide.
Amint ez kész lett kiszedtem azokat a mappákat/file-okat amiket nem szeretnék felülírni véletlenül se, majd (immár kissebb méretben) újabb tar file-okat hoztam létre, amit immár az mc is képes volt megenni.. Pontosabban nem egészen.. Az mc a jelek szerint allergiás a speciális karakterekre (főként a @-ra, amire váltig állítja, hogy hardlink akar lenni), így maradt a puritán 'tar -xv' megoldás, amit így már rá is mertem engedni a gépre, tekintve, hogy már kigyomláltam a problémásabb részeket.
A művelet végére sikerült mindent visszaállítani, a gépem be is bootolt szépen, felállt a rendszerem is, bár volt még 1-2 problémásabb dolog..
Ami nekem első körben probléma volt: a rendszer által felrakott kernel-lel már voltak régen inkompatibilitási problémáim, így ez volt az a pont amit még mindenképp meg akartam csinálni. Ekkor már kb éjfél volt, de úgy voltam vele, hogy ezt még befejezem, aztán holnap már tudok is dolgozni a géppel, max munkaidőben a többi kisebb dolgot megcsinálom.. Ergo nekiálltam egy frissebb kernelt telepíteni.. Ez volt a hiba... A friss kernel olyan gyönyörűen felülvágta az initrd-met, hogy öröm volt nézni.. A következő indulással pedig már a crypt be se töltődött, és bámultam a fekete busybox-ot 2 asztal fejelés között..
Itt voltam úgy, hogy ezt már nincs mese, valahogy meg kell csináljam, holnap ezzel a géppel dolgozni kell. Próbálgattam a grub paraméterekkel játszani, de gyorsan be kellett lássam, hogy ha az initrd-ben nincs benne az ami nekem kell, akkor itt semmiféle grubos fekete mágia nem segít. Így hát liveUSB ismét elő, gép bebootol, kómás fej felébreszt, és lelki szemeimmel bámulom a szakadék túloldalán lévő partot, amihez most ismét nekem kell felépítenem a hidat.. Ami kb így nézett ki:

Feloldottam a titkosítást:
# cryptsetup luksOpen /dev/sda2 rootvg
Aktiváltam a VG-t:
# vgchange -a y rootvg
Megnéztem, hogy minden megvan e:
# lvm vgs
VG #PV #LV #SN Attr VSize VFree
rootvg 1 4 0 wz--n- 55.77g 5.49g
# lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
datalv rootvg -wi-ao 18.62g
homelv rootvg -wi-ao 18.62g
rootlv rootvg -wi-ao 11.18g
swaplv rootvg -wi-ao 1.86g
Bemountoltam a megfelelő FS-eket a /mnt/chroot alá:
# mount /dev/mapper/rootvg-rootlv /mnt/chroot
# mount /dev/sda1 /mnt/chroot/boot
# chroot /mnt/chroot
# mount -t proc proc /proc
# mount -t sysfs sys /sys
# mount -t devpts devpts /dev/pts
Ez után megnéztem hol is baxtam el.. Hát persze.. Én barom felülírtam a /etc/crypttab-ot, illetve a /etc/initramfs-tools/modules alatt se vettem fel az új dolgokat.. Erre bizony figyelni kellett volna.. Na mind1.. Pótoljuk akkor be..

# grep -v ^# /etc/crypptab
rootvg /dev/sda2 none luks,retry=1
# egrep -v "^#|^$" /etc/initramfs-tools/modules
aes-256
dm-crypt
dm-mod
sha256

Majd akkor ismét generáljuk újra az initrd-inket:
# update-initramfs -k all -c

Aztán restart, és ima...
Mákom volt.. Ez megoldotta a problémák nagyját.. A rendszer felállt, bár jó pár dolog nem ment (wifi, aku kijelzés,hang, network manager).. Ekkor már kb hajnali 2 volt, így úgy gondoltam, hogy nem érdekel, ebből már "holnap" tudok valamit kezdeni munkaidőben is.. dhclient megy, IP-t tudok kérni a kábelen keresztül, a fontosabb appok mennek, ezeket a hülyeségeket meg majd megoldom alvás után.
"Másnap" aztán kicsit kipihentebb fejjel átgondoltam mi a fészkesért is mehetett szét így minden, hisz az initrd piszkálás előtt ezek még mentek.. Első körben azt hittem elfelejtettem valami modult még belepakolni, de visszanézve a régi modulok listáját nem nagyon találtam különbséget, így ezt kénytelen voltam elvetni.. Majd fejbe csapott az isteni szikra: Mindezt a sok hülyeséget a dbus irányítja most már (hald sajna már nincs), így azt kéne helyrecsapni.. Mázlimra az első próba megtette a hatását:
# dpkg-reconfigure dbus
Ez után minden ment ahogy annak kellett.. Öröm és bóduttá.. Ismét tudtam dolgozni..

De persze ez a sztori nem lenne teljes, ha itt befejezném.. Akárhogy is nézem, azért volt jó pár dolog amiket ki szeretnék emelni:
- A tar nem backup solution.. Hiába használható annak, attól még lehet egy rsync-el jobban jártam volna, vagy más megoldással
- Este, fáradtan ne kezdjem el a rendszer alapkövét (kernel) piszkálni, mert nem biztos, hogy kifizetődő
- Legközelebb inkább telepítsem újra az egész gépet 0ról, és úgy húzzam vissza a dolgokat. Igaz, hogy ez a megoldás működőnek látszik, viszont nem tudom hány problémás részt hagytam a gépben, ami később visszaüthet. Egy clean install lehet problémamentesebb lett volna.
- Mielőtt nekiállok valami hasonlónak, 1x csináljam azt meg egy virtuális rendszeren! Csak én lehettem akkora marha, hogy a tényleges rendszernek mentem neki tényleges "szimuláció" nélkül, ami sok kellemetlenségtől megkímélt volna, plusz alapból olyan tapasztalatokat szolgáltatott volna, amik révén a tényleges migrálás valóban probléma mentesebb lett volna ( bár az is igaz, hogy ha ott egy ilyen issue-ba belebotlok, akkor ott valószínű nem kezdek el ilyen keményen dolgozni, hogy mindent helyrehozzak amilyen gyorsan csak lehet, és valószínű  ez a project jó pár hetet késett volna)

Hátlapát...

.. annak a baromnak aki ezt a szerver design-t kitalálta (avagy architect epic fail)
Adott egy Power6os box (p570), amelyen a következő setup-ot alkották meg az "okosok":
- Mivel a gép bírja, így pakoltak bele egy csomó diszket meg 1-2 SAS RAID controllert, mert miért ne.. Fiber Channelt persze minek..
- A gépen létrehoztak 2 VIO szervert, ahogy az a nagy könyvben meg van írva.. Egyedül annyi a gáz, hogy valszeg a nagy könyv első 20 oldala lehet csak meg, mert se a network-ot, se a storage-ot, de még a VIO-kat se csinálták redundánsra!
- Na de akkor minek a VIO - Fogták a 2 VIO szervert, majd 1-1 RAID controllert hozzájuk rendeltek. A gépben lévő megannyi szép nagy vinyókat meg pdiskenként bebaxták egy 1-1 nagyobbacska RAID5 tömbbe
- Ebből következik, hogy mint redundancia olyan nincs, mert a RAID kártyákat nem lehet több LPAR-hoz is hozzárendelni, ergo innentől van 2 külön VIO-nk 2 külön RAID5 tömbbel.. Na de mire kell ez?
- A megoldás egyszerű: Fogták magunkat, létre hoztak egy nagy VG-t a RAID tömbben, majd a VG-n belül létrehozott LV-ket Virtual Diszkként kiosztották az LPAR-oknak, hogy azok boldogan magukévá tehessék az immáron új diszkeket.. A probléma persze csak az, hogy mivel a RAID tömbök VIO-nként egyediek, így véletlenül se tudjuk ugyan azt a kiosztást megcsinálni mind2 VIO-nál, ergo a Virtual diszkek csak az 1ik VIO-n keresztül érhetőek el => A 2 VIO csak külön-külön LPAR-okat tud kiszolgálni!
Problémák ezzel a felállással:
- Nehezen bővíthető: Ha elfogy a RAID5 alól a hely, akkor aztán így járás, mert egy idő után a diszkek is elfogynak
- Mivel RAID5ről beszélünk, így a teljes RAID tömbben csak egy VG van. Ennek annyi előnye van, hogy 1 LPAR gond nélkül el tudja vinni a teljes kapacitást a többi elől, ha ő úgy akarja (és mivel applikáció is fut rajta, így persze, hogy úgy akarja )
- Redundancia mint olyan sehol nincs, sőt nem is nagyon lehet úgy átépíteni a rendszert, hogy legyen (az alapoktól újra kéne építeni).
- A vicc kedvéért az LPAR-okhoz használható NIM szerver ugyan azon boxon belül található, mint az LPAR-ok, így aztán komolyabb HW failure esetén (lehal a box) esélye nincs bárkinek is restore-olni az LPAR-okat..
- MINEK MINDEHHEZ VIO????