Archiv der Kategorie: Linux

Fedora Workstation 44 | Jetzt will die Maus garnicht mehr

Veröffentlicht am von
Antwort

Manche Hardware funktioniert einfach, die Microsoft Bluetooth Mouse 3600 unter Fedora 44/GNOME 50 gehört leider nicht dazu. Während sie am Surface Laptop 3 unter Windows jahrelang perfekt lief, war der Umzug auf Linux für das ‚Mausi‘ der Anfang vom Ende. Das Pairing mit Bluetooth wurde stetig schlechter, bis sie mit dem Upgrade auf Fedora 44 nun komplett unbrauchbar geworden ist.

Man muss dazu wissen, dass der mit Fedora 44/GNOME 50 eingeführte Bluetooth-Stack eine gewisse Zurückhaltung gegenüber BLE-HID-Geräten zeigt, was häufig zu Verbindungsproblemen führt.

Eine kurze Beschreibung des Problems

  • Nach dem Upgrade verbindet die Maus nicht mehr automatisch
  • Manuelles Pairing funktioniert, aber nur mit Geduld
  • Und die MAC‑Adresse der Maus wechselt fröhlich hin und her1

1) und ja, auch Bluetooth-Mäuse haben eine MAC-Adresse

Zeit also, der Sache auf den Grund zu gehen, bevor ich die Anschaffung einer neuen Maus überhaupt in Erwägung ziehe. Man ist ja irgendwo auch Schwabe 😉

Das Sympton ist, die Maus wird angezeigt aber Linux tut so als ob es eine neue wäre

Nach dem Upgrade auf Fedora 44 zeigt bluetoothctl folgende Info an:

Device F1:00:85:92:CA:34 (random)

Die Maus meldet sich mit wechselnden BLE‑Adressen. Das ist normal, nennt sich „Resolvable Private Address“ RPA . BlueZ erkennt solche Geräte über einen Identity Resolving Key (IRK). Wenn der IRK fehlt, denkt Fedora bei jeder neuen Adresse: „Noch nie gesehen …“ und das Theater geht los.

Das erklärt, warum AutoConnect nicht funktioniert, obwohl die Maus korrekt gepairt ist.

Die Ursache liegt in einem blockierten AutoConnect vor der Anmeldung

Mit GNOME 50 (und der damit einhergehenden Entwicklung in den zugrunde liegenden Bibliotheken wie bluez) wurde das Sicherheitsmodell für Bluetooth verschärft. BLE-HID-Geräte (wie die Mouse 3600) benötigen oft einen aktiven Austausch von Schlüsseln beim Reconnect. Wenn der Agent der User-Session noch nicht aktiv ist, schlägt dieser Austausch fehl oder wird vom System ignoriert, um unautorisierte Verbindungen auf Hardware-Ebene zu verhindern.

Letztendlich sehen wir die folgenden Syptome:

  • kein AutoConnect beim Boot von Linux
  • manueller Connect funktioniert (bei Fedora 44 auch nicht immer und davor doch recht zuverlässig) oft erst nach 60 bis 120 Sekunden
  • Zur Verbindung muss eine User-Session vorhanden sein

Der erste Schritt ist, dass wir mit der Maus ein neues Pairing durchführen müssen:

bluetoothctl
remove <DEVICE-MAC>
scan on
pair <DEVICE-MAC>
trust <DEVICE-MAC>
connect <DEVICE-MAC>

Schauen wir uns aber die info-Datei für die Maus an, so sind nach einen korrekt erfolgtem Pairing alle notwendigen Einträge vorhanden.

# Speicherung der Bluetooth-Informationen der Maus in der info
/var/lib/bluetooth/<ADAPTER-MAC>/<DEVICE-MAC>/info

Die Datei beinhaltet alle notwendigen Informationen wie den IRK, LTK und HID-Services.

Wir merken uns:

  • ADAPTER-MAC = Hardware-Adresse des Bluetooth-Controllers im Laptop (die ist und bleibt statisch)
  • DEVICE-MAC = Hardware-Adresse der Maus (Device), die sich in Grenzen dynamisch verhält

Den Pfad oben bauen wir als wie folgt zusammen, und dazu wechseln wir der Einfachheit halber in den interaktiven Sudo (wer in diesem verbleibt, spart sich in den kommenden Konfigurationen das nervige tippen von Befehl und Passwort):

# Wechsel in den interaktiven sudo-Modus
sudo -i

Am einfachsten (und damit ohne Tipp-Fehler), lassen sich Verzeichnispfade mit ls und der TAB-Taste verwenden:

# Dazu ls und TAB für die Expansion des folgenden Pfads verwenden
#- wichtig ist, dass die MAC-Adresse des Controllers bei Euch anders heißt!
ls '/var/lib/bluetooth/F0:1D:BC:9C:AC:9D'

Hängen wir dann an diesen Pfad die DEVICE-MAC mit an, können wir im Verzeichnis die info-Datei der Microsoft Bluetooth 3600 finden.

Damit ist die technische Basis gelegt.

Die zweite Baustelle sind die wechselnden MAC-Adresse der Maus (DEVICE-MAC)

Die Microsoft Maus nutzt Adressen, die immer mit F1:00:85: beginnen. Der Rest ändert sich.
BlueZ erkennt die Maus über den IRK, aber GNOME 50 leider nicht zuverlässig.

Das Problem konnte mit einer udev-Regel, die hilft den Connect auszulösen, sobald die Maus auftaucht, gelöst werden.

Die Sache wird nun als dritter Schritt an systemd übergeben und dort in eine Regel gepackt

# udev-Regel erstellen
sudo nano /etc/udev/rules.d/99-bt-mouse-autoconnect.rules

# Inhalt der Regel
ACTION=="add", SUBSYSTEM=="bluetooth", ATTR{address}=="F1:00:85:*", RUN+="/usr/bin/bluetoothctl connect %E{address}"

Genau genommen arbeitet die Regel die folgenden Aufgaben ab:

  • Sie reagiert auf jedes Bluetooth‑Gerät, dessen Adresse mit F1:00:85: beginnt
  • %E{address} übergibt die aktuelle (random) MAC an bluetoothctl
  • GNOME 50 wird komplett umgangen
  • Die Maus verbindet sobald sie auftaucht

Die Regel sollte automatisch ausgeführt werden und damit blieb nur der Weg das mit einem systemd-Service um GNOME „herumzubauen“ (zumindest habe ich keine andere Möglichkeit gefunden).

Damit umschiffen wir die folgenden Problemzonen:

  • GNOME‑Agent‑Blockade
  • Race‑Condition beim Login
  • 60–120‑Sekunden‑Timeout
  • verzögerten BLE‑Reconnect

Der funktionierende systemd-AutoConnect-Service:

# Als erstes muss der Service angelegt werden
sudo nano /etc/systemd/system/bt-mouse-autoconnect.service

# Und der Service in der Config definiert werden
[Unit]
Description=Auto-connect Bluetooth Mouse after GNOME startup
After=graphical.target bluetooth.service
Wants=bluetooth.service

[Service]
Type=oneshot
ExecStart=/usr/bin/bluetoothctl connect F1:00:85:93:CA:34
ExecStart=/usr/bin/sleep 2
ExecStart=/usr/bin/bluetoothctl connect F1:00:85:93:CA:34

[Install]
WantedBy=graphical.target

Das Timing im Logon-Prozess ist nicht ganz optimal, darum probiert es der Service mit dem Start nach 2s ein zweites Mal.

Zum Schluss fehlt nur noch die Aktivierung des Service verbunden mit einem Neustart:

# Aktivierung des Service
sudo systemctl daemon-reload
sudo systemctl enable bt-mouse-autoconnect.service

# Reboot
sudo reboot

Fazit

Die Maus läuft und ich muss keine neue mehr besorgen, zumal ich die Teile immer sehr mochte da sie wirklich robust und zuverlässig waren sind. Auch wenn ich mich erneut an dem Surface Laptop anmelde, ist die Maus nach ca. 30 Sekunden da. Man könnte hier sicherlich noch eine Reihe von Optimierungen und Retries bauen, ich will es aber dabei belassen. Wie sagt der Schwabe gerne „für me duats des“ … und er ist glücklich, muss er doch keine neue Maus kaufen.

Enjoy it, b!

Upgrade | Fedora Workstation 44

Veröffentlicht am von
Antwort

Ende April war es wieder so weit: Eine neue Fedora-Version stand vor der Tür. Mein bewährter Surface Laptop 3 wartete bereits auf das Upgrade auf die Version 44. Doch diesmal lief der Prozess über die Shell nicht ganz so reibungslos durch, wie ich es gewohnt war. Ein Paketkonflikt im Bereich des Power-Managements stoppte das Vorhaben abrupt.

Das Problem waren die Pakete für das Power-Management

Beim Versuch, das Upgrade einzuspielen, brach DNF mit einer Fehlermeldung ab. Der Kern der Nachricht: Dateikonflikte zwischen tlp und tuned-ppd. Beide Pakete versuchten, dieselben DBus-Service-Dateien unter /usr/share/dbus-1/ zu beanspruchen.

Hier der Fehler im Detail:

Fedora hat mit Version 44 den Wechsel hin zu tuned als Standard-Daemon für Stromsparprofile vollzogen. tuned-ppd dient dabei als Schnittstelle, damit die GNOME-Einstellungen (der Schieberegler für „Leistung/Ausbalanciert/Energiesparen“) weiterhin funktionieren. Wer – wie ich – in der Vergangenheit manuell TLP installiert hat, um das Maximum aus dem Akku des Surface herauszuholen, gerät hier in einen harten Ressourcenkonflikt.

Die Lösung war die Deinstallation von TLP

Da Fedora 44 nun massiv auf tuned setzt, habe ich mich dazu entschieden, TLP den Laufpass zu geben und auf den neuen Standard zu setzen. Damit war der Weg für das Upgrade frei.

Folgende Schritte in der Shell haben das Problem gelöst und beschreiben dazu noch das Upgrade:

Die Befehle und Fehlermeldungen findet ihr in dieser Datei, aber bitte nur Schritt für Schritt ausführen.

Nach dem Upgrade ist vor dem Upgrade …

Was mir sonst noch aufgefallen ist (nach dem Upgrade):

Das bisher verwendete Hintergrundbild stammte noch aus Fedora 43 und wurde beim Upgrade entfernt. Daher musste ich ein neues Wallpaper aus dem Fedora‑44‑Paket auswählen.

Die OneDrive‑Integration schlug wiederholt fehl. Erst nach dem vollständigen Entfernen der bestehenden Verbindung und einer neu erforderlichen App‑Registrierung über GNOME konnte die Synchronisation wiederhergestellt werden

Fedora Workstation verwendet aktuell noch den 6er‑Kernel. Das ist jedoch kein Nachteil – das System läuft stabil, wie schon seit langer Zeit.

Fazit

Wieso es genau zu diesem Konflikt kam? Wahrscheinlich habe ich in Fedora 43 zu intensiv an den Energieeinstellungen optimiert und dabei TLP als Ergänzung oder Ersatz installiert. Da Fedora 44 nun eine eigene, moderne Architektur für diese Profile mitbringt (tuned-ppd), vertragen sich die beiden Ansätze auf Dateiebene nicht mehr.

Nach dem Reboot lief mein Surface Laptop 3 anstandslos unter Fedora 44 hoch. Wer also vor einem ähnlichen „Transaction failed“ steht: Prüft eure installierten Power-Management-Tools und werft einen Blick auf die Gnome-Extensions, nicht alle waren zum Start von Fedora 44 kompatibel.

No Panic please!

Ja, nein, vielleicht — und bevor ich mich weiter in dieser Antwortmatrix verliere, schreibe ich jetzt einfach ein paar Sätze. Dieser Blog hier nennt sich Windows SBS und Essentials Blog, und genau so ist er im Mai 2008 gestartet. Der erste Beitrag? Natürlich ein Defekt des CPU‑Lüfters in einem Lexmark X502n Multifunktionsdrucker. Ein würdiger Auftakt für eine lange Reise voller Themen, die streng genommen alle aus dem Small‑ und Medium‑Business‑Umfeld stammen. Und ja: Ich dachte damals, das könnte vielleicht irgendjemandem helfen.

Zur Überraschung: Hat es und tut es immer noch, auch wenn sich die KI an den Themen sattfrist und 50% der Hits weggefallen sind.

Den eigentlichen Windows Small Business Server (SBS) und seinen Nachfolger, den Windows Server 2012 Essentials (SBE), hat uns Microsoft dann genommen — in der charmanten Annahme, kleine Firmen würden natürlich alle in die Cloud wechseln.

Spoiler: Das war gleichzeitig richtig und komplett daneben. Die Chance, Exchange aus den Kellern der Kunden zu befreien und in kompetente Hände zu legen, konnte ich mir jedenfalls nicht entgehen lassen. Also habe ich ASAP eine Menge Migrationen von Exchange (SBS 2008 R2) nach BPOS durchgeführt. Und obwohl ich im Enterprise‑Bereich schon einige Exchange‑Wiederherstellungen überlebt hatte, wollte ich mir diesen Nervenkitzel bei kleinen Kunden nicht mehr antun. Man wird ja nicht jünger. Zusätzlich gibt es im SMB-Umfeld eine Reihe von LOB-Anwendungen die ein wahres Horrorkabinet darstellen … und während die Hyperscaler an die Cloud denken, kämpfe ich mit „lokalen Admins“ damit die Praxissoftware überhaut läuft!

Linux und ich — das ist übrigens keine Beziehung, die erst begann, als virtuelle Router plötzlich „hip“ wurden oder eine SSH‑Session auf ein Synology‑NAS die Tür zu erweiterten Konfigurationen (oder nennen wir es ruhig „Hacks“) öffnete. Nein, Linux war mein zweiter Dateiserver nach Novell NetWare 3.1. Irgendwann in den 90ern habe ich mich — schneller als manche Großunternehmen — entschieden, im Heimnetz auf TCP/IP umzusteigen. Aus Kostengründen lief auf dem Server Linux mit einem Kernel 1.x und Samba. Der Client war bis 1996 OS/2 Warp 3, und erst dann haben Windows NT 4.0 und ich uns endlich gefunden. Eine späte, aber stabile Beziehung.

Grundsätzlich soll hier jedes Betriebssystem seinen Platz finden, das im SMB‑Umfeld sinnvoll ist und mich gelegentlich an den Rand der Verzweiflung bringt — äh, ich meine: vor interessante Herausforderungen stellt.

Darum wird es in diesem Blog auch weiterhin um Themen aus dem SMB‑Kosmos gehen. Vielleicht nenne ich ihn irgendwann sogar „Small‑ und Medium‑Business‑Blog“ oder etwas ähnlich Kreatives. Was meint ihr dazu?

Enjoy it, b!

Routing mit Linux in virtuellen Umgebungen

Veröffentlicht am von
Antwort

Vor 4 Jahren hatte ich einen Blog geschrieben, wie man einen Microsoft Hyper-V Server 2016 als Router “verwenden” kann.

Natürlich stellt man sich dabei die Frage, wieso man das tun sollte? Zum einen ist der Hyper-V Server von Microsoft kostenlos und hat als Mitglied der Windows Server Core Familie geringere Systemanforderungen.

Es gibt hier eine Alternative, dazu müssen wir aber die Windows-Welt verlassen und uns Linux anschauen. Ich selbst bin historisch mit SUSE Linux verbunden, daher habe ich für diese Lösung openSUSE Leap 15.2 verwendet.

Als Ausgangslage haben wir die gleichen Voraussetzungen wie im Blog damals, also gleiche Netzwerke, IP-Adressen und die FRITZ!box usw. Also einfach mal den Blog nochmals anschauen, dort ist auch die Konfiguration der FRITZ!box selbst beschrieben.

Ausgangslage

Hier eine kurze Zusammenfassung davon:

  • Server mit 3 Netzwerkkarten (172.16.16.253, 192.168.110.0 und 192.168.120.1)
  • Fritz!BOX für den Internet-Zugang
  • Netzwerk an der FRITZ!box ist 172.16.16.0/24, das Gateway ist immer die 1 (also die FRITZ!box selbst)

Konfiguration der Linux VM

Für die VM unter Hyper-V habe ich die folgenden Parameter verwendet:

  • Hyper-V Generation 2 VM mit deaktiviertem Secure Boot
  • 2 CPUs
  • Dynamischer Hauptspeicher mit 1GB Start und maximal 2GB, im Betrieb läuft die VM mit grob 800MB
  • 64GB Festplatte (wobei hier auch weniger ausreichend ist), da die VHDX aber dynamisch ist, stellen die 64GB kein Problem dar
  • Zum Start nur einen Netzwerk-Adapter, wobei im Verlauf der Konfiguration weitere hinzugefügt werden

Die folgende Abbildung zeigt eine Übersicht der VM.

image

Installation openSUSE Leap 15.2 in der VM

Für die Installation wird das ISO-Image gemounted und die VM gestartet.

image

Im nun folgenden Menü Installation auswählen und den Dingen seinen Lauf lassen.

image

Da die VM über den einen Adapter eine IP-Adresse vom DHCP-Server bekommen hat, ist das Linux Setup in der Lage ggf. notwendige Updates aus dem Netz zu laden. Nach knapp 2min erscheint die Auswahl zur Konfiguration der Tastatur und der Lizenzvereinbarung. Ich verwende gerne VMs in englischer Sprache (English US) dazu aber eine Tastatur mit den deutschen (QWERTZ) Layout.

image

Hier dann auf Next drücken. Im nun folgenden Menü können wir auf eine Aktivierung von Online Repositories für unseren Zweck verzichten, also No auswählen.

image

Da wir einen schlanken Server wollen, treffen wir die Auswahl Server bei der Abfrage der System Role. Damit  haben wir zwar keine Oberfläche, können aber auf YaST zurück greifen, der alle notwendigen Aufgaben für uns erledigen kann.

image

Weiter geht es mit Next mit dem Vorschlag der Partitionierung die wir so übernehmen können.

image

Hier ebenfalls mit Next die Installation fortsetzen. Als Zeitzone wähle ich Europe und Germany und drücke abermals den Next Button.

Der Benutzer der im nächsten Schritt angelegt wird, findet später seine Verwendung für alle Aufrufe mit sudo.

image

Mit der Übersicht der gewählten Parameter kann die Installation starten.

image

Die gut 800 Pakete mit knapp 2GB Gesamtgröße installiert das Setup relativ schnell, für einen Kaffee reicht es aber trotzdem Smile

Konfiguration der Netzwerk-Adapter

Nach dem Neustart kann das ISO von der VM entfernt werden und die Anmeldung erfolgen.

image

YaST wird danach mit dem sudo Befehl gestartet und alle weiteren Schritte erfolgen im YaST Control Center unter System / Network Settings.

image

Als erstes verpassen wir der Netzwerkkarte eine feste IP (172.16.16.253/24). Dazu wird mit Edit die Konfiguration bearbeitet. Innerhalb von YaST springt man mit der TAB-Taste zwischen den einzelnen Menüpunkten hin und her. Zusätzlich zur IP-Adresse setze ich auch gleich den Hostnamen.

image

Mit Next bekommen wir wieder die Übersicht über die gemachten Einstellungen.

image

In den Einstellungen System / Network Settings / Hostname / DNS trage ich nochmals einen statischen Hostnamen ein und dazu noch die beiden im Netzwerk vorhandenen DNS-Server.

Mit Quit wird YaST beendet und die VM heruntergefahren, was wieder mit einem sudo shutdown erfolgt. Das Herunterfahren der VM ist notwendig, da ich zwei weitere  Netzwerk-Adapter hinzufüge die mit den Netzen 192.168.110.0/24 und 192.168.120.0/24 konfiguriert werden.

image

Der Trick, nur einen der beiden neuen Netzwerk-Adapter zu verbinden funktioniert unter Linux leider nicht, beide werden als Not Connected dargestellt. Nach dem Start der VM sind beide Netzwerk-Adapter zusätzlich sichtbar und können konfiguriert werden.

image

Welcher nun der richtige Adapter ist, lässt sich über die MAC-Adresse herausfinden.

image

Der Adapter eth1 bekommt nun die IP-Adresse 192.168.110.1/24 und dient zukünftig als Gateway für dieses Subnetz.

image

Analog dazu Adapter eth2 mit der Konfiguration 192.168.120.1/24 hier die Zusammenfassung aller Netzwerk-Adapter.

image

Was fehlt nun eigentlich noch? Richtig, wir haben das Routing selbst nicht aktiviert und ein Gateway ist ebenfalls noch nicht konfiguriert. Das erfolgt in den nächsten beiden Schritten.

Gateway und Routing

Die bisher gemachten Konfigurationen kann man mit der Auswahl von Next einfach mal schreiben lassen und hat diese damit gesichert.

Danach sind wir wieder im YaST Control Center unter System / Network Settings unterwegs.

image

Dort wird unter Network Settings / Routing die Weiterleitung für IPv4 aktiviert (wer hier IPv6 benötigt, bitte zusätzliche diese Option auswählen).

image

Damit fehlt nur noch das Gateway und das ist im YaST in der Textversion nach meiner Meinung fies versteckt.

Der Dialog zur Konfiguration ist unter System / Network Settings / Routing und dann unter der Option Add zu finden.

image

Hier wird das Gateway 172.16.16.1 für den Adapter mit der IP-Adresse 172.16.16.253 konfiguriert und damit die Konfiguration abgeschlossen.

Wer will, kann die VM nochmals neustarten. Bei mir hat es ohne diesen geklappt und der Router war fast fertig, denn natürlich muss noch die Firewall konfiguriert werden, sonst geht bei der Einstellung default nur der Ping durch.

Konfiguration der Firewall

Die Firewall in openSUSE verwendet Zonen, die eine Sammlung von geöffneten Ports und Protokollen darstellen. Ich habe die Firewall auf trusted gesetzt, damit ist ein interner Datenverkehr ohne weiteren Einschränkungen möglich.

image

Dazu werden die Netzwerk-Adapter mittels YaST von der Zone default in die Zone trusted geändert.

image

Enjoy it, b!

IPv6 Configuration OpenSuse Leap

Veröffentlicht am von
Antwort

Verwendet man eine FRITZ!Box in seinem LAN dann kann einem die schwer kontrollierbare Vergabe von IPv6-Adressen durchaus Probleme machen. Das Deaktivieren von IPv6 auf allen Windows Systemen halte ich hier für keine saubere Lösung, vielmehr habe ich mich dazu entschlossen die IPv6-Adressen selbst zu vergeben. Darüber will ich in diesem Blog aber gar nicht schreiben, sondern wie einem openSUSE Server eine funktionierende IPv6 Konfiguration eingestellt werden kann.

Eckdaten

  • IPv6 Adresse für den OpenSuse Server: fd8e:5644:167b:100a::18
  • IPv6 Adresse für den Router / Gateway: fd8e:5644:167b:100a::1
  • Interface für die Konfiguration: eth0

Konfiguration

Im Gegensatz zu Windows, ist es bei Linux möglich IP-Adressen nur zur Laufzeit zu konfigurieren oder aber statisch, damit die Konfiguration einen Neustart überlebt.

Die Konfiguration zur Laufzeit ist dabei recht einfach, benötigt aber die Rechte des SU.

# ip -6 address add fd8e:5644:167b:100a::18/64 dev eth0

# ip -6 route add default via fd8e:5644:167b:100a::1 dev eth0

Statisch erfolgt die Konfiguration wie folgt:

# cd /etc/sysconfig/network

# vi ifcfg-eth0

# hinzufügen der folgenden Zeilen ans Ende der Datei (ifcfg-eth0)
LABEL_0='0'
IPADDR_0='fd8e:5644:167b:100a::18'
PREFIXLEN_0='64'

# echo 'default fd8e:5644:167b:100a::1 - -' >> /etc/sysconfig/network/routes

Damit die Konfiguration aktiv wird, entweder den Server neu starten oder den folgenden Befehl ausführen.

# service network restart

Enjoy it, b!

Hyper-V Linux VM Boot Problem

Veröffentlicht am von
Antwort

Für einen aufwendigeren Test hatte ich mir unter Hyper-V eine Linux VM (Generation 2 mit CentOS 7.4) konfiguriert, mit der Absicht deren Disk für eine Reihe weiterer VMs zu verwenden … analog zum SysPrep von Windows.

Der Boot einer neuen VM mit der kopierten Linux VHDX ging aber sofort, mit der folgenden Meldung daneben.

image

Die Lösung des Problems ist, wenn man die notwendigen Schritte kennt nicht sonderlich schwer. Eigentlich haben wir ein Problem mit dem Bootloader von Linux.

Im ersten Schritt schalten wir die VM über das Hyper-V Management aus und fügen im Anschluss (wenn die VM aus ist) ein Linux ISO hinzu. Danach verändern die Boot Reihenfolge so, dass die VM von der DVD (sprich dem ISO Image startet).

image

Die Änderung erfolgt unter Change Hardware/Firmware/Boot order im Hyper-V Management und sollte das DVD-Laufwerk an erster Stelle haben.

  1. DVD Drive
  2. Hard Drive
  3. Network Adapter

Nun wird die VM wieder eingeschaltet und es erfolgt ein Boot von der DVD. Innerhalb des Boot-Menüs erfolgt dann die Auswahl Select Troubleshooting / Rescue a CentOS system.

image

Linux erkennt nun die vorhandene Installation und mounted diese unter /mnt/sysimage

Damit liegt unser Boot-Verzeichnis unter /mnt/sysimage/boot/efi/EFI und wir können das mit Hilfe der folgenden Schritte reparieren.

# Wechsel in das EFI Verzeichniss
cd /mnt/sysimage/boot/efi/EFI
# "Weg-Kopieren" des Boot files
cp -r centos/ boot
# ODER ALTERNATIV bei Ubuntu
cp -r ubuntu/ boot
mv fbx64.efi grubx64.efi

Nun fahren wir das Linux System wieder runter …

shutdown

… schalten die VM aus und ändern erneut die Boot-Reihenfolge unter Change Hardware/Firmware/Boot order im Hyper-V Management damit nun die VHD an erster Stelle steht.

  1. Hard Drive
  2. DVD Drive 
  3. Network Adapter

Damit startet mein CentOS ohne Probleme.

Enjoy it, b!

Lenovo T410 aktivieren von Bluetooth unter Windows 10

Veröffentlicht am von
Antwort

Um an einem Lenovo Notebook Bluetooth zu aktivieren gibt es eine Vielzahl von Möglichkeiten, welche hier im thinkwiki sehr gut beschrieben sind.

Mit einem Lenovo T410 (ein älteres Modell) hatte ich hier so meine Probleme. Ein Bekannter wollte daran eine Microsoft Bluetooth-Maus aktivieren was einfach nicht klappen wollte.

Bei solchen Problemen schaue ich als erstes in den Gerätemanager um nach deaktivierten oder nicht sauber installierten Geräten zu suchen.

Im Gerätemanager (auch nach der Anzeige von versteckten Geräten) waren aber keine Auffälligkeiten zu finden … nur das halt der Bluetooth-Stack garnicht vorhanden war.

OK, ein Blick ins BIOS des Notebooks (Blaue Taste beim Start) zeigte, dass Bluetooth aktiviert ist. Damit konnte ich schon einmal die Aussage, dass dieses Notebook KEIN Bluetooth hätte, entkräften.

Die Installation des Lenovo Hotkey-Utilities unter Windows brachte aber auch keine Lösung. Normaler weise kann der Bluetooth-Stack mit FN+F5 aktiviert oder deaktiviert werden.

Nach einiger Recherche im Internet bin ich auf den Hinweis gestoßen, dass Notebook mit einer Linux-Live-CD zu booten und 1x FN+F5 unter Linux zu drücken (angezeigt wird bei dieser Aktion nichts!), außer das der Bluetooth-Stack aktiviert wird.

So richtig glauben wollte ich die Sache nicht, aber einen Versuch war es wert. In Ermangelung einer Live-CD habe ich meinen c’t Desinfect USB Stick verwendet, damit das Notebook gestartet, und genau 1x FN+F5 gedrückt. Wie beschrieben passierte augenscheinlich nichts, aber in der Systemsteuerung unter Linux war nun Bluetooth vorhanden und ich konnte hier, unter Windows die Maus koppeln … und wenn es unter Linux geht, dann muss es auch unter Windows gehen.

Nach einem Neustart mit Windows 10 hat sich, der nun aktivierte Bluetooth-Stack mit dem aktuellen Treiber versorgt und auch hier klappte die Kopplung der Maus ohne Probleme.

Der Hintergrund ist wohl der, dass wenn der Bluetooth-Stack deaktiviert Windows dafür keinen Treiber lädt, welchen aber wiederum der Hotkey FN+F5 zur Aktivierung / Deaktivierung benötigt. Erfolgt nun bei deaktiviertem Bluetooth eine Neuinstallation, so dreht man sich mi Kreis. Ohne Treiber keine Aktivierung von Bluetooth, und ohne aktiven Bluetooth-Stack keine Installation des Treibers …

Abschließend hatte Linux hier die Lösung gebracht!

Know your gear, b!