Fryboyter

Windows leichter mit Syslinux starten

Wenn man mit dem Bootloader syslinux neben Linux auch Windows starten will, erfolgt dies bei Festplatten mit MBR (nicht GPT!) beispielsweise über folgenden Eintrag in der Datei /boot/syslinux/syslinux.cfg.

...
LABEL windows
	MENU LABEL Windows
	COM32 chain.c32
	APPEND hd0 3
...

Hd0 ist in diesem Fall die erste vom BIOS/UEFI erkannte Festplatte. Und 3 bezieht sich auf die dritte Partition auf dieser Festplatte. Was aber, wenn man mehrere Festplatten installiert hat und Windows nicht auf der gleichen Platte wie Linux installiert ist? Man müsste herausfinden in welcher Reihenfolge das BIOS/UEFI die Festplatten erkennt. Hierbei muss man beachten, dass Festplatten ab 0 gezählt werden, Partitionen aber ab 1. Also warum das ganze nicht etwas einfacher lösen?

Mit dem Befehl “fdisk -l” lässt man sich zuerst die ganzen vorhandenen Festplatten anzeigen und sucht sich dann die Festplatte, auf der Windows installiert ist, heraus. Sollte man wissen auf welcher Festplatte Windows installiert ist, kann man sich diese auch direkt mit beispielsweise “fdisk -l /dev/sde” anzeigen lassen. Das sieht dann beispielsweise wie folgt aus.

Festplatte /dev/sde: 238,49 GiB, 256060514304 Bytes, 500118192 Sektoren
Festplattenmodell: Crucial_CT256MX1
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x0000d958

Gerät      Boot    Anfang      Ende  Sektoren  Größe Kn Typ
/dev/sde1  *         2048    206847    204800   100M  7 HPFS/NTFS/exFAT
/dev/sde2          206848 499123111 498916264 237,9G  7 HPFS/NTFS/exFAT
/dev/sde3       499124224 500113407    989184   483M 27 Verst. NTFS WinRE

Wichtig ist hier im Grunde nur der Festplattenbezeichner. Diesen merken wir uns und ändern den Eintrag von Windows in der Konfigurationsdatei von syslinux wie folgt ab.

...
LABEL windows
	MENU LABEL Windows
	COM32 chain.c32
	APPEND mbr:0x0000d958
...

Mit diesem Eintrag sollte man Windows nun problemlose per Chainloading starten können.

Wenn Windows 10 verhindert, dass man NTFS-Partitionen unter Linux mit Schreibrechten mountet

Auf einem Rechner ist sowohl Windows als auch Linux installiert. Der Datenaustausch erfolgt über eine NTFS-Partition, die unter Linux mit ntfs-3g eingebunden wird. Seit einiger Zeit wird die Partition aber plötzlich nur noch mit Leserechten gemountet.

Nach einigem hin und her (fstab geprüft, nachgeschaut ob ntfs-3g noch installiert ist usw.) habe ich festgestellt, das Windows die Ursache ist. Bis vor kurzem lief auf dem Rechner noch Windows 7 und wurde nun über das kostenlose Upgrade auf Windows 10 aktualisiert (ja das funktioniert immer noch). Unter Windows 10 gibt es so eine nette Funktion namens Schnellstart. Und genau diese Funktion bewirkt, dass ntfs-3g die Partitionen nur mit Leserechten mountet um Probleme zu vermeiden.

Da es bei dem betreffenden Rechner egal ist, ob der Rechner nun in 15 oder 20 Sekunden startet, ist die Lösung recht einfach. Man deaktiviert den Schnellstart. Hierfür öffnet man die Systemsteuerung und wählt unter Hardware und Sound die Energieoptionen aus. Dort gibt es den Punkt “Auswählen, was beim Drücken von Netzschaltern passieren soll”. Hier findet man dann unter “Einstellungen für das Herunterfahren” die Option “Schnellstart aktivieren (empfohlen)”. Leider ist dieser normalerweise ausgegraut, sodass man hier den Haken nicht entfernen kann. Von daher muss man erst noch auf den Link “Einige Einstellungen sind momentan nicht verfügbar” klicken. Danach kann man den Haken bei “Schnellstart aktivieren (empfohlen)” entfernen und die Einstellungen speichern. Nach einem Neustart von Linux sollte nun die NTFS-Partition wie gewohnt mit Schreibrechten gemountet werden.

Windows PowerShell für Linux und OS X veröffentlicht

Unter Windows setze ich die PowerShell recht gerne ein, da sich damit einiges mehr bzw. einfacher machen lässt als mit dem normalen Kommandozeilenprogramm cmd.exe. Microsoft hat den Sourcecode der PowerShell nun unter der MIT-Lizenz auf Github veröffentlicht. Das Ganze ist aktuell als Alpha-Version gekennzeichnet.

Neben dem Sourcecode werden neben den Paketen für Windows auch Pakete für Ubuntu, CentOS und OS X angeboten. Wer will, kann somit die PowerShell auch abseits von Windows nutzen. Ich selbst werde unter Linux aber bei der ZSH bleiben. Für Arch Linux gibt es übrigens auch schon ein Paket im AUR. Allerdings scheint hier die Installation noch nicht ganz zu funktionieren.

Wenn das Team verliert weil die Stromsparfunktion spinnt

Stellt euch vor, ihr spielt gerade mit mehreren Leuten im Internet ein Spiel, das Teamarbeit erfordert. Stellt euch weiterhin vor, das mitten im Spiel die Tastatur nicht mehr funktioniert. Stellt euch auch mal vor, dass man deswegen auch die eine oder andere Runde verliert. Dann wisst ihr wie genervt ich bis vor ein paar Tagen war.

Im Moment spiele ich eigentlich nur Overwatch. Ein FPS in dem zwei Teams gegeneinander antreten. Wenn dann in Runde 5 nach zwei Minuten ein Teammitglied ausfällt, weil seine Tastatur nicht mehr reagiert ist das ziemlich blöd. Noch blöder ist es, wenn man die Tastatur nur wieder zum Laufen bekommen, wenn man entweder den Rechner neu startet oder unter den Tisch kriecht, den Stecker der Tastatur abzieht, bis drei zählt und ihn wieder ansteckt. Da ein Spiel in Overwatch in der Regel nur 5 Minuten dauert, kann man das Spiel eigentlich abhaken. Dass die eigenen Teammitglieder das nicht so toll finden, brauche ich vermutlich gar nicht erwähnen.

Auf der Suche nach dem Problem, welches ausschließlich unter Windows auftritt und nie unter Linux, habe ich die Ereignisanzeige durchgeackert. Nichts, was auf Eingabegeräte hinweist. Dann habe ich geschaut, ob Windows vielleicht die Tastatur (Ducky Shine 3) ausschalten darf, um Energie zu sparen. Auch das war nicht der Fall. Zumal die Beleuchtung der Tastatur ja auch dann weiter geleuchtet hat, wenn das Problem aufgetreten ist. Ich habe Maus und Tastatur auf andere USB-Anschlüsse umgesteckt. Nach neuen Treibern gesucht. Die Firmware der Tastatur aktualisiert. Ich habe sogar die Platten auf Fehler überprüft (wieso auch immer. Zumindest habe ich so festgestellt, dass ein Datengrab wohl langsam erneuert gehört. Aber das ist ein anderes Thema).

Vor kurzem habe ich den Übeltäter erwischt. Im Gerätemanager sind bei mir einige USB-Root-Hubs aufgeführt. Und ratet mal, was hier die Standardeinstellung ist? Windows darf diese bei Bedarf ausschalten, um Strom zu sparen. Scheinbar ist es Windows recht egal, wie ein angeschlossenes Gerät, welches über den USB-Root-Hub gesteuert wird, eingestellt ist. Denn nachdem ich (vorsorglich) allen USB-Root-Hubs die Erlaubnis entzogen habe, dass Windows diese ausschalten darf, funktioniert die Tastatur nun auch nach stundenlangem Spielen ohne Probleme.

Tja das Leben ist grausam und ungerecht. Und Windows trägt oft nicht dazu bei, es zu verbessern.

KB3133977 auf einem Dualbootsystem installieren

Heute habe ich seit einiger Zeit mal wieder Windows gebootet. Logischerweise haben sich hier einige Updates angesammelt, die ich lieber gleich mal installiert habe. Bis auf KB3133977 hat das auch geklappt. Nur dieses verschissene Update hat sich mit Händen und Füßen geweigert. Das Update braucht einen Neustart. Und hier gab es jedes Mal den Fehler 80004005. Dieser bedeutet grob gesagt, es ist ein unbekannter Fehler beim Windows-Update passiert. Wer hätte das gedacht…

Nach einigem hin und her habe ich das Problem gefunden. Ich habe auf dem betreffenden Rechner sowohl Arch Linux als auch Windows 7 HP installiert (jeweils auf einer eigenen SSD). Gestartet werden beide mittels syslinux. Und genau das mag das Update nicht. Es ist scheinbar mal wieder eines dieser Updates der Marke “du darfst keine anderen Götter / Betriebssysteme haben neben mir”. Als ich Windows direkt über UEFI gebootet hatte (sowohl zum Einspielen des Updates als auch beim benötigten Neustart) wurde das Update anstandslos installiert. Warum einfach, wenn es auch kompliziert geht?