Arch Linux testing + upgrade glibc

7.7.2012 17:21 | Přečteno: 1215× | Problémy | poslední úprava: 7.7.2012 17:36

Jen krátce ohledně upgradu glibc na 2.16.0-2 na Arch Linuxu v testingu.

Při aktualizaci (vzdálené přes SSH) to na mě teď vyplivlo, že došlo ke konfliktu souborů ve FS. Balíček se snažil nějak šachovat s /lib a nešlo mu to (selhalo to). Spustil jsem to jako správný blázen s --force a zůstal jsem se zdánlivě nefunkčním systémem. Všechny příkazy vracely "no such file or directory", i když jejich binárky existovaly a FS nebyl připojený s "noexec".

Našel jsem tenhle uzavřený bugreport, kde měl někdo stejný problém a jistý chytroprd mu tam odpověděl, že to má vyřešit jako člověk (místo toho aby napsal jak) a bug zavřel. Nefungovala mi žádná binárka (ani ls), tak mě napadlo použít busybox, který naštěstí fungoval a snažil jsem se zjistit co se dělo s /lib. Pak mi došlo, že se vše přesunulo do /usr a stačí /lib dát pryč a vytvořit místo toho symlink do /usr/lib a pak už to fungovalo.

# nejdřív se ujistěte, že máte busybox nainstalovaný a pak:
pacman -Sf glibc
busybox mv /lib /lib.bak
busybox ln -s /usr/lib /lib

To je vše. Ještě že máme ten BusyBox

       

Komentáře

[M.]

To jsou ty vaše aktuální Archlinuxy

[kotyz]

To je testing, tak se nediv.

[Jardík]

To je proto, že použil testing a může si za to sám. Pokud je normálně na něco dát bacha tak je to popsáno na webu a často i nějakou tu hlášku vyplivne pacman při aktualizaci balíčku, jenom číst.

A lepší než mít debian s 3 roky starým SW s bugy, který nikdo neopraví. Maximálně tak bezpečnostní, ale né funkčnostní.

[David Watzke]

Bohužel o tomhle se nikde nepsalo a balík (pokud vím) taky nic nevypsal. Píše se pouze o stable novinkách. A rozhodně si za to můžu sám a proto jsem to taky v klidu během pár minut vyřešil

[xhc]

si mně pobavil

[Jardík]

"no such file or directory" mi to nedávno házelo na Live CD Fedory, když jsem se tam snažil spustit binárku mého programu zkompilovaného na archlinuxu. Problém bylo, že byly linkovány oproti "/lib/ld-linux-x86-64.so.2", kdežto fedora jí měla v /lib64. Symlink to pořešil. Bohužel je to taková demence hardcódování cesty ke knihovně. Spousta dister má binárky linkovaný oproti /lib64/ld-linux-x86-64.so.2, takže v archu je to vojebáno hackem, kdy kvůli nim existuje /lib64 a v tom 2 symlinky (ld-linux-x86-64.so.2 a ld-2.15.so).

Každopádně bych řekl, že problém byl právě v nenalezení ld-linux-x86-64.so.2 knihovny, která je linkována s absolutní cestou a že busybox fungoval, protože je linkován staticky.

[David Watzke]

Jo, určitě to bylo tím, akorát už je to dlouho, co jsem měl podělanou glibc, tak mi to nedošlo hned

[stativ]

A ten chytroprd měl pravdu. Zaprvé používat force je prasárna, kterou můžeš dělat jen když víš, co děláš. Bohužel je tu spousta „chytroprdů,“ kterým jsou všechna tahle varování někde a bezmyšlenkovitě prostě použijí force místo toho, aby zjistili, kde je problém. To platí dvojnásob, když dotyčný používá testing repozitář. A za druhé – nikdo z vývojářů nemůže ručit za to, že se ti kvůli nějakému balíčku z AURu rozbije systém.

[David Watzke]

Chytroprdem jsem ho nazval proto, že neposkytl (odkaz na) řešení a jen dělal chytrýho. Kdyby dělal chytrýho a zároveň poskytl to řešení, tak neceknu.

Testing je AUR?

[stativ]

Chytroprdem jsem ho nazval proto, že neposkytl (odkaz na) řešení a jen dělal chytrýho. Kdyby dělal chytrýho a zároveň poskytl to řešení, tak neceknu.

Řešení se povalují snad na všech mailing listech, IRC a dost možná i na fóru.

Testing je AUR?

Ne. Ale v testingu by nemělo být kromě glibc nic, co má věci v /lib. Tudíž to musel být nějaký balíček z AURu, co to pokazil. Případně je tu ještě možnost, že je tam nějaký pochybný bordel, který není součástí žádného balíčku.

