In eine Chroot booten?

Ich habe Linux (Debian Jessie) auf einer Festplatte installiert. Laufwerk - sda1, ext4fs und sda2- Swap

Ich habe einen /chrootOrdner. Im /chrootOrdner ist ein anderes System installiert .

Frage:

Wie kann der Bootmanager angewiesen werden, nicht das primäre System (main, Debian Jessie), sondern das System in / chroot zu booten ? Wahrscheinlich ändern /menu.lstund /chroot/etc/fstab? ( vmlinuz root=/dev/sda1/chroot?)

Oder eine andere Variante der Frage: Ist es möglich, Linux nicht im Stammverzeichnis der Partition, sondern im Ordner zu installieren? ( /another_linux/bin, /another_linux/home, /another_linux/etc, ...)

Dies kann weder vom Bootloader noch vom Kernel ausgeführt werden. Der Parameter für die Kernel- rootOption wie in root=/dev/sda1sieht aus wie ein Standard-Unix-Pfadname, aber solche Pfadnamen werden entsprechend dem aktuell gemounteten Dateisystem interpretiert. Zum Zeitpunkt der rootInterpretation der Option sind keine Dateisysteme angehängt. Na ja, fast keine. Zur Kernel-Initialisierungszeit gibt es eine Instanz eines minimalen ramfsDateisystems, rootfsdas als Root für den ersten ausgeführten Prozess bereitgestellt wird start_kernel(). Die eigentliche Interpretation des rootOptionsparameters erfolgt in einer aufgerufenen Routine name_to_dev_t(). Eine der unterstützten Syntaxen ist das /dev/nameFormat, bei dem der Name interpretiert wird, indem eine temporäre Bereitstellung des sysfsDateisystems in der ausgeführt wirdrootfsroot und auf der Suche nach einem Block-Geräteeintrag, der mit dem Namen unter übereinstimmt /sys/block. Dieser Vorgang wird hier näher erläutert .

Das beschriebene Setup müsste durchgeführt werden, indem zuerst in einer minimalen Umgebung gebootet wird, beispielsweise einer, die von a bereitgestellt wird initrd. Hängen Sie das echte Root-Dateisystem von /dev/sda1einem temporären Mount-Punkt aus an /mnt/rootfs, und ändern Sie dann das Root-Verzeichnis in /mnt/rootfs/chrootusing pivot_root(8).

Dies ähnelt in gewisser Weise der Einrichtung der Root-Dateisysteme für LinuX-Container ( LXC ). LXC ist eine Virtualisierungsimplementierung auf Betriebssystemebene für Linux. Die Virtualisierung auf Betriebssystemebene wird häufig in virtuellen Hosting-Umgebungen als einfache Alternative zur vollständigen Virtualisierung verwendet, die von einem Hypervisor verwaltet wird. Bei der Virtualisierung auf Betriebssystemebene wird ein einzelner Betriebssystemkern von mehreren isolierten Benutzerbereichsinstanzen gemeinsam genutzt. Jede Instanz, die häufig als Container, Gefängnis, Virtual Private Server (VPE) oder Virtual Environment (VE) bezeichnet wird, ist im Wesentlichen eine separate Betriebssysteminstallation, die in einem eigenen Verzeichnis auf dem Hostsystem gespeichert ist.

Ich bin auf dasselbe Problem gestoßen und habe es schließlich so geschrieben , dass es auf verschiedenen Systemen (Debian, Ubuntu derzeit) problemlos funktioniert:

Führen Sie ein make_chroot_initrdSkript aus, um aus dem vorhandenen ein neues chroot-fähiges initrd-Image zu erstellen:

#  ./make_chroot_initrd /chroot/trusty/boot/initrd.img-3.13.0-32-generic
making new initrd: /chroot/trusty/boot/initrd.img-3.13.0-32-generic.chroot

Das neue Image ist genau das gleiche, außer dass es jetzt einen chroot=Boot-Parameter verarbeiten kann.

Mit grub2 als Bootloader können Sie einen Eintrag hinzufügen zu /boot/grub/grub.cfg:
(oder besser /etc/grub.d/40_custom)

menuentry "ubuntu trusty, (linux 3.13.0-32) (chroot)" {
    insmod ext2                       # or whatever you're using ...
    set root='(hd0,7)'                # partition containing the chroot
    set chroot='/chroot/trusty'       # chroot path
    linux   $chroot/boot/vmlinuz-3.13.0-32-generic root=/dev/sda7 chroot=$chroot rw
    initrd  $chroot/boot/initrd.img-3.13.0-32-generic.chroot
}

(Ändern Sie die Dateien / Partitionen, um sie an Ihre anzupassen.)

Systemweite Installation

Sobald Sie damit zufrieden sind, können Sie die Änderungen dauerhaft vornehmen
(bis das initramfs-tools-Paket aktualisiert wird).
Im Chroot-System:

# cd /usr/share/initramfs-tools
# cp -pdrv .  ../initramfs-tools.orig       # backup
# patch -p1 < path_to/boot_chroot/initrd.patch
# rm *.orig */*.orig
# update-initramfs -u

Von nun an unterstützt das reguläre initrd-Image das chroot-Booten.
Es muss kein separater initrd.chroot verwendet werden, der dann möglicherweise nicht mehr mit ihm synchronisiert ist.

Siehe boot_chroot für Details.

Ja, Sie können den Trick mit Btrfs-Subvolumes ausführen .

Zuerst müssen Sie ext4 in btrfs konvertieren, wie hier beschrieben .

Konvertieren Sie Ihre Chroot in ein Subvilume, wenn dies noch nicht der Fall ist:

 sudo mv /path/to/chroot /path/to/chroot-tmp
 sudo btrfs subvol create /path/to/chroot
 sudo mv /path/to/chroot-tmp/* /path/to/chroot
 sudo mv /path/to/chroot-tmp/* /path/to/chroot -r # for directories

Jetzt haben Sie ein Subvolume namens path / to / chroot . Sie können es mit überprüfensudo btrfs subvol list /

Jetzt können Sie einen Boot-to-Subvolume-Datensatz in Grub erstellen. rootflags=subvol=path/to/chrootFügen Sie einfach im Menüpunkt grub eine Zeichenfolge zum Laden des Linux-Kernels hinzu oder verwenden Sie diese , um automatisch zu testen.