V0.4.1 rework#2
Conversation
|
@towo2099 Die Änderungen mit Bezug zu systemd erscheinen sinnvoll, das kann ich aber nicht genau beurteilen. ALLOW_GROUPS="users" hat den Sinn, dass der Benutzer snapper Aktionen ohne root-Rechte ausführen kann. Er kann das System (auch als root) mittels snapper Aktionen nicht zerstören. Das verhindert Btrfs. Der gesamte Rest baut viele Fehler (wieder) in das Paket ein. Was hat tuxedo da drin zu suchen? |
Tuxedo hat in den Files gar nichts zu suchen, das waren Überbleibsel aus meinen Umbau-Arbeiten für Tuxedo, ist gefixt.
modules/shellprozess: Das ist im Prinzip sogar falsch, weil modules/mount hat gesetzt, was in meinen Augen falsch ist, das snapper create-config sowohl das subvolume, als auch das verzeichnis anlegt.
Lässt Du mich wissen, welche? |
Tuxedo will da nichts übernehmen. Ich habe das Paket geforkt und für TUXEDO OS umgebaut. Wenn Du als Autor mir sagts, wir dürfen das micht benutzen, dann müssen wir das akzeptieren und uns etwas anderes einfallen lassen. Wenn wir es unter TUXEDO OS nur als siduction-btrfs einsetzen dürfen, dann kann ich das auch abklären. |
Das schaue ich mir genauer an. Das .snapshots Subvolumen einfach mounten zu können hat schon was für sich wenn mann in den Snapshots auf die Suche geht. Das Setup für die Konfig 'root' ist ohne natürlich einfacher.
Heute nicht mehr. Werden morgen ein paar Sachen aufzeigen. |
|
Betr. Tuxedo |
Also ich kann da ohne fstab Eintrag z.B. per Midnightcommander drin rumsuchen. |
| @@ -1,27 +1,17 @@ | |||
| siduction-btrfs (0.4.0-3) unstable; urgency=medium | |||
| siduction-btrfs (0.4.1-1-tux1) unstable; urgency=medium | |||
There was a problem hiding this comment.
Die neue Version gehört nach oben bzw. oberhalb 0.4.0-3 und dann als 0.4.1-0
und dort hinein deine Änderungen.
Die mit 0.4.0-3 und 0.4.0-2 getätigten Fehlerbereinigungen müssen in der Datei snapshot-description wieder eingepflegt werden.
There was a problem hiding this comment.
Beim changelog ist wohl beim kopieren etwas schief gegangen.
snapshot-description sollte wieder auf dem stand von main sein.
Wie das Git repo im Moment angelegt ist, ist halt wirklich suboptimal.
There was a problem hiding this comment.
Durch die chaotische repo-struktur hier, ist mir wohl eine falsche Version von snapshot-description hier herein geraten.
Zeile 3: Name mit dem neuen Verzeichnis.
Der Fehler kommt wenn kein Eintrag in der fstab steht systemd legt eine mount Unit an und mountet das Subvolumen auch immer wieder automatisch wenn es in der fstab steht. Wir sind also darauf angewiesen, dass ein fstab Eintrag besteht.
|
snapper create-config funktioniert nicht, wenn schon ein .snapshots subvolume existiert Dieses system wurde per Calamares installiert, wobei in Calamares kein Subvolumen für .snapshots angelegt wurde. Die gescriiptete snapper-config wurde nicht mehr in calamares gemacht. |
Das ist klar, geht auch aus meinem vorherigen Kommentar hervor.
Jetzt wäre mal von Interesse was Wie oben beschrieben funktioniert bei mir snapper ohne eingehangenes '.snapshots' nicht. |
|
findmnt ".snapshots" => nada Wenn initial mit diesem Paket installiert wird, sind das nested subvolumes, welche nicht explizit in der fstab stehen müssen. Der alte Calamares Code war deshalb auch so verwirrend, löschen von /.snapshots =>snapper create-config => loöschen von /.snapshots + subvol delete. Dein bestehendes sytem hat /.snapshots aber flat angelegt, dseshalb brauchts da den fstab eintrag. |
Ok, verstanden, und so sieht es bei mir aus (statt 'home' 'daten' ) Somit ist deine Variante bei der Installation einfacher. Bei den anderen Dateien habe ich diverse Kommentare und Fragen dazu geschrieben und kleinere Änderungen vorgenommen. Hat denn das "Scripts-Gedöns" etwas mit dem Bootfehler zu tun? |
Das glaube ich nicht, bzw, kann ich mir nicht vorstellen. |
Irgendwie bin ich zu doof für github, manchmal sehe ich die Kommentare, manchmal nicht. |
Habe da auch so meine Schwierigkeiten. |
Changes in version 0.4.
| abort-upgrade|abort-remove|abort-deconfigure) | ||
| ;; | ||
|
|
||
| exec $(systemctl enable --now siduction_btrfs.path) |
There was a problem hiding this comment.
Die systemd Unit müsste auch aktiviert werden. Sonst können keine Booteinträge erstellt werden.
There was a problem hiding this comment.
siduction_btrfs.path ist enabled, wenn man dieses Paket installiert, dafür sogt der Debhelper.
There was a problem hiding this comment.
Einzig, wenn man von 0.4.0 auf dieses Paket upgraden würde, ist das danach nicht anabled (auf Grund des alten codes).
There was a problem hiding this comment.
Wie wäre es mit diesen Code innerhalb 'configure)' um ein Upgrade von 0.4.0 sicher zu gestalten?
if [ "$(systemctl is-active siduction_btrfs.path)" = "inactive" ]; then
if [ "$(systemctl is-enabled siduction_btrfs.path)" = "disabled" ]; then
systemctl enable --now siduction_btrfs.path &>/dev/null
else
systemctl start siduction_btrfs.path
fi
fi
|
@towo2099 |
Lines removed because a file named `btrfs` is being used.
2 participants
Ich habe das Paket mal komplett überarbeitet.
Damit braucht man im Calamares das ganze Scripts-Gedöns nicht mehr machen, sondern dieses Paket konfiguuriert snapper so, wie von uns gewünscht.
Ich habe allerdings
ALLOW_GROUPS=""stattALLOW_GROUPS="users"gesetzt, weil letzteres eigentlich keine so dolle Idee istWas meint ihr dazu?