Gérczei Tamás kolléga egy elég hosszú és mély cikket írt tapasztalatáról egy KuroboxPro NAS-al. Természetesen a dobozt nem csak szokott módon használta, hanem minden féle speciális képességgel felruházta, persze komoly hack-eléssel. Ennek meséje és részletes technikai bemutatása következik most.
I. Intro
Valamikor, (jó-)néhány évvel ezelőtt olvastam érdekes cikkeket online egy japán csodáról – ekkor fedeztem fel a NAS fogalmát. Az elektronikai ipar fejlődése attól a ponttól tette műkedvelők számára akár otthoni használatra is ezeket a technológiákat. Természetesen nem másutt, mint az ‘Államokban és persze a gyártó országban: Japánban. Viszont én a fejembe vettem, hogy nekem kell egy ilyen – és elkezdtem európai viszonteladókat keresni. Természetesen hiába. A vége az lett, hogy a RevoGear jóvoltából Amerikából végül csak került a kezeim közé egy saját tulajdonú, nem kevés pénzt és vámköltséget kóstáló egység: egy KuroBox HG/WR.
A PPC processzorral (kategóriájához mérten abból sem gyengével), valamint (akkoriban) elegendő mennyiségű rögzített memóriával szerelt dobozka teljes mértékig lenyűgözött mind műszaki, mint design-szempontból: apró, gyakorlatilag súlytalan, elhanyagolható mérhető áramfogyasztású, jóformán hangtalan, és rendkívül bájos kalligrafikus írásjegyekkel megfejelt homlokú gadget. Nyilván mindenre akartam használni, csak arra nem, amire az alapfelszereltségével lehetett. Naná.
E ponton kell megjegyeznem, ez már a termék második revíziója volt akkor is, az áramellátást immár világszerte kompatibilissé tették ettől a modelltől fogva. Volt neki mindene: belső PATA (hogy mi? ;) IDE csatolója, a házra esztétikusan kivezetett USB (1.1 natürlich) aljzat – hibátlannak tűnt. A gyári firmware-t sosem láttam! Az első indítás is az ún. „EM-mode”-ban történt, és a második már egy fully-fledged Debian Sarge-ot lehelt életre az akkori Buffalo/MELCO (a termék gyártója) hobbifórum egyik fejlesztőjének, egy Sylver nickű úrnak hála…
Onnantól a saját kis házi serverem szolgált játszóteremül. Tudta, amit tudott, be is értem vele. Egy ideig. Konkrétan addig, amíg kevéssel a Gentoo disztribúcióval történő megismerkedésemet követően elmélyült a viszonyom az aktuálisan új kedvenccé előlépett rendszerrel, és a pontot a képzeletbeli i-re feltette az új hardware-revízió: a KuroBox/PRO megjelenése.
A beszerzés körülményei és módja nem sokat változott ekkorra sem, de a lényeg változatlan: a posta meghozta új „kütyümet”. Ekkor írtunk, azt hiszem, már 2007-et. Megcsúnyult kissé kívül – legalábbis kevésbé dögös, ellenben a processzor-architektúra ARM-ra változott, és a belső IDE csatoló SATA lett; az USB 2.0, és bejött a képbe még egy – ki nem vezetett – eSATA csatlakozás is szükség esetére.
Továbbra is lelkesen követtem az online olvasottakat, és ennek eredményeként egy Debian Lenny armel port kelt életre az új eszközön. Ideig-óráig elégedett is voltam vele, de ugye szerettem volna ezt is finomhangolni Gentoo-val – erről azonban lemondtam, mert a kapcsolódó HOWTO-k felét sem értettem :)
Nem sokkal később új feladatot találtam a doboznak: cmus-sal zenét játszott egy NFS share-ről egy USB csatolófelületű külső, 24 bites hangkártyán egy szép, fadobozos 2.1-es hangfalszettre. Igen ám, de a Lenny image-hez adott kernelből hiányoztak a nekem szükséges modulok – és nem csak az ALSA/OSS, de filerendszert is szerettem volna váltani. Adta tehát magát a feladat – kernelt kell fordítani! Ez nem lett volna önmagában probléma, mert hogy értettem ehhez – desktopokon. Hamar kiderült, hogy a küldetés nem egyszerű, és hogy a dolog jellege nagyban eltér a megszokottaktól. Már a források beszerzése is megérne egy mesét, de ettõl tekintsünk el – a vanillában nem hittem. Próbáltam cross-compiler toolchain-nel gyorsabb gépről – a végeredmény azonban heveny hajhulláshoz vezetett, mivel a gép nem rendelkezik semmiféle grafikus perifériával, így nem volt más segítségem, csak villódzó lámpácskák és speaker-es beepcode-ok :) Nem jutottam értékelhető eredményre, így kezdetét vette a kernel-lopkodási fázis. Ezzel már messzebb jutottam – találtam teljesebb featureset-tel fordított kerneltarball-t az internet csak kockáknak fenntartott bugyraiban (kösz’ davygravy), és ezzel már ment minden, de egy baja azért volt – még mindig nem volt Gentoo :) (azóta eltelt pár év; ami a telepítést illeti, létezik már natív u-bootable debian-installer ARM kernel is – nekem akkor a fapados metodika maradt, no meg a hackelés/reszelés…)
Aztán teltek, múltak a bitek, byte-ok, és a freenode IRC-hálózatán belebotlottam a fent nevezett fórum azóta jócskán kibővült jogutódja (NAS-Central) fejlesztői/karbantartói brigádjába, és a „velük lógó” néhány elvetemült hobbistába. Szó szót követett, és végül sikerült egy szájbarágós step-by-step módú segítséggel (kösz’, tarpman) felvakarnom egy ARM autobuildet a Lenny dd-s diskdump-ja után. Sosem került vissza, pedig volt, hogy majdnem… :)
Ugyanis ha már Gentoo, legyen ugye a bleeding edge a mottónk – ha már kernel, frissítsük az upstream-mel. Ez volt az a pont, amikor a maradék, eleddig nem kihullott hajam őszülésnek indult. A „vakság” teljes mértékig ellehetetlenítette ismét a munkát – akiknek a kerneljeit lopkodtam eddig, rendelkeztek saját készítésű garázs-tuning soros kábelekkel, amikhez forrasztottak a saját NAS-aikra csatlakozót – esetemben ez szóba sem jöhetett. Egyrészt nem értek hozzá, másrészt féltettem az eszközt – azonban sem kábelt készíteni, sem a forrasztást elvégezni nem volt hajlandó senki. Mindenesetre a félelem hatékony kihasználása életben tartotta mindaddig a dobozt, amíg egyszer túl bátornak nem bizonyultam – egy lelkes kernelcsere-kísérletet követően többet nem bootolt be az átok ette szerkezet. No, sebaj, gondoltam, és szétszedve, a lemezt kivéve és külső házba szerelve mount-oltam a /boot-ot egy másik gépen és visszamásoltam a működő, előzőleg elmentett kernelt – de hiába. Aztán egy lopottat – szintén. Megfeküdt.
Ekkor szembesültem az én gyönyörű rolling-release rendszerem másfél éves mivoltával. Amiről készült offline mentés ugyan, de downtime és fizikai hozzáférés, valamint ezek alternatívái hiányában a telepítést követően közvetlenül – épp’ másfél éve. Ez biz’ /dev/null. És megszületett az elhatározás: minden world- (vagy kernel-) update elõtt teljes rendszermentés. Na ja, de hogyan? A rendszer ugyanis időközben remote-tá vált, tehát nem csak hogy nem láttam belőle semmit, ha éppen nem indult el bármi okból, de már a szétszedése sem jelentett alternatívát…
II. In Medias Res
Halotti csend következett majd’ két hónapig, de aztán lehetőségem nyílt ismét a kezem közé kapni a dobozt, és úgy döntöttem, ennyi volt, tovább ez így nem mehet. A mentéshez downtime nem lesz, az online mentéshez kötetkezelés kell, ahhoz pedig arra épített rootfs, amihez új kernel, sőt, ez hagyján, de új initrd is. Ja, és konzol, mert ha nem tudom, mi nem jó, kijavítani sem tudom – ráadásul az sem lenne gond, ha úgy tudnék boot-környezetet választani, hogy ne kelljen szétszedni a vasat. Sőt… Ehhez tehát meg kellett ismerkednem ezen eszközök manapság legdivatosabb bootloader-ével: íme, Das U-Boot! Lássuk tehát, mire megyek immár egymagam…
– VIGYÁZAT: TÖMÉNY MŰSZAKI INFORMÁCIÓÁRADAT KÖVETKEZIK! –
0. Olvasgatás ismét, nem kevés. Aztán nekiálltam. Fogtam a Macbook-omat, és tekertem rá MacPorts-ból pár kelléket: egy netcat-et (nc), egy DHCP-servert (dhcpd) és egy TFTP-servert (tftpd-hpa). Letöltöttem egy foonas-em bootkörnyezetet(FooNAS) is „rescue-mode” gyanánt. Eztán egy patch-elt u-boot bináris image-et is.
1. Alapkiépítésben ugyanis úgy van a bootloader felkonfigurálva, hogy ha nem talál „bootolnivalót”, TFTP-vel próbálkozik tovább egy (majdnem) hardcoded IP-cím felé, (firm-) hardcoded filenevű image-eket keresve. Gyorsan csináltam egy könyvtárat, amibe beletettem a foonas-em image-ét és egy dummy initrd-t, mert arra bár semmi szükség nincs, de az alapkonfiguráció részét képzi a bootloader-ben, tehát az egy tétova lépést sem tesz nélküle. Bekábeleztem a Mac-et keresztbe a NAS-sal, és felkonfiguráltam a gépemet a szükséges statikus IP-re, hogy management-nodeként működjék. Elindítottam a TFTPd-t, rootként megadva az image-eket tartalmazó könyvtáramat. A system-logot tail -f-fel figyeltem, TFTP request-ekre utazva. A DHCP serveremnek írtam gyorsan egy alapkonfigot egy hálózattal/routerrel.
2. Bekapcsoltam az egységet. A bekapcsolást jelző „nóta” után nem sokkal felvillant a link LED – ekkor gyorsan elindítottam a media-érzékeny dhcpd-t is – és bizony meg is jelent mindkét RRQ a TFTPd felé a system-logban. Kisvártatva felhangzott a foonas-em füttyjele, jelezvén, hogy a rendszer üzemkész. (Kösz’ timtimred :)
3. A rendszert a foonas-em boot után telnet-tel lehet elérni. A bejelentkezést követően a foonas-em saját FTP-szolgáltatásán keresztül lementettem mindent, amire az előző rendszerbõl szükségem volt; leginkább a konfigurációs file-okra szorítkoztam (/etc/make.conf, /etc/portage/package.use, /etc/portage/package.keywords). Ezután nekiestem fdisk-kel az SSD-nek – ez nem tartozék, magam vásároltam bele még régebben – és legyalultam. Létrehoztam rajta két elsődleges partíciót: egy „Linux” típusú 50MB méretűt, és a maradék helyet a geometrián „Linux LVM„-ként. A második, nagyobb partícióra létrehoztam egy, annak teljes méretét felölelő pv-t, majd abba egy vg-t. Ezek után létrehoztam 4 lv-t: egyet a root filerendszernek, egyet a swapnek, egyet a home-nak és egyet dump-ként. Mivel az online átméretezhetőség választott nejgyilkos filerendszerem esetében (reiserfs) csak növelést tesz lehetővé – a csökkentés offline művelet, mount-olatlan állapotot kíván – igyekeztem megbecsülni a szükséges minimális területet, és mindössze annyit allokáltam – a maradékot „benne hagytam” a vg-ben. Így lett a swap a szokásos konvenció értelmében a fizikai memória kétszereseként 256MB, a root 2GB, a home 512MB és a dump pedig 3GB. A létrehozott lv-ket mkswap-pel és mkfs.reiserfs-sel, a boot partíciót pedig az u-boot kedvéért mkfs.ext3-mal vettem kezelésbe.
(Ő az ext2-t szereti, a journal-től eltekint, de nekem azért jó, ha az is van – szerencsére díjtalan kompromisszum.) Viszont itt megállok, mert volt még „egy kis dolgom”.
4. Tudtam, hogy mindenképpen szükségem van konzolra, és azt is, hogy jótét lelkek összekalapáltak a gyárilag flash-elt bootloaderbõl egy modernizált verziót, amelyet a netconsole patch-csel dúsított forrásból forgatva bináris tarball-ban tettek közzé. Sikeresen le is vadásztam, majd miután felFTP-ztem a foonas-em alá ideiglenesen, ott kitaroltam, és az online talált leírás szerint dd-vel be is flash-eltem a helyére. Persze a frász kitört, amikor a diff eltérést jelzett a bináris és a NAND tartalma között, de aztán kiderült, hogy ugye ez a patchelt bináris nem tölti ki a negyed megát… Ekkorra már amúgy is mindegy lett volna, szóval elsütöttem a reboot parancsot. Félve erősen.
5. A netcat viszont feléledt cserébe: a netconsole-nak hála megszűnt a „vakságom” – ellenben tíz másodperc múlva megsüketültem, amidőn is az u-boot ordítozva kérte ki magának azt, hogy nem tudja pingelni a bináris image-be alapban konfigurált IP-t, és nem stimmel a bootfile sem… Szerencsére a gép egyetlen gombjával elnémítható volt. Viszont merőben újszerű élmény volt tenylegesen beszélgetni az eszközzel POST után, boot előtt! Gyorsan az igényei után igazítottam a környezetet, és a tftp és bootm parancsok segítségével immáron megnyugodva indítottam vissza a foonas-em-et.
6. A vg-m aktiválása után a friss filerendszereimnek kinéztem egy könyvtárat, és azt / mountpointként kinevezve szisztematikusan aláhúztam mindent a helyére, és adtam egy swapon-t a megfelelő lv-nek. A date parancs persze nem volt hálás a szekrényben, áram nélkül töltött időért; hamar kiigazítottam, és a hwclock --systohc paranccsal be is karcoltam. Beállítottam default gateway-nek a laptopom, a resolv.conf nameserver klauzájába az OpenDNS ns1-ét, és hamar körbepingettem, kilátunk-e. Whee. „Internet Sharing” ist krieg. Gyönyörűen vitte az AirPort-ról az USB-s NIC-en át.
7. Leszedtem és kitaroltam a helyére egy ARM stage3 autobuild-et és egy portage snapshot-ot; nem mélyedek el a Gentoo-telepítésben túlzottan e ponton – akit érdekel, az már tudja, hogy’ kell, aki még nem, ebből tuti nem tanulná meg… Filerendszerek adottak, /proc és /dev bebind-olva a foonas-ból – nincs más hátra, mint a chroot, hogy belecsaphassunk végre a lecsóba – „beköltöztem” tehát a letöltött környezetbe. E ponton így egy majdnem teljes generikus userland állt a rendelkezésemre a foonas-em kernelével. Visszaállítottam a mentett make.conf-om és a portage konfigomat, beállítottam a dumpdir-eket make.conf-ban a kuka-lv fs-ére, majd tekertem elsőként egy ccache csomagot. Ha nem 128 megabyte fizikai memória állt volna csupán rendelkezésemre, azonnal csináltam volna egy tmpfs ramdisket is a gcc-nek, mert nagyságrendekkel gyorsítja meg a forráskódból telepítést – embedded felületen pedig a gyenge processzor miatt az idő pláne pénz… Innentől immáron ccache-be tekertem cron-t, logger-t, dhcp klienst, reiserfsprogs csomagot, és egy subversion-t. Utóbbival checkout-oltam a linkstationwiki sourceforge repo-jából az orion5x overlay-t, és odaadtam a portage-nek. Leszedtem egy friss fsarchiver-forrást is, mert a tarball tartalmaz egy Gentoo ebuild-et is, amit pár mozdulattal integráltam a már éppen kéznél lévő orion5x overlay-embe, és azzal az egy lendülettel fel is tettem. Ez lesz majd a biztonsági rendszermentések eszköze. (Remek dolog, a SysRescCD ismertette meg velem anno – azóta is töretlenül használom e célra, és bizony jött már jól, amikor egy gcc-upgrade utáni deep world update kevésbé lett sikeres… :) Forgattam mdadm-et és lvm2-t is. Itt kezd érdekessé válni: micro_evtd, gentoo-orion5x-sources – ezeken felül devio (és mkimage) kell még és u-boot-tools! (Mint egy rossz szakácskönyv…) A micro_evtd egy teljesen platform-specifikus program: a KuroBox Marvell Orion SoC-ja hardware watchdog-jával való kapcsolattartás és a hőmérséklet-szenzoros aktív hűtésért felelős elem vezérlése a feladata. Létfontosságú leendő rendszeremet tekintve – enélkül a beépített önszabályzó automatizmus nem hagyná élni a dobozt. A kernelforrás-csomag ebuild-je nagy segítség leginkább azért, mert az uImage formátumú target Makefile-ba foglalása mellett a kész bináris patkolását is elvégzi helyettem az architektúrára jellemző egyedi machtype-pal – ami nem csak kényelmes, biztonságosabb is, mintha kézzel csinálnám. A devio is egy ehhez használatos program, az u-boot-tools pedig – az immáron frissített, nemrég kézzel a megfelelő memóriaterületre flash-elt – bootloader-rel való „beszélgetés” eszköze. Elengedhetetlen lesz majd a sikeres – és kényelmes – rendszerindításhoz a későbbiekben. Végül forgattam egy screen csomagot, és megírtam az /etc/fstab-et az LVM layout szerint. Vixie-cron és syslog-ng default runlevelhez; net.eth0 és sshd szintén – utóbbi kritikus a rendszer elérése szempontjából, lévén annak gyakorlatilag egyetlen ésszerű módja. Kitöltöttem a conf.d alatt dhcp-re a kártyát, de beállítottam fallback-ként a statikus default IP-jét is, für alle Fälle. Ugyanott a keymaps és clock file-okat is kiígazítottam; az LVM (és mdadm) konfigurációját is – már amit kellett/lehetett belőle – file-ba írtam. Az inittab-ból a – gépre való tekintettel felesleges – tty-ket kikommenteztem. Az sshd_config-ban a PermitRootLogin direktívát yes-re módosítottam a kezdeti post-install életet megkönnyítendő, majd még melegében beállítottam egy root-jelszót passwd-vel. Az /etc/conf.d/local.start állományt kiegeszítettem két saját bejegyzéssel, melyből az első átállítja az SSD feletti I/O-ütemezőt – az amúgy állatjó – cfq-ról a seek latency híján megfelelőbb noop-ra; a másik egyszerűen a /tmp alá egy last_boot nevű file-ba írja a mindenkori pontos rendszeridőt.
Készen volt ezzel a userland, elvben készre is lettek konfigurálva a rendszerszolgáltatások benne, ellenben a lényeg hiányzott még: a kernel!
8. E ponton lehet búcsút inteni a Gentoo Handbook-nak, mivel a GRUB esélytelen ezen a platformon, akárcsak a genkernel… De szembetűnő az overlay-es kernelcsomag egy újabb előnye hamar a make orion5x_defconfig parancs kiadásakor – ezzel sem nekem kell megharcolni… Finomhangolni ugyanakkor viszont óhatatlanul muszáj lesz. A feladatot az LVM használata teszi érdekessé, mivel a root filerendszert elérhetővé kell tennem a kernel számára – ez adott esetben (ugye, ha nem csak egy lemeznek lenne hely a dobozban, megkívánná első körben a RAID tömb összeállítását és elindítását, majd jelenleg esetünkben is) megkívánja az ennek következtében már elérhető fizikai LVM kötet (pv) volume group-jainak (vg) aktiválását, hogy a filerendszereknek otthont adó logikai kötetek (lv-k) elérhetőek, és így mount-olhatóak legyenek. Ehhez azonban kelleni fog egy initrd image, mivel az ehhez egyébként szükséges dolgok alapesetben a root filerendszeren lelhetőek fel – és úgy a kígyó máris önnön farkába harapott volna.
Beállítottam tehát a .config-ban néhány apróbb változtatást, amit az elképzeléseim (és a kialakított és adott környezet, pl. ReiserFS és initramfs-támogatás, SoC-típus, valamint a netconsole igénye és az új udev deprecated-pseudofs iszonya) megkívántak, és a biztonság kedvéért ellenőriztem a kapott-öröklött beállításokat is. A végén kiadtam az általános célú make parancsot egy time parancs után fűzve, hogy mégis legyen valami fogalmam a manőver időigényéről – tettem azonban ravaszul mindezt egy frissen e célra nyitott screen session-ben, amelyről e ponton galádul detach-eltem, kikapcsoltam a MacBookot, és elvonultam aludni; pontosan tudván, hogy fél nap kellhet adott esetben a kernel elkészítéséhez. Másnap munka után örömmel konstatáltam a kernelfa eddigi sikeres lefordítását, és nyomban meg is fejeltem a dolgot egy make uImage-dzsel. Ez már „látványos”; a fentebb taglalt „patkolás” is megtörténik ilyenkor az u-boot-tal kompatibilis kernelbináris konverziója végén. A make modules_install által a helyére küldtem azt a pár modult is, ami a monolithoz tartozott még. Ekkor lett a dolog félkész, mivel ekkor még mindig nem volt megfelelő initrd-m, anélkül pedig ebből boot itt sosem lenne…
Rövid online kutakodás után fogtam tehát a stage3-mal szállított busybox-ot, és a „static” USE-flaggel újrafordítottam, ahogy egyébként az lvm és mdadm is beörökölte ugyanezt telepítéskor a package.use-ban megadottak szerint. (ugyanitt jegyzem meg, hogy néhány masked package-et engedélyeznem is kellett a package.keywords-szel)
Egy átmeneti könyvtárba összehordtam a szükséges (részben statikus) binárisokat, és a busybox-ra linkeltem, ahogy olvastam, majd létrehoztam egy init névre hallgató futtatható shellscriptet, mivel az initrd ezt hívja meg alapesetben – ez egyébként kernelparaméterezéssel boot-időben állítható lenne, de ettől eltekintettem. Ebbe a scriptbe kerül néhány vitális parancs: (mdadm --assemble, már amikor kell, és…) vgchange és switch_root – hogy példaként csak a legfontosabbakat említsem. Az alap initramfs-formátumnak megfelelően cpio-val a gzip-nek átadva legeneráltam egy initrd állományt, de még mindig nem végeztem – ezzel ugyanis még nem fog tudni a bootloaderem semmit kezdeni. Az mkimage segítségével állítottam elő ebből az u-boot formátumú initrd-met, majd a kernel mindkét file-ját az alapértelmezett uImage.buffalo és initrd.buffalo neveken letároltam a /boot alá szánt kis ext3 partíción. Első körben viszont a már megbízhatónak nevezhető TFTP-s metódussal terveztem kipróbálni, így a chroot-omból átFTP-ztem ugyanezeket, és lecseréltem a foonas-em kernelét és a dummy initrd-t a tftproot-ban az újakra, majd az exit, umount és sync sorozatot követően – ismét csőre töltött netcat-tel – kiadtam újfent a reboot parancsot.
9. Az u-boot promptjában a netconsole-on két ponton kézzel megszakítva az autoboot folyamatát az interaktív prompthoz jutottam. A tftp parancs kétszeri kiadásával átszedtem a kernelt, majd az initrd-t is gond nélkül a megfelelő címekre töltve. A setenv paranccsal megadtam a kernelnek átadásra kerülő bootargs stringet a netconsole és a root (LVM mapping szerinti) megfelelő paramétereivel, majd a bootm mögé ezúttal mindkét címet felsorolva ugrottam a betöltött kernel és initramfs címeire, átadva ezzel a vezérlést a „művemnek”. A bootloader ezzel el is végezte a feladatát – a kernel feléledéséig az így expirált „beépített” konzolom elnémult, de a kernelbe forgatott netconsole-t a bootargs-ben ugyanide lőttem be, így az átmeneti vakság pár másodpercig tartott csak – szépen sorakoztak a printk-kimenetek, majd nem sokkal később láthatóan stabillá vált a link LED fénye, és feléledt a 22/tcp port a fallback IP-n, mivel DHCP server-t nem indítottam neki még.
10. A sikeres teszt-indítást követően a helyére másoltam a foonas-em-ből kilopott konfigurációs állományt az /etc alá, hogy a fw_printenv és fw_setenv parancskészlet az u-boot-tools csomagból a megfelelő memóriaterületen matasson, mivel az alapertelmezett ertékek jelen esetben nem jó helyekre mutatnak. Ezek után lekértem vele a flash-elt binárissal érkezett környezetet, és pár apróság (ncip, serverip, nand_boot, bootdelay) mellett a lényegi részt: a bootcmd klauzát is átállítottam a lemezről indításra az ext2load beépített parancs használatával a tftp helyett, és a végére fűztem a biztonság kedvéért statikusan a bootargs az imént már bevált tartalmát. Egy végső lekérdezéssel ellenőriztem, minden a helyén van-e a firmware-be tolt paraméterlistában, majd az utolsó (sikeres) reboot következett, immáron a lokálisan letárolt image-ekből. Ezúttal a DHCP-s konfigurációt is kipróbáltam (indítottam egy dhcpd-t a MacBook-on), szintén hozta az elvárt szintet szépen. Ezzel elő is állt az alapfunkcionalitással bíró OS image prototípusom.
Konzol- és terminál-kimenet a teljes boot-folyamatról
III. Szorgalmi a házi után
A fentiek láttán valószínűleg nem vagyok egyedül azzal az igénnyel, hogy mindezt ne kelljen ismételnem a későbbiekben – a futó rendszer alól fsarchiver-rel készitettem LZMA algoritmussal külön mentéseket minden filerendszerről – a rootfs-ről természetesen egy előzetesen felcsapott LVM ideiglenes, a mentés után ki is kukázott „eldobható” snapshot-on át. Kedvenc checksummer tool-om (cfv) telepítése után generáltam ellenőrző-összegeket is a mentések mellé, és miután az egészet letároltam a /dump fs-en, levittem a rendszert, kikaptam az SSD-t a dobozból, belöktem egy külső dokkolóba – majd dd-vel egy blokkeszköz-szintű mentést is készítettem a komplett geometriáról failsafe disaster backup gyanánt; termeszetesen szintén egy checksum-file mellékelésevel.
IV. WTF
Alapvetően ilyen rendszereket én elég sok mindenre használtam már: munin-master webservereként, zenegépként, torrent-seedbox gyanánt és „homokozóként” egyaránt kiválóan szerepeltek… Egyszerre is ;) Működésüket alacsony fogyasztás és elhanyagolható zajszennyezés jellemzi, terhelhetőségük értő telepítés és belátó konfiguráció mellett egészen meglepő mértékű. Terveim között szerepel a jövőben a saját példányom digitális videorögzítőkénti beüzemelése, valamint a HG/WR modell u-boot-tal történő ellátása utáni PPC Gentoo-port telepítése – határt csak a fantázia szab, no meg a gyenge hardware-ellátottság ;) Az érdeklődők figyelmét valószínűleg lekötöttem idáig, a többiek pedig biztosan nem jutottak el ezen írás végéig, tehát nem köszönöm meg a figyelmeteket – megyek, tákolok valami mást; tegyetek Ti is így! ;)
