Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
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: