Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Vývoj zavaděče LILO (LInux LOader) byl minulý měsíc obnoven. Byl vytvořen projekt LILO na serveru Alioth. LILO tak má novou domovskou stránku. Byla vydána nová stabilní verze 23.0, do které byly začleněny záplaty a vylepšení především z linuxových distribucí Debian, OpenSUSE a Fedora.
Tiskni Sdílej:
find /boot/grub/stage1
(pokud vím, můžu přeskočit)
root (hdX,X)
setup (hdX,X)
Jak udělám takovou triviální věc v GRUB2?
GRUB 2 je komplikovaný moloch s hromadou skriptů.Stačí je nepoužívat :), pak je GRUB2 úplně stejně jednoduchý a primitivní jako GRUB1. Skripty generující grub config se používaly už v GRUB1 běžně v distribucích, GRUB2 pouze přinesl distribucím jednotný systém přepisu configu a detekce nainstalovaných OS.
# # DO NOT EDIT THIS FILE # # It is automatically generated by /usr/sbin/grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub #Toť celé kouzlo.
/etc/default/grub
prakticky nic není, jen pár hovadinek./etc/grub.d/*
ve formě init-like scriptů. Ano, jasně, dají se editovat, a nakonec se tím člověk probere, ale prosím vás, má tohle člověk zapotřebí?
Mě by zajímalo, kdo z vás, zastánců Grub 2, skutečně šel do těch konfiguráků a zkoušel tam něco nastavit.Tak já předpokládám, že všichni... ale já osobně jsem to nastavoval několikrát.
Vše ostatní je v /etc/grub.d/* ve formě init-like scriptů.Ale vůbec ne, s init skripty to je podobné snad jen tím, že tam jsou shell skripty. Ale pokud nechceš, nemusíš je vůbec používat. Konfigurační soubor je v /boot a je téměř totožný s tím pro GRUB1. Distribuce vždycky používaly různé metody jak do konfigurace grubu nacpat updatovaná jádra a detekované ostatní OS. Najednou se tato sada skriptů objevila přímo v distribuci GRUBu a je zle. Vždyť je to technicky na chlup to samé, jen je to sjednocené a přenesené do grub.d ze speciálních skriptů v různých umístění. Vždycky můžeš upravit "custom", kam se přímo napíše kousek konfigurace, který by si dřív psal do grub.conf za ty speciální komentářové značky, co určují, kde končí automaticky generovaná část. Holt místo komentářových značek to máš rozseklé do několika souborů.
Vždyť ten Grub 2 dělá prakticky to samé jako Grub 1, ale za cenu mnohem složitějšího a více "bloated" nastavení...Samotná konfigurace je prakticky totožná. Pouze pokud využíváš automatického generování, je potřeba vědět, že máš statické položky cpát do custom souboru v grub.d a výsledný konfig nechat generovat, abys tam měl zároveň i ty položky spravované balíčkovacím systémem a automaticky detekované operační systémy.
Ale vzhledem k tomu, že Grub 2 nic moc nevylepšuje, tak mi to přijde jako hovadina...Pokud vím, tak Grub 2 umí nabootovat věci, které Grub 1 nikdy neuměl. Například umí bootovat z LVM. Pokud tuto vlastnost nevyužiješ, dobře, ale nemá smysl tvrdit, že nic nepřináší.
Samotná konfigurace je prakticky totožná. Pouze pokud využíváš automatického generování, je potřeba vědět, že máš statické položky cpát do custom souboru v grub.d a výsledný konfig nechat generovat, abys tam měl zároveň i ty položky spravované balíčkovacím systémem a automaticky detekované operační systémy.Hmmm... čili musím myslet na to, jakým způsobem moje nastavení bude interagovat s balíčkovačem...
Pokud vím, tak Grub 2 umí nabootovat věci, které Grub 1 nikdy neuměl. Například umí bootovat z LVM. Pokud tuto vlastnost nevyužiješ, dobře, ale nemá smysl tvrdit, že nic nepřináší.Z LVM "umí" nabootovat u Grub 1. Umí je v uvozovkách, protože on to sice neumí, ale není to problém
Hmmm... čili musím myslet na to, jakým způsobem moje nastavení bude interagovat s balíčkovačem...Nemusíš, stačí umět používat ten balíčkovač. To je právě rozdíl od Grubu 1, který bez speciálních skriptů neuměl reagovat na nově přidaná jádra apod.
Takže si stejně tu část, kterou tvoří balíčkovač budu muset prostudovat...Můžeš, pokud tě zajímá vývoj, nebo pokud testuješ nějaké vývojové verze distribucí. Nemusíš, pokud používáš rozumnou distribuci, kde jsou ty skripty napsané správně... A dokonce to nemusíš používat vůbec a můžeš konfigurovat ve stylu starého grubu. Pořád se grub řídí jedním konfiguračním souborem. Přepisovací program lze i úplně zablokovat, například tím, že mu odebereš execute bit.
Z LVM "umí" nabootovat u Grub 1. Umí je v uvozovkách, protože on to sice neumí, ale není to problémProsím česky na mě. Já jsem psal, že chápu, že takovou funkcionalitu nepotřebuješ nebo nechceš využívat. Uvedl jsem to jen jako příklad něčeho, co starý grub neumí a nový ano. Vypadalo to, že píšeš, že nic nového neumí.
Nemusíš, stačí umět používat ten balíčkovač.Takové Ubuntu generuje na základě balíčkovače i názvy položek. To se pak edituje dost špatně...
To je právě rozdíl od Grubu 1, který bez speciálních skriptů neuměl reagovat na nově přidaná jádra apod.A co
/boot/vmlinuz
? Kolik lidí skutečně potřebuje bootovat několik různých kernelů? A propos, když už někdo má rozumný důvod bootovat různé kernely (i.e. rozumí tomu), tak pro něj správné nastavení menu.lst
není problém...
Já jsem psal, že chápu, že takovou funkcionalitu nepotřebuješ nebo nechceš využívat. Uvedl jsem to jen jako příklad něčeho, co starý grub neumí a nový ano. Vypadalo to, že píšeš, že nic nového neumí.Napsal jsem, že prakticky nic nového nepřináší. Čili něco v tom changelogu sice určitě bude, ale nic zásadního. Z patra si vzpomínám na možnost použití vlastního fontu a lepší uzpůsobení grafiyk (hola, LILO ). Pohodlnější LVM může být další věc. Má pointa byla v tom, že mi nepřijde smysluplné vyměnit takovéhle spíš velmi jemné vylepšení za složitý systém konfigurace.
Neumělo to strojové generování konfigurace – lidi nadávali.
Umělo to strojové generování konfigurace, ale nedělalo to dobrotu s jinými generátory a ruční konfigurací – lidi nadávali.
Konfigurátory nekolidují, ale za jistou cenu – lidi nadávají.
Až nastane konec světa – lidi budou nadávat.
/boot/grub/grub.cfg #obecné nastavení grubu - cesta k /boot, vzhled, timeout apod.
/boot/grub/skel/conf #výchozí conf, který balíčkovač nakopíruje při tvorbě dalšího jádra
/boot/kernel/26/34/conf #jméno položky (s proměnných jako jméno, verze apod.), kernel options, atd.
/boot/kernel/26/34/initrd #initrd
/boot/kernel/26/34/vmlinuz #jádro
/boot/kernel/26/34-ice/{conf,initrd,vmlinuz} #dtto
/boot/kernel/26/35-rc3/{conf,initrd,vmlinuz} #dtto
/boot/other/.../conf #pro widle, masox, atd..
Neříkám, že nutně přesně takhle, ael v podobné filosofii. Když vytvoříš nového uživatele, tak se taky vytvoří /home/cosi
, /home/cosi/.bashrc
, atd., s jádry to může být podobné. Čili nějak v téhle filosofii. Přijde mi to o dost rozumnější než nějaké podivné dsitribučně-specifické skripty v /etc/grub.d/*
vsetci slackwaraci su stastny...... tu v slackware LILO je bezna vec...
Oukej, takže vyžeru pro jistotu flame ohledně LILO vs GRUB vs GRUB2 dopředu
Osobně LILO používám od dob mého používání Slackware (a vlastně i na Mandrake předtím) a nemohu si ho vynachválit na notebooku. Je to bootloader jednoduchý na konfiguraci, nedělá zbytečné věci, když to po něm uživatel nechce (tzn. nemá svůj vlastní FS driver) a obecně mi přijde nejrychlejší.
S příchodem Debianu jsem (po Gentoo) rezignoval na konfiguraci vlastních kernelů a přešel tak na Grub (protože lilo je asi nejhůře podporovaný loader na Debianu, co se týče automatického "updatu" image linků v konfiguraci). Konfigurák to pořád pochopitelný mělo, vypadalo to taky celkem dobře, takže "no big deal".
Pak přišel Grub2 a já šílel nad konfigurací, ale později jsem pochopil, jak automatizace může být geniální. Důležitým krokem je uvědomit si, že Grub2 nemá být bootloaderem, jako LILO (tzn. snadno použitelný i pro vlastní 10MB linux distribuci), Grub2 je prostě součást systému. Může sice mít jeden konfigurační soubor, ale tím ztrácí řadu výhod.
U debianu je základní Grub2 konfigurace v /etc/default/grub (timeout, default, ..), žádnou jinou konfiguraci prostě nenajdete, protože neexistuje! Je sice možnost umístit si vlastní obrazy do /etc/grub.d/40_custom, ale tím to končí. V tom je ta genialita. Bere to uživateli 100% kontrolu nad finálním grub.cfg, ale přidává daleko snadnější cestu (pro distribuce) updatu kernel image.
Má to výhodu i pro uživatele. Nedávno jsem přecházel z jednoho disku na RAID1 na pracovní stanici. U "starých" bootloaderů by to bylo na několik restartů, než bych našel správnou konfiguraci LILO, která nabootuje (naposled byl problém s nalezením root= , lilo prostě nahrálo špatný major,minor), ale u Grub2 (v integraci do Debianu) mi stačilo
Jistě, celé tohle by se dalo automatizovat i přes LILO, ale stejně tak Grub2 sám o sobě je jen slabým rozšířením Grub1 a nemá složitou konfiguraci, to jen distributoři dělají věci jako /etc/grub.d/.
Závěrem - pokud používáte jen vlastnoručně nakonfigurované kernely, LILO "is the way to go". Pokud na to kašlete a používáte distribuční, netrapte se tím, automatizace generace konfiguráku je daleko robustnější, než u Grub1. Navíc jde odstranit "(single)" řádky pomocí GRUB_DISABLE_LINUX_RECOVERY="true" v /etc/default/grub. Jen jedna věc mě u Grub2 na serveru štve - neumí serial+vga konzole zároveň, jako to umí LILO.
... a pokud vytvoříte delší post, než já, tak mě fakt nakrknete
neumí serial+vga konzole zároveň
Tak to vypadá, že tahle regrese už byla opravena, a to celkem nedávno.
Je to bootloader jednoduchý na konfiguraci, nedělá zbytečné věci, když to po něm uživatel nechce (tzn. nemá svůj vlastní FS driver)A když zapomeneš spustit "lilo" po aktualizaci jádra, jsi v prdeli a šup pro LiveCD. Pěkně děkuju.
V tom je ta genialita. Bere to uživateli 100% kontrolu nad finálním grub.cfg, ale přidává daleko snadnější cestu (pro distribuce) updatu kernel image.Pěkně děkuju, ale já bych si s dovolením kontrolu nad finálním menu.lst ponechal a distribuce ať mi do toho hrabe co nejmíň. Stejně to většinou udělá blbě.
Má to výhodu i pro uživatele. Nedávno jsem přecházel z jednoho disku na RAID1 na pracovní stanici. ...To není žádná výhoda, protože úplně stejně to jde udělat se starým GRUBem.
A když zapomeneš spustit "lilo" po aktualizaci jádra, jsi v prdeli a šup pro LiveCD. Pěkně děkuju.Již od úsvitu časů se doporučuje upgradovat stylem
mv /boot/bzImage /boot/bzImage.old cp arch/.../boot/bzImage /bootCož má za následek že "bzImage.old" okupuje na disku stále stejné místo, takže když zapomenu dát lilo tak se prostě nabootuje "old". Pokud upgrade dělá distribuce (balíčkovač) tak může lilo pustit za mě místo toho aby o tom jen kecal (jak to dělá např. pacman).
Naprostý souhlas: proč se místo toho neudělá hromada skriptů která pochopí a pak co nejméně invazivně upraví lilo.conf nebo menu.lst. Takové skripty existují taky od počátku časů protože UNIX je založen na textových souborech srozumitelných pro lidi!V tom je ta genialita. Bere to uživateli 100% kontrolu nad finálním grub.cfg, ale přidává daleko snadnější cestu (pro distribuce) updatu kernel image.Pěkně děkuju, ale já bych si s dovolením kontrolu nad finálním menu.lst ponechal a distribuce ať mi do toho hrabe co nejmíň. Stejně to většinou udělá blbě.
Bere to uživateli 100% kontrolu nad finálním grub.cfg, ale přidává daleko snadnější cestu (pro distribuce) updatu kernel image.Jenom pokud si ji vzít nechá, jinak lze konfigurovat prakticky stejně jako GRUB1.