[GELÖST] rsync restore: bootet ins falsche system

[ulliroyal]

Hallo Forum

Ich bin dabei, rsync für den Notfall zu testen, und stoße auf folgendes Problem:
Ein älteres rsync-Backup habe ich auf /dev/sdb6 gespielt, und der fstab dort gesagt, sdb6 als / zu benutzen.
Nach

Code: Alles auswählen

mount /dev/sdb6 /mnt/
cd /mnt/
mount -t proc proc proc/
mount --rbind /sys sys/
mount --rbind /dev dev/
chroot /mnt/ /bin/bash
grub-mkconfig -o /boot/grub/grub.cfg
update-initramfs -uk $(uname -r)
update-grub

zeigt er das sdb6-System im Boot-Menu an, doch das System, das er dann von dort lädt, ist das (neuere) Original von sdb2.

Irgendwo muss es jetzt noch eine Einstellung geben, die ich übersehen habe.

Vielen Dank für einen Rat !!

ulli

[hikaru]

Ich würde vermuten, dass in der kopierten grub.cfg auf sda6 immer noch die UUID von sda2 als root-Partition steht.

[ulliroyal]

Danke hikaru,

OMG, die schlimme DO NOT EDIT THIS FILE grub.cfg

Da ist wahr, in der grub.cfg von sdb6 steht nichts von sdb6.
Jetzt denke ich, ich könnte einfach die aktualisierte /boot/grub.cfg von sdb2 mit dem Eintrag:

Code: Alles auswählen

menuentry 'Debian GNU/Linux (8.0) (on /dev/sdb6)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-0708b57c-b8d2-4f26-b396-8eb5d9a9fe22' {
	insmod part_gpt
	insmod ext2
	set root='hd1,gpt6'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt6 --hint-efi=hd1,gpt6 --hint-baremetal=ahci1,gpt6 --hint='hd1,gpt6'  0708b57c-b8d2-4f26-b396-8eb5d9a9fe22
	else
	  search --no-floppy --fs-uuid --set=root 0708b57c-b8d2-4f26-b396-8eb5d9a9fe22
	fi
	linux /boot/vmlinuz-3.16.0-4-amd64 root=UUID=322c6fb6-b68b-478d-a12b-fe1fec9d4c49 ro quiet splash
	initrd /boot/initrd.img-3.16.0-4-amd64
}

nach sdb6 /boot/grub.cfg kopieren, aber ich bin nicht sicher, ob das eine gute Idee ist...
Nicht dass dann gar nichts mehr geht…

…edit: ich hab doch es gemacht, aber auch auch mit der neuen grub.cfg auf sdb6 bootet er sdb2 von sdb6.
Der Hund muss noch irgendwo anders begraben liegen

[hikaru]

Die grub.cfg zu kopieren ist keine gute Idee. Es ist allerdings auch keine schlechte Idee. Es ist eine nutzlose Idee.

Dein selbsteditiertes (on /dev/sda6) im Label ist nur der Text der im Grub-Menü erscheint, für den Bootvorgang selbst aber unerheblich. Was du anpassen musst ist die UUID (hier: 0708b57c-b8d2-4f26-b396-8eb5d9a9fe22) der root-Partition.
Die muss zu /dev/sda6 passen. Wie die passende UUID lautet sagt dir z.B.: blkid

Edit:
Ich hatte völlig übersehen, dass da zwei verschiedene UUIDs in deinem Code-Schnipsel stehen. Falls die UUID in der vorletzten Zeile schon die von sda6 ist, dann sollte das so funktionieren.

Edit2:
In der search-Zeile muss allerdings auch die richtige UUID stehen. So wie es jetzt ist käme zwar deine root-Partition von sda6, der Kernel allerdings von sda2.

[ulliroyal]

Die uuid 0708b57c-b8d2-4f26-b396-8eb5d9a9fe22 wäre schon richtig,
falsch ist nur noch die nach dem „fi“: UUID=322c6fb6-b68b-478d-a12b-fe1fec9d4c49

