Příspěvky

1

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 09. 11. 2024, 19:37:54 »

Ono asi device remove a device replace ve finále udělá na konec totéž. Leda to vzít opravdu doslova a prostě ho hw odpojit a btrfs nic neříkat, nechat ho ať si to přebere sám.
I když - tak jste to asi myslel.

2

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 23:24:13 »

Finálně - původní disky vrácené, skříň zavřená a btrfs scrub spokojený.
Moc díky všem. Když si to projdu znovu od začátku je skvělé vidět kolik lidí se "seběhlo" aby mi pomohlo spravit rozbitý raid. Který jsem si navíc rozbil vlastní blbostí. Tak ještě jednou díky.

Pokud to čte někdo, kdo má podobný problém, tak nezapomeňte na

• Jestli chcete mít víc než jeden pokus, začněte tím, že si disk(y) někam zkopírujete
• Příkaz dd na přepsání magic string musí mít param conv=notrunc
• Až se vám to celé povede a disk se probudí, nezapomeňte na btrfs replace cancel <mountpoint> 

3

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 20:27:21 »

Kód: [Vybrat]

echo "_BHRfS_M" | dd bs=1 count=8 of=sda.img  seek=$((64*1024+64)) conv=notrunc

conv=notrunc - no jasně, to je to co tomu chybělo! V tom původním návodu https://superuser.com/questions/1281942/recover-data-from-replaced-btrfs-disk to nebylo a mě to netrklo.
Moc díky!

4

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 17:56:53 »

Jen update - as se někam blížím, jen tedy netuším kam. Zkusil jsem, ze zoufalství začít úplně odznovu, s novou bitovou kopií jednoho z těch původních disků (uloženou jako sda.img). Doběhl dd, pustil jsem na sda.img btrfs inspect-internal dump-super a dostal jsem:

Kód: [Vybrat]

btrfs inspect-internal dump-super --force --all  sda.img
superblock: bytenr=65536, device=sda.img
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x1d92253c [DON'T MATCH]
bytenr                  65536
flags                   0x1
                        ( WRITTEN )
magic                   ........ [DON'T MATCH]
fsid                    2db8f54a-3a36-4e3c-8e1f-6ef781966d66
metadata_uuid           00000000-0000-0000-0000-000000000000
label                   srv
generation              1598019
root                    6673317888
sys_array_size          258
chunk_root_generation   1598019
root_level              1
chunk_root              67139272704
chunk_root_level        0
log_root                0
log_root_transid (deprecated)   0
log_root_level          0
total_bytes             246096592896
bytes_used              53234524160
sectorsize              4096
nodesize                16384
leafsize (deprecated)   16384
stripesize              4096
root_dir                6
num_devices             2
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x161
                        ( MIXED_BACKREF |
                          BIG_METADATA |
                          EXTENDED_IREF |
                          SKINNY_METADATA )
cache_generation        1598019
uuid_tree_generation    1598019
dev_item.uuid           f3793453-4d55-46eb-9388-e9e716178818
dev_item.fsid           2db8f54a-3a36-4e3c-8e1f-6ef781966d66 [match]
dev_item.type           0
dev_item.total_bytes    123048296448
dev_item.bytes_used     60196651008
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          2
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

superblock: bytenr=67108864, device=sda.img
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0xbdf30df2 [DON'T MATCH]
bytenr                  67108864
flags                   0x1
                        ( WRITTEN )
magic                   ........ [DON'T MATCH]
fsid                    2db8f54a-3a36-4e3c-8e1f-6ef781966d66
metadata_uuid           00000000-0000-0000-0000-000000000000
label                   srv
generation              1598019
root                    6673317888
sys_array_size          258
chunk_root_generation   1598019
root_level              1
chunk_root              67139272704
chunk_root_level        0
log_root                0
log_root_transid (deprecated)   0
log_root_level          0
total_bytes             246096592896
bytes_used              53234524160
sectorsize              4096
nodesize                16384
leafsize (deprecated)   16384
stripesize              4096
root_dir                6
num_devices             2
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x161
                        ( MIXED_BACKREF |
                          BIG_METADATA |
                          EXTENDED_IREF |
                          SKINNY_METADATA )
cache_generation        1598019
uuid_tree_generation    1598019
dev_item.uuid           f3793453-4d55-46eb-9388-e9e716178818
dev_item.fsid           2db8f54a-3a36-4e3c-8e1f-6ef781966d66 [match]
dev_item.type           0
dev_item.total_bytes    123048296448
dev_item.bytes_used     60196651008
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          2
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

Jak já to čtu, tak tam našel 2 kopie superblocku (na třetí není místo, je to 128G disk), celkem smysluplně oba naplněné, nesouhasí magic - očekávané a csum - nevím ale to může být tím přepsaným magic. Celkem tedy docela nadějné.
Neudělám nic jiného než že přepíšu to magic v obou superblocích:

Kód: [Vybrat]

echo "_BHRfS_M" | dd bs=1 count=8 of=sda.img  seek=$((64*1024+64))
8+0 záznamů přečteno
8+0 záznamů zapsáno
8 bajtů zkopírováno, 0,000129285 s, 61,9 kB/s

echo "_BHRfS_M" | dd bs=1 count=8 of=sda.img  seek=$((64*1024*1024+64))
8+0 záznamů přečteno
8+0 záznamů zapsáno
8 bajtů zkopírováno, 0,000323182 s, 24,8 kB/s

a dám znovu btrfs inspect-internal dump-super ať vidím, co jsem udělal. A co nevidím a svým očim nevěřím:

Kód: [Vybrat]

btrfs inspect-internal dump-super --force --all  sda.img
superblock: bytenr=65536, device=sda.img
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x1d92253c [DON'T MATCH]
bytenr                  65536
flags                   0x1
                        ( WRITTEN )
magic                   _BHRfS_M [match]
fsid                    2db8f54a-3a36-4e3c-8e1f-6ef781966d66
metadata_uuid           00000000-0000-0000-0000-000000000000
label
generation              0
root                    0
sys_array_size          0
chunk_root_generation   0
root_level              0
chunk_root              0
chunk_root_level        0
log_root                0
log_root_transid (deprecated)   0
log_root_level          0
total_bytes             0
bytes_used              0
sectorsize              0
nodesize                0
leafsize (deprecated)   0
stripesize              0
root_dir                0
num_devices             0
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x0
cache_generation        0
uuid_tree_generation    0
dev_item.uuid           00000000-0000-0000-0000-000000000000
dev_item.fsid           00000000-0000-0000-0000-000000000000 [DON'T MATCH]
dev_item.type           0
dev_item.total_bytes    0
dev_item.bytes_used     0
dev_item.io_align       0
dev_item.io_width       0
dev_item.sector_size    0
dev_item.devid          0
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

ERROR: failed to read the superblock on sda.img at 67108864 read 72/4096 bytes
ERROR: error = 'Success', errno = 0

Tedy magic v prvním superbloku už sedí, zato se z něj ztratila podstatná část dat, od label dále. Druhý superblock zmizel úplně -

failed to read the superblock on sda.img at 67108864

Co to, sakra, je? dd dostal 8 znaků, tvrdí že zapsal 8 znaků, dokonce tam těch 8 znaků vidím na správném místě... Kam, sakra, zmizel ten zbytek superblocku a proč?

5

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 16:15:50 »

Fakt moc oceňuji tu snahu pomoci. U mě je to nějaké složitější. BTRFS tvrdošíjně hlásí chybu superblock checksum a to na všech kopiích superblocku. Jsem si 100% jistý, že jsem na těch původních discích žádnou operaci nedělal, první operací poté co jsem zjistil že nejdou namountovat bylo dd do souboru na jiném disku a vše ostatní pak probíhalo až tam.
Že ale nějakou záchrannou operaci neudělal proaktivně za mými zády nějaký mountovací démon (Kubuntu), to už si tak úplně jistý nejsem...
Uvidím, celé to vlastně od začátku bylo myšleno jako trénink, rozšíření znalostí o BTRFS, to se tedy naplňuje měrou vrchovatou...

6

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 14:09:33 »

Ano, nejspíš jde o fejky (napsáno je na nich Lenovo). Dostaly se ke mně podivnou cestou, ve které pravděpodobně figuroval nějaký čínský shop (ne že bych je tam kupoval), dostal jsem je jako bonus za nějakou protislužbu. Na nic důležitého bych je nepoužil. I tady jsem si to troufnul jen proto že jsem se (chybně) domníval, že jestli fakt chcípnou, tak se prostě jednoduše a snadno vrátím k původnímu páru.
No - chybama se člověk učí...

7

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 12:25:05 »

Jasně, když člověk ví co má hledat (_BHRfS_M) hned se ta informace hledá snadněji:
https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/On-disk_Format.html#Superblock

O něco jsem se pohnul, teď už hlásí
[ 6224.497322] BTRFS: device fsid 2db8f54a-3a36-4e3c-8e1f-6ef781966d66 devid 0 transid 0 /dev/loop30 scanned by mount (7926)
[ 6224.497921] BTRFS info (device loop30): first mount of filesystem 2db8f54a-3a36-4e3c-8e1f-6ef781966d66
[ 6224.497939] BTRFS info (device loop30): using crc32c (crc32c-intel) checksum algorithm
[ 6224.497944] BTRFS error (device loop30): superblock checksum mismatch
[ 6224.497956] BTRFS error (device loop30): open_ctree failed


Nadějí mě naplňuje že to 2db8f54a-3a36-4e3c-8e1f-6ef781966d66 je opravdu UUID toho původního disku/raid1.

8

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 11:42:42 »

dd z původních disků jinam bylo první co jsem udělal. Ten popis obnovy z odkazu vypadá hodně magicky. Zkusím nejdřív nastudovat a pochopit co vlastně dělá a odkud bere ta záhadná čísla.
Ale díky za odkaz, Google jsem samozřejmě zkoušel, asi jsem se ptal špatně.

9

Software / BTRFS replace - zapisuje něco na původní disk?

« kdy: 08. 11. 2024, 10:59:20 »

Dobrý den.

Měl jsem btrfs raid1 na dvou discích, fungoval bez problémů. Teď, zpětně viděno, jen z hloupého rozmaru jsem si usmyslel vyměnit v něm disky za větší. Připojil jsem dva nové větší disky (pro informaci - poněkud pochybného původu) a udělal postupně btrfs replace obou stávajících disků na nové. Proběhlo v pořádku, žádné chyby. Následně jsem tedy ještě udělal už na těch nových discích btrfs filesystem resize abych využil to nové místo.
Celou dobu jsem si (naivně) myslel, že je to celkem bezpečná operace, protože mi pořád zůstávají v záloze ty původní dva disky, v případě problémů se k nim mohu vrátit a ztratím max. ty změny od začátku replace. V zápětí se ukázalo že ty nové disky (SSD) jsou opravdu pochybné, po pár hodinách používání prostě začaly "zapomínat" data na nich mizela a v btrfs device stats začaly přibývat corruption_errs.
Myslel jsem si, že možná bude stačit jen odpojit ty nové disky a restartovat, případně manuálně mountnout ty původní disky. Ale nic z toho se nedaří. Při restartu systém ty původní disky nenajde a pokus o ruční mount hlásí wrong fs type, bad option, bad superblock
On btrfs replace příkaz něco zapisuje na ty původní, zdrojové disky? Nebo je dokonce nějak přepisuje/nuluje? Existuje vůbec nějaká cesta zpět?
Díky

10

/dev/null / Re:0x00 UDP paket při každém DNS z localhostu

« kdy: 04. 05. 2024, 00:02:34 »

Ach jo. Mám podobný problém, myslel jsem že se o něm něco dozvím. Dozvěděl jsem se akorát že RDa ví ale neřekne.

11

Sítě / Re:Správné nastavení domácí sítě

« kdy: 18. 03. 2024, 23:04:45 »

Ještě mě napadá, některé Windows "antivirové" programy dost agresivně zasahují do konfigurace sítě a možná se nejak nepopasovaly s proběhlými změnami. Zkuste na příští pokusy antivir dočasně vypnout.
V každém případě platí, že to zařízení které počítači přes DHCP přiděluje adresu mu zároveň i v té odpovědi říká kam se obracet s DNS dotazy. Jestli to funguje jinak přes WiFi z D-link a jinak přes kabel z Netgear, možná se vám tam pořád hádají dva DHCP servery...

12

Sítě / Re:Správné nastavení domácí sítě

« kdy: 17. 03. 2024, 11:08:08 »

Vzhledem k charakteru dotazu (nic ve zlém, každý umíme jenom něco), asi nejjednodušší cesta k funkční síti bude vyhnout se těm dvěma routerům.
D-Link prostě nepoužívat, nechat vše na tom Netgearu. Pokud má málo ethernet portů, přikoupit k němu switch. Pokud je potřeba rozšířit dosah WiFi, tak prasácké ale nejjednodušší je použít WiFi extender. Resp. on i ten D-Link nejspíš půjde přepnout do bridge mode a používat ho jen jako WiFi AP/ethernet switch. Je ale otázka, jestli se vám to povede.

13

Sítě / Re:Služby za VPN

« kdy: 29. 02. 2024, 22:30:58 »

Je otázka co myslíte tím "nějaká služba". Ona ta VPN má i jiné funkce než navýšení bezpečnosti. Ale ano, i tak. Většina VPN je opravdu dobře zabezpečená proti neoprávněnému přístupu. A tím že vaše služba není přístupná komukoli odkudkoli ale jen již prověřeným klientům přes VPN tak je opravdu bezpečnější. Nedostanou se na ni např. miliardy botů z nejrůznějších botnetů.

14

Hardware / Re:Co s nevytíženým RPi?

« kdy: 29. 02. 2024, 21:15:23 »

Přimlouval bych se za to letmo zmíněné  pihole výše. Je to přímo pro malinu určené, běhá spolehlivě a elegantně vyřeší většinu reklamního balastu v celé domácí síti z jednoho místa.

15

Server / Re:Oracle Free Tier - založení účtu

« kdy: 29. 09. 2023, 23:18:08 »

Ne že bych měl nějaké řešení ale shoda udávané adresy s adresou držitele karty to asi nebude. Verifikace adresy držitele karty v rámci transakce je americká záležitost, 99% evropských bank to nedělá, nepodporuje. Ono to s těmi 30 různými abecedami a různými transkripcemi mezi nimi je to trochu jiný problém než ověřovat americké adresy, v rámci jedné abecedy a jednotného formátu.
A jestli si Oracle ten 1USD strhne a po týdnu vrátí, nehledal bych příčinu v kartě vůbec. Ta transakce kartou proběhla zjevně úspěšně, Oracle žádné vyšší ověření, než že ten dolar dostane na účet z té karty ani dostat nemůže.