Arch Linux hétfői frissítése

Linux

Tudom, szerda van, de csak most szántam rá magam, ezért most. Ahogy azt a disztibúció használói már biztosan észrevették, a hétfői frissítés átköltöztete (vagyis szerette volna) a /bin-t és az /sbin-t a /usr/bin-be, ami bizonyos esetekben ki is rugta a sámlit a rendszer alól, újraindításnál már csak a busybox fogadott (már ha volt) Aki ilyet nem tapasztalt, az ne is olvasson tovább. :)

A többieknek sajnos elő kell kapniuk egy telepítőt, és arról kell indítaniuk. Ha megkaptuk a root promptot, csatlakoztassuk a kidőlt rendszert, és úgy telepítsük a galibát okozó csomagot. Én paranoiás vagyok, ezért előbb lemásoltam amit piszkálna. Aztán megkérdeztem, hogy milyen csomagok vannak útban, és azokat kíméletlenül el is távolítottam, (csak 2 volt) majd frissítés után vissza. 


~# mount /dev/sdc1 /mnt
~# cd /mnt
~# mkdir sbin.bak && mkdir bin.bak
~# cp -R sbin/* sbin.bak/
~# cp -R bin/* bin.bak/
~# pacman --root /mnt -Qo /mnt/usr/sbin
~# pacman --root /mnt -Rd <a fent listázott csomagok>
~# pacman --root /mnt -S filesystem
~# reboot

Másodjára már sikerült is :) Igazából, ez most nem volt olyan vészes, mint az előző ilyen akciójuk, de egyel több ok hogy a főoldali híreket tegyük ki egy RSS-ablakba az asztalra/tálcára/akárhová.

( fdavid | 2013. 06. 05., sze – 13:10 )

Koszi a figyelmeztetest. Kicsit bosszantoak ezek a dolgok, a gentoo az ilyen atalakitasokat lenyegesen intelligensebben es elegansabban kezelte.

( uzsolt v | 2013. 06. 05., sze – 13:28 )

Illetve eggyel több ok, hogy gondolkodjak a váltáson (nagyon a freebsd izgatja a fantáziámat, sokkal stabilabbnak tűnik ebből a szempontból).

Ilyen "galibák" miatt csináltam egy saját, kb. 240 megás iso-fájlt, amelyet syslinux-szal be tudok boot-olni, saját wifi-kódok, beállított magyar kiosztás, fluxbox, opera a webböngészéshez, stb. Így nem kell a telepítőt megkeresni.

Nem tudom, de nekem nagyon úgy tűnik, hogy Arch-nál nincs egy rögzített irány, mindig valaki kitalál valamit, aztán megcsinálja. Valahogy ad-hoc jellegűnek kezd tűnni az egész. Ami a kisebbik gond, a nagyobbik pedig hogy különböző gondokat okoznak ezzel a váltással.

Csak egyet nem értek: általában a nem támogatott csomagok (aur) okozzák a galibát ilyenkor, ezt mindenki, még a fejlesztők is tudják. A kérdés: az aur-beli csomagok miért nem mennek a /usr/local-ba? Ezzel megszűnnének az ilyen gondok (meg biztos előjönne ezer másik).

Mert mondjuk jellemzően nem telepítesz AUR szerű forrásokból, mint ARCH-on, meg egy kicsit más az upgrade mechanizmus, mivel nem rolling release? :) Nem állítom persze, hogy nem lehetett volna itt is megcsinálni másként, de mondjuk core komponensek esetén a legtöbb user észre se vette a váltást, csak ha mondjuk community-ben volt valami nem felkészített csomag, vagy AUR-ból felpakolt stuff volt a rendszerén, mint nekem is. A symlinkeket meg természetesen megcsinálta, ezért is lehetett gond nélkül visszarakni a problémás csomagokat.

Az rpmfusion.org-ról telepítek, mert jogilag nyűgös dolgokra, mint például mp3 támogatás, video codec-ek, nyilván szükségem van. Ezen felül flash-plugin az Adobe-tól, VirtualBox az Oracle-től. Gond nem szokott lenni vele.

