Das Kopieren von Linux liveUSB verursacht Fehler mit init.d-Skripts - Unmöglich ..?

500
Mr. H. Dumpty

Bitte poste deine Gedankenideen oder alles, was dir vielleicht einfällt. Es würde mich sehr interessieren, was andere denken.

Das allgemeine Problem

Wenn ich eine einfache Java-Anwendung (die ich geschrieben habe) installiere, die beim Booten (im Hintergrund) über /etc/init.d/ ausgeführt wird, funktioniert sie auf der liveUSB, auf der ich sie explizit installiere. Wenn ich eine Kopie dieses Sticks mache, wird er nie erfolgreich gebootet. Beim Booten der liveUSB-Kopie bleibt die Java-Anwendung immer hängen, wenn der liveUSB-Startvorgang mein Skript erreicht. Mein Skript, das genau das tut, was es tun soll, auch alle 5 Minuten, und es wird so lange ausgeführt, bis Sie die Maschine herunterfahren.

  1. Mein Skript blockiert alles andere
  2. Nichts wird über mein Skript hinaus geladen
  3. Sie können mein Skript nicht abbrechen
  4. Es gibt keine GUI
  5. Der einzige Text, den Sie sehen können, ist die Befehlszeilenausgabe meines Skripts

Setup & Test - Alles läuft gut :)

Ich habe eine Linux liveUSB mit 3 Partitionen. Ein einfaches Xubuntu-Standardbild wird geladen.

  • sda1> 2 gb stoage
  • sda2> 2 gb system
  • sda3> verbleibende gb für casper

Ich habe eine einfache Java-Anwendung erstellt, die beim Start im Hintergrund ausgeführt wird. Um so weit zu kommen, folgte ich diesen Schritten:

  1. Kompilierte Java-Anwendung in Klassen
  2. Klassendateien in / home / user / folder / platziert
  3. Kopierte mein startup.sh-Skript in /etc/init.d/
  4. In /etc/init.d/
    • Typ "update-rc.d startup.sh start 20 2 5. Stop 20 0 1 6".
    • Diese aktualisierten Laufebenen wurden erfolgreich aktualisiert
  5. Jetzt kann ich jeden Vorgang neu starten / neu starten / herunterfahren und alles läuft einwandfrei!

Die Kopie - Hier wird es knifflig!

Beim Erstellen einer Kopie dieses Sticks folge ich diesen Schritten:

  1. Montieren Sie sda2
    • Kopieren Sie alles aus diesem Ordner nach / home / user / Desktop / tmp-system /
  2. Montieren Sie sda3
    • kopiere alles aus diesem Ordner nach / home / user / Desktop / tmp-casper /
  3. Gehen Sie nach / home / user / Desktop / tmp-system /
    • Geben Sie "tar -cvf system.tar" ein.
  4. Gehen Sie nach / home / user / Desktop / tmp-casper /
    • Geben Sie "tar -cvf casper.tar" ein.
  5. Umount
    • sda2
    • sda3
  6. Stecken Sie ein leeres USB-Kabel ein (zB SDB)
    • Partitionen einrichten (wie der Stick, von dem Sie kopieren)
    • Unterteilungen in Partitionen
      • tar -xvf system.tar ... in sdb2
      • tar -xvf casper.tar ... in sdb3

Testen - hier geht alles schief!

  1. Schließen Sie neu erstellte liveUSB an einen Computer an
  2. Booten Sie von USB
  3. Alles beginnt gut zu booten
  4. Java-Anwendung, die ich geschrieben habe, wird ausgelöst
    • Der Startvorgang bleibt für immer hängen
    • Keine Eingabeaufforderung für Cmd verfügbar
    • KEINE GUI verfügbar
    • Es ist, als ob der Thread läuft (und es ist! Die Ausgabe kann alle 5 Minuten angesehen werden - genau so, wie es sein sollte)

Lösungsversuche & Gotchas

1

