Új boot rendszer lesz a Debianban

 ( gee | 2009. szeptember 5., szombat - 15:38 )

Az utóbbi években a Debian boot rendszer minősége folyamatosan romlott, mivel a boot rendszer nem tartott lépést a Linux kernel változásaival. A Linux kernel egyre inkább eseményvezéreltté vált, számos feladatot a rendszer párhuzamosan hajt végre.
A Debian boot rendszerében több olyan feltételezés van, ami most már nem igaz. A jelenlegi boot folyamat során előfordul, hogy a /dev alól eszközök hiányoznak, miközben az fsck vagy a mount már használná ezeket, a hálózat nem érhető el NFS kötet mountolása közben, stb.

A megoldás az, hogy a Debian boot rendszere is eseményvezéreltté válik.

Ez az új boot rendszer a fenti problémák mellett a jelenlegi init.d alatti scriptek számos problémáját is orvosolja. Lehetnek valódi függések a boot szkriptek között, a végrehajtási sorrend nem találgatáson alapul (néha rosszul), hanem a függések alapján számolható. Ez a függőség alapú rendszer már most elérhető a Debian unstable rendszerben július 27 óta, és a squeeze kiadásban már így lesz a boot scriptek sorrendje meghatározva.

Az alapprobléma orvoslása azonban hosszabb ideig tart. A boot kezelés újraírása lesz ehhez szükséges, nem elég csupán a boot sorrend keretrendszert módosítani.

A terv részletei előtt egy kis háttérinformáció. A jelenlegi boot rendszer három részből áll:

  1. A /sbin/init implementációja, ami beolvassa a /etc/inittab fájlt és elindítja a második részt implementáló szkriptet (/etc/init.d/rc). Ez alapértelmezetten a sysvinit csomagban található, de alternatív megoldások is elérhetőek, mint az initng és az upstart.
  2. Az /etc/init.d/rc implementációja, ami felelős az init.d szkriptek korrekt sorrendben történő végrehajtásáért. Ezt alapértelmezetten a sysv-rc csomag végzi. Egy alternatíva a file-rc csomag, amely a /etc/runlevel.conf fájlt használja a /etc/rc?.d/ alatti szimbolikus linkek helyett annak eldöntésére, hogy mit hajtson végre és milyen sorrendben.
  3. Maguk az egyedi init.d szkriptek, amelyek a boot során végrehajtandó feladatokért felelnek. Az alapvető keretrendszer az initscripts csomagban található, és az egyes scripteket pedig a telepített csomagok biztosítják. Körülbelül 850 olyan csomag van jelenleg a Debian unstable disztribúcióban, amely saját init.d szkriptet telepít.

A 2. rész (sysv-rc) és a 3. megváltoztatása a függőség alapú boot sorrendre már megtörtént.
Ez a Lenny kiadás kiadási céljai között már szerepelt, és a további munka a Squeeze kiadási céljai közül az egyik.
Az init.d szkriptek függőség alapú sorrendbe állításával kapcsolatos átnézések már több, mint 3 éve zajlanak. Az új telepítések függőség alapú boot sorrendet fognak használni. Rendszer frissítések során egy kritikus szintű debconf kérdés lesz az átállás, aminek az alapértelmezett válasza az új rendszerre való migráció lesz, amennyiben a tesztelés során nem derül fény problémákra a jelenlegi szkriptekkel kapcsolatosan; ez esetben a korábbi boot sorrendet tartjuk meg.

Az alapvető probléma megoldásához a /sbin/init programot szükséges lecserélni egy olyan implementációval, ami képes a kernel eseményeket kezelni. Ez lehetővé teszi, hogy a boot rendszer úgy módosítsuk, hogy a boot korai fázisa eseményvezérelt legyen, a jelenlegi boothoz kapcsolódó dolgok megtartásával. Újraírhatnánk a sysvinitet, hogy eseményvezérelt legyen, vagy megnézhetnénk más boot rendszereket, amik már jelenleg is tudnak kernel eseményeket kezelni. A lehetőségek és más disztribúciók által használt megoldások áttekintése után az upstart rendszer tűnik a leg ígéretesebb választásnak. Jelenleg ezt használja az Ubuntu és a Fedora, és a problémákat visszafelé kompatibilis módon oldja meg.
A terv az, hogy megváltoztatjuk az upstartot, hogy használja a /etc/inittabot, hogy egyszerűbb legyen a váltás a sysvinit és az upstart között. Megváltoztatjuk az init.d szkript kezelést, hogy az upstart feladatokat is init.d szkriptekként kezelje, hogy olyan rendszerek számára is működöképes alternatívát biztosítsunk, amelyeken az upstart nem érhető el. Ezáltal a felhasználó számára transzparens lesz, hogy melyik csomag biztosítja a /sbin/init programot, és így egyszerűbb lesz a sysvinit upstart migráció.

Amikor a /sbin/init már eseményvezérelt keretrendszerré változott, a következő lépés a korai boot rendszer átítása oly módon, hogy használja ezeket az eseményeket, ha elérhetőek, és viselkedjék a tradícionális módon, ha nincsenek események. Amikor ez a végső lépés is megtörtént, az alapvető probléma akkor tekinthető majd megoldottnak, és a boot folyamat újra robosztus lesz még különleges esetekben is, lassú buszrendszerű eszközök esetében.

A tervezett ideje a /sbin/init lecserélésének az upstarttal a Squeeze kiadás, és megpróbáljuk a korai boot rendszert is eseményvezéreltté átírni még a Squeeze kiadásra, legalább annyira, hogy a jelenlegi legégetőbb boot problémákat (fsck és mount probléma USB lemezekkel) megoldja. Squeeze + 1-re a korai boot rendszer nagy részének átírása meg fog történni, még több jelenleg létező hibát kijavítva.

A Linux Software Base specifikációnak megfelelően, minden LSB követő disztribúciónak kezelnie kell a csomagok init.d szkriptjeit. Mivel a Debian továbbra is követni kívánja az LSB-t, ez azt jelenti, hogy a boot rendszer továbbra is kezelni fogja az init.d szkripteket. Ezért olyan boot rendszerre van szükségünk, ami a korai boot során eseményvezérelt, és ami az init.d szkripteket a megfelelő időpontban hajtja végre.

Referenciák:
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

Eredeti bejelentés elolvasható itt

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Köszi, hogy ezt így, részletekbe menően leírtad.. Jó volt egy ilyen cikket is olvasni :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én voltaképp csak lefordítottam... meg kihagytam 1-2 túl aprólékos részt

De egyébként szívesen.

Flame nélkül, de tényleg érdekel, hogy pl ez a megoldás mennyivel jobb/rosszabb mint az openrc?

> ez a megoldás mennyivel jobb/rosszabb mint az openrc?

Írj egy cikket róla. Addig nekem elég ennyi is:

OpenRC is a dependency based init system ...
Upstart is an event-based replacement for the /sbin/init daemon ...

Szerintem az eseményvezéreltség a jövőbe mutató.

tartok tőle megint én leszek itt a nagy negatív...
én jobb szeretnék egy működő, stabil, nem félbehagyott, nem okoskodó bootot a debianba.
és ez nekem azt jelenti, hogy kidobják azt a sok automatizmust, amit mostanában beleraktak, initrd, hal, udev, mittomén és visszatérnek a jó öreg sysv gyökerekhez.
A különbség a word köpködésem meg eközött, hogy wordöm nincs, a debiantól viszont a fizetésem függ.

Nem kell parázni, jó lesz ez :).

Annó udev, hal idején is mindenki köpködött, hogy jaj mi lesz most, aztán milyen jól megvan vele az emberek többsége.
Nekem a jelenlegi rendszer is teljesen megfelel, de tény a korral haladni kell, és ha van olyan ami megkímél a reszelésektől, akkor annak csak örülök.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Ha csak annyira lesz jó, mint az udev, akkor nem parázni kezdek el, hanem freebsd-t tesztelni ezerrel...
hogy van az embernek egy szabályosan telepített debianos szervere, ami 2.6.18-cal megy, 2.6.26-tal meg be sem bootol, az nekem freebsd-t jelent...

En eddig csak forditott helyzettel talalkoztam. 2.6.18-al nem tudott bebootolni a szerver (asszem valami dell r2900 talan, valami rackes borzalom), 2.6.24-el pedig sikerult (meg etch-csel kellett szorakozni). Udev-vel eddig nekem nem volt gondom, szemely szerint nagyon szeretem az egeszet.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

legutóbbi ígyjárásom: scsi diszkek, raid1 a root. aic modulnak van valami késleltetése, hogy a firmware nyugodtan inicializálhassa a kártyát és a diszkeket, utána kezd csak el rendesen működni. Bootkor initrd beránt, aic modul betölt majd azonnal nekilát összeszerelni a root raid1-et. De mivel az alant levő scsi még nem kész, ezért nem voltak meg az sda, sdb device nodeok, hála neked fostos udev, ezért nem is tudta összeszerelni, hanem szépen elszállt.

Nem mondom, hogy nem lehet megoldani háztáji hekkel is meg hivatalosan is, de az én értékrendem szerint ez már parasztos. NAGYON sokkal egyszerűbb lenne, ha a /dev-ben mindig pontosan az, sem több, sem kevesebb lenne, amit odaraktam, a modulokat nem ész nélkül rángatná be a gép, hanem azt töltené be, amit mondok (mert minek nyaral bent olyan modul, aminek a hardverét nem szoktam használni), és rendesen működne minden a raid kód környékén is, mert ami most van, az rémálom, raidhoz csak mérsékelten van köze.

Ez az egész initrd-s halos udeves marhaság tökteljesen felesleges, főleg egy szerver oprendszernél. Desktop oprendszerből meg van mivel dunát rekeszteni, tehát annak nulla értelmét látom, hogy a debian olyan területen nyomuljon, ahol van másik 340 versenytársa, közben azt a területet hanyagolja, ahol lehetne egyedüli király.

A freebsd ennyiben jobb, hogy ott pár keményfejű, hagyományokhoz ragaszkodó commiter a kiskezecskéjére üt mindenkinek, aki bohóckodásra meg @ növelésre akarja használni a cuccot, az sokkal jobban hasonlít a 10-12 évvel ezelőtti, működő linuxokra, unixokra.

Izé... azt hol olvastad, hogy bármit kidobnak, és visszatérnek a gyökerekhez?

Azt írják, hogy pl. hal és udev miatt problémák adódnak, pl. a boot folyamat már elér egy pontra, használná az eszközt, de udev/hal-ék még nem hozták létre a node-ot.

Erre lenne válasz az eseményvezéreltség: mondjuk a mount akkor hajtódjék végre, amikor megjelenik az az eszköz, amit mountolni kell.

Azt, hogy pár dolgot kidobnak, azt nem a bejelentésben olvastam, hanem az álmaim között szerepel.
Mert ami időnként előfordul egy tök szabályos upgrade közben, az horror. Ezért álmodozom arról, hogy kihajítják a retekbe az elektromos csellentyűcskéket meg a sok csicsapicsát és csinálnak végre egy működő, stabil rendszert, azaz visszatérnek a gyökerekhez.

Az LSB is követhetné az eseményeket, mert nem jó a haladás útjába állni. Az egész PC-s környezetet megmételyezi, ez a mindennek kompatibilisnek kell lennie a régivel kórság.

LSB alig kovetel meg valamit az initscriptekrol, legyen start,stop,restart .. es lehessen hasznalni benne par fugvenyt kb. enyit mond.
(Fuggoseg kezeles a gentooban jol megy mar vagy a kezdetektol.)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

jöhet a 10 sec-es boot-ra e-penis lengetés a debiannal is :)

nem hiszem hogy ez lenne a cel, de persze ezek a modositasok ezen a teruleten is javitananak a jelenlegi allapotokon.

Tyrael

Mivel a PC is lassan teljes értékű háztartási berendezésnek tekinthető, elvárható lenne az azonnali rendelkezésre állás.

Kölcsön adom 3 napra az x336-os pc-met, tedd az ágyad mellé, ahol alszol. Hidd el, kicsit másabb, mint az átlag háztartási eszköz.