Fedora 24: Wenn Automount nicht mehr geht

Wenn man einen USB-Stick in seinen Rechner steckt, erwartet man eigentlich, daß er als Laufwerk auftaucht. Seitdem Update auf Fedora 24 passierte das bei mir nicht mehr.

Schuld dürfte das unterbrochene Upgrade von F23 auf F24 sein, aber wer weiß.  Erstmal die Lage feststellen…

Werden die Drives gefunden ?

Als erstens schauen wir ins .. ups.. das gibt bei Euch nicht ja gar nicht mehr… /var/log/messages (Pech, ich habs noch 🙂 ) Wenn Ihr /v/l/m nicht mehr habt, dann könnt Ihr z.B. „dmesg“ befragen.

Steckt man einen USB Stick rein, muß sowas im Log erscheinen:

Nov  2 15:51:07 eve kernel: usb-storage 3-2:1.0: USB Mass Storage device detected
Nov  2 15:51:07 eve kernel: scsi host4: usb-storage 3-2:1.0
Nov  2 15:51:08 eve kernel: scsi 4:0:0:0: Direct-Access     Intenso  Rainbow Line     8.07 PQ: 0 ANSI: 4
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: Attached scsi generic sg4 type 0
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] 7907328 512-byte logical blocks: (4.05 GB/3.77 GiB)
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Write Protect is off
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
Nov  2 15:51:08 eve kernel: sdd: sdd1
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Attached SCSI removable disk

Merkt GVFS, daß ein Gerät angeschlossen wurde ?

In einer Bash als normaler User führt Ihr mal „gvfs-mount -o -i“ aus:

Da müßte dann sowas stehen :

Drive changed:      'Intenso Rainbow Line'
  Drive(0): Intenso Rainbow Line
    Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
    ids:
     unix-device: '/dev/sdd'
    themed icons:  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    symbolic themed icons:  [drive-removable-media-usb-symbolic]  [drive-removable-media-symbolic]  [drive-removable-symbolic]  [drive-symbolic]  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    is_media_removable=1
    has_media=1
    is_media_check_automatic=1
    can_poll_for_media=0
    can_eject=1
    can_start=0
    can_stop=0
    start_stop_type=shutdown
    sort_key=01hotplug/1478096885644198

Volume added:       'Daten'
  Volume(0): Daten
    Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    ids:
     class: 'device'
     unix-device: '/dev/sdd1'
     uuid: '227C9F0E7E06FAF9'
     label: 'Daten'
    themed icons:  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    symbolic themed icons:  [drive-removable-media-usb-symbolic]  [drive-removable-media-symbolic]  [drive-removable-symbolic]  [drive-symbolic]  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    can_mount=1
    can_eject=1
    should_automount=1
    sort_key=gvfs.time_detected_usec.1478096885851240

d.b. das GVFS Kenntnis von dem neuen Gerät hat und nun an den Filemanager melden kann, daß DER es einhängen soll.

Wieso werden die dann nicht gemountet ?

Um das zu beantworten muß man etwas über Prozesskommunikation wissen. Die im OS dafür zuständige Komponente heißt D-BUS . Über den D-BUS kann Anwendung A Informationen an Anwendung B senden. Damit das auch bei Desktopanwendungen funktioniert, braucht es eine Spezialversion D-BUS X11 .

Die hatte es wohl bei meinem unterbrochenen Upgrade nicht sauber installiert, also holen wir das nach:

dnf reinstall dbus-x11

Reinstall simuliert das Entfernen und erneute Installieren in einem Rutsch. Danach noch Nautilus oder Nemo neu starten:

killall nautilus; nautilus --force-desktop

und schon tauchen die Laufwerke auch wieder auf dem Desktop und im Nautilus auf.

So leicht das hier auch klingt, in Realität hat es Stunden gedauert, bis ich das gefunden hatte.

Lenovo & Microsoft sperren Linux aus

Microsoft liebt Linux ? wohl kaum. Die neusten Gerüchte und Berichte deuten eher auf eine Verschwörung gegen Linux hin, denn Microsoft hat Lenovo zu einem Windows-10-Only-Deal für eine Laptopserie  gebracht.

Die Ultrabooks der Yoga 900 Serie sind technisch in einem Zustand, in dem nur Windows 10 damit umgehen kann. Laut einem Bericht der HackerNews wurde die SSD in einen properitären Raidzustand gebracht, so daß andere Betriebssysteme diese nicht ansprechen können.

Aufgedeckt hat das ein Reddit User namens BaronHK, dem es am Ende aber gelang, die SSD zu reseten und damit wieder für Linux erreichbar zu machen. Von einem Kauf ist aber grundsätzlich abzuraten, da sowas natürlich nicht noch gefördert werden muß.

Lenovo Mitarbeiter haben das Verhalten bestätigt und erklärt, daß es auf einen Deal mit Microsoft zurück geht.

Fazit: Microsoft bleibt der Feind, der er immer war und Lenovo würde ich eh nicht kaufen 😉

Der vollständigkeithalber sei erwähnt, daß es auch Berichte gibt, in denen Lenovo eine Verschwörung bestreitet: SlashDot

Im TheHackerNews Artikel wird allerdings ein Post einer Lenovomitarbeiters verlinkt, der das Gegenteil zu beweisen scheint.

Update 11:43 Uhr:

Die Sache schlägt in den Medien so einige Wellen. Für Euch ungefiltert die Links, die ich so gesehen habe:

GNOME:  http://mjg59.dreamwidth.org/44694.html
Heise:       http://www.heise.de/newsticker/meldung/Lenovo-und-Microsoft-blocken-Linux-Installation-auf-Notebooks-wohl-nicht-absichtlich-3329244.htmlGolem:     http://www.golem.de/news/fehlende-treiber-intel-verhintert-linux-installation-auf-lenovo-laptops-1609-123393.html
SlashDot:  http://rss.slashdot.org/~r/Slashdot/slashdot/~3/TVPj3XjkwvE/lenovo-denies-claims-it-plotted-with-microsoft-to-block-linux-installs
The Register: http://www.theregister.co.uk/2016/09/21/lenovo_denies_plot_with_microsoft_to_block_linux_installs/

Zu guter Letzt, der Auslöser der Sache: Reddit.com

https://www.reddit.com/r/linux/comments/53ri0m/warning_microsoft_signature_pc_program_now/