cd /run/media/MONLOGIN/manjaro-etiquette/ sudo systemd-nspawn
Vous êtes maintenant connecté en tant que root sur votre distribution
Note : vous avez ce message : "Press ^] three times within 1s to kill container." mais un simple exit fonctionne aussi, comme le CTRL+ALTGR+]]] du message.
Attention vous êtes en root, pas question de lancer une session graphique
Pour plus de détails/options, voir les man de systemd-nspawn et machinectl
Intéressant ! Je teste ça dès que je rentre. Edit: Impecc . J'ai mis Arch à jour sans la démarrer; normal,c'est un chroot Mais je pense que le meilleur alias est celui qu'on mémorise (avant ) évidemment
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
Je ne suis pas sur d'avoir bien compris l'avantage présenté par systemd-nspawn par rapport au bon vieux chroot... Une fois la racine montée, exécuter systemd-nspawn sur son répertoire monte automatiquement les autres partitions du fstab ?
Non. Chez moi, il n'y a que le home dans le fstab. Arch apparaît dans dans Thunar mais n'est pas montée. En cliquant dessus, la partition monte après MP dans /run/media/user/Arch/ L'intérêt est surtout qu'avec un chroot classique, on change de racine et on modifie le chemin des binaires, alors que là on monte la partition dans un conteneur sécurisé et indépendant tout en restant dans la racine du système démarré. Et ça se démonte mieux qu'avec un chroot. Cela dit, je n'ai pas fais un comparatif exhaustif...
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
N3mesis98 a écrit :Je ne suis pas sur d'avoir bien compris l'avantage présenté par systemd-nspawn par rapport au bon vieux chroot...
Bonsoir, J'"uppe" ce sujet passionnant car, depuis que papajoke nous a déterré cette superbe fonction je l'utilise constamment. En fouillant les sources : ici j'ai trouvé l'option "-b" ! Pour les allergiques à l'anglais j'ai fait un additif sommaire au wiki français du chroot oui j'ai eu la flemme de tout traduire dans un nouvel article... Usage, l'option -b lance la machine du système chrooté qui devient une machine virtuelle:
# mount /dev/sdb7 /mnt # systemd-nspawn -b -D /mnt
Machine virtuelle qui se lance à la vitesse de l'éclair, fonctionne de même, et s'éteint tout aussi vite avec
# poweroff
Quand on a une deuxième partition de dépannage et qu'on a la flemme de rebooter pour la mettre à jour... Je me cite : Ce n'est plus à proprement parler du chroot. Cette commande est plus puissante, elle virtualise l'ensemble du système à chrooter, comme si ce dernier était en cours d'exécution. C'est comme si on démarrait un deuxième OS sur la machine, ce n'est pas une machine virtuelle mais un conteneur.
en fait je n'ai pas compris l’intérêt du -b sauf se loguer en simple utilisateur mais pour un chroot, je ne voie pas l’intérêt et de plus les utilisateurs ne sont pas gérés de la même façon dans un conteneur (plus moyen de passer en root) et ... le boot est extrêmement lent (contre 1/10eme de seconde sans le -b) avec un simple shell (sans -b) je fais très bien mes mises à jour manjaro depuis mon arch ...
man a écrit :If option -b is specified, the arguments are used as arguments for the init binary. Otherwise, COMMAND specifies the program to launch in the container, and the remaining arguments are used as arguments for this program. If -b is not used and no arguments are specified, a shell is launched in the container. -b, --boot Automatically search for an init binary and invoke it instead of a shell or a user supplied program. If this option is used, arguments specified on the command line are used as arguments for the init binary. This option may not be combined with --share-system.
me suis permis d'ajouter l'option --bind au wiki qui dans le cas d'un chroot "pour réparer" peut-être utile (ou pas...)
J'ai fais un petit test avec les deux options. L'option -b n'est pas utile pour mettre à jour un système et est bien sur plus longue puisqu' on démarre une machine virtuelle. Par contre, ça peut être intéressant pour pour compiler depuis yaourt étant donné qu'on ne peut le faire en root, sauf avec l'option -c ce qui reste théoriquement dangereux ou du moins peu déontologique. Ça permet aussi de lancer directement des alias contenus dans le ~/.bashrc ce qui n'est pas possible sans l'option -b, vu que le home est en fait root. Un autre intérêt est de pouvoir manipuler des fichiers dans le home du conteneur sans risquer de voir les permissions modifiées par l'utilisateur de la machine hôte, même s'il est identique car <<toto>> de Manjaro est différent de <<toto>> sur Arch par exemple. Ne pas perdre de vue que le noyau reste celui du système actif et non de la VM. Je pense que les deux options ont leurs propres intérêts...
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
en fait je n'ai pas compris l’intérêt du -b sauf se loguer en simple utilisateur mais pour un chroot, je ne voie pas l’intérêt et de plus les utilisateurs ne sont pas gérés de la même façon dans un conteneur (plus moyen de passer en root) et ... le boot est extrêmement lent (contre 1/10eme de seconde sans le -b)
Là je ne comprends pas ! Au contraire quand je lance la commande ma machine virtuelle s'émule à toute vitesse, on voit défiler toutes les séquences de boot, puis l'invite de l'user, on se logge en root et on fait toutes les taches d'administration comme si on était en tty, et à toute vitesse ! Au reboot sur la machine virtualisée tout fonctionne comme on vient de le configurer.
@lemust Oui, on travaille depuis le noyau de l'hôte, mais sans aucun ralentissement, au contraire on est plus rapide sur le conteneur que sur l'hôte , sans doute parce que l'environnement graphique n'est pas lancé (je n'ai jamais essayé de le faire, je ne me connecte qu'en root). Là je viens, depuis ma Debian en mettant ma Arch en conteneur, de désinstaller gnome-shell qui me bassine (et bugge avec tracker-extract) pour réinstaller plasma/kf5. Ça s'est fait à toute vitesse, je suis même surpris de la différence d'avec une virtualisation.
waitnsea a écrit :Là je ne comprends pas ! Au contraire quand je lance la commande ma machine virtuelle s'émule à toute vitesse, on voit défiler toutes les séquences de boot, puis l'invite de l'user, on se logge en root et on fait toutes les taches d'administration comme si on était en tty, et à toute vitesse ! Au reboot sur la machine virtualisée tout fonctionne comme on vient de le configurer.
je dis que c'est exactement la même chose sans -b mais en moins on ne voit pas "défiler toutes les séquences de boot", on arrive à l'invite directement donc beaucoup beaucoup plus rapidement !
Pour la vitesse, je ne suis pas surpris car c'est la même chose avec docker mais c'est vrai que ca change des VM
@lemust Mais en root avec -b ou sans, yaourt fonctionne très bien dans le conteneur
Ce qui change aussi avec la conteneurisation c'est l'extinction : au lieu de ^^^ qui ne fonctionne pas et que l'on soit obligé se faire un Ctrl+D assez sauvage, le poweroff temine les app proprement. La séquence de boot est hyper-rapide, et j'ai vraiment eu l'impression de travailler plus vite. Reste à faire des tests chronométrés (avec un yaourt -Syy p. ex.) avec les 2 méthodes et je posterai le résultat...demain... Bon dimanche à tous, je vais tâter du beau soleil en vélo...
Impossible de faire le test comparatif depuis ma Debian, car : * si je boote avec l'option -b -D et commence par "yaourt -Syy" je mets à jour et installe ce que je veux. * par contre si je chroote par -D seul, sans booter le conteneur, je suis incapable de charger le cache car j'ai apparemment un problème de resolv.conf (j'ai bidouillé les DNS de mon Arch pour ne pas subir les DNS imposés par Free et ses restrictions). Il y a là un gracieux mélange d'utilisation du noyau hôte et des fichiers systèmes virtualisés. Pas trop compétent pour tirer ça au clair. J'en reste à -b, je n'ai pas le choix...
hote arch : 4,4,4 secondes (pas mêmes dépôts/paquets bien sur que la manjaro ) -manja avec -b : 4,4,4 secondes -manja sans option -b : 7,4,5,5,7,5 secondes ------------------------------------------------------- cette fois, hôte la manjaro précédente(cinnamon), virtuel une autre manjaro(kde4 avec pleins de pkgignore: tout kde4 depuis aout) hôte manjaro cinnamon : 4,5,4,4 secondes - autre manja kde avec -b : 4, 8, 4, 7 , 5 - autre manja kde sans -b : 15,4,4,4,5 (peut-être un "parasite" sur ma ligne au premier essai...)
Mesurer vaut mieux qu'une impression, merci papajoke. Mais il me reste à comprendre ce qui se passe vraiment avec nspawsn, mon impossibilité - en chroot sans -b - à résoudre les DNS alors que (vérifié par uname) j'utilisais le noyau hôte... j'utilise donc le réseau "Debian" mais avec un conflit de resolv.conf... : J'avais traduit ça du Wiki :
L'option -n établit un réseau privé entre hôte et conteneur. Elle n'est pas nécessaire pour connecter la machine à Internet; au contraire, elle implique d'avoir créé un réseau privé.
mais pas compris comment le mettre en place puisque le "pont" semble exister naturellement.
je me retrouve "en root" alors que je suis connecté uniquement par l'utilisateur et non en root ???? et j'ai une erreur au log très intéressante pour toi waitnsea :
Failed to remove existing timezone info /mnt/monportable/etc/localtime in container: Permission denied Failed to copy /etc/resolv.conf to /mnt/monportable/etc/resolv.conf: Permission denied
et voila ce que nous cache systemd-nspawn
dans le conteneur, id me retourne :
uid=0(root) gid=0(root) groupes=0(root)
le prompt m'indique aussi "root" mais en fait je suis bien le simple utilisateur "patrick" lorsque je crée un fichier il est bien marqué comme appartenant à "patrick:users" et j'ai bien que les droits sur mon home !
Foti faire un rapport de bug ? Edit : L'efficacité et la rapidité de cette conteneurisation me font comprendre l'intérêt du "système Docker" et qu'il soit promis à un bel avenir...
j'avais fait un peu de pub pour docker ici : une arch dans un conteneur accessible via vnc si l'on désire le graphique. Mais ce n'est pas le but des conteneurs. On crée un conteneur "système" par exemple une arch, un autre conteneur serveur http, un autre serveur mysql, autre ssh etc... et on les relient entre eux (reseau,fichiers) avec "Docker compose", on crée même des conteneurs de fichiers (volumes) pour avoir des répertoires partagés.
Si je monte Arch dans /mnt puis je lance sudo systemd-nspawn -b -D /mnt , la machine se lance bien et je peux faire la mise à jour d'Arch en conteneur avec l'option -b . Si je monte la partition contenant Arch via Thunar donc dans /run/media/toto/, la machine démarre bien avec l'option -b , mais j'ai cette erreur dès que je lance une commande en sudo:
sudo: le uid effectif n'est pas 0. Est-ce que /usr/bin/sudo est sur un système de fichiers avec l'option « nosuid » ou un système de fichiers NFS sans privilèges root ?
Par contre, sans l'option -b, ça marche... Donc en résumé, pour avoir une machine virtuelle fonctionnelle en TTY avec l'option -b, il faut monter la cible dans /mnt. Pour un simple conteneur, on peut monter la cible via le gestionnaire de fichier sans l'option de boot.
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
je ne pense pas que se soit cela, j'utilise toujours /run/media/... monté avec dolphin aucun problème avec manjaro host(systemd 227) monter une arch (systemd 228) ou l'inverse MAIS je me connecte TOUJOURS en root ! (sans -b tu es toujours en root!) et yaourt est ok avec -b il est possible de se connecter en simple user mais il est alors impossible d'utiliser sudo ou su : on ne peut pas passer en admin dans un conteneur une fois connecté en simple utilisateur ! (sauf si monté dans /mnt ?? ) pour nos besoins : réparation/maj la connexion en simple user n'a pas trop de sens.