Portál AbcLinuxu, 14. května 2025 22:40
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.
Tiskni
Sdílej:
Pokud se něco v systemd pokazí tak to lze velmi snadno analyzovat a stejně jako u jiných initů rychle opravitMá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é.
13.3.2014 10:09
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
)
13.3.2014 10:09
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
13.3.2014 14:02
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
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á.
13.3.2014 14:29
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
Na desktopu to není poznat a na serverechTo jsou mi zase teorie, a co bys řekl o laptopu, na tom mém to zrovna poznat je ;).
Na desktopu to není poznat
Co prosím?
14.3.2014 10:59
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
Myslím tím při normálním použití.Odkaz na normu?
14.3.2014 11:35
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
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.
13.3.2014 09:51
FrostyX | skóre: 27
| blog: Frostyho_blog
| Olomouc
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?
by u mne práci nenašel.To by pro něj bylo jen štěstí...
13.3.2014 13:47
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
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.... :'-(
"Why are you taking my /etc/fstab away?"
"We are not. /etc/fstab always overrides automatic discovery."
$ 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?
$ ls -lh /etc/mtab -rw-r--r-- 1 root root 2,0K 13. bře 10.05 /etc/mtabNa CentOS 6:
# ls -lh /etc/mtab -rw-r--r-- 1 root root 533 13. bře 04.42 /etc/mtabDebian 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
13.3.2014 07:20
14.3.2014 20:36
13.3.2014 08:14
13.3.2014 09:13
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.
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.
kdy bych musel do mtab lest rucneRuč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.
tak tam uz se da hledat /boot podle UUID partitionTaky 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.
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
14.3.2014 09:41
--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.
neustálý boj s NM zvedá už i tak pracnost o třetinuA bude hůř. Co zkouším aktuální stav v Gitu, tak se kolikrát nestačím divit.
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.Tak tím se myslí root oddíl, ze kterého to bootujeeh? - bootuje to snad z /boot a ne z / (aspoň co se týče Fedory, vlajkové to lodi systemd ...)
# 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
the disk the EFI ESP used to boot is located ona 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 ...
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.
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.
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ď ;).
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.
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)?
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.
zase vedle :)
13.3.2014 10:16
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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
13.3.2014 09:28
blkid dává zcela jiné GUID pro root, /home i swap než ty, které jsou specifikovány v Discoverable Partitions Specification.
13.3.2014 14:48
Pavel Stárek | skóre: 44
| blog: Tady bloguju já :-)
| Kolín
13.3.2014 11:52
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
13.3.2014 12:34
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
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ě.
13.3.2014 12:33
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
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.
14.3.2014 11:57
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
# 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
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.
tak je to krok kupreduToto 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.
13.3.2014 13:08
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
13.3.2014 13:37
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Především je to přesný opak toho, co little.owl píše,Co je opacne nez pisi?
13.3.2014 14:06
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
13.3.2014 14:31
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
13.3.2014 15:25
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
13.3.2014 19:25
13.3.2014 14:25
* 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.
14.3.2014 10:55
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
13.3.2014 15:42
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
$ yum list systemd Zavedené moduly: langpacks Nainstalované balíčky: systemd.i686 211-1.fc21 @rawhideAkorát mi není jasné jak mi to bude fungovat bez UEFI…
14.3.2014 12:14
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
14.3.2014 10:57
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
14.3.2014 12:35
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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
14.3.2014 12:40
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
možná krom Gentoo, které úspěšně vzdorujeVzhledem k absenci standardního instalátoru, v případě Gentoo se jedná pouze o dokumentaci.
14.3.2014 14:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
14.3.2014 13:31
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
