Kerberos schriebDas Problem wird weder durch cp -r noch durch cp -a oder durch cp -ar gelöst.
Pjotr schriebSicher? cp --help sagt zu -a und -r: [...] und bei mir funktioniert das Ordnerkopieren wunderbar mit -a...
Kerberos bezog sich hier mit Sicherheit auf die Fehlermeldung ("[ OK ] Reached target Graphical Interface" und Hänger) beim Booten, die eben auch das "korrekte" Wiederherstellen/Kopieren von /etc nicht beseitigte ;-)
Bei cp ist -a auf jedenfall besser als nur -R, wobei ich ad hoc nicht sagen kann ob nach extundelete die Timestamps noch ok sind (aber es spricht eigentlich nichts dagegen, da daß Teil ja auf FS-Ebene arbeitet).
Durch den "plötzlichen Tod" der HD hat sich das ja nun erledigt, ich hoffe du hast wenigstens deine Nutzdaten im Backup (und eine funktionierende Restore-Prozedur<g>). Trotzdem würde ich dir raten, zukünftig auch /etc mitzusichern (zumindest periodisch). /etc ist zwar mittlerweile recht "fett" geworden (im Gegensatz zu Früher[tm]), aber läßt sich nach wie vor optimal komprimieren. Man merkt erst schmerzlich wie viel "Arbeit" in /etc steckt wenn es mal nicht mehr vorhanden ist.
Zumindest ein cronjob, der periodisch /etc (und z.B. auch /var/lib/pacman/local/) sichert - und sei es auf das gleiche System/HD - ist allemal beruhigend.
rm hat ja nun keinen "Papierkorb" (wobei man sich das AFAIK einrichen kann) und was Gelöschtes aus dem Backup zu holen ist auf jedenfall zuverlässiger als z.B. per extundelete sich Inhalte auf "freien" Inodes zusammenscharren zu müssen - eben auch mit der Ungewissheit ob nun wirklich alle Daten wieder "da" sind bzw. diese integer sind. Backup/Restore und Datenrettung sind halt zwei unterschiedliche Paar Schuhe…
Wobei mich extundelete wirklich überzeugt hat, im Gegensatz zu manch anderem Tool von früher. Wenn das FS also noch intakt ist und das Blockdevice funktioniert, dann ist es auf jedenfall eine gute Waffe. Vor allem wenn es um sowas wie gelöschte Daten ginge, die eben noch nicht im Backup drin sind.