Posts Tagged ‘fdisk’

Montag, 23. Oktober 2017

Mit Debian Rescue eine CD mounten und auf einen USB-Stick kopieren

Unsere Wohnung ist (fast) eine DVD/CD-ROM-freie Zone. All unsere Endgeräte verfügen mittlerweile über kein optisches Laufwerk mehr.

Doch was nun, wenn man eine CD erhält, deren Daten man auf die Endgeräte laden möchte?

Man nimmt den herumliegenden Lenovo T400 zur Hilfe, welcher noch über ein CD-ROM-Laufwerk verfügt. Leider fehlt der guten Maschine die Festplatte, weil der auf AliExpress.com gekaufte Festplatten-Käfig sowie die Plasticschienen derzeit gerade aus China unterwegs in die Schweiz sind.

Damit man auf der Kiste also ein Linux zum Laufen kriegt, bootet man von einem USB-Stick, auf welchen die Netinst-Version von Debian 9.0 kopiert wurde. (tftp Netzwerk-Boot wäre noch ein Todo für die langen Winternächte).

Nach ein paar Kapriolen, um das Boot-Laufwerk auf USB umzubiegen, startet der Laptop mit der graphischen Installationsoberfläche. Dort wählt man unter Advanced Options den Rescue Modus ein (ohne graphische Benutzeroberfläche).

Nach viel zu vielen Dialogfenster hat man endlich eine Shell zur Hand. Sobald man die CD eingelegt hat, gibt man folgende Befehl ein:

# mkdir /mnt/cdrom
# mount /dev/cdrom /mnt/cdrom

Unter /mnt/cdrom sieht man mit ls -l den Inhalt der CD.

Hat man den zweiten USB-Stick, auf welchen die Daten der CD kopiert werden sollen, bereits bei der Anzeige des Debian-Menus eingestöpselt, könnte man dem Rescue-System in einem Dialog-Fenster sagen, diesen Stick ebenfalls bereits zu mounten.

Hat man dies nicht gemacht, sucht man sich zuerst einen weiteren freien USB-Port am Gerät und steckt den USB-Stick ein.

Anschliessend sucht man sich mit fdisk -l den Devicenamen sowie den Namen der Partition hervor. Gleichzeitig sieht man auch, ob der Stick mit FAT16/32 formatiert ist — ich konnte in meinem Versuch nur solche Sticks mounten.

In unserem Fall trägt die Partition des USB-Sticks den Pfad /dev/sdb1, deshalb mountet man den Stick so:

# mkdir /mnt/usb2
# mount /dev/sdb1 /mnt/usb2

Anschliessend wechselt man auf das CD-Laufwerk und verwendet — leider, da rsync in dieser Umgebung fehlt — folgenden Befehl, um die Daten auf den USB-Stick zu kopieren:

# cd /mnt/cdrom
# cp -R . /mnt/usb2

Doch OBACHT — nur weil der Kopierbefehl abgeschlossen ist, heisst das leider noch nicht, dass alle Daten bereits auf den USB-Stick geschrieben wurden:

USB write: delay between when Ubuntu says its done and it actually being done

Bevor man den USB-Stick ausstöpselt, muss man mit folgendem Befehl sicherstellen, dass auch wirklich restlos alle Daten auf den Stick geschrieben wurden:

# sync

Danach werkelt sync, was locker noch einmal ein oder zwei Minuten dauern kann.

Anschliessend kann man den Stick mit folgendem Befehl für die Entfernung bereitmachen:

# umount /mnt/usb2

Sobald dieser Befehl ausgeführt wurde, kann man den Stick aus dem USB-Port entfernen und auf einem Endgerät einstöpseln.

Tags: , , , , , , , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. Oktober 2014

Mac bootet nach Upgrade auf Yosemite und TimeMachine-Restore nicht mehr

Kürzlich durfte ich einem Arbeitskollegen helfen, welcher sein neues Retina MacBook-Pro bei der Installation von Mac OS X Yosemite und dem anschliessenden Restore des TimeMachine-Backups zerschossen hatte.

Bootete der Kollege den Mac, erschien alsbald das blinkende Fragezeichen, welches darauf hindeutete, dass im System kein brauchbares Boot-Volume gefunden wurde.

Wir booteten deshalb in den Recovery-Modus und ich sah mir anschliessend die Situation genauer an. Im Disk Utility erschien die Festplatte zwar, uns war es aber nicht möglich, Partitionen auf der Festplatte zu erstellen oder zu löschen. Wählten wird die Systempartition an, blieb der „-„-Knopf (für „Löschen“) ausgegraut.

Ich wechselte deshalb in Terminal.app und startete auf einem anderen PC einige Google-Suchen zur Thematik. Äusserst rasch stiess ich auf folgende Ask Different/Stackexchange-Frage:

Can’t ever remove partition?

Wie in der Frage dargelegt führte ich ebenfalls folgendes Kommando aus:

# diskutil list
    ~ - Tue Aug 14 10:12:00: diskutil list
    /dev/disk0
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *512.1 GB   disk0
       1:                        EFI                         209.7 MB   disk0s1
       2:                  Apple_HFS MacSSD                  425.7 GB   disk0s2
       3:                 Apple_Boot Recovery HD             784.2 MB   disk0s5
       4:          Apple_CoreStorage MacSSD 2                85.3 GB    disk0s4   <--- Want to remove this
       5:                 Apple_Boot Boot OS X               134.2 MB   disk0s6
    /dev/disk1
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                  Apple_HFS MacSSD2                *84.9 GB    disk1

(Symbolauszug) Wie auch bei dem Terminalauszug auf Stackexchange lag das Problem bei uns auch bei einer Partition, die als "Apple_CoreStorage" gekennzeichnet war. Dies bedeutet, dass die Partition mit FileVault verschlüsselt ist.

Der Kollege gab mir sein OK, dass ich die Partition löschen konnte, da er ja ein aktuelles Backup auf seiner TimeCapsule liegen hatte. Wie in der Antwort auf Stackexchange beschrieben listet ich zuerst alle File Vault-Partitionen auf:

# diskutil cs list

Anschliessend kopierte ich die Volume ID des Logical Volumes, eine Zeichenkette aus den Buchstaben und Zahlen A-F0-9. Als nächstes löschte ich die Volumengruppe:

# diskutil cs delete <Volume ID>

Nach dieser Aktion starteten wir Disk Utility wieder - und siehe da, die Festplatte konnte neu partitioniert werden.

Meine Vermutung war daraufhin, dass der Restore mit Time Machine eine fehlerhafte Manipulation an der Festplattenverschlüsselung vorgenommen und die Partition unlesbar gemacht hatte.

Tags: , , , , ,
Labels: Apple

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 5. März 2014

Alle Spuren von GPT-Partitionen von einer portablen Festplatte entfernen

Ich habe eine kürzlich erworbene Festplatte mit dem Disk Utility von Mac OS X komplett neu formatiert und partitioniert. Als ich die Festplatte kürzlich unter Linux neu partitionieren wollte, realisierte ich, dass die Festplatte mit den neuen GPT-Partitionen eingerichtet war (im Gegensatz zu den aus der DOS-Zeit stammenden MBR-Partitionen).

Wie entfernt man jegliche Überreste von GTP-Partitionierungsschemen von der Festplatte? Ganz einfach: Man installiere sich das Debian-Paket gdisk und führe dann folgendes aus:

# apt-get install gdisk
# gdisk /dev/sde
GPT fdisk (gdisk) version 0.7.2

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 1

Command (? for help): x

Expert command (? for help): z
About to wipe out GPT on /dev/sde. Proceed? (Y/N): y
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N): n
MBR is unchanged. You may need to delete an EFI GPT (0xEE) partition
with fdisk or another tool.

Quelle: Wiping Out Old GPT Data

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 7. Juli 2013

Debian-Installation auf eine SSD-Festplatte migrieren

Auf Grund eines längeren Ausfalls meines Servers (Gründe: Netzteil des Cablemodems ist gestorben, Switch auf Grund eines Wackelkontaktes des Netzteils ohne Strom) war ich heute im Elternhaus. Aus gegebenem Anlass habe ich mich entschieden, die Debian-Installation von einer Samsung HD161GJ (160GB) auf eine hier unbenutzt herumliegende 128GB SSD–Festplatte (Crucial M4-CT128M4SSD2) zu migrieren.

Nachfolgend eine Schritt-für-Schritt-Anleitung, wie dieses Vorhaben in möglichst kurzer Zeit bewerkstelligt werden kann.

Grob (für Profis)

  1. Zweite Festplatte an Server anschliessen (SATA oder via USB-Adapter)
  2. SSD-Festplatte partitionieren (bei mir: /boot, Swap und / (root))
  3. SSD-Partitionen formatieren (mkfs.ext4, mkswap)
  4. Partitionen mounten
  5. Mittels rsync alle Nutzdaten von den System-Partitionen auf die SSD-Partionen verschieben
  6. Die UUIDs in /etc/fstab der SSD-Festplatte anpassen
  7. grub-install auf die SSD-Festplatte
  8. Herunterfahren
  9. Ehemalige System-Platte vom System trennen
  10. Neu starten
  11. BIOS anpassen
  12. grub rescue überreden, von der SSD-Festplatte zu starten, obwohl die UUIDs nicht mehr stimmen
  13. update-grub ausführen

Detailliert (für Anfänger/Erfahrene)

Partitionierung

Nachdem die Festplatte erfolgreich an den SATA-Bus angeschlossen worden ist, sollte sie sowohl unter /var/log/messages als auch mittels fdisk -l aufgelistet werden. Den von dort übernommenen Device-Namen (in meinem Fall: /dev/sdd) verwendet man, um das Partitionierungstool fdisk zu starten:

# fdisk /dev/sdd

Ich habe mir zuerst eine primäre Partition für /boot erstellt (p, 1024MB) und die Partition bootbar gemacht (a). Anschliessend habe ich eine erweiterte Partition erstellt, in welcher ich einerseits eine Swap-Partition erstellt habe (Typ 82, 1024MB — so gross wie der verfügbare RAM-Speicher) als auch die root-Partition.

Ganz wichtig ist, alle Änderungen am Schluss mittels w auch effektiv auf die SSD zu schreiben.

Formatierung

Die Formatierung ist schnell erledigt. Mittels mkfs.ext4 formatiert man die /boot-Partition:

# mkfs.ext4 /dev/sdd1

… als auch die / (root)-Partition:

# mkfs.ext4 /dev/sdd6

Mittels mkswap formatiert man die Swap-Partition:

# mkswap /dev/sdd5

Mounten

Solange man die /etc/fstab-Einträge noch nicht umgebogen hat, müssen /boot und / (root) manuell gemountet werden:

# mount /dev/sdd1 /mnt/neu/boot
# mount /dev/sdd6 /mnt/neu/root

Der Filesystem-Typ wird automatisch erkannt.

Filesystem klonen

Die beiden Partitionen klont man folgendermassen:

# cd /
# rsync -av --one-file-system . /mnt/neu/root
# cd /boot
# rsync -av --one-file-system . /mnt/neu/boot

fstab

Die fstab-Datei muss auf der neuen / (root)-Partition angepasst werden. Die Festplatten sollte man heutzutage mit den UUIDs ansprechen. Die UUIDs findet man mit dem Befehl blkid heraus:

...
/dev/sdd1: UUID="3993c6e2-de5c-4227-9cae-637bbfc820b7" TYPE="ext4" 
/dev/sdd5: UUID="79c00de9-06a7-41e5-a470-641b5f68b909" TYPE="swap" 
/dev/sdd6: UUID="9672eb79-b6da-4192-a507-45de2662af2d" TYPE="ext4"
...

Die Partitionen definiert man basierend darauf folgendermassen in /etc/fstab:

...
#/etc/fstab: static file system information.
#
# 												
UUID=3993c6e2-de5c-4227-9cae-637bbfc820b7	/boot		ext4	discard,noatime,errors=remount-ro	0	2
UUID=79c00de9-06a7-41e5-a470-641b5f68b909	none		swap	sw					0	0
UUID=9672eb79-b6da-4192-a507-45de2662af2d       /               ext4    discard,noatime,errors=remount-ro       0       1
...

Gemäss SSD-Fetischisten sind die Optionen discard,noatime unendlich wichtig, um die Lebensdauer der SSD-Festplatte von 19 auf 19.1 Jahre zu erhöhen … Randbemerkung: Die SSD-Optimierer erscheinen mir ähnlich suspekt wie die Idioten, welche bei jedem Mac-Problem erst einmal raten, Repair Permissions durchzuführen (Richtigstellung: Seriously, ‘Repair Permissions’ Is Voodoo).

grub installieren

Mittels folgendem Befehl wird der grub Bootloader in den MBR der neuen Festplatte geschrieben:

# grub-install /dev/sdd

ACHTUNG: Viele Web-Seiten raten in diesem Schritt, den Computer von einer Linux Live-CD zu starten, mittels chroot das Root des Systems auf die SSD-Festplatte umzubiegen sowie sys, proc und dev neu zu mounten. Wer den hier notierten Anweisungen folgt, kann sich diesen umständlichen Schritt sparen.

BIOS

In meinem Fall war im BIOS hardkodiert, dass die 160 GB-Platte von Samsung die zu bootende Festplatte war. Da diese nun fehlte, blieb das System ohne Fehlermeldung hängen. Im BIOS musste ich deshalb die SSD-Festplatte neu als Boot-Festplatte aufnehmen.

grub rescue

Da ich grub-install ausgeführt hatte, als Linux noch von der Samsung-Festplatte als Systemplatte lief, wurden die UUIDs der Partitionen dieser Festplatten in den grub-MBR der SSD-Festplatte geschrieben.

Als das BIOS den Bootloader von der SSD-Platte startete, erschien folgende Fehlermeldung auf dem Schirm:

No such Device: ad4103fa-d940-47ca-8506-301d8071d467

Mittels des Befehls ls wurden mir alle erkannten Festplatten und Partitionen angezeigt. Nachdem ich die System-Festplatte in der grub-Nomenklatur ausgemacht hatte, konnte ich grub mitteilen, wie es zu starten hatte:

set prefix=(hd0,msdos0)/grub
set root=(hd0,msdos5)
insmod normal
normal

Mit diesen Angaben fand grub die Partitionen mit den benötigten Boot-Informationen und Debian startete sauber — und dank SSD blitzschnell.

grub

Da das System nun von SSD-Festplatte lief, konnte ich grub-install erneut ausführen. Dieses Mal übernahm grub die UUIDs der SSD-Partitionen, was ich mir mit update-grub bestätigen liess. Der letzte Befehl schrieb die grub-Konfiguration im Klartext in die Datei /boot/grub/grub.cfg.

Links

Tags: , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen