systemd 211

Lennart Poettering oznámil vydání nové verze systemd. Nejviditelnější a nejdiskutovanější novinkou ve verzi 211 je podpora rozpoznávání diskových oddílů (Discoverable Partitions Specification), jež umožňuje, aby systemd při startu systému automaticky připojil root, swap, /srv a /home. Soubor /etc/fstab a parametr jádra root= se tak na "standardních" systémech stávají zbytečnými.

13.3.2014 04:54 | Ladislav Hagara | Nová verze

Komentáře

[Gilhad]

Další ukázka jak zbytečný bloatware je systemd.

[...]

"systemd" ako meno nevystihuje podstatu tohto komplexneho softweroveho balicku. Navrhujem sutaz o nove meno a prikladam par navrhov:

- kitchensinkd

- hugemessd

- lennartd

[Ivorne]

Jsem pro lennartd

[kolcon]

jsem pro lennartOS

[erino72]

To uz by nemalo daleko od retard :D

[pavlix]

To by byla ale chyba, on není pozadu, ale naopak těžce napřed.

[Michal Kubeček]

Kdo jde pořád dopředu, voctne se vzadu…

[pavlix]

Nostalgie. Úplně jsem na něj zapomněl.

[Petr Ježek]

Alespoň trochu věcné argumentace by příště neškodilo. Fstab je již dávno opuštěným sirotkem, kdy na něj nereagují jiná disková montovadla, jež je nutno konfigurovat jinak. lze říci, že kdyby fstab vyhovoval, nikdo nebude vyvíjet cokoli, co jej pro init a práce sdisky nepoužívá. Pokud se něco v systemd pokazí tak to lze velmi snadno analyzovat a stejně jako u jiných initů rychle opravit. Místo pindání bez arguentů by bylo záhodno Lennartovi buď vysvětlit, proč nepoužívat jeho systemd nebo mu naopak s ním vývojově pomáhat.

[ikar]

Pokud se něco v systemd pokazí tak to lze velmi snadno analyzovat a stejně jako u jiných initů rychle opravit

Mám bohužel opačné zkušenosti. Nedaří se většinout ani příjít na to, co je vlastně v systemd pokažené. Příčiny špatného chování systému v důsledku blbé funkce systemd jsou pro normálního smrtelníka neodhalitelné.

[pavlix]

To je pro systémový software typické.

[systemd]

Ano, bloatware... Child porn in systemd journal? Yes, we can.

[Michal Kubeček]

Hm… Takže když už se konečně podařilo dospět ke konsensu, že automatické rozpoznávání a aktivace MD zařízení není (až na výjimky) dobrý nápad, tak někdo stejnou myšlenku implementuje o úroveň výš. :-(

[Petr Ježek]

Automatické rozpoznávání je jedna věc a aktivace věc druhá. Aktivaci lze vždy binárně nastavit. Že to kdekdo netuší či neumí, je ovšem smutné. Ovce používají korýtko, bačové ho vymýšlejí a vyrábějí, vlci to monitorují a občas nějakou ovci sežerou...

[Pali]

Som zvedavy, co na toto budu hovorit admini o par rokov, ked tato vec prebuble to stabilnych distribucii, ktore pouzivaju na serveroch a nieco sa na tom pokazi...

[Petr Tomášek]

Mou nadějí je, že právě kvůli takovýmto excesům serverové distribuce systemd používat nebudou...

[trekker.dk]

Jo, tak třeba takový Debian, kde tahle sračka má být od příštího vydání výchozí init systém. (A moc bych se nedivil, kdyby od dalšího vydání jediný init systém.)

[Ondřej Profant]

Jedná se o funkcionalitu, ne? Čili to jde normálně vypnout, ne?

[Michal Kubeček]

Teď úplně vidím toho Svěráka s kosou, jak se uchechtává…

[kavol]

můžu poprosit o výklad? - nějak se nechytám

[trekker.dk]

"My nesmíme ani naznačovat."

Cimrman, hra (tuším) Vizionář.

[Heron]

Kua, byls rychlejší

[kavol]

ď. (oboum)

měl bych si to zopáknout ... zařazuju do fronty až po večerech dokoukáme MASH (jsme asi u osmého dílu )

[Heron]

My nesmíme ani naznačovat.

[ovoce]

Já tam slyším Smoljaka :) /my co jsme vyrostli na elpíčku/.

[OTC]

My, co jsme si stáhli jinou verzi MP3

[Václav "Darm" Novák]

Tak tohle už je trochu absurdní Jo, chápu stížnosti že by to teoreticky mohlo zkomplikovat detekci chyb při špatném fstab, kdy se do toho opře systemd a namountuje to podle svého, ale vzhledem k časté potřebě mít netradičně rozdělený a připojený disk je obava že by to v některé fázi vývoje přestalo používat fstab (resp. nějakou možnost statické konigurace) IMO celkem zbytečná.

[pavlix]

To je těmi špatnými zkušenostmi z dřívějška, viz přečíslování síťových rozhraní.

[Václav "Darm" Novák]

Ta změna na en<něco> a wl<něco>? Na desktopu to není poznat a na serverech si už delší dobou pojmenovávám interfacy přes udev sám kvůli přehlednosti, takže jsem to ani nepostřehl

[Petr Ježek]

A pak že je svět zlý :)

[pavlix]

Na desktopu to není poznat a na serverech

To jsou mi zase teorie, a co bys řekl o laptopu, na tom mém to zrovna poznat je ;).

[Michal Kubeček]

Na desktopu to není poznat

Co prosím?

[Šangala]

Na desktopech jsou některá písmenka méně zřetelná díky časté absenci ECC pamětí.

[pavlix]

Vidím, že už se diskuze zvrhává.

[Šangala]

V poslední době už jsem to udělal několikrát, měl bych se nad sebou zamyslet, ale na svou obranu: já si nezačal :).

[Václav HFechs Švirga]

+1

[Václav "Darm" Novák]

Myslím tím při normálním použití. Fakt si jiných názvů interfaců nevšimnu :)

[pavlix]

Myslím tím při normálním použití.

Odkaz na normu?

[Šangala]

Jestli ti přijde normální to znormovat, udělej to!

[Václav "Darm" Novák]

Jakou normu? Prostě tak jak používá desktop většina lidí. Síť nastavujou přes Networkmanager, wicd nebo jiného síťového démona. Pokud bych měl na desktopu víc než jednu síťovku a potřeboval si hrát s nastavením, platí stejný případ jako u serveru a nastavím si názvy přes udev ručně

[pavlix]

Jakou normu? Prostě tak jak používá desktop většina lidí.

Nějak mi není jasné, proč do technické diskuse pleteš většinu lidí.

Prostě tak jak používá desktop většina lidí. Síť nastavujou přes Networkmanager, wicd nebo jiného síťového démona.

Nesmysl. Když vynechám klíčový fakt, že většina lidí vůbec nemá na Linuxu založený desktop, stejně dojdeme k tomu, že většina lidí používá síť úplně stejně na Linuxu jako na Windows a jiných OS. Drátovou síť nastavují zapojením kabelu, bezdrátovou síť rozkliknutím ikonky, vybráním sítě a na požádání zadáním hesla.

Síťový démon je pro uživatele jen technický detail, který ho nezajímá, s výjimkou situace, kdy nastane problém a uživatel se sám pasuje na technika.

Pokud už chceš mluvit o normálním uživatelském použití, je potřeba to rozlišovat důsledně a nikoliv definovat normální ve smyslu takhle to dělám já. Pro každého je normální to, co za normální on přijal a žádná obecná norma neexistuje. Jediné, co lze považovat za normu je chování přímo vycházející z návrhu GUI třeba Gnome, nebo to, co je popsáno v dokumentaci té které distribuce.

Tvrzení, že na desktopu není změna jména poznat a na serveru ano, jaksi postrádá jako kontext, tak význam.

[FrostyX]

Lidi jsou tak nepoučitelní, ...

[kavol]

Mou nadějí je, že právě kvůli takovýmto excesům serverové distribuce systemd používat nebudou...

o Debianu již mluvil kolega ... a RHEL není serverovou distribucí? SLES taky ne?

[geri]

Clovek ktory sa hybe v tejto branzi 10+ rokov, riesi problemy intuitivne. Vela krat ani nepotrebuje vidiet obrazovku terminalu. Postaci popis situacie z telefonatu a zabehnuta hlava s predstavivostou najde niejake aspon zalozne riesenie. Pripadne si vykresli niekolko moznych scenarov. prakticky pocas jednej - dvoch generacii adminov je tu nemenny system startu, kde sa prejavi vacsina vaznych problemov. Bude trvat velmi dlho az tu budu taky experti na systemd (podstatne zloziejsi start system).

[pavlix]

Inzerát: Hledáme administrátora s pětiletou praxí spravování Debianu na systemd.

[Petr Ježek]

Člověk, který se pohybuje v braži deset let a z toho čtyři roky ignoruje vývoj a nasazování nového init systému, by u mne práci nenašel.

[pavlix]

Ono by mu to ovšem bylo jedno, protože na většině míst by se ho na čtyři roky vyvíjený init systém nikdo neptal.

[ikar]

by u mne práci nenašel.

To by pro něj bylo jen štěstí...

[j]

Ja myslim, ze by to samo melo proscanovat sit, pripojit vsechny ftp, nfs, samba ... co najde ... a pokud to nepude podobrym, tak vyuzit vsech znamych der a hacknout to.

BTW: Sem opravdu zvedav, japa si to poradi s 3ma / na jednom disku ...

[Václav "Darm" Novák]

Asi nijak a nastaví se to postaru.

[Václav Vanc]

Připojí je přece všechny přes sebe... :D

[...]

A zase sa vesele ide podla hesla: systemd vie najlepsie ako to ma fungovat, najlepsie automaticky bez moznosti to ovplyvnit nejakou zbytocnou konfiguraciou.

[ovoce]

Tak tak, přitom by se stačilo zeptat na ábíčku v diskusi, a hned by jim vysvětlili, jak to správně měli udělat.

[mica]

✅

[D.A.Tiger]

Soubor /etc/fstab a parametr jádra root= se tak na "standardních" systémech stávají zbytečnými.

Tim padem i knihovna mntend? Tak to je v haji - pouzivam ji v programech, ktere potrebuji mapovat diskove jednotky, kdyz selzou (nebo nejsou dostupne) jine moznosti. Spatne, dalsi rozhrani asi v haji.... :'-(

[Jakub Galgonek]

"Why are you taking my /etc/fstab away?"

"We are not. /etc/fstab always overrides automatic discovery."

[kavol]

zatím ...

[D.A.Tiger]

Presne, nebude trvat dlouho a nekdo zacne prudit, ze kdyz je to ( pro nej ) zbytecne, tak to v systemu byt nema.

[Peter Golis]

Let flame begin:

$ ls -l /etc/mtab
lrwxrwxrwx 1 root root 17 Aug 15  2013 /etc/mtab -> /proc/self/mounts
$

Predpokladám, že si už nikto nespomenie že /etc/mtab bol v dávnych dobách súborom priamo na disku. Všimol si niekto tej zmeny, a malo to nejaký dosah mimo znudených poznámok?

[kavol]

všiml bo jsme to testovali ... :-p

[random]

Mělo to zejména ten dopad, že od té doby můžeš mít /etc na read-only oddílu.

[Petr Ježek]

Vadí? Proč?

[random]

Nevadí, naopak to byla vítaná změna. Od určité doby šlo použít union mount, ale dělat to kvůli jednomu souboru je poměrně ošklivé.

[pavlix]

Všiml bo mi vždy /etc/mtab přišel ještě mnohem debilnější než /etc/resolv.conf.

[Honza Jaroš]

No já nevím, co dělám špatně (kromě toho, že nemám tu správnou distribuci)?

Na aktuálním Gentoo:

$ ls -lh /etc/mtab 
-rw-r--r-- 1 root root 2,0K 13. bře 10.05 /etc/mtab

Na CentOS 6:

# ls -lh /etc/mtab 
-rw-r--r-- 1 root root 533 13. bře 04.42 /etc/mtab

Debian Squeeze (novější Debian už mám jen v OpenVZ kontejnerech):

# ls -lh /etc/mtab 
-rw-r--r-- 1 root root 545 12. bře 10.22 /etc/mtab

[trekker.dk]

Všiml, protože od té doby df místo vypsání všech filesystémů vypíše všechny skutečné filesystémy a pak ještě všechny bind-mounty. Takže místo df musím volat df | less.

mount pro změnu u bind-mountů vypisuje místo "adresář odkud - adresář kam" kombinaci "blokové zařízení - adresář kam". Zbytečná informace, většinou hledám ten adresář, který už to neukazuje.

[biolog]

Nevšiml, protože používám cat /proc/mounts, protože /etc/mtab občas neobsahuje aktuální stav (např když řeším problém že FS je read-only) a už mockrát jsem se jím nechal napálit.

Vida, příjemná novinka.

[D.A.Tiger]

Nevsiml, protoze mntend to prekryje (takze aplikacim je to putna) a osobne jsem se jeste nesetkal se situaci, kdy bych musel do mtab lest rucne (/etc/fstab - to je jina)

[pavlix]

kdy bych musel do mtab lest rucne

Ručně mtab přepisuju při instalaci OS, kdy potřebuju aby si bootloader správně nadetekoval která cesta je na jakém zařízení. Na druhou stranu u GRUBu lze zapsat přímo device.map, a s přechodem na GRUB2 jsem měl pocit, že se detekce nějak zlepšila, pokud má někdo odkaz na popis toho, jak GRUB2 detekuje fyzické umístění boot partition, tak sem s ním.

[Conscript89]

Hm, ted jsem se na to dival a skoncil jsem na grub2-probe, coz je binarni soubor. Jinak mi to prislo pomerne stejny jako u grub1. Co se tyce ale stage2, tak tam uz se da hledat /boot podle UUID partition, popripade podle cesty k souboru.

[pavlix]

tak tam uz se da hledat /boot podle UUID partition

Taky jsem se tím zprvu nechal zmást, ale tady nejde o hledání podle UUID při bootu, to je samozřejmě dobrá věc. Ale ta autodetekce při instalaci grubu musí zvládnout opačný proces, tedy najít oddíl, na kterém ty soubory jsou, přečíst si jeho UUID a ideálně ještě zjistit, jaké všechny moduly GRUBu je potřeba načíst, aby se ten oddíl při bootu vůbec nadetekoval.

Hledání podle cesty k souboru je podle mě taková berlička spíš vhodná pro interaktivní mód, i když teoreticky by se tím dalo nahradit UUID ve výjimečných případech, kdy není podporováno.

[Conscript89]

Kod na moduly jsem v grub2-install videl, co se ale zapise od prvnich 443 bytu (stage1) jsem nezjistil. Vim ze grub1 mel problemy treba s resolvovanim multipath a podobnych silenosti, to uz ale v RHEL-5 i RHEL-6 funguje, ale tam to byl symlink hell a to co delal grub-install je na cteni pro silne povahy.

[j]

Trebas kdyz si chrootnes nebezici system, a chces mu dat info o primontovanych discich, tak to musis zapsat rucne.

[pavlix]

Využije se to jindy než při instalaci bootloaderu (viz výše)?

[R]

Do nebeziaceho systemu sa chrootuje velmi casto prave kvoli oprave bootloaderu.

[pavlix]

Tady zas někdo neumí číst.

[j]

Co kdyz je fstab nejak poskozenej? Ted system proste nenastartuje => jednoznacna indikace ze je tam nejaky problem ... se systemd to "nejak", 100% zcela blbe ... nastartuje, zkurvi data a vi buh co dalsiho ... uzasna budoucnost.

[Jakub Galgonek]

Díval ses, jak ta detekce funguje?

[chrono]

Čo keď bude poškodený nejaký súbor systemd?

[D.A.Tiger]

Budoucnost? O.o

[biolog]

No to je strašné. Kdežto SysV init by nabootoval v pořádku... aha, vlastně by taky nenabootoval. Takže asi podezříváte, že autodetekce nějak zkurví data, ale jak by se jí to mohlo povést? Namountováním na špatný adresář asi ne.

[pavlix]

Toho je schopná autodetekce RAIDu, možná si to někdo prostě v hlavě spojil.

[Michal Kubeček]

Třeba tím, že by se při bootu automaticky vypustil fsck na poškozený filesystém, který jsem měl v úmyslu nejdřív zazálohovat a pak ručně analyzovat. Situace ne nepodobná tomu, když automatická aktivace SW RAIDu způsobí, že se spustí resync na poli, u kterého jsem se tomu chtěl vyhnout.

[pavlix]

Situace ne nepodobná tomu, když automatická aktivace SW RAIDu způsobí, že se spustí resync na poli, u kterého jsem se tomu chtěl vyhnout.

Mě vždycky dost zajímalo, jaká komponenta přesně mohla za to, že se ten resync spustil dokonce po rebootu znovu ze špatného disku (na který nedoběhl resync) na dobrý disk, který jediný obsahoval správná data. Vždycky jsem si myslel, že součástí implementace RAIDu je právě podchycení podobných situací a zajištění dat i v případě, že je část disku nesynchronizovaných.

Přijde mi, že tohle snad ani nemůže být chyba systemd, pokud tedy ten resync přímo nevyvolá s volbou typu --force. RAID by měl přece obsahovat informace, zda je disk plně synchronizovaný a nechám přece rozběhnout zjevně rozbité pole, natož abych do něj dodatečně zařadil plně synchronizovaný disk a ten nechal v klidu zlikvidovat.

Modelová situace, která se stala na nějaké Fedoře nevím přesně kdy, probíhala tak, že po jednom startu synchronizace začala probíhat jedním směrem a nebyla dokončena kvůli restartu a po dalším startu se zjevně rozběhla opačným, alespoň tak to dotyčný tvrdil. Ten RAID si nastavoval sám, aby nepřišel o data při selhání disku, takže pokud ní konkrétní důvod, mám tendenci jeho analýze věřit.

[Šangala]

Furt mě neděste, nemám ze systemd žádné zkušenosti (a stávající stav mi vyhovuje), neustálý boj s NM zvedá už i tak pracnost o třetinu, když se do toho napakuje ještě další „já vím jak to chceš a ty mě do toho nemluv“, tak to za chvíli budeme nastavovat jak Widle i ze stejnou jistotou výsledku.

[pavlix]

neustálý boj s NM zvedá už i tak pracnost o třetinu

A bude hůř. Co zkouším aktuální stav v Gitu, tak se kolikrát nestačím divit.

[Šangala]

Potřeboval jsem něco pozitivního.

Mně hlavně vadí to, že musím zakazovat místo abych povoloval (u NM), ta koncepce je postavená na hlavu.

Ona spousta věcí je způsobená administrátorem (tedy mnou), ale tento přístup k věci fakt nepomáhá.

Poslední případ několik málo dní starý, minimální instalace CentOS, virtuální server k danému účelu, NM není instalován, konfigurace je nastavena staticky (pro jistotu i na DHCP). Je třeba doinstalovat X-ka/Desktop, protože je tam třeba spustit VNC-čko a klikací nástroje. Dohodím (abych to moc nekomplikoval, tak přes groupinstall - bohužel to obsahuje i NM, což jsem přehlídl, když jsem se díval co je součástí). Všechno v pohodě, ale najednou si říkám jaktože ten čas je 2sec mimo (synchronizuje se s hostitelem přes ntpd). Aha ono to nevidí ven, aha vidí, ale jen čísilkama, jakto že nefunguje DNS, co je v resolv.conf, do pr..le, jaktože vygeneroval NM. No a celé to bylo o tom, že interafce měl sice volbu nespravovat přes NM, ale místi no tam bylo n0 (vím proč, je to chybným mapováním přes seriovou konzoli - to je věc jiná), no a DNS to nemělo asi proto, že to má v interface cfg. má i volbu PEERDNS=no (nevím, jen úvaha, bylo mi to jedno proč to NM nezvládl a DHCP DNS korektně dává).

Možná je i je správně, že po instalaci desktopu nahodí NM, nicméně na CentoOS se snad všechno nainstaluje Off, tak by ani NM nemusel být default on. Ale hlavně rozhodně mělo být NM_CONTROLLED=no jako default, tedy má se povolovat ne zakazovat. Za chvilku budeme vymýšlet vnitřní „firewally“ proti nechtěným „chytrým“ službám, protože už se to nedá furt hlídat ;).

Na mém NTB proti NM ani popel, ale taky to není pravidlo.

[pavlix]

To už jsou takové detaily.

[Šangala]

Jsou, ale v těchto detailech se právě skrývá nejvíc provozních problémů.

[pavlix]

Máš pravdu mnohem víc, než si sám myslíš. Jestliže totiž ten software nebude v základu pořádně fungovat, tak s ním zdaleka tolik provozních problémů nebude.

[Šangala]

Snad jsem to pochopil ;).

[Migi]

ehm, to jako ze mi to z dual/triple bootu udela jedno velke "neco" ?

[slukas]

tak to sem zvedavej...pac budu mit taky na disku jedno velke "neco" ;)

[Jakub Galgonek]

Neudělá. Koukni se na tu Discoverable Partitions Specification.

[R]

Fakt super napad, to je na nobelovu cenu. Co to asi urobi, ked budem mat pri boote pripojeny druhy disk vybraty z nejakeho ineho PC?

[Jakub Galgonek]

To jsou zase nářky. V odkazovaném dokumentu se píše: "The first home partition on the disk the root partition is located on is automatically mounted to /home."

[kavol]

a pro nás pomalejší ... jak to přesně souvisí s tím, čeho se obává kolega?

[Jakub Galgonek]

No já to pochopil tak, že oddíl je mountován do /home jen pokud se nachází na stejném disku jako root oddíl (+ jsou tam další podmínky). Takže připojením druhého disku se mu nic nepokazí.

[kmarty]

Vynecham-il myslenky ohledne /home, postaci jen prosty koren v kombinaci s jednou "uzasnou" masinou co tu mam, kde se mi takrka pravidelne co start "prohazuji" naskenovane disky. Dnes to resim pres uuid.

Zkratka si myslim, ze prilisna inteligence sw vede k jeho debilite.

[kavol]

no, pokud bude mít "druhy disk vybraty z nejakeho ineho PC", tak není tak úplně nepravděpodobné, že na něm nebude jen /home ale i /, tudíž z "se nachází na stejném disku" asi tak úplně neplyne "se mu nic nepokazí" ...

[Jakub Galgonek]

Tak tím se myslí root oddíl, ze kterého to bootuje, takže pořád platí, co jsem psal.

[kavol]

Tak tím se myslí root oddíl, ze kterého to bootuje

eh? - bootuje to snad z /boot a ne z / (aspoň co se týče Fedory, vlajkové to lodi systemd ...)

[Jakub Galgonek]

A z čeho se asi pouští systemd?

[kavol]

slyšel už jsi někdy o initrd?

# lsinitrd /boot/initramfs-3.13.6-200.fc20.x86_64.img | grep usr/lib/systemd/systemd
lrwxrwxrwx   1 root     root           24 Mar 11 10:38 init -> /usr/lib/systemd/systemd
-rwxr-xr-x   1 root     root      1210216 Mar 11 10:38 usr/lib/systemd/systemd
-rwxr-xr-x   1 root     root        32296 Mar 11 10:38 usr/lib/systemd/systemd-cgroups-agent
-rwxr-xr-x   1 root     root        61408 Mar 11 10:38 usr/lib/systemd/systemd-cryptsetup
-rwxr-xr-x   1 root     root        49072 Mar 11 10:38 usr/lib/systemd/systemd-fsck
-rwxr-xr-x   1 root     root       220384 Mar 11 10:38 usr/lib/systemd/systemd-journald
-rwxr-xr-x   1 root     root        53688 Mar 11 10:38 usr/lib/systemd/systemd-modules-load
-rwxr-xr-x   1 root     root        28184 Mar 11 10:38 usr/lib/systemd/systemd-reply-password
-rwxr-xr-x   1 root     root        87008 Mar 11 10:38 usr/lib/systemd/systemd-shutdown
-rwxr-xr-x   1 root     root        49416 Mar 11 10:38 usr/lib/systemd/systemd-sysctl
-rwxr-xr-x   1 root     root       262072 Mar 11 10:38 usr/lib/systemd/systemd-udevd
-rwxr-xr-x   1 root     root        45048 Mar 11 10:38 usr/lib/systemd/systemd-vconsole-setup
lrwxrwxrwx   1 root     root           24 Mar 11 10:38 usr/sbin/init -> /usr/lib/systemd/systemd

[Jakub Galgonek]

Slyšel jsi o EFI ESP?

[kavol]

slyšel - například se o tom píše na odkazu ve zprávičce - ale nějak nerozumím, kam tím míříš?

[Jakub Galgonek]

An operating system should automatically discover and mount the first root partition (which does not have the no-auto flag set, see above), by looking on the disk the EFI ESP used to boot is located on. It should automatically discover and mount the first /home, /srv and swap partitions (which do not have the no-auto flag set, see above) by looking on the disk the root partition is located on. It should automatically discover and mount the /boot partition to the ESP used for booting. It should not discover/mount partitions with other GUID partition types, or partitions located on other disks, or partitions with the no-auto flag set (see above). User configuration shall always override automatic discovery and mounting. If a root, /home, /srv, /boot file system or swap partition is listed in /etc/fstab or with root= on the kernel command line it shall always take precedence over automatically discovered partitions. If a /home, /srv, /boot file system is found to be populated already the automatic discovery shall not overmount it with any discovered file system.

[kavol]

the disk the EFI ESP used to boot is located on

a když tam není, tak to dělá co? - možná mi to uniklo, ale nevšiml jsem si, že by ESP (nebo jakákoli jiná ze jmenovaných partition) byla povinná?

kromě toho, výše jsi napsal "root oddíl, ze kterého to bootuje", na což jsem reagoval, že z / Fedora nebootuje, a na tvůj doplňující pochybovačný dotaz doložil, že systemd je v initramfs (který je na /boot a ne / - pravda, vynechal jsem listing, že jde o dvě různé partition, ale to snad jasně plyne z kontextu), takže opravdu nechápu, proč se mě v tomto kontextu ptáš na ESP ...

[Jakub Galgonek]

Když tam není, tak neudělá asi nic - prostě nic neautodetekuje. Ta autodetekce také není povinná.

To s tím boot oddílem mi trochu "uklouzlo", já bootuju z root oddílu. Ale celá ta diskuze je o tom, že přidáním disku se to při popsaném návrhu prostě nerozbije. Anebo tebe napadá nějaký scénář, který nedomysleli?

[j]

A jak vis, ze kteryho oddilu chci nabootovat, a jak vis, ze chci prippjit /home z /dev/sda a ne z /dev/sdb ? Co kdyz z nejakyho duvodu /home na /sda pouzivam jako backup ... a ty mi ho zkurvis, protoze to pri startu pripojis jako provozni?

[Jakub Galgonek]

Pokud nějaký oddíl používáš jen jako backup pro home, tak mu nenastavuj GUID pro home a máš to.

[Gilhad]

na jednom pocitaci mam asi tri / partitions a asi 5 /home partitions, nemam zajem, aby mi z toho neco nejak losovalo, co to dnes pripoji kam, zvlast, kdyz obcas ty partisny mazu, predelavam, pridavam ...

[Jakub Galgonek]

Přečetl sis, jakým způsobem ta autodetekce funguje? Nic o losování tam není.

[pavlix]

Jak že se přesně vybírá root filesystém pokud jich je přítomno několik třeba i napříč více disky?

[Jakub Galgonek]

The Discoverable Partitions Specification: Suggested Mode of Operation

[pavlix]

Dobře, v případě EFI bootu zná kernel bootovací disk a drží se ho. Co to ale konkrétně znamená v případě bootování jiným bootloaderem než přímo z EFI, tedy když kernel nemá k dispozici informaci o bootovacím disku? Kernel panic?

[Jakub Galgonek]

V takovém případě bys asi měl použít parametr root= (a fstab).

Note that automatic discovery of the root or ESP partition only works if the boot loader communicates this information to the OS, by implementing the Boot Loader Interface.

[pavlix]

To není odpověď na otázku.

[Jakub Galgonek]

To, že v takovém případě automaticky nedetekuje nic, není odpovědí na otázku?

[pavlix]

To už ano.

[j]

Boze ... miluju obhajovace jako ses ty ... ktery vedi kulovy o tom jak kdo co pouziva, ale tvrdej, ze zadnej problem nikde neni...

Ses vazne tak blbej, ze nechapes takovou trivialni vec, ze kdyz udelas img oddilu, ze ten img bude (jake prekvapeni) uplne stejny? Vcetne vsech priznaku? Protoze to se jaksi u zalohy predpoklada?

[Jakub Galgonek]

A on je snad partition type GUID uložen na tom oddílu? Není, takže ta img, jaké překvapení, nebude jako home detekována.

[pavlix]

Kluci vy mě bavíte. Jakub, ač trochu zvláštním způsobem, prezentuje fakta a i tentokrát se jich drží. Má pravdu, že k žádnému losování nedochází, na druhou stranu zcela ignoruje to, technika, o které se tu mluví není funkční řešení, které by mělo problém s ojedinělými corner cases, ale obecně nefunkční řešení, které v ojedinělém corner case funguje.

Zda se takový corner case postupem času stane majoritním stavem nebo ne, mi nepřipadá až tak důležité, protože tahle vlastnost ani administrátorovi ani uživatelům nepřináší žádnou zásadní výhodu, je to jenom taková hezká hračička, kterou se dá pochlubit před veřejností a ukázat tak, že se něco dělá.

Útočný komentář j tady vyšel jaksi naprázdno, vzhledem k tomu, že klasický image GPT oddílu opravdu neobsahuje metadata oddílu, ledaže by měl namysli nějaký speciální nástroj, který ta metadata vyčte a k tomu oddílu je přidá.

[Jakub Galgonek]

Netvrdím, že ta autodetekce je něco super, na co jsme všichni čekali. Ale nadzvedlo mne, jak tu většina nadávala, jak je to řešení špatné, ale už se neobtěžovali kouknout, jak vůbec funguje.

Výhoda té autodetekce mne osobně napadá jen jedna. Pokud do nějakého počítače strčím disk, tak z něj prostě nabootuju a ty základní oddíly se mi správně namountují, i kdybych tam už měl jiný disk s úplně stejným obrazem.

[Conscript89]

Takze vyhoda je, kdyz ma clovek 2 disky, ktery maji FS se stejnyma UUID a ono to vybere ten disk, ze kteryho se bootovalo? Jinak to uz resit fstab s UUID=... a root=UUID=...
Pokud stroj obsahuje 2 disky i se stejnyma GPT/MBR a neni to raid, tak mi to prijde jako naprosta silenost.

[pavlix]

Takze vyhoda je, kdyz ma clovek 2 disky, ktery maji FS se stejnyma UUID a ono to vybere ten disk, ze kteryho se bootovalo?

Tedy naprosto nulová souvislost s bootováním podle typu.

Pokud stroj obsahuje 2 disky i se stejnyma GPT/MBR a neni to raid, tak mi to prijde jako naprosta silenost.

Stačí připojit přes USB disk, který představuje 1:1 kopii.

[pavlix]

Netvrdím, že ta autodetekce je něco super, na co jsme všichni čekali. Ale nadzvedlo mne, jak tu většina nadávala, jak je to řešení špatné, ale už se neobtěžovali kouknout, jak vůbec funguje.

S tím se zkus smířit. Každá ohlášená změna systemd představuje potenciální problém. Ono to platí o software obecně, ale systemd má dlouhou historii toho, že je to správcům natolik jedno, že se ani nesnaží těm problémům předcházet.

Výhoda té autodetekce mne osobně napadá jen jedna. Pokud do nějakého počítače strčím disk, tak z něj prostě nabootuju a ty základní oddíly se mi správně namountují, i kdybych tam už měl jiný disk s úplně stejným obrazem.

1) To nemá s autodetekcí podle typu vůbec nic společného, na to stačí vždy preferovat disk, ze kterého se bootuje a pak lze bootovat podle UUID stejně jako doposud.

2) Jak s autodetekcí tak bez autodetekce to závisí na tom, že kernel dostane informaci z kterého disku byl nabootován.

Takže zde se obávám, že jsi úplně mimo. Jestliže je tedy tvá domnělá hlavní výhoda bootování podle typu vyvrácena, zajímá mě, s jakým nadšením o tom budeš psát teď ;).

[Jakub Galgonek]

Můžeš ty dva body trochu rozvést? Nejsem si jist, zda jsem tě správně pochopil.

Předpokládejme, že kernel dostane informaci, odkud byl nabootován (bez toho nemá smysl mluvit o autodetekci). Pak si připojí root, home a další, z toho disku, z kterého bootoval. Tedy i když budu mít v PC dva disky s naprosto stejným obsahem, tak se mi připojí správné oddíly z toho spávného disku. Anebo jsi chtěl jen říct, že tohle může init řešit už nyní jen pomocí UUID (a znalosti boot disku)?

Jak se vlastně chová mountování podle UUID, pokud mám v PC dva oddíly se stejným UUID?

[Conscript89]

Spatne pokud to neni RAID, on pozadavek na FS je, aby mel unikatni UUID (ostatne UUID to ma uz v nazvu). Jak rikam, pokud nejde o RAID-1, je takova situace proste spatna a nemela by se stat.
Mas pravdu, ze pokud zna device (coz v UEFI podle vseho jde), tak muze pro mount pouzit oddily z bootovaciho disku. Nevim ovsem jak chces v ten moment premluvit grub, aby nacetl kernel a ramdisk z toho spravneho zarizeni, nemluve o nasledne bezicim systemu, ktery z toho muze byt pekne v haji.

[Conscript89]

Resp. aplikace, ktere nejak pracuji s oddily v takto bezicim systemu.

[Jakub Galgonek]

V UEFI by měl jít vybrat kernel k bootování přímo (tedy žádný grub). Ale do toho moc nevidím, můj notebook má podporu UEFI nějakou divnou, takže jsem se o to nikdy moc nezajímal.

[pavlix]

Ono by bohatě stačilo nebýt z UEFI tak posraný. Tak si Intel taky napsal bootloader, ale to neznamená, že se obrátila země naruby.

[Conscript89]

Hehe, jak se to vezme, primy bootovani kernelu je realizovany tim, ze kernel je sam bootloaderem (efi aplikaci) :) Intel udelal akorat takovy "efi DOS".

[pavlix]

To si nemyslím, že je správný pohled. Kernel jako celek nemůže být ani při nejlepší vůli považován za bootloader, vzhledem k tomu, že je to stále běžící jádro operačního systému. Naopak už to, že ho označuješ za EFI aplikaci naznačuje, že EFI umí spustit linuxový operační systém a tedy funguje jako tradiční bootloader.

[Conscript89]

No, to neni uplne pravda, pod pojmem efi aplikace jsem mel neco jako toto: PE32+ executable (EFI application). Do vmlinuz je potreba pridat kratky kod, ktery nacte ramdisk a samotny kernel spusti. vmlinuz je tak i sam sebou bootloader. Tudle techniku tusim pouziva gummiboot ze jen spusti aplikaci vmlinuz s nejakyma argumentama cimz preda kernel command line a umisteni ramdisku. Kdyz ma clovek takhle upraveny jadro, tak ho muze "spustit" z EFI shellu, nebo na nej muze udelat zaznam v NVRAM. Z pohledu UEFI je to tak, ze (az na par drobnosti) se nerozlisuje mezi EFI aplikaci jako je treba shell a bootloaderem.

[pavlix]

No, to neni uplne pravda, pod pojmem efi aplikace jsem mel neco jako toto: PE32+ executable (EFI application).

Tady jsi mimo kontext, já jsem o technické specifikaci EFI aplikace vůbec nemluvil.

Do vmlinuz je potreba pridat kratky kod, ktery nacte ramdisk a samotny kernel spusti.

Což je v přímém rozporu s ekvivalencí mezi kernelem a bootloaderem. Já od začátku chápu, co chceš říct, ale říkáš to špatně. Linuxový kernel není bootloader. Jestli jeho část přebírá funkci bootloaderu na tom nic nemění, už jen proto, že bootloader sám o sobě není cílový software, ale jeho jediným smyslem je zahájit spouštění operačního systému a případně umožnit uživateli do toho spouštění nějak zasáhnout.

Z pohledu UEFI je to tak, ze (az na par drobnosti) se nerozlisuje mezi EFI aplikaci jako je treba shell a bootloaderem.

Připadá mi více než zřejmě, že pohled UEFI nemá na úlohu linuxového jádra pražádný vliv. Je sice hezké, že UEFI se chová k jádru stejně jako k bootloaderům, ale ono se stejně chová ke všemu včetně samostatně běžících aplikací. Nic z toho neznamená, že bootloader, kernel a standalone aplikace jsou to samé, stejně jako čtyři nohy neznamenají, že kočka je kráva.

[Conscript89]

Mas recht, nemel jsem rikat kernel, ale vmlinuz, ten muze totiz byt i bootloader, kernel sam takovou funkci neplni (teda neni pro to delany).

[pavlix]

Vzhledem k tomu, že vmlinuz je jen komprimovaný image jádra, to je v podstatě pořád to samé. Docela by mě zajímalo, jak definuješ bootloader, aby tě vůbec takové tvrzení napadlo.

[David Jaša]

Docela by mě zajímalo, jak definuješ bootloader, aby tě vůbec takové tvrzení napadlo.

že by tím myslel ten kus sw, který je spuštěb hw (fw)?

[pavlix]

Právě. Mě taková definice přijde tak nějak nesmyslná. Už vzhledem k tomu, že to má loader v názvu bych očekával definici spíše z druhé strany, tedy že to slouží k natažení operačního systému nebo dalšího mezikroku během bootu. Proto se mi zdá nesmyslné za bootloader označovat poslední krok.

[Conscript89]

Jo, jde bootovat rovnou kernel, to je ovsem v kombinaci s UEFI Secure boot prakticky nerealne. Navic, musel bys pro kazdy kernel pridat zaznam do NVRAM. Ted jsem si uvedomil, ze je tam prakticky pozadavek na to, aby kernel lezel vedle grub.efi, takze to by taky nemel byt problem. Jako cistsi reseni mi prijde kdyz uz tak do ramdisku ulozit co je pro nej root a informace o dalsich partitionach. Porad v tom ale nevidim zadny prinos.

[pavlix]

Anebo jsi chtěl jen říct, že tohle může init řešit už nyní jen pomocí UUID (a znalosti boot disku)?

To je v podstatě zjednodušené shrnutí obou bodů. Ohlášenou feature a dokument chápu především jako zavedení podpory pro bootování podle UUID typu namísto UUID oddílu.

Jak se vlastně chová mountování podle UUID, pokud mám v PC dva oddíly se stejným UUID?

Současné bootloadery musejí pracovat v reálném světě a nikoliv nějakém vysněném lennartově/intelovském světě, kde existuje jen UEFI, takže není problém obecně řešitelný. Na druhou stranu pokud by měl kernel (například v případě UEFI) od začátku informaci, který disk je bootovací, tak není problém tuto informaci předat userspace a vždy při vyhledávání preferovat ten jeden disk.

Jenže to je natolik triviální, že se kolem toho dá jen těžko udělat takový hype.

[Conscript89]

+1000, stve me, ze ja takhle argumentovat neumim a pritom to tak citim :)

[Jakub Galgonek]

Mimochodem, nevím jak ty, ale já teda data zálohuju na jiný disk, než na kterém ta data mám.

[Marek]

Zda se, ze po 10ti letech budu muset hledat nejakou non-systemd nahradu za Debian.

[SPM]

A já tipoval, že to tentokrát nahradí httpd.conf zase vedle :)

[Heron]

Já zahrnutí pulse audio.

[Heron]

No potěš. Další komplikace hledání chyb. Teď, když se něco zapomnělo ve fstab, tak se na to velmi rychle přišlo. Teď, když to nebude ve fstab a nebude to mít no-auto flag, tak se to automaticky možná někam připojí. Takže: * Pokud možno nepoužívat GPT
* Pokud je to nutné, pečlivě nastavovat no-auto
* Nastavotat partition type na Other Data Partitions
* Dávat si ještě větší pozor na konfiguraci fstabu, protože se chyba nemusí projevit hned

[----]

Automatické připojování - ano, automatické připojování v systemd - ne. Třeba ZFS tuto funkcionalitu má ale je to integrované přímo s FS, resp. s celým systémem ZFS pools; což je IMHO správný přístup.

[anonym]

+1

What about automatic mounting of btrfs subvolumes to /var, /home and so on?

Doing a similar automatic discovery of btrfs subvolumes and mounting them automatically to the appropriate places is certainly desirable. We are waiting for the btrfs designers to add a per-subvolume type UUID to their disk format to make this possible.

mit seznam nesmyslnych UUID, podle kterych pak bude fungovat automounter je cesta do pekel. mnohem lepsi reseni je umoznit uzivateli ke kazdemu volume rict jestli a kam pripojit

zfs get mountpoint pool/volume

[Petr Ježek]

A proč je to IYHO správný přístup? Lidi, naučte se uvádět důvody, jinak zanecháte podivná dojem... :)

[kralyk z abclinuxu]

[systemd intensifies]

*grabs popcorn*

[lertimir]

A jak to ten systemd pozná? Mě blkid dává zcela jiné GUID pro root, /home i swap než ty, které jsou specifikovány v Discoverable Partitions Specification.

[pavlix]

Musíš rozlišovat ID partition a ID typu partition.

[Pavel Stárek]

A máš (U)EFI BIOS s GPT?

[abcd]

Systemd nastartuje systém, i když nebude existovat /etc. Nastaví počítač tak nějak užitečně. Myslím, že nás čekají světlé zítřky.

[mhepp]

Jo, a root-ovské heslo si automaticky najde u NSA...

[R]

Ano, cele /etc treba zrusit, pretoze by mohlo zmiast pouzivatelov. Vsetko treba zakompilovat priamo do kodu.

[Michal Kubeček]

Ano, poslední dobou mám pocit, že některé projekty se řídí filosofií "Potřebuje-li uživatel něco nastavit v konfiguraci, jsou jen dvě možnosti: (a) špatně jsme zvolili default, (b) default je správně, špatně je uživatel."

[pavlix]

suckless.org

[bugme]

Meh. Je rozdil mezi "nakonfigurovat jednou a pak to zkompilovat" a "nekonfigurovat nic a nechat nefungujici automagii at to jakoze vyresi za nas"

[little.owl]

Pokud je detekce zalozena na unikatnich GUID a vlastni boot na setu globalnich UEFI NVRAM variables, s tim ze to muze byt prekonfigurovano v fstab, tak je to krok kupredu. Cim mene nutne rucni konfigurace v zakladnim nastaveni, tim lepe.

[chrono]

Tá detekcia závisí, okrem iného, aj na presnom poradí partícií.

[little.owl]

A neni poradi detekce dano konfiguraci UEFI v NVRAM?

[pavlix]

Pokud je detekce zalozena na unikatnich GUID a vlastni boot na setu globalnich UEFI NVRAM variables, s tim ze to muze byt prekonfigurovano v fstab, tak je to krok kupredu.

Ta detekce je založena na neunikátních GUID, která se opíšou právě z toho dokumentu. Je to něco jako IBM/MS-DOS MBR a boot flag, akorát v pozdější fázi bootování, tedy krok kupředu osmdesátým létům. Tím, neříkám, zda je to dobře nebo špatně.

[little.owl]

Tak jiste, tam se predoklada, ze tvoje instalace bude sledovat nejakou specifikace. Prenesene to lze rici i o UEFI, nic te v praxi nenuti pouzit jimi doporucene GUID v tve GPT.

U Fedory bude stacit modifikovat Anakondu a je vymalovano.

[pavlix]

V tom nevidím žádnou novou informaci.

[kralyk z abclinuxu]

Ta detekce je založena na neunikátních GUID, která se opíšou právě z toho dokumentu.

To není GUID partice, ale GUID typu partice. A jako takové ty GUID unikátní jsou. Neplést PARTUUID nebo dokonce UUID filesystému.

[pavlix]

To už jsem v diskuzi psal několikrát, nespletl sis příspěvek k reakci?

[lertimir]

A kde to je a jak se nastaví GUID typu oddílu? (Ptám se asi jen pro obeznou znalost, protože pokud budu mít (a mám) více systémů a boot přes grub tak budu se fstab spokojen.)

[pavlix]

Pokud se ptáš jakým nástrojem, tak bych tipoval, že jakýmkoli nástrojem, co umí pracovat s GPT, například parted. Pokud se ptáš na umístění toho nastavení, tak je to součást metadat GPT partition.

[Grunt]

Nevím jestli s tím umí vyloženě parted, ale na takové věci je gdisk. Zas podle hlášek co to má nemám moc odvahu nějak v tom procesu pokračovat:

# gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

Command (? for help): quit

[pavlix]

Nevím jestli s tím umí vyloženě parted, ale na takové věci je gdisk.

Nemyslím si, že by bylo až tak těžké si to zjistit.

[Grunt]

No vidíš jaký si šikula.

[deda.jabko]

tak je to krok kupredu

Toto je z principu prasarna, protoze pripojovani disku je roztrousene na dve ruzna mista -- jednou se o pripojovani disku stara nejake letajici spagetove monstrum a podruhe /etc/fstab. Takze krome znalosti formatu /etc/fstab, musi clovek jeste pochopit myslenky a chovani tohoto monstra.

[little.owl]

Ja v tomto pripade spokene vyhodim fstab ve vetsine svych konfiguraci.

[pavlix]

Co konkrétně tě vede k tomu, že jsi ho ještě nevyhodil?

[pavlix]

Především je to přesný opak toho, co little.owl píše, tedy odklon od unikátních UUID, která zajišťovala správný průběch bootu bez ohledu na další připojená zařízení (za předpokladu spuštění správného bootloaderu). Místo unikátních identifikátorů nabízí použití identifikátorů, které jsou z principu nejednoznačné a celým jejich smyslem je připojovat filesystémy na základě příznaků namísto konfigurace.

[little.owl]

Především je to přesný opak toho, co little.owl píše,

Co je opacne nez pisi?

GUID schema umoznuje rezervovat ID pro specificke pouziti, v tom problem neni. Krom toho zminuji, ze je treba asi mit nejake zaznamy v NVRAM, coz automaticku implikuje nutnost pouzit bootloader, ktery jim rozumi.

[pavlix]

Přijde mi, jako bychom každý psali pod jinou zprávičkou.

V odkázané specifikaci se píše o možnosti označit oddíly v GPT jako root/home/swap/boot partition. To jsou data uložná přímo na disku v rámci GPT formátu. Celá ta funkcionalita je o tom namísto dosavadní jednoznačné identifikace oddílu začít používat označení účelu oddílu.

Nevidím tam nic o nvram ani jiných ptákovinách, navíc je to funkcionalita linuxového userspace, takže už je na nějaké bootloadery jaksi pozdě.

[little.owl]

Je to o auto-discovery, tedy o automaticke konfiguraci na UEFI systemech s GPT. Jejich nove GUID jen rozsiruji v soucasne dobe GUID specifikovane v platnem UEFI standardu pro Linux (swap, home, etc.), predevsim pridavaji ID pro root partition a pouzivaji je. Stejne tak pouzivaji GPT Attribute Flags, coz opet neni nic noveho.
Strucne, v podstate mirne rozsirili to co jiz existuje a pouzili to.

[pavlix]

Captain Obvious?

[Petr Ježek]

Tentokrát zásah hřebíčku na hlavičku, Sovičko. Zdejší rutinéři nějak zapomněli sledovat cvrkot venku...

[Petr Ježek]

Omluva, hodilo to příspěvek jinam, patřilo to jako reakce na poslední příspěvek Little Owla.

[pavlix]

Mám obavu, že little.owl si na vlezdoprdelství moc nepotrpí :D.

[xxx]

Zdejsi rutineri nezapomneli sledovat cvrkot venku. Jen pred rokem na serveru (z nejakeho zahadneho duvodu s Ubuntu), ktery jsem zdedil zanamenal upgrade na systemd stav, kdy uz to nebootoval a neslo to tam ani zpatky. Nastesti to byl virtual.

Co jsem se tak z praxe naucil je to, ze cokoliv co obsahuje slovo "auto" je zdroj potencialnich problemu, nebot v momente, kdy nastane nejaky neocekavany stav (at uz je to cokoliv od pripojene usb flashky, restartovaneho routeru, ...) auto cosi provede a skonci akorat tak v nejakem neznamem stave. Kdyz ma clovek kliku, tak alespon dostupnym po ssh. Nicmene rucni zasah je stejne nevyhnutelnym. Jako bonus to obcas dopadne akorat tak, ze misto aby se to vzpamatovalo samo po odezneni nejakeho kratkofobeho problemu, tak to v nedefinovanem stave zustane trcet.

Zkratka co si na servru nenastavim, na to nemuzu stejne spolehat.

Pruser celyho systemd je, ze nahrazuje naprosto zakladni cast systemu. Neni sance ho poradne otestovat. Neni mozne na nej primocare upgradovat, protoze hrabe vsude mozne, nahrazuje spoustu veci. Jeste se da zkusit, ze v normalnim stave to funguje, ale zjistit co se stane v chybovych stavech znamena to proste zkusit, a otestovat do ceho vseho v takovem pripade hrabne.

Jinak k tehle konkretni funkcionalite snad jen to, ze na primitivnim systemu ten fstab staci, na cem koliv slozitejsim je to stejne potreba nastavit rucne, takze je vlastne na hovno.

[Jardík]

No ještě aby mi to samo zadávalo heslo pro můj /home a bude to super... Né teď vážně. Nějak jsem nečetl, jak to funguje, ale co třeba počítač, a na něm mám 3 různá distra, sdílený /boot a sdílený home. Aby mi to náhodně nemountovalo jeden ze 3 rootů

[Václav "Darm" Novák]

V takovém případě asi bude nejlepší normálně nastavit fstab

[kolcon]

no co, Lennart ti oznami, ze jsi dinosaurus a ze vyvoj pujde dopredu i bez takovych lidi ;)

[fert]

a tolik jsem vahal a po letech jsem si pripustil debian na disk.. ja nestastnik... no nic, takze pujdu o dum dal.

[little.owl]

Rekl bych, ze hlavni duvod pro auto-discovery je zde:

* systemd-nspawn gained a new --image= switch which allows
          booting up disk images and Linux installations on any block
          device that follow the Discoverable Partitions Specification
          (see above). This means that installations made with
          appropriately updated installers may now be started and
          deployed using container managers, completely
          unmodified. 

[PavelC]

Dukaz kruhem ?

[little.owl]

Hektagonem.

Proc?

[Grunt]

Tak je tam:

$ yum list systemd
Zavedené moduly: langpacks
Nainstalované balíčky:
systemd.i686                         211-1.fc21                         @rawhide

Akorát mi není jasné jak mi to bude fungovat bez UEFI…

[Jardík]

Na GPT nepotřebuješ UEFI

[Grunt]

Máš recht. Teď jsem se to dozvěděl. Resp. potřebuješ, ale pouze pokud máš Windows, či některé ne-Intelí verze Mac OS.

[Peter Golis]

No vidíš. Mne funguje systemd bez UEFI, BIOSu a aj bez GPT a starej MBR Partition Table. Ten OFI ktorý mi inicializuje štart zavádzača systému vyžaduje iný typ rozdelenia disku.

[Conscript89]

No, jen doufam ze to nebude defaultni zpusob instalace. Bojim se ale bojim, ze se casem stane (uz jen kvuli pruraznosti urcitych lidi a jejich silenych nazoru). <irony>Musim rict, ze je to fakt super, ted budeme na tu krasnou FAT32 co se pouziva na bootloader ukladat i kernel a ramdisk</irony> (ted to vlastne uz vyzaduje treba gummiboot, ale u nej je to pochopitelne).

[pavlix]

Co je horší, že tohle bude další tlak na ARM a podobné, aby se ubírali stejnou cestou jako x86.

[little.owl]

Ty pudou primo, nebot se nebudou muset ohlizet na zpetnou kompatibilitu.

[Grunt]

No tak podle tohoto tipuju, že je to jen otázkou času než začnou instalátory všech majoritních distribucí používat GPT jako default.

BTW: Ten Leoš Poetteringovich včetně celého vývojářského týmu si to valí na cukru nebo jak si to mám vysvětlit?:

In fact, on my machine I now boot up with an empty kernel command line and with no fstab at all, and everything just works magically! Yay!

And then, you can use "systemd-nspawn -i /dev/sdb -b" to play around withit even without reboot! Yay!

Podle nadšení osob zúčastněných tipuju, že se můžeme začít vsázet jak dlouho to bude trvat než se z toho stane výchozí stav (i díky šíření systemd jako výchozího inicializačního systému). Já vidím GPT a DPS jako default tak na další verzi Fedory a tak maximálně do dvou let než se z toho stane default ve všech majoritních distrech (možná krom Gentoo, které úspěšně vzdoruje), ať se to každému líbí nebo ne. Yay!¹

1. 

[Grunt]

and everything just works magically!

Jo a ještě doporučuju oprášit a naleštit kouzelnické hůlky. On se fakt měl jmenovat Harry Potter, ne Lennart Poettering.

[David Jaša]

tož pokud by se mergnul s Haraldem Hoyerem, tak by k tomu Harrymu Potterovi fakt neměli daleko.

[pavlix]

možná krom Gentoo, které úspěšně vzdoruje

Vzhledem k absenci standardního instalátoru, v případě Gentoo se jedná pouze o dokumentaci.

[Grunt]

Máš recht. Takže jediný možný způsob jak se vyhnout Poetteringománii je zkompilovat si vlastní systém a zvolit si něco jiného než systemd. Takže se to týká ještě LFS.

[pavlix]

Erm... takhle jsem to úplně nemyslel, takže se o kredit hlásit nemůžu. Ale je to v souladu s tím, co píšu v jiných souvisejících diskuzích. Vzhledem k tomu, že já osobně se na Gentoo dívám jako na naskriptované LFS s trackováním souborů v systému, tak se můžu s tvým příspěvkem ztotožnit.

Ve skutečnosti si totiž budeš muset udržovat u všech služeb patche přidávající podporu pro daný init, pokud nebude naopak on plně podporovat systemd service soubory. Gentoo mainstream z pochopitelných důvodů brzo na systemd přejde, takže to bude ještě zajímavé.

[little.owl]

Tohle je presne vec, ktera se mi taky libi.

Yay!

[pc2005]

Už si představuju jak jednou vyjde zprávička: "Systemd podporuje plánovač souborů a správu paměti, CFS je již zbytečné" .

[JS1]

Jednou takova zpravicka nepochybne vyjde, ale bez te druhe vety. IBM z/OS tohle uz davno umi (WLM).