bonjour
je me trouve dans une situation ou j'ai trois pc portables disposant d'une quantité d'information assez grande (des dizaines de Gigas) et je vais devoir m'en servir à distance, car je ne serai pas à proximité pendant plusieurs mois.
Or, ces 3 pc ont un dual boot linux/windows via grub2.
Je dispose d'un logiciel de controle à distance sur chacun des deux systèmes. Or, ce dont je ne dispose pas, c'est d'une procédure simple pour passer de windows à linux sans être présent lors du grub (en tout logique..)
Je souhaitais donc savoir, car j'imagine que rien n'existe pour controler grub à distance, surtout qu'ils sont en wifi… si il est possible d'avoir un système de sélection différente du démarrage par incrémentation d'allumage. Je m'explique :
j'ai deux entrées windows et linux. Je démarre sous windows. Ce que je souhaite, c'est que tous les trois démarrages, le choix soit porté vers l'un, puis l'autre. Au bout de trois démarrages sous linux, grub redirige le démarrage vers windows. Pareil sous windows, trois démarrage, puis rebelotte à la situation de départ.
L'idée étant, de pouvoir passer d'un système à l'autre à distance en utilisant le redémarrage de la machine (qui peut se faire à distance) comme interrupteur au bout d'un certain nombre d'essais, car changer de sélection au menu ne peut se faire à distance.
Mon idéal étant d'utiliser quand je le souhaite l'ordi sous nux, puis sous windows, au travers de mon logiciel de controle à distance (fonctionnel sur les deux systèmes), sans me retrouver bloqué sous windows, ni sous linux, lorsque j'ai besoin du système qui n'est pas en choix par défaut..
auriez vous des idées?
merci :)
# VM ?
Posté par Colargol . Évalué à 3.
Une autre solution serait de monter le Windows dans une VM du Linux comme indiqué ici : https://opensource.com/article/21/1/virtualbox-windows-linux
[^] # Re: VM ?
Posté par Graveen . Évalué à 4.
ou un hyperviseur type 1 qui peut lancer Windows et Linux en simultané (Xen ou KVM)
# choix grub
Posté par _kaos_ . Évalué à 5. Dernière modification le 30 mai 2021 à 06:57.
Salut,
Je trouve ça moyennement satisfaisant, mais
grub-reboot
permet de spécifier le prochain choix à grub (éventuellement autre que celui par défaut).Donc tu pourrais avoir linux par défaut, et choisir de redémarer sous windows sinon depuis linux, manuellement.
Évidement, il ne faut pas que windows redémarre tout seul comme un grand, mais ça, c'est une autre histoire :)
Post SO
Matricule 23415
[^] # Re: choix grub
Posté par NeoX . Évalué à 3. Dernière modification le 30 mai 2021 à 11:17.
cette solution me semble aussi la meilleure,
si tu es le seul a utiliser la machine, tu actives linux en démarrage par defaut
donc le PC demarre toujours sous linux, sauf si depuis linux tu fais le
grub-reboot XYZ
qui va lui dire de rebooter sous windows.attention quand meme, si tu as des disques partagées entre windows et linux, parfois un reboot windows -> linux peut rendre le disque inutilisable car pas vraiment "libéré" par le windows.
[^] # Re: choix grub
Posté par Psychofox (Mastodon) . Évalué à 3.
Pour les partages d'un volume NTFS il faut désactiver l'équivalent de l'hibernation (je ne me rappelle plus le nom spécifique dans windows 10) car par défaut windows 10 ne fait pas un arrêt normal mais l'équivalent d'une hibernation donc en gardant le fs dans un status monté.
# UEFI
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 30 mai 2021 à 11:23.
Si ils sont sous UEFI, il te faudrait faire les entrées Windows et Grub proprement dans ton UEFI (Grub lançant Linux par défaut).
Ensuite dans chaque OS tu devrais pouvoir dire 'reboote sous telle entrée UEFI'.
Sous Linux il y a
efibootmgr
qui le fait, et je te laisse chercher sous Windows (mais ça doit bien exister).En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: UEFI
Posté par totof2000 . Évalué à 1.
Bof, dans la mesure ou en général, Wondows se considère comme le seul 0S installé sur la machine, c'est pas sûr que ça marche. Sinon, est-ce que ça marche si le système dispose d'1 seul disque partitionné Windows/Linux ?
[^] # Re: UEFI
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 30 mai 2021 à 16:16.
Le fait que Windows se considère comme seul n'a d'effet que lors de la procédure d'installation où il aura facilement tendance à casser le reste. Mais une fois ton double boot effectif, Windows ne te gênera plus. Ila s on propre bootloader, c'est tout ce qui l'intéresse.
Oui. Pour info Grub ne lance pas Windows, Grub lance de bootloader de Windows, exactement comme le fait UEFI. Donc si tu as un double boot via Grub, tu peux avoir un double boot via UEFI.
Après, reste la question de "y a-t-il un utilitaire" ?
Oui : https://www.easyuefi.com/faq/en-US/EasyUEFI-Command-Line.html (première entrée de ma recherche Google).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: UEFI
Posté par _kaos_ . Évalué à 2.
Et des MaJ (éventuellement automatiques) :)
Le choix du boot par UEFI est peut-être plus robuste à ce niveau, je n'en sais rien.
Matricule 23415
[^] # Re: UEFI
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 30 mai 2021 à 16:52.
Ça ne change rien à l'installation, c'est juste un paramètre de plus dans UEFI.
Si Windows veut tout casser (bon, moi j'ai jamais vu ça depuis des années que je maintiens mon double boot mais admettons), il le fera quand même. Mais là on parle du problème générique du double-boot Windows/Linux, pas d'ajouter une entrée supplémentaire dans UEFI.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: UEFI
Posté par totof2000 . Évalué à 1.
Moi non plus, j'ai plus de windows (enfin si, j'en ai de nouveau un depuis peu), mais j'ai vu des messages passer dans les forums, indiquant que leur Linuix ne démarrait plus suite à des mises à jour.
Après le problème a peut-être été corrigé, ou c'était un accident, mais il me semble que c'est arrivé.
[^] # Re: UEFI
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
Je pense que ça dépend beaucoup de l'implémentation au niveau du firmware UEFI.
Vu récemment sur une permanence LUG, un système qui disait oui-oui à toute modification des paramètres via
efibootmgr
, mais qui s'obstinait à chaque fois à démarrer Windows, quelle que soit la configuration spécifiée. Sur une install party, j'ai également vu des firmwares qui se vautraient avec des erreurs mémoire quand on essayait de manipuler les entrées, par exemple pour… les afficher ! (Genreefibootmgr
était OK maisefibootmgr -v
explosait dans tous les sens.)Voir également le besoin assez classique d'utiliser l'astuce du removable media path.
Bref, sur le papier, ça pourrait être une excellente piste. Dans la réalité, les implémentations sont… tout autant plein de bogues que l'étaient les BIOS historiques.
:(
Debian Consultant @ DEBAMAX
[^] # Re: UEFI
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 30 mai 2021 à 17:07.
Ah bin d'ailleurs il n'y a même pas besoin d'un utilitaire sous Windows en fait :)
Chez moi j'ai les deux entrées UEFI, et c'est bien évidemment Grub est lancé par défaut (et qui propose à son tour le double boot, ce que j'utilise normalement quand je veux aller sous Windows). Et Grub par défaut lance Linux (normal).
Avec un
sudo efibootmgr -n 0 && reboot
je reboote bien sous Windows (cette commande c'est du one shot, ça met une variable UEFI valable uniquement pour le boot suivant).Si je reboote depuis Windows, il repartira sous Linux (puisque c'est par défaut Grub qui est lancé par UEFI, et que Grub par défaut lance Linux).
Donc le seul truc que je ne puisse pas faire à distance ce serait de rebooter directement de Windows à Windows, il me faudrait alors repasser par Linux.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Y a pas mal de solutions différentes
Posté par ptit_poulet . Évalué à 1.
En cherchant vite fait je suis tombé là-dessus.
Regarde le dernier post ;)
Je crois qu'il y a vraiment pleins de possibilités par rapport à ton "problème".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.