Vous n'êtes pas identifié(e).
Dernière modification par Belfaigore (27-06-2017 13:21:58)
Hors ligne
Dernière modification par daufinsyd (20-06-2017 14:48:24)
Portable i7 7700HQ, 16Go RAM, GTX 1050Ti, MX 500 Crucial
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero
Hors ligne
Hors ligne
Oui effectivement le principe est simple ; un peu comme si on voulait installer Windows + Debian + MacOs sur un PC par exemple ... je retiens l'idée.
excactement
GRUB est "juste" un chargeur d'amorçage, ce n'est pas possible (à ma connaissance). Cela dit on peut imaginer proposer un menu lancé une fois le système booté qui te demanderait quel mode lancer (ou bien utiliser 3 sessions différentes qui lors de la connexion lancent chacune un des logiciels).
C'est possible pour /home, /boot et sans doute /tmp mais c'est tout. Si tu installes trois distribs avec la même racine elles vont se marcher dessus
Portable i7 7700HQ, 16Go RAM, GTX 1050Ti, MX 500 Crucial
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero
Hors ligne
Hors ligne
SDDM me semble intéressant
Il vraiment joli ( et personnalisable ! )
d'ailleurs je viens à l'instant de lui faire une page dans le wiki
Portable i7 7700HQ, 16Go RAM, GTX 1050Ti, MX 500 Crucial
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero
Hors ligne
GRUB est "juste" un chargeur d'amorçage, ce n'est pas possible (à ma connaissance).
GRUB peut passer des options à la ligne de commande du noyau.
Traditionnellement (avant systemd), on pouvait passer le runlevel dans lequel on voulait démarrer le système, et chaque runlevel démarrait un ensemble de services. Dans certaines distributions (pas Debian), il y avait un runlevel pour le démarrage en mode graphique et un autre pour le démarrage en console.
Je n'ai pas regardé de près, mais il doit y avoir l'équivalent de tout cela dans systemd.
Par contre la génération automatique des entrées de menu supplémentaires par les scripts de /etc/grub.d/ ne va pas être de la tarte.
(Partitions communes à plusieurs installations)
C'est possible pour /home, /boot et sans doute /tmp mais c'est tout.
Je déconseille fortement le partage de /boot entre plusieurs installations. C'est un coup à perturber GRUB.
Dernière modification par raleur (20-06-2017 20:21:35)
Il vaut mieux montrer que raconter.
Hors ligne
Je n'ai pas regardé de près, mais il doit y avoir l'équivalent de tout cela dans systemd.
Ha oui autant pour moi ! Ce sont les target sous systemd.
Portable i7 7700HQ, 16Go RAM, GTX 1050Ti, MX 500 Crucial
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero
Hors ligne
Dernière modification par Belfaigore (21-06-2017 13:20:45)
Hors ligne
Portable i7 7700HQ, 16Go RAM, GTX 1050Ti, MX 500 Crucial
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Les modifications directes du fichier /boot/grub/grub.cfg seront écrasées à la prochaine exécution de update-grub.
Pour que ce soit update-grub qui crée ces entrées de menu, il faut modifier (ou dupliquer et modifier les copies) /etc/grub.d/10_linux.
ça confirme ce que je pensais, mais j'ai regarder le '10_linux', c'est nettement moins simple a comprendre que le grub.cfg, je ne trouve pas comment renommer l'entrée, ni comment organiser le menu sans sous menu, juste avec 3 entrées, ni comment il gère le recovery
Hors ligne
dans le fichier /etc/default/grub.
Toutes les entrées qui étaient dans un sous-menu (normal, dépannage et toutes les versions de noyau) seront directement dans le menu principal.
L'entrée dépannage/recovery (avec le paramètre "single" dans la ligne de commande du noyau) est générée si l'option
du même fichier est absente ou commentée.
Source : https://www.gnu.org/software/grub/manual/grub.html
Note : Il y a une certaine confusion sur la valeur à donner aux variables booléennes du fichier /etc/default/grub. Parfois "true", parfois "y"... Si cela ne fonctionne pas avec l'une malgré ce que dit la documentation, essaye avec l'autre.
Dernière modification par raleur (21-06-2017 15:05:04)
Il vaut mieux montrer que raconter.
Hors ligne
2. Dans la suite du fichier, le libellé de l'OS (je veux pas afficher la version de linux, juste Debian) j'ai mis en commentaire les lignes 41,42,44-48
3. Modification de la fonction 'linux_entry()' dont le rôle est de produire, les entrées affichées dans le GRUB, le paramètre $3 correspondant au type nous interresse il informe la méthode s'il s'agit d'une entrée simple ou recovery ... et si on lui ajouter le mode 'console' ; la méthode génére également les libellés ; j'ai mis en commentaire les anciens codes (lignes 124, 127, 130 + commentaire en 112)
4. Le reste se passe en fin de fichier, quand le script crée les entrées du menu GRUB, l'idée étant de reprendre le principe du recovery (avec desactivation), et de placer la console au dessus (dans le menu) , donc on va utiliser une variable 'GRUB_DISABLE_CONSOLE' qu'on mettra dans le /etc/default/grub si on veut pas la console et pour l'entrée, on utilisera la variable qu'on a crée plus haut (j'ai ajouter les lignes 364-367)
5. Voilà, j'aurai pu m’arrêter là, mais "qu'y-t-a" flinguer une après-midi par 37°C autant aller au bout de ce que je veut faire, a savoir, n'afficher le GRUB que si [Shift] est appuyé, donc mise en place d'un fichier /etc/grub.d/50_hidemenu
merci au post de 'tux1c' sur askubuntu https://askubuntu.com/questions/117525/ … his-happen
6. Et voilà plus qu'a mettre à jour /etc/default/grub et faire un 'update-grub' et le tour est joué
Et pour reprendre une réplique de "Le coeur à ses raisons - scene de Beky avec le téléphone" ... "Et ben voilà, c'était pas si compliqué".
Bon pour ceux qui souhaite refaire mes manipulation ... j'espère que je n'ai rien oublié dans ce post ... sinon dommage pour vous, car chez moi ça marche bien
Hors ligne