Stažené soubory s nesedícím md5

[LamZelezo]

Vymenit pameti a vyzkouset.
Pokud nepomuze, vymenit zdroj a vyzkouset.

[Reklama]

[hungarec]

Co jsem stihl vyzkoušet:
- stažení za použití live distro (konkrétně USB flash s Gparted) na shodném HW: md5 sedí(!)
- znovu stažení na ntb, ověření md5 (tady samozřejmě sedí) a v terminálu scp na server - md5 nesedí(!)
- diff použitý na zip stažený wgetem (na serveru) a souborem poslaným na server přes scp hlásí, že se liší

Zkoušel jsi opravdu na Live distru všechno přesně tak jak to provozuješ na současné instalaci OS notebooku?
Pokud na stejném HW to při Live distru funguje OK a na současné instalaci OS nefunguje, proč zkoušet hledat problémy v síťovce, kabelech, switchíš nebo RAM?
Udělem si zálohu OS a pak ten Debian přeinstaluj a vyzkoušej to na čisté instalaci.

[Karmelos]

Neděláš ten MD5 moc brzy po stažení? Jen jestli se ti to ještě na ten disk všecko z těch všech keší po cestě fyzicky zapsalo.
A taky, co já vim, čistě náhodou, při tom downloadu, neměníš někdy vlastníka, práva, pravidla spouštění, apod?
A dělá ti to stejně pod userem i pod rootem? Co jinej, novej user?

[RDa]

Neděláš ten MD5 moc brzy po stažení? Jen jestli se ti to ještě na ten disk všecko z těch všech keší po cestě fyzicky zapsalo.
A taky, co já vim, čistě náhodou, při tom downloadu, neměníš někdy vlastníka, práva, pravidla spouštění, apod?
A dělá ti to stejně pod userem i pod rootem? Co jinej, novej user?

To jsi napsal mega blbost. Nevyflushnuty cachovani pri zapisu na disk nehraje roli v tom, co jiny programy vidi za obsah souboru.

Rozdil by to byl pouze v pripade, kdyz by md5sum volal na neuzavrenej soubor (tj. wget/curl jeste bezi), a to predpokladam ze nedela.

[Martin Poljak]

Neděláš ten MD5 moc brzy po stažení? Jen jestli se ti to ještě na ten disk všecko z těch všech keší po cestě fyzicky zapsalo.

Čím by ho dělal? Něčím, co používá O_DIRECT? O tom tedy dost pochybuju.

[Reklama]

[DrFreeze]

Oprávnění určitě neměním, pod rootem můžu zkusit.

Ještě mě ale napadla jedna věc: jedná se sice o nevýkonný Intel J1800, ale celé to napájím picoPSU modulem. Má už pár let za sebou a mohl bych zkusit pustit nějaký stress test, jestli to v té chvíli nebude chybovat víc.
Ten picoPSU by měl zvládat dodávat 200 W, ale kdoví jak jsou na tom kondenzátory. Navíc jsem nedávno přidal druhý HDD. Před tím jsem tam ale dlouho nic nekutil, tak nemůžu tvrdit, že tento problém nastal přesně po přidání disku.
Každopádně si seženu normální funkční zdroj a zkusím to s ním.

[RDa]

Hod nam sem konecne diff z hexdumpu, jaky druh chyby tam nastava.

[Jan Fikar]

Tím zdrojem by to mohlo být, navíc jestli je tam nový disk.

Zkusil bych toto hodinu toto: stress-ng --matrix 0 --verify --tz --timeout 3600

A k tomu bych zaroven cetl vsechny disky, jestli to zdroj vydrzi: sudo dd if=/dev/sda of=/dev/null bs=1M status=progress

Ty disky jdou dat taky do stress-ng, ale to nemam vyzkouseny.

Druha moznost misto stress-ng a se zatezi jen na dve jadra je:  dd if=/dev/zero bs=1M count=40000 status=progress| ssh -q -c aes128-ctr localhost 'cat > /dev/null'

[DrFreeze]

Příští týden budu mít půjčený ATX zdroj. Pro teď jsem to vyzkoušel rozjet jen s jedním diskem a stažení instaláku bylo bez přerušení, md5 sedí a apt-get update byl taky bez chyb.
Myslím, že pro teď není potřeba zkoumat obsah poškozených souborů, resp. s největší pravděpodobností je příčina odhalena.
Děkuji všem, kteří se tématu věnovali.

[DrFreeze]

Tak anabáze bohužel nekončí. Mám půjčený zánovní 400W zdroj a dospěl jsem k tomuto:
- v konfiguraci jen s SSD šlo stahování vždycky bez přerušení, md5 vždycky sedí
- v konfiguraci s SSD a jedním HDD šlo stahování vždycky bez přerušení, md5 sedí
- jakmile připojím druhý HDD (zkoušel jsem i různé kombinace portů - nemají na to vliv), začne se stahování přerušovat, md5 nikdy nesedí

Tedy zdrojem to taky není, takže si zkusím sehnat nějakou desku se starším Intelem, abych to všechno nemusel instalovat znovu a vyzkoušel to na ní.

[RDa]

A proc sem nedas ten diff z hexdumpu? Ono to napovi kde je chyba.

[Jan Fikar]

A co ten stress-ng nebo to dd přes ssh, jak jsem psal výše. To projde bez chyby i se dvouma diskama?

[Martin Poljak]

Tak anabáze bohužel nekončí. Mám půjčený zánovní 400W zdroj a dospěl jsem k tomuto:
- v konfiguraci s SSD a jedním HDD šlo stahování vždycky bez přerušení, md5 sedí
- jakmile připojím druhý HDD (zkoušel jsem i různé kombinace portů - nemají na to vliv), začne se stahování přerušovat, md5 nikdy nesedí

Ehm, sice jsem nesledoval celou diskuzi, ale tady se mi celkem fest rozblikala červená kontrolka: to SSD je SATA nebo NVMe? Pokud není SATA, dost bych se obával o život SATA řadiče na desce. Už se mi taky stalo, že celkem nenápadně odešel i když zbytek desky běhal bez problémů. Pokud je SATA i to SSD, pak bych se obával o osud kontroleru jednoho z těch HDD.

[Wasper]

Pokud je SATA i to SSD, pak bych se obával o osud kontroleru jednoho z těch HDD.

Jo, vítejte v klubu. Něco na tohle téma (plus v další fázi i dost podivný pokles FPS na grafice za nepredikovatelných podmínek) mě loni donutilo k upgradu boardu(+CPU).

[DrFreeze]

- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůže
- na stress se taky chystám, dělám to po chvilkách
- dnes chci tu kombinaci disků vyzkoušet na jiné základní desce

Co jsem ještě nepsal: deska má dva SATA porty, plus v miniPCIe přídavný řadič s dalšími dvěma. Zkoušel jsem různé kombinace připojení a nemá to na to na nic vliv, vždycky platí, že samotný SSD nebo SSD + 1xHDD jsou OK, jen plná konfigurace SSD + 2xHDD chybuje. Zkoušel jsem dokonce bootovat z toho SSD připojeného přes USB (stejný nOK výsledek). A pokud se to takto chová se dvěma různými zdroji, můžeme jejich vliv taky vyloučit.