Nyár van és...

... szeretném ha az összes grub, kernelfejlesztő, open-source csomagkezelő, disztrófejlesztesztő terméketlen lenne, leprát, bubópestist, kolerát, ebolát kapna egyszerre, és kezelés gyanánt tüzes szívlapáttal csapkodnák őket mindaddig míg lélegeznek. Oh, és mellékesen, a hasonló sorsot élvező, "ötpercenként lekapcsoljuk a fél falut, hogy lophassuk az áramot nyaralókkal" kerüljenek egy szobába.
A dolog kezdődött, hogy barátosném megkért, legyek olyan kedves és digitalizáljak be egy szívéhez közel álló videoszalagot. Na most, az egyetlen ilyen célra alkalmas gépen ugye utoljára a telefon újraélesztése miatt XP-t telepítettem, ami ugyebár szétcseszte a boot szektort. Megpróbáltam egy grub2 újratelepítéssel megoldani, de a dolog borult, mivel a kernel elbaszócsoportnak büdös volt, hogy egyszerűen eszközként és partícióként hivatkozhassunk a root partícióra. Neeeem. Az túl egyszerű lenne. A grub teamről ne is beszéljünk, mert nekik egy komplett operációs rendszert kell tákolniuk, hogy egy 2MB-os kernelt betöltsenek és kicsomagoljanak. Bónuszkérdés, hogy miért kell 2012-ben egy merevlemezre telepített kernelt tömöríteni? Plusz egy hibalehetőségért?
Erre csak azt tudom mondani amit Ivan Ivanovics a szentpétervári bakter mondott, miután elvitte mindkét lábát a moszkvai gyors:
"HÁT A FASZOM NEM KÉNE?"
Az áramszünetekkel és fsckval fűszerezett, kernel pánikokat megunva, maradt tehát az újratelepítés.
Oh, igen, az rendkívül bájos, hogy a cutting-edge ext4-es filerendszer képes javíthatatlan filerendszerhibát kreálni úgy, hogy a gép üresen jár (értsd, nincs diszk forgalom), az egyetlen veszteség egy 300MB-os pdf, ami az elmúlt 3 hétben meg sem volt nyitva. Ízlelgessük egy kicsit. Egy üresjárásban álló gép filerendszerén megsérül/olvashatatlanná válik egy olyan file amivel utoljára hetekkel korábban volt bármiféle művelet végezve. Mi ez, ha nem egy rakás fos?
Visszatérve a telepítésre, 15 év Linux használat szopatás, megtanította, hogy semmi kényes adatokat nem tárolunk a gyökérpartíción. Fogtam tehát és DVD-re faragtam egy Debian telepítőt. Enter, enter, enter, aztán 3.5 óra töltögetés és telepítés. Alap desktop rendszer. 4 órával később, hibaüzenet. "Csókolom, hibára futottam, így jártál!", hibát megnézve mit látok? Ah, igen nem képes kicsomagolni a pythont mert elbasztak valamit a csomagban. Python egy asztali rendszerhez, minek? Legyen mi lassítsa a gépet, hátha túl gyors lenne? Vagy nehogy törést okozzon a tabok nélküli programozás Náncsi néninek?
Jó, ugorjunk... Mivel nem volt kedvem a dependency pokol összes bugyrát megjárni ezért magamhoz, akarom mondani Ubuntuhoz nyúltam. Ez ugye a Linux downkóros, celebgyereke. Lassú, csicsás, debil, de legalább seggfájás nélkül települ. Precíz Tobzoska lenyes, kipörköl, betesz telepít, az-az csak telepíteném, mert valahol az első harmadban helyrehozhatatlan hiba. WTF? Kiscsillió googlevel később, kiderül, hogy a hiba ismert. Vajon mi akasztja meg a telepítőt? Hát a slideshow! Igen. ez megint egy szignifikáns, helyrehozhatatlan hibát okozó komponensnek kell lennie.
Szerencsére, viszonylag egyszerűen orvosolható volt a dolog, és ezután csak egy "nem tudom megnyitni a filet" lehetett nézni, míg a telepítésjelző vonal futott. Jól jellemzi a szoftverminőséget...
Tanulság 10 óra telepítgetés és egy elbaszott vasárnap után? Az nincs, csak ilyenkor kicsit úgy érzem, hogy oka van amiért az open-source és a Linux olyan amilyen...

