Fedora 21

Pre-alfa állapotban van, de egy hirtelen ötlet alapján feltettem a gépemre. Eddigi tapasztalatok:

- sonata mpd kliens elhasal
Attempt to unlock mutex that was not locked
Aborted (core dumped)

- a Firefoxban a HUP fontjain nincs élsimítás, eddig más fontoknál nem látom ezt a problémát

- valamiért úgy tűnik roppant lassú a wireless hálózatom, a kernel 3.16.1-es. Ezt azért tesztelni kell, mert lehet szolgáltató, szerver, bármi. Az gyanús, hogy bárhonnan töltenék le, nagyon lassú

- a Xorg.bin a root nevében fut, holott talán sima felhasználóként kellene. Ennek viszont lehet, vannak feltételei, így utána kéne olvasnom

-amúgy működik

Update1:

Találtam újabb két hibát:

- az Evince-n ugyan működik a zoom, de ha a legördülő menüt használnám zoom-ra, elhasal

- hibernálásból felébredve nouveau video driver-t használva nincs kép. Olyannyira, hogy a monitor standby-ba megy. Ugyanakkor Ctrl-Alt-F2-vel konzolra tudtam váltani, bár ezt sem láttam, mert kép továbbra sem lett. Beléptem "vakon" root-ként, és továbbra is monitor nélkül kiadtam a

systemctl reboot -i

parancsot. Azért így, mert hibernálás után sima felhasználóként be voltam lépve, nem engedte volna újraindítani a gépet. Végrehajtotta, újraindult.

Feltettem a Fedora 20 3.15.10-es kernelét, s két dolgot teszteltem: a wireless hálózati bajomat és a hibernálást. Mindkettő hibátlanul működött, tehát a hálózat gyors volt az eredeti TL-WN722N interface-szel, továbbá hibernálásból úgy ébredt fel, hogy volt videojel.

Szomorú dolog, hogy a kernel.org-on már stabilnak mondott kernelben ilyen csúnya regressziók vannak, ezek a kifutott 3.15.10-esben még működtek.

Update2:

Talán a gdk-pixbuf2 vagy a pango frissítésének köszönhetően végre működik a sonata mpd kliens.

Ugyanakkor a 3.16.2-es kernelben továbbra is ott van a wireless regresszió és a korábban jól működő nouveau driver elromlása is.

Update3:

Evincét javították, ath9k_htc bugjára van workaround, ezt hozzászólásban írtam.

Update4:

Nézem a hamarosan megjelenő 3.16.4-es kernel changelog-ját, az ath9k_htc regressziója végre javítva lesz:

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index bb86eb2ffc95..f0484b1b617e 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -978,7 +978,7 @@ static bool ath9k_rx_prepare(struct ath9k_htc_priv *priv,
        struct ath_hw *ah = common->ah;
        struct ath_htc_rx_status *rxstatus;
        struct ath_rx_status rx_stats;
-       bool decrypt_error;
+       bool decrypt_error = false;
 
        if (skb->len < HTC_RX_FRAME_HEADER_SIZE) {
                ath_err(common, "Corrupted RX frame, dropping (len: %d)\n",

Update5:

Addig javítgatták, hogy magától nem rántja be a loop nevű kernel modult. Ez loop device-okhoz kell. Fogalmam sincs, ez pontosan hogyan van, kinek a dolga, mindenesetre, mint systemd bugot, jeleztem a bugzillán.

Az élsimítós problémán kívül minden más megjavult a régi bajok közül.

Update6:

Megjavultak az egyes weblapoknál eddig ronda fontok. Most már azok is élsimítottak. Visszanézve a history-t, a xorg-x11-font-utils és a libfontenc csomagok frissültek, legalább is ezeknek lehet közük a probléma megjavulásához.

Még nincs kint a béta változat sem, s eljutott oda a Fedora 21, hogy számomra minden jól működik, már az apró kellemetlenségek is elmúltak. :)

Update7:

Azóta egy újabb gépet upgrade-eltem yum-mal Fedora 21-re. Semmilyen probléma sem ütötte fel a fejét.

( sherpa v | 2014. 08. 15., p – 08:50 )

:)
Te vagy az én Trey-m Fedora-ban
Amikor frissítesz, akkor mindig elgondolkodom én is, hogy mondjuk fél év múlva frissítenem kellene.
De azt hiszem, egy kicsit hamar nyúltál hozzá, lehet, hogy 9 hónap lesz belőle :)

Üdv

Épp ráértem, kíváncsi voltam, a Fedora 20 meg már unalmasan tökéletes volt. :)

A frissítést yum-mal csináltam, volt 3 függőségi problémája. A --skip-broken 2400 csomag környékén nem járható, mert akkor függőség miatt kihagy néhány csomagot azok függősége miatt újabbakat, végül az jött volna ki, hogy 320 csomagot frissítene, pár ezret meg nem.

Azt csináltam, hogy megnéztem, az egyik függő csomagra nincs szükségem - flashrom, ez BIOS update-re való -, ezt letöröltem. Maradt két csomag, a GraphicsMagick és a splix, ezek ugyanattól a library-től függtek. Nyomtatni szeretnék, szóval a splix kell. Viszont észrevettem, hogy a koji buildszerveren már lefordították a legújabb lib-hez ezt a két programot. Letöltöttem őket, majd createrepo_c paranccsal lokális repo-t csináltam, s a yum.repos.d-be írtam egy local.repo file-t, így innen vette a legújabb GraphicsMagick és splix csomagokat, amelyek a koji-ról származtak. Ezzel hiba nélkül lefutott a distro-sync Fedora 21-re. :)

Alfa előtti állapotot még sohasem használtam. A hálózat lassúságát kell megnézzem, az összes többi probléma nem izgat. MPD kliens van rogyásig, addig használok mást, de akár terminálról az mpc-t, az működik. A csúnya fontok tényleg csak itt a HUP-on jönnek elő, lehet, hogy egy adott fontcsaládot sújt a dolog, nem tudom, de attól még olvasható. Úgy általában van élsimítás, csak itt nincs.

Amúgy meg működik, pont nem izgat, hogy pre-alfa még. Tény, hogy vakmerő voltam, ez az egyetlen otthoni gépem, a host-on csináltam, még csak nem is virtualizálva.

Jut eszembe, a VirtualBox is gond nélkül megy rajta. Nem is vártam mást, hiszen a VirtualBox-ot is módosítják szükség szerint az utolsó vanilla kernelhez, Fedora 21-hez meg a mindenkori legfrissebb kernel van, jelenleg 3.16.1.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 08. 15., p – 11:37 )

A sonata bugját jeleztem a bugzillában.

Megnéztem a boot.log file-t, csak szép zöld OK státuszú üzenetek vannak benne, ami egy pre-alfa állapotú oprendszertől várakozáson felül szép.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 08. 15., p – 13:21 )

Úgy látom, közelítek a wireless lassúságának felderítéséhez. Na, nem kód szinten, pusztán bug jelentés közelébe jutottam. Fedora 20-on jól működött a TP-Link TL-WN722N interface-em, Fedora 21-ben az újabb NetworkManagerrel, kernellel viszont az iwconfig igen sok invalid misc. csomagot reportol. Ha jól értem, ezek a wireless infrastruktúrához tartoznak, alsó rétegbeli csomagok, amelyek például a csatornát, sebességet beszélik meg.

Van egy másik wireless interface-em is, ez Realtek RTL8187B, ezzel sokkal gyorsabb a kommunikáció, pedig ez utóbbi belső antennás. Eredendően az előbbi képes többre, csak most nagyon nem.

Szerk.: bugreportoltam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Semmi. Kellene csomag. Arra gondoltam, hogy nem esélytelen, hogy valaha lesz, mert a fejlesztők látőkörébe került a project. Azt nem tudom, hogy van-e mód direkt csaomagot kérni, s ha igen, mennyire hajolnak meg a közakarat előtt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 08. 16., szo – 11:46 )

Van update. :) Ott fenn, a blog leírásában.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 09. 06., szo – 10:31 )

Van frissítés: sonata jó már, kernel még rossz. Maradok egyelőre a 3.15.10-esnél.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 09. 06., szo – 22:11 )

A compiz-manager wrapper scriptben volt egy bug, kijavítottam, a patch-et bugzillára elküldtem, az új rpm már meg is jelent a buildszerveren. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( 4fonya | 2014. 09. 25., cs – 20:08 )

Van már 3.16.3-as kernel, de az írásod hatására még mindig a 3.5.10-et használom és nem engedem hogy a yumex föltegye az újabbat.

A wireless bug csak az ath9k_htc driver-t érinti. Addig kerestem a neten, amíg megtaláltam. Egy inicializálatlan boolean változó okozza. Ez a változó azt mondja, hogy hibás a kódolt csomag. Mivel nem false értékről indul, hanem memóriaszemétről, így egy rakás jó csomagot is eldobál, ezért lassú. A probléma megkerülhető úgy, ha a kernelmodulnak elmondjuk, hogy megtiltjuk a hardware-es kódolást. Ekkor némi CPU időt beáldozunk, cserébe viszont működik.

A nouveau hibája nem tudom, hogy valóban az-e, mert más gépen nem teszteltem. Simán lehet, hogy az alaplapom nem támogat olyan dolgot, amit másképp csinálnak, mint korábban.

Mindamellett lehet, hogy jól teszed, ha esetleg megvárod a 3.17-es sorozatú kerneleket.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A wireless nem érint mert nincs semmi ilyen eszközöm, a nouveau-t pedig alapból tiltom, mivel az nvidia meghajtó csomagját szoktam lefordítani. Ezzel együtt a mostani kernellel semmi bajom, tehát ennél maradok. Annyi disznóságot tapasztalok hogy a gép leállításakor a folyamat néha elakad. A grafikus felületről mindig kilép, de néha nem tudja lecsatolni a titkosított területet és emiatt nekiáll malmozni. Csak próbálja és újra próbálja. Ilyenkor régebben - jobb ötlet híján - pár perc után egyszerűen áramtalanítottam a gépet. Egy ideje már azt csinálom hogy négy-öt másodpercig heverészek a Ctr+Alt+Del billentyűkön. Ezután ha Esc-et ütök akkor eltűnik a Fedora logó és látom a kernel kiírásait. Egy csomó piros kiírás több sorban a Ctr+Alt+Del miatt és köztük látszik a lecsatolási próbálkozások szövege és egyszercsak sikerül neki. Innentől már símán lekapcsol. Hogy ez a systemd bűne-e vagy sem azt nem tudom. Esetleg egy folyamat elakad valamilyen lemezművelettel a titkosított területen és a kernel ezért nem tudja azt leválasztani.

Gyanítom, a systemd csak szolgaian vár a zárolások feloldódására. Gondolom, valaki fogva tartja egy nyitott file-lal a filerendszert.

Nem tartom kizártnak, hogy a systemd konfigurálható, hogy adott idő után akkor is vágja ki a process-t, ha azt SIGTERM-re nem sikerült.

Ha megnézed a manualt, van systemctl poweroff --force, valamint brutálisabb formája, a systemctl poweroff --force --force. Legalább is, ha jól értettem ezt:

If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss.

Mondjuk ez utóbbi nagyjából a konnektorból kirántás esete.

Ja, és ha jól emlékszem, az inhibitet is felül lehet bírálni:

systemctl poweroff -i

Bár ez utóbbit most nem látom a doksiban. Lehet, már a --force van csak?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Értelek. Ez azért nem triviális probléma, mert ha a systemd nem vár, az adatvesztést okozhat, ha vár, akkor meg hibás programok miatt nem áll le soha a gép. Kompromisszumként azt lehetne, hogy vár, majd mondjuk 2 perc elteltével elfogy a türelme.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 10. 04., szo – 12:07 )

Az ath9k_htc hamarosan meggyógyul. Igaz, nem volt égető a dolog, volt rá workaround.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 10. 07., k – 00:35 )

Az a fura érzésem támadt, hogy az Xfce sokkal gyorsabban indult a 3.17-es kernellel. Méréssel nem tudom alátámasztani, szubjektív, amit írok.

Van objektív dolog is. A kernel konfigból kimaradt ez a sor:

CONFIG_ZBUD=y

Ezáltal a zswap nem működik.

[    1.179477] zswap: loading zswap
[    1.180360] zswap: zbud zpool not available
[    1.180459] zswap: zpool creation failed

Bugzillán jeleztem a problémát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 11. 01., szo – 02:11 )

Update5-öt kell nézni...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 11. 02., v – 10:49 )

Van Update6 is: a fontok megszépültek, jó az evince, működik a hibernálásból való felébredés, a wireless, a sonata, szóval minden jó.

Bár, a sonata, mpd párost lehet, audacious-ra fogom cserélni. Eredetileg azért kezdtem mpd-t használni, mert tetszett a sonata egyszerű felülete, valamint tudott értesítési területre dokkolódni. Ugyanakkor megfelelő beállításokkal az audacious is képes dokkolódni a system tray-re.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 11. 05., sze – 01:55 )

Ezt csak hozzászólásban írom. Nem tudom, melyik systemd build van a repókban, én a Koji build szerverről szoktam frissíteni néhány csomagot, a systemd-t is. Jelenleg az utolsó lefordított systemd-216-10.fc21.x86_64 bugos, a hiobát jelezték, magam kiegészítettem a hibajegyet. Az utolsó, működő verzió a systemd-216-8.fc21.x86_64.

A hiba annyi, hogy leállás helyett újraindul a gép.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 11. 09., v – 00:01 )

Eddig mpd-t használtam sonata klienssel zenehallgatásra. Jó volt, de valami oknál fogva olykor elfelejtette a státuszát, az aktuális lejátszó lista üres lett egy boot után. Nem kezdtem el keresni az okát, áttértem audacious-ra.

Az audacious képes értesítési területre dokkolódni. Elindítom a login alkalmával futó script-emből, így használatra készen ott vigyorog a system tray-en.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 11. 11., k – 01:10 )

Vicces történet...

Audacious-t kezdtem használni az eddigi sonata + mpd páros helyett. Egyből találtam is hibát. Na, de milyet?

Az audacious a natív pulseaudio output plugin használatával néha elakad a lejátszásban, a pulseaudio panaszkodik is, hogy

Client sent non-aligned memblock

Elnémul a lejátszás, megáll az idő, de playing státuszban marad. Ugyanakkor reagál a kezelőszervekre.

Kipróbáltam a Simple Directmedia Layer output plugint is, amellyel hibátlanul megy. Szerencsére a pulseaudio-ban implementálták ezt a felületet is. A pulse által felkínált, emulált ALSA felületen is működne nyilván.

Szóval az a vicces benne, hogy épp a natív pulseaudio interface-t szúrták el, az egyéb felületek mennek.

Bugreportoltam, rá is haraptak, kértek még infót, leírtam, szóval sanszos, hogy ki fog javulni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Viszont lehet, némileg belefutottam a pofonba. Azt írják, ez az interface régóta nem változott, én meg feltettem a build szerverről a legutóbb fordított pulseaudio-t, s egyre inkább úgy néz ki, hogy ez ennek a legfrissebb, még repókba sem került pulseaudio-nak a bugja.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 11. 19., sze – 20:47 )

Letiltották a testing repókat, szóval célegyenesbe fordult. Már produktív környezetbe, irodába is tettem, semmi gond nincs vele.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE