Démarrer le système Linux à partir d'un sous-directory sur une partition?

Je voudrais essayer de mettre en place un ordinateur afin qu'il dispose de plusieurs installations Linux dans le même système de files. Par exemple, le filesytem aurait 3 dossiers: /Ubuntu_Precise , /Ubuntu_Oneiric , et /Ubuntu_Natty .

(Je sais que vous pouvez le faire avec BTRFS et subvolumes, mais je voudrais utiliser EXT4 pour la vitesse).

J'ai déjà installé plusieurs installations de différentes dissortingbutions en utilisant BTRFS, et d'get que cela fonctionne, je sais que Grub fonctionne bien avec le démarrage de l'image vmlinuz et initrd à partir de paths «non standard». Mais quand je faisais la chose BTRFS, il y avait rootflags=subvol=@<subvolume_name> qui a dit au kernel de monter ce sous-volume comme / dans le système de files. Y at-il un argument que vous pourriez passer le kernel qui ferait lier monter un sous-dossier dans une partition comme / et puis démarrer?

Je pense que pour les autres parties, je suis assez proche. Je sais comment spécifier un mount bind dans /etc/fstab . De plus, à partir du moment où j'ai installé mon système avec plusieurs installations linux dans des sous-volumes BTRFS, je suis habitué à installer une distro dans une VM puis à la migrer en utilisant rsync, donc je ne m'inquiète pas trop de ce que je devrais faire get la bonne configuration, j'essaie juste de find la bonne configuration. Une fois que je le sais, je devrais être capable de faire la migration dans les sous-dossiers et l'édition de files assez facilement.

Je connais déjà la virtualisation et les partitions, mais ce n'est pas ce que je search. L'ordinateur cible n'a pas assez de puissance pour effectuer la virtualisation et les partitions ne partagent pas d'espace libre. Je cherche à mettre en place un système dual / sortingple / quad / etc boot linux distros, mais qui le fait avec un seul système de files, de sorte qu'il n'y a pas de cas de «J'ai de l'espace libre, mais il est dans la mauvaise partition!

Si quelqu'un a des suggestions pour modifier ma question ou son titre pour être plus clair, je suis tout oreilles.

Réponse courte – il y a autant que je ne connais pas de solution de travail pour vos besoins spécifiques. Vous devrez ajuster chaque initramfs de chaque dissortingbution pour répondre à vos besoins spécifiques.

Réponse longue – oui c'est possible. De nos jours, la plupart des dissortingbutions Linux utilisent un initramfs qui sera chargé en memory par le bootloader, puis décompressé par le kernel. Il exécutera /sbin/init qui est responsable de la configuration de l'espace user initial (exécution d'udev, chargement des modules, démarrage de plymouth, request de mot de passe crypté, configuration du réseau pour les assemblys réseau, …). Comme vous pouvez exécuter vos propres scripts et évaluer les paramateurs de démarrage personnalisés.

Exemple pour Debian

Si vous utilisez Debian (devrait être la même chose avec Ubuntu), vous devriez pouvoir placer un script dans /etc/initramfs-tools/scripts/init-bottom/ qui sera exécuté avant le démarrage de init. Pour plus d'informations sur le script, les différents directorys et la layout jetez un oeil à man initramfs-tools . Vous devrez ajuster rootmnt et append le directory cible.

Exemple de script (non testé) qui doit être installé sous /etc/initramfs-tools/scripts/local-bottom/00-myroot ou /usr/share/initramfs-tools/scripts/init-top/00-myroot

 #!/bin/sh -e PREREQS="" prereqs() { echo "$PREREQS"; } case "$1" in prereqs) prereqs exit 0 ;; esac for opt in $(cat /proc/cmdline); do case $opt in rootdir=*) new_mntdir="${opt#rootdir=}" ;; esac done if [ -n "$new_mntdir" ] ; then echo rootmnt="$rootmnt/$new_mntdir" >> /conf/param.conf fi

L'idée est d'ajuster rootmnt qui est utilisé dans le script d' init initramfs pour démarrer / exécuter l'init réel. Comme le périphérique racine est déjà monté dans l'étape init-bootom , vous pouvez simplement ajuster / modifier le directory cible.

Pour utiliser ce script, ajoutez simplement un nouveau paramètre de démarrage, copyz le script, exécutez-le, régénérez votre initramfs et ajoutez un paramètre de démarrage pour votre dissortingbution Linux, par exemple rootdir=/Ubuntu_Precise .

Une autre solution pour un système de files partagé est d'utiliser des volumes en boucle, ici les quelques changements nécessaires en supposant que vous ayez un file / volume de la boucle debian dans le système de files / dev / sdb1 (J'utilise GNU / Debian sid / unstable pour les os principal et loop).

 /etc/grub.d/40_custom: # outside from loop volume menuentry 'label' --class gnu-linux --class gnu --class os { ... loopback loop (hd2,msdos1)/debian linux (loop)/boot/vmlinuz root=/dev/sdb1 loop=/debian ro initrd (loop)/boot/initrd }

Les arguments définis dans grub en tant que command line linux sont définis sur env par initrd / init, ainsi:

 ROOT=/dev/sdb1 rootmnt=/root loop=/debian

loop mount /dev/sdb1 /root il suffit de remonter le directory / dev / sdb1 comme rw s'il était ro, puis toujours append un mount -o loop /root/debian /root .

 /etc/initramfs-tools/scripts/local-bottom/loop: # inside the loop volume #!/bin/sh [ "$1" = "prereqs" ] && echo && exit 0 if [ -n "${loop}" ]; then if [ "${readonly}" = "y" ]; then roflag=-r mount -o remount,rw ${ROOT} ${rootmnt} else roflag=-w fi mount ${roflag} -o loop ${rootmnt}${loop} ${rootmnt} fi

Il faut aussi précharger un module dans l'initram (alors n'oubliez pas de lancer update-initramfs)

 /etc/initramfs-tools/modules: # inside the loop volume ... loop ext4

Je ne sais pas comment utiliser les performances d'influence de boucle ou de gaspillage de ressources, je me request si le assembly de ext4 sur ext4 double les probabilités d'un échec du système de files, mais devinez un peu d'accord pourrait être fait. Peut-être qu'il y a une meilleure façon d'utiliser la boucle, less hackish, s'il vous plaît laissez-moi savoir parce que je n'ai pas trouvé.

Ce n'est pas une réponse, mais je veux clarifier un point sur la réponse et les commentaires d'Ulrich (je ne peux pas commenter ci-dessus).

La solution Ulrich propose "peut" fonctionner (non encore testé) mais vous obtiendrez alors un système de files non-remontable . En tant que solution de contournement (IMHO laide), vous pouvez monter le fs comme rw avant chrooting ( comme suggéré ici ), mais faites attention aux scripts d'initialisation brisés. Je suppose que cette solution de contournement ont plus d'effets secondaires (comme des fs cassés essayant de remonter ro et d'échouer).

J'utilise le kernel 3.2 avec ext4 et monter un dev déjà monté dans le chroot donne toujours EBUSY comme psusi commenté.