Hozzászólások

mindig jokat rohogok ezeken a postokon, hihetetlen, hogy mennyit tudod szivatni magad :-)

Taníts kérlek, mester. Osszd meg velünk bölcsességedet, hogy miképp lehetett volna elkerülni ezen szívást anélkül, hogy vasárnap reggel ne kelljen egy fullossan kiépített új PCt előretelepített Windowssal és szupporttal megvenni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ugyan megértem, átérzem (de mióta nem szopatom magam direkt, szerencsére halványul az emlék :) a frusztrációd a desktop linux ökoszisztéma evolúciós zsákutcába száguldása miatt de ha úgy látszik, hogy előre tudtad, hogy csak szívni fogsz, a fenti komment alapján ha hosszabb távon szükséged lenne windowsra, azt meg tudnád oldani, tehát csak idő szűkében voltál, és ha a cél hw elég erős videókonvertálásra és xp futtatásra, akkor valószínűleg win7-re is, akkor a helyedben én megfontoltam volna ezt:

http://technet.microsoft.com/en-us/evalcenter/cc442495.aspx

A tömörített kernelnek pedig addig van elméletileg értelme, míg a háttértár sebessége annyival elmarad a processzortól és a memóriától, hogy gyorsabb egy kisebb tömörített imaget kibontani majd betölteni, mint közvetlenül egy nagyobb tömörítetlent.

Szerk.: Live ID kell a letöltéshez, és ha az online form
"*What occupation best describes you?"-kérdésére nem IT Workert vagy kapcsolódót
választasz, akkor visszadob azzal, hogy a trial csak it professionaloknak van fenntartva.. :)

Tömörített kernelnek csak addig volt értelme, amíg a kernel csak így fért rá egy floppyra. Manapság mikor a floppy a legtöbb embernek történelem, a tömörített kernel karcolja a 4MB-ot, és az asztali gépek esetében gigabyteos háttértárak állnak rendelkezésre, picit programozói maszturbációnak tartom a tömörített kernelt.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Bocs, hogy belevau, de ha már Ubuntu, az alternate telepítő nem lett volna jobb?

=============================================================================
"Senkinek sem kötelessége, Hogy nagy ember legyen. Már az is nagyon szép,ha valaki ember tud lenni." (Albert Camus)

Attól, hogy ez az aktuális sztereotípia az Ubuntura, még nem feltétlenül egy lassú giccshalmaz. Ezt elsősorban a „szar a default, letörlöm”, illetve „nem tetszik a háttér, letörlöm” típusú emberek indították, akiknek megy Debianon az apt-get install/remove, de Ubuntu előtt hirtelen elfelejtik.

Hát én egyébként Debiant használok, amiből kiirtottam mindent, ami nem volt szükséges, de amikor Ubuntut tettem fel pár alkalommal magamnak vagy valakinek, az volt a benyomásom, hogy ubuntuban a dependency sokkal több csomagot megkövetel.
Úgy értem, hogy nem tudtam ugyanazokat a csomagokat eltávolítani, amiket Debianból, mert Ubuntuban valami alapcsomag fogta.

Az lehet. Lehet, hogy több helyet foglal, lehet, hogy több ikon van a menüben és lehet, hogy a régi 256 MB RAM-os Pentium 3-asomat jobban belassítja, ha egyszerre fut a Skype és a Firefox sok fülön. Oda lehet, hogy jobban tenném, ha Debian tennék, vagy kidobnám az egészet a fenébe. De egy nem ilyen bazi régi gépen azok a plusz csomagok és egy kicsit több lefoglalt erőforrás nem okoz problémát.

Ezzel nem ertek egyet, messze az Ubuntu telepitoknel lattam a legtobb marhasagot, volt olyan gep, amin a liveCD-n nem lehetett rakattintani az install gombra, azt mar tenyleg nem tudom, hogy csinalhattak. Esetleg meg a GRUB1-es disztrokkal szokott gond lenni, de ha csak a GRUB-bal/GRUB2-vel van para, akkor altalaban bootolok egy Archot, es azalol kezzel is helyre tudom mar hozni (mondjuk szomoru, hogy ez mar nalam amolyan "rutinfeladat"), GRUB2-nel meg is lepodtem, hogy nem hogy chroot, de meg mount se kellett az mkconfig-hoz

De a mainstream disztrok kozul amivel a legkevesebb baj volt, es ami tenyleg kivetel nelkul mindig felment nekem kattintgatassal gond nelkul, az a Linux Mint volt. Legutobbi szopas: openSuse logikai particiora, GRUB1 vegul csinalt 3 Windows entry-t a 3 NTFS meghajtonak, az openSuse bootolhatosagat meg kifelejtette.

LiveCD-ről nem tudok semmit mondani, sosem azt használtam telepítésre. Van egy rendes telepítője is, GUI nélkül, csak nem kell beírni, hogy /arch/setup :). Érdekes, hogy engem valahogy nem találnak meg ezek a telepítési problémák, a Grubbal sem volt sosem bajom. Viszont a feltelepült rendszerek többségén amit nagyon utálok, az az, hogy külön kell mindenféle repókra vadászni a neten vagy az olyan dolgokkal görcsölni, mint pl. az nvidia hivatalos drivere vagy wifi kártya driver, ami persze nincs rajta a telepítő CD-ken (Fedora, Suse, Mandriva, Debian). Archon és Ubuntun nincs ilyen őrület, beb*sszák az nvidia drivert, multimédia támogatást meg mindent és bemutatnak RMS-nek meg körberöhögik a Debian Free Software Policy-t.

na ezért van a közelembe (család/barátok) mindig egy tűrhetően működő wines gép:)

A cím alapján legalább valami miniszoknyás shot-ot vártam, de ez is elég fun volt LOL.

Azért ez a blog pár dologról azért meggyőzött:

1. Jó dolog az a LILO még 2012ben is. Házi használatra mindenképpen.
2. Inkább az ext3 még 2012ben is.
3. A python os ügy érdekes. Mikor frissítettem a lennyt nem futottam bele ilyesmibe ha jól rémlik.
4. azért jó, ha baj esetére továbbra is tartok egy knoppix live-dvd-t raktáron, azzal pl. egy LILO ba is gyorsan életet lehet köhögni.
Adott esetben megkímélhet akár 10 óra telepítéstől is, vagy ha sikerül elfelejteni bárhol a tulajnak a winxp bejelentkezési (admin) jelszót, stb.,
vagy ha egyszerűen hw hibát keresünk, mert egy kék/fekete képernyő bootoláskor nem túl informatív...

hon egy asztali rendszerhez, minek? Legyen mi lassítsa a gépet, hátha túl gyors lenne?

Jah, benne van a gimp,gnome függőségek között. Az meg gondolom az alap desktop profilban. (?)

Tanulság 10 óra telepítgetés és egy elbaszott vasárnap után? Az nincs, csak ilyenkor kicsit úgy érzem, hogy oka van amiért az open-source és a Linux olyan amilyen...

Ez így van.
Ha egy problémát, jelenséget, tulajdonságot, akármit
15 év alatt sem lehet megoldani, azt nem lehet megoldani és pont.
Ezzel vagy együtt élsz , vagy keresel mást.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Én kinn voltam a Bakonyban a hétvégén a span telkén. Magas, árnyas fák, csend, sör, whiskey, grill. Csumára ittam magam.

--
trey @ gépház

"mivel a kernel elbaszócsoportnak büdös volt, hogy egyszerűen eszközként és partícióként hivatkozhassunk a root partícióra."

Hogy? Mi van? Lemaradtam valamiről?

Annó, réges, régen az udev előtti időkben, mikor még a grub is karakteres volt, elég volt annyit megadni, hogy root=/dev/hda1 kernelparaméternek és lészön viágosság, futott a rendszer. Mostanában UUID és még kilenc másik voodoo megoldást kell végigzongorázni ami függ a csillagok állásától kezdve Linus zoknijának színéig mindentől.
A legszebb, hogy hiba esetén, nincs menekülőút, egyszerűen kernel pánikkal (VFS not syncing és tsai.)összehányja magát a rendszer. Ez meg mókás, lévén az initramfs-el egy kvázi rendszert húzunk a kernel alá.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Én elhiszem hogy az UUID nem ment neked valamiért, pedig azt elvileg "csak" meg kell határozni valahogy.

Én úgy képzelem ezt, hogy XP kitörli az MBR-t, utána live cd, chroot a partícióra, majd grub2-install és ennyi, mivel az UUID már ott van bekészítve a grub.conf-ba.

Azon felül grub command line-ban megnézheted a meghajtók grub számozását. Aztán ott a /dev/disk/by-uuid könyvtár, ott symlinkek az egyes megfelelő meghajtókra.

Amúgy nem lenne gáz ez az UUID csak tényleg több supportot építhettek volna a használatához.

+ megjegyzem nem kötelező a használata, megadhatod a hagyományos formában is hda ... sda ... sdz valami csak.

Egyáltalán nincs szüksége a grub2-nek UUID-re. Egyszerűen nyomogatni kell a tabot a kernel és az initrd megadásához, meg be kell írni a root=/dev/sdxx-et kernelparaméterként. 10 perc man. Ha meg nem fejlődne semmi, akkor az lenne a baj, hogy 2012-ben képtelen a linux blabla, blabla. PEBKAC...

Aham. Próbáld csak meg. 2.6.8-tól felfelé az eredmény a d20-al való dobással egyenértékű.
Nem a fejlődéssel van a probléma, hanem az idióta, szükségtelen túlbonyolítással. Áruld el, miért szükséges egy bootloadernek grafikusnak lennie? Miért szükséges modulokat töltögetnie? Miért szükséges egy kernel bootolásához önálló "ramdiskre"? De ha már csak az UUID-nél vagyunk, mennyiben javítja a rendszer hordozhatóságát, klónozhatóságát, milyen pozitív előnye van neki, és mivel javítja a kernel munkáját? Hmm?
Bizony, PEBKAC a fejlesztők részéről.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Áruld el, miért szükséges egy bootloadernek grafikusnak lennie?"

Hogy színesítse az életünket. :D

"Miért szükséges modulokat töltögetnie?"

Gondolom nem kell magyaráznom hogy a grub-nak sokféle körülmények között kell helyt állnia. Egy idő után már nem lehet mindent belesuvasztani egy bin-be, ezért találták ki a modularitást.

"Miért szükséges egy kernel bootolásához önálló "ramdiskre"?"

Ha itt a kernel modulokra akarsz célozni, akkor a fenti érvelésem a kernelre is vonatkozik. Nem akar mindenki custom kernelt faragni.

"De ha már csak az UUID-nél vagyunk, mennyiben javítja a rendszer hordozhatóságát, klónozhatóságát, milyen pozitív előnye van neki, és mivel javítja a kernel munkáját?"

Hát ez a legegyértelműbb nem? Kit érdekel hogy a kernel hogyan betűzi, számozza a meghajtókat, kénye kedve szerint, ha én egy adott partícióra akarok hivatkozni.

Nem. A modularitás jó, de nem jó ha kifogás a tákolásra. Csak számomra kontraproduktív, hogy a bootloader egy modult töltsön be a háttértárról, hogy utána a háttértárról betölthesse a kernelt?
Érdekes módon, más OS-ek kernelei képesek a modulok töltögetését, LVM, soft RAID és egyéb nyalánkságokat megoldani "pszeudó filerendszer" használata nélkül.
Ha adott meghajtó azonosításáról van szó, akkor ott a meghajtó szériaszáma, nem? A kernel pedig konzisztensen, interface alapján sorszámozza a meghajtókat. Oh, wait, hogy minden scsi emuláción keresztül megy? Cutting-edge...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Tehát akkor vegyük sorjában:
Az mbr loader betölti a grub-ot, a grub a konfig fájlt, a saját muduljait, a háttérképet, a kernelt, és néhány kernel modult, majd a kernel felmountolja a root meghajtót, és a többi modult is betölti. :)

Amit itt látunk az az hogy nincs integráció, hanem minden réteg igyekszik elhatárolódni a másik gyökérségeitől. A kernel fejlesztők egyik része, és a grub nem akar foglalkozni azzal hogy mit gányolnak a meghajtó számozásnál, ezért kitaláltak valamit amivel letudják a problémát. A GRUB fejlesztők szintén sem magukkal sem a kernellel nem akarnak integritásban lenni, függni egymás baromságaitól. Így szépen lassan létrejön ez a sokrétegű felépítmény.

Nekem pl. nem grafikus. Mert van aki használja őket, és nem fér el mind az MBR-ben. A sok-sok hardver és igény meg a flexibilitás miatt. Nagyban, én pl. gyakran használom. Ezek elég vicces kérdések, olyan elemeket reklamálsz meg, amit mások meg használnak, de neked nem kell, ezért hülyeség. Szerintem pl. a grub2 rohadt jó lett, a legjobb bootmanager. Na és akkor most mi lesz?

grub2 konfig része:

set root='hd0,msdos6'

Nem bonyolult. Első vinyó, 6. partíció (és jé, linuxúr /dev/sda6-nak látja).
Kernel betöltő rész:

linux   /boot/vmlinuz-linux root=/dev/sda6 ro init=/sbin/e4rat-preload ro elevator=deadline

És megy.

$ uname -r
3.4.4-2-ARCH

Ezekre gondoltál?

Megj.: az uuid-ot én se értem. Biztos nagyobb környezetben praktikusabb, de "otthoni" használatra a partíció-sorszámozás jobb (nekem legalábbis).

Fájlrendszer-gond esetleg? Márhogy a /dev/sdkutyafüleX olyan fájlrendszert tartalmaz, amihez szükséges dolgok csak modulban vannak. Teszem azt, xfs - kernel nem ismeri xfs-t, csak akkor, ha az xfs modul be van töltve. De az meg pont azon a partíción van, amit pont ez miatt nem tud csatolni (mint a "régi" esetem, mikor egy alaplap meghajtóit cdrom-on adják xp-hez - persze addig nem tudod a cdrom-ot kezelni, amíg nincs feltelepítve). Ezért lehet praktikus az initramfs, mert oda betolod az xfs-modult, onnan betölti, vígan felcsatolja a rút kiskacsát, oszt' indulhat a buli.

"Megj.: az uuid-ot én se értem. Biztos nagyobb környezetben praktikusabb, de "otthoni" használatra a partíció-sorszámozás jobb (nekem legalábbis)."

Egészen addig praktikus a /dev/sdx-es hivatkozás, amíg konzekvensen ugyanazt a meghajtót adja vissza.
Ám időnként olyan esettel is találkozik az ember, amikor ez nem teljesül - anélkül, hogy másik SATA portra kötném az eszközt.

Erre pl. nagyon jó az UUID vagy legalább Label szerint csatolni.

Az UUID jó dolog, én Lilo-t használok ezer éve (Slackware alap) és előfordult hogy kihúztam a Sata/USB SSD-met és átraktam külsőnek hogy az új meghajtó legyen az SDA fixen, ha nincs UUID akkor borul a behúzás is. Kézzel kellett kitalálnom, hogy a sok sdX közül éppen hova került az USB-s vinyóm. UUID-nél szépen elintézi magának egy gyors kereséssel és nem kell foglalkozni vele.


#boot = /dev/sda
boot = /dev/disk/by-id/ata-BUFFALO_SHD-NSUM64G_04050112009072800005
...
image = /boot/vmlinuz-huge-smp-3.4.3-pf-smp
  initrd = /boot/initrd.gz
  #root = /dev/sda1
  root = "UUID=632cfef5-1de7-4278-b4a2-cde1b6ed12ca"
  label = pfLinux34
  read-only

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Sokat nem kell jegyezni:


# lilo-uuid-diskid -h
Usage:
    lilo-uuid-diskid [-h] [-v] [lilo.conf]

# blkid 
/dev/sda1: UUID="632cfef5-1de7-4278-b4a2-cde1b6ed12ca" TYPE="ext4" LABEL="system" 
/dev/sda3: UUID="71aff3b5-7d36-4cf0-abdd-6568e55f6be2" TYPE="ext4" LABEL="home"

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Csak azért kérdeztem, mert ha nem, akkor egy automount felcsatolja neked rendesen az usb-s hdd-t, nem? Ezáltal felesleges az fstab és mindenféle szerkesztése. Nem az ókorban élünk már, van már automount a világon ;)
Viszont ha usb-s hdd-ről indulsz, és összevissza kapod az sda, sdb, stb. eszközöket, akkor igen, érdemes lehet az uuid alapján szerkeszteni az fstab-ot, hogy minden szükséges partíciót mindig fel tudjon csatolni (bár nekem a label alapján akkor is szimpatikusabb és könnyebben értelmezhetőbb, de ez ízlés dolga).

Ezért kérdeztem, illetve így jött ez ide.