Rettungsinstallation auf USB-Stick

[smutbert]

Hab gerade die Art und Weise verewigt, auf die ich ein System für den Notfall auf USB-Stick installiere

Ein Notfallsystem auf einem USB-Stick installieren

Hinweise oder Korrekturen werden freudig entgegengenommen.
edit: Besonders interessant wäre ob der Stick auf 32-Bit UEFIs tatsächlich korrekt bootet - das konnte ich bis jetzt nicht testen.

Ich hab beim Kopieren vom Texteditor ins Wiki irrsinnige Schwierigkeiten mit den Zeilenumbrüchen gehabt - die sind beim Klicken auf Vorschau immer verschwunden und wenn ich sie vorher korrigieren wollte sind wie aus dem Nichts überzählige Leerzeichen erschienen. Auch zu diesem Problem werden Hinweise dankend entgegengenommen ☺

[MSfree]

btrfs auf einem Rescue-Stick? Warum?

[smutbert]

warum nicht?

Mir taugt btrfs und ich bilde mir ein, dass eine Installation auf einem USB-Stick mit btrfs mit aktivierter Kompression sogar (leicht) spürbar schneller ist, als mit einem 0815-Dateisystem ohne Kompression. Außerdem habe ich mit xfs und ext4 schon Dateisystemfehler auf USB-Sticks gehabt (ev. wegen der "Lahmheit"?) und mit btrfs hatte ich (auf denselben Sticks) noch keine derartigen Probleme.

[smutbert]

Einen Fehler hab ich selbst entdeckt.
Bei meinen Installationen setze ich für gewöhnlich die debconf-Priorität auf low, aber im Artikel wollte ich das nur für einen Befehl

Code: Alles auswählen

# apt -o Dpkg::Options::="--priority=low" install grub-pc

Das funktioniert aber nicht weil "--priority=low" eine Option von dpkg-reconfigure und nicht von dpkg ist. Kann mir jemand auf die Sprünge helfen wie man die deconf-Priorität für einen apt-Aufruf festlegen kann?

[rendegast]

edit: Besonders interessant wäre ob der Stick auf 32-Bit UEFIs tatsächlich korrekt bootet - das konnte ich bis jetzt nicht testen.

https://github.com/BlankOn/ovmf-blobs
Das bios32.bin.
Da das ein NSA-blob sein könnte, vielleicht eher dem README nach entsprechend erstellen
'git ....' (tianocore ist die Projektseite von ovmf)
'... -a IA32 ...'

[smutbert]

Ah, danke, der Test folgt noch.

Bei der Suche nach einer Möglichkeit die debconf-Priorität einmalig zu setzen, habe ich die Variable DEBIAN_PRIORITY gefunden und

Code: Alles auswählen

# DEBIAN_PRIORITY=low apt install grub-pc

sollte das machen, was ich will.

[matthiasklein]

Hallo smutbert,

Du hast in einem anderen Thread (viewtopic.php?t=179899) geschrieben, dass an der Anleitung noch das eine oder andere zu verbessern/zu ergänzen ist.

Ich würde das Ganze gerne mal mit Buster oder noch lieber mit Bullseye durchspielen, habe debootstrap aber bisher noch nie verwendet.
Auf was muss ich denn achten, bzw. was meintest Du mit verbessern / ergänzen?

Viele Grüße,
Matthias

[smutbert]

Als erstes wollte ich dem Artikel einen anderen Namen geben, weil das nun einmal nicht nur als Rettungssystem nützlich ist ☺

Ein weiterer Punkt betrifft die Partitionierung: Zum Booten auf Systemen mit BIOS bzw. im BIOS-/Legacy-Mode auf UEFI-Systemen, lege ich eine 100 MB große BIOS Boot Partition an – es macht meines Wissens zwar nichts, wenn die Partition größer als notwendig ist, aber nachdem die Partition ja nur als Ersatz für einen kleinen freien Speicherbereich von mbr/msdos-partitionierten Datenträgern dienen soll, würde ich mich an der Stelle auf die übliche 1 MB große Partition beschränken.

Nachdem das Booten auf Systemen mit 32-Bit-uefi oder BIOS immer mehr aus der Mode kommt, überlege ich überhaupt, ob ich darauf im Artikel nicht verzichten könnte – das würde die Anleitung doch erheblich verkürzen.

Dann würde ich natürlich stretch durch buster (oder gar schon bullseye) ersetzen und schließlich will ich am Ende vielleicht noch eine paar Hinweise einbauen welche Pakete man installieren könnte um zu einem schlanken Gnome Desktop zu kommen – das muss ich allerdings selbst erst ausprobieren.


Würde dir das Booten auf Hardware mit 64-bittigem uefi ausreichen?

[Lord_Carlos]

Hab gerade die Art und Weise verewigt, auf die ich ein System für den Notfall auf USB-Stick installiere

Welchen Anwendungsfall oder Vorteil hat es gegenueber einer offiziellen live image?

[matthiasklein]

Welchen Anwendungsfall oder Vorteil hat es gegenueber einer offiziellen live image?

Mit persönlich geht es nicht um eine Art Live bzw. Rettungssystem sondern um eine minimale bzw. händische Installation über debootstrap.
Zuerst auf einem X86 System, um es mal in "einfach" gesehen zu haben, um es anschließend per Multiarch & QEMU auf einem X86 System für ein ARM System zu versuchen.

Würde dir das Booten auf Hardware mit 64-bittigem uefi ausreichen?

Ich könnte mit der Einschränkung leben.
Obwohl der uralte Rechner den ich für den ersten Test verwenden wollte, ein BIOS System ohne UEFI ist. VMware VM's verwenden in Standard auch BIOS.
Aber wie gesagt, ich kann auch ein 64 bit UEFI System verwenden ...

[smutbert]

Welchen Anwendungsfall oder Vorteil hat es gegenueber einer offiziellen live image?

Der Anwendungsfall ist bei mir eine Art Reserveinstallation, auf der ich mich einigermaßen zu Hause fühle und bei einer „normalen“ Installation lässt sich Software wie gewohnt nachinstallieren und es lässt sich alles ohne weiteren Aufwand wunschgemäß anpassen, auch bei der grub-Konfiguration/Installation, Kernel und initrd.

Bei einem Live-System dagegen weiß ich nie auf Anhieb wie man es schafft Änderungen dauerhaft zu speichern und selbst wenn das erledigt ist, meine ich sind Änderungen an Kernel und initrd mindestens unübersichtlich (wenn überhaupt möglich) und ohne es je gemessen zu haben, kommt mir vor, dass dieses zweigeteilte Dateisytem (Image und getrennt davon die Änderungen) speziell auf USB-Sticks spürbar langsamer ist als ein nicht-Live-System.

Welchen Vorteil hätte den ein Live-Image?

Würde dir das Booten auf Hardware mit 64-bittigem uefi ausreichen?

Ich könnte mit der Einschränkung leben.
Obwohl der uralte Rechner den ich für den ersten Test verwenden wollte, ein BIOS System ohne UEFI ist. VMware VM's verwenden in Standard auch BIOS.
Aber wie gesagt, ich kann auch ein 64 bit UEFI System verwenden ...

Ok, ich werde mich bemühen das ganze in naher Zukunft durchzuspielen und entweder hier posten oder den Wiki-Artikel anpassen – wie gehabt mit allen Bootmöglichkeiten.

[matthiasklein]

Ok, ich werde mich bemühen das ganze in naher Zukunft durchzuspielen und entweder hier posten oder den Wiki-Artikel anpassen – wie gehabt mit allen Bootmöglichkeiten.

Vielen Dank für die Mühe!
Wenn Du soweit bist, würde ich es in einer VMware VM und mit einem USB-Stick auf den mir zur Verfügung stehenden Rechnern testen...

[KP97]

Eine Ergänzung dazu von mir:
Ich habe vor längerer Zeit auf einem 32GB großen USB-Stick ein Debian Buster 64bit installiert mit der Netinstall incl. Firmware.
Diesen Stick habe ich mit gparted partitioniert, mit ext4 formatiert und mit dem Installer eine automatische Installation incl. Uefi ausgeführt. Erstmal eine Minimalinstallation ohne grafische Oberfläche. Das hat ohne Probleme funktioniert, anschließend habe ich Xfce als DE und die von mir gewünschten Programme nachinstalliert und eingerichtet.
Dieser Stick kann überall eingesetzt werden, auch auf Fremdrechnern, und dient u.a. für Backups und als Rettungssystem.
Da es ein Stable ist, halten sich die Updates in Grenzen, da ich auf einem Stick nicht so viele Schreibvorgänge ausführen will.
Wenn Bullseye stable wird, brauche ich nur ein full-upgrade machen und habe wieder ein funktionierendes Debian auf einem Stick.
Das hat den Vorteil - um @LordCarlos' Frage zu beantworten - dass ich damit mobil sein kann, ohne ein CD-Laufwerk haben zu müssen. Das ist ja mittlerweile auch nicht mehr überall vorhanden.

Vor einigen Monaten habe ich ein HP Elitebook 2170p für kleines Geld erstanden. Das hat kein Uefi, läuft aber tadellos.
Ich hatte nicht damit gerechnet, nochmal solche alte Hardware in die Finger zu kriegen, aber was solls. Ich habe einen weiteren USB-Stick vorbereitet, darauf ein Slax als Live-CD kopiert,
und habe nun auch für mein altes Schätzchen ein Backup -bzw. Rettungssystem. Mein Uefi-Stick funktioniert hier natürlich nicht, daher der zusätzliche Stick.
Slax basiert auf Debian, hat apt und das beste ist, diese Live-CD ist schon von Haus aus persistent. Man kann wie gewohnt Programme nachinstallieren und hat diese dann, ganz ohne weiteres Zutun, beim nächsten Start zur Verfügung.

Auf meinem Hauptsystem und auch auf dem alten Netbook läuft Sid, wie immer ohne Probleme.

Das habe ich geschrieben, um zu sagen, daß eine "normale" Installation auf einem Stick problemlos möglich ist, ganz ohne debootstrap.
Vielleicht braucht @smutbert gar nicht so viel ändern.

[smutbert]

Grundsätzlich müsste ich glaube ich gar nichts ändern, weil alles so funktionieren sollte, aber ich finde die Anleitung momentan auch etwas unübersichtlich. Jetzt habe ich jedenfalls eine SSD im USB-Gehäuse, auf der ich bullseye installieren will.
Ich schreib das jetzt für matthiasklein und mich auf, wenn ich später den Artikel ändern will.

Die externe SSD ist als /dev/sdb zugänglich und bei der Partitionierung fangen die Unterschiede schon an, so schaut die Partitoinierung aus

Code: Alles auswählen

# gdisk -l /dev/sdb
[...]
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4196351   2.0 GiB     EF00  EFI system partition
   2         4196352         4198399   1024.0 KiB  EF02  BIOS boot partition
   3         4198400       976773134   463.8 GiB   8300  Linux filesystem

und im Gegensatz zur bisherigen Anleitung werde ich die Partitions- und Dateisystemlabel ignorieren und mich nur nach den UUIDs richten.

Es folgt das Erstellen der Dateisysteme

Code: Alles auswählen

# mkfs.vfat -F 32 /dev/sdb1
# mkfs.btrfs /dev/sdb3

und das Mounten und vorbereiten für debootstrap

Code: Alles auswählen

# mkdir /mnt/tmp
# mount -o noatime,compress=zstd /dev/sdb3 /mnt/tmp
# btrfs subvolume create /mnt/tmp/debian
# umount /mnt/tmp
# mount -o noatime,compress=zstd,subvol=debian /dev/sdb3 /mnt/tmp

(dass Unmounten neuerliche gezielte Mounten des btrfs-subvolumes hilft später bei grub-Installation)


es folgt debootstrap, das werde ich hoffentlich bald nachreichen können – ich muss mir erst eine Paketliste zusammenstellen und werde diesen Beitrag weiter ergänzen...

...so sieht das aus:

Code: Alles auswählen

debootstrap --variant=minbase --include=linux-image-amd64,nano,systemd,rsync,btrfs-progs,debconf,adduser,whiptail --arch=amd64 bullseye /mnt/tmp

dann die Vorbereitungen und für chroot und chroot selbst, angefangen mit der Namensauflösung in der chroot-Umgebung bis zu den virtuellen Dateisystemen, die man braucht (die sources.list habe ich hier einfach aus dem laufenden System kopiert – die muss gegebenenfalls natürlich angepasst oder schlimmstenfalls neu geschrieben werden)

Code: Alles auswählen

# cat /etc/resolv.conf > /mnt/tmp/etc/resolv.conf
# cp /etc/apt/sources.list /mnt/tmp/etc/apt/
# mount -o bind /sys /mnt/tmp/sys
# mount -o bind /dev /mnt/tmp/dev
# mount -o bind /proc /mnt/tmp/proc
# mount -o bind /dev/pts /mnt/tmp/dev/pts

für die fstab brauchen wir die uuids

Code: Alles auswählen

# blkid /dev/sdb1 /dev/sdb3 

und tragen sie in ein (natürlich in die »/mnt/tmp/etc/fstab«)

Code: Alles auswählen

# /dev/sda3 als /-Dateisystem und /dev/sda1 als EFI System Partition, allerdings nicht unter /boot/efi
UUID=XZY	/		btrfs	noatime,compress=zstd	0	0
UUID=ABC	/mnt/efi	vfat	dmask=077,fmask=177,noauto	0	0

es folgt chroot

Code: Alles auswählen

# chroot /mnt/tmp /bin/bash

und in der chroot-Umgebung geht es weiter, aber dafür mach ich einen neuen Beitrag sonst wird mir das zu unübersichtlich

[smutbert]

Ab jetzt sind wir also in der chroot-Umgebung und los geht es mit dem mounten der EFI System Parition, die wir später für den Bootloader brauchen

Code: Alles auswählen

# mkdir /mnt/efi
# mount /mnt/efi

außerdem installieren wir ein paar Pakete

Code: Alles auswählen

# apt update
# apt install systemd-cron libpam-systemd network-manager apt-rdepends apt-show-versions arping arp-scan bash-completion bash-doc bc busybox bzip2 console-setup debootstrap debsums dosfstools efibootmgr eject ethtool file gddrescue gdisk groff hashdeep htop iftop info iotop keyboard-configuration less libnss-myhostname libpam-systemd locales lsof manpages mlocate netcat-traditional net-tools nfacct nmap openssh-client pciutils rfkill rzip screen sharutils strace tcpdump testdisk traceroute tree units unzip usbutils xz-utils zip

hardwarespezifische Pakete wie zB Firmwaredateien, etwa firmware-iwlwifi müssen natürlich auch installiert werden.
Für den Betrieb von Gnome genügt es zusätzlich diese Pakete zu installieren

Code: Alles auswählen

# apt install dconf-editor eog epiphany-browser evince file-roller gdm3 gedit gnome-calculator gnome-characters gnome-control-center gnome-disk-utility gnome-extra-icons gnome-font-viewer gnome-icon-theme gnome-screenshot gnome-session gnome-shell-extension-prefs gnome-system-monitor gnome-terminal gnome-themes-extra gnome-tweak-tool gstreamer1.0-libav libcanberra-pulse nautilus nautilus-extension-gnome-terminal network-manager-gnome policykit-1-gnome pulseaudio totem totem-plugins yelp

ich kopiere und aktiviere auch immer die systemd-unit, die unter /tmp ein tmpfs mountet

Code: Alles auswählen

# cp /usr/share/systemd/tmp.mount /etc/systemd/system
# systemctl enable tmp.mount

Damit sollte abgesehen vom Bootloader einmal ein Grundsystem installiert sein.


Beim Bootloader gehe ich insofern eigene Wege, als ich den Bootloader nicht von Debian automatisch installieren lassen und die Konfigurationsdatei selbst schreibe. Deswegen haben wir die EFI System Partition auch nicht wie üblich unter »/boot/efi« gemountet sondern unter »/mnt/efi«. Dort erstellen wir jetzt ein Verzeichnis für die grub-Installation
(noch immer alles in der chroot-Umgebung!)

Code: Alles auswählen

# mkdir /mnt/efi/grub

und legen dort eine Konfigurationsdatei »/mnt/efi/grub/grub.cfg« mit dem Inhalt (XYZ muss wieder durch die UUID der btrfs-Partition ersetzt werden)

Code: Alles auswählen

insmod part_gpt
insmod btrfs
insmod gzio
insmod gettext
insmod all_video
insmod gfxterm

set debian_uuid=XYZ

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

set default=0

menuentry 'Debian GNU/Linux Rettungssystem' {
        search --no-floppy --fs-uuid --set=root $debian_uuid
        linux  /debian/vmlinuz root=UUID=$debian_uuid rootflags=subvol=debian ro quiet loglevel=2
        initrd  /debian/initrd.img
}

Diese grub-Konfiguration sollte dann mit allen Bootmechanismen (32-bit uefi, 64-bit uefi, bios) funktionieren, aber wir müssen auch noch alle drei grub-Versionen installieren, zuerst in der bios-Variante (die Fragen bei der Installation können getrost ignoriert werden):

Code: Alles auswählen

# apt install grub-pc
# grub-install --boot-directory=/mnt/efi /dev/sdb
# apt purge grub-pc grub-pc-bin

32-bit uefi (die Fragen spielen wieder keine Rolle, aber bei der Frage nach dem Updaten der nvram-Variablen sagen wir sicherheitshalber nein):

Code: Alles auswählen

# apt install grub-efi-ia32
# grub-install --target=i386-efi --boot-directory=/mnt/efi --efi-directory=/mnt/efi --no-nvram --removable
# apt purge grub-efi-ia32 grub-efi-ia32-bin

und dasselbe noch für 64-bit uefi:

Code: Alles auswählen

# apt install grub-efi-amd64
# grub-install --target=x86_64-efi --boot-directory=/mnt/efi --efi-directory=/mnt/efi --no-nvram --removable
# apt purge grub-efi-amd64 grub-efi-amd64-bin

und die Überreste einer eventuell versuchten automatischen Installation tilgen wir auch noch

Code: Alles auswählen

# rm -rf /boot/grub

Ein Passwort für root dürfen wir auch nicht vergessen

Code: Alles auswählen

# passwd

und wenn ich nichts falsch gemacht habe, sollte das System nach einem Neustart booten – ausprobiert habe ich es auf die Schnelle allerdings nur für ein 64-bittiges uefi.

Wenn irgendetwas unklar ist bitte fragen, immerhin soll das die Basis für einen neuen Wiki-Artikel sein.

[GosuSan]

Feedback Rettungssystem:

Disclaimer: Ich habe Teile der alten und neuen Anleitung kombiniert um mein System zu installieren. Ich hätte auch auf den neuen Artikel warten können, aber da smutbert bereits um Feedback gebeten hat, dachte ich ich schreibe gleich was mir aufgefallen ist.

Leider ist sind meine Stichpunkte etwas unsortiert, ich bitte dies zu entschuldigen.

1. einen allgemeineren Namen wählen
Eventuell für die überarbeitete Version des Artikels einfach ein wenig weg von "Rettungssystem" und mehr in Richtung "portable Debian Vollinstallation".
ich habe mich zwar auch etwas dämlich angestellt beim Suchen nach einer solchen Anleitung, aber eventuell stoßen in Zukunft so mehr Leute auf diese nützliche Anleitung.

2. kernel-img.conf (alte Anleitung)

Die »/mnt/tmp/etc/kernel-img.conf« sorgt dafür, dass in »/boot« symbolische Links zum jeweils aktuellen und vorigen Kernel erzeugt werden, was dann bei der Installation des Bootloaders ausgenutzt wird:

Ich habe in der Dokumentation nachgelesen was die beiden Einstellungen tun. Jetzt weiß ich zwar was das ändert, aber nicht wirklich welche Auswirkungen das auf diese spezielle Installation hat, bzw. was wir dabei ausnutzen. Weil ich mir unsicher war habe ich diesen Teil einfach mal weggelassen um eventuell später festzustellen welche Auswirkungen das hat, aber bisher ist mir nichts aufgefallen.

3. außerdem installieren wir ein paar Pakete (neue Anleitung)
Das ist definitv persönliche Meinung, aber mMn ist hier weniger mehr. Pakete wie "eject, debootstrap, screen, gddrescue, nmap, netcat-traditional" sind sicherlich für viele Anwender nützlich, aber ich persönlich würde mich mehr auf die Basics einer allgemeinen Installation beschränken. (siehe 1.)

4. Firmware Installation (neue Anleitung)
Ich habe alle Schritte in einer Debian bullseye (lxqt / nonfree) VM durchgeführt, da das Übernehmen der apt sources.list etc. so einfacher war. Obwohl ich die VM von einem non-free Live-Image installiert habe sind in der sources.list weder "contrib" noch "non-free" eingetragen. Vielleicht sollte man im Absatz "Firmware Installation" kurz darauf hinweisen dass man unter Umständen die sources.list per

Code: Alles auswählen

sed -i 's/main/main contrib non-free/g' /etc/apt/sources.list

(stimmt das so..?)
anpassen muss um bestimmte Firmware nachinstallieren zu können.

5. zuverlässiger im Textmodus (alte Anleitung)

... aber zuverlässiger ist ein Rettungssystem, das nur im Textmodus bootet

Wieso ist das deiner Meinung nach so? Meiner Erfahrung nach bin ich in einer GUI flexibler wenn ich z.B. etwas im Internet suchen möchte um ein Problem zu beheben. Ich bin kein Freund von CLI-Webbrowsern. Davon abgesehen kann man eigentlich immer in eine TTY droppen, sollte die Desktopumgebung Probleme verursachen.

6. grub config (neue Anleitung)
Geschmackssache, aber ich persönlich hab unter "set default=0" noch ein "set timeout=2" hinzugefügt.
Einfach weil ich gewohnt bin dass GRUB meine Standard-Auswahl nach ein paar Sekunden bootet.

7. Erstellung des btrfs subvolumes (neue Anleitung)
In diesem Abschnitt wird das Subvolume nach seiner Erstellung gemountet. Hierfür musste ich zuerst mal /dev/sdb3 unmounten, was nicht in der Anleitung aufgeführt ist.

Positives Feedback:

genug in den Krümeln gesucht, jetzt kommt das Lob

1. Deaktivieren von APT recommends and suggests
In '/mnt/tmp/etc/apt/apt.conf.d/99local'

Code: Alles auswählen

APT::Install-Recommends "0";
APT::Install-Suggests "0";

Super Sache! Habe mich nie groß mit der Konfiguration von apt auseinandergesetzt und es meist so genommen wie es ausgeliefert wird, aber für ein solches System das man eher schlank halten will ist das eine tolle Sache. Würde ich auf jeden Fall drin behalten.

2. bootbar auf allen Systemen
Ich habe gelesen dass du im Forum-Thread zu der Anleitung kurz mit dem Gedanken gespielt hast die Anleitung zu vereinfachen indem du nur 64bit UEFI Bootloader installierst. Du hast den Gedanken zwar ein paar Posts später verworfen, aber ich wollte dennoch Feedback dazu geben. mMn macht genau der Umstand dass das System auf jedem PC booten kann (wenn er USB-boot unterstützt) so wertvoll und ich würde es nicht streichen. Wenn man nur eine Debian-Installation mit 64bit UEFI bootloader auf einem Stick möchte kann man auch einfach einen Debian Live-Installer auf einem zweiten Stick nehmen und Debian ganz normal installieren.

3. Nutzung von tmpfs für /tmp
Auch hier ein großes Plus, vor allem für die Installation auf einem USB Stick. Jeder Schreibzugriff auf den Flash weniger ist super!

4. ganz Allgemein eine tolle Anleitung
Abschließend möchte ich sagen dass die Anleitung(en) gut strukturiert und wirklich sehr hilfreich sind. Ich möchte nicht dass das hier rüberkommt was wäre dem nicht so. Keine der oben aufgeführten Punkte ist eine große Sache, nur kleine Dinge die mir aufgefallen sind. Und viele davon sind auch nur persönliche Präferenz. Auch die deutliche Trennung zwischen dem ersten (nicht-chroot) Abschnitt und den Befehlen in der chroot-Umgebung ist deutlich und sehr wichtig.

PS: Auch der Wechsel auf UUIDs für die fstab in der neuen Anleitung ist sinnvoll und zeitgemäß.

Danke fürs Lesen,

Tobias

[smutbert]

Danke für deine Rückmeldung. Das muss ich mir noch einmal in Ruhe durchlesen, aber einen Punkt kann ich gleich beantworten:

[...]
2. kernel-img.conf (alte Anleitung)

Die »/mnt/tmp/etc/kernel-img.conf« sorgt dafür, dass in »/boot« symbolische Links zum jeweils aktuellen und vorigen Kernel erzeugt werden, was dann bei der Installation des Bootloaders ausgenutzt wird:

Ich habe in der Dokumentation nachgelesen was die beiden Einstellungen tun. Jetzt weiß ich zwar was das ändert, aber nicht wirklich welche Auswirkungen das auf diese spezielle Installation hat, bzw. was wir dabei ausnutzen. Weil ich mir unsicher war habe ich diesen Teil einfach mal weggelassen um eventuell später festzustellen welche Auswirkungen das hat, aber bisher ist mir nichts aufgefallen.
[...]

Bei einer gewöhnlichen Installation wird die grub-Konfiguration vom System aktualisiert, das heißt jedes Mal, bei jeder Kernelinstallation oder -deinstallation und jedem Kernelupdate wird update-grub aufgerufen, das die grub.cfg neu schreibt (und damit die aktuell installierten Kernel in das Bootmenü aufnimmt) und bei uefi auch den Booteintrag von neuem ins nvram schreibt.
Das würde grundsätzlich auch auf USB-Sticks und anderen externen Datenträgern funktionieren, aber wenn man die grubs für drei Bootmechanismen (bios, uefi-amd64, uefi-ia32) installiert haben will, kann das zu Nebeneffekten führen, weil man nicht mehrere grub-Versionen parallel installiert haben kann. Obendrein ist das Schreiben von Booteinträgen ins nvram, wenn es sich um einen externen Datenträger handelt, meistens auch unerwünscht.

In der Anleitung wird grub dagegen sozusagen unabhängig von Debian installiert und die grub.conf manuell angelegt. Das heißt aber auch, dass sie nicht automatisch bei jedem Kernelupdate oä neu geschrieben wird und hier kommt die »/mnt/tmp/etc/kernel-img.conf« ins Spiel (oder auch nicht). In dieser Datei kann man festlegen ob und wo symbolische Links auf den aktuellen und vorigen Kernel samt initrd angelegt werden sollen

1. ohne diese Konfigurationsdatei werden die Links per default in / angelegt (»/vmlinuz« und »/initrd.img«)
2. mit der Datei und dem Inhalt aus der alten Anleitung werden die Links dagegen in /boot angelegt (»/boot/vmlinuz« und »/boot/initrd.img«)

Diese Links werden in der grub.cfg zum Laden von Kernel und initrd verwendet und der Pfad unterscheidet sich bei den beiden Varianten durch das boot/.

Die zweite Variante mit den Links in /boot habe ich früher bevorzugt, weil es dabei egal ist, wenn /boot auf einem anderen Dateisystem liegt als / (das war zu Beginn bei btrfs notwendig oder zumindest von Vorteil). Inzwischen legt aber auch bei btrfs niemand mehr eine eigene Partition für /boot an und man kann einfach die per default angelegten Links verwenden.

[GosuSan]

[..]
Die zweite Variante mit den Links in /boot habe ich früher bevorzugt, weil es dabei egal ist, wenn /boot auf einem anderen Dateisystem liegt als / (das war zu Beginn bei btrfs notwendig oder zumindest von Vorteil). Inzwischen legt aber auch bei btrfs niemand mehr eine eigene Partition für /boot an und man kann einfach die per default angelegten Links verwenden.

Ah alles klar, das ergibt jetzt Sinn, danke für die Erklärung

[GosuSan]

Ich habe noch zwei Fragen, ich hoffe ich nerve nicht

1. Wieso erstellen wir ein btrfs subvolume?
btrfs liegt noch etwas außerhalb meiner Komfortzone, aber ich finde es sehr interessant und experimentiere hin und wieder damit (nur auf eher unwichtigen Installationen).
Ich habe unter https://btrfs.wiki.kernel.org/index.php ... Subvolumes nachgelesen wann üblicherweise Subvolumes zum Einsatz kommen und keiner der aufgeführten Punkte scheint hier relevant zu sein. Und wir mounten in der fstab ja auch nur das Haupt-Volume, oder?

2. Ich habe versucht, zusätzlich zu den in der Anleitung aufgeführten Partitionen, eine vierte, mit NTFS formatierte Partition einzurichten.
Aber sobald ich den Stick von meiner VM auswerfe versucht mein Hostsystem (Debian Buster) ihn zu mounten und sagt das btrfs-Dateisystem ist beschädigt. (Hab die Fehlermeldung nicht notiert, muss das die Tage nochmal versuchen) Ich kann den Stick dann auch nicht mehr verwenden (auch in der VM nicht) - er findet die »/vmlinuz« und »/initrd.img« dann nicht mehr. Bin nicht sicher ob das an der Installation in einer VM liegt, beim mounten im Hostsystem irgendwas schiefläuft oder ob es überhaupt an der vierten Partition liegt. Würde mich diesbezüglich glaube ich nochmal mit mehr Informationen melden, aber vielleicht fällt ja schon jemandem etwas dazu ein.

PS: Nicht wundern, ich habe meinen Benutzernamen ändern lassen - hab den alten Namen schon vor langem abgelegt.

[smutbert]

Man könnte sich das subvolume auch ersparen, aber das wäre eher unüblich und ein eigenes Subvolume schadet jedenfalls nicht.
Dafür hat es den Vorteil, dass wenn man irgendetwas vor hat, was man möglicherweise hinterher wieder rückgängig machen will, man einfach vorher einen Snapshot anlegen kann. Man kann dann entweder direkt den Snapshot statt dem ursprünglichen Subvolume dazu verwenden oder hinterher das originale Subvolume löschen und durch den Snapshot ersetzen.

Das Anlegen und das Löschen eines Snapshots geht in Sekundenschnelle – gerade auf einem tendentiell langsamen USB-Stick ist das ein großer Vorteil.

Auf die Art lassen sich auch mehrere Distributionen oder zB Debian stable und unstable auf unterschiedliche Subvolumes auf einem Stick installieren.
Da ist auch die besondere grub-Installation von Vorteil:
Für weitere Debian-Installationen (oder andere Distributionen, arch wird ja zB ohnehin meist mit einem debootstrap-ähnlichen Tool installiert), genügt es ein eigenes Subvolume zu erstellen, sie (ohne Bootloader) dorthinein zu installieren und den passenen Booteintrag zur grub.cfg hinzuzufügen. So gibt es keine konkurrierenden Bootloader, die sich bei jedem Update gegenseitig überschreiben und ersetzen.

Und wir mounten in der fstab ja auch nur das Haupt-Volume, oder?

Es stimmt, dass in der fstab kein subvolume angegeben ist, aber gemountet wird das /-Dateisystem ja schon früher, während noch die initrd abgearbeitet wird und das bekommt die Information von den Parametern, mit denen der Kernel aufgerufen wird:

linux /debian/vmlinuz root=UUID=$debian_uuid rootflags=subvol=debian ro quiet loglevel=2

Das subvolume ist also debian (=/debian) und das wird dann beibehalten, auch wenn es in der fstab gar nicht drin steht.

Das hat wieder den Vorteil, dass man einen Snapshot direkt ohne Änderung der fstab booten kann – man muss nur in die grub.cfg einen Booteintrag mit dem richtigen Subvolume schreiben.



zu deinem 2. fällt mir nicht viel ein:
Wenn du die Partition von Anfang an angelegt hast, sehe ich keinen Grund warum etwas daran scheitern sollte. Wenn du die vierte Partition erst hinterher anlegst, musst du möglicherweise grub neu installieren (und wenn, dann in allen drei Varianten), weil grub mitunter recht empfindlich auf Änderungen der Partitionierung reagiert.

Wenn du außerdem vorher noch Platz frei machen, also etwa die btrfs-Partition verkleinern musst(est), wobei das glaube ich bei btrfs ja gar nicht funktioniert, ist es ohnehin einfacher die Daten vom Stick zu kopieren, neu zu partitionieren und formatieren und hinterher die Daten wieder zurückzukopieren – die subvolumes müssen halt auch neu angelegt werden, die UUIDs in der fstab und grub.cfg angepasst und schließlich grub neu installiert werden.
(Das war übrigens ein Grund weshalb ich in der alten Anleitung statt UUIDs die Dateisystemlabel verwendet habe. Die sind leichter zu ändern bzw. direkt dieselben wieder zu verwenden und dann muss man bei so einer Aktion die fstab und grub.cfg nicht mehr anpassen sondern nur mehr grub neu installieren.)

Wenn du die ntfs-Partition mit Windows anlegst, weiß ich auch nicht ob nicht Windows da noch irgendetwas macht – das hat ja schon früher gerne den MBR überschrieben und vielleicht macht das jetzt zusätzlich noch gerne ähnliches mit der EFI System Partition.

[GosuSan]

Danke für deine ausführlichen Erklärungen, und entschuldige dass ich so spät antworte, war viel Los in letzter Zeit.

Ich konnte mich über Ostern endlich mal wieder damit beschäftigen.
Mein Problem mit der zusätzlichen Partition (die tatsächlich gar keine Schuld traf) konnte ich lösen.
Wenn man sich entscheidet das Subvolume anders zu nennen sollte man natürlich auch die /mnt/grub/grub.cfg entsprechend anpassen

[B52]

Hab gerade die Art und Weise verewigt, auf die ich ein System für den Notfall auf USB-Stick installiere

Ein Notfallsystem auf einem USB-Stick installieren

Ich habe mir die Zeit genommen, das Tutorial durchzulesen. Respekt! da steckt viel Arbeit dahinter. Für einen Laien ist dies jedoch abschreckend.

Stimmt! Es wird Anfangs erwähnt, dass es sich nicht um ein simples Live-System handelt, welches ab Stick gebootet wird. Dabei wäre es so einfach: knoppix herunterladen und mit dd auf den Stick schreiben. Fertig! Jetzt geht es an die Rettung des Systems.

Für den Neueinsteiger ist dies die falsche Plattform und es sollte dringendst darauf hingewiesen werden, dass sich diese Anleitung primär an fortgeschrittene User hält. Versetzt euch ein paar Sekunden in einen Neueinsteiger, welcher einfach sein System versucht zu retten...

B52

[smutbert]

Du hast schon einmal zumindest insofern recht, als der Artikel nicht (nur) für Rettungssystem sondern allgemein als Installationen mittels debootstrap gedacht ist. Auf meinem stationären PC habe ich Debian ja auch (ungefähr) so installiert wie in meinem Artikel beschrieben.
Wenn dadurch nicht einige Links aus dem Forum kaputt würden, hätte ich den Artikel längst umbenannt. So warte ich zumindest bis ich den Artikel überarbeitet habe. Damit wäre das in gewisser Weise weitgehend hinfällig, hoffe ich zumindest:

[...]
Für den Neueinsteiger ist dies die falsche Plattform und es sollte dringendst darauf hingewiesen werden, dass sich diese Anleitung primär an fortgeschrittene User hält. Versetzt euch ein paar Sekunden in einen Neueinsteiger, welcher einfach sein System versucht zu retten...

[muenster]

Hi und guten Tag, smutbert, Lord_Carlos, B52, Kp97 GoSusan, Redegast u. ihr Anderen


vorweg: vielen Dank für diesen Thread und auch für das ganze Wiki zu Debian!

Also, ich hatte auch schon des Öfteren die Aufgabe einen Rettungsstick zu bauen. Deshalb bin ich froh, dass Ihr euch hier die Mühe macht und das mal dokumentiert!

Euer Ansatz - Danke: https://wiki.debianforum.de/Ein_Notfall ... stallieren

Für den Neueinsteiger ist dies die falsche Plattform und es sollte dringendst darauf hingewiesen werden, dass sich diese Anleitung primär an fortgeschrittene User hält. Versetzt euch ein paar Sekunden in einen Neueinsteiger, welcher einfach sein System versucht zu retten.

Ja - ggf. für blutige Anfänger etwas steil - die Lernkurve.

die Partition für das eigentliche System wird im Beispiel schließlich mit BTRFS formatiert und BTRFS.RESCUE benannt.
Im Gegensatz zu den Namen für die Partitionen, die nur der Übersicht dienen, sind die Namen der Dateisysteme, die Dateisystemlabels wichtig, weil sie später noch eine Rolle spielen werden. Selbstverständlich können auch andere unter GNU/Linux übliche Dateisysteme wie ext4 oder xfs verwendet werden.

okay - das ist wichtig - der unten genannte Hinweis.

Für den Neueinsteiger ist dies die falsche Plattform und es sollte dringendst darauf hingewiesen werden, dass sich diese Anleitung primär an fortgeschrittene User hält. Versetzt euch ein paar Sekunden in einen Neueinsteiger, welcher einfach sein System versucht zu retten...

Denke auch, dass das wirklich für etwas fortgeschrittenere User gedacht ist. Als Anfänger wird mans ggf. etwas schwer haben dem Ganzen zu folgen.


Dennoch - vielen Dank für die Mühe u. insgesamt für das Wiki.

Das ist ja wirklich klasse


Viele Grüße
Münster

[uname]

Ich gebe zu, dass ich nicht alles im Detail gelesen und auch nicht verstanden habe.

Aber ich nutze als "Rettungssysteme" immer Live-Systeme auf USB.
Hier bietet sich doch z. B. GRML an.
Auch bietet GRML die Möglichkeit von persistency.
Ja die Pakete sind dann teilweise veraltet. Aber das möchte ich hier mal etwas ignorieren.

Ihr schreibst ja selbst, dass eure Lösung vielleicht nicht was für jeden wäre.
Wäre denn der Ansatz mit GRML mit oder ohne Persistenz eine gangbare Lösung für andere Personen?
Würde mich interessieren. Könntet ihr damit (theoretisch) euren Use-Case abbilden?
Was fehlt oder könnte bei GRML fehlen?