V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 1.8.0 svobodného multiplatformního softwaru pro konverzi video formátů HandBrake (Wikipedie). Přehled novinek v poznámkách k vydání na GitHubu. Instalovat lze také z Flathubu.
Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
mkinitcpio -k 3.2.12-1-ARCH -g /boot/initramfs-linux.imgDíky
VERB="-q" get_uuid() { sed -ne "\%^UUID=[-0-9a-f]\+\s\+$1\s%s/UUID=\([-0-9a-f]\+\)\s.*/\\1/p" < /etc/fstab } # backup root partition backup_root() { DEST=$1 if grep -q $DEST /proc/mounts ; then : ; else echo "Backup patition $DEST not mounted" exit 1 fi rsync $VERB -x -a --inplace --delete --delete-excluded --exclude-from /rsync-exclude / "$DEST" ROOT_UUID=`get_uuid /` BACKUP_ROOT_UUID=`get_uuid "$DEST"` # replace root partition in backup fstab, comment out backup root and swap sed -e " s%^UUID=$ROOT_UUID%UUID=$BACKUP_ROOT_UUID% t s%\(UUID=$BACKUP_ROOT_UUID.*\)%\#\\1% t s%\([^\#].*\sswap\s.*\)%\#\\1% t " < "$DEST"/etc/fstab > "$DEST"/etc/fstab.edited mv "$DEST"/etc/fstab.edited "$DEST"/etc/fstab sed -e " s%$ROOT_UUID%$BACKUP_ROOT_UUID% t " < "$DEST"/boot/grub/grub.cfg > "$DEST"/boot/grub/grub.cfg.edited mv "$DEST"/boot/grub/grub.cfg.edited "$DEST"/boot/grub/grub.cfg } backup_root /mnt/root-backup
Dobrý den. Dle mých zkušeností není UUID úplně optimální. Jak řešíte když je UUID zapsáno v initrd ? Respektive jak initrd přegenerujete, když nemáte po ruce funkční systém se stejným jádrem? Zatím jsem si na tom několikrát úspěšně vylámal zuby. děkujiJá tak úplně netuším v čem je problém, ani jsem na něj nikdy nenarazil.
snímek souborového systémuTohle se mi jednou vymstilo – systém pak po restartu nabootoval ze snapshotu místo z původního oddílu, docela průšvih… UUID je potřeba změnit resp. udržovat jedinečné.
Emil-II:~# ll /dev/disk/by-id/ | grep wwn lrwxrwxrwx 1 root root 9 Apr 24 20:24 wwn-0x50014ee0571cb58b -> ../../sdb lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x50014ee0571cb58b-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Apr 24 20:24 wwn-0x50014ee057e7e8e6 -> ../../sdc lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x50014ee057e7e8e6-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc -> ../../sda lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part3 -> ../../sda3 lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part5 -> ../../sda5 lrwxrwxrwx 1 root root 10 Apr 24 20:24 wwn-0x5e83a97f52f3f9cc-part6 -> ../../sda6 Emil-II:~#
Příklad výpisu:Výpisu čeho (jakého programu)? Věnovat se GRUBU Legacy je škoda. Jednak začíná být obsolete, druhak o něm už toho bylo napsáno moc a bylo by lepší popsat GRUB 2.
V "archaických časech" jsem LILO rovněž používal a pamatuji si, že následný přechod na GRUB mi přinesl více nevýhod, než-li výhod...
lilo
se umí chrootnou samo (parametr -r
), zmatek může být jenom v tom, jak se jmenují zařízení v /dev
a jak vypadají oblasti disků v /proc
(ale jejich absenci lilo
skousne).
PS: Když to srovnám s ostatními zavaděči Linuxu na ne-PC platformách, kde stačí většinou jen připravit jádro v učitém formátu a pak ho nahrát do první oblast bootovacího média, tak je i lilo
složité
jak se s tím Airbusem, pardon grubem, vlastně lítáÚplně pro BFU to sice není, ale vzhledem k tomu, že tam funguje doplňování tabulátorem, tak se dá i s celkem minimálními znalostmi nabootovat, ten GRUB ti hodně pomáhá.
Grub mi ani tak nevadí, vadí mi, že pokud chci používat nějakou moderní distribuci, nemám možnost volby.Nevím, jestli je moje distribuce dostatečně moderní, ale někde jsem tam viděl volbu "pokračovat bez zavaděče" -- a pak tě to nijak neomezuje a ten systém si nabootuj, jak chceš -- někdo třeba bootuje v KVM přímo jádro bez zavaděče, někdo si tam dá LILO...
bzlilo
, kde se obraz jádra (pojmenovaný vmlinuz
) s případným initramdiskem překopíroval do /boot
(nebo do /
a symlinknul do /boot
) a pak se zavolalo lilo
. Dnes to jde teoreticky rešit přes cíl install
a skript /bin/installkernel
, který to automaticky spustí po překladu.
Takže pokud si často překládáte jádro, stačí si připravit tento skript a make
spouštět s parametrem install
.
/
, má ovladač v jádře. Protože nepoužívám initramdisk/initramfs, tak jádro před pokusem o jeho přijení vidí jen jediný disk a tudíž se nemůže poplést. Bohužel to u nových desek, kde je jen jediný SATA řadič, nejde použít.
Ve světě PC BIOS umí sdělit, ze kterého zařízení se bootovalo. Spolehlivě to ale funguje jen při bootu z ATA. LILO si dokonce při instalaci stěžuje, když se jej pokusíte nainstalovat do MBR jiného disku. Mám pocit, že UEFI je v tomto ještě lepší.
Údaj o bootu je ale k ničemu, když kořenový systém je ve virtuálním zařízení (například LVM). Pak se stejně musí použít nějaké umělé číslování.
za root zvolit partition na tom disku, z ktereho zavadec natahl jadro.Ale jakou partition?
za root zvolit partition na tom disku, z ktereho zavadec natahl jadroA o tom má jádro rozhodnout jako jak? Jádro je spustitelný blok kódu, který někdo (zavaděč) natáhne do paměti a spustí/nastartuje instrukcí JMP (V podstatě je to úplně obyčejný program akorát v reálném módu s exkluzivním během — teda ještě ho nikdo neplánuje, plánuje se samo, ale až na pár takových drobností je to úplně obyčejný ELF). Jádro neví nic o tom jak to vypadalo v systému před tím než bylo spuštěno. Samo si detekuje periferní zařízení na stroji na kterém bylo spuštěno a až má práci hotovou, tak je postaveno před nelehký úkol: Určit jak pokračovat. Většinou se to dělá tak, že pokračování nechá na Early User-Space a ten si dělá co chce (ten musí být v systému vždycky) a nech si pokračuje jak chce ten kdo si ho napsal. Disky a pole a takové věci jsou specifikum architektury x86. Na jiných architekturách může jádro klidně ležet pouze jako blok RAW-dat od adresy X do adresy Y na nějakém zařízení (to nemusí být ani disk), jiný systém ho natáhne do paměti a spustí jako běžný ELF (a nemusí to být ani jiná architektura — DOS-Grub pamatuje kdo?). Jak by mělo rozhodnout v takovém případě? Jádro se nepoužívá jen na Hi-Tech serverech s polema a loukama, ale jádro musí zůstat univerzální.
A o tom má jádro rozhodnout jako jak? Jádro je spustitelný blok kódu, který někdo (zavaděč) natáhne do paměti a spustí/nastartuje instrukcí JMP (V podstatě je to úplně obyčejný program akorát v reálném módu s exkluzivním během — teda ještě ho nikdo neplánuje, plánuje se samo, ale až na pár takových drobností je to úplně obyčejný ELF). Jádro neví nic o tom jak to vypadalo v systému před tím než bylo spuštěno.To je otazka boot protokolu mezi zavadecem a jadrem. Treba Multiboot predava informaci o disku a partition (i kdyz ve forme jeho BIOS identifikatoru, takze by mozna nebylo jednoduche z nej zjistit skutecny disk). Standardni linuxovy x86 boot protokol to asi (jak ted koukam) nepredava. Jak je to u jinych boot protokolu (treba OFI, UEFI) netusim, ale prekvapilo by mne, kdyby to tam nebylo.
Disky a pole a takové věci jsou specifikum architektury x86.No a? VGAcon je take vicemene x86 specifikum, a presto se defaultne hojne pouziva.
Tiskni Sdílej: