Posts Tagged ‘Boot’

Montag, 13. April 2020

HP ProBook 6570b erkennt bootbaren USB-Datenträger nicht

Gestern half ich einer Bekannten, ihr HP ProBook 6570b mit einer vom Software-Hersteller nicht mehr unterstützten Windows 7 Professional-Installation auf Windows 10 zu lüpfen.

Diese unsägliche Upgrade-Odyssee bestätigte mir wieder einmal, dass mein Entscheid 2004 richtig war, Windows den Rücken zu kehren und auf Mac OS X (heute: macOS) sowie Debian GNU/Linux zu setzen.

Frickelmässig hat sich im Umgang mit Windows kaum etwas geändert — mit Backup-Image, dateibasiertem rsync-Backup, Installationsdatenträger herunterladen und erstellen sowie drei (!) Installationsversuchen (Stichwort: 0x800f0955 - 0x20003 und „The installation failed in the SAFE_OS phase with and error during INSTALL_UPDATES operation.“) habe ich gut und gerne 12 Stunden verbraten.

Ein kleines Problem ganz zu Beginn: Der USB-Installationsdatenträger, ein 8GB USB-Stick, wurde vom HP BIOS anfänglich nicht als Bootquelle aufgeführt (beim Booten ESC drücken, dann F9). Nach viel Haare ausreissen dann die Erkenntnis auf Grund eines Tipps in einem Forum: Ich hatte den Datenträger an einem der zwei SS (SuperSpeed) USB-Anschlüsse auf der rechten Seite des Geräts angeschlossen. Das BIOS erkennt aber nur USB-Datenträger, die am linken USB/eSATA-Anschluss angeschlossen werden.

Wie bescheuert ist das denn?!

Tags: , , , , , , , , , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen

Samstag, 10. Februar 2018

PC von einem USB-Stick booten meldet „Missing Operating System“ (oder: Lenovo Thinkpad BIOS Updates ohne Windows)

Kürzlich habe ich dank der Funktion dmidecode nicht nur herausgefunden, wie ich aus der Ferne feststellen kann, um welchen Gerätetyp es sich bei einem Laptop-Server konkret handelt …

...
Handle 0x000E, DMI type 1, 27 bytes
System Information
	Manufacturer: LENOVO
	Product Name: 4236MBG
	Version: ThinkPad T420
	Serial Number: XXXXXXX
	UUID: 045E0181-510B-110B-BEFD-D0C20D7188AE
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: ThinkPad T420
...

… sondern auch, dass die BIOSse meiner Thinkpad-Flotte wohl mal aktualisiert werden sollten:

...
BIOS Information
	Vendor: LENOVO
	Version: 6QET69WW (1.39 )
	Release Date: 04/26/2012
...

Erstaunlicherweise unterhält Lenovo seine Support-Seiten vorzüglich und es fanden sich innert weniger Minuten alle Seiten mit BIOS-Updates für meine Thinkpads X200s, X201, T400 und T420.

Da auf den Dingern kein Windows läuft, kann man das Update über diesen Weg vergessen. Glücklicherweise bietet Lenovo auch noch CD-Images (sog. ISOs) an, mit welchem die ca. 40MB Updatedaten auf CDs gebrannt werden können. Der Laptop kann dann von dieser CD gestartet und die Updates installiert werden, d.h. die Anforderung Windows entfällt so.

Erstes Problem: Die Links auf die ISO-Images auf den Seiten mit dem „BIOS Update Utility for Windows“ funktionieren nicht. Hier hilft Google jeweils kurzerhand weiter: „X200s BIOS Update Bootable CD“ findet dann den korrekten Link der Seite.

Nachdem man sich von dort die ISOs heruntergeladen hat und sie bspw. (graphisch) mit Etcher (oder auf dem CLI mit dd) unter macOS auf einen USB-Stick schreiben will, ein weiterer Showstopper: Etcher meldet nach dem Transfer, dass der USB-Stick kein gültiges Dateisystem enthält.

Wie sich mit etwas googeln herausstellt verwendet Lenovo für seine Boot-CDs den El Torito-Standard. Deshalb muss man aus dem .iso mit dem Perl-Script geteltorito.pl das eigentliche Image extrahieren. geteltorito.pl findet sich unter Debian GNU/Linux im Paket genisoimage. Aus der Boot-CD des BIOS-Updates für ein Lenovo Thinkpad X201 extrahiert man das eigentliche ISO-Image folgendermassen:

#!/bin/bash

/Users/mario/Scripts/cd-dvd/geteltorito.pl -o 6quj19us.img 6quj19us.iso

exit 0

Auf der Kommandozeile liest man dann ungefähr Folgendes:

$ extract.sh 
Booting catalog starts at sector: 20 
Manufacturer of CD: NERO BURNING ROM
Image architecture: x86
Boot media type is: harddisk
El Torito image starts at sector 24 and has 65536 sector(s) of 512 Bytes

Image has been written to file "6quj19us.img".

Anschliessend schreibt man das .img folgendermassen auf einen USB-Stick, welcher als /dev/rdisk5 gemountet ist:

#!/bin/bash

dd if=6quj19us.img of=/dev/rdisk5 bs=512k

exit 0

Auf der Kommandozeile liest man dann ungefähr Folgendes:

# write.sh
32+0 records in
32+0 records out
33554432 bytes transferred in 6.970957 secs (4813461 bytes/sec)

Einige der folgenden Links waren für die Auskundschaftung dieser Alternative essentiell, andere (weiter unten) Sackgassen:

Die Grösse des USB-Sticks scheint eine Rolle zu spielen

Während einer Stunde habe ich mir dann die Zähne ausgebissen — sowohl mit Etcher als auch mit dd habe ich diverse Images auf einen uralten SanDisk Cruzer USB-Stick mit 512MB geschrieben. Doch jedes Mal, als ich mein Testgerät, ein Lenovo Thinkpad T400, damit booten wollte, erschien die Fehlermeldung „Missing Operating System“.

Erst als ich den USB-Stick auswechselt und einen LaCie itsaKey mit 4GB verwendete, klappte das booten und updaten der Thinkpads reibungslos.

Derzeit bin ich der Meinung, dass dies irgendwie damit zu tun hat, dass der erste USB-Stick mit 512MB kleiner als eine CD mit 640MB ist und dadurch Probleme mit dem Boot-Programm im MBR entstehen. Oder aber dass vom SanDisk-Stick schlicht und einfach nicht gebootet werden kann, weil die Hardware des USB-Sticks das aus mir unerfindlichen Gründen nicht unterstützt.

Zum Schluss noch ein Screenshot, wie die Partition im Disk Utility.app angezeigt wird — mich erstaunt, dass „Bootable“ als „No“ angegeben wird, wobei ich nicht weiss, ob damit gemeint ist, dass Macs gebootet werden können:

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 28. Juli 2010

Debian GNU Linux auf „dependency-based boot system“ umstellen

Seit einigen Wochen offeriert mir Debian bei jedem apt-get dist-upgrade, mein System auf ein abhängigkeitsbasiertes Bootsystem („dependency-based boot system“) umzustellen.

Störrische Pakete

Leider ist dies bisher jedesmal gescheitert, weil folgende init.d-Skripte die Umstellung verhindert haben:

'libdevmapper1.02' missing LSB tags and overrides, 
'iptables' missing LSB tags and overrides, 
'xfree86-common' missing LSB tags and overrides, 
's3sqld.init' missing LSB tags and overrides, 
'libdevmapper1.00' missing LSB tags and overrides, 
'dhcp' missing LSB tags and overrides, 
'raid2' missing LSB tags and overrides, 
'rendezvous' missing LSB tags and overrides,

Gestern habe ich mir nun endlich die Mühe genommen, mein System zu durchforsten, aufzuräumen und auf die neue Boot-Methode umzustellen. Wie es sich herausstellte, war es doch nicht so kompliziert, wie ich es befürchtet hatte.

Generisches Vorgehen

Zuallererst ist zu überprüfen, ob das bemängelte Script tatsächlich noch vom System benötigt wird oder ob es bei einem apt-get remove <package> versehentlich zurückgelassen wurde.

Als erstes sucht man deshalb auf packages.debian.org mit der Suchfunktion unter „Search the contents of packages“ nach der entsprechenden Datei. Kann diese in keinem aktuellen Paket gefunden werden, ist es wahrscheinlich, dass es sich um ein Überbleibsel handelt. Zur Sicherheit kann man mittels dpkg --list | grep <vermutetes package> überprüfen, ob das Paket tatsächlich vor langer Zeit entfernt wurde (rc steht in diesem Fall zu Beginn der Zeile).

Wird die Datei hingegen irgendwo gefunden, muss man mittels Google herausfinden, ob und wie das init-Skript von Hand angepasst werden kann, um die geforderten „LSB tags“ und „overrides“ eingepflegt zu erhalten.

Konkretes Vorgehen

Konkret sah das Prozedere bei mir folgendermassen aus (Achtung: Sicherheitskopien sind ratsam, um notfalls nicht das gesamte System zu zerschiessen):

  • libdevmapper1.02 wird benötigt. Das Skript muss mit der Anleitung von Bug#361358: marked as done (libdevmapper1.02: Please add LSB formatted dependency info in init.d script) angepasst werden
  • libdevmapper1.00 Überrest, kann gelöscht werden (apt-get remove libdevmapper1.00), da eine neuere Version dieses Pakets auf dem System installiert ist (s. oben)
  • iptables Überrest, kann gelöscht werden (rm /etc/init.d/iptables) — auch wenn es der Package-Maintainer aus Rückwärtskompatibilität dort belassen möchte: „The script was dropped from the package ages ago. Unfortunately, removing it would have been problematic, so it’s just a vestige.“
  • xfree86-common Überrest, kann (in meinem Fall!) gelöscht werden, da dpkg --list | grep xfree meldet: rc xfree86-common 6.9.0.dfsg.1-6
  • s3sqld.init Überrest einer Testinstallation des unbrauchbaren Seco Backups. Kann gelöscht werden.
  • dhcp Es handelt sich hierbei um ein hoffnungslos veraltetes Paket, das aus Sicherheitsgründen umgehend ersetzt werden sollte: apt-get install dhcp3-server Die DHCP-Konfiguration in /etc/dhcp3/dhcpd.conf muss dabei glücklicherweise nicht angepasst werden.
  • raid2 Überrest (?), verweist auf nicht mehr vorhandene raidstart etc. und kann deshalb gelöscht werden.
  • rendezvous Überrest, das Paket wird auf dem Debian-Server nicht mehr gefunden. Das Paket kann entfernt werden: apt-get remove rendezvous. Je nachdem muss man vorher noch einen in der Zwischenzeit gelöschten Benutzer daapd erstellen, der dann von der Deinstallationsroutine gleich wieder entfernt wird.
  • initrd-tools.sh Bei der Suche nach dieser Datei im Debian Package-Archiv wurde kein Paket zurückgeliefert, welches dieses Script auf dem System installieren würde. Ich habe diese Datei deshalb kurzerhand gelöscht.

Endlich den Schalter umlegen …

Schlussendlich kann man die Boot-Methode nun umstellen:

# dpkg-reconfigure sysv-rc
info: Checking if it is safe to convert to dependency based boot.
info: Reordering boot system, log to /var/lib/insserv/run-20100727T1330.log
success: Enabled dependency based boot system.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen