Nos a restrict_mprotect() mindjárt megakasztotta
az openoffice.org-gcj csomag eltávolítását, és ezzel első körben bedöntötte a frissítést.
paxctl -m /usr/bin/gcj-dbtool-4.1
Ez a parancs átlendítette a holtponton a történetet. És le is zajlott a frissítés, de a gnome terminalja - gőzőm sincs hogy hívják, élesben nem használok gnome ot évek óta, csak gondoltam miértnetesztalatt - pl. nem akarta az igazságot. És annyit nem ért, hogy nyomozzak utána. Felment csak nem ment. Mondjuk azt sem értettem ha etch ben megvolt, akkor dist upgrade nál hova tűnt. Külön fel kellett tenni. És nem is ment.
Valószínűleg néhány csomagról a frissítés idejére le kellett volna venni a restrict_mprotect()et. élesben az nvidia-bináris driver miatt elég sok ilyen GL* csomag lesz. A dolog utólag is kezelhető, mert a libc6on és a működéshez elengedhetetlenül szükséges csomagokon átlendül, tehát azok frissülnek.
Még filózom rajta hogy a frissítés idejére vagy az összes emiatt HOLD ra tett csomag - végül is mégsincs olyan sok tizenvalamennyi? - ot majd kézzel átteszem. vagy pedig 2lépcsős frissítés lesz.
Egyszer élesben aptitude -d download. feltolok egy sima nativ 2.6.27.10 es kernelt grsec és hálókártya driver nélkül, és az megoldja a frissítést, és utána visszabootolok a normál kernelre.
Mivel lustaság fél egészség valszeg ez utóbbi lesz majd. de még nem tudom.
A hang kezeléssel mindenesetre sem voltam lenny alatt megelegédve, de ez lehet a kvm miatt van. Sajnos a deb backportban olyan kvm et találtam amiben az SDL/ALSA broken, így elvileg nincs hang. szépen failedekkel indul, google n kerestem sajnos ez egy ilyen verzió.
OSS elég kényelmetlen, mert lefogja a hangeszközt, viszont PaX megoldotta a problémát. Ugyanis a broken probléma SDL failed nem jelentkezik ha a KVM en fullos védelem van (PAGE/SEGMexec + restrict_mprotect) , ha leveszem, akkor szar lesz, de ha rajta marad akkor meg jó.
hang is van. Érdekes. :-)) Általában a korlátozás nem szokott inkompatibilitási problémákat megoldani, inkább generálja, de itt most mégis ez történt :-))
ess1370est használtam, mert sajnos ebbe a kvm be mást nem fordítottak bele ami használható. újat fordítani meg lusta voltam.
Szóval a hang lennyben nem volt az igazi, gnome nál a beállításoknál a "rendszerhangok" nyomogatására nem reagált. A beállításokat elvileg etch ből örökölte, ott jó volt, lenny ben meg nem jó. Persze ez is lehet a restrict_mprotect() miatt. Lehet hogy gnome frissítésnél is a gnome alap csomagokról le kell venni . (mint pl. kdeinit ről kde nél, frissítés után nem megy pl. a zárolás ) A lista megvan, csak a HOLD os csomagok listája több mint 10, és ez már lassan eléri a lustasági küszöbértéket... De lehet hogy ez még ilyen RC bug, nem nyomoztam utána. hang amúgy volt, mert ugyanazt a fájlt mplayer rel lejátszotta, de a gnome beállítások teszt nél vagy hogy hívták meg nem.
Etch el jelen állás szerint elégedett vagyok, az is lehet hogy r1 et megvárom lenny vel. Még nem tudom. A kernel az mostmár 99,98% hogy a 2.6.27 szériából megmarad. Ami végül is jó lenne, az a v86d, mert kidobhatnám a gányolásomat ami a vesafb nem megfelelő dpms támogatása miatt került be.
A wine külső repora valami megoldás kell, mert Bad Exe format nem indultak a cuccok.
- Oscon blogja
- A hozzászóláshoz be kell jelentkezni
- 765 megtekintés
Hozzászólások
A Gnome terminaljat meglepo modon gnome-terminal -nak hivjak :-) Bonyolult lelkulete van am!
A rendszerhangok tesztje lehet azert dobott falsot, mert az adott fajlok egyszeruen hianyoznak. Azt hiszem, gnome-audio vagy gnome-sounds a csomag neve, amit fel kell pakolni.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Fent volt. Ugyanazt a hangfájlt mplayer lejátszotta, gnome viszont nem.
Menüből próbáltam alkalmazások terminál. etch ben fent volt ment, aztán dist-upgrade után e'tűnt.
-------------
r=1 vagyok, de ugatok...
- A hozzászóláshoz be kell jelentkezni