Jo, teď mě napadá ještě jedna možnost (a řekl bych, že dost pravděpodobná), za kterou může pacman, protože v něm není možné vynutit pořadí aktualizovaných balíčků – k aktualizaci glibc došlo dříve, než k aktualizaci ostatních balíčků a ty tedy neodstranily své soubory z /lib před tím, než glibc začalo čachrovat se symlinky. Pak by pomohlo něco jako pacman -Syu --ignore glibc && pacman -S glibc

[David Watzke]

Tím pádem by pro něj nebyl žádný problém na to odkázat

A ke zbytku: díky za info.

[Mrkva]

Symlink /lib na /usr/lib? To je hnus. Jdu blejt, velebnosti.

[stativ]

Jsem rád, že nejsem jediný, komu to vadí. Prý je to proto, že to tak má Fedora (resp. se o to přinejmenším snaží) a protože se to snaží protlačit vývojáři systemd.

[pavlix]

Jsem rád, že nejsem jediný, komu je to jedno (plus je tomuto kroku mírně nakloněn).

[stativ]

plus je tomuto kroku mírně nakloněn

Tohle mě zajímá. Nějaké důvody, proč by to mělo být lepší?

Zatím jsem nikde neviděl opravdu dobrý důvod, proč to tak mít. Pořád to jsou jen vyjádření typu: Fedora to tak má (proč?), Solaris to tak má (proč?), všechny binárky jsou v /bin i v /usr/bin (máme přece PATH), už vyžadujeme, aby /usr bylo namountováno v initramfs (jak to s tím souvisí?). Když už, tak mi přijde rozumnější udělat merge opačným směrem – ušetří to psaní (což je samo o sobě chabý důvod).

[pavlix]

Taky jsem původně navrhoval merge opačným směrem. Ale nechal jsem se přesvědčit, že je lepší mountovat jeden /usr než jednotlivě /bin, /sbin, /lib a k tomu ještě /usr (protože například /usr/include, /usr/share, /usr/doc, …).

Nový /usr tak sdružuje všechna neměnná data pohromadě v jednom filesystému.

Ale, jak už jsem psal, jsem tomu mírně nakloněn, kvůli zde uvedenému, jinak je mi to v podstatě jedno. Co ale prakticky neexistuje, jsou nějaké relevantní důvody proti tomuto kroku v době, kdy systém bez /usr není tak jako tak považován za plně funkční.

[stativ]

Taky jsem původně navrhoval merge opačným směrem. Ale nechal jsem se přesvědčit, že je lepší mountovat jeden /usr než jednotlivě /bin, /sbin, /lib a k tomu ještě /usr (protože například /usr/include, /usr/share, /usr/doc, …).

Nový /usr tak sdružuje všechna neměnná data pohromadě v jednom filesystému.

To dává smysl, hlavně vzhledem k počtu adresářů s nestálým obsahem co jsou v /.

Co ale prakticky neexistuje, jsou nějaké relevantní důvody proti tomuto kroku v době, kdy systém bez /usr není tak jako tak považován za plně funkční.

To ne, ale přijde mi to takový krok stranou, který nic nezmění.

[pavlix]

To ne, ale přijde mi to takový krok stranou, který nic nezmění.

Přesně z toho důvodu píšu, že jsem mu nakloněn mírně :). Nemyslím si, že by to něco měnilo, nemyslím si, že by to bylo špatně, a myslím si, že to má nějaké drobné výhody.

[Mrkva]

A to s tim --force mi vypada jak pristup rm -rf / nefunguje, tak pridam --no-preserve-root

[kotyz]

Já používam -f jen když na homepage archu v news píšou že to je třeba pro konkrétní balíček udělat, aby upgrade doběh úspěšně. A to je tak jednou do roka. Na testingu nejedu, nedavno sem si ten repozitář zakázal úplně.

[David Watzke]

No vždyť jo! Je to osobní notes, tam je ten systém od toho

[Bedňa]

Archu sa vyhýbam, vďaka politike čo platilo včera dnes nieje pravda, holt cena za najaktuálnejší soft.

[Begleiter]

čo platilo včera dnes nieje pravda

1. Toto platí u libovolné distribuce, akorát Arch to má "rychlejší".

2. Je to jenom prostě přirozená reakce na aktuální dění v oblasti (svobodného, otevřeného) softwaru.

[Bedňa]

čo platilo včera dnes nieje pravda

1. Toto platí u libovolné distribuce, akorát Arch to má "rychlejší".

2. Je to jenom prostě přirozená reakce na aktuální dění v oblasti (svobodného, otevřeného) softwaru.

1. Distrá čo používam používajú v danej verzií backporty, takže nič sa nemení.
2. Našťastie sú štandardy a niektorí vývojári sa ich aj držia.

[Begleiter]

Jenom dodám, že tu "cenu" za aktuální software rád "zaplatím".

[Bedňa]

Preto aj Arch patrí medzi obľubené distrá, mi leniví naň ale pozeráme z diaľky

[Begleiter]

Výstižně napsáno.