Debian 12.3 byl kvůli chybě v jádře 6.1.64-1 nakonec přeskočen. Vydán byl rovnou Debian 12.4.
Počítačové hře Doom je dnes 30 let. Vydána byla 10. prosince 1993. Zahrát si ji lze také na Internet Archive.
V srpnu společnost HashiCorp přelicencovala "své produkty" Terraform, Packer, Vault, Boundary, Consul, Nomad a Waypoint z MPL a Vagrant z MIT na BSL (Business Source License). V září byl představen svobodný a otevřený fork Terraformu s názvem OpenTofu. Na konferenci Open Source Summit Japan 2023 byl představen (YouTube) svobodný a otevřený fork Vaultu s názvem OpenBao (GitHub).
Na dnes plánované vydání Debianu 12.3 bylo posunuto. V jádře 6.1.64-1 v souborovém systému ext4 je chyba #1057843 vedoucí k možnému poškození dat.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek i s náhledy aplikací v Týden v GNOME a Týden v KDE.
Tak od ledna linuxové terminály, výchozí pozadí i celé desktopy v barvě "broskvového chmýří", v barvě "jejíž všeobjímající duch obohacuje mysl, tělo i srdce". Barvou roku 2024 je PANTONE 13-1023 Peach Fuzz.
Byla vydána verze 10 linuxové distribuce Freespire (Wikipedie). Jedná se o bezplatnou linuxovou distribuci vyvíjenou společností PC/OpenSystems LLC stojící za komerční distribucí Linspire (Wikipedie), původně Lindows.
Binarly REsearch před týdnem informoval o kritických zranitelnostech UEFI souhrnně pojmenovaných LogoFAIL. Tento týden doplnil podrobnosti. Útočník může nahradit logo zobrazováno při bootování vlastním speciálně upraveným obrázkem, jehož "zobrazení" při bootování spustí připravený kód. Pětiminutové povídání o LogoFAIL a ukázka útoku na YouTube.
Byla vydána listopadová aktualizace aneb nová verze 1.85 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.85 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
git.kernel.org je nově oficiálně také v tmavém vzhledu.
V prvom rade musíš dať filesystém do režimu Read-olny a potom je možnosť pokúsiť sa o obnovu.
Aké tam máš disky ? Výrobca, séria a atď. Prilož výpis príkazu mount
. V raid 1 je jedná vlastnosť, ktorá spôsobi, že vplyvom chyby na jednom disku sa prenesie na druhý disk. Šance na obnovu neviem definovať.
Mne sa raz podarilo na ext3 filesystéme obnoviť súbory ale to bolo okamžite nastavení ro mód a ako ďalšie plus bol nastavení príznak u v rozšírených atributoch.
/dev/sda1 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda3 on /virtualbox_ssd type fuseblk (rw,nosuid,nodev,allow_other,blksize=4 096) /dev/md2 on /datad02ssd type ext2 (rw) /dev/md1 on /datad02 type ext2 (rw) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) ten filesystém jsem spletl, je to ext2
Priklad z praxe: stahujem subor z webu a urobim tvrdy reset. Ked mam zurnal (ext3 data=ordered), stratim len malu cast suboru na konci a mozem pokracovat v stahovani. Ked zurnal nemam, tak bude pravdepodobne cely subor v prdeli.
To je dost optimistická vize a obecně něco takového rozhodně tvrdit nelze (ani jednu část).
V zurnale su vsetky potrebne informacie na uvedenie filesystemu do konzistentneho stavu.
Přesně: do konzistentního stavu. Ale nikde nemáte záruku, že to bude právě ten, který byste chtěl.
Nestalo sa ti to nahodou po nekorektnom vypnuti/restarte? ext2 nema proti tomu ziadnu ochranu. Musi sa urobit fsck.to bohužel nevím, přišel jsem na to v podstatě náhodou, protože se to stalo u mailového účtu, který používám na různé registrace, takže se sice stahuje s ostatními, ale čtu ho jen jednou za čas
Nemyslel so podporu v ovládači , ale podporu v jadre pri pripájaní disku.Nemůžu říct, že bych chápal, co se tu snažíš říct.
FS ext2, to je ešte podporované? Pred pár rokmi sa mi vysypal a zistil som že pri štarte systému, po vyskytnutí sa nekonzistencie robí iba prehranie neexistujúceho žurnálu a označenie že disk je OK. Takže sa mi tam množili chyby ktoré mi systém veselo ignoroval. Distribúcia bola Gentoo x86, ale to je vedľajšie.Aha, netušil jsem, jak moc jsem už zastaral
Takže držím palce.Díky
FS ext2, to je ešte podporované?Ext2 je uplne normalne podporovany, muzete to snadno zjistit pohledem do logu v gitu. Navic k pripojeni ext2 FS muzete pouzit i ext3 a ext4 driver.
Pred pár rokmi sa mi vysypal a zistil som že pri štarte systému, po vyskytnutí sa nekonzistencie robí iba prehranie neexistujúceho žurnálu a označenie že disk je OK. Takže sa mi tam množili chyby ktoré mi systém veselo ignoroval. Distribúcia bola Gentoo x86, ale to je vedľajšie.To vubec neni vedlejsi - to, ze se na rozbitem FS nespustil fsck, je chyba distribuce, protoze ta je za to zodpovedna.
Jadro mi našlo pri štarte dirty FS EXT2 a vypísalo "recovering journal".
Jste si jistý?
mike@unicorn:~/work/git/kernel-upstream> grep -r 'recovering journal' * fs/gfs2/ops_fstype.c: fs_err(sdp, "error recovering journal %u: %d\n",
Ale především: ext2 žádný žurnál nemá a ani mít nemůže, ext2 není žurnálovací filesystém. Pokud na něm žurnál vytvoříte, uděláte z něj ext3.
I keď to bolo 5 rokov dozadu, tak som si istý podstatou chyby. Ale, ako som už spomínal, tak presným znením už nie. Takže použitie grep je trošku mimo.+-10 let sleduju patche, co jsou zarazeny do mainstreemu a mohly by se tykat nasich zarizeni, na kterych pouzivame mimo jine i ext2 a zadneho takoveho problemu jsem si nevsiml. Nerikam, ze to neni mozne, ale je mnohem pravdepodobnejsi, ze jste si to rozdrbal sam a nebo to byla chyba ve startovacich skriptech v distribuci.
Proč do toho pořád pletete jádro? A co je to "neodhalení dirty FS"? Flag "dirty" je pouhý příznak v superblocku, který se nastaví při (rw) mountu a shodí při odmountování nebo přemountování read-only, na tom není co odhalovat. To, že se při startu zkontroluje dirty flag a případně provede check, řeší init skript distribuce, ne jádro. Přičemž e2fsck defaultně pouze zkontroluje dirty flag a když není nastaven, vlastní kontrolu neprovádí - což máte napsáno v dokumentaci. Pokud máte podezření na poškozený filesystém, máte ho zkontrolovat ručně (a samozřejmě s -f
).
A hlavně - už asi potřetí - ext2 není žurnálovací filesystém, tedy pokud vám jakýkoli nástroj tvrdil, že na něm obnovuje žurnál, tak si o něm rozhodně nemyslel, že je to ext2, takže jste měl problém v konfiguraci.
Alebo si niečo pletiem keď hádžem hrach na stenu a bavím sa s človekom trpiacim selektívnou slepotou?
No, když už jste začal s tou selektivní slepotou a házením hrachu na zeď… Už mne nebaví pořád dokola upozorňovat na zjevně nepravdivá tvrzení ve vašem popisu problému. Takže se omezím na obecnou radu: naučte se při popisu problému rozlišovat mezi fakty a vašimi doměnkami. Jinak riskujete, že ten, kdo ho bude číst, při určitém počtu zjevných nepravd přestane zkoumat, co by mohla být pravda a co si pouze myslíte, a bude se věnovat něčemu jinému.
V okamžiku, kdy pořád dokola připisujete jádru činnosti, které nedělá a dělat nemá, a kdy zatvrzele ignorujete fakt, že ext2 žádný žurnál nemá a že tudíž pokud na něm někdo chtěl žurnál "obnovovat", pak jedině v důsledku chybné konfigurace, se nemůžete divit, že beru s odpovídající rezervou i ostatní informace, kterými si jste stejně jistý jako těmi, o kterých vím, že nemohou být pravda.
A tímto konstatováním s tímto threadem končím, tedy přinejmenším do chvíle, než začnete rozlišovat mezi fakty a doměnkami (dojde-li k tomu).
Pak jde spíše o chybou FS/jádra a ne chybou hw.
Já bych s tou Occamovou břitvou šel ještě trochu dál a místo hypotézy, že je v široce používaném a léty prověřeném filesystému ext3 je chyba způsobující, že se tazateli náhodně obyčejné soubory mění na stejnojmenné adresáře (ale jen tazateli a jen u mailboxů), bych začal spíš s daleko pravděpodobnější hypotézou, že je to chyba userspace aplikace, např. nepovedený nebo násilně přerušený pokus o konverzi mailboxu na maildir či jiný formát pracující s adresářem.
Zvláště pak píše-li tazatel věci jako
na vyhrazeném oddílu Raid1 z 2x ext3 (SSD disky)
On se snad dělá RAID nad filesystémy? (Nepočítám BtrFS, to je úplně jiná kapitola.) RAID (md) sestavuje pole z blokových zařízení a teprve na výsledném blokovém zařízení se vytváří filesystém.
Já bych s tou Occamovou břitvou šel ještě trochu dál a místo hypotézy, že je v široce používaném a léty prověřeném filesystému ext3 je chyba způsobující, že se tazateli náhodně obyčejné soubory mění na stejnojmenné adresáře (ale jen tazateli a jen u mailboxů), bych začal spíš s daleko pravděpodobnější hypotézou, že je to chyba userspace aplikace, např. nepovedený nebo násilně přerušený pokus o konverzi mailboxu na maildir či jiný formát pracující s adresářem.jediná aplikace je Thunderbird, o žádné konverzi nic nevím (chci tím říct, že se to stalo při normálním používání desktopu, žádný upgrade/přechod na jiný poštovní program apod.)
On se snad dělá RAID nad filesystémy? (Nepočítám BtrFS, to je úplně jiná kapitola.) RAID (md) sestavuje pole z blokových zařízení a teprve na výsledném blokovém zařízení se vytváří filesystémAsi jsem to popsal špatně, myslel jsem to tak, že jsem měl dva disky formátované na ext3 a ty jsem přes Webmin spojit do raid1 a na něm byla data (to pole se v příkazu mount vypisovalo jako ext2, ale disky, na kterých jsem je sestavil, byly ext3).
jsem měl dva disky formátované na ext3 a ty jsem přes Webmin spojit do raid1 a na něm byla data
To nebyl dobrý nápad. Driver md
potřebuje na zařízení uložit hlavičku s metadaty (persistent superblock), takže i když to nejspíš na první pohled vypadalo, že je filesystém v pořádku (na rozdíl od starších verzí se dnes defaultně metadata neukládají na začátek), tak v pořádku nebyl. A navíc dalším používáním mohlo docházet ke vzniku nových chyb.
A good rule of thumb is that it is okay if you have a few strange files in your profile since they are probably either due to an add-on or this article not being updated yet, but any time you find a SQLite file replaced by a directory with the same name its probably due to a bug.
na vyhrazeném oddílu Raid1 z 2x ext3 (SSD disky)Nejprve bych dal do pořádku filesystémy a pak začal řešit něco dál
Pochybuji, že to způsobila filesystému (na 99.99 % ne).Jo? Tak mohu přidat hned další případ. O tomto víkendu odešel v raid6 jeden ze čtyř disků. V poli byl SPARE, takže bych nečekal žádný problém. První varování bylo, že zmizela binárka pro tail, přesto že měla replikace proběhnout v pořádku. V systému visela hromada procesů, které nešlo odstřelit a po restartu už systém díky rozbité ext4 nenajel - grub nenašel potřebné soubory. Fsck.ext4 ze systemrescuecd pak dokonal dílo zkázy a celé je to zralé na reinstalaci, protože jenom pánbů ví, co bylo v inodech, které šly do kytek. Naštěstí jde pouze o systémový disk. Zákeřná kombinace? Raid+LVM+Ext4 K tomu bych jen poznamenal, že u reiserfs se mi takovým způsobem systém nikdy nerozbil.
Tiskni
Sdílej: