btrfs - Jedi-Ritter System - per script ein snapshot vor dem Update

[GI-Joe]

Das erklärt auch, warum mein Verzeichnis /@ leer ist.
Gewundert hatte ich mich darüber schon.

ja, kein Problem, brauchst Du später eh nicht mehr ....
siehe auch HIER --->Berichtigung: /@ wird doch immer noch gebraucht, da es das parent zu den Snapshots @TESTING, @STABLE und @OLDSTABLE ist.

Hab gerade keine Zeit, melde mich später .....

Installiert hatte ich das System mit einem anderen Video "Total Arch Linux | 2.3 Btrfs für Snapshots einrichten", https://www.youtube.com/watch?v=mho64LjLrsU , das ist für PC-Bios.

dann schau mal ab Teimcode 12:20 ....
umount und danach mount mit optionen

 

[xsid]

Guten Morgen Forum,

was haltet Ihr von dieser Lösung "btrfs - per script ein snapshot"?

Ist das eine professionelle Lösung oder hat Aussichten dahingehend?

Bin ich durch meinen Wunschgedanken doch etwas verblendet?
Welcher Admin hat Lust so etwas im professionellen Bereich zu Administrieren?

Wer hat hier die Lösung, außer GI-Joe nachgebaut?

Welche Vorteile hat hier die /dev/sda1 als /boot?
Warum meint Ihr wurde das so gewählt?
Um die Option zu haben auf ein zfs Filesystem umzustellen?

Für mich sieht das System zur Zeit nach hausgemachter Bastelfreaklösung aus, man kann zu viele Fehler einbauen. Das mounten in Subvolumes ist sehr fehleranfällig.

Der Youtuber übernimmt teilweise Snapper Konfigurationen.
Warum nicht gleich Snapper? Snapper ist richtig im Text dokumentiert.

@GI-Joe und Anwender
Wie kommt man bei so einem System schnellstmöglich an Admin, der das System nicht aufgesetzt hat in die chroot Umgebung?


MfG

xsid

 

[GI-Joe]

Das mounten in Subvolumes ist sehr fehleranfällig.

das ist völliger Quatch ! Wie kommst Du auf solch einen Humbug ? wenn die Einstäge in der fstab einmal richtig stimmen, wo soll es da denn mountprobleme geben ?

man kann zu viele Fehler einbauen.

Für Den, der unter Linux mit root-Rechten arbeitet und dabei nicht weiß, was er tut, für den trifft das sicher zu.
Abhilfe: man lernt durch Tips und Howtos, welche das Internet tonnenweise bietet, mit der Materie richtig umzugehen um das zu verstehen, was man tut und dann gibt es auch am Ende keine Fehler.

Und wer dazu keine Zeit und/oder Lust hat, der macht halt ein Ubuntu oder ein Mint drauf mit ext4 und gut is.

@GI-Joe und Anwender
Wie kommt man bei so einem System schnellstmöglich an Admin, der das System nicht aufgesetzt hat in die chroot Umgebung?

Schon mal ins Arch-WIKI geschaut ? Da steht doch alles haarklein drin ....

mit dem Installmedium booten, all seine Dateisysteme nach /mnt mounten, so, wie sie später im system sein sollen (also inkl. aller optionen, swap u.s.w.), dann denn Befehl arch-chroot
kannst alles im Arch-Wiki nachlesen.

 

[xsid]

mit dem Installmedium booten, all seine Dateisysteme nach /mnt mounten, so, wie sie später im system sein sollen (also inkl. aller optionen, swap u.s.w.), dann denn Befehl arch-chroot
kannst alles im Arch-Wiki nachlesen.

Wie sieht das aus mit den Subvolumes von btrfs?

Wie das im "normalen" System funktioniert weiß ich, nur bei diesem Spezialsystem ist es etwas kniffliger.

das ist völliger Quatch ! Wie kommst Du auf solch einen Humbug ? wenn die Einstäge in der fstab einmal richtig stimmen, wo soll es da denn mountprobleme geben ?

Dazu muss das System aber eingerichtet sein.

Hier scheint kein weiterer Anwender das System anzuwenden.
Da frage ich mich warum, weil wenn es funktioniert ist es gut.

Zum lernen ist es ideal geeignet und um sich mit btrfs auseinander zusetzen.

Diese System kann mit jedem Linux, dass btrfs unterstützt einsetzen, z. B. auch Debian Sid.

Welche Vorteile hat hier die /dev/sda1 als /boot?
Warum meint Ihr wurde das so gewählt?
Um die Option zu haben auf ein zfs Filesystem umzustellen?

Hat jemand darauf eine Antwort?

 

[GI-Joe]

Wie sieht das aus mit den Subvolumes von btrfs?

Wie das im "normalen" System funktioniert weiß ich, nur bei diesem Spezialsystem ist es etwas kniffliger.

ist alles hier - ab Timecode 12:30 beschieben - kannste 1:1 übernehmen ! Und ergänzende Erklärungen gibt es dazu auch noch gratis oberdrein. Einfach mal machen
und wenn Du keine Videos magst, dann schreibe es Dir einmal 1:1 ab und mache Dir ein Textfile oder gleich ein Install-Script daraus ...

Dazu muss das System aber eingerichtet sein.

Das ist wahr - ist aber bei JEDEM System so

 

[xsid]

Trotzdem weiß der EDV-Servicetechniker nicht wie so ein System aufgebaut, ein fremdes System!

 

[GI-Joe]

Welche Vorteile hat hier die /dev/sda1 als /boot?

In diesem Setup ist es ein MUSS, eine separate Boot-Partition zu haben, denn hier sind alle Kopiien (TESTING, STABLE, OLDSTABLE) von vmlinuz und initramfs abgelegt, die NICHT gesnapshottet(anders versioniert) werden dürfen, weil auf die einzelnen Versionen von vmlinuz und initramfs will man ja im Zweifelsfall beim Booten (Auswahl in Grub) drauf zugreifen.

- - - Beitrag zusammengeführt - - -

Trotzdem weiß der EDV-Servicetechniker nicht wie so ein System aufgebaut, ein fremdes System!

das interessiert MICH überhaupt nicht, weil ICH der Techniker bin und ich weiß, was ich tue.

Außerdem: ein guter EDV-Fuzzi kann die /etc/fstab und die /boot/grub/grub.cfg und die /etc/mtab (bzw. die Ausgabe von mount | grep '/dev/sd') lesen und daraus ALLES WEITERE ableiten
Einen schlechten EDV-Techniker sollte man eh nicht an seinen Rechner lassen

 

[xsid]

In diesem Setup ist es ein MUSS, eine separate Boot-Partition zu haben, denn hier sind alle Kopiien (TESTING, STABLE, OLDSTABLE) von vmlinuz und initramfs abgelegt, die NICHT gesnapshottet(anders versioniert) werden dürfen, weil auf die einzelnen Versionen von vmlinuz und initramfs will man ja im Zweifelsfall beim Booten (Auswahl in Grub) drauf zugreifen.

Grub kann doch auch auf btrfs Systeme zugreifen, ich verstehe das nicht.
Kann man nicht ein Subvolume /@boot erstellen und dann auf /dev/sda1 verzichten?

 

[GI-Joe]

Kann man nicht ein Subvolume /@boot erstellen und dann auf /dev/sda1 verzichten?

ja, könnte man auch, der Aufwand wäre aber nicht weniger, da wiederum im grub diverse boot-optionen geändert werden müssen.
würde aber funzen denke ich ....
MICH stört eine separate boot-partition nicht, im laufenden Betrieb ist nachher davon eh nix mehr zu merken ....

 

[xsid]

Nach meinem Verständnis nutzt Du dadurch die Vorteile von btrfs nicht vollständig aus.

/dev/sda1 ## btrfs
/dev/sda2 ## swap

Mehr Partitionen braucht es vermutlich nicht.
Subvolumen kann man wie benzüglich des Mountes wie Partitionen behandeln.

Der Youtuber ist ein Freak.

 

[GI-Joe]

Du versuchst immer wieder Probleme zu lösen, die gar Keine sind.
Gehe mal in Dich und frage Dich, was eigentlich Dein Ziel ist !
Dein System so zum Laufen zu bringen ?
Dabei zu lernen aka "learning by doing" ?
Ein Wiki darüber und mit allen eventuellen Fallstricken zu schreiben ?
Oder gar alles zusammen.

Wenn Dein Ziel fest steht, solltest Du erstmal auch nur das fokussieren - sonst trittst Du immer auf der Stelle und bist am Ende gefrustet.

 

[xsid]

Das System will ich verstehen und ein optimales System.

Da sind noch viele Fragen offen.

Dein System so zum Laufen zu bringen ?
Dabei zu lernen aka "learning by doing" ?

Das ist Basteln ohne Struktur, genauso wie in der /boot/grub/grub.cfg editieren.

#
# DO NOT EDIT THIS FILE
#

 

[GI-Joe]

Nach meinem Verständnis nutzt Du dadurch die Vorteile von btrfs nicht vollständig aus.

/dev/sda1 ## btrfs
/dev/sda2 ## swap

Es gibt keine Vorteile, die /boot-Partition auf BTRFS zu formatieren bzw. als Subvolume laufen zu lassen.
Kannst Du aber so machen, das ist ja das schöne an Linux - jeder hat maximale Freiheiten.

 

[xsid]

Ich möchte auf /dev/sda1 /boot verzichten und ein Subvolume /@boot dafür nutzen.

Maximale Freiheiten möchte ich nicht, ich möchte reproduzierbare Systeme, die jeder administrieren kann. Bastellösungen geben später meist immer Probleme, die kaum oder nur mit erheblichen Stundenaufwand zu lösen sind.

Ich frage mich warum Red Hat sich von btrfs zurückgezogen hat.

- - - Beitrag zusammengeführt - - -

Total Arch Linux | 2.3 Btrfs für Snapshots einrichten

https://www.youtube.com/watch?v=mho64LjLrsU

Wo finde ich das Nachfolgevideo für PC-Bios?
Der Youtuber verweist ganz zum Schluss darauf.

Das wird wohl gemeint sein:

Total Arch Linux | 3. Installation des Basissystems

https://www.youtube.com/watch?v=Cr0UVudxko0

"per script ein snapshot" wird in der Serie "Total Arch Linux" nicht behandelt oder ich finde es nicht.

Müssen die Serien gemischt werden, "Total Arch Linux" und "Arch My Way"?

Arch My Way 3 | Snapshot und Rollback (Deutsch)

https://www.youtube.com/watch?v=J9jaVH9DjTU

 

[GI-Joe]

Da sind noch viele Fragen offen.

fast alle Fragen wurden hier und in den Videos schon geklärt.
Ich verweise immer wieder darauf.

Mein Tipp an Dich:
Fange nochmal von vorn an und nimm diesen Leitfaden für das Ganze !

Leitfaden für die Installation unter einem Standard-BIOS-System ohne UEFI

Festplatte leer machen
mit dem ArchInstallMedium booten
Festplatte partitionieren (auch swap !)
Festplatte formatieren (auch swap !)
btrfs ohne Mountoptionen unter /mnt mounten
btrfs subvolumes anlegen
/mnt unmounten (!!)
@ - subvolume mounten mit den richtigen btrfs-optionen mounten (subvol=... ssd?? compress=lzo ??) hier bitte die richtigen Entscheidungen treffen !!!
alle Verzeichnisse (mountpoints) anlegen
alle subvolumes mit den richtigen btrfs-optionen mounten (subvol=... ssd?? compress=lzo ??) hier bitte die richtigen Entscheidungen treffen !!!
fstab generieren (genfstab - siehe Archwiki)
/mnt/etc/fstab editieren (optimieren - siehe hier)
in die chroot-umgebung wechseln (mit arch-chroot - Archwiki)
archlinux installieren (siehe Archwiki)
grub installieren (siehe Archwiki)
eine /boot/grub/grub.cfg erzeugen mit grub-mkconfig (siehe Archwiki)
eine /boot/grub/grub.cfg.old erzeugen mit cp
nicht neustarten, einfach alle Apps und dienstprogramme installieren - auch btrfs-progs (siehe Archwiki)
am ende exit, cd / , umount /dev/sda1 , reboot
nach dem neustart die / - snapshots für TESTING, STABLE und OLDSTABLE anlegen
dann die Kopien (STABLE, OLDSTABLE) von vmlinuz und initramfs in /boot erzeugen
dann erstmal die /boot/grub/grub.cfg bearbeiten mit den erforderlichen Menüs/Werten - diese grub.cfg könnte dabei hilfreich sein

Wenn dann irgendwann alles korrekt bootet (also mit subvolume @TESTING gebootet wurde), kannst Du dich an eine /etc/grub.d/40_custom machen nach diesem Schema - kann so übernommen werden, nur die UUIDs von /boot und / müssen angepasst werden

das wars schon.

Dann später einfach nur das Updatescript von mir benutzen, welches vor dem Update Snapshots macht/rotiert und die /boot - files rotiert.

Und falls ein Rollback nötig ist, dann einfach - je nachdem - eines dieser Scripte benutzen:
rollback_stable_nach_testing.sh
rollback_oldstable_nach_stable_und_testing.sh

Vieles davon ist bei Archlinux eh Handarbeit - is halt so bei Arch, dafür hab ich aber ein stabiles RollingRelease was ich problemlos als Produktivsystem einsetzen kann ....

Zielführend war für mich die Vorgehensweise von Nick in seinen Videos "Arch my Way" hier ab Timecode 2:15

 

[xsid]

Warum die /etc/grub.d/41_custom?

Hast Du dich vertan, ist es nicht die 40_custom?

Wie wird eigentlich die /dev/sda mit /boot gesichert?

KLICK! ab Timecode 20:10

Ok, die Serien werden gemischt, man muss sich alle Videos anschauen, das gibt Klicks.
Gleichzeitig kann mir jedesmals nochmals ansehen wie toll der Youtuber ist.

Technische Probleme habe ich nicht mehr, nachmachen kann ich.
Youtube kann ich inzwischen auch auf die HDD Downloaden und anschauen.

Danke für das Script, das kommt aber, ganz, ganz zum Schluss.

 

[GI-Joe]

Warum die /etc/grub.d/41_custom?

Hast Du dich vertan, ist es nicht die 40_custom?

ja, hab mich vertan - und geändert , genau so wie ich noch etwas ganz unten im Posting hinzu gefügt hab bzgl meines Scriptes ...

 

[xsid]

Hättest Du nicht mal Lust deine, die Lösung im Arch Wiki zu präsentieren?

Leider habe ich zu viele Wissenslücken.

 

[GI-Joe]

Danke für das Script, das kommt aber, ganz, ganz zum Schluss.

genau, erst mal muss dein system am ende sauber booten, und zwar von TESTING, STABLE und OLDSTABLE.

Falls das noch nicht der Fall ist, AUF KEINEN FALL über das Script updaten, das bringt Dir alles durcheinander !
Wenn Dein System allerdings sich sauber über TESTIN, STABLE und OLDSTABLE booten lässt, hast Du gewonnen und du kannst beim Update über das Script ganz entspannt sein, selbst falls es zu Fehlern beim Update kommt, denn Du hast immer noch STABLE, mit dem Du booten kannst. Und im Zweifelsfalle auch noch OLDSTABLE.

Merke: Dein Prodiktivsystem und auch das System, mit dem Du updatest ist TESTING !
STABLE und OLDSTABLE sind zwar vollwertige Systeme, aber praktisch nur für den Notfall gedacht !

- - - Beitrag zusammengeführt - - -

Hättest Du nicht mal Lust deine, die Lösung im Arch Wiki zu präsentieren?

Nein, weder Lust noch Zeit !

Leider habe ich zu viele Wissenslücken.

Gehe bitte jeden Schritt des Leitfadens von Posting #95 durch und finde für Dich heraus, bei welchem Schritt ganz konkret es bei Dir stockt.
Am besten während der Installation.
Suche dann konkret für diesen Schritt eine Lösung, bevor Du mit dem nächsten Schritt weiter machst - Du lernst daduch nur dazu !
Und Du wirst sehen, das hier schon fast alle Schritte erklärt wurden.

Falls Du nicht weiterkommst, informiere Dich, poste eine konkrete Frage hier und warte auf eine Antwort daruf.
Pausiere im Zweifelsfalle solange Deine Installation.

 

[xsid]

TESTING, STABLE und OLDSTABLE.


Was ist eigentlich mit dem /@ dem root-System?

In ./snapshots/TESTING, ./snapshots/STABLE und ./snapshots/OLDSTABLE, werden nur die Änderungen gespeichert?