Igaz ugyan, hogy a Fedora nem rolling release, ugyanakkor lehet upgrade-elni a soron következő kiadásra, illetve a kiindulási alaphoz képest maximum két kiadással nagyobb verzióra. Ez könnyebbség a fejlesztőknek, mert a rendszer szintű átfaragást nem kell kezelnie a sima update-nek, elegendő azt upgrade alkalmával megoldani. Másfelől viszont ugyan nem az ajánlott metódus, mégis létezik yum upgrade vagy yum --releasever=19 distro-sync parancs, amelyek az upgrade-et sima frissítés keretén belül megoldják. Ezek használatánál persze adódhat némi kézimunka még, például ellenőrizni a csomagkészlet integritását, s effélék.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( batyu v | 2013. 06. 05., sze – 14:15 )

hogy okozhatott ez gondot? Nekem szólt, hogy a telepítés nem mehet le így, tehát ha valaki nem force-olta ész nélkül, elvben nem kellett volna a sámlit kirúgnia... Mindenesetre az RSS vagy hírek kipakolása nem oktondi dolog továbbra sem :)
Egyébként nem mélyedtem bele, de ez valami változás az FHS-ben, vagy eltérés attól, vagy eddig nem követte, vagy egyéb? Nem igazán látom értelmét, de mondjuk nekem pont mindegy jelen pillanatban :)

Igaz, rosszul fogalmaztam. Hétfő óta nekem is azt írta, hogy nem tud frissíteni, addig nem volt gond. De a hír végén ott van ez: 


# pacman -Syu --ignore filesystem,bash
# pacman -S bash
# pacman -Su

Na, ekkor búcsúztunk.

De ezt leszámítva mind a disztroval, mind a frissítésekkel teljesen elégedett vagyok. Volt vagy 10 éve Fedoram, de biztos rosszul fogtam, mert fél hónap után lelassult, szenvedett. Akkor tértem át ide, azóta semmi bajom. De ha valami történne, lehet én is rápróbálnék egy pcbsd-re, vagy újra megnézném a kalapost, gondolom csak jobb lett.

Hát skippelt néhány lépést, gondolom :) Bátor ember :)
Én még molyolok a cuccokon, amiken megakadt. Szégyellem, de nem értem, mit kell velük csinálnom :(
" Fix any non-official packages with files in /bin, /sbin or /usr/sbin to put those files in /usr/bin"
Oké, de how to fix? Which files to put in /usr/bin?
Ezt kaptam az első javasolt keresésre:

grub 0.97-21
gen-init-cpio 2.6.36-1
grub 0.97-21
sysvinit 2.88-9
initscripts 2012.10.1-1
tcp_wrappers 7.6-12

Segítene valaki? :/ Honnan tudom pontosan, mely fájlok tartoznak ezekhez?

Ezeket a csomagokat le kell szedni, csak ugy tudod frissiteni a rendszered. De nem art vigyazni, mert a Grub ugy latom nem mai gyerek! Eloszor a Grubot cserelnem le a grub-bios csomagra, utana mehetne a moka! :) https://wiki.archlinux.org/index.php/GRUB

szerk: fentiek AURban megtalalhato csomagok, es 1-2t leszamitva nem is kellenek. Ami meg kell, azt kesobb vissza lehet rakni.

--
http://www.flickr.com/photos/mizyhun/

Én kicsit lazábban csináltam: Az összes fájlt átdobtam a tesztek után a /usr/bin-be, aztán a nyomi könyvtárakat töröltem, frissítettem a filesystem csomagot, frissítettem a bash-t, utána ment minden gond nélkül. Elsőre nekem is kárált a /bin miatt, elolvastam a vonatkozó hírt, pontról pontra követtem, gond egy szál se...
--
Fight / For The Freedom / Fighting With Steel

Attól, hogy a grub.cfg úgy kezdődik, hogy ne szerkeszd, még nyugodtan szerkesztheted. Gyanítom, két ok miatt írják oda, hogy ne. Az egyik, hogy ha elszúrja az ember, nem fog boot-olni a gép. A másik, hogy ha az ember felülírja ezt a file-t, de alkalmazza konfig file-t generáló scripteket, akkor elvész a nagy műgonddal kreált alkotás, hiszen felülíródik.

Én viszont nem foglalkozom a konfig file-t generáló scriptekkel, hanem belenyúlok kézzel, s ezzel le van tudva a dolog.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egy pillanatig sem kételkedem tapasztalatában, rátermettségében. :) Különben annak idején én is idegenkedtem a Grub2-től, én sem szeretem a nagyon automatizált dolgokat, mert amíg működnek, addig jó, ám ha valami nyakatekert dologgal találkoznak, amire nincsenek felkészítve, több kárt okoznak, mint hasznot.

Ma már megszoktam a Grub2-t, szokott működni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most, hogy a "hétfői frissítés" miatt le kellett szednem a régi grubot, meghagytam egyelőre az újat, és maradhat is, amíg fel nem bosszant valamivel :)
Úgy látom, jobb lett ahhoz képest, amilyennek legutóbb megismertem. Mivel van egy entry, ami gyakran változik nálam, és az os-prober sokszor nem ismerte fel, amit fel kellett volna (és nekem egyelőre ez az egy kényelmi funkció az, ami előnyt jelentett nála a régivel szemben), egyszerűbbnek tűnt a régi grubbal ügyködni. Plusz inkonzisztensnek érzem, hogy - például - 'set root=hd0,msdos3'. Egyik nulláról indul, a másik egyről...

Na mindegy, most csak a systemd-sysvcompat hiányzott még, és tökéletes lett minden :) (nem kell már az init=/usr/lib/systemd/systemd append - ez a lépés valahogy elmaradt nálam az átálláskor).

Arch lelkét mélyebben nem ismerem, egyedül egy live Arch-ot szerettem, használtam, de amióta saját képemre és hasonlatosságomra csinálok magamnak Fedora live-ot, már nem hoz lázba a live Arch sem.

Mielőtt bárki egy flame indítását véli felfedezni mondandómban, semmi bajom az Arch-csal, sokkal inkább az a helyzet, hogy megszoktam a Fedorát, így nekem ez a kényelmes, hiszen akkor is életet lehelek bele, ha valamiért nem indulna, mert többé-kevésbé ismerem a logikáját, nyűgjeit, s így tovább. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

En is meg tudtam volna szokni a Fedorat, ha egy rogton egy olyan Gnome fallback session felutessel kezd, mint amivel az Ubuntu. De nem nagyon akart, pedig en elegge igyekeztem.

Az Archon pedig a MATE felprobalasa kisse vegyes erzelmek garmadajat inditotta el, ami nem lett volna problema, ha alapvetoen tobbsegben lettek volna a pozitivak. Hat, nem voltak. Sot. Mint utobb kiderult, sikerult valami alfa/beta/gamma verziot felrakni, de akkor mar megvolt az elso benyomasra torteno felig lesikalas.

(Azert kisse meg mindig kinos, hogy Ubuntu van a gepen, majd kitalalok valami ideologiat is moge :-) )
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Semmi. Azonban ha valaki nem ismeri a grub2-t, annak szivas lehet, ha hirtelen ott talalja magat egy nem-bootolhato rendszerrel akarmiert.

Ha van egy problema, akkor mindig az adott problemat oldom meg eloszor, illetve az esetleg kozben felmerulo egyeb problemakat, de nem kezdek bele alapveto dolgok frissitesebe, mert abbol mindig csak kavarodas van. Ha nekem lenne ilyen problemam, mint a topicnyitonak, eloszor a rendszert hoznam rendbe, es utana fontolnam meg a grub -> grub2 valtast, mert barmennyire is idoszeru, nem egy felig nem mukodo rendszeren kellene megejteni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

öö...valahol lemaradtam. Nekem nincs problémám a grub->grub2 váltással, mert grub2 van amióta SSD vásárlás miatt (ürügyén) újraraktam mindent, úgy fél éve talán. :)

És +1 annak, hogy előbb az aktuális problémát tudjuk le, ne kapjunk bele minden utunkba kerülőbe.

Mondjuk, arch alatt különösen igaz szerintem, hogy minél tovább halogatunk frissítéseket, annál több szívás fog következni, lásd initscripts->systemd, /bin áthelyezés, a most emlegetett grub, pacman verzió, stb. Jobb szeretek ezeken hamar túlesni, ha havonta egyszer frissítenék, biztos hogy kiharapnám a pókot a sarokból..

De kinek hogy.

Szerencsere a grub - grub2 valtas nem egy ilyen halalkomoly dolog. En majdnem mindenutt sima grubot hasznalok, es sosem volt bajom vele. Igaz nem bootol LVM-rol meg 1-estol eltero RAID-rol, de nekem oszinten szolva nem is hianyzik.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Pedig egyszerű:

1. Megnézed milyen csomagod van, ami nem standard repos:
#pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -

ezeket a legegyszerűbb ideiglenesen leszedni.

2. Megnézed van e más nem hivatalos repos csomagod. Ezt az /etc/pacman.conf-ban tudod megnézni. Ha csak a [core] [extra] [community] repokat használod és nincs saját sorod mint pl. [archlinuxfr] akkor nem kell semmit sem tenned.

#paclist [reponame] | awk ' { print $1 } ' | pacman -Ql - | grep ' /s\?bin/\| /usr/sbin/'

ezeket is a legegyszerűbb ideiglenesen leszedni.

3. Megnézed van e gazdátlan bináris az említett könyvtárakban, ha igen és nem te raktad oda (sicc!), akkor letörlöd, mert valószinűleg nincs ott semmi keresni valója.

#find /bin /sbin /usr/sbin -exec pacman -Qo -- {} + >/dev/null

4. Ezután lefuttadod a frissítést, több lépcsőben:
# pacman -Syu --ignore filesystem,bash
# pacman -S bash
# pacman -Su

5. Ha mindent jól csináltál, gond nélkül megcsinálja a symlinkeket (/bin /sbin /usr/sbin) és minden bináris az /usr/bin/-ben lesz.

6. Visszarakod az 1. és 2. pontban leszedett csomagokat.

( Replaced | 2013. 06. 05., sze – 14:57 )

/usr-t kellene pedig kiirtani

--
NetBSD - Simplicity is prerequisite for reliability

Ha erre gondolt, nincs igaza. Éppen azért került át Fedorán és ezek szerint Arch-on is, meg még ki tudja, hány disztribúción a /bin a /usr/bin-be, valamint a /sbin a /usr/sbin-be, hogy meg lehessen tenni azt, hogy a /usr egy önálló, read-only mountolt filerendszer legyen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Gondolom, az nem a legjobb ötlet, ha chmod -R +w /bin /sbin /lib /lib64 paranccsal indul a frissítés, majd ugyanez vissza, amikor elkészült. Vagy az immutable flag-et felrakjuk mindenhova, aztán néha leszedjük. Esetleg SELinuxos szabályokkal védjük az alkönyvtárakat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az elso foleg azert nem nyero otlet, mert annyit er, mint lejart mackosajtnak a brummogas. A csomagkezelok jellemzoen rootkent futnak, es a r/w jogok ignoralasra kerulnek, ha root vagy. Egyedul az x jog az, ami ilyenkor szamit, es az is csak a fajlokon. Ezek a fajlok meg jellemzoen amugy is root ownerrel vannak, 0644 vagy 0755-os joggal, tehat a root igy is, ugy is tudja oket irni, mas meg igy sem es ugy sem, max idohuzasnak jo ilyesmikre fanyalodni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Mármint úgy értem, hogy a /usr könyvtár szűnik meg.
Nem lennék meglepve, ha egyszer csak elmaradna a /usr könyvtár.
Ahogy írod, már Fedora esetében is a /bin és /sbin és a többiek is csak symlinkek. Egyszer valaki kitalálja, hogy akkor mégis miért kell /usr könyvtár (mint ahogy feljebb írták), és akkor a gyökérben lesznek a bin, lib*, share, include könyvtárak (remélem, nem hagytam ki semmit).
Ezért gondoltam, hogy errefele halad a dolog, azaz lassan-lassan a /usr már csak "történeti" okokból van.

