Názory k článku
Další chyba v Ubuntu 25.10 kvůli rust-coreutils

použije u dd parametry bs, ibs, obs a count

Tož snad alespoň if a of fungují správně...!
Ale vážně: o moc víc, než těchhle šest parametrů jsem snad s dd nikdy nepoužil a nepotřeboval - snad už jen zobrazení průběhu.

seek/skip se taky obcas hodi :)

Líbí se mi ta formulace "nefungují zcela správně" ;-)
No co, pár bajtů sem, pár tam, hlavně že je to free, cool, in a memory safe...

Tak to jste si ale dost zahrával, protože dd je minové pole. tl;dr dd bez flagu fullblock prostě yolo udělá syscall read s velikostí podle nastavené velikosti bloku, a když mu kernel vrátí méně dat, tak to neřeší a zapíše je na výstup a počítá to za plný blok. Takže můžete snadno přenést méně dat než jste chtěl. Skoro mi podle popisu bugu přijde, že tohle je sice bug v rust-coreutils (kromě částečného přečtení na vstupu udělá i částečný zápis na výstupu a ztratí přečtená data), ale kdyby se situace sešla, tak problém nastane i s normálním dd.

Já se na dd vykašlal, soubory přenáším normálně catem (nebo ještě lépe pv - zobrazuje průběh, navíc celou dobu a nemusí se dráždit jak dd), a začátky a konce usekávám pomocí head a tail (-c 100, -c +100).

Průběh obecně zobrazuji nástrojem progress, podporuje spoustu programů (gzip a další *zip, md5sum a další *sum…). Funguje tak, že se podívá do /proc/pid/fd aby zjistil, který soubor je vstup a výstup, a pak do /proc/pid/fdinfo, kde se dozví aktuální pozici. Pokud jsem na systému, kde není a nechci/nemůžu ho instalovat, tak tohle podívání se udělám ručně.

No ale dd je urceny na pracu s diskovymi partition takze uz ste niekedy skusal vypisat poslednych 100GB s 1TB oddielu pomocou TAIL?

Tak zrovna tohle jde naprosto v pohodě, i když nevím, proč bych to dělal (oddíly jsou typicky číslované od začátku). Poslední gigabajt:

# time tail -c $(( 1000*1000*1000 )) /dev/nvme0n1 | md5sum
90f6764444b7952a4dcf1c7bb24e5ff5  -

real    0m1.063s
user    0m0.966s
sys 0m0.395s

Chápu, že tenhle přístup nejde použít k přepisu hodnoty uprostřed disku.

Tuhle narážku na dd (že nemusí číst celý blok) jsem o tebe před mnoha lety četl už na ABCLinuxu. Tobě se někdy reálně stalo, že by dd nenačetl celý blok a nic by neoznámilo chybu? Mě teda nikdy a to jsem pomocí dd běžně dělal image virtuálek a přenesl možná stovky TB dat. Nedovedu si představit, že by fs vrátil méně než blok a nenahlásil by chybu čtení apod.

No ne, když kopíruješ celý disk/image atd. tak je to v pohodě, protože se ve čtení pokračuje dál. Problém je když používáš "count" a chceš aby to přeneslo přesně tolik dat kolik je count*bs.

Nasimulovat se to dá takhle:

$ (while sleep 0.1; do head -c 1000 /dev/urandom ; done) | dd bs=1024 count=10 of=/dev/null
dd: warning: partial read (1000 bytes); suggest iflag=fullblock
0+10 records in
0+10 records out
10000 bytes (10 kB, 9,8 KiB) copied, 1,0492 s, 9,5 kB/s

(mělo přenést 10240 a přeneslo jen 10000). Tj. stane se to pokud se čte z programu/sítě, ze kterého padají data po menších bobečcích než chceme číst.

A je to reálné při síťovém provozu, např. ssh po normálním rozumně rychlém internetu:

$ ssh f "cat /dev/urandom" | dd bs=1M count=10 of=/dev/null
dd: warning: partial read (32768 bytes); suggest iflag=fullblock
0+10 records in
0+10 records out
327680 bytes (328 kB, 320 KiB) copied, 0,527688 s, 621 kB/s

A stejně tak při čtení komprimovaného archivu:

$ zstdcat openwrt-imagebuilder-24.10.2-ramips-mt7621.Linux-x86_64.tar.zst | dd bs=1M count=10 of=/dev/null
dd: warning: partial read (65536 bytes); suggest iflag=fullblock
0+10 records in
0+10 records out
593920 bytes (594 kB, 580 KiB) copied, 0,00314817 s, 189 MB/s

Přímo disku se to doufejme dít nebude, a doufejme že ani např. z NFS share. Ale nesázel bych na to… Konec konců, diskutujeme pod zprávičkou, kdy měl někdo částečný zápis při zapisování do "pomalého" md5sum.

Aha, tak v pipě jsem dd snad nikdy nepoužil, pouze if, of z block device. Pro pipe používám právě pv.

Muzes to zopakovat s ddrescue a pajpy jestli tam jde ?

Posledni dobou preferuji ddrescue na delsi operace protoze to ma hezci progress bar (hezci nez dd status=progress) a moznost spare detekce. Nemam to vyslovene kvuli badblock/retry.

Jakoze ta vec ale neni na streamy, Jendo...

Za mě se to chová správně. Tímhle dd říkáte "udělej 10 čtení po maximálně 1024 bajtech". Pipe v jednom čtení vrací 1000 bajtů, takže není možné, aby se vrátilo 10240 bajtů. Pokud chcete, aby dd dočetl data do plného bloku, musí udělat větší počet čtení, než jste mu zadal. To zapnete pomocí iflag=fullblock, jak doporučuje.

Koukam same benefity z toho naprosto umeleho prepisovani funkcnich utilit do Rustu.
Tak nejak mi unika smysl, pokud jsou aplikace odladene a battlefield tested tak proc je reimplementovat. Dobre odladeny c/cpp kod pravdepodobne bude memory safe.

No, funkcnich a dobre odladenych... posledni bezpecnostni dira tam byla loni :-) Ono ten stary kod si holt v sobe nese relikty, ktere se treba uz i prehlizi a pak najednou vyplavou. Bezpecnostnich der, na ktere se prislo az po mnoha letech bylo i v opensource svete cela rada.... proste nejsou kapacity na to veskery kod zodpovedne projit, zeano :-) Ono nekdy refactor kodu smysl proste dava...

Mi dava smysl treba to, ze se vemou jedny data, nad nima se pusti puvodni overena verze a taky nova verze a porovna se vystup.

Tohle mi prijde, jako by na to snad ani kdo zadne testy neudelal.

Chyby se stanou, ale tohle mi prijde jako slusny slendrian a rozhodne to nevzbuzuje pocit jistoty ohledne kvality tech rustovych core utils jako celku a kvality procesu jejich zarazeni do distra :-(

> Tohle mi prijde, jako by na to snad ani kdo zadne testy neudelal.

Naopak, testy mají velmi extenzivní.

Tuto chybu je testy těžké odchytit, protože nastane jen v případě, že je konzument dat z dd pomalý, a není nastavený fullblock flag.

Testy se dělají extenzivní - ale pro ty rustové utility jich stále asi stovka selhává? :-D

Ale chápu, že to asi nebudou tak zajímavé případy, jako se teď objevují. A je fajn, že se v Ubuntu obětují a ostatním to trochu líp odladí i na praktickém použití a nejen takových umělých testech.

Někdy ano, jen to nesmí dopadnout tak, že je pak 10 různých forků, a každý v jiném stavu funkcionality a svými bugy. Viz nedávný stav zranitenosti v rust async-tar...

Proti tomu přepsání nic nemám, ale nasazovat to do produkce v masivně používaném distru, když to nepokrývá 99% funkčnosti originálu, je tedy odvaha...

24. 10. 2025, 20:20 editováno autorem komentáře

Je, ale když to neuděláte, tak to nikdy neodladíte :)

Microsoft by souhlasil

Masivne nasazovana nepriznana beta ;-)

Inu, testovano na lidech :-)

Průzkum bojem.

Ubuntu bylo vždycky nepřiznané beta distro.

Ja nechtel byt zas tak konfrontacni, no

I use arch, btw

Non-LTS verze určitě. Pokud si někdo nainstaluje .10 verzi a něco nejede, čemu se pak diví?

No, alespoň to udělali teď a u 26.04, která bude LTS, to už bude snad odladěné. Případně mají prostor to vyřešit, např. tam vrátit i původní verzi a nechat na výběr.

Mimochodem odkud máte informaci, že to nepokrývá 99% funkčnosti originálu? To jste tu jen tak plácnul, nebo to máte něčím podložené?

Ty automatické testy mají teď 84 % pass, 5 % skip a 11 % fail, viz https://github.com/uutils/coreutils/releases/tag/0.3.0

Už se to tu ve vláknu řešilo.
https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-test-suite-compatibility
https://github.com/uutils/coreutils/issues taky velmi výživné

Tak ona ani safe podmnožina Rustu nemusí být memory safe a může způsobit segfault (například přistupovat k již uvolněné paměti). Krom toho se tam používá i dost unsafe Rustu, takže těch chyb tam může být více - protože unsafe Rust je bohužel složitější než C (zejména pravidla pro aliasing pointerů a referencí).

Pokus Safe podmnožina Rustu způsobí přístup k již uvolněné paměti, znamená to buď bug v kompilátoru, nebo bug v unsafe části. Tedy vlastně jde o úplně stejnou situaci jako ve všech memory-safe jazycích.

Ano, v kompilátoru je bug nahlášený před 10 lety, který nikdo neopravil. Už se dá říct, že je to spíš feature.

Njn, stari pardi dobre vi, proc tu zbytecnou blbost v kernelu nechtej. Nahrazovat neco, co funguje nejakym neproverenym kodem, a proc vlastne ?

Kdyz to funguje, tak do toho nej.b !

Ti staří pardi se shodli, že jim to nevadí, proto se to dělalo.

A asi to nebylo špatné rozhodnutí. Buď to bude fungovat a všechno bude sluníčkové. Nebo nebude a pak z toho bude ostuda a vrátíme se k tomu, co nějakou záhadou fungovalo přes 50 let (nebo k něčemu jinému).

Jediným případným negativem může být možnost, že přílišná horlivost a její důsledky zabijí zájem o Rust dřív, než se vyřeší jeho současné problémy.
Třeba, že se nepovažuje za standardní vyhazovat nepoužité funkce při kompilaci. Nebo že standardní knihovny jsou předkompilovaný obrovský blob, ze kterého se taky nevyhazují funkce, a to ani když nastavíte, že se mají funkce vyhazovat a musíte si tedy stáhnout ozdrojákovanou verzi knihoven a manuálně na ně přepnout. Nebo že to defaultně cpe debugovací symboly i do release verze. Nebo že se z binárky dozvím, kde absolutně na disku byl uložený každý zdroják, ze kterého se program kompiloval. Nakonec aby ta jednoduchá command-line aplikace komunikující po sériovce neměla 6 mega, musel jsem ji procpat UPXkem a nakonec měla "jen" 1.8. Pořád by se to ani nevešlo na disketu. A debug verze měla původně 11 mega.

Ty 50 let staré utility taky měly bugy. A afaik, GNU utility tak staré ani nejsou. Já nejsem fanda přístupu, kde se používa obsolete kód, kterého autoři se nacházejí na hřbitově, jen aby se něco nepokazilo.

Kdysi UNIX fungoval tak, že pět lidí bylo připojeno dálnopisem k PDP, když jeden něco pos*al, tak to spadlo všem. Jen probůh nedělejte žádný nový kód, aby to fungovalo dobře - neřekl zrovna Linus Torvalds v roce 1991.

to sa nám to portuje, keď niektoré funkcie proste vynecháme, a tie čo nevynecháme implementujeme nesprávne :D

Problémem, který nikdo nezmiňuje je i chybějící lokalizace pro většinu jazyků. Na rozdíl od GNU coreutils, jejichž překlady jsou na velice dobré úrovni.

Dalším problémem je pak (dle mého názoru) ne příliš vhodná, s GPL nekompatibilní (MIT) licence.

MIT je kompatibilní s GPL. Ale ne naopak.

Jedna věc je kompatibilita licencí. Ale absurdní je, že uutils borci se kvuli MIT licenci ani nesmí dívat do zdrojáků GNU coreutils pro inspiraci apod. Tj. kompatibilita je založená pouze na dokumentaci a vnějších projevech utilit.

Lokalizace to je noční můra - nesnáším bug report kde je třeba čínština, v tom se prase nevyzná :)

Proboha, co je na MIT licenci za problém? Problém je spíš to všude navirované GPL. Byl, je a bude.

Tak teď už je to osobní. Těmi VBox additions mě fakt teda zatopili. Nečekal bych, že chyba je v tomhle.

25. 10. 2025, 13:01 editováno autorem komentáře

Stačí se podívat na issues:

https://github.com/uutils/coreutils/issues

Těch chyb je tam spousta a bude to trvat roky než to odladí. Podle mě to nasazení bylo hodně předčasné.

Nebuďte dinosaurus, na nějakou stabilitu a ladění se dneska nehraje, rozkaz ten zněl jasně přepsat, popíliť... ;-)

BTW ty issues jsou fakt docela výživné, i jen první stránka by mě přivodila vrásky a vytrhané poslední zbytky vlasů.

Protože je to lepší.
A když je to lepší, tak to bude klidně i vnuceno.
A co je pro Vás špatné, to musí být zakázáno.

A cokoliv v Rustu je prostě lepší, i když to nefunguje.