sigellef blogja

Megosztom... lehet akár tesztelni is. Ha valaki úgy gondolja, kipróbálja, ide a blogra írhat kérdést, véleményt.

http://pvtv.hu/tarolo/out_files/fabatka/fabatka.iso

A képfájl kereken 64Mbyte.

Később le is írom, hogyan készült.

Megérte hosszú évekig tanulmányozni a Linuxot. Ma már eljutottam oda, hogy forrásból építettem egy működő rendszert. Komplettnek még nem komplett, de már működik. Gondoltam, csinálok egy boot dvd-t, amire felpakolok mindent, ami egy Linux rendszer ellenőrzéséhez, javításához kell. Amit összekovácsoltam:
kernel-3.10.9
glibc 2.18.0
util-linux, coreutils, e2fsprogs, dosfsprogs, ntfsprogs a legújabbak, net-tools, wireless-tools, mc, w3m + a hozzájuk való lib-ek... tar/gz/bz2/xz, zip, arj, rar... meg egy csomó egyéb apróság.
Mindent a ram-imagebe pakoltam, ne kelljen még külön image-eket behúzatni szerencsétlen kernellel. A ram image egyre inkább zavaróan nagy lett, már eleve a kernelmodulok, firmware-k 100M körül voltak... és csak egyre jobban dagadt.
Elérkeztem a 200M-hoz. Nahh, gondoltam, itt reménytelen dolog, hogy ez a cucc bebootol olyan gépen, amiben csak 256M RAM van.
Rájöttem, hogy milyen jó játék a squashfs... és milyen jó, hogy azt belefordítottam a kernel bzImage gyomrába, az összes fájlrendszerrel együtt.
Az RAMdisk image mérete lecsökkent 52Mbyte-ra. Örömmel tapasztaltam, hogy a memóriába betöltődvén sem tömörítődik ki, hanem az úgy ott van tömörítve.
A gond akkor jött, amikor mountoltam volna, aztán az mtab-ot nem tudja írni. Ezt is megoldottam. Az /etc, /var, /mnt, /tmp, /root, /home ment tmpfs-be, természetesen az /etc és a /var tartalmát másolgatással helyére téve.
Egyelőre ennyi... még nem 100%-os, de már ez is megvan, többféle gépen is kipróbáltam. Bebootol, aztán utána már a cd is kivehető... ott lakik a RAM-ban... mintha csak egy memtest volna... jahh, került rá egy memtest is.
Ebből csinálok majd egy installert is... vagy egy live Linuxot.

Már augusztus óta egy saját Linuxot tákolok. Csak úgy, saját célra, saját szájíz szerint összerakva. Haladok is vele szépen, csomagról-csomagra, már kompletten megvan a gtk-gnome ág, server programok, multimedia, grafikus progik... meg a milliónyi sok lib*... Épp most is eme félkészterméket használom. Sokat segített a függőségek keresésében az UHU-Linux forrásfájljai, leginkább a build-depends nevű aprócska szövegfájl, ami minden csomagforrás könyvtárába oda van biggyesztve.
Eddig 872 csomaggal játszottam végig a letölt-jól megvizslat-buildscriptetkészít-lefordít-tarxz-aztisjólmegvizslat-feltelepít játékot. Elérkeztem arra a pontra, hogy a sok modulfüggőséget jó volna valahogy grafikusan ábrázolni.
Adott a dologhoz: csonagnév-x.x.x-ub.tar.gz fájlok tömkelege, azokban pedig a build-depends fájl. Ez a fájl szépen, soronként tartalmaz egy csomagnevet, verziószám és minden nélkül. A verziószám egyelőre nem fontos. Nagyrészt megegyeznek az UHU-Linux 2.0-ban szereplőkkel.
A probléma: mivel rajzoljak graph-ot? Nyilván olyan szerkesztőprogram kellene, ami vektorgrafikus, tudja értelmezni az objektumok közti kapcsolatokat, és a fájlformátuma valami "human-readable" legyen.

Mostanában elég sűrűn eljátssza a Google, hogy a főoldalára a kereső fölé berak valami animációt. Eddig különösebben nem zavart annyira, 40-60%-ban terhelte le csak a procit. Ma viszont már olyan valamit tett be, hogy 100%-ra pörgette a procit, és még a kereső input-jába sem tudtam gépelni... illetve tudtam, csak 15 másodperc volt a leütött billentyű és az inputban történő megjelenése között eltelt idő.
Hát... új gépre nem futja, kezdőoldalnak jó lesz az about:blank, a firefoxon meg úgy is ott van egy google keresős input.
De valahogy bosszant, hogy mindent el kell rontani azokkal szar animációkkal, és még a letiltásukra sincs lehetőség.

Még 2005-ben történt, hogy sikerült kitörnöm a címben írt merevlemez IDE csatlakozójának egyik lábát... de úgy hogy még a NYÁK-ról is leszakadt. Betettem a szekrénybe, ha lesz időm/kedvem forraszgtatni, akkor majd nekiállok.
Tegnap kedvet kaptam hozzá. Csak egy régi szlovák pákám van, de aki akar, azzal is tud dolgozni. ( Na jó... 100 lábú smd-hez azért nem nyúlok, nem csak azzal, semmivel. ) Végül is kész lett 20 perc alatt, erre a műtétre várt 8 évet.
Rá is kötöttem a gépre, secondary masterként. A BIOS megismerte, de boot-oláskor gyanús kerregések jöttek belőle, ami IO hibáknál szokott lenni. Az is volt. A cfdisk /dev/hdc hatására csak kerregés jött, meg a kernel-debug telehányta a képernyőt üzenetekkel, hogy mely szektorokat nem tudta olvasni.
De particionáláskor miért akarja olvasni a 200., 300., 400. szektorokat? Ja mersze, multisector data transfer, meg LBA... reboot, kikapcsoltam a BIOS-ba, aztán újraindítás. Most nem kerregett. A cfdisk-kel is sikerült rajta partíciókat létrehozni.
Van egy hibás vinyóm, és örülök neki, legalább végre játszhatok a dd, dd_rescue nevű játékokkal, meg olyanokkal, amiket eddig nem mertem kipróbálni semmilyen merevlemezen.
Kezdjük: dd if=/dev/zero of=/dev/hdc: vajon meddig jut? Néhány tízezer szektor után kerregés. Nahh... itt hibás... de mi van a 200..400 szektorok környékén? Miért nent túl hiba nélkül mikor az előbb ott akadt el?
Akkor folytassuk: dd_rescue if=/dev/zero of=/dev/hdc: megy... 18.7 MByte/s... már a milliomodik szektor körül jár, és nincs kerregés. Majd lesz, ha visszaolvasom sima dd-vel
Nem lett... Mind a 20 millió szektort visszaolvasta, kerregés nélkül.
Próbaként rátoltam egy Linuxot, csak úgy swap nélkül, egy particióra. Futott, hibátlanul.
De hová lettek a hibás szektorok? Lemágneseződött volna a lemez, és az írás helyrehozta? Pedig szinte örültem, hogy van végre egy szektorhibás vinyóm...