Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
fdisk -l /dev/sdb Disk /dev/sdb: 640.1 GB, 640133946880 bytes 255 heads, 63 sectors/track, 77825 cylinders, total 1250261615 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xd3d9838a Device Boot Start End Blocks Id System /dev/sdb1 * 63 86829055 43414496+ 7 HPFS/NTFS/exFAT /dev/sdb2 86829056 143017983 28094464 f W95 Ext'd (LBA) /dev/sdb3 143017984 1250261614 553621815+ 8e Linux LVM /dev/sdb5 86831104 143017983 28093440 7 HPFS/NTFS/exFATa měl by se tedy chovat normálně. b1 je normál, b2 extendid, b5 je uvnitř extended logická, a b3 je LVM umístěná za b2. Ale v yastu se objeví, že je něco vytvořeného v /dev/mapper
ls /dev/mapper/ control pdc_bijaajjed pdc_bijaajjed-part1 pdc_bijaajjed-part2 pdc_bijaajjed-part5viz i obr s1. Oddíly 1, 2 a 5 odpovídají těm b1, b2 a b5. b3 chybí. (a zkusil jsem přes gparted jinou konfiguraci a to b2 a b5 na konec disku a b3 před něj. Pak nebylo v mapper b5). Ty oddíly v mapper namapovat jdou, přímo oddíly disku ne.
mount /dev/sdb5 /windows/d fuse: mount failed: Device or resource busy caras-galathon:~ # mount /dev/mapper/pdc_bijaajjed-part5 /windows/d caras-galathon:~ #S tím bych se třeba i smířil, ale nejsem schopen se dostat na LVM.
vgchange -a y data device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument 2 logical volume(s) in volume group "data" now activeJakýkoliv pokus se dostat na A je to součást téhle konkrétní instalace. Není to v HW. Protože když vyndám disk a přemístím ho do USB docku na jiném kompu tak je OK, stejně tak je OK a má normální oddíly, když nabootuji jiný systém. Zkusil jsem partedmagic se kterým jsem dělal úpravy a i live openSUSE 12.3 KDE vidí disk s normálními oddíly. A moje otázka je, jak se toho mapování zbavit? A také porozumět, co se vlastně děje.
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
dd if=/dev/null of=/dev/sdb abych smáznul vše na disku a když jsem pak udělal úpravy dělení a instalaci XP zcela jinde a zapojil do systému tak se to jako DMRAID objevilo znovu. A se stejným mapper jménem, pokud si to dokážu pamatovat. Na disku ta informace není.)
mdadm --examine /dev/sdb /dev/sdb: MBR Magic : aa55 Partition[0] : 86828993 sectors at 63 (type 07) Partition[1] : 56188928 sectors at 86829056 (type 0f) Partition[2] : 1107243631 sectors at 143017984 (type 8e)Nicméně zase to nechápu dále. fdisk oznámí:
fdisk -l /dev/sdb Disk /dev/sdb: 640.1 GB, 640133946880 bytes 255 heads, 63 sectors/track, 77825 cylinders, total 1250261615 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xd3d9838a Device Boot Start End Blocks Id System /dev/sdb1 * 63 86829055 43414496+ 7 HPFS/NTFS/exFAT /dev/sdb2 86829056 143017983 28094464 f W95 Ext'd (LBA) /dev/sdb3 143017984 1250261614 553621815+ 8e Linux LVM /dev/sdb5 86831104 143017983 28093440 7 HPFS/NTFS/exFATnicméně ten superblok jsem jistě nedělal. Z nějakého důvodu ho vytvořil systém. A modifikuje to když posouvám oddíly přes gparted. Počáteční boot po přidání disku trval delší dobu, zkusím najít ve starých messages co se dělo.
mdadm --zero-superblock /dev/sdbVerzi metadat zjistíš pomocí :
mdadm --examine /dev/sdb mdadm --examine /dev/sdb1 mdadm --examine /dev/sdb2 mdadm --examine /dev/sdb3 mdadm --examine /dev/sdb5
Osobně jsem to nikdy neřešil.
Zdar Max# mdadm --examine /dev/sdb /dev/sdb: MBR Magic : aa55 Partition[0] : 86828993 sectors at 63 (type 07) Partition[1] : 56188928 sectors at 86829056 (type 0f) Partition[2] : 1107243631 sectors at 143017984 (type 8e) :~ # mdadm --examine /dev/sdb1 /dev/sdb1: MBR Magic : aa55 Partition[0] : 1953701989 sectors at 1953133940 (type 73) Partition[1] : 544433526 sectors at 2691459872 (type 75) Partition[2] : 658734 sectors at 1818575915 (type 2b) Partition[3] : 48809 sectors at 2541944832 (type 00) caras-galathon:~ # mdadm --examine /dev/sdb2 /dev/sdb2: MBR Magic : aa55 Partition[0] : 56186880 sectors at 2048 (type 07) :~ # mdadm --examine /dev/sdb3 mdadm: No md superblock detected on /dev/sdb3. :~ # mdadm --examine /dev/sdb5 /dev/sdb5: MBR Magic : aa55 Partition[0] : 1769239328 sectors at 1702128245 (type 74) Partition[1] : 1126200165 sectors at 1990225003 (type 74) Partition[2] : 10 sectors at 225207620 (type 41) Partition[3] : 48553 sectors at 2541944832 (type 00)Ale to jsou dost hausnumera.
11.7.2013 13:25
nodmraid pri bootu. Tim se da nabehnout s vypnutym dm raidem a pritom se nemeni zadna data, takze se disk neposkodi.
# dmsetup table pdc_bijaajjed-part1: 0 86828993 linear 253:0 63 pdc_bijaajjed: 0 1250260608 linear 8:16 0 pdc_bijaajjed-part5: 0 56186880 linear 253:0 86831104 data-swap: data-data: pdc_bijaajjed-part2: 0 2 linear 253:0 86829056vypsalo co dmraid vidí. A
# dmsetup remove pdc_bijaajjed-part1 # dmsetup remove pdc_bijaajjed-part2 # dmsetup remove pdc_bijaajjed-part5 # dmsetup remove pdc_bijaajjedsmazaly informace o DMRAIDu. Nyní se k oddílům dostanu (ty data-data a data-swap jsou LV na LVM na /dev/sdb3). Na disku již žádné info není. Ale
# ll /dev/mapper/ total 0 crw------- 1 root root 10, 236 Jul 10 13:50 control lrwxrwxrwx 1 root root 7 Jul 12 21:31 data-data -> ../dm-5 lrwxrwxrwx 1 root root 7 Jul 12 21:28 data-swap -> ../dm-4 brw-r----- 1 root disk 253, 0 Jul 10 13:50 pdc_bijaajjedještě pořád pdc drive má. Po rebootu už ne. Vyřešeno.
dmraid -r -E může nadělat víc škody, než užitku, jak jsem se krutě poučil v této diskuzi.
Tiskni
Sdílej:
