Adam Przedniczek

DEAMON, dzięki za wskazanie tego opisu błędu na sourceforge. Swoją drogą jak ktoś może to proszę o głos na te dwa poniższe pytania na stackexchange. Może w ten sposób kogoś zainteresuję tematem i jakoś to rozwiążą. http://unix.stackexchange.com/questions/317694/mount-samsung-galaxy-s7-using-simple-mtpfs http://android.stackexchange.com/questions/160439/cannot-mount-galaxy-s7-with-simple-mtpfs-with-s4-it-used-to-work-fine Poza tym rozmawiałem już Peto Hatiną (twóraca simple-mtpfs) i w następnym tygodniu rzuci okiem, więc możę uda się coś z tym zrobić.

Witam, Chciałbym zamontować Samsunga Galaxy S7 pod Fedorą 24 w określonym katalogu i okazuje się, że nie mogę tego zrobić w taki sposób jak dotychczas (jak pod wcześniejszą Fedorą 23 i ze starszym Galaxy S4). Za każdym razem jak podłączam telefon do komputera to sprawdzam czy jest podłączony w trybie MTP, więc to nie może stanowić problemu. Do tej pory pod Fedorą 23 podłączałem S4 Nawet pod nową Fedorą 24 podłączam stary Galaxy S4 i jedną komendą montuję go do katalogu jako root bądź zwykły użytkownik. # simple-mtpfs /media/s4 $ simple-mtpfs /home/adam/s4 Teraz po podłączeniu S7, na telefonie pyta mnie o tryb MTP i po potwierdzeniu w Nautiliusie mogę przeglądać jego zawartość, ale nie mogę w prosty sposób dostać się do niego poprzez terminal. Pierwszą rzeczą jaką sprawdziłem było wskazanie na różne sposoby konkretnego urządzenia do zamontowania, ale poniższe próby też zawiodły: # simple-mtpfs --list-devices 1: SamsungGalaxy models (MTP) # simple-mtpfs --device 1 /home/adam/S7 # simple-mtpfs /dev/libmtp-3-1 /media/s7 Próbowałem nawet poprzez stworzenie reguły udev: # dmesg | tail [16821.258485] usb 3-1: Product: SAMSUNG_Android [16821.258487] usb 3-1: Manufacturer: SAMSUNG [16821.258489] usb 3-1: SerialNumber: 98867????????????? [16827.556099] usb 3-1: USB disconnect, device number 29 [16830.383366] usb 3-1: new high-speed USB device number 30 using xhci_hcd [16830.548882] usb 3-1: New USB device found, idVendor=04e8, idProduct=6860 [16830.548887] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [16830.548903] usb 3-1: Product: SAMSUNG_Android [16830.548905] usb 3-1: Manufacturer: SAMSUNG [16830.548907] usb 3-1: SerialNumber: 98867????????????? # touch /etc/udev/rules.d/10-phone.rules # echo echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}="6860", SYMLINK="S7"' >> /etc/udev/rules.d/10-phone.rules # udevadm control --reload-rules # ls -l /dev/S7 lrwxrwxrwx. 1 root root 15 10-20 15:03 /dev/S7 -> bus/usb/003/075 # ls -l /dev/libmtp-3-1 lrwxrwxrwx. 1 root root 15 10-20 15:03 /dev/libmtp-3-1 -> bus/usb/003/075 # simple-mtpfs /dev/S7 /media/s7 Niestety, nic to nie dało. Żadna z tych metod nie wyrzuciła żadnego błedu, ale katalog, gdzie chciałbym zamontować telefon nadal jest pusty. Będę bardzo wdzięczny, jeżeli ktoś mógłby doszukać się, gdzie może tkwić problem. Z góry dziękuję za odpowiedź. Adam Update: Poniżej zamieszczam zapis z logów, dokłądniej ostatnie wpisy z journalctl po podłączeniu telefonu i wprowadzeniu polecenia simple-mtpfs /media/s7: # journalctl -n 53 -- Logs begin at śro 2016-10-19 21:29:20 CEST, end at sob 2016-10-22 09:26:43 CEST. -- paź 22 09:24:31 PRZEDNICZEK01 kernel: usb 3-1: USB disconnect, device number 10 paź 22 09:24:31 PRZEDNICZEK01 PackageKit[1559]: get-updates transaction /384_eccedcee from uid 1000 finished with success after 45ms paź 22 09:24:32 PRZEDNICZEK01 kernel: usb 3-1: new high-speed USB device number 11 using xhci_hcd paź 22 09:24:32 PRZEDNICZEK01 kernel: usb 3-1: New USB device found, idVendor=04e8, idProduct=6860 paź 22 09:24:32 PRZEDNICZEK01 kernel: usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 paź 22 09:24:32 PRZEDNICZEK01 kernel: usb 3-1: Product: SAMSUNG_Android paź 22 09:24:32 PRZEDNICZEK01 kernel: usb 3-1: Manufacturer: SAMSUNG paź 22 09:24:32 PRZEDNICZEK01 kernel: usb 3-1: SerialNumber: 98867????????????? paź 22 09:24:32 PRZEDNICZEK01 gvfsd[1813]: PTP: reading event an error 0x02ff occurredDevice 0 (VID=04e8 and PID=6860) is a Samsung Galaxy models (MTP). paź 22 09:24:32 PRZEDNICZEK01 gvfsd[1813]: LIBMTP ERROR: couldnt parse extension samsung.com/devicestatus:0 paź 22 09:24:32 PRZEDNICZEK01 tracker-miner-fs.desktop[2001]: (tracker-miner-fs:2001): Tracker-CRITICAL **: Could not set mount point in database 'urn:nepomuk:datasource:5e7b19a6b9795726a5c47a99a89757bf', GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: UNIQUE constraint paź 22 09:24:32 PRZEDNICZEK01 tracker-miner-fs.desktop[2001]: (tracker-miner-fs:2001): Tracker-CRITICAL **: Could not set mount point in database 'urn:nepomuk:datasource:5c7e6bb78b9a6691c3ecea3925b2971d', GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: UNIQUE constraint paź 22 09:24:34 PRZEDNICZEK01 org.gnome.Shell.desktop[1832]: (gnome-shell:1832): Gjs-WARNING **: JS ERROR: TypeError: is null paź 22 09:24:34 PRZEDNICZEK01 gvfsd[1813]: ** (process:3243): WARNING **: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/18 (g-dbus-error-quark, 19) paź 22 09:24:34 PRZEDNICZEK01 gvfsd[1813]: ** (process:3243): WARNING **: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/18 (g-dbus-error-quark, 19) paź 22 09:24:34 PRZEDNICZEK01 gvfsd[1813]: ** (process:3243): WARNING **: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/18 (g-dbus-error-quark, 19) paź 22 09:24:34 PRZEDNICZEK01 gvfsd[1813]: ** (process:3243): WARNING **: send_done_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/18 (g-dbus-error-quark, 19) paź 22 09:24:35 PRZEDNICZEK01 PackageKit[1559]: get-updates transaction /385_decdbbba from uid 1000 finished with success after 45ms paź 22 09:26:37 PRZEDNICZEK01 kernel: usb 3-1: usbfs: process 3385 (simple-mtpfs) did not claim interface 0 before use paź 22 09:26:37 PRZEDNICZEK01 kernel: usb 3-1: reset high-speed USB device number 11 using xhci_hcd paź 22 09:26:38 PRZEDNICZEK01 kernel: usb 3-1: usbfs: process 3385 (simple-mtpfs) did not claim interface 0 before use paź 22 09:26:38 PRZEDNICZEK01 kernel: usb 3-1: usbfs: process 3250 (events) did not claim interface 0 before use paź 22 09:26:40 PRZEDNICZEK01 kernel: usb 3-1: USB disconnect, device number 11 paź 22 09:26:40 PRZEDNICZEK01 kernel: usb 3-1: new high-speed USB device number 12 using xhci_hcd paź 22 09:26:40 PRZEDNICZEK01 kernel: usb 3-1: New USB device found, idVendor=04e8, idProduct=6860 paź 22 09:26:40 PRZEDNICZEK01 kernel: usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 paź 22 09:26:40 PRZEDNICZEK01 kernel: usb 3-1: Product: SAMSUNG_Android paź 22 09:26:40 PRZEDNICZEK01 kernel: usb 3-1: Manufacturer: SAMSUNG paź 22 09:26:40 PRZEDNICZEK01 kernel: usb 3-1: SerialNumber: 98867????????????? paź 22 09:26:41 PRZEDNICZEK01 gvfsd[1813]: PTP: reading event an error 0x02ff occurredDevice 0 (VID=04e8 and PID=6860) is a Samsung Galaxy models (MTP). paź 22 09:26:41 PRZEDNICZEK01 gvfsd[1813]: LIBMTP ERROR: couldnt parse extension samsung.com/devicestatus:0 paź 22 09:26:41 PRZEDNICZEK01 tracker-miner-fs.desktop[2001]: (tracker-miner-fs:2001): Tracker-CRITICAL **: Could not set mount point in database 'urn:nepomuk:datasource:0e6a8582e05ac627e4014d1ca1e6ec87', GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: UNIQUE constraint paź 22 09:26:41 PRZEDNICZEK01 tracker-miner-fs.desktop[2001]: (tracker-miner-fs:2001): Tracker-CRITICAL **: Could not set mount point in database 'urn:nepomuk:datasource:5c7e6bb78b9a6691c3ecea3925b2971d', GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: UNIQUE constraint paź 22 09:26:41 PRZEDNICZEK01 dbus-daemon[1760]: [session uid=1000 pid=1760] Activating service name='org.gnome.Shell.HotplugSniffer' requested by ':1.16' (uid=1000 pid=1832 comm="/usr/bin/gnome-shell " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") paź 22 09:26:41 PRZEDNICZEK01 dbus-daemon[1760]: [session uid=1000 pid=1760] Successfully activated service 'org.gnome.Shell.HotplugSniffer' paź 22 09:26:42 PRZEDNICZEK01 org.gnome.Shell.desktop[1832]: (gnome-shell:1832): Gjs-WARNING **: JS ERROR: TypeError: is null paź 22 09:26:43 PRZEDNICZEK01 gvfsd[1813]: ** (process:3399): WARNING **: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/17 (g-dbus-error-quark, 19) paź 22 09:26:43 PRZEDNICZEK01 gvfsd[1813]: ** (process:3399): WARNING **: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/17 (g-dbus-error-quark, 19) paź 22 09:26:43 PRZEDNICZEK01 gvfsd[1813]: ** (process:3399): WARNING **: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/17 (g-dbus-error-quark, 19) paź 22 09:26:43 PRZEDNICZEK01 gvfsd[1813]: ** (process:3399): WARNING **: send_done_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/17 (g-dbus-error-quark, 19) paź 22 09:26:43 PRZEDNICZEK01 PackageKit[1559]: get-updates transaction /386_acdeddea from uid 1000 finished with success after 48ms

Może ja niezbyt fortunie opisałem ten problem i powinienem wyraźniej rozbić go na dwie części: Dlaczego po aktualizacji się to wszystko posypało i jak się tego ustrzec na przyszłość. Jak wycofać pojedynczą aktualizację bez zastanawiania się nad przyczynami. Zajmijmy się tylko drugim zagadnieniem, czyli wycofaniem. Wydaje mi się, że przynajmniej samo wycofanie konkretnego update'u nie jest aż tak machinalnym problemem tylko ja nie wiem jakiejś bardzo prostej rzeczy, którą pewnie większość uznaje za oczywistą. Skupmy się na pojedynczej bibliotece np. mesa-libOSMesa. Próba wycofania aktualizacji dnf history undo 54 kończy się błędem wynikającym z braku mesa-libOSMesa-0:12.0.3-1.fc24.i686. Rozumiem, że ta sekwencja w nazwie 0: oznacza tylko nazwę pakietu zarchiwizowanego po udanej aktualizacji i oczekującego na ewentualne wycofanie zmian. W pliku /etc/dnf/dnf.conf nie miałem ustawionej (w ogóle jej nie było) opcji keepcache=1 i dlatego mam takie problemy. Niemniej jednak, nawet bez tej opcji powinienem móc wycofać zmiany poprzez automatyczne ściągnięcie sobie z repozytorium odpowiedniej wersji, chyba że w tym publicznym repozytorium już jej nie ma. Dlaczego mówię, że może jej już nie być - ponieważ próbowałem zainstalować ręcznie dnf install mesa-libOSMesa i okazało się, że mam już nawet dwie takie: mesa-libOSMesa-12.0.3-2.fc24.x86_64 i mesa-libOSMesa-12.0.3-2.fc24.i686. Można dostrzec, że posiadana wersja różni się od tej wymaganej tylko infixem -1.fc24 a nie -2.fc24. Jeżeli dobrze rozumiem politykę Fedory to ta o jeden wyższa wersja zawiera jedynie minimalne poprawki, np. wyeliminowanie jakiegoś błędu, bez ruszania interfejsów oferowanych bibliotek i odwołań do innych bibliotek. Dlatego wydaje mi się, że przynajmniej teoretycznie przy wycofywaniu można by użyć tej wyższej wersji. Czy coś takiego jest w ogóle możliwe? Co do Fedory 24 to bardzo sobie ją cenię, może oprócz problemów ze samymi sterownikami własnościowymi Nvidii i SDK CUDA. Używam Fedory od 2007 i jeżeli CUDA mi zadziała to nie mam ochoty jej na nic innego wymienać.

Witam, Ujmując w największym skrócie, mój aktualny problem z moją instancją Fedory 24 polega na niemożności zalogowania się już z poziomu GNOME'a. Podejrzewam, że przyczyną tej usterki jest aktualizacji wykonanej wczoraj, która obejmowała 23 biblioteki z grup: mesa-*, xen-* oraz dbus-*. Niestety zwykłe wycofanie przez dnf history undo NUM lub dnf history rollback NUM -1 nie działa. Podejrzewam, że to właśnie wczorajsza aktualizacja spowodowała, że podczas staru wyświetlany jest komunikat: Coś poszło nie tak Wystąpił problem i nie można przywrócić systemu Proszę się wylogować i spróbować ponownie. Będę bardzo wdzięczny za pomoc w usunięciu tego problemu oraz pokazaniu czy na przyszłszość można ustrzec się takiej sytuacji np. rezygnując z własnościowych sterowników Nvidii i zostając przy nouveau? Teraz może dokładniej: opiszę moją instalację jakie kroki podjąłem do tej pory Ad. 1 Korzystam ze sterowników Nvidii zainstalowanych wg opisu ze strony http://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/ # uname -r 4.7.6-200.fc24.x86_64 # rpm -q gnome-session gnome-session-3.20.2-1.fc24.x86_64 # rpm -q gnome-shell gnome-shell-3.20.4-1.fc24.x86_64 # nvidia-settings -version version 370.28 (buildmeister@swio-display-x64-rhel04-17) Powyżej jest minimalna różnica w sercjach gnome-shell i gnome-session, 3.20.4-1 i 3.20.2-1. Ponieważ podejrzewam, że przyczyną obecnego stanu rzeczy jest aktualizacja obejmująca pakiety z grup mesa, xen i dbus zamieszczam ich aktualny stan. Zapis samej aktualizacji podaję dalej przy opisie próby wycofania tejże aktualizacji. W przypadku pakietów mesa moją uwagę zwrócił fakt, iż w większości występują parami różniącymi się tylko końcówką, .i686 i .x86_64. Nie mam pojęcia czy tak ma być, ale nie każdy pakiet występuje w takim tandemie, np. mesa-libwayland-egl czy mesa-libxtracker. Niby .i686 i .x86_64 na jedno wychodzi, ale wygląda to trochę tak jakby instalowały się przy różnych okazjach. Druga sprawa to numery wersji w jakiej występują te biblioteki. Większość występuje w wersji 12.0.3-2, natomiast mesa-libGLU w wersji 9.0.0-10 i także w dwóch kopiach .i686 oraz .x86_64. # rpm -qa | grep mesa mesa-dri-drivers-12.0.3-2.fc24.x86_64 mesa-libgbm-12.0.3-2.fc24.x86_64 mesa-libxtracker-12.0.3-2.fc24.x86_64 mesa-libGL-12.0.3-2.fc24.i686 mesa-libglapi-12.0.3-2.fc24.i686 mesa-libOSMesa-12.0.3-2.fc24.x86_64 mesa-filesystem-12.0.3-2.fc24.i686 mesa-dri-drivers-12.0.3-2.fc24.i686 mesa-libEGL-12.0.3-2.fc24.i686 mesa-libGL-12.0.3-2.fc24.x86_64 mesa-libEGL-12.0.3-2.fc24.x86_64 mesa-libGLU-9.0.0-10.fc24.x86_64 mesa-libgbm-12.0.3-2.fc24.i686 mesa-libwayland-egl-12.0.3-2.fc24.x86_64 mesa-libGLU-9.0.0-10.fc24.i686 mesa-libOSMesa-12.0.3-2.fc24.i686 mesa-libglapi-12.0.3-2.fc24.x86_64 mesa-filesystem-12.0.3-2.fc24.x86_64 # rpm -qa | grep xen xen-licenses-4.6.3-6.fc24.x86_64 xen-libs-4.6.3-6.fc24.x86_64 # rpm -qa | grep dbus dbus-glib-0.108-1.fc24.x86_64 dbus-x11-1.11.6-1.fc24.x86_64 dbus-python-1.2.4-1.fc24.x86_64 dbusmenu-qt.0.9.3-0.11.20150604.fc24.x86_64 dbus-libs-1.11.6-1.fc24.i686 dbus-1.11.6-1.fc24.x86_64 dbus-libs-1.11.6-1.fc24.x86_64 abrt-dbus-2.8.2-1.fc24.x86_64 dleyna-connector-dbus-0.2.0-7.fc24.x86_64 python-slip-dbus-0.6.4-3.fc24.noarch python3-slip-dbus-0.6.4-3.fc24.noarch python3-dbus-1.2.4-1.fc24.x86_64 Ad. 2 # dnf history list Identy | Wiersz poleceĹ„ | Data i czas | DziaĹ‚ania | Zmienio ------------------------------------------------------------------------------- 55 | install gnome-system-log | 2016-10-15 20:06 | Install | 1 54 | update | 2016-10-14 09:42 | Update | 23 # dnf history info 54 Identyfikator transakcji : 54 Czas rozpoczęcia : Fri Oct 14 09:42:41 2016 Rozpoczęcie bazy danych RPM: 5701:823efc10b49ac8e9973c5db57731f631f4c6a9c9 Czas ukończenia : 09:42:52 2016 (sekundy: 11) Ukończenie bazy danych RPM : 5701:2d2cbc27f00c09a715cd898ad8dd5bd9efb9fbd7 Użytkownik : Adam Przedniczek <adam> Kod zwrotny : Powodzenie Wiersz poleceń : update Wykonano transakcję za pomocą: Zainstalowano dnf-1.1.10-1.fc24.noarch @updates Zainstalowano rpm-4.13.0-0.rc1.27.fc24.x86_64 @koji-override-0 Zmienione pakiety: Zaktualizowano evolution-data-server-3.20.5-4.fc24.x86_64 @updates Aktualizacja 3.20.5-5.fc24.x86_64 @updates Zaktualizowano mesa-dri-drivers-12.0.3-1.fc24.i686 @updates Zaktualizowano mesa-dri-drivers-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.i686 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-filesystem-12.0.3-1.fc24.i686 @updates Zaktualizowano mesa-filesystem-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.i686 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-libEGL-12.0.3-1.fc24.i686 @updates Zaktualizowano mesa-libEGL-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.i686 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-libGL-12.0.3-1.fc24.i686 @updates Zaktualizowano mesa-libGL-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.i686 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-libOSMesa-12.0.3-1.fc24.i686 @updates Zaktualizowano mesa-libOSMesa-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.i686 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-libgbm-12.0.3-1.fc24.i686 @updates Zaktualizowano mesa-libgbm-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.i686 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-libglapi-12.0.3-1.fc24.i686 @updates Zaktualizowano mesa-libglapi-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.i686 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-libwayland-egl-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano mesa-libxatracker-12.0.3-1.fc24.x86_64 @updates Aktualizacja 12.0.3-2.fc24.x86_64 @updates Zaktualizowano xen-libs-4.6.3-5.fc24.x86_64 @updates Aktualizacja 4.6.3-6.fc24.x86_64 @updates Zaktualizowano xen-licenses-4.6.3-5.fc24.x86_64 @updates Aktualizacja 4.6.3-6.fc24.x86_64 @updates Zaktualizowano dbus-1:1.11.4-1.fc24.x86_64 @updates Aktualizacja 1:1.11.6-1.fc24.x86_64 @updates Zaktualizowano dbus-libs-1:1.11.4-1.fc24.i686 @updates Zaktualizowano dbus-libs-1:1.11.4-1.fc24.x86_64 @updates Aktualizacja 1:1.11.6-1.fc24.i686 @updates Aktualizacja 1:1.11.6-1.fc24.x86_64 @updates Zaktualizowano dbus-x11-1:1.11.4-1.fc24.x86_64 @updates Aktualizacja 1:1.11.6-1.fc24.x86_64 @updates Podejrzewałem, że to właśnie ta 54 aktualizacja spowodowała problemy, więc próbowałem wycofać tą pojedynczą aktualizacje jak i cofnąć się do 53. Niestety bezskutecznie: # dnf history undo 54 Nie ma pakietu mesa-libwayland-egl-0:12.0.3-1.fc24.x86_64 #dnf history rollback 53 Nie ma pakietu mesa-libEGL-0:12.0.3-1.fc24.x86_64 Logi sugerują jedynie problem z inicjalizacją Cluttera: # journalctl -b -1 _SYSTEMD_UNIT=session-l.scope -- No entries -- # journalctl -b -1 /usr/bin/gnome-session -- No entries -- # journalctl -b -1 /usr/bin/gnome-shell -- Logs begin at nie 2016-10-09 18:58:18 CEST, end at 2016-10-15 23:18:23 CEST. -- paź 15 20:01:03 PRZEDNICZEK01 org.gnome.Shell.desktop[1327]: (gnome-shell:1327): Clutter-CRITICAL **: Unable to initialize Clutter: Nie można zainicjować machenizmu biblioteki Clutter: nie odnaleziono dostępnych sterowników. paź 15 20:01:03 PRZEDNICZEK01 org.gnome.Shell.desktop[1327]: (gnome-shell:1327): mutter-WARNING **: Unable to initialize Clutter. # rpm -qa | grep clutter clutter-1.26.0-1.fc24.x86_64 clutter-gst3-3.0.20-1.fc24.x86_64 clutter-gst2-2.0.18-1.fc24.x86_64 clutter-gtk-1.8.0-1.fc24.x86_64 Teraz na koniec mam kilka pytań: Co mogę zrobić aby uratować tą konkretną instalację? Czy przy kolejnych aktualizacjach ten problem może wystąpić ponownie i jak mógłbym mu zapobiec? (Jak wykryć czy dane aktualizacje będą skutkować takim błędem jeszcze przed ich wykonaniem - jakieś wskazówki sugerujące, że te wersje różnych pakietów ze sobą nie zagrają? Czy jeżeli porzuciłbym sterowniki Nvidii i pozostał przy nouveua to czy ustrzegłbym się takich niespodzianek? Jeżeli będę upierał się przy własnościowych sterownikach Nvidii (będę potrzebował zainstalować jeszcze SDK CUDA) to jak uchronić się przed takim błędem? Z góry dziękuję za pomoc

Rzeczywiście, jeżeli chodzi o "czysty" tryb VGA to 1600x1200 jest to max, ale prawie na pewno można użyć czegoś typu VBE (VESA BIOS Extension) i uzyskać większą rozdzielczość. W pytaniu pisałem przecież o odczytaniu w GRUBie kodów dla tej rozdzielczości z VBEINFO, więc jak podają to musi być możliwość ustawienia. Druga sprawa potwierdzająca wykonalność tego zadania to fakt, że po świeżej instalacji Fedory jak po raz pierwszy zamykam system (instalator) i widzę masę komunikatów w trybie tekstowym w pożądanej rozdzielczości.

Witam, Chciałbym ustawić w trybie tekstowym pełną rozdzielczość oferowaną przez mój monitor (po wciśnięciu kombinacji [Ctrl+Alt+F3] chciałbym mieć konsolę w rozdzielczości 2560 x 1440). Jak poprawnie powinienem to zrobić? Dawno temu (kilka dystrybucji Fedory wcześniej) udała mi się ta sztuka, poprzez dodanie w GRUBie parametru VGA i wszystko działało poprawnie. W mojej bieżącej instalacji F24 ze sterownikami Nvidii próbowałem zrobić coś podobnego, ale po dopisaniu czegoś takiego w ogóle nie działa ten tryb tekstowy (zupełnie czarny ekran). Wcześniej działało, ponieważ ustawiałem rozdzielczość VGA=795 (1280x1024) a teraz potrzebuję ustawić WQHD 2560x1440 i prawie na pewno w tym tkwi cały szkopuł. W GRUBie odczytałem sobie kod mojej rozdzielczości set pager=1 insmod vbe vbeinfo 2560x1440 x32 -> 0x14d 2560x1440 x16 -> 0x14c 2560x1440 x8 -> 0x14b Wartość 0x14d (hex) to 333 (dec) i może trochę naiwnie próbowałem dodać parametr vga=333 lub video=333. Próbowałem także poprzez fbset, ale dostaję poniższy kominikat (prawdopodobnie w związku ze sterownikami Nvidii): open /dev/fb0: No such file or directory uname - r 4.7.4-200.fc24.x86_64 nvidia-settings --version 370.28 lspci |grep -i VGA 01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1) Z góry dziękuję za odpowiedź. Aktualizacja: Próbowałem jeszcze w pliku /etc/default/grub dopisać dwie linijki: GRUB_GFXMODE=2560x1440x32 GRUB_GFXPAYLOAD_LINUX=2560x1440x32 Po aktualizacji GRUBa (grub2-mkconfig -o /boot/grub2/grub.cfg) pojawiły mi się wpisy w każdym menuentry postaci: set gfxpayload=2560x1440x32 Funkcja load_video też wygląda dobrze (sam GRUB dodał VBE) function load_video { if [ x$feature_all_video_module = xy ]; then insmod all_video else insmod efi_gop insmod efi_uga insmod ieee1275_fb insmod vbe insmod vga insmod video_bochs insmod video_cirrus fi } Czy fakt, iż używam własnościowych sterowników Nvidii sprawił, że w ogóle nie działa kernel mode-setting i nie da się nic z tym zrobić?

Po usunięciu quiet z opcji kernela zatrzymuje się na: fb: switching to nouveaufb from EFI VGA Dodałem za to opcję nomodeset, która pozwoliła mi na wejście, w jakimś podstawowym trybie 1024x768, do systemu i zainstalowanie sterowników Nvidii za pośrednictwem RPMFusion: dnf update kernel* selinux-policy* dnf install akmod-nvidia xorg-x11-drv-nvidia-libs kernel-devel acpid mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img dracut /boot/initramfs-$(uname -r).img $(uname -r) Jeszcze przed zrestartowaniem znalazłem trzy nowe moduły: nvidia.ko, nvidia-uvm.ko i nvidia-modeset.ko (chyba tak się nazywały). Ponieważ Fedorę mam na UEFI i z Secure Boot to podpisałem te trzy moduły własnym kluczem, dla którego odpowiadający mu klucz publiczny mam jako Machine Owner Key. Użyłem tego samego skryptu, którym podpisywałem moduł WL, który musiałem własnoręcznie łatać (ale on działał). Po restarcie dalej nie wchodzi. Ponieważ wykonywałem to na jądrze 4.2.6.-300, to chciałem wejść przez niższe 4.2.5-300 z opcją nomodeset, ale próbuje otwierać GNOME Display Manager i tu się wysypuje otwierając jakieś okno "Oh no! Something has gone wrong. Log out". Jutro porobię i zamieszczę zdjęcia z jakimi wynikami się wysypuje.​​​

Witam,   Podczas próbu uruchomiania Fedory 23 dostaję błąd uniemożliwiający dalszy rozruch systemu: Ignoring BGRT: invalid status 0 (expected 1) Do tej pory też dostawałem czasem powyższy błąd Boot Graphics Resource Table (oczywiście od czasu przejścia na UEFI), ale nie uniemożliwiał dalszego startu systemu, po prostu czekałem kilka sekund i sam przechodził dalej (pewnie błąd był zawsze, ale czasem tak szybko przechodził, że go nie zauważałem). Teraz po wypisaniu powyższego błędu i przejściu karetki do następnej linii zastyga, wcześniej jak przechodził, to znak podkreślenia migał. Teraz nie mogę wejść do systemu przy użyciu żadnego z trzech jąder zainstalowanych w systemie kernel-core-4.2.6-300.fc23.x86_64 kernel-core-4.2.5-300.fc23.x86_64 kernel-core-4.2.3-300.fc23.x86_64 oraz przy próbie uruchomienia Fedory 23 Live z płyty uruchomionej w trybie UEFI. Jeżeli uruchamiam tą samą płytę, ale w trybie MBR Legacy to wszystko działa (i mam dostęp do plików na dysku).   Po zainstalowaniu Fedory 23 nie instalowałem żadnych dodatkowych sterowników karty graficznej (np. akmod-nvidia), ale wszystko działało.   Co ciekawe odkryłem, że pod Windowsem 10 (zainstalowanym na osobnym dysku) przestał działać (nawet przestał wykrywać) drugi monitor. Do tej pory miałem dwa monitory podpięte pod GTX 580, jeden po DVI-D a drugi DVI-A (jeden z portów jest DVI-I i mam kabel z przejściem DVI-A -> D-Sub). Oba monitory są sprawne, podłączam każdy z osobna pod Windowsem i działa, ale podłączenie dwóch powoduje, że jednego nawet nie wykrywa.   Moja Fedora 23 wspiera Secure Boot. Wszystkie niestandardowe moduły, kompilowane przez mnie bądź nawet z RPMfusion, podpisuję własnym kluczem a klucz publiczny mam wrzucony jako Machine Owner Key i jest widoczny w system_keyring. W międzyczasie nie instalowałem żadnych aktualizacji.   W jaki sposób mogę przywrócić bootowanie Fedory?   Jak  mam zebrać informacje (oraz jakie) dotyczące tego błędu, jeżeli mogę jedynie uruchomić Fedorę z płyty Live (polecenie journalctl wydane przy uruchomieniu z płyty Live pokazuje tylko informacje z tego uruchomienia).   Czy możliwe, że to w jakiś sposób karta się wysypała skoro pod Windowsem przestał wykrywać drugi monitor. Na tym jednym (dowolnie którym) monitorze Windows działa.   Pozdrawiam   Adam     Niniejszy wątek jest do zamknięcia. Okazało się, że był to błąd sprzętowy a nie software'owy. Moja stara karta przestała obsługiwać 2 monitory, zaczeły się pojawiać błędy wskazujące na jakiś problem ze sterownikami, ale dzisiaj wymieniłem kartę na nową i już ich nie ma. Jakoś dziwnie posypała mi się ta stara karta, ponieważ nie całkowicie, ale połowicznie. ​

Jeżeli nikt inny na tym forum nie rozwiąże Twojego problemu, to ja bym zainstalował sterowniki od producenta http://support.brother.com/g/b/downloadlist.aspx?c=pl〈=pl∏=dcpj515w_eu_as&os=127&flang=English i jeżeli dalej nie będzie działać to zgłosił do Brothera http://www.brother.pl/support/contact-us Infolinia: 801 333 803 lub (22) 500 94 94 Kupiłeś, zapłaciłeś, oni sami przyznają się do wsparcia urządzenia pod Linuxem (publikując sterowniki), więc niech popracują. P.S. Odnośnie sterowników producenta: jak wybierzesz Driver Install Tool i naciśniesz akceptuję umowę EULA i pobierz , to zobaczysz dokładną instrukcję instalacji.

Parę dni temu udało się rozwiązać problem, załatany (dla >= 4.2) i podpisany moduł wl działa. Nie udało mi się wgrać mojego klucza publicznego poprzez mokutil (ten problem dalej jest otwarty), ale wgrałem go poprzez BIOS. Okazuje się, że graficzne menu w UEFI BIOS nie działa tak jakby można było się tego spodziewać. Przynajmniej dla wersji 1901 płyty X99 Deluxe należy: 1. Idziemy do: BIOS > Advanced Mode > Boot > Secure Boot 2. Upewniamy się, czy OS type = Windows UEFI mode (nie zmieniać na Other OS) 3. Teraz dalej do Key Management i tam mamy m.in. Append Default db (można też próbować z Load Default db, chociaż wiem, że to dość dziwnie brzmi). Klikamy Append Default db i klikamy NO (tak NO, wedle opisu pojawiającego się po najechaniu strzałkami na opcję Append). Dostajemy możliwość wyboru klucza publicznego w formacie DER i klikamy na niego. Teraz pojawia się prośba o wybór typu tego klucza: podświetlony Key Certificate blob i niepodświetlony Uefi Serure Variable. Poniżej znajdują się przyciski OK i Cancel, ale NIE NACISKAMY OK POMIMO, ŻE Key Certificate blob JEST PODŚWIETLONY. ZADZIAŁA WYŁĄCZNIE KLIKNIĘCIE NA Key Certificate blob. SAM PRZYCISK OK NIE DZIAŁA Dlaczego? Nie mam pojęcia. Ważne, że jakoś działa.

Oznacza to na razie tyle, że ten wpis do 40_custom jest w pełni poprawny. Rozumiem, że to samo jest dla wszystkich: 3, 5, 6. Jeżeli chodzi o naprawę to masz tutaj: https://support.microsoft.com/pl-pl/kb/2622803 , ale to naprawi Windowsa i nie wiem czym będzie skutkować dla Fedory. Jak naprawisz Windowsa, to może się okazać, że będziesz musiał naprawić Fedorę. Rzeczywiście może brakować Ci chyba jednej partycji 100M, ale tak jak wcześniej napisałem możliwe jest umieszczenie partycji systemowej i rozruchowej jako jednej, ale jeśli sam instalowałeś Windowsa, to raczej tego nie robiłeś. (tej drugiej 450M raczej nie miałeś bo to jest Środowisko odtworzeniowe). Jestem bardzo ciekawy co jest na /dev/sda1. Teraz mocno teoretyzuję i nie wiem czy takie coś jest możliwe, ale załóżmy że usunięcie sda1 nie uszkadza partycji /boot, ew. wpis w MBR oraz (to jest dla mnie wątpliwe założenie) czy można poddać sda2 tak defragmentacji i zmniejszeniu "z przodu" o ok. 120M, aby móc powiększyć sda1. Wtedy można by usunąć całkiem sda1 i użyć odzyskiwania z powyższego linku, co skutkowałoby utworzeniem tej partycji 100M w wolne miejsce i wpisem Windowsa do MBR. O ile da się tak zmniejszyć sda2 "z przodu", co jest dla mnie mocno wątpliwe.

Pytanie 1: Plik /etc/grub.d/40_custom był już i tylko dopisywałeś do niego i 5 wierszy nagłówka zostawiłeś, tak? Pytanie 2: Po dopisaniu do /etc/grub.d/40_custom i odpaleniu grub2-mkconfig -o /boot/grub2/grub.cfg czy coś napisał, że mu się nie podoba? Zadanie 3: Ustaw zawartość /etc/grub.d/40_custom dokładnie na: #!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. menuentry "Windows 7" { insmod part_msdos insmod ntfs set root=(hd0,msdos5) chainloader +1 } Jeżeli będzie mu się coś nie podobało to powinien to zgłosić przy tworzeniu pliku grub.cfg. Ja wszędzie piszę 5, ale rozumiem, że sprawdzasz po kolei 3,5,6. Zadanie 4: U mnie fdisk -l jest bardziej wylewny i przy partycjach Windowsowych pokazuje typ słownie: System EFI (tego mieć nie będziesz), Microsoft - dane podstawowe, etc. Spróbuj poleceniem blkid dowiedzieć się coś więcej o typie każdej z tych partycji i wrzuć na forum. Może rzeczywiście coś się wycięło.

Ja niestety nie mogę tego hasła ustawić ani 'w locie' # mokutil --import public_key.der input password: input password again: Failed to enroll new keys ani ustawić, wyczyścić czy też użyć hasła roota # mokutil --password input password: input password again: Failed to write MokPW # mokutil --clear-password Failed to write MokPW # mokutil --root-pw --password Failed to write MokPW # mokutil --root-pw --import public_key.der Failed to enroll new keys # rpm -q mokutil mokutil-0.2.0-3.fc23.x86_64 Nie mam zupełnie pomysłów co mogę robić źle. Na razie podpiąłem się pod już istniejący bug 1263992

Moje próby uruchomienia WiFi wespół z Secure Boot to jakaś niekończąca się opowieść Podpisywanie modułu nie nastręcza problemów, ale mam kłopot z ręcznym dodaniem mojego klucza publicznego do listy MOK. Próbowałem wykonywać według punktu 23.7.4.3. , ale mam problem z hasłem # mokutil --import /home/adam/klucze/public_key.der > input password: > input password again: > Failed to enroll new keys # mokutil --password > input password: > input password again: > Failed to write MokPW Czy jest jakieś tajemne hasło, które ustawia producent płyty głownej (Asus), czy może to jakaś nadgorliwość SELINUX-POLICY? Jak mogę wgrać ten mój klucz publiczby do MOK? W BIOSie mam Boot > Secure Boot > Key Management > Load default db Tak, Load default db , jak kliknę to i kilknę jeszcze raz YES to załaduje domyślną db. Natomiast, według opisu, kliknięcie tego Load default db i NO pozwala na doczytanie klucza DER. Rzeczywiście pozwolił mi z USB wczytać plik z kluczem publicznym (dawał jakiś wybów, wczytaj jako BLOB i coś jeszcze, ale BLOB wybrałem). Niby zapisał zmian, ale jakoś nie widzę tego klucza, przy użyciu żadnej z komend: keyctl list %:.system_keyring dmesg | grep 'EFI: Loaded cert' Czy wiecie jak mam wczytać ten klucz DER, najlepiej tym mokutil, ale jeśli da się tylko poprzez BIOS to także będę zadowolony.

Niby ściągnąłem sobie źródła z interesującą mnie łatką nr 10 dla jądra od 4.2 : http://rpm.pbone.net/index.php3/stat/3/srodzaj/2/search/wl-kmod-6.30.223.248-9.fc22.src.rpm i udało mi się przebudować i zainstalować nowy akmod-wl, ale dalej mam problem: # modprobe wl > modprobe: ERROR: could not insert 'wl': Required key not available Jeżeli dobrze rozumiem, to mam problem z załadowaniem niepodpisanego modułu i jeżeli teraz głupot nie piszę to wynika on z faktu, iż Fedorę 23 zainstalowałem na UEFI i muszę obejść jakoś Secure Boot (tak rozwiązałem mój wcześniejszy problem z tego wątku ). Co mogę zrobić, aby nie wyłączać Secure Boot? Czy mogę jakoś sam podpisać z użyciem Machine Owner Key? P.S. Ciekawe czy uda mi się włączyć WiFi przed NVieville'em Bug 3823 z przedwczoraj