Ich dachte nur, der richtige Weg wäre, ihm das über fstab und update-grub mitzuteilen.
Naja, ich probiere, die uuid hinter dem fi auch noch zu ändern, gottseidank ist es ja noch kein Notfall

Stay tuned

[ulliroyal]

Die uuid 0708b57c-b8d2-4f26-b396-8eb5d9a9fe22 wäre schon richtig,
falsch ist nur noch die nach dem „fi“: UUID=322c6fb6-b68b-478d-a12b-fe1fec9d4c49

Ich dachte nur, der richtige Weg wäre, ihm das über fstab und update-grub mitzuteilen.
Naja, ich probiere, die uuid hinter dem fi auch noch zu ändern, gottseidank ist es ja noch kein Notfall

Stay tuned

Yippieh, das wars !!
Ärgerlich nur, dass ich jetzt so viele Schritte probiert habe und nun nicht mehr weiß, welche wirklich erforderlich waren.

[ulliroyal]

Jetzt habe ich dann das gute alte Permissions-Problem auf der Sicherung sdb6:

Code: Alles auswählen

ulliroyal 17:47 $~>sudo -s
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set.

Mal schauen, wo das wieder steckt

[uname]

Ich weiß gar nicht was du mit "sudo" bei Debian willst. Aber bei einer normalen Kopieraktion hätte selbst das keine Probleme machen dürfen. Das GRUB-Problem könntest du im übrigen lösen, wenn du z.B. per USB-Stick bootest. UUIDs sind im übrigen auch eine Sicherheitsfunktion. Mit den Buchstaben kann man schon mal Pech haben (z.B. wenn /dev/sda nicht erkannt wird und dann z.B. /dev/sdb automatisch gebootet wird, welches dann als /dev/sda nicht /dev/sdb findet).

[hikaru]

Ärgerlich nur, dass ich jetzt so viele Schritte probiert habe und nun nicht mehr weiß, welche wirklich erforderlich waren.

Tja, dann das ganze Spiel nochmal!

Jetzt habe ich dann das gute alte Permissions-Problem auf der Sicherung sdb6:

Code: Alles auswählen

ulliroyal 17:47 $~>sudo -s
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set.

Zeig doch bitte mal:

Code: Alles auswählen

ls -l /usr/bin/sudo

Interessant wäre auch dein rsync-Kommando zu kennen mit dem du das Backup erstellt hast und was da das Zieldateisystem war.

[ulliroyal]

Interessant wäre auch dein rsync-Kommando zu kennen mit dem du das Backup erstellt hast und was da das Zieldateisystem war.

Code: Alles auswählen

sudo rsync -aAXv --exclude …

Weitere Recherchen ergaben, dass das Problem mit den Permissions wohl dadurch entsteht, wenn man auf eine NTFS-formatierte Platte rsynct, da werden die Permissions wohl immer nivelliert.
Halbwegs geholfen hat dann in meinem Fall nur vom Remoterechner das hier:
Mit viel Gebastel und

Code: Alles auswählen

chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key   # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail

aber man stößt immer wieder auf Detail-Probleme, der Rat ist, neu aufsetzen.
Ich bin jetzt dabei, meine verranzte Windows-Platte frei zu räumen.

Klasse wär jetzt noch ein Rat, wie ich sie formatieren muss, damit sie am vielseitigsten ist.

[hikaru]

Wie? "Windows-Platte"? Ich bin enttäuscht von dir!

Klasse wär jetzt noch ein Rat, wie ich sie formatieren muss, damit sie am vielseitigsten ist.

Falls du noch mit Windows darauf zugreifen willst, dann ist ntfs schon die beste Wahl. Das erhält allerdings nicht die Unix-Dateirechte wie du schon selbst erkannt hast (und was der Grund war warum ich nach dem Dateisystem fragte).
Deine Linux-Backups (die du vermutlich von einer Linux-Live-CD aus ausführst) musst du dann in ein tar-Archiv stecken oder auf einem mit einem passenden Dateisystem (z.B. ext) formatierten Image ablegen. Beides erhält die Unix-Dateirechte, auch wenn das Archiv/Image selbst auf ntfs abgelegt wird.

Falls du nicht mehr von Windows darauf zugreifen willst wäre ext4 eine recht schlaue Wahl für die Neuformatierung deiner Backup-HDD.

[ulliroyal]

Wie? "Windows-Platte"? Ich bin enttäuscht von dir!

Ja ja,
aber Schwindows zeigt schon lange den blue screen of death
und wurde bis jetzt nur mitgeschleppt, wegen der alten Daten und so. Damit ist jetzt auch Schluss, nur Ärger !!

Tar dauerte ja wohl länger als rsync, bin ich auch schon mal mit gescheitert,
nee, ich nehm jetzt ext4 und glücklich sein, hat ja alles schon super geklappt letztendlich, bis auf ntfs, das new-technology-file-system, blanker Hohn.

Danke !!

[Dogge]

Warum sollte ein Windows-FS Unix-Rechte unterstützen? Ich würde jetzt auch nicht davon ausgehen, dass meine Rechte noch passen wenn ich ein Windows-Backup auf ext4 schreibe.
Ok, du steigst auf ext4 um, ansonsten hättest du mal folgendes probieren können:

--fake-super
When this option is enabled, rsync simulates super-user activi-
ties by saving/restoring the privileged attributes via special
extended attributes that are attached to each file (as needed).
This includes the file's owner and group (if it is not the
default), the file's device info (device & special files are
created as empty text files), and any permission bits that we
won't allow to be set on the real file (e.g. the real file gets
u-s,g-s,o-t for safety) or that would limit the owner's access
(since the real super-user can always access/change a file, the
files we create can always be accessed/changed by the creating
user). This option also handles ACLs (if --acls was specified)
and non-user extended attributes (if --xattrs was specified).

This is a good way to backup data without using a super-user,
and to store ACLs from incompatible systems.

The --fake-super option only affects the side where the option
is used. To affect the remote side of a remote-shell connec-
tion, specify an rsync path:

rsync -av --rsync-path="rsync --fake-super" /src/ host:/dest/

Since there is only one "side" in a local copy, this option
affects both the sending and receiving of files. You'll need to
specify a copy using "localhost" if you need to avoid this, pos-
sibly using the "lsh" shell script (from the support directory)
as a substitute for an actual remote shell (see --rsh).

This option is overridden by both --super and --no-super.

See also the "fake super" setting in the daemon's rsyncd.conf
file.

http://manpages.debian.org/cgi-bin/man. ... &locale=en

[schwedenmann]

Hallo

ich nehm jetzt ext4 und glücklich sein, hat ja alles schon super geklappt letztendlich, bis auf ntfs,

Kannst du nat. machen, erwarte dann aber nciht, das ext4 alle Windows-FS-Attribute aufnehmen kann

Dann wäre für winsicherunge dd besser.

mfg
schwedenmann

[ulliroyal]

--fake-super

wow, so geht es auch, es bleiben ein paar Unwägbarkeiten, die auch noch getestet sein wollen.
(Da ich kein Backupprofi werden will, und heilfroh bin, windows entkommen zu sein, schlage ich persönlich jetzt lieber den Weg mit ext4 ein, aber das ist ein hilfreicher Tipp für die, die drauf angewiesen sind.)

Dann wäre für winsicherungen dd besser.

dd macht meines Wissens nach (korrigier mich) keine incremental backups, dass heißt, im Gegensatz zu rsync dauert jedes Backup ewig, auch wenn sich nur wenig geändert hat.
Wie gesagt, für mich gilt: no windows no cry