Udzielone Odpowiedzi
- Posty
Masz Manjaro – masz yaourt, zatem:
yaourt -G dolphin-root cd dolphin-root nano PKGBUILDZmieniasz:
pkgver=17.04.1
na
pkgver=17.04.2`
Wydajesz polecenie:
updpkgsums && makepkg -sirc --skippgpcheck
Tak dolphin i dolphin-root są w konflikcie. Musisz odinstalować dolphin, by zainstalować dolphin-root. Jak Ci wcześniej napisałem – cała zabawa jest na… 10 dni (mniej więcej) i zależna od KF5.36, które ma się pojawić w drugą sobotę lipca. Wówczas z dolphin będziesz mógł korzystać mając dostęp tam, gdzie trzeba uprawnień roota – bez konieczności usunięcia zmian dokonanych w dolphinie. Osobiście polecałbym zainstalowanie krusadera i poczekanie na zmiany. Up2U.
Po zakończeniu operacji nie cieszymy się poprawną wersją dolphina, ale taką, która w sposób niedozwolony korzysta z możliwości jej uruchomienia na prawach roota.
Dziwi mnie, że nie widzi serwera kluczy, ale to ostanio w różnych dystrybucjach popularny błąd.
Wiki Archa jest na prawdę obłędne. Trzeba tylko je czytać i starać się zrozumieć. Też na Archa przeszedłem po kilku(-nastu) różnych dystrybucjach, niemniej jednak to co jest konieczne i podstawowe – jest tam opisane dokładnie.
A w „debianowych”? Cóż… jeśli ktoś nie zrobiłby paczki deb z dolphin-root to takiej pewnie nie miałbyś i nie zrobił. Tu nie jest to problemem. Taka różnica, że nie trzeba pisać doktoratu by zrobić paczkę.róbowałem zrobić jak napisałeś
Nie, nie próbowałeś tego zrobić tak jak napisałem. Napisałem:
aktualizować sumy kontrolne oraz wydać polecenie budowy z pominięciem weryfikacji kluczy publicznych,
Nie zrobiłeś, to masz taki wynik, jaki masz. Szczerze, jeśli ktoś tego nie potrafi, to nie powienien mieć w ogóle dostępu do aplikacji działających jako root.
Info nt. wszystkich niezbędnych rzeczy masz albo w helpie makepkg albo na wiki Archa.
Jeśli chcesz dodać klucz:
gpg --receive-keys kod_klucza
Jeśli chcesz zbudować paczkę bez weryfikacji klucza – opcja:
--skippgpcheck
To nie jest problem. To brak chęci przeszukania podstawowych informacji ogólnie dostępnych.Trochę szukałem na necie i do starszych wersji są poprawki które jednak nie działają z ostatnimi wersjami Manjaro KDE.
Próbowałeś? Oczywiście, że działają. Oto wynik:
==> Rozpoczynanie prepare()... patching file src/main.cpp ==> Rozpoczynanie build()...Z czego wynika, że patche nakładają się. Jedyne co trzeba zrobić, to ściągnąć na dysk tarball dolphin-root, wyedytować PKGBUILD,
zmienić numer wersji na 17.04.2 i zaktualizować sumy kontrolne oraz wydać polecenie budowy z pominięciem weryfikacji kluczy publicznych, albo dodać klucz 227CA7C556B2BA78.
Dowód na to, że dolphin-root 17.04.2 buduje się prawidłowo:
==> Ukończono tworzenie: dolphin-root 17.04.2-1Prawdopodobnie można też zainstalować dolphin-root z Antergosa, ale tutaj jest wyłącznie wersja 17.04.1, czyli pozbawiona tych poprawek: https://www.kde.org/announcements/fulllog_applications.php?version=17.04.2#dolphin
Alternatywą jest zbudowanie KF5 z GIT, albowiem wówczas dolphin będzie mógł wykonywać niektóre (i wystarczające) operacje na plikach i katalogach nienależących do użytkownika.
Można też poczekać na KF5.36 (pojawi się w przyszłą sobotę, a kiedy w Manjaro – nie wiem).
Można też zainstalować np. krusader, który jeszcze oferuje „starą” możliwość pracy z uprawnieniami roota.
Więcej: http://linux-pavbaranov.blogspot.com/2017/06/aplikacje-kde-pozwola-na-roota.html
Hmm, a nie zepsuje się coś po drodze?
Nie rozumiem.
Kolejność:
– instalacji linux-firmware-git – obojętna,
– edycja /etc/mkinitcpio.conf – w zasadzie obojętna – musi wystąpić przed przebudowaniem initcpio oraz przed restartem.EDIT:
Swoją drogą, to przychodzi mi do głowy jeszcze jedno rozwiązanie (a w zasadzie jedynie swego rodzaju naprowadzenie na możliwe rozwiązanie). Doinstaluj np. OpenBox, wyloguj się z Cinnamon, zaloguj do OpenBox lub ustaw w DM OB jako domyślne „środowisko”, zaktualizuj do kernel49, restart. Teraz winien Ci się włączyć OB (który – jeśli tylko Xy potrafią się włączyć – niemal zawsze się włączy). Sprawdźmy, czy to działa.
I jeszcze pytanie: jakiego repozytorium (stable/testing/unstable) korzystasz?
Akurat jeśli chodzi o Cinnamona, to z innego wątku na tym forum wynikałoby, że są/były z nim jakieś problemy ostatnio w Manjaro.Cóż…
1. Zakładam, że problem z owymi znikającymi ikonami jest raczej problemem występującym w Manjaro. Dlaczego? Nie mam pojęcia. Mozna zerknąć do pliku dziennika, można też uruchomić journalctl z opcją „-f” i doprowadzić do błędu (możesz sobie zrobić backup ~/.config) dla spokoju, a po błędzie po prostu odtworzyć.
Wynik możesz podrzucić tu lub twórcom.
Dlaczego twierdzę, że to problem z Manjaro (lub też jego wersją Manjaro Cinnamon), otóż w Archu + Cinnamon coś takiego nie występuje, a – o ile się nie mylę – to w Manjaro Cinnamon jest (a przynajmniej był) ściągany z Archa; w przypadku Manjaro Cinnamon mogą to być jakieś kwestie jakichś prekonfigów.
2. Jeśli chodzi o kwestie związane z problemami na poszczególnych kartach – załóż osobny wątek dla Radeona, albowiem nie jest on raczej związany z opisanym problemem.To co możesz sobie natomiast we własnym zakresie zrobić, to zainstalować np. wersję XFCE czy np. Mabox, zaktualizować i doinstalować Cinnamon. Zobacz czy problem też występuje.
Tak, czy inaczej – przydałoby się wiedzieć co jest aktualizowane w Twoim przypadku, skoro przed aktualizacją jest wszystko ok.
Niestety skończyła się możliwość edycji, zatem muszę podbić.
@iggys: Sprawdź sobie, czy ów amdgpu jest otwarty, czy zamknięty (amdgpu-pro) /powinieneś to zobaczyć w GUI dla mhwd/. Z dotychczasowych danych wynikałoby, że pierwszy, ale upewnij się. Okazuje się, że zamknięte rozwiązanie (amdgpu-pro) niekoniecznie musi współpracować prawidłowo z najnowszymi kernelami i wersją xorg.
Jeśli jest otwarty, możesz spróbować:
– zainstalować pakiet linux-firmware-git z AUR,
– wyedytować plik /etc/mkinitcpio.conf i w sekcji MODULES dodać amdgpu; będzie to wyglądać mniej więcej tak:
MODULES="... amdgpu ..."
Po zapisaniu, musisz odnowić obraz:
# mkinitcpio -p linux49
(to 49 dla linux49, ale niech mnie ktoś, kto ma Manjaro ewentualnie skoryguje).To jest RC. Mimo wszystko może jeszcze nie wszystko być dopracowane i działać. Jeśli widzisz w nim jakieś braki, powinieneś je zasygnalizować twórcom.
Zainstaluj z wersji 17.0.1.Ze względów bezpieczeństwa każdy aurhelper daje możliwość wglądu do PKGBUILDu. Możesz to zwykle wyłączyć albo wywołując program, albo zmieniając plik konfiguracyjny danego programu. Zob. np.:
yaourt -S --help@azja – Zerknij w wolnej chwili na wynik inxi z tego posta. Inxi widzi to tak, jakby tu był układ AMD APU z Carrizo (tj. APU 6 generacji) oraz karta AMD Topaz XT (czyli Radeon R7). Wygląda też, że system wstaje na Carrizo (zintegrowanej).
Przyznam, że pierwszy raz widzę notebook (bo raczej do stacjonarki nikt nie wsadziłby APU), który ma dwie karty i obie są tej samej firmy.Nie, to nie to. Kernele > 4.4 mają lepsze wsparcie dla amdgpu. Zatem coś jest skopane w kernelach i/lub (co najbardziej prawdopodobne) konfiguracji. Niestety Manjaro próbuje być milusińskie i nie zawsze to pomaga. Pomyślę i wrzucę coś.
Jak na razie mam pomysł taki, abyś zainstalował sterowniki xf86-video-ati. System winien powstać a jedynie gorzej wspierana będzie karta.
Swoją drogą, to masz przedziwny układ z podwójnym GPU AMD (zintegrowana i dedykowana).Mam laptop HP, Arch, APU AMD i działa to bez najmniejszego problemu, zatem nie tu dziura w całym.
Zainstaluj w końcu jakiś inny kernel >4.4, ale nie 4.9 i zdaj relację.Jeśli podane przez Ciebie dane nt. wersji paczek pochodzą z Manjaro 16.10.3 przed jego aktualizacją, to w wersjach mesy i sterownika amdgpu nic się nie zmienia. Sterownik jest otwarty i winien on zostać wykryty i użyty przez Xy OTB – bez żadnej ingerencji.
Ciekaw jestem co się zmienia – sprawdź ewentualnie po prostu z dowolnym innym kernelem oprócz 4.9.
@azja – Pozostawmy przyzwyczajenia z wydawniczych dystrybucji. To jest rolling release – raz zainstalowane ma działać tylko i wyłącznie dzięki aktualizacji. „Wydanie” jakiekolwiek – jak sam pisałeś – to tylko odzwierciedlenie stanu repozytoriów w określonej daty.Gwoli ścisłośći – to co proponuję z GRUBym nie ma kompletnie związku z instalacją jakiegokolwiek kernela. Usunięcie quiet powoduje, że podczas startu systemu są wyświetlane informacje, łatwiej możesz nam podać, w którym momencie się zatrzymuje. Zmiana w GRUB_DISABLE_RECOVERY powoduje, że w GRUBym pojawi się dodatkowa pozycja, umożliwiająca łatwe wystartowanie systemu po jakiejś awarii (np. grafiki) i jego naprawdę (w konsoli).
Ale dziwne jest to, że 16.10.3 jak jest świeżo postawiony to zasysa 49 bez problemu i chodzi.
Czy mam rozumieć, że instalacja 16.10.3 i wgranie kernela 4.9 jest możliwa i działa to prawidłowo?
Po aktualizacji jest problem z grafiką.
Rozumiem, że po wydaniu pacman -Syu, z zainstalowanym kernelem 4.9. Ów problem z grafiką przejawia się w tym, że po starcie jest „czarny ekran”? Ok. Pokaż zatem co Ci się chce zaktualizować i jak to robisz. Między 16.10.3 a obecną chwilą nieco paczek się pozmieniało.
Nadto prosiłbym o wersje Xów, mesy i sterownika. Najlepiej pokaż (może będziesz musiał doinstalować):
inxi -Gxx
oraz:pacman -Qs mesa pacman -Qs xorg | grep videoNo to jeszcze gwoli wyjaśnienia:
1. Polecenie:
pacman -Syyuu
dokonuje:
– wymuszonej synchronizacji lokalnej bazy danych pacmana z bazą zdalną (na serwerze), która dokonywana jest nawet, gdy lokalne repozytoria są aktualne (to jest to yy); nie ma to większego sensu w normalnych warunkach,
– aktualizacji systemu, przy czym jeśli lokalnie zainstalowany pakiet jest w wersji świeższej niż na serwerze, to zostanie dokonana jego aktualizacja do wersji na serwerze (czyli tzw. downgrade); ma to sens w przypadku np. przejścia z testing na stable; tak, czy inaczej należy być absolutnie świadomym konsekwencji jego wykonywania.
2. Błąd „Error filesystem, Entering rescue mode” jest generowany przez GRUB, który napotyka jakieś trudności w wystartowaniu systemu. Jest to poważny błąd GRUBa, uniemożliwiający mu nawet wystartowanie kernela, a zatem jako taki z jego wersją raczej niewiele ma wspólnego. Przyczyny mogą być różne od wadliwego wygenerowania pliku konfigurującego GRUB, po skopanie czegoś w systemie. Wobec faktu, że kernele Manjaro (niestety) automatycznie wywołują przeładowanie GRUB być może coś w istocie jest skopane w kernel49, choć wątpię, albowiem wywoływane polecenie post-install jest poleceniem GRUBa i nie powinno zawierać żadnych instrukcji ingerujących w jego plik konfiguracyjny.
3. W przypadku takiej, zdalnej pomocy jak ma miejsce na forum, nie interpretuję, nie domyślam się, bo wyniknąć mogą z tego wyłącznie złe rzeczy. To ktoś pragnący pomocy musi dokładnie i precyzyjnie opisać co robi.
4. @iggys udzielił nam odpowiedzi na pytanie o sterowniki. Jeśli jest ona prawidłowa, to jest to amdgpu, czyli otwarty sterownik dla kart AMD GCN w wersjach 3 i 4. Wsparcie dla GCN 1 i 2 jest tu eksperymentalne, wymaga odpowiedniej wersji kernela (w 4.4 i nawet bodaj w 4.9 nie jest dostępne) oraz jego odpowiedniej kompiacji (nie wiem, czy kernel Manjaro jest kompilowany z uruchomieniem wsparcia dla tej eksperymentalnej funkcji, ale jeśli tak, to jest to proszenie się o kłopoty).A teraz już do @iggys:
Rozumiem, że masz obecnie zainstalowane, działające Manjaro; wersja kernela to 4.4. Wykonaj w nim:
sudo pacman -Syu
Nie dokonuj instalacji żadnego innego kernela. Restart – działa?
Jeśli działa – zainstaluj inny kernel, ale nie 4.9. W Manjaro (niestety) wersji kernela pod dostatkiem – zainstaluj np. najnowszy, stabilny kernel 4.11 (przez mhwd). W tym momencie powinieneś mieć 2 kernele w systemie: 4.4 oraz 4.11, które winny być dostępne do wyboru podczas startu GRUBa. Zanim dokonasz restartu dokonaj edycji pliku /etc/default/grub, odnajdź w nim linijkę gdzie w treści znajdziesz:
GRUB_DISABLE_RECOVERY=
i doprowadź ją do postaci:
GRUB_DISABLE_RECOVERY=false
Linijka ta nie może być poprzedzona znakiem #.
Nadto usuń słowo „quiet”, które występuje w linii:
GRUB_CMDLINE_LINUX_DEFAULT=
Przeładuj GRUBego:
sudo update-grub
lub jeśli nie masz
sudo grub-mkconfig -o /boot/grub/grub.cfg
Restart i spróbuj wystartować komputer za pierwszym razem z kernela 4.4, za drugim z 4.11.
Jeśli wszystko pójdzie prawidłowo i w obu przypadkach system wstanie, zainstaluj kernel 4.9 i restart – teraz już tylko na 4.9 i bez wykonywania zmian w grub (bo wcześniej je dokonałeś). Jeśli system nie wstanie i nie będziesz miał możliwości przełączenia się do konsoli (alt+ctrl+Fx ew. jeśli jeszcze system graficzny nie wstał: alt+Fx) – twardy reset i przełącz się na działający kernel.
Opisz.
