Udzielone Odpowiedzi
- Posty
Nie wiem jak w Gnome, ale… zadaj konkretniejsze pytanie, bo miejsc gdzie się można „podpiąć” jest sporo. Napisz również o jakie programy Ci chodzi, albowiem ich konfiguracja – na razie – jest różna. Piszesz „kontakty i kalendarz”… chodzi Ci o Kmail i Kalendar?
Ciekawe dlaczego problem z programem wykorzystywanym w procesie kompilacji, powoduje kernel panic
Prawdopodobnie do repozytorium przeszło nowe glibc (bo jest już 2.25-7), ale co najmniej niektóre paczki, które winny zostać przebudowane nie zostały poddane temu procesowi.
glibc w stable w wersji 2.25-7 pojawiło się 14.07, Manjaro 17.0.2 jest z 20.06 i tam jest glibc w wersji (prawdopodobnie) 2.25-3.
Kolejne kroki opisane w rozwiązaniu są takie:
– aktualizacja, czyli otrzmymujemy glibc 2.25-7 i konsekwencja kernel panic,
– podmiana ld do wersji 2.25-3 i wszystko działa.
Inna sprawa, że to prowizoryczne rozwiązanie i na dłuższą metę system może się pogubić. Będzie wszak miał jedną bibliotekę – ld – z innej wersji niż w nim powinna być (2.25-3 zamiast 2.25-7), ale będzie „myślał”, że ma glibc w wersji 2.25-7. Kiedy trafią paczki zbudowane już z wykorzystaniem glibc 2.25-7 (a to w Archu jest od 13.07 i programy są już budowane na nim), to coś innego może się pogubić.
Wg mnie – jeśli glibc jest przyczyną, to sensowniej jest – choćby czasowo – jeśli ktoś potrzebuje aktualizacji systemu, to przejść na gałąź testing. Tutaj kernele, przynajmniej te „świeże”, o których była mowa w wątkach, jak 4.9, 4.12, są przebudowane już po pojawieniu się glibc w nowej wersji – istnieje zatem prawdopodobieństwo, że będzie to działać poprawnie.
Drugie rozwiązanie – oczywiście nie sprawdzane przeze mnie – to czasowe dodanie glibc do IgnorePkg w pacman.conf i aktualizacj. W stable powinno zadziałać. W momencie, gdy pojawią się jakieś nowe aktualizacje, szczególnie dotyczące tzw. paczek systemowych – należałoby pozwolić już na aktualizację glibc. Wiele nie ryzykujecie, bo „rozwiązanie” znane. Polecałbym jedynie ściągnąć sobie na jakiś nośnik również glibc 2.25-7, albowiem jeśli przy zablokowaniu tej paczki pojawią się jakieś problemy ze startem, to będzie to oznaczało konieczność zainstalowania tej paczki.
Generalnie, to proponowane rozwiązanie uznać należy za protezę, która niestety może odbić się czkawką. Podobnnie jak w poprzednim akapicie, proponuję ściągnięcie sobie glibc 2.25-7 i w razie czego dokonanie aktualizacji z tej paczki (lub podmianę pochodzących z niej ld).
Oczywiście jeśli ktoś ma multilib to potrzebował będzie jeszcze paczki lib32-glibc.Prawdopodobnie nic nie wiadomo. Mam nie dość, że Archa, to jeszcze testing. Fakt – również miałem problemy.
Jak się bawisz, to się baw – zainstaluj sobie… Archa za pomocą arch-anywhere i zobacz czy jest to samo/podobnie.
O co chodzi z „podpisywaniem” przez glibc absolutnie nie wiem, albowiem to raczej do podpisywania czegokolwiek nie służy, ale też i nie powinno mieć znaczenia do czego służy. Inna sprawa, że glibc winien być w systemie po instalacji.Dlaczego montujesz sda1 pod /boot systemu, z którego chrootujesz?
dmesg jest z zainstalowanego systemu?Dlaczego nie skorzystasz z mhwd-chroot? (tak to się chyba tu nazywa).
Polecenie chroot na /mnt nie może się w tym przypadku udać.Skończ z postponowaniem azji, a powiedz dokładnie jak przeprowadzałeś chroot.
Inna sprawa, że mi się nie udało :(I tak nie minie Cię chroot (choć mi się nie udało) lub reinstalka. Jeśli uda Ci się chroot – dokonaj tam aktualizacji i zrób sync (powinien się udać). Jeśli instalacja – to zamiast restart „w normalnym trybie” wydaj w konsoli:
sync && reboot
Głowy nie daję, że się uda.
Faktem, że przez bodaj 3 dni walczyłem z podobną przypdłością (Arch). Wszystko było ok, ale… do godziny 0:00 potem jakakolwiek próba wywołania nowego (tj. niedziałającego do tej pory programu) powodowała segfault error. Także „normalny” restart nie działał, a jedynie hard reset. Po nim – kernel panic jak u Ciebie z tą samą informacją (non-syncing).
O ile się nie mylę, to za owe „syncing” odpowiada systemd. Może cofnięcie jego wersji da jakiś efekt, bowiem fakt – wystąpiło to niedawno (między piątkiem a środą).Czy wersje KDE i Gnome pochodzą z tego samego czasu i wydania?
Tak jakoś mi to wygląda na sytuację związaną bardziej ze sterownikami niż z programami. Jeśli praktycznie wszystkie programy wyświetlające treści multimedialne będą się zachowywać tak samo, to szukałbym przyczyny w odmiennych ustawieniach jakie w stosunku do KDE masz w Gnome w zakresie właśnie sposobu korzystania ze sterowników.
Jeśli już przy sterownikach… Jakie GPU? Jakie sterowniki? Jakie ich ustawienia systemowe i środowiskowe?Może by tak docker? pavbaranov –
No wyżej, o ile pamiętam, proponowałem, że jedyne sensowne rozwiązanie z LH (w ogóle, nie tylko w Archu i Manjaro) polega na opakowaniu go do jakiegoś „formatu uniwersalnego”: appimage, flatpak… Dołączyłeś dockera… Tak – skoro LH opiera swoje rozwiązania na dawno porzuconych rozwiązaniach (równie dobrze mogliby teraz to robić na dosowej wersji dBase), to winna zadbać o to, by nadawało się współcześnie do używania. Biorąc pod uwagę, że jest to rozwiązanie komercyjne, to nie bardzo chce mi się ich wspierać choćby dla sportu. Mogę tylko przypuszczać, że to rozwiązanie jest możliwe.
Zapominamy o jednym:
Oba problemy pojawiły się gdy gnome zaczął być „oficjalną” wersją (GNOME – dop.mój), system przeinstalowany jednego dnia 4 razy dla pewności. Na wersji KDE wszystko działa zacnie.
Teraz to już kompletnie nie rozumiem tego, co napisał Ci support LH.
Tak, czy inaczej – chcesz się bawić w to LH+FB1.5, czy nie. W pierwszej opcji możesz ode mnie liczyć na przeróbkę PKGBUILDów (ale już nie na testowanie). Resztę musisz zrobić sam, włącznie z tak trywialną w sumie rzeczą, jak nabycie wiedzy kiedy FB będziesz musiał przekompilować. Niestety w ogóle nie ręczę, że to się uda z uwag – jak Ci już napisałem – na to, że FB1.5 zaprzestało być rozwijane w 2009 r. Pewnie nawet na żaden support już z ich strony liczyć nie można.
Decyzja należy do Ciebie.
PS: No i nie licz na to, że PKGBUILDy pojawią się zaraz po tym, jak powiesz, że chcesz :)
