abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 02:00 | Bezpečnostní upozornění

Byly zveřejněny (Project Zero, Intel, AMD, Arm) informace o dalších 2 bezpečnostních chybách v procesorech: variantě 3a aneb CVE-2018-3640 - Rogue System Register Read (RSRE) a variantě 4 aneb CVE-2018-3639 - Speculative Store Bypass (SSB). Podrobnosti o chybě CVE-2018-3639 například v příspěvku na blogu Red Hatu. Princip vysvětlen pomocí videa na YouTube.

Ladislav Hagara | Komentářů: 0
včera 19:44 | Zajímavý software

Spolek vpsFree.cz na svém blogu informuje, že přechází z OpenVZ na vpsAdminOS. Distribuce vpsAdminOS je založena na NixOS a not-os. Pokud provozujete OpenVZ Legacy a nevíte co dál, můžete zvážit vpsAdminOS, který je na migraci kontejnerů z OpenVZ připraven.

Ladislav Hagara | Komentářů: 4
včera 10:22 | Komunita

Minulý týden byla ze správce souborů (Files, Soubory, Nautilus) v GNOME odstraněna možnost spouštění aplikací. Po bouřlivé diskusi byla dnes tato možnost do správce souborů vrácena (commit).

Ladislav Hagara | Komentářů: 27
20.5. 22:44 | Nová verze

Ani ne po měsíci vývoje od vydání verze 2.10.0 byla vydána nová verze 2.10.2 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP. Přehled novinek i s náhledy v oznámení o vydání. Opraveno bylo 44 chyb. Novinkou je podpora formátu HEIF (High Efficiency Image File Format) a dva nové filtry.

Ladislav Hagara | Komentářů: 46
20.5. 17:44 | Komunita

SFC (Software Freedom Conservancy) na svém blogu blahopřeje společnosti Tesla k prvnímu kroku k dodržování licence GPL. Tesla ve svých elektromobilech používá svobodný software. Změny ve zdrojovým kódech ale doteď veřejně nezveřejňovala. Změna nastala tento týden. Zdrojové kódy byly zveřejněny na GitHubu. Nejedná se zatím ale o kompletní odpovídající zdrojové kódy (CCS - complete corresponding source).

Ladislav Hagara | Komentářů: 14
19.5. 17:33 | Komunita

Společnost Purism informuje o aktuálním vývoji chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů. Telefon už umí telefonovat. Librem 5 by měl být k dispozici v lednu 2019. Předobjednat jej lze za 599 dolarů.

Ladislav Hagara | Komentářů: 32
19.5. 09:00 | Bezpečnostní upozornění

Společnost Qualys zveřejnila výsledky bezpečnostního auditu procps-ng, tj. balíčku s příkazy free, kill, pgrep, pidof, pkill, pmap, ps, pwdx, skill, slabtop, snice, sysctl, tload, top, uptime, vmstat, w a watch. Nalezeno bylo 7 bezpečnostních chyb (CVE-2018-1120, CVE-2018-1121, CVE-2018-1122, CVE-2018-1123, CVE-2018-1124, CVE-2018-1125 a CVE-2018-1126). Dvě z nich jsou zneužitelné k lokální eskalaci práv. Příslušné záplaty jsou již k dispozici v upstreamu.

Ladislav Hagara | Komentářů: 5
18.5. 06:44 | Nová verze

Byla vydána třiadvacátá alfa verze svobodné historické realtimové strategie 0 A.D. (Wikipedie). Kódový název této nejnovější verze je Ken Wood. Představení novinek v poznámkách k vydání a také na YouTube.

Ladislav Hagara | Komentářů: 3
18.5. 05:55 | Zajímavý článek

Tento týden se v Cambridge ve Velké Británii konal hackfest, který měl za cíl zlepšit výkon na GNOME postavených systémů na slabších počítačích. Hans de Goede například analyzoval spotřebu paměti jednotlivých komponent ve Fedora 28 Workstation na stroji s 2 GB RAM a pomocí kroků popsaných v článku Kde uspořit paměť ve Fedora Workstation na MojeFedora.cz snížil spotřebu paměti z 1,4 GB na 765 MB.

Ladislav Hagara | Komentářů: 10
17.5. 20:55 | Nová verze

Bram Moolenaar oznámil vydání verze 8.1 textového editoru Vim (Vi IMproved). Hlavní novinkou je integrovaný terminál.

Ladislav Hagara | Komentářů: 7
Používáte pro některé služby inetd?
 (34%)
 (24%)
 (42%)
Celkem 137 hlasů
 Komentářů: 4, poslední včera 12:56
    Rozcestník

    Dotaz: Poškození souborového systému nedetekovatelné při bootu pomocí fsck

    8.2.2012 04:27 vasek
    Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Přečteno: 565×
    Ahoj. Systém CentOS 6.2 32-bit. / jako LVM oddíl. VG je na /dev/md1. Při vytváření lvm snapshotu jsem si všiml v dmesg opravy osiřelých inodů. Provedl tedy na souborovém systému RO fsck test a dopadl takto:
    LANG=C e2fsck -n -f /dev/data/system
    e2fsck 1.41.12 (17-May-2010)
    Warning!  /dev/data/system is mounted.
    Warning: skipping journal recovery because doing a read-only filesystem check.
    Pass 1: Checking inodes, blocks, and sizes
    Inodes that were part of a corrupted orphan linked list found.  Fix? no
    
    Inode 394505 was part of the orphaned inode list.  IGNORED.
    Inode 394506 was part of the orphaned inode list.  IGNORED.
    Deleted inode 524293 has zero dtime.  Fix? no
    
    Inode 524294 was part of the orphaned inode list.  IGNORED.
    Inode 524295 was part of the orphaned inode list.  IGNORED.
    Inode 524296 was part of the orphaned inode list.  IGNORED.
    Inode 524297 was part of the orphaned inode list.  IGNORED.
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    Free blocks count wrong (31459038, counted=31459005).
    Fix? no
    
    Inode bitmap differences:  -(394505--394506) -(524293--524297)
    Fix? no
    
    Free inodes count wrong (8039856, counted=8039814).
    Fix? no
    
    
    /dev/data/system: ********** WARNING: Filesystem still has errors **********
    
    /dev/data/system: 29264/8069120 files (0.2% non-contiguous), 796962/32256000 blocks
    
    Touch /forcefsck nezabralo, systém ten soubor "jen" odstranil. Proto jsem si upravil /etc/rc.d/rc.sysinit a přidal tam ručně "e2fsck -f -y /dev/data/system", jehož výstup přesměrovávám na předem rw připojený jiný oddíl. Výstup tohoto příkazu je
    e2fsck 1.41.12 (17-May-2010)
    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/data/system: 29264/8069120 files (0.2% non-contiguous), 796962/32256000 blocks
    
    tj. jako by byl souborový systém v pořádku. Avšak RO fsck v běžícím systému zase ukáže stejný špatný inody. Přijde mi, že se systém zbláznil, v čem může být problém?

    Řešení dotazu:


    Odpovědi

    8.2.2012 05:11 vasek
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    A tak ono to dělá j na jiných strojích při kombinaci root filesystem jako rw / ext4. Vadí mi to z toho důvodu, že se vytváří poškozený lvm snapshot. Je nějaká možnost udělat konzistentní snapshot?
    8.2.2012 09:53 Jack
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Nemuzes delat konktrolu na pripojenem FS! I kdyz je read only, tak zurnaly nejsou zapsany kompletne a podobne dalsi veci - to je duvod proc ti to hazi chyby, pokud chces mit jistotu, nastartuj z live cd a udelej konktrolu na odmountovanem FS!
    8.2.2012 10:51 vasek
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Takže konzistentní snapshot není možné udělat?
    8.2.2012 10:57 Jack
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Ale ten snapshot bude normalne v pohode. Si to zkus - udelej snapshot, pak nahod live, obnov snapshot a udelej fsck. Jde proste o to, ze nemuzes kontrolovat jestli je FS konzistentni kdyz se s nim pracuje, data jsou ctena, ev. zapisovana, zurnaluje se, atp.
    8.2.2012 12:22 vasek
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Však já to zkoušel. Udělal jsem snapshot a připojil ho ro. Pokaždé když toho udělám, tak se opravují stejné inody ve zhotoveném snapshotu.
    EXT4-fs (dm-3): orphan cleanup on readonly fs
    EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 394506
    EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 394505
    EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524297
    EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524296
    EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524295
    EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524294
    EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524293
    EXT4-fs (dm-3): 7 orphan inodes deleted
    EXT4-fs (dm-3): recovery complete
    
    8.2.2012 12:55 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    A to proto že to máš ro a nemůže se tam zapisovat.
    8.2.2012 13:09 vasek
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Když to připojím rw, chová se to stejně.
    8.2.2012 13:21 Jack
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Nepripojuj to a udelej konktrolu na odpojenem svazku, jak do dubu.
    8.2.2012 13:55 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Prostě hledá chybu kde není.
    8.2.2012 13:59 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Asi by to chtělo zkusit vícekrát na RW svazku, a jak se to tím celé po..zí|re, tak konečně poslechnete a příště to už budete provádět na odpojeném svazku…
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    8.2.2012 14:32 vasek
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Ale já na snapshotu vůbec neprovádím kontrolu. Tohle se do dmesg zapíše automaticky po připojení toho snapshotu. Podle předchozí odpovědi "Ale ten snapshot bude normalne v pohode. Si to zkus - udelej snapshot, pak nahod live..." jsem pochopil, že by se to stávat nemělo a proto se taky tady ptám.
    8.2.2012 15:37 Jack
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Hod sem prikazy a vystupy toho jak to pripojujes, resp jak tam nahazujes ten snapshot.
    8.2.2012 17:30 vasek
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    $ sync // toto jsem přidal dodatečně
    $ lvcreate -s -L 4G -n system_snapshot /dev/data/system
      Logical volume "system_snapshot" created
    $ e2fsck -fy /dev/data/system_snapshot // toto jsem přidal dodatečně
    e2fsck 1.41.12 (17-May-2010)
    Clearing orphaned inode 394506 (uid=0, gid=0, mode=0100600, size=0)
    Clearing orphaned inode 394505 (uid=0, gid=0, mode=0100600, size=0)
    Clearing orphaned inode 524297 (uid=27, gid=27, mode=0100600, size=0)
    Clearing orphaned inode 524296 (uid=27, gid=27, mode=0100600, size=0)
    Clearing orphaned inode 524295 (uid=27, gid=27, mode=0100600, size=0)
    Clearing orphaned inode 524294 (uid=27, gid=27, mode=0100600, size=133)
    Clearing orphaned inode 524293 (uid=27, gid=27, mode=0100600, size=0)
    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/data/system_snapshot: ***** FILE SYSTEM WAS MODIFIED *****
    /dev/data/system_snapshot: 29321/8069120 files (0.2% non-contiguous), 797174/32256000 blocks
    $ mount -o ro /dev/data/system_snapshot /lvm_partitions_ro/system
    
    8.2.2012 17:31 vasek
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    uid=27, gid=27 má mysql
    michich avatar 8.2.2012 18:21 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Orphaned inodes nepředstavují žádný problém. Viz např. vysvětlení od Stephena Tweedieho z jednom starém bugreportu.
    8.2.2012 09:55 R
    Rozbalit Rozbalit vše Re: Poškození souborového systému nedetekovatelné při bootu pomocí fsck
    Je to normalne.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.