Siduction Forum
Siduction Forum => Scripting & Kernelhacking => Topic started by: pit on 2015/01/28, 10:18:33
-
Hat schon mal jemand von euch etwas in der Art realisiert?
Ein Rechner mit (1) SSD und (2) HD (magnetisch) hat auf (1) mehrere Partitionen, auf der ersten ist das mehr oder weniger in Ausschließlichkeit genutzte Windows 7 installiert. Auf der letzten Partition von (2) soll ein (wie auch immer geartetes) Abbild dieser Systempartition konserviert werden.
Auch (2) beinhaltet mehrere Partitionen, u.a. die Datenpartition für Windows (D). Ich würde dort gerne auf einer hinteren Partition ein schlankes Siduction installieren und dort eine Verknüpfung zu einem Script auf den Desktop legen, das es a) erlaubt, ein solches Abbild von Windows zu erstellen und b) anbietet, ein solches Abbild zurückzuspielen. Erst mal nicht zwingend: In einer Ausbaustufe stünden die vorhandenen Abbilder zur Auswahl und es erschiene eine unmissverständliche Warnung vor unwiderruflichem Datenverlust.
Da es sich um den Rechner meines betagten Vaters handelt und letzterer über 400 Kilometer entfernt von mir lebt, würde ich in Siduction auch Teamviewer installieren und ein entsprechendes Icon auf dem Desktop platzieren.
Welche Tools empfehlen sich für das Erstellen eines solchen Abbilds? Einfach nur dd ? Windows-Bootloader sollte natürlich mitgesichert werden. Siduction muss nicht zwingend in den MBR, dessen Bootloader könnte ja auch auf der Siduction-Partition liegen, Start dann per Auswahl (Taste F11 oder so beim Rechnerstart).
Im Ergebnis sollte mein Vater in der Lage sein, Siduction zu booten, das unübersehbare Icon auf dem Desktop ("Windows wiederherstellen") anzuklicken und nach einem Reboot sein jungfräuliches Windows wieder zur Verfügung zu haben. Im Zweifel sollte mir das via Teamviewer auch möglich sein. Sein Router ist so konfiguriert, dass er das entsprechende Gerät automatisch mit dem Internet verbindet.
Der letzte Absatz steht aber noch ein bisschen in Frage: Ich habe mich noch nicht entschieden, ob ich es meinem Vater ermöglichen sollte, eine solche Operation eigenständig durchzuführen. Im Zweifel gäb's einen zweiten User (od. einfach nur root) für mich, der die Scripte zum Rückspielen u. zur Erstellung des Abbild exklusiv nutzen dürfte. Der Standard-User (für meinen Vater) hätte dann die Möglichkeit, die Teamviewer Session zu starten - ich würde den Rest via Konsole erledigen.
Input welcome!
-
Hi,
zu Teamviewer kann ich Dir nichts sagen, ich hatte das Problem mit der Fernwartung bei meiner Mutter (die ein siduction benutzt) hiermit gelöst:
http://wiki.siduction.de/index.php?title=VNC-Verbindung_durch_ssh-Tunnel_mit_dynamischer_DNS_herstellen (http://wiki.siduction.de/index.php?title=VNC-Verbindung_durch_ssh-Tunnel_mit_dynamischer_DNS_herstellen)
Was ich Dir auch noch sagen kann, was funktioniert, ist eine komplette Platte mit Win7 mit bootloader per dd auf eine andere Platte zu "verschieben".
also
dd if=/dev/sda of=/dev/sdb
Das geht mit Sicherheit auch in Deinem Fall z.B. mit if=/dev/sda of=/dev/sdb2 und zurück mit if=/dev/sdb2 of=/dev/sda. Jeweils noch ein bs=4096 empfielt sich. Diese beiden Anweisungen jeweils in ein script "save" und "restore" und Du könntest das Problem bereits auf der Kommandozeilenebene per Fernwartung lösen, sobald siduction -auf der zweiten Platte- läuft.
Dein Vater müsste, um dies selbst zu machen, lediglich im Dateimanager auf das entsprechende Icon klicken, lässt sich aber per drag and drop auch auf den Desktop legen.
Da die Datenpartition des Win auf der zweiten Platte liegt sollte auch kein Datenverlust dann Probleme machen.
Dumm ist nur daß Du damit die komplette SSD sichern müsstest, inklusive der "leeren" Teile. Möglicherweise liese sich dies aber durch verkleinern der Win7-Partition auf das nötige Minimum und der Angabe eines count=(benötigte Größe an 4096er Blöcken) bei dd reduzieren.
Also
dd if=/dev/sda of=/dev/sdb(x) bs=4096 count=xxx
Bin aber auch mal auf andere, möglicherweise geschicktere, Lösungen gespannt.
Gruß
ayla
-
So auf die schnelle würde ich mich erstmal ayla anschliessen, mit zwei Änderungen/Abweichungen:
- Zum einen statt of=/dev/sdbX in ein Imagefile sichern, also ähnlich of=/dev/sdbX/Winbak.img
Hätte den Vorteil dass man das auch mal auf 'ne externe Platte sichern kann, und man könnte mal drüber nachdenken den Befehl zwecks Komprimierung (unbelegter Platz) noch durch tar/gzip zu pipen.
- Zum zweiten würde ich mal suchen ob dd auch mit der Syntax /dev/disk-by-uuid oder disk-by-label klarkommt (weiß ich grad nicht). Der Kernel muss nicht immer zwingend der gleichen Platte den gleichen Buchstaben a/b zuweisen, und nichts wär blöder als "automatisiert" die falsche Partition zu überschreiben.
Tipps/Syntax zum separaten Sichern des MBR kennt u.a. Wikipedia: https://en.wikipedia.org/wiki/Dd_%28Unix%29#Master_boot_record_backup_and_restore
-
Hi der_bud,
dd-Images lassen sich per gzip/bzip/lzop komprimieren, das praktiziere ich seit Jahren mit meinen Backups. Da sind durchaus bis 50% Plattenplatz zu sparen. Ich würde dir lzop empfehlen, das ich für meine Kompressaktionen verwende, das besonders schnell ist im Gegensatz zu anderen beiden Tools.
Wenn du die Devices labelst sollte es ohne die Angabe konkrete Namen wie sdaX gehen.
-
bis auf siduction hört sich das gut an - ich würde für sowas eher Lubuntu LTS oder debian/stable LXDE nehmen, wenn ich ehrlich sein soll. Dann fällt auch der Stress mit dem aktuell halten wech, alle Monate mal security einspielen und das wars.
-
Schon mal vielen Dank für eure Tipps!
Bin was dd angeht eher Theoretiker und scheitere aktuell beim Testen in einer VM. Wenn ich Partition 1 der zweiten HD in ein File auf Partition 1 der dritten HD kopieren will, passiert das:
# dd if=/dev/sdb1 of=/dev/sdc1/test.img
dd: konnte „/dev/sdc1/test.img“ nicht öffnen: Ist kein Verzeichnis
Keine dieser Partitionen ist gemountet. Passiert auch, wenn ich statt sdb1 nur sdb schreibe. Und passiert auch, wenn ich /dev/disk/by-label/rettung/test.img adressiere (entsprechend gelabelt ist die Zielpartition natürlich). Sicher irgendein Deppenfehler meinerseits. Was mache ich falsch?
Zielpartition sieht so aus:
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 52428799 52426752 25G 83 Linux
-
Ups, mein Fehler -sorry ???. Da siehst Du dass ich dd auch zu selten nutze, meist um isos auf einen Stick zu bringen. Also, dass die Quelle wie bei Dir oben ein nicht gemountetes Device ist ist richtig so, das willst Du ja komplett dumpen.
Als Ziel gibt es zwei Möglichkeiten: gibt man wie ayla oben schrieb ein Device an (/dev/sdxy), wird dieses mit der Quelle befüllt, 1:1. Willst Du wie ich es vorschlug stattdessen ein Image erzeugen, ist dieses natürlich ein File was auf einem erreichbaren, also schreibbar gemountetem Dateipfad liegen muss.
Also erst z.B. /dev/sdc1 nach /media/backup mounten, dann ist dieses mit of=/media/backup/test.img erreichbar.
Und für den richtigen Befehl um ein komprimiertes Image zu erzeugen hau nochmal bluelupo um ein Beispiel an, das hab ich praktisch noch nie gemacht. Möglicherweise hilfreich Datenträger sichern und wiederherstellen (http://www.gtkdb.de/index_7_1975.html) oder Systembackup mit dd (https://freetux.wordpress.com/2007/12/23/systembackup-mit-dd/)
-
@all:
Also ein Device (hier im Besipiel /dev/sda1 sichern per dd geht so. "if=" ist die Quelle, also das Inputfile und "of=" ist das Ziel wo die zu sichernde Dateien oder auch ein komplettes Device geschrieben werden soll. Das Ziel muss natürlich ein vorhandener (gemounteter) Pfad sein zB. auf einer einer externen Disk oder einem per NFS gemounteten NAS.
Backup:
# dd if=/dev/sda1 of=/media/NAS-Box/backups/Abbild-sda1.img
Wenn man mit dem file Kommando den Header des Image ansieht sollte es als solches erkannt werden.
# file Abbild-sda1.img
Abbild-sda1.img: Linux rev 1.0 ext4 filesystem data, UUID=xxx3db35-c457-41d2-3325-accfcf28fe21 (needs journal recovery) (extents) (huge files)
Ein Restore von sda1 kann dann von zweiten Rettungsystem auf der Disk oder einem Livestick (USB) erfolgen. Dort mountet man sich Filesystem mit Backup-Image und schreibt es auf die ursprüngliche Disk zurück.
Restore:
# cd <zum_backup_dir>
# dd if=./Abbild-sda1.img of=/dev/sda1
-
und ich rate noch mal ausdrücklich davon ab, das mit siduction zu machen - siduction muss man wenigstens ab und zu mal warten - sollte man zumindest, wenn man eine geplante Lebensdauer des Rettungssystems von über einem Monat annimmt
-
Und für den richtigen Befehl um ein komprimiertes Image zu erzeugen hau nochmal bluelupo um ein Beispiel an
Da nehme ich @der_bud beim Wort: Könntest du (@bluelupo) mir noch verraten, wie ich das Image in einem Rutsch via lzop komprimieren kann? ;)
@melmarker: Mit Lubuntu hatte ich bisher noch nix zu tun. Hab's mir mal fix in einer VM angeguckt. Das sieht ganz vielversprechend aus. Für den beschriebenen Zweck ein Debian Unstable Derivat eher nicht zu nutzen, ist für mich nachvollziehbar.
-
dann empfehle ich ein debian stable oder testing, was man kurz vor dem stable-Release auch auf stable stellt - die liste der Pakete kann man ja aus pyfll/lxde nehmen und hübsch bekommt man das auch relativ problemlos - da kann ich helfen
-
@pit:
dd if=/dev/sda1 of=/media/NAS-Box/backups/Abbild-sda1.img | lzop -1 -U -o Abbild-sda1.img.lzo
-U löscht das Original
-o Output File
-1 geringste Kompression aber schnell
....ansonsten man lzop ;-)
-
@melmarker: Jetzt bin ich kurz verwirrt - du hast doch selber Lubuntu LTS empfohlen. Da damit vermutlich für ein paar Jahre Ruhe wäre und Jessie ja noch nicht veröffentlicht ist, würde ich mir zusätzliches Gebastel ("liste der Pakete kann man ja aus pyfll/lxde nehmen") mangels eigener Erfahrung eher sparen wollen. Aber danke für das Hilfsangebot!
@bluelupo: Danke! Habe gestern Abend mal spaßeshalber via dd ein Abbild einer alten (nicht mehr genutzten) XP-Systempartition gemacht. 30 GB. Dann mit lzop (Defaultwerte) komprimiert. 17 GB. Das lohnt sich also abhängig vom Füllstand der Partition dicke. Irgenwann muss ich das halt alles mal von a bis z durchexerzieren.
Der Plan ist: Ich komme am 15.2. mit besagtem Rechner zurück, setze Win 7 neu auf, installiere alle Programme, spiele die Nutzdaten (extra Partition) zurück und versuche dann das eingangs beschriebene Vorgehen. Das wird dann mindestens einmal unter Realbedingungen getestet. Bei Erfolg geht die Kiste via gelbe Post zurück zu meinem Vater. Möchte die Zeit dort nicht mit Konfigurationsorgien vertrödeln - so oft sehe ich meine Eltern leider auch nicht mehr.
-
@pit - wenn Du mit lubuntu noch nichts am Hut hattest, empfiehlt sich eventuell ein natives debian
-
@bluelupo
Irgendwas mach ich noch falsch. Testszenario ist eine VM mit drei vdi's, auf denen sich jeweils eine Partition befindet:
sda1: Siduction 2014.1 Indian Summer KDE 64bit
sdb1: Slitaz 5.0 (Winz-Linux mit Openbox, Xserver Xorg/XVesa)
sdc1: Leere Linux Partition (ext4)
Gebootet ist Siduction, gesichert werden soll Slitaz, Ziel ist sdc1, letzteres ist auf /mnt/sdc1 gemountet.
# dd if=/dev/sdb1 of=/mnt/sdc1/150129-slitaz.img | lzop -1 -U -o /mnt/sdc1/150129-slitaz.img.lzo && ls -lh
10240000+0 Datensätze ein
10240000+0 Datensätze aus
5242880000 Bytes (5,2 GB) kopiert, 42,4682 s, 123 MB/s
insgesamt 4,9G
-rw-r--r-- 1 root root 4,9G Jan 29 15:22 150129-slitaz.img
-rw-r--r-- 1 root root 42 Jan 29 15:21 150129-slitaz.img.lzo
# file 150129-slitaz.img
150129-slitaz.img: Linux rev 1.0 ext4 filesystem data, UUID=f950e127-36bc-41c0-943a-c75bdd471400 (extents) (large files) (huge files)
Zwar wird die Image-Datei sauber erstellt (siehe das Ergebnis von "file" am Ende des Code-Schnipsels), der lzop-Befehl scheint aber fehlerhaft zu sein. Die komprimierte Version hätte nur 42 Bytes. Das wäre ein sensationeller Komprimierungsfaktor ;-)
Vorgehen in zwei Schritten klappt aber (hier nur der zweite):
# lzop -1 -U -o bla.lzo 150129-slitaz.img
root@siductionbox:/mnt/sdc1# ls -lh
... 109M Jan 29 16:07 bla.lzo
Probleme scheint's also mit dem Pipen zu geben.
Was aber funktioniert ist das:
# dd if=/dev/sdb1 | lzop -1 -o /mnt/sdc1/150129-slitaz.img.lzo
@melmarker: lubuntu passt schon, so exotisch ist das auch nicht und mit lxde hatte ich bereits in der Vergangenheit ein bisschen halbherzig rumgespielt.
-
@pit: Sorry, da hast du recht. Bei der Übergabe an eine Pipe gibt es für das dd-Kommando kein of (Ouputfile), denn das wird ja via Pipe weitergereicht an lzop und der wiederum ist für den Output zuständig. Als deine Variante ist korrekt.
Was hast du denn für eine Kompressionsrate?
-
@bluelupo:
Partition: 4,9 GB
Benutzt: 157 MB
LZO: 109 MB
Rechnen musste selbst (das kann ich nicht so gut) ;-)
-
Hallo pit, sieht ja gut aus soweit. Nur zur Vervollständigung: wenn Du wie im Beispiel (und angekündigt für Dads notebook) /dev/sda1 sichertst, ist das genau die Partition. Damit sicherst Du noch nicht MasterBootRecord mbr, bestehend aus dem Bootloader (in den ersten 446 Bytes) und die Partitionstabelle (64 Bytes). Zur Sicherheit solltes Du also nacher auf dem realen System einmal (nach Ubuntuwiki (http://wiki.ubuntuusers.de/dd#MBR-Boot-Loader-und-Partitionstabelle-sichern)):
dd if=/dev/sda of=mbr_sicherung bs=512 count=1
durchführen und bei Partitionsänderungen aktualisieren.
Und noch ein Zusatztipp, wir hatten hier im Forum ein paarmal was zum Thema "Fortschritt von dd mit pipeview (pv). Wenn Du pv nachinstallierst, kannst Du das noch zwischen Eingabe und Ausgabe setzen und kriegst eine Fortschrittsanzeige. Die Syntax wäre z.B.
dd if=/dev/sdb1 | pv -petra | lzop -1 -o /mnt/sdc1/150129-slitaz.img.lzo
-
Hallo pit, sieht ja gut aus soweit. Nur zur Vervollständigung: wenn Du wie im Beispiel (und angekündigt für Dads notebook) /dev/sda1 sichertst, ist das genau die Partition. Damit sicherst Du noch nicht MasterBootRecord mbr, bestehend aus dem Bootloader (in den ersten 446 Bytes) und die Partitionstabelle (64 Bytes).
Hi,
deswegen schlug ich das Sichern von sda mit Counter statt sda1 vor, dann ist der MBR etc. mit drauf und das Restore kann aus einer Datei erfolgen. Und solange man darauf achtet daß das Ende der 1. Partition beim Sichern leer ist ist es auch nicht so wichtig wo genau die Sicherung endet, solange sie nahe des Endes innerhalb! des leeren Bereichs der ersten Partition endet.
Zur Sicherheit solltes Du also nacher auf dem realen System einmal (nach Ubuntuwiki (http://wiki.ubuntuusers.de/dd#MBR-Boot-Loader-und-Partitionstabelle-sichern)):
Code: dd if=/dev/sda of=mbr_sicherung bs=512 count=1durchführen und bei Partitionsänderungen aktualisieren.
Das macht natürlich Sinn wenn man Partitionsänderungen vornimmt und sich anschließend eine komplette Sicherung der Partiton 1 sparen kann, allerdings darf dann auch nicht mehr ein früher gesichertes sda zurück gespielt werden, sondern dann ein sda1.
Interessanter Thread übrigens.
Gruß
ayla
-
deswegen schlug ich das Sichern von sda mit Counter statt sda1 vor, dann ist der MBR etc. mit drauf und das Restore kann aus einer Datei erfolgen.
Ich kann deine Argumentation nachvollziehen. Da ich aber nicht weiß, ob ich ein solches Image nur einmal - quasi initial nach mustergültiger Installation - erstellen werde, oder z.B. auch mein Vater Zwischenstände konservieren möchte, klingt mir das zu riskant. Nicht auszuschließen also, dass der Füllstand der zu sichernden Partition die voreingestellte Grenze dorch irgendwann überschreitet. Am Ende hat mein ein unvollständiges und in dieser Form vermutlich nicht verwendbares Image erstellt. MBR u. Partition in gesonderten Backups zu speichern, klingt für mich wie ein vertretbarer Kompromiss.
-
Hi pit,
ich würde dringend raten folgende Backupstrategie (aus leidvoller Erfahrung) ans Herz legen. Aus der Rettungspartition heraus würde ich per Shellscript (auf dem Desktop anklickbar) folgende Partitionen sichern (alles per dd):
* MBR
* Windows Systempartition
* Windows Datenpartition
...davon würde ich die letzten 5-10 Backupsätze aufbewahren. Somit stellst du sicher das keine Windows-Partition (pus MBR) nicht mehr ersetzbar ist. Im Idealfall hast du die Rettungspartition auf einer eigenen Festplatte, dann bist bei einem HW-Defekt der Windows-Disk auch noch auf der sicheren Seite.
Ich gehe im Prinzip bei dem Rechner meiner Freundin genauso vor, d.h. Systemartition (siduction) liegt auf einer SSD (sda) und die Backup-Sätze liegen auf einer zweiten HDD (sdb) auf der ich nur die Sicherungen ablege.
-
dd if=/dev/sdb1 | pv -petra | lzop -1 -o /mnt/sdc1/150129-slitaz.img.lzo
Ähm - blöde Frage: Wie spiele ich das zurück? So?
dd if=/mnt/sdc1/150129-slitaz.img.lzo | pv -petra | lzop -x -o /dev/sdb1
Das würde ja bedeuten, dass lzop gleichermaßen entpacken und blockorientiertes Kopieren kann. Letzteres doch sicher nicht oder? Hieße, dass man das in zwei Schritten machen müsste? Dann hätte ich im Zweifel aber schon wieder ein Platzproblem.
-
Moin pit, die Anleitungen die ich mir abgespeichert haben fangen bei komprimierten Images den Rückspielbefehl mit dem Unpacker an, dessen Ausgabe wird zu einem 'dd of=' gepiped. Hier mehrere Syntaxvarianten mit gzip, für lzop anzupassen:
gunzip -c /media/sdb1/backup.img | dd of=/dev/hda bs=1M
gzip -dc image.dump.gz | dd of=/dev/sdb
cat /home/user/image_sda1.img.gz | gunzip -c - | dd of=/dev/sda1
Kommt mir jetzt beim Nachdenken auch logisch vor, da Du beim Rückspielen ja nicht ein Blockdevice ausliest, aber zu einem schreibst. Mit dd beginnen würde das Rückspielen bei einem 1:1-kloning Device-auf-Device.
-
Hello
Another idea is to use ntfsclone.to clone and restore a windows partition.
to make an image
ntfsclone --save-image -o - /dev/$dev | gzip -c > /usr/local/$dev.gz
and for restoring an image
gunzip -c /usr/local/$dev.gz | ntfsclone --restore-image --overwrite /dev/$dev -
ntfsclone is very quick and clones only used sectors.
Maybe if it's used lzo instead of gzip the process will be faster.
To use ntfsclone input and destination partitions should have same sizes.
If dest partition has a different size it can be used fsarchiver instead.
to make an image
fsarchiver -v savefs /usr/local/${dev}.fsa /dev/$dev
to restore an image
fsarchiver -v restfs /usr/local/${dev}.fsa id=0,dest=/dev/$dev
fsarchiver works at files level and is able to understand ntfs and linux ext4 if I am not wrong.
-
@der_bud
Was klappt: lzop-komprimiertes Image erstellen (habe ein Script gebaut, um Trouble mit sudo und Pipes zu umschiffen).
Was nicht klappt: Restore in einem Rutsch.
Probiert habe ich
sudo sh -c 'lzop -d bla.img.lzo | dd of=/dev/sda3'
Habe zwischenzeitlich statt sda3 auch mal in ein File schreiben lassen - das hat aber immer 0 Byte.
Packe ich die *.img.lzo gesondert aus (lzop -d ....), wird korrekt entpackt. Wo ist mein Denkfehler?
(Wer oben mitgelesen hat und sich jetzt wundert, warum ich statt sda mit sdaN operiere: Auf dem Zielrechner wurden bei der Windows-Installation (SSD = sda) gleich drei Partitionen angelegt. sda1 = UEFI, sda2 = WindowsBoot, sda3 = Win-C.)
-
Hi pit, ich glaube ich habe neulich in einem Forum genau die selbe "Falle" gesehen die ich bei Dir zu erkennen glaube: wenn Du root-Rechte bzw sudo benötigst, dann für jeden Befehl einzeln, also auch nach der Pipe.
sudo sh -c 'lzop -d bla.img.lzo | sudo dd of=/dev/sda3'
könnte eher klappen.
__
Edit: ^ falsch, siehe unten.
-
äh nee - dat is gruselig, der_bud, so solltest Du dat mit den Hochkommas nich mixen
sudo su -c "lzop -d bla.img.lzo | dd of=/dev/sda3"
dürfte passen, weil als Befehl das in den Hochkommas eingeschlossene betrachtet wird. sudo ist eigentlich immer gruselig.
-
:-[ aaiihh - ich hatte komplett die Hochkommas übersehen...
-
@melmarker
Du meinst, ich soll die Hochkommata schlicht gegen Anführungszeichen austauschen? Ich bin jetzt nicht so der Fachmann in Sachen Shellscripts: Macht das in diesem Fall einen Unterschied? Ich finde dazu z.B. das hier (http://www.linux-services.org/shell/#SECTION00332000000000000000), lese daraus aber keinen Unterschied.
Meine Version (die nicht funktioniert):
sudo sh -c 'lzop -d bla.img.lzo | dd of=/dev/sda3'
Deine Version (die ich noch nicht testen konnte)
sudo su -c "lzop -d bla.img.lzo | dd of=/dev/sda3"
-
ob du in diesem speziellen Fall einfache oder doppelte Hochkommata benutzt, ist recht wurst, witzig wird der Unterschied erst, wenn Du Variablen und solch Zeug expandieren musst:
Der Unterschied zwischen einfachen und doppelten Anführungszeichen ist, dass bei doppelten Anführungszeichen eine Variablenerweiterung stattfindet. Einfache Anführungszeichen gewährleisten, dass die Zeichenfolge von der Shell buchstäblich interpretiert wird.
Und wenn Du mir jetzt noch erklärtst, was Du mit "sudo sh" erreichen willst ...
-
Und wenn Du mir jetzt noch erklärtst, was Du mit "sudo sh" erreichen willst ...
Das Ganze läuft auf Ubuntu und ich darf's als normaler User nicht. Es sind ja zwei Befehle mit Pipe dazwischen. Mir ist's anders nicht gelungen, beide mit SuperUser-Rechten zu starten. Diese Lösung hatte ich ergoogelt.
-
mit sudo sh machst Du eine shell mit rootrechten auf und führst dat mit -c übergebene Kommando oder die Sequenz aus - und zwar alles mit root-Rechten. Als Test:
sudo sh -c "ls | tee /test"
cat /test
Mit anderen Worte: Sollte funktionieren™, einen offensichtlichen Fehler konnte ich in Deinem Befehl nicht wirklich feststellen. Das lässt nur 2 Schlüsse zu: entweder das File oder die Partition existieren nicht und ein output wäre sehr hilfreich. Oft hilft es auch beim entwicklen, die Sachen ein wenig gesprächiger zu machen. in lzop gibt es die Option --verbose, bei dd könnte status=?xyz helfen.
-
Hallo Freunde,
ich möchte diesen äußerst interessanten Thread nochmal aufgreifen um vielleicht eine Lösung meines Problems zu finden. Ich habe ein Notebook (mit SSD) auf dem eine Windows 7 Professional vorinstalliert war (keine System DVD vorhanden) und habe mein Siduction dazu gepackt. Da ein Wechsel zwischen beiden (den ich leider geschäftlich häufig benötige) immer mit einem nervigen reboot ins andere System verbunden ist möchte ich das Windows System auf einen Stick oder eine mobile Platte sichern und dann in eine VM (Virtualbox) unter Siduction zurückspielen. Wie kann ich das machen?
Meine Partitionen sehen wie folgt aus:
blkid
/dev/sda1: LABEL="SYSTEM_DRV" UUID="64369CAE369C82AA" TYPE="ntfs" PARTUUID="78fd53ea-01"
/dev/sda2: LABEL="Windows7_OS" UUID="4A34A53B34A52AC1" TYPE="ntfs" PARTUUID="78fd53ea-02"
/dev/sda3: LABEL="Lenovo_Recovery" UUID="3424AB6D24AB3132" TYPE="ntfs" PARTUUID="78fd53ea-03"
/dev/sda5: UUID="20ee80df-fe1f-4c01-87b1-255d2c5e0bda" TYPE="ext4" PARTUUID="78fd53ea-05"
/dev/sda6: UUID="b9bea0dd-4ff7-4e08-baba-11df80dd9d98" TYPE="ext4" PARTUUID="78fd53ea-06"
/dev/sda4 habe ich als extended Partition eingerichtet und da Siduction drauf gepackt. (siehe Anhang)
-
gib 29€ aus und nimm TrueImage dafür. Deine Nerven werden es Dir danken.
-
Wenn du das von Acronis meinst das kostet nen Fuffi und das wollte ich für eine einmalige Aktion nicht ausgeben. O. k. ich könnte mal die 30 Tage Testversion ausprobieren und hoffen dass es klappt .... :) und nicht irgendwann beim Zurückspielen die Aufforderung kommt "Geben Sie die Seriennummer ein ..." oder ähnliches. ::)
-
Es sind nicht meine Nerven ... 8)
-
Hi Peter,
hast du schon mal über eine Neuinstallation von Windows in einer VM nachgedacht (Virtualbox)? Das müsste der sauberste Weg sein. Auch bei einer Windows-OEM-Version ist ein Aufkleber am Gerät mit Nummer für die erneute Registrierung von Windows.
-
hallo harley-peter,
Virtualbox wird in einer VM einem Windowssytem neue virtuelle Hardware präsentieren, die von der echten Hardware des Hostsystems abweicht. Das Wechseln der Hardware ist aber wegen der hardwaregebundenen Lizenz nicht erwünscht und kann somit erhebliche Probleme bereiten, wenn Du ein Image-basiertes Verfahren verwenden willst.
Grüße
musca
-
@bluelupo:
Hi Michael, das wäre noch eine Alternative dann muss ich nur noch im Netz oder bei Microsoft schauen ob die Software irgendwo herumschwirrt.
@musca:
Das muss ja möglich sein. Was machen denn sonst die Leute wenn die Hardware kaputt geht?
Grüße
Peter
-
Die Bauchschmerzen von Microsoft ignorieren und neue Hardware nehmen - wenn alles gut geht, dann muss man eventuell neu aktivieren und wenn man das schon einige Male gemacht hat, dann lernt man auf diesem Wege auch mal die Menschen hinter Microsoft kennen - mit denen man dann nett über die erneute Freischaltung sprechen kann, so telefonisch :D
Das schicke daran ist, dass die Leute, die man beim Anruf an die Strippe bekommt, das meist nicht dürfen und man dann eine Stufe höher eskaliert wird - oder auch noch eine. Ist echt spassig und je höher man kommt, desto netter werden die Gesprächspartner. Echt. Wirklich. 8)
-
Hi Alf,
das hört sich ja interssant und nach längeren und nervigen Telefonaten an. Einen ersten Einddruck habe ich bereits bekommen als ich das System von der Microsoft Seite herunterladen wollte. Nachdem ich den Produktkey eingegeben hatte wurde mir gesagt dass es sich vermutl. um ein vorinstalliertes System handelt und ich mich doch bitte an meinen OEM-Anbieter wenden soll. Habe jetzt im Netz eine 30 Tage Testversion gefunden mit der ich es die nächsten Tage mal in einer VM versuchen werde.
-
Hi Peter,
wer ist denn der OEM-Anbieter? Dort würde ich es tatsächlich mal probieren, wenn's bei Microsoft nicht klappt.
-
Hi Michael,
der Laden der mir das Gerät verkauft hat verweist mich auf die Lenovo-Seite wo mir die "kostenlose" Recovery-DVD für 20 € angeboten wird. >:( Mit den eingebauten Windows Tools kann ich ebenfalls kein Abbild erstellen weil mir nur die eigene Festplatte (nicht genügend Platz) oder ein nicht vorhandenes DVD-Laufwerk als Speichermedium angeboten wird. USB ist Fehlanzeige. Windows ist toll!
Edit:
Habe mir jetzt mal die 30 Tage Testversion in die VM installiert. Ich bin völlig verblüfft :o dass die Kiste bei Eingabe des Produktkeys nicht gemault hat sondern anstandslos installiert hat. Na ja vielleicht kommt das böse Erwachen nach den 30 Tagen bin mal gespannt. :P
-
Hi Peter,
besorgt dir doch Windows OEM CD, die gibt es für ca. 30 Euro (habe selbst eine Win7 Prof. OEM) im Netz zu kaufen. Dann bist du das leidige Thema mit der Lizenz los.
-
Hi Michael,
ich warte jetzt erst mal ab was nach den 30 Tagen passiert denn den Produkt-Key hat Microsoft anscheinend klaglos akzeptiert. Vielleicht klappt ja alles (bin Optimist). :)
Mal ne andere Frage: Hast du schon mal für so ein System die Option auf Windows 10 gewählt? Wenn ja ist das empfehlenswert?
-
Habe hier ein Windows10 in einer Virtualbox auf einem Mac Mini mit OSX laufen. Geht da problemlos.
Ich gehe davon aus das das dann auch unter Linux tut.
-
Win 10 geht auf KVM problemlos.
Win 10 runs perfectly on a KVM VM.