#76 Le 13/11/2017, à 23:30
- Babdu89
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonsoir.
Réponse au post#89 en passant les commandes du post#87.
Alors je disais que en activant le nativedisk en commande avec la touche c
j'avais droit au menu vide.
La même chose en passant les commandes du post#87.
Alors comme j'avais vu qu'en activant le nativedisk depuis les menu de SG2D. j'avais accès aux options des menus.
J'ai refait la même manip, mais après avoir activé le nativedisk dans le menu.
Alors, je reviens au menu avec Échap, Option pour avoir les Os de la clé additionnelle.
Après un long temps d'attentes, voila ce que j'ai.
Celui-ci c'est le menu grub de l'Os Xubuntu-efi
je lance.
Un boot info fait depuis le Xubuntu-efi de la clé de tests additionnelle , lancé depuis la clé SG2D en mode UEFI
http://paste.ubuntu.com/25956815/
Il y a quand même quelque chose à comprendre? .
Pourquoi en activant le nativedisk en commande çà bloque les options des menus ? .
@+. Babdu89 .
Dernière modification par Babdu89 (Le 14/11/2017, à 13:50)
J'ai découvert Ubuntu avec la 07.10.... Et alors?!... Depuis je regarde de temps en temps si Windows marche toujours....
Hors ligne
#77 Le 14/11/2017, à 14:23
- malbo
Re : [Expérimental] Super Grub2 Disk sur clé USB
En cours de construction
Procédure pour fabriquer une live USB bootant avec SG2D avec un windows EFI
Cette procédure peut être interessante pour les utilisateurs qui disposent d'un windows 64 bits (ou 32 bits) et d'un bios exclusivement EFI 32 bits pour lesquels UBUNTU ne propose pas de solution.
1) Vérifier que le windows est bien installé en EFI.
Faites la commande msinfo et vérifier que l'élément "mode bios" est bien positionné à la valeur "EFI"
2) Fabriquer une clé USB sans détruire le structure "disque" de cette clé. Je ne peux que citer ce tuto en précisant qe l'idée d'utiliser le mode persistant ne doit pas être exclu.
3) Télécharger le fichier "standalone" de SGD2 a cette adresse https://sourceforge.net/projects/superg … 2.02s10b4/
Voici le lien pour la version 64 bits https://sourceforge.net/projects/superg … I/download
Voici le lien pour la version 32 bits https://sourceforge.net/projects/superg … I/download
4)
Bonjour,
Tu serais bien aimable de créer une nouvelle discussion pour ce nouveau projet. Merci d'avance.
Hors ligne
#78 Le 14/11/2017, à 16:22
- Babdu89
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonsoir.
Alors au sujet des temps d'attente!...
Il m'est venu une idée.
La config;
Machine démarrée en UEFI
Un ssd en MSDos avec un Windows et un Linux.
la clé additionnelle en GPT avec deux Linus qui démarrent en UEFI (partition boot-efi) et Bios Le gacy (partition boot-grub)
la clé SG2D version béta 3, lancée..
Comme j'avais un doute au sujet de la recherche longue.
Recherche sur le ssd avec installations en Bios_Legacy + recherche sur la clé additionnelle avec installations UEFI et Bios_Legacy...
On demande quand même beaucoup à SG2D non?
Aller je fait fonctionner la machine qu'avec les périphériques usb uniquement, démontage du ssd.
Tests en Bios_Legacy de la clé SG2D avec un hdd usb, Msdos , remplis de l'Os en Bios_Legacy;
SG2D affiche tout de suite les menus après utilisation des Options. La recherche répond rapidement.
Tests en Bios_Legacy des clés MultiSystem. SG2D retrouve et affiche de suite à la fin de la recherche.
Test en Bios_Legacy de la clé additionnelle (install UEFI et Bios_Legacy) sans avoir à utiliser le nativedisk depuis les menus.
SG2D trouve les système et indique bien le Système à lancer en mode UEFI. De suite après la recherche.
Comme j'ai aussi fait un CD SG2D avec la béta 3. J'ai le même fonctionnement avec le CD.
Démarrage et tests en mode UEFI
La clé SG2D béta 3 démarrée en UEFI. Avec la clé additionnelle.
Il faut activer le nativedisk depuis les menus, sinon retour direct au menu sans rien indiquer d'autre.
Et là, on retrouve les longs temps d'attente, avant affichage de retour. La recherche sur le ssd ne peut pas être en cause, puisque absent de la config.
Alors je refais le même test avec le CD SG2D béta 3. Les temps d'attentes sont moins long qu'avec la clé, mais plus long qu'en mode Bios_Legacy.
Pour moi. L'iso SG2D béta 3 ne semble pas en cause. Mais son utilisation en mode UEFI depuis un support usb.
J'ai l'impression que je demande trop de choses. Surtout avec une config peu banale.
Mais bon, normalement si on cherche à avoir un outil qui fonctionne dans tous les cas de figures.
Dommage que personne d'autre n'ai testé SG2D depuis une clé usb, sur une machine réelle, avec une config en UEFI que l'on voit habituellement...
@+. Babdu89 .
Dernière modification par Babdu89 (Le 14/11/2017, à 18:41)
J'ai découvert Ubuntu avec la 07.10.... Et alors?!... Depuis je regarde de temps en temps si Windows marche toujours....
Hors ligne
#79 Le 14/11/2017, à 18:48
- Babdu89
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonsoir.
@ ?? .
Tu dis;
Cela va être fait dans une nouvelle discussion que je prépare tranquillement en mettant un brouillon dans cette discussion. (Il sera supprimé lorsque la nouvelle discussion sera ouverte).
Le but sera simple; Installer un ubuntu 32 bits sur une machine EFIi avec SG2D et sera utilisable si l'erreur refind persiste. (pas installable avec la version 32 bits).
Je pense que l'on sort de la config habituelle en mode UEFI que l'on voit souvent.
Un Ubuntu 64 bits installé en UEFI
Ou, un dual boot Windows/ Linux installé en UEFI.
@+. Babdu89 .
J'ai découvert Ubuntu avec la 07.10.... Et alors?!... Depuis je regarde de temps en temps si Windows marche toujours....
Hors ligne
#80 Le 14/11/2017, à 23:49
- adrian15sgd
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonsoir.
Réponse au post#89 en passant les commandes du post#87.
Alors je disais que en activant le nativedisk en commande avec la touche c
j'avais droit au menu vide.
J'ai déjà repondu avec ça:
Si tu veux le faire à la main ça serait:
nativedisk set sg2d_directory="${prefix}/sgd" export sg2d_directory set sg2d_dev_name="${root}" export sg2d_dev_name set secondary_locale_dir="${sg2d_directory}/sgd_locale" export secondary_locale_dir set config_directory="${sg2d_directory}" export config_directory
La même chose en passant les commandes du post#87.
Ces commandes n'étaient pas là pour arranger que les menus se voient. Elles étaient là pour passer pour tous tes dispositifs. Si l'un d'eux faisait crasher le SG2D (avec nativedisk activé) on le saurait.
Il n'y a pas eu de crash donc ce n'est pas ça qui fait coincer / crasher / bloquer ton SG2D quand tu fais la recherche de tous les systèmes avec les options des menus.
Alors comme j'avais vu qu'en activant le nativedisk depuis les menu de SG2D. j'avais accès aux options des menus.
J'ai refait la même manip, mais après avoir activé le nativedisk dans le menu.
Alors, je reviens au menu avec Échap, Option pour avoir les Os de la clé additionnelle.
Avec le 'nativedisk des menus' des variables nécessaires à SG2D sont actualisées et il sait trouver ses propres menues correctement.
Après un long temps d'attentes, voila ce que j'ai.
Celui-ci c'est le menu grub de l'Os Xubuntu-efi
je lance.
Un boot info fait depuis le Xubuntu-efi de la clé de tests additionnelle , lancé depuis la clé SG2D en mode UEFI
http://paste.ubuntu.com/25956815/
Il y a quand même quelque chose à comprendre? .
Apparemment quand on tu passes pour tous tes dispositifs, en montrant son nom et les contenus de ses racines... la detection de tous les OSes ne se bloque pas comme avant.
Je peux développer une option dans le menu 'Extra GRUB2' qui fasse exactement la même chose pour que tu puisse valider que ce celui la le workaround qui fait que sa fonctionne dans ton équipe.
Pourquoi en activant le nativedisk en commande çà bloque les options des menus ? .
@+. Babdu89 .
Déjà expliqué. Il te manque actualiser les variables de SG2D.
Hors ligne
#81 Le 15/11/2017, à 00:08
- adrian15sgd
Re : [Expérimental] Super Grub2 Disk sur clé USB
Pour moi. L'iso SG2D béta 3 ne semble pas en cause. Mais son utilisation en mode UEFI depuis un support usb.
J'ai l'impression que je demande trop de choses. Surtout avec une config peu banale.
Mais bon, normalement si on cherche à avoir un outil qui fonctionne dans tous les cas de figures.Dommage que personne d'autre n'ai testé SG2D depuis une clé usb, sur une machine réelle, avec une config en UEFI que l'on voit habituellement...
@+. Babdu89 .
Je me cite une autre fois:
C'est ce que je disais au début quand tu disais que SG2D ne trouvez pas tes systèmes d’exploitation. C'est ton UEFI qui ne montrez pas tous les UEFIs quand elle démarre depuis un USB.
Ajouté à tout ça, du moment que la BIOS ne donnez pas accès à tous les dispositifs et que tu mets en marche le nativedisk le disque SG2D va employer les drivers du même Grub, les drivers ata, les driver usb. Et ces drivers ne sont pas optimisées comme les drivers BIOS de toute la vie parce que très peux de gens les emploient. C'est aussi simple que ça.
et je remarque qu'ici la confusion est de croir que tu as une config peu banale.
Ce n'est pas le cas!!!
En premier tu emploies un disque usb additionel que peu de personnes emploient pour démarrer.
En second tu as une UEFI qui ne sait pas montrer tous les dispositifs USBs quand elle démarre depuis un dispositif USB. As tu déjà envoyé une plainte pour qui le corrigent?
Et en troisième comme conséquence de ton UEFI (et de ta fixation à faire fonctionner ta clé usb extra) tu doit mettre en marche les 'Native Disk Drivers' de Grub qui ne sont pas les plus stables au monde.
La seule chose pour la quelle tu pourrais te plaigner initialement à mon avis c’était SG2D qui ne montrait pas ses menus correctement après avoir mis en marche la commande nativedisk.
Du moment que ton UEFI n'est pas bien programmé pour montrer tous les dispositifs USBs ça rend tout plus bien compliqué que ne l'est pour le 98% des gents.
Hors ligne
#82 Le 15/11/2017, à 00:30
- adrian15sgd
Re : [Expérimental] Super Grub2 Disk sur clé USB
(Commentaire #76)
Bon, je vais tester la version 2.02s10b3 en mode UEFI avec l'autre machine.
À suivre.Alors je viens de démarrer sur la machine UEFI avec la clé additionnelle branchée. En Bios_Legacy et en UEFI, après avoir activé le "nativedisk" le clavier fonctionne.
Mais je n'ai plus de réponse aux options de recherche des systèmes. Écran noir, pas d'activité dans la config.
Malgré les temps d'attente longs, la v 2.02s10b2 fonctionne mieux.
(Commentaire #94)
Démarrage et tests en mode UEFI
La clé SG2D béta 3 démarrée en UEFI. Avec la clé additionnelle.
Il faut activer le nativedisk depuis les menus, sinon retour direct au menu sans rien indiquer d'autre.
Et là, on retrouve les longs temps d'attente, avant affichage de retour. La recherche sur le ssd ne peut pas être en cause, puisque absent de la config.
Est-ce que tu me confirmes que sur la même machine avec la beta 3 démarré en USB-UEFI et en faisant exactement les mêmes manipulations (activé le nativedisk avec les menus):
* Si le SSD interne est branché tu tombes sur un écran noir et c'est bloquée.
* Si le SSD interne est débranché les menus sont bien montrés.
?
Moi, je pense qu'il y a quelque chose d’aléatoire en tout ça mais si on trouve qu'est-ce qu'il fait le crash on pourra avancer.
Est-ce que peut-être dans ses premiers essaies de la beta 3 (Commentaire #76) tu n'as pas eu de la patience et tu n'a pas attendu suffisamment de temps?
Hors ligne
#83 Le 15/11/2017, à 01:05
- adrian15sgd
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonjour.
Je continue l'action de test. Je pense avoir stabilisé pour un ordinateur et une piste vient de m'apparaitre pour le second.
Je vais essayer de te répondre en détaille après parce que tu semble mélanger trop des trucs.
Si non, j'ai confiance dans mon post actualisé (après ton feedback qui m'a servi becaucoup).
Est-ce que tu peux le confirmer en quelque sorte?
Hors ligne
#84 Le 15/11/2017, à 01:30
- Babdu89
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonsoir.
@adrian15sgd, tu dis;
Est-ce que tu me confirmes que sur la même machine avec la beta 3 démarré en USB-UEFI et en faisant exactement les mêmes manipulations (activé le nativedisk avec les menus):
* Si le SSD interne est branché tu tombes sur un écran noir et c'est bloquée.
* Si le SSD interne est débranché les menus sont bien montrés.
?
Oui, oui.
Moi, je pense qu'il y a quelque chose d’aléatoire en tout ça mais si on trouve qu'est-ce qu'il fait le crash on pourra avancer.
Est-ce que peut-être dans ses premiers essaies de la beta 3 (Commentaire #76) tu n'as pas eu de la patience et tu n'a pas attendu suffisamment de temps?
Alors, demain, je refais le test, et je laisse tourner jusqu'à ce que çà réponde quelque chose.
Ce qui m'a incité à tester sans le ssd, c'est que je ne peux pas contrôler complètement l'activité de la machine.
Je vois bien les led des clés SG2D et clé additionnelle clignoter.
Lorsque les led ne clignotent pas, je constate que la machine chauffe. Donc elle n'est pas au repos en attendant une réponse, mais je pensais qu'elle cherche sur le ssd.
En utilisant la clé SG2D en UEFI. Le ssd débranché, pendant le temps d'attente elle chauffe aussi. C'est donc un indice trompeur. Il y a de l'activité, mais ce n'est pas dans le ssd puisqu'il est débranché.
@+. Babdu89 .
J'ai découvert Ubuntu avec la 07.10.... Et alors?!... Depuis je regarde de temps en temps si Windows marche toujours....
Hors ligne
#85 Le 15/11/2017, à 02:32
- adrian15sgd
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonjour.
Je continue l'action de test. Je pense avoir stabilisé pour un ordinateur et une piste vient de m'apparaitre pour le second.
La procédure que j'ai suivie est la suivante:adrian15sgd a écrit :Démarrer SG2D EFI depuis Windows Boot Manager démarré en UEFI
(...)
Comme je te disais je suis presque sur que ma recette est maintenant prête.
Initialement j'avais tenté de faire une nouvelle entrée "chargeur de démarrage". Son contenu était de ce style
Chargeur de démarrage Windows ----------------------------- identificateur {9f6c0d03-9bc9-11e6-9f19-d050995e0817} device partition=C: path \EFI\SG2D\SG2DX64.EFI description SG2D EFI X64 locale fr-FR inherit {bootloadersettings} recoverysequence {9f6c0d00-9bc9-11e6-9f19-d050995e0817} recoveryenabled Yes bootdebug Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \Windows resumeobject {9f6c0cfe-9bc9-11e6-9f19-d050995e0817} nx OptIn bootmenupolicy Standard
J'y reviendrais certainement car la piste OSDEVICE est prometteuse , Mais il est possible que cela ne soit pas le seul paramètre à modifier. Notons que ni le shimx64 ni refind n'ont pu booter avec cette technique.
Cette technique est la bonne parce que le chargeur de démarrage est exclusif de Windows et est sauvegardé dans le BCD de Windows. Le gestionnaire de démarrage ce sont les différentes entrées qu'on va trouver dans le NVRAM de la UEFI.
Pour éditer ou voir ces entrées on peut employer Rescatux, efibootmgr ou BCDBoot.
Moi je veux l'option qui fonctionne depuis le menu de démarrage de Windows. Et ça c'est un chargeur de démarrage.
Le shimx64 ni le refind n'ont pas pu booter parce que avec:
device partition=C:
path \EFI\SG2D\SG2DX64.EFI
il essaye à chercer C:\EFI\SG2D\SGD2DX64.EFI et ce fichier tu ne l'as pas là.
Je suis donc resté classique et j'ai seulement modifié le " gestionnaire de démarrage" dont le contenu est
Gestionnaire de démarrage Windows --------------------------------- identificateur {bootmgr} device partition=\Device\HarddiskVolume2 path \EFI\SG2D\SG2DX64.EFI description Windows Boot Manager locale fr-FR inherit {globalsettings} bootdebug Yes flightsigning Yes default {current} resumeobject {9f6c0cfe-9bc9-11e6-9f19-d050995e0817} displayorder {current} {769fca8e-a909-11e5-bc16-f1c66d176776} {9f6c0d02-9bc9-11e6-9f19-d050995e0817} {9f6c0d03-9bc9-11e6-9f19-d050995e0817} toolsdisplayorder {memdiag} timeout 30
J'ai fait pas mal de modifications et je pense que la ligne "device partition=\Device\HarddiskVolume2" est celle qui a solutionné le problème. Mais je n'ai pas le souvenir de l'avoir modifiée!
D'abord comme je disais on ne veut pas toucher le NVRAM de l'UEFI. Donc il ne faut paus toucher à le gestionnaire de démarrage.
Cette entrée je soupçonne qu'en initiale permettait de démarrer Windows en cherchant un efi prope à Windows (bootmfgw.efi? je n'en sais rien). Où se trouvait ce bootmfgw.efi ? Dans ta partition EFI qui est le volume 2.
D'ailleurs tu as de la chance que tu as des autres entrées sur la NVRAM de la UEFI pour démarrer le Windows. Si non ta seule entrée Windows Boot Manager (regarde sa ligne description) te servirait non pour booter sur Windows mais sur SG2D. (Bien sur dépuis SG2D tu poudrais en suite booter sur l'efi de Windows).
Nota, pour l'autre micro, je peux booter en bricolant de la façon suivante:
1) Sélectionner un OS Windows qui ne peut pas fonctionner (cela tombe bien , j'en avais un en réserve).
2) Demander sa réparation. (touche F1).
3) Constater que SG2D s'affiche.
4) choisir l'OS qu'on veut parmi les lignes proposées.
Je n'ai pas encore compris pourquoi.
Je soupçonne que l'entrée de SG2D (comme Chargeur de démarrage Windows) doit être configurée sur cette entrée 'Chargeur de démarrage Windows' que tu essaies à démarrer comme recoverysequence.
5) Je vais tenter cela
UEFI :
•BCDBoot copie les fichiers de démarrage sur la partition système EFI ou sur la partition spécifiée par l’option /s.
BCDBoot crée le magasin BCD dans la même partition.
Par défaut, BCDBoot crée une entrée Gestionnaire de démarrage Windows dans la NVRAM sur le microprogramme pour identifier les fichiers de démarrage sur la partition système. Si l’option /s est utilisée, cette entrée n’est pas créée. BCDBoot s’appuie alors sur les paramètres de microprogramme par défaut pour identifier les fichiers de démarrage sur la partition système. Selon la spécification UEFI 2.3.1, les paramètres de microprogramme par défaut doivent ouvrir le fichier \efi\boot\bootx64.efi dans la partition système EFI.
===> Cela n'a rien donné. Je suis de nouveau sous ubuntu et je liste le contenu de la nvram que windows a fabriqué. Il y a une énorme quantité d'options que je n'ai jamais pensé à décortiquer.
u16041@u16041:~$ sudo efibootmgr -v ....... Boot0009* SG2D EFI X64 HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(\EFI\SG2D\SG2DX64.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.a.d.9.3.2.8.e.d.-.c.7.d.1.-.1.1.e.7.-.9.3.6.e.-.4.8.d.2.2.4.6.0.9.a.e.7.}...o................ Boot000B* SG2D EFI X64bis HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.e.9.4.8.a.b.9.2.-.c.8.0.9.-.1.1.e.7.-.a.5.2.7.-.4.8.d.2.2.4.6.0.9.a.e.7.}...o................ Boot000C* SG2D EFI X64bis HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.e.9.4.8.a.b.9.0.-.c.8.0.9.-.1.1.e.7.-.a.5.2.7.-.4.8.d.2.2.4.6.0.9.a.e.7.}...o................ Boot000D* Windows Boot Manager HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)RC Boot000E* SG2D EFI X64bis HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.e.9.4.8.a.b.9.1.-.c.8.0.9.-.1.1.e.7.-.a.5.2.7.-.4.8.d.2.2.4.6.0.9.a.e.7.}...o................ Boot000F* SG2D EFI X64 HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(EFI\SG2D\SG2DX64.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.f.3.4.f.1.2.d.8.-.c.7.9.4.-.1.1.e.7.-.a.5.1.b.-.4.8.d.2.2.4.6.0.9.a.e.7.}...o................ Boot0010* SG2D EFI X64 HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(\EFI\SG2D\SG2DX64.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.f.3.4.f.1.2.d.9.-.c.7.9.4.-.1.1.e.7.-.a.5.1.b.-.4.8.d.2.2.4.6.0.9.a.e.7.}...o................ Boot0012* Windows Boot Manager HD(2,GPT,cede99d7-4497-4328-ab76-0b5344779345,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
Voir mes explications antérieures sur BCDBoot et les entrées NVRAM de l'UEFI.
PROBLEME RESOLU.
La solution fut apportée avec cette commandebcdedit /set "{bootmgr} device partition=\Device\HarddiskVolume2
Non! Ce que tu propose démarre sur SG2D mais ce n'est pas la bonne solution. Pas du tout! Du moment que t'interactionnes avec {bootmgr} tu est entrain de modifier le démarrage par defaut de Windows. Et c'est mieux ne rien toucher là.
A noter que la commande
bcdedit /set "{bootmgr} device partition=A:
a provoqué l'affichage de l'écran de SG2D lorsque je tentais de réparer. ( J'ai répété de nombreuses fois pour en être certain).
Si ta partition système était montée sur A: c'est à espérer. Mais comme je dis il ne faut pas modifier le {bootmgr}.
Remplacer A: par C: ou S: ne faisait pas fonctionner l'écran SG2D.
Et pour quoi devrait-il le faire exactement XD ?
Le fichier n'est pas dans C: ni dans ton S: .
Je ne sais pas la commande qu'il aurait fallu faire si j'avais eu de nombreux disques. J'aurais pu trouver plus rapidement car, avec l'autre micro, il m'avait semblé que c'était la piste.
Cependant, n'étant pas sur de la valeur 2 pour ce micro, j'ai d'abord tenté la valeur 20 qui n'a pas fonctionné
On va voir si je sais l'expliquer.
Du moment que:
* Tu montes la partition système EFI sur la lettre que tu veux
mountvol S: /S
* Et que t'emploies cette lettre pour ton 'Chargeur de démarrage Windows' comme device
fait qu'il soit gardé par derrière comme: partition=\Device\HarddiskVolume2 .
bcdedit /set "{cbfe2a65-d996-11e5-8118-8b921f5b8924}" device partition=s:
où ta partition EFI est la seconde partition.
Nota: Je ne suis pas sûr 100% que HarddiskVolume2 soit garde au lieu de "s:" . J'écris tout ça sans avoir fait les tests. Si Windows garde là "s:" il me décevra.
puis j'ai épuré tous les gestionnaires de démarrage anciens que je ne sais pas encore faire afficher et qui donc deviennent inutiles pour le moment!.
Ok.
DISKPART> list volume N° volume Ltr Nom Fs Type Taille Statut Info ---------- --- ----------- ----- ---------- ------- --------- -------- Volume 0 M DVD-ROM 0 o 0 média Volume 1 C PremierWind NTFS Partition 49 G Sain Démarrag Volume 2 D SavePremier NTFS Partition 47 G Sain Volume 3 O RAW Partition 1628 M Sain Volume 4 F Famille NTFS Partition 5120 M Sain Volume 5 G secondWindo NTFS Partition 49 G Sain Volume 6 H HOMEenNTFS NTFS Partition 4096 M Sain Volume 7 L ISOWINDOWS FAT32 Partition 5120 M Sain Volume 8 N Windows7Pro NTFS Partition 100 G Sain Volume 9 P sdb2 NTFS Partition 40 G Sain Volume 10 Q sdb3 NTFS Partition 10 G Sain Volume 11 R RAW Partition 375 M Sain Volume 12 T SG2D FAT32 Partition 375 M Sain Volume 13 K bidon2 NTFS Partition 20 G Sain Volume 14 S BIDON3 FAT Partition 100 M Sain Volume 15 I MesDonnees NTFS Partition 100 G Sain Volume 16 U RAW Partition 20 M Sain Volume 17 V RAW Partition 35 M Sain Volume 18 J RAW Partition 44 G Sain Volume 19 Récupératio NTFS Partition 450 M Sain Masqué Volume 20 FAT32 Partition 100 M Sain Système Volume 21 NTFS Partition 797 M Sain Masqué Volume 22 E MEMTEST FAT32 Partition 33 M Sain Masqué DISKPART>
Volume 14 S BIDON3 FAT Partition 100 M Sain
Cette partition montée par défaut sur S: fait ton cas intéressant. Maintenant on va savoir quoi faire quand on a si tant de lettres en windows .
Cependant j'ai noté cet échange https://forum.ubuntu-fr.org/viewtopic.p … #p21819935 , Je vais un peu regarder s'il n'y a pas plus simple avec LILIUSBCREATOR .
J’espère mes annotations t'aident à comprendre mieux qu'est que ce tu étais en train de faire.
Finalement l’idéale:
Le UEFI charge les entrées de la NVRAM (Ce que Windows appelle 'Gestionnaires de démarrage').
Normalement un menu n'est pas proposé mais la première des ces entrées est démarré.Disons que cette première entrée est bootmgfw.
bootmgfw si trouve plusieurs entrées dans le BCD montre un menu avec les differentes entrées (Ce que Windows appelle 'Chargeur de démarrage')
Tu trouves l'option pour démarrer SG2D en standalone et ça fonctionne.
Ce que tu semblerait en train de faire:
Le UEFI charge les entrées de la NVRAM (Ce que Windows appelle 'Gestionnaires de démarrage').
Normalement un menu n'est pas proposé mais la première des ces entrées est démarré.Disons que cette première entrée est 'Démarrer SG2D en Standalone' (avec le titre 'Windows Boot Manager')
SG2D en standalone démarre.
Dernière modification par adrian15sgd (Le 15/11/2017, à 22:01)
Hors ligne
#86 Le 15/11/2017, à 02:43
- adrian15sgd
Re : [Expérimental] Super Grub2 Disk sur clé USB
En utilisant la clé SG2D en UEFI. Le ssd débranché, pendant le temps d'attente elle chauffe aussi. C'est donc un indice trompeur. Il y a de l'activité, mais ce n'est pas dans le ssd puisqu'il est débranché.
@+. Babdu89 .
Ça doit être le Grub. Est-ce que tu connais les interruptions? Le OS ne fait rien en attendant l'interruption du clavier, et la CPU est à 0% de activité. C'est le clavier qui fait une interruption, la BIOS la passe à l'OS et celui la se réveille.
Grub n'est pas un OS complet et il me semble n'a pas implémente ses interruptions.
Resultat?
Pour voir s'il y a des données nouvelles sur le clavier la cpu est employée à 100% après un loop éternelle.
Je pense que une chose similaire doit se donner quand Grub espère les donnes que le disque dur lui fourni.
Peut-être dans une machine virtuelle tu pourrais mieux voir si ce que je dis de l'usage CPU est vrai ou non.
Finalement plus d'usage CPU = plus de chauffage .
Hors ligne
#87 Le 15/11/2017, à 12:06
- Bougron
Re : [Expérimental] Super Grub2 Disk sur clé USB
Bonjour
Il serait intéressant de consulter aussi cette discussion https://forum.ubuntu-fr.org/viewtopic.p … #p21825770
Il est probable que certains messages concernant windows et refind disparaissent dans les heures qui viennent
Hors ligne
#88 Le 10/12/2017, à 18:02
- adrian15sgd
Re : [Expérimental] Super Grub2 Disk sur clé USB
Merci à tous pour vous retours sur Super Grub2 Disk.
La prochaine fois que je devrais m’asseoir à écrire la documentation je sais qu'il faut que je parle de comment faire un fake-hybrid et comment faire l'installation depuis le Windows.
Rescapp - Réparer le démarrage. Changer les mots de passe,...
Maintenant je suis centré sur Rescatux. J'ai ouvert un fil pour que vous pouviez me donner des retours sur Rescapp qui maintenant fonctionne sur Ubuntu 16.04 Xenial ou Ubuntu 17.10 Artful.
L'outil devrait pouvoir aider les gents dans ce forum d'Installation. Et en retour vous me donnez du feedback quand les choses ne fonctionne pas comme prevu .
L'idée c'est de pouvoir remplacer boot-repair dans ses options les plus habituelles.
Hors ligne