[RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

maxire · Le 21/02/2018, à 11:09

Solution:

info grub a écrit :

5.1.2 Chain-loading an OS
-------------------------
Operating systems that do not support Multiboot and do not have specific
support in GRUB (specific support is available for Linux, FreeBSD,
NetBSD and OpenBSD) must be chain-loaded, which involves loading another
boot loader and jumping to it in real mode.
The 'chainloader' command (*note chainloader::) is used to set this
up. It is normally also necessary to load some GRUB modules and set the
appropriate root device. Putting this together, we get something like
this, for a Windows system on the first partition of the first hard
disk:
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}

Tu recherches le bloc de commandes équivalent pour Vista dans /etc/grub/grub.cfg et tu le copies dans /etc/grub.d/40_custom en n'oubliant pas de supprimer la ligne parttool et sans supprimer les premières lignes de code déjà présentes en tête de 40_custom.
Tu désactives alors osprober puis update-grub.

Ce bloc de commandes ne réalise pas la découverte de Windows, elles servent à son lancement.

WinUbuntu-43 · Le 21/02/2018, à 19:40

maxire a écrit :

Tu recherches le bloc de commandes équivalent pour Vista dans /etc/grub/grub.cfg et tu le copies dans /etc/grub.d/40_custom en n'oubliant pas de supprimer la ligne parttool et sans supprimer les premières lignes de code déjà présentes en tête de 40_custom.
Tu désactives alors osprober puis update-grub.
Ce bloc de commandes ne réalise pas la découverte de Windows, elles servent à son lancement.

En suivant tes conseils, j'ai tapé la commande

sudo gedit /etc/grub.d/40_custom

afin d' avoir accès à ce fichier et j'ai inscrit le menu de démarrage de windows

menuentry 'Windows Vista (loader) (sur /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-52D0377CD03764FF' {
insmod part_msdos
insmod ntfs
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 52D0377CD03764FF
else
search --no-floppy --fs-uuid --set=root 52D0377CD03764FF
fi

chainloader +1
}
set timeout_style=menu
if [ "${timeout}" = 0 ]; then
set timeout=10
fi

Je ma suis assuré que:

parttool ${root} hidden-

n'y soit pas.
J'ai tapé la commande:

sudo gedit /etc/default/grub

afin d'écrire la ligne pour désactiver la recherche de nouveaux OS

GRUB_DISABLE_OS_PROBER=true

puis la commande:

sudo update-grub

J'ai redémarré le système et maintenant je peux sélectionner soit ubuntu , windows, ainsi que les modes de réparation ou test mémoire proposés par grub, et cette fois, après chaque

sudo update-grub

mon option windows reste dans le menu de grub et on peut booter avec.

Cette fois, vous saurez que le problème de démarrage peut être résolu sans devoir ré installer ubuntu en créant les partitions manuellement.
Un grand merci à toi maxire.

enebre · Le 21/02/2018, à 19:51

Et aussi merci à toi WinUbuntu-43 , pour ton effort à refaire cette explication détaillée.
Bonne continuation.

maxire · Le 22/02/2018, à 15:07

Bon, c'est réglé, par contre je ne comprends pas la présence dans 40_custom de ceci:

set timeout_style=menu
if [ "${timeout}" = 0 ]; then
  set timeout=10
fi

Le timeout doit être paramétré dans /etc/default/grub, mais bon c'est un détail.

enebre · Le 22/02/2018, à 15:45

Ce que j'en comprend c'est que:

if = 0 then...set = 10

si timeout est réglé à 0 il repasse automatiquement set = 10
Depuis 1 an ou 2 quelques années grub n'accepte plus set = 0

maxire · Le 22/02/2018, à 16:28

Ce n'est pas la signification de ces quelques lignes de code qui pose problème mais leur présence dans /etc/grub.d/40_custom, elles n'ont rien faire là dans la mesure où le timeout est généré par /etc/grub.d/00_header à partir des informations trouvées dans /etc/default/grub.

enebre · Le 22/02/2018, à 16:46

S'il peut y avoir plusieurs loader dans le custom ? dans ce cas ça se justifierait, vista XP etc

maxire · Le 22/02/2018, à 16:58

Le timeout est une temporisation du démarrage du système d'exploitation par défaut, il s'applique au menu dans son ensemble pas à un démarrage en particulier.

WinUbuntu-43 · Le 22/02/2018, à 17:46

@ maxire

J'avais remarqué ces lignes, c'est moi qui les ai recopiées depuis

etc/grub/grub/.cfg

pensant que cela faisit partie du menu de démarrage de windows.
Par contre, peut être ces lignes sont apparues dans etc/grub/grub/.cfg quand j'ai modifié la ligne GRUB_TIMEOUT=-1

Voir le contenu de /etc/default/grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=-1
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
GRUB_DISABLE_OS_PROBER=true
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

maxire · Le 22/02/2018, à 19:57

Ces lignes sont à retirer de /etc/grub.d/40_custom elles vont empêcher une prise en compte de nouveaux paramètres de timeout en cas de modification de /etc/default/grub.

WinUbuntu-43 · Le 22/02/2018, à 21:18

maxire a écrit :

Ces lignes sont à retirer de /etc/grub.d/40_custom elles vont empêcher une prise en compte de nouveaux paramètres de timeout en cas de modification de /etc/default/grub.

OK maxire c'est chose faite, toutes tes remarques ont été bénéfiques et m'ont permis de résoudre ce problème de démarrage impossible de vista (cela aurait pu être un autre OS) sans devoir tout réinstaller, encore merci!

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 21/02/2018, à 11:09

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#102 Le 21/02/2018, à 19:40

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#103 Le 21/02/2018, à 19:51

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#104 Le 22/02/2018, à 15:07

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#105 Le 22/02/2018, à 15:45

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#106 Le 22/02/2018, à 16:28

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#107 Le 22/02/2018, à 16:46

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#108 Le 22/02/2018, à 16:58

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#109 Le 22/02/2018, à 17:46

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#110 Le 22/02/2018, à 19:57

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

#111 Le 22/02/2018, à 21:18

Re : [RESOLU] Démarrage Vista impossible depuis grub suite installation Ubu

Pied de page des forums