j’ai modifié l’intitulé du fil en effet, l’user n’a en fait pas d’importance, je pense (sans être tout à fait sûr que ça ne facilite pas les choses que ce soit le même sur les deux systèmes).
Si j’ai bien compris, ma logique conduirait à faire ainsi:
sur sda1, Buster
sur sda2 Librazik
sur sdb1 le point de montage «/home/»
avec: les répertoires «user» suivant:
/home/denis/ avec la configuration de Buster,
et
«/home/invités/*» avec la configuration des invités (pour Librazik), c’est à dire l’accès au groupe «denis» pour les 2 répertoires de musique.
*invité sans accents: «musicos», par exemple 
PS
Je n’ai aucune pratique de virtualisation, mais si j’ai bien compris, ça éviterait d’avoir à redémarrer tout en utilisant l’installation prévue pour le dual boot, une fois ce problème résolu. Par exemple démarrer sur Librazick, et donner l’accès à Denis seulement, pour sa configuration (Buster et /home/denis/). Mais ceci est une autre question…
Ce serait plus facile à gérer avec un serveur de stockage en fait. Un nas en somme, car là la question ne se poserait plus; si ta machine le permettait, tu fait une VM avec le stockage seul, et ton host te sert soit avec librazik soit avec buster.
Car de fait, c’est juste un compte d’accès et donc facile à gérer dans le cadre d’un serveur, alors que dans l’autre cas ce sont deux systèmes qui utilisent le même disque et donc avec des écarts qui rendent la chose très difficile.
Merci beaucoup pour vos réponses.
Je n’ai plus été notifié (il me semble) du coup j’avais mis ce fil de côté (étant donné que j’avais une solution alternative [montage avec chgrp et chmod au lancement de session accordé avec un fstab adéquat]; et j’étais parti sur l’étape suivante qui est en effet un peu ce sur quoi vous me répondez, à savoir l’installation du dual-boot. En me disant que peut-être allait m’apparaître la solution lors du partitionnement et de l’installation du second debian (qui mutera en suite en librazik).
Évidement, ça ne s’est pas passé comme j’imaginais 
et j’ai eu des problèmes 
… Ceci dit je vais faire un fil pour ça car ici ça n’aurait plus rien à voir avec tout ce qui précède et le titre.
Ici je voulais surtout (mais on s’est éloigné en développant le pourquoi du comment) savoir comment (syntaxe), et où (quels fichiers de conf.) écrire que :
Telle partition donnée (ne faisant initialement pas partie du fstab donc [« wasn’t » mounted during installation] si tant est que ça signifie durant l’installation du système et son partitionnement …), pour faire court « extérieure » au système initial, se monte automatiquement comme toute autre partition du système de fichier avec des droits paramétrés et particuliers (par exemple un sticky bit) de mon choix.
J’ai tenté de mettre ces options dans fstab mais ça ne marche pas avec les fichiers linux (ext4 par exemple). Puisque ces options de user (uid=1000, gid=1000, etc) ou umask=… entre en action pour des systèmes de fichiers qui n’ont pas la gestion des droits linux, comme vfat.
J’ai tenté des règles udev avec la syntaxe udev dans le répertoire de conf. d’udev (et un fichier /etc/udev/rules.d/10-local.rules :
# KERNEL=="sdb" SUBSYSTEM=="block" ATTR{size}=="488397168" OWNER="denis" GROUP="denis" MODE="1775"
# KERNEL=="sdb" SUBSYSTEM=="block" ATTR{size}=="488397168" OPTIONS="rw,user,relatime,last_rule"
Peut-être des erreurs de syntaxe, j’ai commenté ces lignes puisque ça ne fonctionnait pas. Mais c’est un peu ce que je cherchais à faire à la base.
En revoyant ça je m’aperçois que KERNEL==« sdb » c’est un peu lège pour désigné la partition voulue (exemple sdb8), si l’idée est réalisable avec une règle udev, ça peut venir de cette mauvaise définition …
Si ça vient de là et que quelqu’un comprenant l’idée peut me donner la bonne syntaxe par l’exemple, je serais ravi 
je réponds à vos réponses (merci encore) :
Alors je pouvais mettre ça en place à un moment ou un truc du genre, mais je ne souhaite pas de serveur, ni d’invités. dans la conf de base de mes deux systèmes.
On pourrait même imaginé un serveur mp3, un nextcloud, des trucs ainsi mais j’ai un peu laissé tomber. Librazik c’est plutôt une utilisation très occasionnelle, la plupart du temps je veux booter sur kde (jusqu’à ce que l’envie me prenne de faire du son).
C’est vraiment deux config différentes, et à part pour faire de la zik, il me faut debian kde ou autre pour mon utilisation et mon confort quotidiens.
Un peu la même réponse je te fais Zargos. j’ajoute :
Pour l’instant là, j’utilise maintenant deux ssd, un kde et un librazik. J’ai eu quelque souci à l’install du second noyau qui est venu se mettre à l’endroit où je ne voulais pas (cad dans /boot/efi de sda1 alors que je lui avais préparé un /boot/efi sur sdb1.
Mais je ne m’étends pas, je ferais sans doute un fil demain car si ça fonctionne là maintenant, c’est pas hyper propre, ça me gène un peu.
Sûrement pas. C’est absurde.
Spécifiées dans /etc/fstab qui est dans la partition racine. Question : comment fais-tu pour avoir deux fichiers /etc/fstab distincts dans la même partition racine ?
Sticky bit sur le répertoire pour empêcher la suppression des fichiers appartenant à un autre utilisateur. Permission en écriture classique sur les fichiers pour empêcher la modification des fichiers appartenant à un autre utilisateur.
Les permissions dans un système de fichiers POSIX comme ext4 sont intrinsèques à celui-ci et ne sont pas définies par des options de montage. Changer les permissions sur le disque ou la partition /dev/sdb* n’a pas d’effet sur les permissions du système de fichiers.
Mais tout cela n’est efficace que si les utilisateurs ont des UID distincts, quels que soient leurs noms dans chaque système. S’ils ont le même UID (par exemple 1000 qui est l’UID par défaut du premier utilisateur créé dans Debian), alors ils sont considérés comme le même utilisateur et ont les mêmes permissions.
Debian n’installe pas ses noyaux dans /boot/efi (point de montage de la partition système EFI) mais dans /boot. C’est uniquement le chargeur d’amorçage GRUB qui est installé dans /boot/efi.
bonsoir
Je te le fais pas dire, j’ai dû mal m’exprimer.
Et bien parce que c’est absurde d’avoir le même / , on va donc dire sur le même ssd;
par conséquent j’avais (je parle au passé parce que j’ai fini par faire différemment) deux / sur le même ssd. Je m’y prenais mal sans doute mais ça semblait pouvoir fonctionner, c’est pas là-dessus que je butais.
par exemple voici deux fstab sur le même ssd!
sda1 /boot/efi
sda2 /
sda3 /var
sda4 /tmp
sda5 swap
sda6 /home
+ 80 Go d'espace libre, partitionné lors d'une deuxième installation :
sda7 /boot/efi (là ça coinçait car il faut un seul efi par volume, donc le noyau est venu écraser sda1 et sda7 est resté vide.
sda8 /
sda9 /var
sda10 /tmp
sda11 swap
sda12 /home
Je pense que ça aurait pu fonctionner, finalement j’ai fait autrement tout en rencontrant des problèmes. Mais restons sur ce schéma, c’est viable comme ça ?
Ah, mais là encore je voulais bien dire changer les permissions sur une partition donnée (et au montage de celle-ci), pas sur le système de fichier.
Ah bon ? oui mais le problème c’est que le sdb en question se monter en root:root
c’est bien ça mon souci, comment le monter, au démarrage, en denis:denis par exemple ? (Car dans fstab ou udev rules, je suis pas parvenu à le paramétrer.)
Tout à fait, j’ai vu par la suite. Je ne veux pas développer car ça va encore apporter à la confusion, car en vérité now j’ai un autre schéma que donné ci-dessus (fstabs). J’aimerais bien savoir si les deux systèmes sur le même ssd, c’est viable, ou si c’est scabreux.
NB: pour ce qui est de l’UEFI, j’ai pentaillé pour le désactivé dans la CM . Si j’avais vraiment su que c’est un truc microsot, carrément j’aurais installé en legacy, un truc normal comme avant. Mais bon là, j’ai deux noyaux installés en mode uefi et je fais avec, je le saurai pour une prochaine fois.
En fait j’aurais plutôt fait les /boot/efi en sda2 et sda8, et les racines en 1 et 7
d’ailleurs je me demande, en passant, si on peut faire deux partions primaires non continues (1 et 7) … Ou si c’est pas gênant d’avoir une seule primaire, mais un deuxième OS sur une étendue (sda7)…
Non, on peut créer plusieurs partitions EFI sur un même disque. Chaque système instalé peut utiliser une partition EFI différente.
Le noyau n’écrase rien du tout. L’installateur Debian utilise la première partition EFI marquée « utiliser comme : partition d’amorçage EFI », il faut donc marquer les autres comme « ne pas utiliser ». En tout cas il ne formate pas ni n’écrase pas le contenu d’une partition EFI existante, sauf s’il provient d’une précédente installation de Debian.
Oui. Mais avec autant de partitions, j’aurais plutôt opté pour LVM pour tous les volumes Linux (excepté les partitions EFI).
Et je redis que ça ne sert à rien, ni au montage ni avant ni après.
« Monter en x:x » ne veut rien dire. Il y a d’un côté l’utilisateur qui monte le système de fichiers (généralement root), et d’un autre côté le propriétaire de la racine de ce système de fichiers (modifiable avec chown). Et il n’y a aucun rapport entre les deux.
Aucune importance. Personnellement j’aurais fait les deux partitions EFI en sda1 et sda2 au début du disque (ou une au début et l’autre à la fin), ainsi tout le reste de l’espace est libre et contigu pour le reste sans avoir une partition EFI qui traîne au milieu.
Eviter le format DOS et privilégier le format GPT pour l’amorçage EFI (et même pour l’amorçage BIOS si possible).
En format DOS et amorçage BIOS, éviter de mettre /boot dans une partition logique.
C’est là que le bas blesse, car puisque je j’installais un second noyau identique, c’est passé pour une installation précédente Debian. Toutefois je note que j’avais clairement dû faire une fausse manip lors de la deuxième install, je n’ai pas dû être vigilant au fait que le premier /boot/efi n’était vraisemblablement pas marqué comme « ne pas utiliser ».
Je te rappelle que lors de ces manips, j’avais encore le boot secure activer, avec démarrage en « uefi uniquement » (dans bios), tu maintiens. J’ai pourtant lu le contraire quelque part. Mais soit.
Ok. N’ayant jamais utilisé LVM je n’ai pas voulu explorer ce qui me semblait déjà aventureux en terme de partitionnement.
Oui root au boot forcément . Mais comment faire que root monte la partition pour le compte de Toto ? possible ? sans avoir un recours ultérieur à chown .
Très bien, je note la logique.
Intéressant. Il se trouve que je suis au format GPT, pourtant [edit: heu, forcément, gparted 
] et non DOS (cependant /boot/efi sont des partoche vfat). GPT c’est bien ce qui est noté dans les fichiers de Grub qui configure de pointer vers tel ou tel volume pour trouver /usr et / .
Quoiqu’il en soit comme je ne comprenais pas bien pourquoi ça ne fonctionnait pas ma deuxième install (menu grub avec seulement la deuxième proposée mais c’est une autre histoire qui touche à Grub que peut-être je soulèverai dans un fil plus tard), ma config utilise maintenant les deux disques. Un pour chaque système, à la base c’est plus simple quand on maîtrise pas.
$ sudo /sbin/fdisk -l /dev/sda /dev/sdb
Disque /dev/sda : 111,8 GiB, 120034123776 octets, 234441648 secteurs
Modèle de disque : KINGSTON SA400S3
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 0F480ADA-287E-49BF-9A30-8C8FBA4341DD
Périphérique Début Fin Secteurs Taille Type
/dev/sda1 2048 3905535 3903488 1,9G Système EFI
/dev/sda2 3905536 23437311 19531776 9,3G Système de fichiers Linux
/dev/sda3 23437312 42969087 19531776 9,3G Système de fichiers Linux
/dev/sda4 42969088 52733951 9764864 4,7G Système de fichiers Linux
/dev/sda5 52733952 56639487 3905536 1,9G Système de fichiers Linux
/dev/sda6 56639488 58593279 1953792 954M Partition d'échange Linux
/dev/sda7 58593280 117186559 58593280 28G Système de fichiers Linux
/dev/sda8 117186560 234440703 117254144 55,9G Système de fichiers Linux
Disque /dev/sdb : 232,9 GiB, 250059350016 octets, 488397168 secteurs
Modèle de disque : CT250MX500SSD1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 2EAC6AAE-3146-479C-A366-7A18A079D999
Périphérique Début Fin Secteurs Taille Type
/dev/sdb1 2048 2148351 2146304 1G Système EFI
/dev/sdb2 2148352 19726335 17577984 8,4G Système de fichiers Linux
/dev/sdb3 19726336 66600959 46874624 22,4G Système de fichiers Linux
/dev/sdb4 66600960 84178943 17577984 8,4G Système de fichiers Linux
/dev/sdb5 84178944 86132735 1953792 954M Système de fichiers Linux
/dev/sdb6 86132736 88086527 1953792 954M Partition d'échange Linux
/dev/sdb7 88086528 117383167 29296640 14G Système de fichiers Linux
/dev/sdb8 117383168 195508223 78125056 37,3G Système de fichiers Linux
/dev/sdb9 195508224 488396799 292888576 139,7G Système de fichiers Linux
sudo blkid /dev/sda /dev/sdb
/dev/sda: PTUUID="0...d" PTTYPE="gpt"
/dev/sdb: PTUUID="2...9" PTTYPE="gpt"Je répète que l’installation d’un noyau Debian ne touche pas à la partition EFI.
Il faut aussi faire attention à cela avec les partitions de swap, sinon l’installateur Debian reformate toutes les partitions de swap marquées « utiliser comme : swap » par défaut.
Mais Grub oui, et c’était le souci (puisqu’il n’est pas venu se poser sur le nouveau /boot/efi mais sur l’ancien du système kde …
Et effectivement , j’avais bien mais noyaux distincts dans leur /boot respectifs.
Oui pour la swap j’avais percuté sur le moment.
NB: le fdisk ci-dessus n’est pas la description du schéma de partitionnement dont on parle. Je le donne juste à titre indicatif.
(C’est au final ce que j’ai fini par faire).
Concrètement Pascal,
comment, en bootant sur sda (kde) je peux faire en sorte que :
- sdb9 se monte automatiquement dans un répertoire de sda8
- et même, que l’user dans kde ait les droits en écriture dans les dossiers (création de fichiers possible) de sdb9 mais pas dans les fichiers (modifications de fichier interdite hormis ceux qu’il a lui-même créés).
Autre chose, je ne me souviens plus les solutions avec fuse et merge je crois, pour monter différents répertoires de différentes partitions dans un répertoire donné, si on pouvait me redire la commande les paquets (+ que fuse)
nb: sb9, /home/user/projets, sda8 /home, répertoire: /home/user/Musique
Il n’est pas forcément nécessaire de créer deux partitions EFI, et même quand c’est le cas, ce n’est pas forcément suffisant. De deux choses l’une : soit les deux systèmes s’identifient auprès de GRUB avec le même nom (« debian »), soit ils s’identifient avec des noms différent (« debian » et par exemple « ubuntu »). Dans le second cas, il est inutile de créer deux partitions EFI car les deux car le GRUB de chaque système sera installé dans un répertoire différent. Dans le premier cas, il faut prendre en compte que l’installation de GRUB en mode EFI comprend deux opérations :
-
l’installation des fichiers dans la partition EFI montée sur /boot/efi
-
la création ou la mise à jour de l’entrée d’amorçage EFI stockée dans la mémoire non volatile de la carte mère qui indique au firmware UEFI comment démarrer GRUB.
Le nom de l’entrée d’amorçage EFI est l’identifiant du système passé à GRUB (« debian » pour Debian). Donc si les deux systèmes ont le même identifiant, même s’ils utilisent des partitions EFI distinctes ils créeront et modifieront la même entrée d’amorçage EFI qui pointera vers le dernier GRUB installé. Certes quand on installe GRUB manuellement on peut forcer un identifiant différent, mais on ne peut pas le faire dans l’installateur. D’autre part ça ne fonctionne pas avec la variante de GRUB signée pour le secure boot qui est installée par défaut car elle s’attend à être installée dans un répertoire EFI/debian codé en dur.
Déjà répondu : avec /etc/fstab, comme n’importe quel autre système de fichiers à monter automatiquement au démarrage. Tu peux même le faire à l’installation lors du partitionnement.
Déjà répondu aussi : en gérant les utilisateurs et les permissions.
- Les deux utilisateurs doivent avoir des UID distincts.
- Les répertoires doivent être accessibles en lecture et écriture à tout le monde ou à son groupe propriétaire dont les deux utilisateurs doivent être membres (dans les deux systèmes, donc avec le même GID).
- Les répertoires doivent avoir le « sticky bit ».
Peux-tu préciser ? Il est possible de monter un répertoire quelconque sur un autre répertoire quelconque avec l’option --bind de mount (option « bind » dans /etc/fstab). A moins que tu veuilles parler de montage en union (union mount) comme overlayfs (intégré au noyau depuis stretch ou via FUSE), unionfs (via FUSE), aufs (patch externe du noyau nécessaire)… ?
unionfs il me semble que c’est ça à un moment que j’avais utilisé. Merci pour toute les précisions, je lirai tout bien demain. Bonne soirée.
Bonjour,
Je suppose qu’on a pas le choix de nommer le système au moment de l’installation via l’assistant ? Et puisque dans mon cas c’est deux systèmes Debian avant modifs, il me fallait deux partoches efi. Ou alors, avant l’installation du second debian, je manipulais Grub afin de renommer le premier système en place. Dans ce cas, je n’ai pas bien compris comment je peux faire.
Pas en rajoutant des entrées menus dans /etc/grub.d/40_custom car effectivement j’ai nommé deux nouvelles lignes dans le menu au boot mais elles sont en fin de liste, et j’ai toujours les premières lignes de ce menu qui concerne debian + mode recovery qui pointent toutes vers sdb. (tandis que mes menu entry rajoutées, c’est ok). Mais je ferai un autre fil pour ce sujet, si je trouve pas.
Là par contre c’est plus clair. J’expérimenterai comme ça alors, faut juste que je crée un groupe propriétaire commun aux deux systèmes, ou même pas, ajouter les deux utilisateurs au groupe « audio » suffira, rendre audio groupe propriétaire, et poser un sticky bit sur la partition, je suppose que je vais faire ça avec gparted … À confirmer.
Merci beaucoup.
Juste parce que je suis en train de lire des trucs dessus, l’utilisation d’un docker ne pourrait-il pas répondre plus simplement à ton problème?
du coup, pas besoin de deux systèmes. Juste Librazik. en considérant que celui-ci permet d’installer docker bien évidement. les mises à jour de docker ne sont pas forcement à faire avec une version actuelle stable. et du coup, tu as un docker debian qui te permet de faire le reste.
Si un connaisseur docker peut nous éclairer?
je sais pas quoi dire …
je crois pas non … Pomper la mer quand le radeau prend l’eau …
à mon avis rien à voir, et incompatible.
Tu veux dire via l’installateur Debian ? Non.
Ça ne suffit pas. Il y a bien deux GRUB qui ne s’écrasent pas l’un l’autre, mais une seule entrée d’amorçage EFI qui pointera vers celui installé dans la partition EFI qui était montée lors de la plus récente exécution de grub-install. On doit créer une entrée d’amorçage EFI pour l’autre avec efibootmgr.
On peut modifier l’identifiant du système spécifié par la variable GRUB_DISTRIBUTOR dans /etc/default/grub puis exécuter grub-install, mais la variante de GRUB signée pour le secure boot qui est installée par défaut ne fonctionne que si elle est installée dans EFI/debian. Pour installer la variante non signée il faut désinstaller les paquets pour le secure boot (grub*signed*, shim…) ou exécuter grub-install avec l’option --no-uefi-secure-boot.
A condition que le groupe « audio » ait le même GID dans les deux systèmes.
Oui
Merci pour toutes ces réponses pointues. 
je manquerai pas de mettre en résolu lorsque j’aurai appliquer tout ça, mais pas pour l’instant, pas le moment.