Dotaz: Upgrade jádra

[lertimir]

Instaluji openSUSE 13.2 na nový notebook. Zatím je nefunkční wifina. Důvod je téměř jistě ten, že je tam nový chip BCM43228, který má podporu až od jádra 3.17 zatímco openSUSE 13.2 má jádro 3.16. (podobně jako ubuntu 14.10) Nicméně opensusí roling release (Thumbleweed/Factory) už je na 3.17. Z druhé strany je ale ještě požadována funčnost virtualboxu a není mi úplně zcela jasné, co s tím. Protože je to zcela nový stroj bez dat, tak vidím 3 možnosti.

1. přejít do jiného distra. Asi jedinné je MAgeia 5 RC 1 s kernelem 3.17.
2. Zkompilovat si vlastní jádro, ale pak musím hlídat bezpečnostní aktualizace.
3. Vrazit tam jádro z Factory, Pro bod 2 a 3 a nějak jádro zařadit do bootu, je jsem zatím nedělal. ( To bude znamenat asi stáhnout i k němu zdrojáky a ručně přikompilovat BLOB virtual boxu.)

Co je tak asi nejschůdnější cesta, nechci tomu věnovat moc času.

---

---

Odpovědi

[lertimir]

Ještě poznámka nechci přecházet a přehodit repo na Factory.

[Andrej]

Jaképak jediné distro?! Fedora i Arch samozřejmě už odpradávna mají kernel 3.17. Nemusí být každé distro fosilní.

Zkompilovat si vlastní kernel je celkem snadno proveditelný nápad. Není pak nutně potřeba hlídat žádné aktualizace — stačí si kernel překompilovat, když vyjde nová verze. Lidský čas je drahý, proto nemá smysl zabývat se pokaždé znova otázkou, jestli je aktualizace zrovna na danou verzi nezbytná, a místo toho prostě spustit „na pozadí“ svůj oblíbený skript na kompilaci kernelu.

Nejjednodušší cesta by mohla být dočasné použití vlastního zkompilovaného kernelu (ať už vlastnoručně z Gitu nebo pomocí nějakého nástroje v distru) do doby, než se dostatečně nový kernel dostane implicitně přímo do distribuce. To podle mě nemůže trvat déle než pár měsíců.

[ewew]

Vidím, že máš veľa ušetreného času. Prečo svoj ušetrený čas nevyužiješ vylepšovaním svojho Archu.

Si znalec distribúcii ? Nech každí používa čo chce. Každí má slobodné rozhodnutie čo si vyberie. Podľa mňa robíš veci tak aby boli hotové a nezaujíma ťa ani ako sa to dá urobiť inač. Najskôr volíš cestu najnižšieho odporu ? Neviem čo ťa motivuje stále aktualizovať arch. Keby má niečo stabilné čo sa nemení každú sekundu možno by si toho naprogramoval niečo viac. Možno keby to bolo aj 0.00000001% viac. Keby to bolo možne možno by si každí deň upgradoval firmvér riadiacého systému rozvodu elektrického prúdu,vody, plynu, elektrárni ? Síce je to extrém ale nič nie je nemožné. Mal by si odvahu zobrať zodpovednosť za takéto systémy pri dennom upgrade firmvéru. Ako by si sa dorozumieval pri páde týchto systémov ? Predstav si, že by nefungovala sieť Internetu. To znamená, že VOIP nefunguje. Mobil by mohol fungovať ale je to zastaraná technológia. Čo urobíš. Hlasová komunikácia nie je vždy dostatočne zretelná. Na toto exitstuje riešenie z vysielačiek. Foneticke hláskovanie. Aha znovu zastaraná technológia. Nakoniec pri kolapse je vždy najlepšia najjednoduchšia technológia.

Sorry za off-topic.

[Andrej]

Si znalec distribúcii ?

Ano, jsem. Není mi jasné, kam směřuje tato otázka a čím přesně přispívá do konstruktivní debaty.

Tak celkově nechápu, na co se tu snažíš reagovat. Anglicky se tomuto jevu trefně říká over-reacting. Kdybys dočetl můj komentář do konce, věděl bys, že jsem zmiňoval několik možností. Vlastnoruční upgrady kernelu jsem uváděl pouze jako jednu z možností a doporučoval jsem je spíš jako dočasné řešení, což ale pochopili jen ti, kteří dokázali udržet pozornost a chápat psaný text až do posledního odstavce.

Tvůj příspěvek je opravdu těžce off-topic, když uvádíš příklady nějakých embedded systémů, u kterých se kernel a základní userspace označuje za „firmware“. Původní tazatel se jasně ptal na běžný desktopový systém a jasně uvedl, proč potřebuje upgrade kernelu. Řeči o vodě, plynu a elektrickém rozvodu jsou úplně mimo mísu. Úvaha o používání zastaralých technologií jako záložních prostředků komunikace na tom není o nic lépe. Můžeš nějak objasnit, jak ty zastaralé technologie zprovozní WiFi chipset BCM43228?

Neviem čo ťa motivuje stále aktualizovať arch.

Mě nemusí k aktualizacím nic motivovat. Jsou totiž tak jednoduché, automatizované, nenáročné a snadno dostupné, že nemám absolutně žádný důvod je neprovádět.

Keby má niečo stabilné čo sa nemení každú sekundu možno by si toho naprogramoval niečo viac.

Zas a znova tahle nesmyslná pověra. Až je to někdy únavné. Záleží sice na konkrétní platformě, toolchainu a podobně, ale obecně platí, že na programování není nic lepšího než aktuální systém. Stačilo by například vzít nějakých 1000 projektů z GitHubu, které zaznamenaly v uplynulém týdnu nějaký push, a zkusit, na které distribuci se kolik z nich přeloží. Fosilní distribuce zoufale prohrají a nutí své uživatele bojovat o každý balíček, o každou knihovnu.

Už dávno jsem tu někde psal, jak se liší domovské adresáře uživatelů na rozumné distribuci a na Ubuntu. (To nelze přehlédnout, když člověk příslušné systémy zálohuje.) Na normální distribuci tam uživatelé mají pár svých souborů, nic víc. Na Ubuntu tam mají celý „stínový“ root filesystém s gigabyty knihoven a programů v aktuálních verzích, které si museli sami stáhnout (!) a sami zkompilovat (!), aby vůbec mohli dělat svou práci. Takhle tedy „naprogramují víc“? Věřit báchorkám se nevyplácí.

[nobody]

Co to zace placas, v Ubuntu v home neni zadnej stin rootfs, pokud chce nekdo neco novejsiho nez nabizeji oficialni repositare pouzije se ppa repository daneho programu, malokdy bude problem aby bylo treba resit nove navazane knihovny, a pokud ano ve vetsine pripadu budou pripravene i v tom ppa programu kterej je na ne navazanej, v tech par promile ostatnich pripadu uz se bude jednat o takove speciality ze uzivatel nebude mit problem si zprovoznit Gentoo, Arch, nebo klidne LFS :)

Andreji, kdyby jsi byl trochu min arogantni, trochu min opovrhoval ostatnima, trochu min se povysoval, trochu min te nesnasenlivosti, trochu min pouzival slova fosilni... mozna by jsi byl trochu mensi hovadko ;) jo a nezapomen poznamenat, ze by jsi ty anonymy uplne zakazal :D

[Jendа]

Co to zace placas, v Ubuntu v home neni zadnej stin rootfs

Můžeš prosím zkusit rozepsat, jestli má tedy Andrej halucinace?

pokud chce nekdo neco novejsiho nez nabizeji oficialni repositare pouzije se ppa repository daneho programu

Pokud existuje.

v tech par promile ostatnich pripadu uz se bude jednat o takove speciality ze uzivatel nebude mit problem si zprovoznit Gentoo, Arch, nebo klidne LFS

Dotaz, pod kterým diskutujeme, vznikl takovou „specialitou“. Notebook s novým broadcomem totiž má jenom pár promile lidí?

[Michal Kubeček]

Notebook s novým broadcomem totiž má jenom pár promile lidí?

Nepřekvapilo by mne to.

[lertimir]

No zase tak moc specialita to není. Je to normální HP EliteBook 820 G1, v podstatě slušný nový notebook. Vzhledem k tomu, že na stránce mají, že se dodává i se SUSE (asi SLED s HP upravou) tak očekávám, že si ho může koupit více linuxářů a věřím, že půjde plně zprovoznit.

[Jendа]

Na Ubuntu tam mají celý „stínový“ root filesystém s gigabyty knihoven a programů v aktuálních verzích, které si museli sami stáhnout (!) a sami zkompilovat (!), aby vůbec mohli dělat svou práci.

A to je poslední Ubuntu, nebo pět let stará LTS verze?

[Andrej]

Je to 12.04 LTS.

Takže není to zrovna pět let staré (to už by spadlo pod hranici elementární použitelnosti), ale určitě to bude mít dobré tři roky, když uvážím, že ta distribuce byla „předzastaralá z výroby“ už v tom dubnu 2012.

[Jendа]

Takže srovnáváš pravidelně aktualizovaný Arch s Ubuntu starým 5 releasů a stěžuješ si, že v něm máš starý software. Fascinující. Proč na to Ubuntu nepoužiješ podobný přístup jako u Archu, tedy dist-upgrade každý půlrok?

[Andrej]

Kdybych měl v otázce těch konkrétních strojů nějaké rozhodovací pravomoci, samozřejmě bych takový přístup použil. (Hlavně by pak k žádnému takovému problému nedošlo, protože by se tam nikdy žádné Ubuntu nedostalo.)

Když si vzpomenu, jak jsem teď na nějakém 14.10 (ne-LTS) musel zase (neúspěšně) kompilovat polovinu Ruby ve snaze zprovoznit nějakou ptákovinu, která na Archu i na Fedoře prostě okamžitě běží, řekl bych, že ač mé srovnání výše není fér, moje původní pointa pořád platí.

[Jendа]

Si znalec distribúcii ? Nech každí používa čo chce. Každí má slobodné rozhodnutie čo si vyberie.

Vždyť v tom příspěvku nepsal nic jiného…

Neviem čo ťa motivuje stále aktualizovať arch.

Nevím, co jeho, ale mě: v nových verzích jsou nové funkce a opravené bugy, případně jsou potřeba nové verze knihoven, abych mohl zkompilovat gitovou verzi různých jiných projektů, které jsou třeba experimentální nebo je chci ladit (gnuradio, osmo*).

[Michal Kubeček]

Nevím, co jeho, ale mě: v nových verzích jsou nové funkce a opravené bugy

…a taky nové bugy. Na to se často a rádo zapomíná.

[Jendа]

Ale on se ptal proč aktualizuju, ne proč neaktualizuju

[Andrej]

Co je lepší — zachování a hýčkání starých bugů nebo upgrade na nové bugy?

Podle mě to vyjde nastejno. Z pohledu bezpečnosti na tom můžou být nové bugy lépe, protože budou méně známé útočníkům všeho druhu.

Na nové bugy se tedy rozhodně nezapomíná, ale v celkovém součtu výhod a nevýhod nemají nikde ústavní většinu.

[Jendа]

Na staré bugy se zase líp googlí workaround, protože už se tím někdo stihl zabývat.

[Michal Kubeček]

Co je lepší — zachování a hýčkání starých bugů nebo upgrade na nové bugy?

Falešné dilema. Pro funkčně dostačující existující systém je lepší opravit známé bugy, které někomu opravdu vadí, a (pokud možno) zbytečně nezanášet nové. Vážně si myslíte, že ty firmy, které dodnes platí nemalé peníze za support systémů z roku 2004, to dělají jen proto, že jsou banda idiotů, kteří tomu na rozdíl od vás vůbec nerozumějí?

[Andrej]

Ano, to si skutečně myslím, bez legrace.

[Andrej]

A když už je řeč o gitu a kompilaci, já občas uvádím třeba Diasporu jako dobrý důvod, proč mít Arch na některém serveru. Jeden z vývojářů Diaspory používá Arch a udržuje balíčky s Diasporou, díky kterým je dnes instalace a aktualizace Diaspory v Archu (přímo z gitu) jednoduchá. Nebýt Archu, asi bych svůj Diaspora pod už dávno zavřel.

[Jendа]

Keby má niečo stabilné čo sa nemení každú sekundu možno by si toho naprogramoval niečo viac.

Možná ano, ale pak by to lidem s novějším systémem nešlo zkompilovat. A nebo zase ne, protože bych třeba tři dny řešil bug, který už v poslední verzi někdo vyřešil (příklad z praxe, kdybych používal starší verzi, tak se z toho po***).

[lertimir]

To máš pravdu. Opomněl jsem tvůj oblíbený Arch. Nicméně ten beru mnohem více jako distro pro lidi, kteří se chtějí "učit linux" a jsou s mnohými vlastnostmi a časovými nároky buď smířeni (když je ještě dostatečné neumí) nebo je mají rádi a využívají je (když je umí jako zřejmě ty). Tento notebook je pro uživatele, který na něm pracuje a nespravuje jej. Takového pro kterého je příkazová řádka poslední možnost, jak něco řešit, když už to naklikat nejde. Distro openSUSE s KDE prostředím díky Yastu na management systému a Nastavení Systému v KDE díky čemuž si uživatel většinu nakliká, je pro uživatele i pro mne nejmenší časová zátěž po níž se tomu systému musím věnovat. Arch by stál více času, alespoň v době než bych se ho naučil dobře. Fedoru neznám tam nevím, jak moc je management dobře integrovaný v KDE. Mandrake/Mandrivu/Mageiu jsem znal z před cca 10 let grafickou správu systému měla slušnou. Proto jsem ji uvažoval.

[Andrej]

Fedoru s KDE jsem používal v práci cca rok a měl jsem s ní jen ty nejlepší zkušenosti. (Jako zásadní odpůrce Gnome bych nikdy nedoporučoval distro, ve kterém nefunguje dobře KDE.) Kdybych nezměnil zaměstnání a kdybych nemusel ten desktop s Fedorou vrátit, používal bych asi Fedoru v práci dodnes.

OpenSUSE jsem naposledy viděl v roce 2012, takže to nemůžu přesně srovnat, ale ve Fedoře s KDE taky existuje spousta nativních klikátek a udělátek pro správu systému. (Samozřejmě se musí nainstalovat — nejsou automaticky v dependencích KDE, což je asi jedině dobře.) Pro správu softwaru tam je velice pěkné GUI částečně napsané rovnou v Qt a částečně integrované do nějakého Plasma appletu atd. Celý rok, kdy jsem Fedoru používal, se aktualizace děly naprosto automaticky a bez mého přičinění. Jenom se mi třeba při uspávání desktopu objevila bublina "bacha, dnes se aktualizoval kernel, je doporučeno vypnutí místo uspání" a tak. Tahle doporučení byla dost precizně odstupňovaná, protože to třeba umělo říct „aktualizovaly se komponenty KDE, až budeš mít chvilku, odhlas se a znova se přihlas“, případně „byl aktualizovaný kus X-serveru, tak až budeš chtít, restartuju KDM“. Nikdy to nechtělo žádné bezdůvodné restarty kvůli nějakým banálním každodenním aktualizacím. Navíc se tam dalo velice přesně nastavit, co se má aktualizovat automaticky a co ne a jak často se má něco takového řešit. Taky s grafickými utilitami pro nastavení sítě (Plasma appletem pro ovládání NetworkManagera) jsem byl naprosto spokojen. Ten je tam v podstatě out-of-the-box. Asi bych taky vyzdvihl instalátor, který se nebojí konfigurace bootující z Btrfs a používající subvolumes. Binární ovladače od grafických karet překompiluje automaticky podle potřeby akmod s pluginem pro daný hardware (tj. například něco jako akmod-nvidia). Sečteno a podtrženo, umím si představit, že by to někdo mohl používat i jako klikací distro, ve kterém nesahá do terminálu. (Poté, co mu někdo pomůže se základní instalací a přidá všechna ta standardní distribuční klikátka.)

[lertimir]

Hotovo i na openSUSE. Jádro se automaticky zařadilo do grub2, na wifinu se musely ještě extra zavolat vlastní downaload driverů podle příkazu, který jádro napsalo do dmesg. (Počítám, že to je licenční záležitost oss/non-oss.) Virtual box se nainstaloval celý automaticky standardním způsobem, po zařazení přímého repozitáře z oraclu. Pohoda. Mimochodem openSUSE 13.2 také bootuje zvnitř btrfs sedícího na LVM, žádný separátní /boot oddíl, jen subvolume pro /boot, /var a pár dalších. Při nové instalaci dává na root btrfs jako implicitní filesystem. A opensuse také neotravuje zbytečně z rebootem, aktualizuji sice vetšinou sám, protože chci vědět co, ale nastavení aktualizuj automaticky (bud jen security nebo vše) má také. maximálně se občas mohu chtít zeptat, jak to z restartem služeb je, když si pustím zypper ps tak mi vypíše procesy, které mají naloudované soubory, které díky aktualizaci už nejsou (a je vhodné je někdy restartovat.)

[MadCatX]

Na distribuci využívající RPM balíčky bych asi použil rpmbuild a upravil si .spec soubor pro sestavení jádra 3.17. Je to IMHO nejčistší řešení a rpmbuild to dokáže dostatečně automatizovat. Ovladače pro VirtualBox hosta se dají zkompilovat automaticky třeba přes DKMS.

[Jendа]

Mně na Debianu VirtualBox s 3.17 normálně funguje, modul si to zkompilovalo samo (samozřejmě bylo potřeba nainstalovat s jádrem i hlavičky).

Vrazit tam jádro z Factory, Pro bod 2 a 3 a nějak jádro zařadit do bootu, je jsem zatím nedělal.

Na Debianu se jádra z balíčků generují do nabídky bootloaderů automaticky, na OpenSUSE snad taky…

[Michal Kubeček]

Mně na Debianu VirtualBox s 3.17 normálně funguje, modul si to zkompilovalo samo (samozřejmě bylo potřeba nainstalovat s jádrem i hlavičky).

Zrovna mezi 3.16 a 3.17 došlo k nekompatibilním změnám API, takže některé third party moduly (VMware, VirtualBox) je potřeba opatchovat. Novější VirtualBox to AFAIK řeší, ale ten ve 13.2 pochopitelně není. Ale když už si bude z Factory brát jádro, může vzít i VirtualBox.

Na Debianu se jádra z balíčků generují do nabídky bootloaderů automaticky, na OpenSUSE snad taky…

Pokud ho instaluje z RPM balíčku tak ano.

[lertimir]

Právě VirtualBox ve Factory není. Ale díky všem za komentáře. Z komentářů vypadá, že řešením bude vzít jádro z Factory včetně hlavičkových souborů a možná i zdrojáku a VirtualBox vzít přímo od Oracle ne z repa, balík z oracle je instalační script/zdroják (možná i kus blobu), který právě zkompiluje jaderný modul na interface pro konkrétní jádro. Při změně jádra se znovu musí zkompilovat ať již automaticky nebo ručně. To mu doufám sestaví, co potřebuji. OpenSUSE slibuje, že cílové jádro pro 13.2 je 3.17 a asi se ho do vánoc dočkáme, pak bych to stáhnul na standardní repo.

[Josef Kufner]

V Debianu se používá DKMS (Dynamic Kernel Module Support), což je služba, která kompiluje 3rd-party moduly na požádání při bootu nebo při instalaci balíčku. Slouží právě k tomu, aby při upgrade nebylo potřeba se o nic starat. Google tvrdí, že v OpenSuse to je také.

[Michal Kubeček]

To je sice hezké, ale v okamžiku, kdy máte nekompatibilní změnu API (jako právě mezi 3.16 a 3.17), tak vám žádný takový automatický nástroj prostě fungovat nebude; ty moduly se prostě musejí opatchovat.

Google tvrdí, že v OpenSuse to je také.

DKMS sice asi existuje, ale spíš jako doplňkový nástroj pro ty, kdo chtějí používat jiná jádra než ta z distribuce. Distribuční jádro zachovává kABI, aby šly tytéž moduly použít bez rekompilace. (Tuhle zásadu by ale při případném upgradu na 3.17 bylo nutné porušit.)

[lertimir]

No je a není. Oficiální repa ho nemají. dokonce stránka download VirtualBoxu na posledním řádku připomíná, že openSUSE dkms nemá. Našel jsem ho jedině v komunitním repu, které dělá jeden člověk, které navíc podle subprojektů je sině zaměřen na rekompilaci nVidia driveru, což nevím, jak moc dobře bude mít zintegrované i pro VB.

[Michal Kubeček]

OpenSUSE slibuje, že cílové jádro pro 13.2 je 3.17

To byl sice původní plán, ale s ohledem na časový harmonogram vydání jádra 3.17 a OpenSuSE 13.2 to nakonec nebylo reálné a ve 13.2 zůstalo jádro 3.16.

a asi se ho do vánoc dočkáme

Tak to máte asi nějaké informace, které mne minuly. V příslušném diskusním listu proběhla sice debata na toto téma a upgrade na 3.17 v rámci updatů 13.2 byl sice jednou z probíraných možností, ale nezdálo se, že by vedla k jasnému výsledku, natož aby se dalo tvrdit "a asi se ho do vánoc dočkáme". Mimochodem, právě problémy s third party moduly jsou asi nejvýraznějším argumentem proti takovému kroku.

[lertimir]

Aha, já myslel, že tu změnu provedou ve vydaném releasu. A odhad že měsíc by mohl stačit, aby změnu jádra doladili. Tak to bude na ruční práci.

[mimi.vx]

Factory uz neni .. Je Tumbleweed a je dost stabilni i pro bezne pouziti

[Michal Kubeček]

Factory je pořád to, co byla dosud. Ten nápad, že se z Factory udělá rolling distribuce pro praktické nasazení, měl naštěstí jen krátké trvání. Pak jim došlo, že je k tomu vhodnější použít Tumbleweed a Factory ponechat původnímu účelu.