Nesetkali jste se náhodou někdo s následujcí chybou při upgradu Ubuntu?
Upgraduju ze 14.04 na 16.04 pomocí do-release-upgrade a pokaždé mi to zůstane viset po následujícím:
...
Preparing to unpack .../systemd_229-4ubuntu21.23_amd64.deb ...
Unpacking systemd (229-4ubuntu21.23) ...
Setting up systemd (229-4ubuntu21.23) ...
Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service, pointing to /lib/systemd/system/getty@.service.
Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target, pointing to /lib/systemd/system/remote-fs.target.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service, pointing to /lib/systemd/system/systemd-timesyncd.service.
Initializing machine ID from random generator.
Adding group `systemd-journal' (GID 120) ...
Done.

(bez jakéhokoliv posunu i po několika hodinách). Můžu to samozřejmě zabít, ale evidentně to pak zůstane v nějakém polovičním stavu (i po restartu); apt/dpkg hlásí zamčené adresáře, nenajde to ani příkaz reboot, snad ani systemctl... Přijde mi, že se nejspíš nedotáhne pořádně instalace systemd. Netušíte někdo, jak by se tomu dalo pomoct?
(Tohle to poměrně přesně popisuje, nicméně bohužel bez pomoci: https://askubuntu.com/questions/1115271/dist-upgrade-stops-at-adding-group-systemd-journal)

SUK: Vysloveně se stejným problémem ne, ale rawtherapee mi stále padalo, bylo dost nespolehlivé celkově tak jsem přešel na ten DT a s tím jsem spokojenej a pokud si správně pamatuju tak mi to nikdy nespadlo a neměl jsem s ním nikdy žádné problémy...

CHOROBA: Jo, neco si tam cachuje, ale to by nemel delat behem exportu a i kdyby jo, tak to nesmi zadrhavat mys :)

JUNIOR: DT mi nesedl a docela mi i padal, RawT fungoval doted dobre. Dokonce nekdy v Q3 minulyho roku optimalizovali de-mozaic, takze na tom mym Atomu jsem na fotku misto dvou minut cekal jen 10 sekund. Kazdopadne, ty ses setkal vyslovene se stejnym problemem?


DELVIT: Ach tak, ne. Nebezi mi nic takovyho, mam relativne cistej sysem :)

SUK: myslel jsem něco jako Akonadi. Ale podle toho jak to popisuješ tak to tím nebude.

SUK: Přesně kvůli tomuto jsem přešel na Darktable. Tam mi všechno běhá mnohem lépe. Ještě teď s tou novou verzí 3 je to prý mnohem svižnější - neměl jsem zatím důvod přecházet tak nemohu porovnat...

SUK: na IO je lepsi atop nez htop

hele jen letmy vhled na rawtherapee a pisou tam, ze si to pro sichr vsechno dava do cache na disku. tak mozna esli neexistuje nejakej switch aby to nedelal

VESNACH: htop vypada neskutecne v klidu, ten stroj se nudi, ani plny IO buffery nejsou. iotop hlasi obcasny zapis/cteni 30 mega (to odpovida tak nejak zdrojovymu RAWu a cilovymu jpegu (ktery jsou fakt veliky)).

ten SMART proverim, ale i kdyby byl disk kompletne v riti, neexistuje duvod, proc by to melo zapisovat na interni disk

MARASAN: vzhledem k tomu, ze se to nudi, tak mi nice asi moc nepomuze (mozna ionice?). Zkusim to, moc od toho ale necekam.


Jinak jsem vcera jeste neco kopiroval na flash/ext. disk a vsiml jsem si, ze strasne dlouho trva sync/eject. Takze hadam, ze bude bud spatne neco v zen-kernelu (vanilku jsem zatim nezkousel) a nebo vyslovene v mym kompu. Diky za tipy

SUK: pust to s nice 15, co?

SUK: ja bych teda pustil htop, podival se na cem se to vydrdava, s tim diskem musi neco delat, resp. ti neco musi zrat zdroje...pripadne jestli nemas disk pomalej na IOcka nebo upsanej pred smrti treba? smartctl

DELVIT: RawTherapee si naindexuje (+ extrahuje z RAWu nahledy) hned po otevreni slozky, ale to problem nedela, nastava az pri zpracovavani fronty. Kterou navic exportuju nekam jinam a ten cil to tim padem nezpracovava.

SUK: hele neindexuje ti to něco? Zkusil bych to vypnout.

DANIELSOFT: To zkusim, jen se obavam, ze z toho asi nic nezjistim - predpokladam, ze krom read/write syscallu tam nebude nic zasadniho. Koneckoncu si myslim, ze userspace aplikace by nemela mit moznost zasekat system tak, ze se bude zadrhavat i kurzor mysi. Pro jistotu upozornuju, ze tahle masinka zvladne kompilovat kernel v osmi vlaknech (cimz zabere temer celou RAM) a i tak lze pocitac porad celkem bez problemu pouzivat (zpomaleni je teda uz docela znatelne, ale nic se nezadrhava).

SUK: nejak pres strace zjistit, co se pri tom vola?

Ja mam furt problemy s tucnakama, nebejt widle tak hrozny, tak snad prejdu zpatky :D

Mys mi to od minule prestala delat. Nicmene jsem zacal mit jinej problem - kdyz necham zpracovat frontu fotek v RawTherapee ("vyvolavani" RAW fotek), tak se pocitac stane naprosto nepouzitelnym. Chova se to, jako bych mel nedostatek pameti pro zpracovani a musel si uplne vsechno odswapovat. Ackoliv fotky (jak RAWy, tak finalni JPEGy) mam na externim disku, brutalne zacne hrabat interni disk a po dokonceni pak trva, nez se to "odswapuje". Nicmene, RAM zaplnena nebyva ani z poloviny.

Takhle hrozne se nechoval pri stejne cinnosti ani Atom s 1GiB pameti a nedavno se to vubec nedelo. Poradi nekdo, jak bych takovouhle vec mohl diagnostikovat? Dikec :)

JUNIOR:
DANIELSOFT:
Tak nakonec problém s grafickým ovladač (prý). Jsem upgradoval na nový MInty a jede to ve stejném nastavení...

DANYSEK: tak problém je nejspíš s přístupovými právym ake nevímn, jak nastavit rwx pro celé médium. Cokoliv připojím a uložím přes USB mi jiná zařízení neotevřou

MCKIDNEY: Snapshoty ceho?
Produkcni serery jsou VPS, mam tam LVM a ext4.
Pokud myslis snapshoty LVM, napsal bys mi, jak to resis ty, pripadne mi vygooglil nejake smysluplne howto, mne se to nepovedlo. Diky

MRDAC_BEDEN: To je hrozne neefektivni reseni. I ten rsync je brutalne pomaly. Mrkni na snapshoty a pokud chces aspon zvedni block size na maximum pro rsync. Nezapomente ze rsync existuje pro snizeni datoveho toku - ne pro rychlost ci nizkou zatez.

MRDAC_BEDEN: a stejne velky problem je mazani - smazani zalohy trva nekolik hodin.

partitiona fs je vytvoreny a primountovany s defaultnimi paramtery
mount | grep storage
/dev/md3 on /storage type ext4 (rw,nodiratime,relatime,errors=remount-ro)