Grundsatzüberlegungen vor Neuinstallation

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 10.07.2013 17:54:33

NAB hat geschrieben:Auf dem /boot/-Raid ist ein Dateisystem. Wenn du das System startest, wird /boot/ gemounted. Dann reicht ein simples "ls", und die "atime" im Dateisystem wird geändert. Schwupp hast du einen Schreibzugriff.
Aha. Das würde ja jedesmal passieren, wenn ich boote?
Einmal! Der Zustand wird in den Raid-Headern gespeichert. Du solltest auch Informationen darüber in /proc/mdstat sehen können.
Jupp, habe ich mittlerweile auch herausgefunden, da ich die genannten Parameter nicht ungeprüft übernehmen wollte, habe ich mich mal auf die manpage besonnen und siehe da, es steht sinniges drin ;)
Aber das kann nicht sein, denn dann würde auch der Eintrag für swap in der fstab fehlen.
Tja ... sieht wirklich nach einem Fehler im Installer aus.
Ebend.
Aber ... hey ... es läuft! :)
Ja - endlich. Eine erneute Installation hat dann auch alles gut zuende gebracht, aber dabei ist das "große" md schon wieder out-of-sync. Keine Ahnung wieso. Im übrigen darf man sich nicht irritieren lassen und muss eventuell sogar mehrfach ganz neu ansetzen. Bei mir hat das Erstellen der crypt-devices schon nicht mehr funktioniert, nachdem ich mir die Partitionierung der Platte im Installer nur nochmal angesehen hatte (also nicht weiter angerührt). Danach wollte der Installer die Partitionstabelle für die zweite Platte (nur die habe ich mir nochmal genauer angeschaut) neu schreiben und das hat dem crypt-Kram nicht gefallen. So ganz perfekt ist der Installer nicht.
Nur der Test mit sdb alleine fehlt noch. Das würde mich schon wegen diesem Thread hier interessieren:
http://debianforum.de/forum/viewtopic.php?f=12&t=143578
Öhm, ja. Das habe ich nur kurz angetestet: grub-install /dev/sdb, dann sda abgezogen, grub hat auch von sdb gebootet. Das habe ich dann hart unterbrochen und die Kiste abgeschaltet, weil ich weiterkommen wollte.

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 10.07.2013 18:55:50

Jetzt fehlt mir noch die Angabe, wie ich das System den verschlüsselten swap automatisch entschlüsseln lassen kann, wenn ich nicht dieses derive_decrypted verwenden möchte (wegen suspend_to_disk), sondern einfach nur das swap automatisch decrypted haben möchte.

wanne
Moderator
Beiträge: 7616
Registriert: 24.05.2010 12:39:42

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von wanne » 10.07.2013 19:06:34

In der crypttab kannst du in der dritten Spalte eine Datei angeben, in der eine Datei mit dem Passwort steht. (Achtung in der Datei darf nur das pw ohne Zeilenumbruch am Ende stehen.) Liegt die auf ner verschlüsselten Partition und ist nur von root lesbar ist das auch sicherheitstechnisch unproblematisch.
Also vom Prinzipher so

Code: Alles auswählen

md2_cryptp1  /dev/md2                   /etc/swappw       luks
Wbei in /etc/swappw halt das passwort steht.
/etc/swappw /etc/swappw legst du am besten so an

Code: Alles auswählen

echo -n "passwod" > /etc/swappw
chmod 400  /etc/swappw
rot: Moderator wanne spricht, default: User wanne spricht.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von NAB » 10.07.2013 21:10:56

dirk11 hat geschrieben:Aha. Das würde ja jedesmal passieren, wenn ich boote?
Öhm ... vermutlich würde das nicht passieren, wenn du die Boot-Partition als "read-only" mountest oder mit der Option "noatime". Aber warum solltest du ...
dirk11 hat geschrieben:habe ich mich mal auf die manpage besonnen und siehe da, es steht sinniges drin ;)
Das ist eine sehr gute Idee! ;-)
Wenn dir der Lesestoff ausgeht, mach gleich bei den manpages von cryptsetup und crypttab weiter :)
dirk11 hat geschrieben:aber dabei ist das "große" md schon wieder out-of-sync. Keine Ahnung wieso.
Direkt nach der Installation? Das ist aber merkwürdig.
Schau hin und wieder mal ins dmesg, ob da eine Festplatte aus dem Tritt kommt und kurz verschwindet. Die gewöhnliche und ausgesprochen lästige Ursache dafür sind mistige Sata-Kabel.

Ausgesprochen gut gefällt mir übrigens das kleine Script von Cae hier:
http://debianforum.de/forum/viewtopic.p ... 78#p942453
dirk11 hat geschrieben: Im übrigen darf man sich nicht irritieren lassen und muss eventuell sogar mehrfach ganz neu ansetzen. Bei mir hat das Erstellen der crypt-devices schon nicht mehr funktioniert, nachdem ich mir die Partitionierung der Platte im Installer nur nochmal angesehen hatte (also nicht weiter angerührt). Danach wollte der Installer die Partitionstabelle für die zweite Platte (nur die habe ich mir nochmal genauer angeschaut) neu schreiben und das hat dem crypt-Kram nicht gefallen. So ganz perfekt ist der Installer nicht.
Sicherlich ist der nicht "perfekt" ... aber wenn man mal die Mailingliste verfolgt, wieviele wenns und abers die da abdecken müssen, dann macht er seine Sache schon recht gut. Aber man muss erst mal ein Gefühl für seine Logik bekommen, da hast du recht.
dirk11 hat geschrieben:Das habe ich nur kurz angetestet: grub-install /dev/sdb, dann sda abgezogen, grub hat auch von sdb gebootet. Das habe ich dann hart unterbrochen und die Kiste abgeschaltet, weil ich weiterkommen wollte.
Fein, das hat mich auch interessiert, ob der Installer das jetzt richtig macht. Bei Squeeze gab's da noch ein paar Macken.
Ja, das sollte als Test reichen ... sobald der Kernel bootet und das Raid läuft, gibt es ja keinen Unterschied mehr zwischen den Platten.
dirk11 hat geschrieben:wenn ich nicht dieses derive_decrypted verwenden möchte (wegen suspend_to_disk), sondern einfach nur das swap automatisch decrypted haben möchte.
"decrypt_derived" macht einfach folgendes: Es bildet aus dem _entschlüsselten_ Header deiner "/"-Partition ein neues Passwort.
Ob du deine Swap-Partition nun mit dem von decrypt_derived gebildeten Passwort oder mit einem Passwort aus einer Datei auf deiner Platte verschlüsselst, ist für die Funktion von Suspend-to-disk völlig egal - es kommt auf's selbe raus.
Der Vorteil von decrypt_derived ist einfach, dass du keine Passwort-Datei im Dateissystem hast und auch kein Passwort vergessen haben kannst, falls diese Datei mal versehentlich gelöscht oder geändert wird.

Suspend-to-disk funktioniert so oder so.

(genauer gesagt weiß ich nicht genau, ob Suspend-to-disk dann gleich funktionieren wird. Eventuell musst du es noch in einer Config-Datei aktivieren - ich hab die Details gerade nicht im Kopf)
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 10.07.2013 23:43:54

NAB hat geschrieben:
dirk11 hat geschrieben:aber dabei ist das "große" md schon wieder out-of-sync. Keine Ahnung wieso.
Direkt nach der Installation? Das ist aber merkwürdig.
Vielleicht nicht "schon wieder", sondern "immer noch". Ich bin mir nicht sicher, aber 3TB sind viel im Vergleich zu den anderen Partitionen. Vielleicht war das _initial_ ja bei allen so, und bei den anderen habe ich es nur nicht mitgekriegt. Fehlermeldung in dmesg gibts jedenfalls keine, die Kiste schnurrt bis jetzt wie mein Kater - nur leiser ;)
Ausgesprochen gut gefällt mir übrigens das kleine Script von Cae hier:
http://debianforum.de/forum/viewtopic.p ... 78#p942453
Das awk-script? Eine .bash_login gibt's hier nicht, ich nehme mal an einfach erstellen.
NACHTRAG: geht nicht, wenn ich die erstellt habe, wird scheinbar danach weder .profile noch .bashrc eingelesen. Und nun?
Suspend-to-disk funktioniert so oder so.
Gut. Aber decrypt_derived funktioniert offensichtlich nicht so, wie ich mir das vorstelle. Ich bin nach der Ubuntu-Anleitung vorgegangen. Es hat mich erstmal geraume Zeit gekostet, das <Name_des_Ursprungsgeräts> das device md5_crypt ist, während an späterer Stelle <Gerät> /dev/md3 meint. Und etwas weniger Zeit hat mich gekostet, dass das swap dazu off sein muss. Es scheint auch zu funktionieren, aber beim Booten gibt es Fehlermeldungen, die muss ich jetzt leider abtippen, weil sie so früh kommen, dass sie nichtmal in /var/log/boot stehen:

Enter passphrase:
cryptsetup: md5_crypt set up successfully
/lib/cryptsetup/scripts/decrypt_derived: 28: /lib/cryptsetup/scripts/decrypt_derived: grep: not found
/lib/cryptsetup/scripts/decrypt_derived: failed to find md5_crypt in dmtable
cryptsetup: cryptsetup failed, bad password or options?
lib/cryptsetup/scripts/decrypt_derived: 28: /lib/cryptsetup/scripts/decrypt_derived: grep: not found
/lib/cryptsetup/scripts/decrypt_derived: failed to find md5_crypt in dmtable
cryptsetup: cryptsetup failed, bad password or options?
lib/cryptsetup/scripts/decrypt_derived: 28: /lib/cryptsetup/scripts/decrypt_derived: grep: not found
/lib/cryptsetup/scripts/decrypt_derived: failed to find md5_crypt in dmtable
cryptsetup: cryptsetup failed, bad password or options?
lib/cryptsetup/scripts/decrypt_derived: 28: /lib/cryptsetup/scripts/decrypt_derived: grep: not found
/lib/cryptsetup/scripts/decrypt_derived: failed to find md5_crypt in dmtable
cryptsetup: cryptsetup failed, bad password or options?
INIT Version 2.88

Irgendwann wird weitergebootet, aber mehr kann ich nicht mehr sichtbar machen.


Woran kann das liegen? Braucht das Teil irgendwas in der initramfs, was fehlt? Busybox oder sowas?

Nachtrag: jupp, busybox wird benötigt. Nachinstalliert, geht fehlerfrei!

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von NAB » 11.07.2013 00:27:47

dirk11 hat geschrieben:Ich bin mir nicht sicher, aber 3TB sind viel im Vergleich zu den anderen Partitionen. Vielleicht war das _initial_ ja bei allen so, und bei den anderen habe ich es nur nicht mitgekriegt.
*stirnpatsch* ... doch, ja klar ... bei einer Neuinstallation wird das Raid ja neu aufgesetzt, und da du vermutlich auf das Überschreiben mit Zufallszahlen verzichtet hast, ist er dann mit seinem Sync auch noch nicht fertig.

Aber falls er aus einem unerfindlichen Grund plötzlich mal mit einem resync anfängt, guck ins dmesg.
dirk11 hat geschrieben:Es hat mich erstmal geraume Zeit gekostet, das <Name_des_Ursprungsgeräts> das device md5_crypt ist, während an späterer Stelle <Gerät> /dev/md3 meint. Und etwas weniger Zeit hat mich gekostet, dass das swap dazu off sein muss.
Stimmt ... der Code-Schnippsel bei Ubuntu ist recht schlecht kommentiert und dazu etwas "übervorsichtig" gehalten, weil sie vorher noch eine Ramdisk anlegen, in der der Schlüssel abgelegt wird, bevor er an "luksAddKey" verfüttert wird.

Durch das "AddKey" wird übrigens ein zweites Passwort hinzugefügt. Dein altes Passwort ist immer noch gültig. (Du könntest dein altes Passwort auch löschen, dann würde nur das neue funktionieren, aber warum solltest du)

Dass luksAddKey nur dann funktioniert, wenn das Gerät nicht entschlüsselt ist, wusste ich auch noch nicht ... sorry. In der manpage steht auch nichts davon.
dirk11 hat geschrieben:/lib/cryptsetup/scripts/decrypt_derived: 28: /lib/cryptsetup/scripts/decrypt_derived: grep: not found
/lib/cryptsetup/scripts/decrypt_derived: failed to find md5_crypt in dmtable
Sorry, das sagt mir gar nix .. außer, dass das Script offensichtlich "grep" in der initramfs vermisst.

Hast du danach ein "update-initramfs -u -k all " gemacht?
dirk11 hat geschrieben:Nachtrag: jupp, busybox wird benötigt. Nachinstalliert, geht fehlerfrei!
holla ... das wundert mich nun! Ich wüsste nicht, wozu dieses Script ne busybox braucht. Aber egal ... hauptsache es geht.

Aber wenn du schon dabei bist ... du kannst dein Passwort auch über's Netzwerk eingeben:
http://debianforum.de/forum/viewtopic.php?f=27&t=143593

Und vielleicht willst du dir von mdadm ne Mail schicken lassen, wenn eine Platte ausgefallen ist:
/etc/mdadm/mdadm.conf

Ein paar Geschwindigkeitstests der Festplatten mit Verschlüsselung können auch nicht schaden. Und dabei ein Blick auf die Temperaturen.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 11.07.2013 01:44:11

NAB hat geschrieben:Dass luksAddKey nur dann funktioniert, wenn das Gerät nicht entschlüsselt ist, wusste ich auch noch nicht ... sorry. In der manpage steht auch nichts davon.
Ups. Das hoffe ich mal nicht, dann könnte ich ja nur von einem USB-stick gebootet ein PW hinzufügen. Das wird kompliziert, im Moment noch keine Ahnung, wie das geht. Aber ebenso wie mit der Eingabe via Netzwerk...
Aber wenn du schon dabei bist ... du kannst dein Passwort auch über's Netzwerk eingeben:
http://debianforum.de/forum/viewtopic.php?f=27&t=143593
Danke, kümmere ich mich später drum. Auf der Prioritätenliste steht jetzt erstmal die Übernahme der Installation vom alten Server inkl. Sichtung, was weg kann.
Und vielleicht willst du dir von mdadm ne Mail schicken lassen, wenn eine Platte ausgefallen ist:
/etc/mdadm/mdadm.conf
Danke für den Hinweis, aber das machte schon der alte Server.
Ein paar Geschwindigkeitstests der Festplatten mit Verschlüsselung können auch nicht schaden. Und dabei ein Blick auf die Temperaturen.
Geschwindigkeit kommt irgendwann, die Platten werden momentan nur zwischen 35 und 37° warm. Fast zehn Grad kühler als die Platten im alten Server.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von NAB » 11.07.2013 06:05:23

dirk11 hat geschrieben:
NAB hat geschrieben:Dass luksAddKey nur dann funktioniert, wenn das Gerät nicht entschlüsselt ist, wusste ich auch noch nicht ... sorry. In der manpage steht auch nichts davon.
Ups. Das hoffe ich mal nicht, dann könnte ich ja nur von einem USB-stick gebootet ein PW hinzufügen. Das wird kompliziert, im Moment noch keine Ahnung, wie das geht.
Eh ... ich weiß nicht, was du da falsch verstanden hast, aber da gibt es absolut kein Problem. Der einzige Grund (für dich), einen Schlüssel hinzuzufügen, ist das decrypt_derived, und das betrifft nur Swap und ganz sicher nicht deine Root-Partition.

Wobei das auch nicht angehen kann, was ich da geschrieben habe ... du hast ja nur das Swap ausgeschaltet, und nicht den Crypt-Container geschlossen (glaub ich). Neee, mach dir da keine Gedanken, da hast du was in den falschen Hals gekriegt.
dirk11 hat geschrieben:Geschwindigkeit kommt irgendwann, die Platten werden momentan nur zwischen 35 und 37° warm. Fast zehn Grad kühler als die Platten im alten Server.
Könnte das an den fehlenden Gehäuseseiten liegen? ;-)
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 11.07.2013 13:04:13

NAB hat geschrieben:
dirk11 hat geschrieben:
NAB hat geschrieben:Dass luksAddKey nur dann funktioniert, wenn das Gerät nicht entschlüsselt ist, wusste ich auch noch nicht ... sorry. In der manpage steht auch nichts davon.
Ups. Das hoffe ich mal nicht, dann könnte ich ja nur von einem USB-stick gebootet ein PW hinzufügen. Das wird kompliziert, im Moment noch keine Ahnung, wie das geht.
Eh ... ich weiß nicht, was du da falsch verstanden hast, aber da gibt es absolut kein Problem. Der einzige Grund (für dich), einen Schlüssel hinzuzufügen, ist das decrypt_derived, und das betrifft nur Swap und ganz sicher nicht deine Root-Partition.
Deine Aussage klang allgemeingültig und nicht nur auf das swap bezogen. Ich meinte das Problem dahingehend betrachtet, dass ich vielleicht mal einen zweiten Key für eine vertrauenswürdige Person (Eltern z.B.) bei meiner Haupt-Partition mit / hinzufügen will. Auch bin ich momentan sehr an dieser Sache interessiert, nur fangen in meinen USB-Sticks die Partitionene alle bei 1 an - ich habe gar keinen Platz für diese Idee :(
du hast ja nur das Swap ausgeschaltet, und nicht den Crypt-Container geschlossen
Exactamente.
(glaub ich). Neee, mach dir da keine Gedanken, da hast du was in den falschen Hals gekriegt.
Könnte das an den fehlenden Gehäuseseiten liegen? ;-)
Eh, nööö. Das ist ein vom Aufbau her ziemlich geiler Rechner auf BTX-Basis (also quasi falschrum): der hat auf der Öffnungsseite so eine Art Tür, in welcher zwei Einschübe sind, in denen Festplatten übereinander Platz haben. Platten eingeschoben, Kiste zu, Deckel drauf, fertig. Ich habe nur keinerlei Ahnung, wie warm der Prozessor wird, lm-sensors behauptet was von -49° Core-Temp, das kann nicht sein. Das ärgert mich auch ein wenig, aber um solche Feinheiten kann ich mich immer noch kümmern, wenn die Kiste an ihrem endgültigen Standort steht und den derzeitigen Server ersetzt hat.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von NAB » 11.07.2013 18:02:43

dirk11 hat geschrieben:Deine Aussage klang allgemeingültig und nicht nur auf das swap bezogen.
Meine Aussage bezog sich vorallem auf deine Aussage, dass du das Swap vor dem luksAddKey ausschalten musstest.

Ich wüsste keinen technischen Grund, warum das so sein sollte. Ich mag's aber auch nicht ausprobieren.
dirk11 hat geschrieben: Ich meinte das Problem dahingehend betrachtet, dass ich vielleicht mal einen zweiten Key für eine vertrauenswürdige Person (Eltern z.B.) bei meiner Haupt-Partition mit / hinzufügen will.
Okay, das ist neu.
Möglichkeit 1: Du sagst deinen Eltern DAS Passwort (evtl. auf einem USB-Stick). Wenn sie dein Vertrauen verlieren, kannst du immer noch ein zweites Passwort setzen und das erste Passwort löschen.
Möglichkeit 2: luksAddKey geht vielleicht doch bei entschlüsseltem Container.
Möglichkeit 3: Du bootest mit einem anderen System. Das muss dann mdadm und cryptsetup enthalten. Die Arrays sollten sich von selber zusammensetzen. Tja, und dann kannst du auch schon mit cryptsetup luksAddKey /dev/mdX loslegen.
dirk11 hat geschrieben: Auch bin ich momentan sehr an dieser Sache interessiert, nur fangen in meinen USB-Sticks die Partitionene alle bei 1 an - ich habe gar keinen Platz für diese Idee :(
Ich halte von diesem Ansatz absolut nichts.
Der "Finder" eines solchen USB-Sticks wird genau so wenig "Verdacht" schöpfen wie der Finder eines USB-Sticks, auf dem sich die Datei "secrets of my life.mp3" finden lässt (vorausgesetzt, es handelt sich um eine abspielbare mp3-Datei). Für einen erfahrenen Kryptologen wären die sinnlosen Bytes vor dem Partitionsanfang vielleicht sogar schon verdachtsfördernd.

Und "findet" jemand neben dem USB-Stick auch deinen Rechner, so findet er in der unverschlüsselten initramfs eh eine genaue Anleitung, wie der Rechner zu entschlüsseln ist.

Ein Schlüssel ist ein Schlüssel, egal ob du auf den Schlüssel draufschreibst "ich bin nicht da", oder "ich bin kein Schlüssel".

Wenn du Diebstahl vorbeugen willst, häng dir den USB-Stick um den Hals oder kleb ihn mit Montagekleber an die Heizung, und schließ ihn mit einem Verlängerungskabel an. Wenn du volle Kontrolle haben willst, darf das Passwort eh nur in deinem Kopf existieren.
dirk11 hat geschrieben:Ich habe nur keinerlei Ahnung, wie warm der Prozessor wird, lm-sensors behauptet was von -49° Core-Temp, das kann nicht sein.
Tja ... willkommen bei AMD ...

Die einzige Möglichkeit, die ich kenne, aus den Core-Temps vernünftige Werte zu machen, ist es, den Prozessor zu überhitzen bis er sich abschaltet und derweil die Core-Temps zu notieren. Kurz vor dem Abschalten hat er dann die maximal zulässige Temperatur erreicht - die wiederum kannst du in den Datenblättern von AMD nachgucken. Damit kannst du dir die Differenz zwischen Core-Temp und realer Temperatur ausrechnen ... die Differenz ist bei jeder CPU anders.

Sonst schau, ob sensors-detect noch andere Sensoren findet ... die meisten Mainboard-Hersteller setzen noch einen Temperaturfühler unter den Prozessor.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 11.07.2013 19:41:09

NAB hat geschrieben:Wenn du volle Kontrolle haben willst, darf das Passwort eh nur in deinem Kopf existieren.
Korrekt, das sehe ich genauso. Auf meinem Laptop würde ich auch nichts anderes umsetzen, aber ein feststehender Rechner ist da etwas anders...
Sonst schau, ob sensors-detect noch andere Sensoren findet ... die meisten Mainboard-Hersteller setzen noch einen Temperaturfühler unter den Prozessor.
Scheinbar nicht, sensors-detect habe ich natürlich als erstes laufen lassen.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von NAB » 11.07.2013 23:54:24

dirk11 hat geschrieben:Scheinbar nicht, sensors-detect habe ich natürlich als erstes laufen lassen.
"scheinbar"? Schau mal genau hin ... da gibt's ein paar Hardware-Chips, die noch keinen ACPI-Treiber haben. "sensors-detect" findet die, aber "sensors" zeigt nix an, weil der alte Treiber nicht geladen wird. Stichwort für google: "acpi_enforce_resources=lax"
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 12.07.2013 13:04:33

Danke, schaue ich mir bei Gelegenheit an.

Habe gerade ein anderes Problem, wo ich keinen Fehler finde:
ich habe seit Ewigkeiten ein selbst erstelltes Script unter init.d stehen, welches u.a. in rcS.d ausgeführt wird. Auf dem alten Server (Squeeze) läuft das auch noch, auf dem neuen Server (Wheezy) wird es beim Start (also von rcS.d) einfach nicht ausgeführt. Es gibt auch keinerlei Fehlermeldung oder dergleichen, und wenn ich es danach händisch starte, klappt das problemlos.
Das script macht übrigens nichts weiter als iptables mit entsprechenden Parametern zu starten.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von NAB » 12.07.2013 20:22:54

Wie wäre es mit einem neuen Thread dazu? Hier unten liest das eh keiner mehr und mit "Grundsatzüberlegungen" und "Neuinstallation" hat das auch nix mehr zu tun.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 13.07.2013 18:22:31

Das stimmt, das Problem hat sich aber erledigt, man muss auch oben die .-Dateien beachten. Oder update-rc.d nehmen.

Vielen lieben Dank an alle, die hier so fleißig mitgedacht und -diskutiert haben, die Installation ist geglückt und läuft so weit! Ohne eure tatkräftige Hilfe hätte das nicht so einfach geklappt! :lol: :!: :hail: :THX:
Was jetzt noch an Problemen aussteht, ist so speziell, dass da vermutlich hier sowieso niemand mehr helfen kann - und wenn ich das anders sehe, mache ich dazu dann spezielle threads auf!

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 01.10.2013 00:42:45

Hierzu noch eine Frage: wenn ich z.B. vom USB-Stick gebootet das Filesystem checken will, wie gehe ich da vor?
Boote vom USB-Stick, terminal-window als root. Und dann?

Struktur auf Platte: root ist XFS in einem dmcrypt in einem RAID1 md-device.

dirk11
Beiträge: 2842
Registriert: 02.07.2013 11:47:01

Re: Grundsatzüberlegungen vor Neuinstallation

Beitrag von dirk11 » 03.10.2013 19:26:18

Zur Vervollständigung meine momentane Vorgehensweise:

1. grml z.B. von USB-Stick booten
2. mdadm-startall
3. cryptsetup luksOpen /dev/md5 md5_crypt
4. mount /dev/mapper/md5_crypt /mnt
5. umount /mnt
(6. xfs_check /dev/mapper/md5_crypt) # stürzt ab, kann an grml liegen.
7. xfs_repair -n /dev/mapper/md5_crypt
7a. xfs_repair /dev/mapper/md5_crypt
8. cryptsetup luksClose /dev/mapper/md5_crypt
9. mdadm -S /dev/md*
10. reboot

Hoffe ich habe dabei nichts übersehen.

Antworten