Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
Byl představen ICT Supply Chain Security Toolbox, společný nezávazný rámec EU pro posuzování a snižování kybernetických bezpečnostních rizik v ICT dodavatelských řetězcích. Toolbox identifikuje možné rizikové scénáře ovlivňující ICT dodavatelské řetězce a na jejich podkladě nabízí koordinovaná doporučení k hodnocení a mitigaci rizik. Doporučení se dotýkají mj. podpory multi-vendor strategií a snižování závislostí na vysoce
… více »Nizozemský ministr obrany Gijs Tuinman prohlásil, že je možné stíhací letouny F-35 'jailbreaknout stejně jako iPhony', tedy upravit jejich software bez souhlasu USA nebo spolupráce s výrobcem Lockheed Martin. Tento výrok zazněl v rozhovoru na BNR Nieuwsradio, kde Tuinman naznačil, že evropské země by mohly potřebovat větší nezávislost na americké technologii. Jak by bylo jailbreak možné technicky provést pan ministr nijak nespecifikoval, nicméně je známé, že izraelské letectvo ve svých modifikovaných stíhačkách F-35 používá vlastní software.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 162 (pdf).
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report za rok 2025 s klíčovými daty o vývoji domény .CZ. Na konci roku 2025 bylo v registru české národní domény celkem 1 515 860 s koncovkou .CZ. Průměrně bylo měsíčně zaregistrováno 16 222 domén, přičemž nejvíce registrací proběhlo v lednu (18 722) a nejméně pak v červnu (14 559). Podíl domén zabezpečených pomocí technologie DNSSEC se po několika letech stagnace výrazně
… více »Google představil telefon Pixel 10a. S funkci Satelitní SOS, která vás spojí se záchrannými složkami i v místech bez signálu Wi-Fi nebo mobilní sítě. Cena telefonu je od 13 290 Kč.
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Fedora 43 Asahi Remix s KDE Plasma už funguje na M3. Zatím ale bez GPU akcelerace. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Red Hat představil nový nástroj Digital Sovereignty Readiness Assessment (GitHub), který organizacím umožní vyhodnotit jejich aktuální schopnosti v oblasti digitální suverenity a nastavit strategii pro nezávislé a bezpečné řízení IT prostředí.
BarraCUDA je neoficiální open-source CUDA kompilátor, ale pro grafické karty AMD (CUDA je proprietární technologie společnosti NVIDIA). BarraCUDA dokáže přeložit zdrojové *.cu soubory (prakticky C/C++) přímo do strojového kódu mikroarchitektury GFX11 a vytvořit tak ELF *.hsaco binární soubory, spustitelné na grafické kartě AMD. Zdrojový kód (převážně C99) je k dispozici na GitHubu, pod licencí Apache-2.0.
dd if=/dev/sda1 of=/shares/internal/backup
Chtel jsem se posleze vratit k puvodnimu stavu takze jsem provedl - opet dle navodu :
dd if=/shares/internal/backup of=/dev/sda1
Pote co to dobehlo jsem jeste provedl
# e2fsck -yf /dev/sda1
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 9508/368000 files (0.1% non-contiguous), 71220/734944 blocks
Jenze pak jsem najednou skoncil s read-only pripojenym systemem :
<2>EXT3-fs error (device md1): ext3_readdir: bad entry in directory #289136: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
<3>Aborting journal on device md1.
<2>EXT3-fs error (device md1): ext3_readdir: bad entry in directory #289181: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
<2>ext3_abort called.
<2>EXT3-fs error (device md1): ext3_journal_start_sb: Detected aborted journal
<2>Remounting filesystem read-only
No a po pravde moc nevim co s tim ted, zarizeni totiz bezi jako raid1 dvou disku a mam pocit ze v tom je problem.
Jeste prikladam vypis fstab
# /etc/fstab: static file system information.
#
# < file system> < mount pt> < type> < options> < dump> < pass>
/dev/root / ext3 rw,noauto,noatime 0 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts defaults,gid=5,mode=620 0 0
sys /sys sysfs defaults 0 0
/dev/md2 none swap defaults 0 0
/dev/md3 /var ext3 defaults,noatime 0 2
/dev/md4 /shares/internal ext3 defaults,noatime 0 2
Kdyby mi nekdo poradil jak SPRAVNE udelat obnovu systemu z te image budu moc rad.
Deiky predem K
# cat /proc/mdstat
Personalities : [linear] [raid1]
md1 : active raid1 sdb1[0] sda1[1]
2939776 blocks [2/2] [UU]
md2 : active raid1 sdb2[0] sda2[1]
104320 blocks [2/2] [UU]
md3 : active raid1 sdb3[0] sda3[1]
987904 blocks [2/2] [UU]
md4 : active linear sdb4[1] sda4[0]
968655104 blocks 64k rounding
Toto je stzav pote co jsem prehral zalohu na /dev/sda1 a pak spoustel nejake ty e2fsck
Chtel jsem se posleze vratit k puvodnimu stavu takze jsem provedl - opet dle navodu :
dd if=/shares/internal/backup of=/dev/sda1
Pote co to dobehlo jsem jeste provedl
Z jakého systému to běželo ve chvili restaurace? ta záloha systému ze systému, který běži by nemusela dopadnou hůře, než situace kdy by vám vypadlo
napájení a byl jste bez UPS a to systém často přežije i když se opravuje. Ale pokud tohle znamená, že vám systém běžel na /dev/sda1 a vy jste
mu začal přepisovat jeho partišnu, tak se mu to hodně nemuselo líbit.
Zkusil bych nabootovat z live distribuce, připojit do ni to raid pole, a prohlédnout to z ní.

ls -l /dev/rootZdar Max
# ls -l /dev/root
/dev/root: No such file or directory
a jeste
# mount
/dev/root on / type ext3 (ro,noatime,data=ordered)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sys on /sys type sysfs (rw)
/dev/md3 on /var type ext3 (rw,noatime,data=ordered)
/dev/md4 on /shares/internal type ext3 (rw,noatime,data=ordered)
usbfs on /proc/bus/usb type usbfs (rw)
Me by hlavne zajimalo co s tim ted. Mam tu image vytvorenou jak jsem popisoval na zacatku (vytvorenou za behu systemu). Lze s ni neco podniknout nebo mam radsi cely system udelat uplne znovu ? (coz je bohuzel dost pracne a zdlouhave)
Nebo lze - treba po pripojeni toho disku ktery chci obnovit na externi pocitac - s tou image system obnovit ?
at se zachova formatovani...
i kdybys to vzkrisil, doporucil bych to prelejt nacisto...
# fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 4 369 2939895 fd Linux raid autodetect
/dev/sda2 370 382 104422+ fd Linux raid autodetect
/dev/sda3 383 505 987997+ fd Linux raid autodetect
/dev/sda4 506 60801 484327620 fd Linux raid autodetect
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 4 369 2939895 fd Linux raid autodetect
/dev/sdb2 370 382 104422+ fd Linux raid autodetect
/dev/sdb3 383 505 987997+ fd Linux raid autodetect
/dev/sdb4 506 60801 484327620 fd Linux raid autodetect
V cem je hlavni zadrhel ? Ze ta image byla vytvarena ze systemu za behu nebo ze jsem se ji snazil za behu obnovit ?
A kdybych zkousel obnovit ten system z /dev/sda1 popripojeni jednotek na jiny pocitac jak mam postupovat ? System je udelany jako raid0 - strip
V cem je hlavni zadrhel ? Ze ta image byla vytvarena ze systemu za behu nebo ze jsem se ji snazil za behu obnovit ?V tom, že byla vytvářená za běhu. dd totiž postupovalo od začátku ke konci disku, ale systém během zálohy dělal změny - takže například supernode není konzistentní se skutečným obsahem disku, protože po záloze supernode se na konci disku něco změnilo. Když už potřebuješ systém zálohovat za běhu, zálohuj na úrovni souborů, ne na úrovni souborového systému. Pokud to uděláš rsyncem a ten rsync spustíš víckrát po sobě (aby se během jeho běhu provedlo co nejméně změn), není problém systém obnovit - maximálně si stěžují některé programy, že nebyly korektně ukončeny, ale systém bez problémů naběhne.
fsck /dev/md1NN
#Záloha : sfdisk -d /dev/sda > sda_table_backup # obnova : sfdisk /dev/sda < sda_table_backupObnova by pak probíhala tak, že by jsi obnovil tabulku rozdělení disků :
sfdisk /dev/sda < sda_table_backuppartition naformátoval :
mke2fs -J /dev/sda1 mke2fs -J /dev/sda2 mke2fs -J /dev/sda3 ...Obnovil na ní data a ve finále zapsal boot loader.
Tiskni
Sdílej: