Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Ahoj,
jaká je prosím pravděpodobnost, že bych mohl zvrátit výsledek výše uvedeného příkazu. Partišna sdb2 byla ext4 a měla 322.5GB a byl v ní adresář /home a Idiotovi s rootovským oprávněním :'-( se jí povedlo přepsat obrazem obraz.img o velikosti asi 570MB.
Předpokládám, že už se mi z toho nepovede asi nic zachránit. Za případné nápady a rady předem děkuju.
Řešení dotazu:
Děkuju, určitě vyzkouším. Ale ke vší smůle ani nemám k dispozici disk kam bych případně obnovená data ukládal. Musím to zkusit jindy.
Moc děkuju, ale to nebude třeba. Už mám domluvenou výpujčku zítra u kámošky. Pak dám vědět jestli sem z toho něco dostal nebo ne. Jak jsem projížděl různý možnosti tak se určitě podívám na ten testdisk a photorec.
Všech rizik jsem si vědom. Těch dat je sice škoda, ale nezáleží na nich tolik, abych je pro získání osobních zkušeností nebyl ochoten obětovat Výsledek svých snah i s děkovačkami určitě napíši ...
ddrescue
.
S kopií počítám, ale ddrescue jsem vůbec nezaznamenal a přitom podle wiki vypadá, že je na takovou situaci přímo určený. Dík
Zkazit s tím snad nic nemůžu. A pokud dd přepsalo fyzicky jenom těch 600MB a alokační tabulku ext4, tak si myslím že by těch 322 GB dat bitová kopie s ddrescue měla zaznamenat. A když ne, tak udělám kopii s "obyčejným" dd. Až budu mít možnost poexperimentovat tak poreferuju.
ddrescue
to bylo zřejmě přestřelené. Pokusil bych se na tom disku najít alternativní superbloky a od některého začít. Třeba pomocí dumpe2fs
nebo pokud jsou přesně známy parametry s níž byl FS vytvářen tak mke2fs -n
tam opatrně! Bez paramteru -n se zničí všechno. Testdisk v advanced modu by je také měl najít.
Ahoj, tak už jsem něco málo vyzkoušel. Nejprve jsem si udělal s dd bs=2048 if=/dev/sdb2 of=obraz
obraz(trvalo to asi 4 hodinky). Dále jsem zkusil dumpe2fs
, ten hlásí:
Chybné magické číslo v superbloku při pokusu otevřít. Nemohu najít platný superblok v systému souborů.To hlásí u obrazu i u originálu. Dále jsem zkusil, jak radíš,
photorec
, který je velice úspěšný v hledání neúčelných dat jako je cache firefoxu, přitom výsledek vypadá jak bitva u Maglaje . Nicméně, že nedokáži obnovit /home v jeho původní celistvosti a struktuře jsem očekával už na začátku. A při důkladné probírce za dlouhých zimních večerů se z toho určitě něco vytáhnout dá. Ještě se po nějakých řešeních ve volných chvílích mrknu někde jinde, ale jak jsem čtl, že jméno příkazu dd se interpretuje jako "Data Destroyed" věděl jsem, že veškerá snaha bude marná. Tímto děkuji všem za ochotu a trpělivost.
Zjistím zkusím, jdu na to. Dík za tip
mkfs -n /dev/sda1
Typ OS: Linux
Velikost bloku=4096 (log=2)
Velikost fragmentu=4096 (log=2)
Krok=0 bloků, Šířka pásu=0 bloků
21127168 iuzlů, 84481536 bloků
4224076 bloků (5.00 %) rezervováno pro superuživatele
První blok dat=0
Maximum bloků v systému souborů=4294967296
2579 skupin bloků
32768 bloků ve skupině, 32768 fragmentů ve skupině
8192 iuzlů ve skupině
Zálohy superbloku uloženy v blocích:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968
dumpe2fs -o superblock=(zkusil jsem všechny čísla) /dev/sda1
Filesystem volume name: -none- Last mounted on: /media/bd5fcb24-19f8-4883-a03e-eeac27765545 Filesystem UUID: bd5fcb24-19f8-4883-a03e-eeac27765545 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 21127168 Block count: 84481535 Reserved block count: 4224076 Free blocks: 13335062 Free inodes: 20494852 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1003 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 RAID stride: 32748 Flex block group size: 16 Filesystem created: Fri Oct 26 13:37:54 2012 Last mount time: Sun Oct 19 19:20:10 2014 Last write time: Sun Oct 19 20:41:31 2014 Mount count: 0 Maximum mount count: -1 Last checked: Sun Oct 19 20:11:26 2014 Check interval: 0 (-none-) Lifetime writes: 2567 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 159f7744-7dc3-4866-a3af-c1806742b041 Journal backup: inode blocks Invalid argument při čtení superbloku žurnálu.Dělám něco špatně?
e2fsck -b zalozni_superblock /dev/device
. a případně také ten Testdisk pokud to umí undelete a ziskat soubory se smazaného oddílu. tak by to mohlo pomoci.
Na e2fsck
se mrknu zitra. Dik. Zatim mi aspon nejak fungoval ten photorec. Ale nenajde to vsechno a z ostatniho je dost bordelu. Ten testdisk
jak tady Jenda probiral, ze slouzi vyhradne k vyhledani souborovych systemu, tak jsem se jim nezabyval, protoze to uz mam vlastne prepsane tim obrazem. Jeste se tomu testdisku na ten manual podivam. Snad budu mit zitra chvili, ted pred tema Saturnaliema toho mam nejak moc.
Tak na tech strankach o TestDisku jsem se sice docetl, ze zvlada obnovu souboru, ale pouze z FAT, NTFS a ext2. Ja tam mival ext4 a u ext4 zvladne pouze vyhledat ztraceny oddil, coz asi u lehce prepsaneho nebude mozne. No zitra jeste mrknu na ten e2fsck
Děkuju. Přece jen pomohlo.
Dnes se mi podařilo z té partišny vydolovat zhruba 85% dat i s jejich původními jmény a někde i s původní adresářovou strukturou.
Podařilo se to pomocí těch záložních superbloků a skutečně toho testdisku. Po konečném experimentování dávám v plac všechny příkazy v kostce i se zálohováním oddílu a mountováním konečného obrazu:
dd if=/dev/sdb2 of=backup_sdb2.img mkfs -n backup_sdb2.img e2fsck -y -b zalozni_superblock backup_sdb2.img testdisk backup_sdb2.img mount -t ext4 backup_sdb2.img /mnt
Obraz oddílu je tedy mountován v adresáři /mnt a v něm je pak adresář lost+found, ve kterém jsou očíslované adresáře s více či méně uspořádaným původním obsahem. Pro srovnání PhotoRec z toho oddílu nenašel ani polovinu, natož aby to bylo uspořádáno.
Zase mám o něco více zkušeností, ale bráchu k tomu rootovskýmu účtu už stejně nepustím . Všem Vám moc děkuji za pomoc a přeji Veselé Vánoce.
Tiskni Sdílej: