Open source software pro úpravu digitálních fotografií LightZone (Wikipedie) byl vydán v nové verzi 5.0.0. LightZone je dnes k dispozici pod licencí BSD. Původně se jednalo o proprietární software vyvíjený společností Light Crafts. Ta v prosinci 2012 souhlasila s uvolněním zdrojových kódů jako open source [Wayback Machine].
Byla vydána verze 0.84 telnet a ssh klienta PuTTY (Wikipedie). Podrobnosti v přehledu nových vlastností a oprav chyb a Change Logu.
Microsoft představil Azure Linux 4.0 a Azure Container Linux. Na konferenci Open Source Summit North America 2026 organizované konsorciem Linux Foundation a sponzorované také Microsoftem. Azure Linux 4.0 vychází z Fedora Linuxu. Azure Container Linux je založen na projektu Flatcar. Azure Linux (GitHub, Wikipedie) byl původně znám jako CBL-Mariner.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 165 (pdf).
Byla vydána verze 9.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 informačním videu.
Firefox 151 podporuje Web Serial API. Pro komunikaci s různými mikrokontroléry připojenými přes USB nebo sériové porty už není nutné spouštět Chrome nebo na Chromiu postavené webové prohlížeče.
Byla vydána nová stabilní verze 8.0 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 148. Přehled novinek i s náhledy v příspěvku na blogu.
Ve FreeBSD byla nalezena a opravena zranitelnost FatGid aneb CVE-2026-45250. Jedná se o lokální eskalaci práv. Neprivilegovaný uživatel se může stát rootem.
Společnost Flipper Devices oznámila Flipper One. Zcela nový Flipper postavený od nuly. Jedná se o open-source linuxovou platformu založenou na čipu Rockchip RK3576. Hledají se dobrovolníci pro pomoc s dokončením vývoje (ovladače, testování, tvorba modulů).
Vývojáři Wine oznámili vydání verze 2.0 knihovny vkd3d pro překlad volání Direct3D na Vulkan. Přehled novinek na GitLabu.
--unrestricted príslušnej položke v /boot/grub/grub.cfg.
Debian však pri aktualizácií bežne prepisuje súbor /boot/grub/grub.cfg (na rozdiel od Archlinuxu napríklad), čo pri unattended upgrades je trocha nepríjemné. Ako to máte ošetrené Vy?
Napadá ma možnosť ošéfovať to skriptom, ktorý sa spustí pri generovaní konfiguračného súboru (v podstate ten skript, ktorý do konfiguráku vkladá heslo). Alebo sa na to heslo úplne vykašľať - má toto heslo dnes ešte význam?
Řešení dotazu:
Soubor grub.cfg se nemá editovat protože ho tvoří script update-grub který v Archu standartně není instalován , zde výpis také na archu kde ho ale instalován mám.
which update-grub
/usr/bin/update-grub
cat /usr/bin/update-grub
#!/bin/sh set -e exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
úprava grub.cfg se provádí skrze scripty /etc/default/grub a /etc/grub.d
například mám vypnuté v /etc/default/grub volbu GRUB_DISABLE_OS_PROBER=true pro detekci napříklat osx a windows a naházenou ji mám ručně v souboru /etc/grub/40_custom takto :
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry 'Operační systém Windows 7 a 10' --class windows --class os $menuentry_id_option 'osprober-chain-903E44A03E4480E8' {
savedefault
insmod part_msdos
insmod ntfs
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 903E44A03E4480E8
else
search --no-floppy --fs-uuid --set=root 903E44A03E4480E8
fi
parttool ${root} hidden-
drivemap -s (hd0) ${root}
chainloader +1
}
kde to číslo 903E.... je blokové číslo oddílu
sudo blkid
/dev/sda1: LABEL="RezervovM-CM-!no systM-CM-)mem" UUID="903E44A03E4480E8" TYPE="ntfs" PARTUUID="5a49bc46-01"
/etc/boot/grub vypadá nějak takto
GRUB_DISTRIBUTOR="Arch" GRUB_TERMINAL_INPUT=console GRUB_THEME=/boot/grub/themes/Archxion/theme.txt GRUB_SAVEDEFAULT="true" GRUB_GFXMODE="1024x768" GRUB_GFXPAYLOAD_LINUX=keep GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3 nvidia-drm.modeset=1 vga=0x034d nomodeset video=uvesafb:mode_option=1920×1080-24,mtrr=3,scroll=ywrap" GRUB_CMDLINE_LINUX="" GRUB_PRELOAD_MODULES="part_gpt part_msdos" GRUB_DISABLE_RECOVERY="true" GRUB_DISABLE_SUBMENU=y GRUB_DISABLE_OS_PROBER=true GRUB_DEFAULT=saved GRUB_TIMEOUT=4
Nemám ale zaheslovaný grub ale podle mne to máš nastavovat v těchto souborech /etc/grub.d/* a /etc/default/grub potom ti automatická aktualizace jádra a jiné vytvoří vždy aktuální grub.cfg který bude hodnoty již obsahovat.
Nevím jak vypadají tvé úpravy ale podle mne pokud chceš jít metodou post-install tak uprav script update-grub či update-grub2 a do něj přidej dodatečnou úpravu již vygenerovaného grub.cfg a to obslouží opravu po vygenerování.
update-grub, ale skôr tým, že /boot/grub/grub.cfg bol vlastnený balíčkom a označený ako zálohovaný súbor (čiže sa pri upgrade neprepísal). Čo pozerám, už to tak nie je, ale bol by som za to dal ruku do ohňa.
V Archu tiež treba dávať bacha na to, že nie všetky súbory v /etc/grub.d/ sú zálohované a pri upgrade budú prepísané. Myslel som, že v Debiane to bude podobné, ale čo pozerám, nie je to tak - čiže úprava akéhokoľvek z týchto konfigurákov bude v Debiane v pohode.
Vďaka za nakompnutie... Vlastne mi ide o to, aby položka pre zavedenie najnovšieho jadra bola odomknutá a všetko ostatné uzamknuté. Nejde ani tak o staršie jadrá ako o kadejaké single-user režimy a podobne. Najschodnejšia cesta však asi bude vypnúť generovanie recovery režimov (nikdy som to aj tak nepoužil) a nechať odomknuté všetky položky.
Moje riešenie je zmena v skripte /etc/grub.d/10_linux. Mám pridanú premennú superusers, heslo pre užívateľa root a pridané do sekcie tvorby položiek v premennej CLASS reťazec --unrestricted
Já k tomu přistupuju takhle: Jediné heslo, které GRUBu dávám, je heslo pro LUKS. No a všechny položky, které tam mám, potřebují to heslo, protože všechno je šifrované, samozřejmě i adresář /boot. Ergo nemám důvod vymýšlet nějaké zamykání některých položek a některých zase ne. 
Nebo se tam dá dát ten „shim“, který je podepsaný a funguje i v implicitním striktním režimu. (Tak to má například Fedora.) Ale někde se proslýchá, že soukromé klíče od toho proprietárně striktního režimu nějak unikly a/nebo nejsou bezpečné, takže je asi fakt lepší používat vlastní klíče.
Pokud je ovšem v nějaké UEFI implementaci backdoor nebo jiná neopravená zranitelnost, nepomůže nic.
Tiskni
Sdílej: