Dienstag, 16. Januar 2024
Ganz wichtig, und eigentlich ganz einfach, aber ich mache es immer falsch:
SOURCE Source is the directory that is backed up. At least one source is required. A trailing slash on a source path means „copy the contents of this directory“. Without a trailing slash it means „copy the directory“.
DESTINATION Destination is the directory that source is copied to. Trailing slash on the destination directory doesn’t matter.
Quelle: rsync_tutorial.md
Mittwoch, 22. November 2017
Die Migration von meinem Mac mini auf einen iMac 27″ Retina schreitet stetig voran. Die Daten habe ich dazu mit rsync über Gigabit-Ethernet vom Mac mini auf den iMac rüberkopiert.
Der Befehl sah ungefähr so aus:
$ rsync --protect-args -avz -e ssh . mario@domain.tld:/tmp
Bei einem besonderen Verzeichnis trat (ungefähr) folgende Fehlermeldung auf (ich habe sie leider nicht festgehalten):
rsync: on remote machine: --extended-attributes: unknown option rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-45/rsync/main.c(1333) [server=2.6.9] rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]
Nach etwas Googlen realisiert ich, dass auf dem Zielsystem (dem iMac) zwar MacPorts mitsamt dem neuesten rsync längst installiert waren (/opt/local/bin/rsync mit rsync version 3.1.2 protocol version 31), über den ssh-Tunnel stattdessen aber das alte, von Apple mitgelieferte Binary verwendet wurde (/usr/bin/rsync mit rsync version 2.6.9 protocol version 29).
Der Grund: Wenn rsync einen SSH-Tunnel aufbaut, werden die üblichen Initialisierungsfiles von bash nicht geladen und somit auch die MacPorts-Pfade (/opt/local/...) nach Binaries abgesucht.
Abhilfe schafft man, indem man dem lokalen rsync mit dem Argument --rsync-path sagt, wo sich die gewünschte Binary befindet:
$ rsync --rsync-path=/opt/local/bin/rsync -av -e ssh . mario@domain.tld:/tmp
Quelle: How can I set environment variables for a remote rsync process?
Tags: Apple, High Sierra, macOS, macOS High Sierra, MacPorts, rsync
Labels: Apple, Linux
Sonntag, 25. Mai 2014
Ergänzungen meiner IT-Installation machten es kürzlich nötig, dass ich neu auch unter Mac OS X curlftpfs einsetze, um per FTP von bestimmten Web-Sites Sicherheitskopien anzufertigen (Stichwort: Vagrant und puPHPet, dank an Christian für die „Erleuchtung“!)
Entweder hat sich curlftpfs in der Zwischenzeit weiterentwickelt, oder unter Mac OS X läuft der „Karren“ etwas anders. Auf jeden Fall habe ich bei der Adaptierung meiner Linux-Scripte unter Mac OS X folgendes gelernt:
curlftpfs installiert man sich folgendermassen:
# port install curlftpfs
Wenn man curlftpfs dann zum ersten Mal ausführt, warnt einem Mac OS X (hier: 10.9 Mavericks), dass man eine Kernelextension aktiviert, welche von einem unbekannte Entwickler kompiliert wurde. Henusode … (NSA lässt grüssen). Die Warnung ist seither nie mehr aufgetaucht; ich hoffe, dass dies auch nach einem Reboot so bleibt.
In Tests hat sich herausgestellt, das das Mounten von FTP-Volumen längert dauert als unter Linux. Meinem Script habe ich deshalb folgendermassen Geduld beigebracht:
... MAXIMUMITERATIONS=5000 ... TIME=$(date +%H:%M:%S) echo -n "Checking whether mountpoint is populated ($TIME): " COUNTER=0 while [ ! -d "$SOURCE" ] do let COUNTER=COUNTER+1 echo -n "." if [ "$COUNTER" -eq "$MAXIMUMITERATIONS" ] then echo "Mountpoint still not available after $COUNTER iterations. Aborting." exit 1 fi done ...
In der Variable $SOURCE ist der Pfad zu einem auf dem FTP-Server vorhandenen Unterordner gespeichert. Sobald bash meldet, dass dieser nun verfügbar ist, kann ich mit den Kopieraktionen beginnen.
Bei den Tests traf ich auch auf ein Berechtigungsproblem: Manchmal wurde rsync beim Traversieren von FTP-Ordnerstrukturen der Zugriff verweigert. Nach einigem Pröbeln realisierte ich, dass einige Ordner auf den FTP-Servern das Execution-Bit nur für den Owner gesetzt hatten, nicht aber für die Gruppe oder gar Dritte. In einem Fall passte ich die Berechtigungen über den FTP-Client meiner Wahl an, in einem anderen Fall war ich mir todsicher, dass ich allen Serverbenutzern definitiv keine Berechtigung zum Lesen aller meiner Dateien geben wollte. Was nun?
Folgende Option verhindert, dass curlftpfs respektive FUSE bei FTP-Verbindungen Berechtigungschecks durchführen (dies ist hier Aufgabe des FTP-Servers — gibt dieser Zugriff auf eine Datei, hat definitiv schon eine zuverlässige Authentifizierung und Authorisierung stattgefunden):
$ curlftpfs -o defer_permissions ...
In meinem älteren Blog-Artikel zu curlftpfs habe ich gezeigt, wie der Zeichensatzproblematik unter Linux begegnen kann. Unter Mac OS X klappt dies so nicht. Stattdessen sind folgende Werte an curlftpfs zu übergeben:
$ curlftpfs -o modules=iconv,from_code=latin1
Quelle: International characters (e.g. Swedish åäö) in remote file system folder names makes Finder hang #71
Den Ausgabezeichensatz finden FUSE respektive curlftpfs offenbar selber heraus.
Dem Parameter from_code ist natürlich der Zeichensatz des FTP-Servers mitzugeben. Es sind alle iconv bekannten Zeichensätze konfigurierbar:
$ iconv -l
In Verbindung mit rsync führt dies aber zum unerwünschten Verhalten, dass Verzeichnisse und Dateien mit Umlauten im Namen bei jeder Synchronisation erneut heruntergeladen werden (ich bin unschuldig, das war ein anderer Benutzer des Servers!).
Tags: curlftpfs, FUSE, How-To, Mac OS X, OS X, rsync
Labels: Apple, Linux
Donnerstag, 6. März 2014
rsync ist das Tool meiner Wahl, um meine Backups auf mein Synology NAS im LAN sowie per WAN auf einen Linux-Server im Elternhaus zu spiegeln. Doch aufgepasst: Wer sich seit jeher daran stört, dass die Backup-Scripts bei hunderttausenden Dateien eine Ewigkeit bei „building file list…“ stehen bleiben, sei folgender Rat gegeben:
Man sollte unbedingt eine aktuelle Version von rsync – mindestens aber Version 3 – verwenden. Bis und mit Mac OS X 10.8 liefert Apple Version 2.6 mit, welche in dieser Hinsicht noch nicht optimiert wurde: Version 2 liest zuerst alle Dateien des Quellverzeichnis ein, während Version 3 nach den ersten 1000 Dateien (oder so) mit dem Backup beginnt und die verbleibenden Dateien anschliessend päckchenweise (nach Bedarf, basierend auf der Backup-Geschwindigkeit), einliest. Diese Massnahme verringert nebenbei auch gerade den RAM-Bedarf des Tools.
Version 3 ist auf meinem System über MacPorts installiert:
# port install rsync
Damit man auch wirklich sicher ist, dass in den eigenen Backup-Scripts Version 3 und nicht Version 2 verwendet wird, sollte man den rsync-Pfad in Scripts hardkodieren:
#RSYNC=$(which rsync) RSYNC="/opt/local/bin/rsync/"
Um während der Ausführung eines Scripts zu prüfen, ob Version 3 des Tools verwendet wird, empfiehlt es sich, rsync das Argument --info=progress2 mitzugeben. In diesem Fall wird jede Datei, die kopiert wird, auf einer neuen Zeile ausgegeben. Neben dessen Grösse, dem Netzwerk-Durchsatz und der Transfergeschwindigkeit auf das Zielmedium steht ganz am Ende der Zeile einerseits xfr für die fortlaufende Nummer aller übertragender Dateien und Ordner sowie to-chk, die Zahl der bereits überprüften Dateien vom (provisorischen) Total aller Dateien. to-chk wird sich während der Laufzeit des Scripts sequentiell erhöhen.
$ rsync -av --info=progress2 . /mnt/backup/2014-03-06/ ... 1,238,099 100% 146.38kB/s 0:00:08 (xfr#5, to-chk=169/396) ...
Tags: 2.x, 3.x, building file list, Geschwindigkeit, Mac OS X, MacPorts, rsync
Labels: Linux
Sonntag, 26. Januar 2014
Komplexe Shell-Scripte, welche ein Unix-Tool mit unzähligen Optionen aufrufen, muss man ab und zu debuggen. Damit dies möglichst einfach funktioniert, habe ich mir angewöhnt, die Optionen so zu notieren, damit ich jede einzelne Option mit einem Tastendruck auskommentieren kann:
... OPTS="" OPTS="$OPTS --verbose" OPTS="$OPTS --archive" OPTS="$OPTS --no-owner" OPTS="$OPTS --no-group" #OPTS="$OPTS --delete" # WILL DESTROY EVERYTHING! DO NOT UNCOMMENT OPTS="$OPTS --progress" ... rsync $OPTS "$SOURCE" "$DESTINATION" ...
Sonntag, 3. November 2013
Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.
Please be aware to use the special rsync-Version written for Mac OS X (fucking resource forks, again!). Otherwise you could end up with a mess (only on the backup side, but this sucks as much!).
I separated iPhoto-Files from the rest, because the .sparseimage wouldn’t fit on a DVD anylonger.
backup.sh
#!/bin/sh
if [ $# -lt 1 ]
then
echo "Please provide a destination to store the backup to:"
echo "fwdsk (Firewire-Drive)"
echo "eth (Server-Share)"
echo "tmp (/tmp)"
exit 1
fi
case $1 in
"fwdsk")
IMAGEFOLDER="/Volumes/TRANSFER";;
"eth")
IMAGEFOLDER="/Volumes/RSYNC";;
"tmp")
IMAGEFOLDER="/tmp";;
*)
echo "Please provide a destination to store the backup to:"
echo "fwdsk (Firewire-Drive)"
echo "eth (Server-Share)"
echo "tmp (/tmp)"
exit 1;;
esac
if [ ! -d "$IMAGEFOLDER" ]
then
echo "Directory '$IMAGEFOLDER' not found"
exit 1
fi
BACKUPINFO=( "home" "iphoto" )
for VOLNAME in ${BACKUPINFO[@]}
do
DISKIMAGENAME="$VOLNAME"
DISKIMAGEPATH="$IMAGEFOLDER/$VOLNAME.sparseimage"
BACKUPSOURCEFILE="/Users/mario/Rsync/bkpsrc/$VOLNAME.txt"
if [ ! -f "$BACKUPSOURCEFILE" ]
then
echo "File '$BACKUPSOURCEFILE' not found"
exit 1
fi
BACKUPSOURCE=`more $BACKUPSOURCEFILE`
BACKUPDESTINATION="/Volumes/$VOLNAME"
RSYNCEXCLUDE="/Users/mario/Rsync/exclude/$VOLNAME.txt"
#-------------------------------------------------
# Create/reuse & mount Disk-Image
#-------------------------------------------------
if [ ! -f "$DISKIMAGEPATH" ]
then
# Disk-image-file doesn't even exist - create it
echo "Creating disk image \"$DISKIMAGEPATH\""
hdiutil create -fs HFS+ -type SPARSE -size 20g -volname "$DISKIMAGENAME" "$DISKIMAGEPATH"
else
echo "Using pre-existing disk image \"$DISKIMAGEPATH\""
fi
if [ ! -d "$BACKUPDESTINATION" ]
then
# Disk-image doesn't seem to be mounted
hdiutil attach "$DISKIMAGEPATH"
fi
#-------------------------------------------------
# Did Disk-Image mount correctly?
#-------------------------------------------------
if [ ! -e "$BACKUPDESTINATION" ]
then
echo "There was a problem creating or mounting the disk image"
exit 1
fi
#-------------------------------------------------
# Rsync
#-------------------------------------------------
/Users/mario/Rsync/rsync.sh "$BACKUPSOURCE" "$BACKUPDESTINATION" "$RSYNCEXCLUDE"
#-------------------------------------------------
# Unmount Disk-Image and do maintenance operations
#-------------------------------------------------
# hdiutil info | grep /Volumes/$VOLNAME | cut -f 1
#
# Expected output: /dev/disk2s2 Apple_HFS /Volumes/Rsync-Backup
# ^ this info is required to unmount
DISKIMAGEDEVICE=`hdiutil info | grep /Volumes/$VOLNAME | cut -f 1`
echo "Disk image mounted as $DISKIMAGEDEVICE"
hdiutil detach -quiet "$DISKIMAGEDEVICE"
echo "Disk image ejected"
hdiutil compact "$DISKIMAGEPATH"
echo "Disk image compacted"
done
rsync.sh
#!/bin/sh if [ $# -ne 3 ] then echo "Usage:" echo "rsync.sh" exit 1 fi BACKUPSOURCE="$1" BACKUPDESTINATION="$2" RSYNCEXCLUDE="$3" if [ ! -d "$BACKUPSOURCE" ] then echo "Source directory '$BACKUPSOURCE' not found" exit 1 fi if [ ! -d "$BACKUPDESTINATION" ] then echo "Destination directory '$BACKUPDESTINATION' not found" exit 1 fi if [ ! -f "$RSYNCEXCLUDE" ] then echo "Exclude file '$RSYNCEXCLUDE' not found" exit 1 fi # --verbose # --showtogo # --dry-run time sudo /usr/local/bin/rsync -a --delete --delete-excluded --eahfs --showtogo --exclude-from\ "$RSYNCEXCLUDE" "$BACKUPSOURCE" "$BACKUPDESTINATION"
bkpsrc/home.txt
/Users/mario/.
bkpsrc/iPhoto.txt
/Users/mario/Pictures/iPhoto Library/.
exclude/home.txt
Music/ Movies/ PoisonDownloads/ Cache/ Caches/ .Trash/ Fun-Stuff/ .DS_store iPhoto Library/
exclude/iphoto.txt
.Trash/ .DS_store
Mittwoch, 18. September 2013
Als Gedankenstütze nachfolgend einige Lösungen für Probleme, die sich mir in den Weg stellten:
$ ssh-keygen -t rsa -b 2048 -f id_rsa_dashboard_vault
Die Aufforderung, ein Passwort für den Private Key zu generieren, bestätigt man mit ENTER — der Private Key wird so nicht zusätzlich mit einem Passwort geschützt, weil dies den automatisierten Login von Raspberry Pi auf die DiskStation verhindern würde.
Der Befehl erstellt zwei Dateien:
Als erstes richtet man sich über die Web-Oberfläche einen normalen Benutzer dashboard ein, in dessen Home-Verzeichnis die Backup-Daten geschrieben werden.
Hierzu müssen dem Benutzer Schreibrechte auf /homes gegeben werden. Ansonsten sieht man sich beim Starten des Backup-Scripts (s. unten) mit folgender Fehlermeldung gegenüber:
ERROR: module is read only
Quelle: Rsync over ssh: “ERROR: module is read only” suddenly appeared
Wichtig ist weiter, dass der SSH-Zugang über die Web-Oberfläche aktiviert wurde.
Dem neu erstellten Benutzer müssen wir nun eine gültige Login-Shell zuweisen:
... dashboard:x:1029:100::/var/services/homes/dashboard:/bin/ash
Erfasst man hier ein nicht existierendes Login-Shell, kriegt man beim Debugging des publickey SSH-Logins folgende komische Infos ans Gesicht geworfen:
... Authentication succeeded ... Permission denied ...
Um sicher zu gehen, dass die Login-Shell richtig konfiguriert ist, macht man als auf der DiskStation eingeloggter User root folgendes:
# su dashboard
Wechselt man in ein neues Shell, ist /etc/passwd korrekt konfiguriert.
In dieser Datei legen wir den Public Key ab (id_rsa_dashboard_vault.pub).
Wahrscheinlich müsste man hier gar nichts anpassen, beim Debugging habe ich es dann doch getan (wohl unnötigerweise):
$ cat sshd_config | grep -v "^#" | sort
AllowTcpForwarding no
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
ChrootDirectory none
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_rsa_key
LogLevel INFO
Match User root
AllowTcpForwarding yes
Protocol 2
PubkeyAuthentication yes
Subsystem sftp internal-sftp -f DAEMON -u 000
SyslogFacility AUTH
UseDNS no
UsePAM yes
Host vault Hostname 10.0.44.44 User dashboard IdentityFile ~/.ssh/id_rsa_dashboard_vault
In der Datei ~/.ssh/id_rsa_dashboard_vault legt man den Private Key ab.
Dies sollte nun ohne Eingabe eines Passwortes möglich sein:
$ ssh vault
Bei einer Fehlermeldung helfen die Optionen -v, -vv und -vvv weiter:
$ ssh -v vault
Folgendes Script sichert / (root) des Raspberry Pis auf den Host vault in den Pfad /volume1/homes/dashboard/backups/. Auf dem Raspberry Pi nicht mehr vorhandene Dateien werden auf der DiskStation gelöscht.
#!/bin/sh RSYNC=`which rsync` if [ ! -e "$RSYNC" ] then echo "rsync binary not found: '$RSYNC'" exit 1 fi TODAY=`date +"%F_%T"` SNAPSHOTFILE="/var/log/rsync/$TODAY.snapshot.txt" #touch "$SNAPSHOTFILE" echo "$TODAY" > "$SNAPSHOTFILE" if [ ! -f "$SNAPSHOTFILE" ] then echo "Could not create snapshotfile '$SNAPSHOTFILE'" else echo "Snapshotfile created at:" ls -l "$SNAPSHOTFILE" fi LOGFILE="/var/log/rsync/$TODAY.log.txt" EXCLUDEFILE="/usr/local/bin/backup-exclude.txt" SOURCE="/" DEST="vault:/volume1/homes/dashboard/backups/" echo "Running rsync ..." $RSYNC -avz --log-file="$LOGFILE" --exclude-from="$EXCLUDEFILE" --delete -e ssh "$SOURCE" "$DEST" echo "Backup complete." exit 0
proc/* sys/* dev/* tmp/* run/* mnt/*
Quelle: Can a Raspberry Pi be used to create a backup of itself?
... 4 0 * * * root /usr/local/bin/backup.sh
Hiermit wird das Backup-Script täglich um 4 Uhr morgens ausgeführt.
Tags: Linux, Raspberry Pi, rsync, SSH, Synology
Labels: Linux
Sonntag, 7. Juli 2013
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.
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.
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
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.
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
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).
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.
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.
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.
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.
Tags: ext4, fdisk, grub, grub2, rsync, SSD, Swap
Labels: Linux
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT (Linux, OSS, Apple), Heim-Automation; mein mittlerweile abgeschlossenes Geschichtsstudium; Erkenntnisse aus meiner aktuellen Tätigkeit in der Informationssicherheit, meine Erfahrungen als IT-Berater, IT-Auditor, Web-Developer und IT-Supporter; die Schweiz, den Kanton Bern, meine ursprüngliche und auch wieder aktuelle Wohngemeinde Neuenegg, meine vorherige Wohngemeinde Bern, über lokale, regionale und globale Politik; meine Reisetätigkeit und Erfahrungen mit anderen Kulturen; und zu Guter letzt auch das Älter werden.
Alle in diesem Blog gemachten Aussagen und Meinungen sind persönlich und nicht als Ansichten meines aktuellen und/oder meiner bisherigen Arbeitgeber zu verstehen.
 |