Forum Debian Users Gang

Jaka wersja udeva?

3.0-rc4 zainstalowałem, działa.
Konfig do Gentoo zrobiłem z konfigu Debiana przez localyesconfig.
Coś zauważyłem:
Jajo obecne:

 zgrep -i pty /proc/config.gz
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=0

Wszystko chodzi.

Na 3.0-rc4 na takim ustawieniu nie działa ani xterm, ani inny terminal, nawet na koncie root.
Jajo Debiana:

grep -i pty config-3.0.0-rc4-686-pae
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set

na takim ustawieniu w w 3.0-rc4  Gentoo nie działa żaden terminal.

zgrep -i pty config-3.0.0-rc4
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

Sukces, root ma terminal, userzy nie.

Do tego najciekwsza nowina:

grep -i pty linux-3.0-rc2/.config
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=0

- wszystko pięknie działa - w zakresie terminala.
Nie działa za to prawidłowo Vesa, ani Uvesa, konsola przypomina horror z ZX Spectrum.
Jajo rc4 na konfigu z rc2 nie wstaje w ogóle.
Konfig z rc2 powstał przez oldconfig z kernela 2.6.37-tic - najlepszego w mojej karierze, tego z TOI, grsecurity i autogroup.

Także chyba poczekam na stabilne jajo 3.0, bo dość się nakombinowałem z ACPI w 2.6.38/39, żeby teraz kombinować jak koń pod górę z następnym cyrkiem.
Zobaczę, czy w rc5 będzie to samo, wersje rc u mnie przypominają totolotka, każda działa inaczej od poprzedniej.
A stąd wnioskuję, że w kernelu trwa chyba ostre porządkowanie i optymalizacja kodu, co ma też dla mnie dość pocieszne skutki.
Od kernela 2.6.38.4 mam z kernelami jak nie urok, to sraczkę ;)
Po kolei: ACPI, Noapic w vaniliowych,  konflikt Paxa i Nvidi w łatanych, ogólnie dość wesoło.

rc2 bez łat  działało, biorę rc4 - make oldconfig, dodaję do gruba, reboot, czarny ekran, zero reakcji..., wywalilem opcję quiet, odpalam, kailkaset linijek testku i jest samoczynny  halt+blackscreen.

Jedno, co mi się naprawdę przyda, to wiadomość, jak zgrać na dysk log debug  z uruchomienia kernela, bo bez tego, to mogę szukać igły w stogu siana.

EDYTA:

qlist -IvU udev
sys-fs/udev-164-r2 (extras selinux test)

U mnie ten link http://pastebin.com/86VXHUmH
otwiera się bez problemu na FF5 i Chrome.

Edyta2:
sprobuję najmłodszego udeva...
I guzik:

qlist -IvU udev
sys-fs/udev-171-r1 (acl extras introspection rule_generator selinux test)

Start kernela, mieli dyskiem, nie montuje konsoli,Openrc wstaje w tle, nagle wstaje GDM, mam obrazi dxwięk, potem dopiero mam konsolę.
Na moje oko to błąd w jaju, i to dość głęboko.
W Ubuntu kiedyś był taki cyrk z jajem dystrybucyjnym, poprawili to po tygodniu.
Poza tym małym drobiazgiem jajo chodzi elegancko, szybko i płynnie.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2011-06-26 13:25:48)

Jak się trochę ochłodzi :), to skompiluję tego diabla bezpoścednio na konfigu Debianowatym, tylko muszę sobie przypomnieć, jak się generuje initrd w Gentoo ;)

Edyta:
W tym logu,
http://pastebin.com/7Z2nbeMm
pomiędzy linią 700 a 956 jest wyjaśnienie problemu.
Ale to chyba trochę za wysokie progi dla mnie.

Ostatnio edytowany przez Jacekalex (2011-06-26 13:43:53)

Krótko piszac, ja do Debianowego konfigu zrobionego przez localyseconfig nic nie dodałem nowego, a problem wygląda na jakięś nowe zabezpieczenie.
Log strace -f xterm: - kawałek z 991 linni.

2953  open("/dev/ptyp0", O_RDWR)        = -1 EACCES (Permission denied)
2953  open("/dev/ptyp1", O_RDWR)        = -1 EACCES (Permission denied)
2953  open("/dev/ptyp2", O_RDWR)        = -1 EACCES (Permission denied)
2953  open("/dev/ptyp3", O_RDWR)        = -1 EACCES (Permission denied)
2953  open("/dev/ptyp4", O_RDWR)        = -1 EACCES (Permission denied)
2953  open("/dev/ptyp5", O_RDWR)        = -1 EACCES (Permission denied)

Tylko musiałem wejść na roota, tam odpalić terminal, w nim przelogować się na usera, i odpalić debugowanie xterma :)

Objawy takie, jakby nie byl zamotowany /dev/pts, tylko że jest zamontowany, a jajo nic o tym nie wie, pomimo, że w /proc/mounts jest normalny wpis, taki, jak zawsze.

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

Pojęcia nie mam, jak to ugryźć.
Na razie fajrant, w czwartek lub piątek będzie rc5.
Bo coś mi się wydaje, że w kernelu jest jakiś banalny bląd, który Developerzy kernela z Debiana znają, i poprawili, a ja go nie znam.
Możliwe też , że blad jest innego rodzaju:
np tuner Tv, kiedy wbuduję moduly na stale, jest dostępny tylko dla roota, /dev/video0 ma uprawnienia 700 - i nic nie pomaga, załadowany modul zewnętrzny powoduje, że /dev/video ma chmod 750 i właść root:video - czyli prawidłowo.
I tu prawdopodobnie jest taka sytuacja z /dev/pty* - załadowany modul z initrd inaczej działa, wbudowany troszkę inaczej.

Pizdrawiam, i dziękuję, jeszcze się tym trochę pobawię, mam też  nadzieję, że stabilny 3.0 nie będzie mial takich klocków.
Na razie temat na kołek , czekam na rc5, sprobuję też tego konfigu na rc3  lub rc2.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2011-06-26 14:04:47)

Bardzo możliwe.
Choć też obstawiam kilka innych możlowsci:
np, kto uzywa tekiego kompilatora?

gcc version 4.4.5 (Gentoo Hardened 4.4.5 p1.2, pie-0.4.5)

Poza tym, główne problemy z kernelami mam z ACPI, na plycie Gigabyte, wiem, że u innych Ludzi to czy tamto dziala, a u mnie nie.

Codo testowego kernela 3.0.0 - to już wyczaiłem głowną zmianę: pomiędzy rc2 a rc3 wprowadzono zmiany, po których mój konfig z rc2 powoduje tylko blackscreen.

Edyta:
Nareszcie koniec problemów (mam nadzieję)
problem z Acpi zacząl się w kernelu 2.6.38.4, trwal do kerneli 2.6.39.1 i 2.6.39-gentoo-r2.
Myslalem, ze coś trzeba w konfigu sprawdzić, czy coś w ytym guście.
Dlatego kilka razy robilem konfig od nowa, bez sukcesu.
Tymczasem wczoraj skompilowalem jajo 2.6.39.2 (vanilla-sources) - i ACPi ruszyło, a caly kernel konfigurowalem 30 sekund - bez klopotu dziala na konfigu z 2.6.37-tuxoncie - wcześniejszego kernela, nic nie zmieniałem.

Z kernela  2.6.39.2 - poprzez make oldconfig zrobilem konfig do 3.0.0-rc5 - ruszył, właśnie działa.
Ruszył, jakby nic się nie stało, a kłopoty z kernelami 3.0.0-rc3 i 3.0.0-rc4 były złym snem.
Podobnie wczoraj, 2.6.39.2 ruszył, jakby cyrki z ACPi w kilku wcześniejszych wersjach mi się tylko przysniły.

Pewnie te przejściowe trudności były wynikiem gruntownej optymalizacji kodu, jake byla zapowiadana w okolicach kernela 2.6.38, i ma docelowo zmniejszyć liczbe sterowników w kernelu (poprzez ich unifikację), i zmniejszyć objętość źródel kernela poniżej 200 MB - z ponad  300 MB obecnie.
(czytałem o tym kiedyś na polskim heise).

W każdym razie system działa, teraz obaczym Xena.
:D

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2011-06-28 11:27:20)