És akkor, ha megszűnik, hogyan csinálsz ezekből read-only mountolt alkönyvtárakat? Mert valljuk be, az egyfelől helypazarlás, másfelől nehezen kezelhetően fragmentálttá teszi a rendszert - nem a file-okat -, ha külön filerendszer a /bin, egy másik a /lib, egy újabb filerendszer a /sbin, megint újabb a /lib64, aztán a /share, s így tovább. Arról nem is beszélve, hogy frissítéskor ezt a sok filerendszert kellene rw remount-olni, majd vissza ro, s a hibakezelés is sokkal problémásabb. Mi van, ha egyes filerendszerek remount-olása sikeres, míg másoké nem?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Magát a root-fájlrendszert is lehet read-only módon mountolni.

A többi csatolt könyvtár ettől független: 

# mountpoint /home/
/home/ is a mountpoint
# mount --options ro,remount /
# touch /home/x
# ls /home/x
/home/x

Innentől kezdődően gyakorlatilag ott vagyunk, mintha a /usr-t csatolgatnánk, amivel a /bin, /lib, stb. is ro-vá válik. És persze az előbb felvetett hibalehetőségek tárgytalanok :)

Ez igaz, viszont akkor az összes olyan alkönyvtárnak kell külön filerendszernek lennie, amelyek rw csatoltak. Van még egy lehetőség: belapátolunk minden rw alkönyvtárat egyetlen alkönyvtár alá csatolt rw filerendszerbe. Jé, éppen azt kaptuk eredményül, mint most a /usr-rel, csak kifordítva. Lenne egy /valami, s akkor az alatt lennének könyvtárak, például /valami/home, /valami/tmp, /valami/var, /valami/root.

Most akkor ez mennyivel volna jobb? Ugyanaz pepitában.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

De a /usr-es módban is. Ha a /home könyvtárat rw akarod, akkor azt mindkét esetben külön partícióra kell raknod, akár a /usr-t akarod ro módon, akár a /-t akarod ro módon.

Amit írtam példát, pont ezt szemlélteti:
- mutattam, hogy a /home nálam külön partíción van
- a /-t ro módon újracsatoltam
- létrehoztam _sikeresen_ a /home könyvtárban (ami rw-csatolt) egy x nevű fájlt

Ha gondolod, megcsinálhatom ugyanezt a külön partíción lévő /var könyvtárammal is, ha nem hiszed :)

Igazából, ha belegondolsz, a /usr-es megoldás a "neccesebb", ha már az ro/rw szempontot nézzük. Ui. kell egy root partíció (mondjuk sda1), illetve erre kell egy /usr partíció (mondjuk sda2).
Mi történik:
mount /dev/sda1 /
mount /dev/sda2 /usr <= amíg sda1 nem csatolt, addig a /usr könyvtár sem létezik csak úgy a levegőben!

A usr-nélküli verzióban csak egy root partíció kell, és csak egy 'mount /dev/sda1 /' parancs kell (persze nyilván szükséges paraméterezéssel, initrd, társai).

Ezek után felcsatolod a /home-ot, a /var-t, meg amit még akarsz.

Nem egyszerűbb és kevésbé bonyolult a usr-nélküli megoldás?

Ha gondolod, megcsinálhatom ugyanezt a külön partíción lévő /var könyvtárammal is, ha nem hiszed :)

Nem tudom, ezzel miért hozakodsz elő. Sehol sem állítottam, hogy ne lehetne egy ro filerendszer alkönyvtárához rw filerendszert csatolni. Lehet. Az a gyanúm, Te nem értetted meg, mit akartam mondani.

Ha a /home könyvtárat rw akarod, akkor azt mindkét esetben külön partícióra kell raknod

Már miért kellene? Ha rw a root fs, akkor a /home lehet csak az alkönyvtára, nem kell másik filerendszeren lennie. Az más kérdés, hogy erősen ajánlott önálló filerendszernek lennie annak érdekében, hogy az egész oprendszert újra lehessen telepíteni úgy, hogy a személyes adatoknak a haja szála sem görbül.

Én csak azt mondtam, hogy azért célszerű berakni minden telepített file-t a /usr alá, mert akkor ez lehet egy önálló, ro filerendszer is akár. Ha közvetlenül a root fs-en vannak ezek szétszórva, s azt szeretnénk, hogy ro legyen, akkor az a gond, hogy minden rw alkönyvtár vagy külön-külön filerendszer lesz, vagy be kell lapátolni minden rw alkönyvtárat egy filerendszerbe, ezt valahova csatolni, majd a /-ből symlinkelni az rw filerendszer megfelelő alkönyvtárát. Ez viszont éppen az, ami most van a /usr-rel, csak éppen fordítva, azaz az rw alkönyvtárak vannak egy alkönyvtár alá söpörve. Most meg a potenciálisan ro alkönyvtárak kerültek a /usr alá.

Szerintem nincs baj azzal, hogy a /usr alatt vannak ezek, mert aki igényli, megteheti, hogy ro mountol egy filerendszert alá. A kompatibilitás sem sérül, hiszen a symlinkek ezt megoldják.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sehol sem állítottam, hogy ne lehetne egy ro filerendszer alkönyvtárához rw filerendszert csatolni.
Valóban nem. Azért gondoltam, hogy így hiszed, mert magyarázat lehetett volna a usr-hez való ragaszkodáshoz. De akkor én hittem rosszul, hogy te hiszed rosszul :)

Én csak azt mondtam, hogy azért célszerű berakni minden telepített file-t a /usr alá, mert akkor ez lehet egy önálló, ro filerendszer is akár. Ha közvetlenül a root fs-en vannak ezek szétszórva, s azt szeretnénk, hogy ro legyen, akkor az a gond, hogy minden rw alkönyvtár vagy külön-külön filerendszer lesz
Milyen könyvtárakra gondolsz? A home-on és a var-on kívül más nemigen jut eszembe, amit érdemes/praktikus lehetne külön partícióra rakni az rw hozzáférés miatt. Ezt a kettőt meg úgyse rakod egy partícióra :)
De számoljunk:
- a te megoldásodban kell egy root-partíció (ami mondjuk legyen rw), valamint kell egy usr-partíció (ami ro/rw, ahogy a feladat követeli). Ez kettő partíció.
- az én megoldásomban kell egy root partíció (amin ro/rw lesz, ahogy a feladat kívánja), és lesz egy home-partíció. Ez is kettő.
Persze ha még esetleg a var-t is rw-re akarod, akkor azt is egy külön partícióra rakod, ezzel három. Viszont ennyi erővel azt is meg lehetne oldani, hogy a root-on a var egy szimlink, amit ügyesen "bedugsz" valahova (pl. /home/var :), ahogy írtad - ha a /bin lehet szimlink, akkor a /var miért ne lehetne - és "kifordítottunk").

Nyilván két különböző dolog, két különböző filozófia, szerintem mindkettőnek van/lehet realitása.

Szerintem nincs baj azzal, hogy a /usr alatt vannak ezek, mert aki igényli, megteheti, hogy ro mountol egy filerendszert alá. A kompatibilitás sem sérül, hiszen a symlinkek ezt megoldják.
Ezt meg én nem mondtam ;) De nem is gondolom, hogy ezzel baj van, csak azt mondtam, hogy kicsit arrafelé áll a szekér rúdja.

A /var irhatosaga nem opcionalis. Konkretan a mai szerverprogramok 99% szazaleka el sem indul, vagy nem mukodik megfeleloen, ha a /var nem irhato. A pidfajlok csak a jeghegy csucsa, a logolas a masik, de ezen felul van olyasmi, amit le sem lehet beszelni ertelmesen arrol, hogy a /var ala dolgozzon.

Ja, es aki a /home -t nem rakja kulon particiora egy olyan rendszenrel, ahol 1-nel tobb user van, az szimplan csak ostoba, jobb esetben meg onmaga ellensege. De igazad van, serul a gyoker, seruljenek hat a user adatok is. Who cares?

Amugy szerintem a legjobb megoldas kozepen van: a gyoker egy rw fajlrendszer (ez foleg a /etc miatt kenyelmes), a /usr kulon particio, ha kell ro, es ha kell, akkor a /var es a /home egy-egy LVM particio. Nem csak a readonly fajlrendszer vedhet meg, a jogosultsagokat sem kell lefitymalni, ha meg rootig verik a gepet, akkor meg annyira mindegy, hogy mi van readonly particion, egy mount -oremount,rw kiadasa nem hiszem, hogy egy komolyabb hacker tudasat meghaladna.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Miért is lenne jó, ha elmaradna az /usr könyvtár?

Nagy rendszernél még mindig lehet cél, hogy a root filerendszer minél kisebb legyen, és ez az oka az /usr könyvtár létezésének (külön mountolható). Tulajdonképpen a /bin és /sbin volt kényszer, mert az ebben lévő programokra akkor is szükség lehet, mielőtt még az /usr mountolva van. Ezt dobták el azzal, hogy úgyis mindenki valamiféle initrd-vel indít, és ott elférnek a szükséges cuccok. (személy szerint nem értek ezzel egyet, de ez más kérdés)

De az /usr meg fog maradni.

Sot, nagyobb rendszereknel a /usr lehet valami halozati fajlrendszeren is akar, es akkor minden oda dolgozik. A kernelben eleg alapszintu az NFS tamogatas, nem hiszem, hogy nagy kunszt lenne igy felepiteni mondjuk egy clustert.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

ertelmetlen kolonc a multbol

afaik az eredete az, hogy ket disk volt a pdp-ben, amin a unixot fejlesztgettek, egyik volt /-kent mountolva, a masik a homedireknek /usr (user) neven. egyszer betelt a / es onnantol a masikra kezdtek pakolaszni a dolgokat...

--
NetBSD - Simplicity is prerequisite for reliability

( Dolpa | 2013. 06. 05., sze – 15:47 )

Pedig kint volt a főoldalon hírként, meg az is, hogy kell kezelni. Én minden frissítés előtt megnézem a híreket, és ezt mindenkinek javaslom aki éles rendszert üzemeltet! A miért meg itt olvasható.

( Polesz v | 2013. 06. 05., sze – 18:15 )

Mi a búbánatos retkes istenért nem jó a /bin /sbin könyvtár?

A /media helyett /run meg a többi agymenés...

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

Nem fogadom el. Eddig szépen leszeparáltam a / /var /usr /tmp partíciókat és nem kellett variálni. Most jött /media /run /anyámtyúkja. Eddig is lehetett a fontosabb bináris read-only. Egyébként is a /bin /sbin a gép futtatásához elengedhetetlen cuccokat tartalmazta. Legalábbis eddig.

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

Ez eddig rendben, de gondolom, a read-only mount egyik célja éppen az, hogy ne tudja valami gonoszság felülírni a file-okat. Ugyanakkor megkérdezem, miért okoz Neked fájdalmat az, hogy a /usr/bin alatt van például a bash, ha van egy /bin -> /usr/bin symlink, s a #!/bin/bash kezdetű scriptjeid éppen ezért továbbra is futni fognak?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Eddig pont azért voltak dolgok a /bin-ben, mert ha netalán a /usr külön partíción van, akkor az ottani dolgok csak a helyi fájlrendszerek felcsatolásának pillanatától elérhetőek, és a bootfolyamat közben ezt megelőzően is szükség van bizonyos parancsokra, pl. a mount parancsra.

Igen, es ezert kellett volna elolvasni az ArchLinuxos indoklast: az initrd mar mountolja a /usr-t is a /-el egy idoben, ha szukseg van ra. Gondolom, hogy vagy van egy masolat az fstabrol az initrd-ben, vagy azt feltetelezi, hogy a /etc nem kulon particio. Mondjuk en remelem, hogy az utobbi, az initrd-be rejtett fstab-bal mar egyszer-ketszer megszivtam, nem is tudom melyik disztro, talan suse csinal ilyen hulyeseget. Koltoztetesnel vicces ilyen hibakra szaladni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Igen Archlinux alatt ez nagyon jól ki van találva. Az /etc/mkinitcpio.conf-ban szépen be lehet állítani, hogy mi legyen benne, és ezt minden kernel frissítésénél autómatikusan elkészíti, mármint a friss kernelhez kapcsolódó initrd-t. Nagyon bénának kell lenni ahhoz, hogy ezt elrontsuk.

( Dolpa | 2013. 06. 05., sze – 20:24 )

Az initrd szerinted mire való? Az összes normális disztrib azt használja, pont azért, hogy ha nem megy a mountolás, rossz a fstab, stb. akkor is legyen valami alap rendszered (pl. busybox). Teljesen jó az, hogy az összes bináris, lib, share, var stb. egy helyen legyen.