Ich kann die kopierte liveUSB einbinden, die Datei startup.sh bearbeiten, um meine Java-Anwendung nicht zu starten, und sie wird immer noch nicht gestartet (genau wie ich es vermutet habe).

2

Wenn ich "dd if = sda of = sdb" verwende, funktioniert die Kopie des liveUSB einwandfrei. Dies ist jedoch keine akzeptable Lösung. Wenn ich einen 16-GB-Stick mit dd auf einen 64-GB-Stick kopieren würde, würde aus dem 64-GB-Stick ein 16-GB-Stick werden. Das Ändern der Werte, die in jeder Partition geändert werden müssen, wird außerdem erheblich schwieriger.

3

Getestet viele Variationen von startup.sh und der Java-Anwendung selbst. Alle erzeugen den gleichen Fehler.

4

Die Methode, die ich zum Kopieren verwende, funktioniert für jede andere Form von Anwendung, Datei oder irgendetwas anderem.

5

Ich möchte auch versuchen, die Verwendung zusätzlicher Bibliotheken oder Programme zur Ausführung der Java-Anwendung zu vermeiden.

6

Ich habe auch sda2 & sdb2 gemountet, um alles direkt von einem zum anderen zu kopieren, dann folgte das gleiche für sda3 & sdb3. Dies erzeugt den gleichen Fehler.

ZUSÄTZLICHE PUNKTE

  1. Die sda3-Partition wird mit cryptsetup verschlüsselt
  2. Es gibt 2 Dateien in der Datei system.tar (die sdb2 sein wird, die von sda2 stammt), deren Wert geändert wird, nachdem sie auf den USB-Stick geschrieben wurden.
    • Diese beiden Werte haben in der Vergangenheit keine Probleme verursacht und wurden jedes Mal geändert, wenn ein neues liveUSB erstellt wird
  3. Es gibt 1 Datei in der Datei casper.tar (die sdb3 sein wird, die von sda3 stammt), deren Wert geändert wird, nachdem sie auf den USB-Stick geschrieben wurde.
    • Dieser Wert hat in der Vergangenheit keine Probleme verursacht und wurde bei jedem neu erstellten liveUSB immer geändert.

Prüfsummen-Testprozess

Orignial liveUSB Bild

Live arbeiten usb> sda empty usb> sdb

Schritte:

  1. Mounten, Kopieren und Checksumme sda2
    • Typisiert "mount / dev / sda2 / media / sda2"
    • Typisiert "tar -C / media / sda2 -cvf ~ / Desktop / system.tar."
    • Typisiert "find. -Type f -exec sha1sum {} ';' > /tmp/sda2_checksum.txt "
    • Typisch "umount / media / sda2"
  2. Mounten, Kopieren und Checksumme sda3
    • Typisiert "mount / dev / sda3 / media / sda3"
    • Typisiert "tar -C / media / sda3 -cvf ~ / Desktop / casper.tar."
    • Typisiert "find. -Type f -exec sha1sum {} ';' > /tmp/sda3_checksum.txt "
    • Typisch "umount / media / sda3"
  3. Erstellen Sie Partitionen für SDB
  4. Mount, schreiben und Checksumme sdb2
    • Typisiert "mount / dev / sdb2 / media / sdb2"
    • Typisiert "tar -C / media / sdb2 -xvf ~ / Desktop / system.tar"
    • Typisiert "find. -Type f -exec sha1sum {} ';' > /tmp/sdb2_checksum.txt "
    • Typisch "umount / media / sdb2"
  5. Mounten, Schreiben und Checksumme sdb3
    • Typisiert "mount / dev / sdb3 / media / sdb3"
    • Typisiert "tar -C / media / sdb3 -xvf ~ / Desktop / casper.tar"
    • Typisiert "find. -Type f -exec sha1sum {} ';' > /tmp/sdb3_checksum.txt "
    • Typisch "umount / media / sdb3"
  6. Kontrollsummen vergleichen
    • sortiere /tmp/sda2_checksum.txt -o /tmp/sda2_checksum.txt.sort
    • sortiere /tmp/sda3_checksum.txt -o /tmp/sda3_checksum.txt.sort
    • sort /tmp/sdb2_checksum.txt -o /tmp/sdb2_checksum.txt.sort
    • sort /tmp/sdb3_checksum.txt -o /tmp/sdb3_checksum.txt.sort
  7. Ergebnisse

sda2 & sdb2

Typ "diff sda2_checksum.txt.sort sdb2_checksum.txt.sort"

45d44 < 2ddf9802c9c15ac6e4575cc9de32e3530eae6b7d ./efi/boot/grub.cfg 82d80 < 59bb2775a8e7e499e0590b7b8c2492eb250fb7d8 ./syslinux/txt.cfg 154a153 > ae6c127713e01fc5fb4a2e4e28f6bbddc6bd6af5 ./efi/boot/grub.cfg 158a158 > b78090b66b4e3fa04ca9d466ee78c9060adf744e ./syslinux/txt.cfg

Diese 2 Dateien enthalten jeweils einen Wert, der geändert wird. Alles andere ist das Gleiche. Die Ergebnisse sind genau das, was sie sein sollten.

sda3 & sdb3

Typ "diff sda3_checksum.txt.sort sdb3_checksum.txt.sort"

Identisch - Denken Sie daran, dass dies das Original-LiveUSB-Bild ist.

Im nächsten Abschnitt werde ich weitere Vergleichsergebnisse veröffentlichen.

NÄCHSTE SCHRITTE - alias Aktionsplan

Start von liveUSB-Image ohne die Skripts, die ausgeführt werden müssen.

Schritt 1 - Erfolg / Misserfolg?

ERFOLG - Prüfsummen passen wie sie sollen

  1. Java auf liveUSB von 6 auf 7 aktualisieren
  2. Teer neu erstellen
  3. Erstelle neue liveUSB aus tar's
  4. Testen Sie liveUSB

Schritt 2 - Erfolg / Misserfolg?

ERFOLG - Prüfsummen passen wie sie sollen

  1. / Home / user / Ordner / erstellen
  2. Kopieren Sie Klassendateien für die Java-Anwendung nach / home / user / folder /
  3. Teer neu erstellen
  4. Erstelle neue liveUSB aus tar's
  5. Testen Sie liveUSB

Schritt 3 - Erfolg / Misserfolg?

ERFOLG - Prüfsummen passen wie sie sollen

  1. Fügen Sie in /etc/init.d/ die Datei startup.sh hinzu.
  2. Ohne update-rc.d aufzurufen
  3. Teer neu erstellen
  4. Erstelle neue liveUSB aus tar's
  5. Testen Sie liveUSB

Schritt 4 - Erfolg / Misserfolg?

ERFOLG - Prüfsummen passen wie sie sollen

(Ich habe es bisher noch nicht so erfolgreich gemacht) - der Wert, der geschrieben werden muss, wurde jedoch noch nicht in die casper-Partition (sda3) eingefügt.

  1. Geben Sie "update-rc.d startup.sh start 21 2 5" ein.
  2. Teer neu erstellen
  3. Erstelle neue liveUSB aus tar's
  4. Testen Sie liveUSB

Schritt 5 - Erfolg / Misserfolg?

ERFOLG - Prüfsummen passen wie sie sollen

Ich kann nicht glauben, dass dies funktioniert hat! Was bringt mich zu ... (um es auf eine nette Art auszudrücken) Warum hat die Welt vorher nicht funktioniert?

- Zufälligerweise funktionierte Version-13.

  1. Boot liveUSB
  2. Geben Sie den Wert ein, der in casper (sda3) überschrieben werden soll, bevor Sie tar erstellen
    • Beim Laufen von liveUSB
    • Bearbeiten Sie die Konfigurationsdatei in /home/user/folder/config.properties
  3. LiveUSB herunterfahren
  4. Teer neu erstellen
  5. Erstelle neue liveUSB aus tar's
  6. Testen Sie liveUSB

BILD VOLLSTÄNDIG !!

Ich bin damit noch nicht fertig!

* Das Schreiben an die USB hat sich nie geändert.

Warum hat es vorher nicht funktioniert?

  1. Teer-Methode? - Nur eine kleine Änderung ...
    • Von "tar -cvf casper.tar".
    • TO "tar -C / media / sda3 / -cvf ~ / Desktop / casper.tar.
    • Erreichen diese Zeilen nicht dasselbe?
    • Ich werde das in Kürze testen. - Ich vermute keinen Unterschied.
  2. Das Verfahren in einzelne Schritte aufteilen?
    • Vor:
      • Unter dem NÄCHSTEN SCHRITT - auch Aktionsplan genannt - würde ich alle diese Schritte ausführen, bevor Sie ein neues Bild erstellen.
    • Nach dem:
      • Der NEXT STEPS - alias Aktionsplan - wurde genau befolgt
    • Könnte das der Unterschied sein?
    • Ich werde das in Kürze testen.
  3. Kann das Löschen großer (oder kleiner) Dateien aus dem Verzeichnis / home / in der Partition casper (sda3) zu Beschädigungen führen?
    • Ich habe keine Ahnung..?
    • Ich werde das in Kürze testen.

Weitere Tests - ich möchte meine Antwort!

Beginnend mit dem ursprünglichen liveUSB-Bild.

  1. Java auf liveUSB von 6 auf 7 aktualisieren
  2. / Home / user / Ordner / erstellen
  3. Kopieren Sie Klassendateien für die Java-Anwendung nach / home / user / folder /
  4. Fügen Sie in /etc/init.d/ die Datei startup.sh hinzu.
  5. Geben Sie "update-rc.d startup.sh start 21 2 5" ein.
  6. Bearbeiten Sie die Konfigurationsdatei in /home/user/folder/config.properties

Schritt auf einmal dieses Mal. - Wird es funktionieren?

Test 1 - Erfolg / Fehler?

SCHEITERN!

  1. Alte Teermethode

Test 2 - Erfolg / Fehlschlag?

  1. Alte Teermethode
  2. Gelöschte generierte Datei in / boot /
    • Diese Datei wird von meinem Skript erstellt, wenn die casper-Partition (sda3) geschrieben wird. Sie enthält nur eine ID, die zur Verifizierung keinen Einfluss auf den Startvorgang hat.

Test 3 - Erfolg / Fehlschlag?

  1. Neue Teermethode

Test 4 - Erfolg / Fehlschlag?

  1. Neue Teermethode
  2. Gelöschte generierte Datei in / boot /
    • Diese Datei wird von meinem Skript erstellt, wenn die casper-Partition (sda3) geschrieben wird. Sie enthält nur eine ID, die zur Verifizierung keinen Einfluss auf den Startvorgang hat.

Ergebnisse

Ich werde in dieser Reihenfolge testen:

Test 1 -> Test 3 -> Test 4 -> Test 2

Wenn Test 1 funktioniert, springe ich aus dem Fenster! - Ich habe keine Ahnung, warum es jetzt funktionieren würde, da ich dies viele Male getestet habe und jedes Mal erfolglose Stiefel hervorgebracht hat. - Vielleicht war der CP- oder TAR-Prozess irgendwie beschädigt.

Wenn Test 1 fehlschlägt: Wenn Test 3 funktioniert ... - Die tar-Methode hat den Fehler verursacht. - Ich verstehe nicht, was mit der alten tar-Methode und der neuen tar-Methode falsch wäre.

TBC ...

4

2 Antworten auf die Frage

2
Nanzikambe

Angesichts Ihrer Beschreibung des Problems vermute ich, dass etwas anderes geschieht, als Sie beschreiben. Versuchen Sie es auf jeden Fall:

# sda2 mount /dev/sda2 /mnt/tmp tar -C /mnt/tmp -cf ~/Desktop/sda2.tar . umount /dev/sda2  # ... repeat for sda3 ... # do your create partition shenanigans mount /dev/newsda2 /mnt/tmp tar -C /mnt/tmp -xpf ~/Desktop/sda2.tar umount /dev/newsda2 # repeat ... # test ..

Wenn dies funktioniert, besteht die Chance, dass / home / noexec gemountet ist oder ein Dateisystem von fubar ist, weil das Problem darin bestand, dass das Ausführungsbit entfernt wurde.

Wenn dies nicht funktioniert, bearbeiten Sie Ihr Startskript, um Debug-Informationen wie die Ausgabe von mount, den Inhalt von syslog usw. anzuzeigen, und suchen Sie dort nach Hilfe.

Sie können auch Prüfsummen für jede Datei generieren und Kopie mit Original vergleichen:

find . -type f -exec sha1sum {} ';' > /tmp/sda2_checksums.txt

für jede gemountete Partition die Dateien /tmp/*_checksums.txt

This has been very useful for testing. Thank you very much! I will keep updating with progress that I am making and the output from checksum comparisons. Thank you again. Mr. H. Dumpty vor 10 Jahren 0
Die neue Teer-Methode scheint den Trick zu vollbringen. Ich frage mich immer noch, warum meine alte Methode diesen Fehler erzeugen würde. Ich habe in den Ordner / home geschaut und finde keinen Unterschied. Ich muss weiter suchen und alle auf dem Laufenden halten. Mr. H. Dumpty vor 10 Jahren 0
0
Tom

Antwort auf Lösungsversuche und Gotchas # 2 bezüglich der Verwendung des Befehls dd:

Wenn Sie den ursprünglichen Live USB mit dem Befehl dd kopieren, wird der 64-GB-Stick nicht dauerhaft in einen 16-GB-Stick umgewandelt. Dies geschieht nur, wenn Sie den 64-GB-Stick nach der Verwendung des Befehls dd nicht neu partitionieren. Sie können die Größe der Parition ändern, um den verbleibenden freien (nicht zugewiesenen) Speicherplatz auf dem 64-GB-Stick nach der Verwendung des Befehls dd wiederherzustellen.

Sie können die Partitionen überarbeiten, indem Sie einen der GParted- oder Parted Magic-Partitionseditoren verwenden, um nach der Verwendung des Befehls dd auf dem geklonten USB-Flashlaufwerk freien Speicherplatz von 16 GB bis 64 GB wiederherzustellen.

Der Nettoeffekt ist, dass der Befehl "dd" den 64-GB-Stick nicht dauerhaft in einen 16-GB-Stick verwandelt, indem entweder GParted oder Parted Magic verwendet wird, nachdem der Befehl "dd" gestartet wurde, um den Rest des 64-GB-Sticks zurückzufordern.

Verwenden Sie das Linux Disk Utility-Programm für Ihre Linux-Distribution, um zu überprüfen, ob der Partitionsspeicher frei oder zugewiesen ist.

Sie können GParted aus dem Tutorial "GParted partitioning software - Full Tutorial" unter http://www.dedoimedo.com/computers/gparted.html lernen

Informationen zu Parted Magic finden Sie unter: https://en.wikipedia.org/wiki/PartedMagic, aber meiner Erfahrung nach würde ich GParted empfehlen, da Parted Magic eine vollständige Distribution von Tools war, es sei denn, Sie bevorzugen die spätere Vorgehensweise darüber.

Kurz gesagt, Sie haben bereits die einfachste Lösung für Ihr Problem gefunden, die nur eine umgestaltete Partition entfernt ist, wenn keiner der Tests, die Sie am Ende Ihrer Posts geplant haben, funktioniert.

Verwandte Probleme