[Ubuntu-QC] lors d'une installation : (reMERciements) : mise à jour du BIOS et traitement des Kernels hérités?

Louis Bourque louibourque at gmail.com
Mar 4 Déc 21:01:08 UTC 2012


Bonjour Simon, et bonjour Louis,


Merci pour vous réponses! J'ai fait beaucoup de lecture ce matin, et j'en
arrive au point où il me semble pertinent de partager ma compréhension et
mes questions. J'apprécierais beaucoup recevoir votre avis, et vos
directives avant de poursuivre.


Des forums que tu proposes et de d’autres, Simon, je lis que l’erreur
serait vraissemblablement causée par une mauvaise assignation des
devices/partitions à Grub, de l’installation de Grub dans une
device/partition inadéquate (ou de nature inadéquate, logique plutôt que
primaire par exemple) ou encore, d’un ordre de device/partition au BIOS ne
correspondant plus à l’ordre inscrit au moment de l’écriture du Grub. Dans
ce cas, j’envisage les questions et opérations suivantes:



-Savoir où Grub est installé, et quelles sont ses dépendances le cas échéant

-exécuter Purge de Grub ; aussi purger ou conserver les dépendances


-Et savoir où réinstaller Grub et/ou ses dépendances

-Puis exécuter l’installation de Grub et de ses dépendance /ou le cas
échéant établir les liens avec les dépendances originellement conservées


... Est-ce aussi simple?


Question : Avant installation de Xubuntu12.04, et lorsqu’Ubuntu 10.10
démarrait normalement, soit après l’apparition du menu de sélection de
kernels (et de WinXP à titre égal). La structure de mon disque comportait
alors un espace inutilisé, entre la partition dédiée à WinXP et la
partition étendue, celle-ci contenant dans l’ordre Ubuntu10.10 (monté en
racine /), swap et /home. L’image en PJ ne montre pas cet espace, entre
NTFS et Logique EXT. Toutefois elle montre '' shéma de partitionnement :
MasterBootRecord '' .


Or cet espace libre n’était pas détectée, ou représenté sur le continum
graphique représentant la structure du disque par l’installateur
Xubuntu12.04. Cet espace libre contenait-il (était-il) le MBR de WindowsXP
ainsique Grub ? Le tout fut-il écrasé? Avec pour conséquence de rendre le
démarrage sous XP impossible également? Ainsi la réinstallation de GRUB
m’offrirait-elle à nouveau cette possibilité de démarrer avec l’un ou
l’autre des systèmes? À cette fin (ou à d’autres) le MBR doit-il être
réinstallé, ou recréé? Dans ce cas, une réinstallation avec des commandes
adéquates serait-elle la meilleure solution, puisque mon système est
fraîchement installé sur une paritition distincte?


Je relis d’ailleurs, Simon, que tu m’avais écrit la chose suivante :


‘Pour être précis, le bootloader (grub) est stocké dans le MBR et non
 dans un système de fichier. Une réinstallation s'occupera de tout
 réinitialiser’.


...Après m’avoir écrit :

'Dans tout les cas, c'est pas bien grave car apparemment tu n'as que 3
 partitions: /, swap et /home’.

Peut-être t’avais-je confus et laissé entendre que mon disque ne comportait
pas de partition primaire ntfs pour WinXP.

Je veux donc envisager que j’eus donné des directives erronnées ou
insuffisantes à l’installateur Xubuntu et ensuite, envisager que
l’installateur ait failli d’écrire le Grub au bon endroit ou même, qu’il
ait détruit le MBR. Je veux donc envisager qu’une forme d’installation
vierge du système apporte la solution la plus judicieuse. Cela, en donnant
les bonnes directives et en conservant les autres détenant WindowsXP, le
Swap Linux et Home.

La virginité serait (-elle) obtenue en formatant préalablement la partition
destinée à Xubuntu, ce que je n’avais pas fait (bien que j’eus demandé le
formattage à l’installateur).

Le cas échéant, saurais-tu (sauriez-vous) m’indiquer quelles directives
donner à l’installateur, dans quel ordre et qu’attendre en retour ?


*Je suis naïvement sensible à l’option d’une réinstallation vierge car je
ne connais pas l’architecture du système, et que plusieurs usagers sur
forum ont exécuté de simples commandes de purge et d’installation de Grub
sans obtenir résolution. Bien que certain l’obtinrent (exemples reproduits
ci-bas)*.


Dans un tout autre ordre, est-ce possible que ce problème ait à voir avec
l’architecture i386 de mon CPU, et un code conçu pour les processeurs
amd64? Est-ce que la nature de l’erreur : ' grub_divmod64_full ’ fait
référence à un paquet destiné aux processeurs amd64?

Pour faire suite donc, je pourrais m’inspirer des directives contenues dans
ce manuel; on y recommande notamment le ' Boot repair ' mentionné par Louis
:

‘ HOWTO: Purge and Reinstall Grub 2 from the Live CD ‘ :
http://ubuntuforums.org/showthread.php?t=1581099

Devrais-je, pourrais-je vous informer de ce que retourne la commande :

       debconf-show - query the debconf database

Mais la réinstallation vierge avec des directives correctes correspond le
mieux à cet avis, contenu dans le même manuel :  ‘ *Doing the least
necessary to fix a system is generally a good idea* ‘.

Je vous remercie candidement mais crucialement pour votre aide précieuse!

Louis



... Voici les expériences d’uagers avec les tweaks, sur l’un des forum que
tu m’as suggéré, Simon :
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/768716

' This is almost certainly a case of the upgraded version of GRUB not
being installed to where your computer is actually booting from ‘.


‘ Remy, do you have more than one disk in this computer?
The usual fix for this class of problem is to run 'sudo dpkg-reconfigure
 grub-pc', and make sure that all your disks are checked. (Unless you
 have specific requirements, you don't need to and probably shouldn't
 check any of the partitions, only whole disks.)
I'm certain that this isn't a bug in GRUB's source code - it's just due
 to the GRUB core image being out of sync with its modules, which happens
 sometimes for the reason I describe. We get bugs like this pretty much
 every time we change the interface between the core image and modules in
 any way at all, although they've got much less frequent as the debconf
 interface has been improved to increase the likelihood that people will
 install GRUB to the right place ‘.

...

D’autre part, les opérations de purge et de réécriture du Grub ne
fonctionnent pas dans bien des cas.
Ainsi parmi d’autres :




‘@Remy
If you read in the thread on ubuntuforums.org posted by Ants you will see
that update-grub wasn't working for everyone. I know it didn't work for me.


I did end up fixing this problem, but I can't tell you exactly how. I
downloaded the source and took a look at where grub_divmod64 and
grub_divmod64_full reside. I thought it might have been a bug when
grub_divmod64_full was created, however, everything looked correct.


I then compiled and installed it. (... mention d’un conflit entre paquets
hérités) ... So, I booted into the gentoo 11.0 livedvd and chrooted into
ubuntu to try and install grub properly. This time it worked without a
problem’.





et Nathan Clemons (qui affiche sa debconf au forum) :


'Purging and reinstalling grub did not fix the problem.’




...


La note suivante de Collin semble avisé; je me demande comment interpréter
le passage en itallique, s'il est pertinent pour tous :




‘Remy, do you have more than one disk in this computer?


The usual fix for this class of problem is to run 'sudo dpkg-reconfigure
grub-pc', and make sure that all your disks are checked. (Unless you
have specific requirements, you don't need to and probably shouldn't
check any of the partitions, only whole disks.)


I'm certain that this isn't a bug in GRUB's source code -* it's just due
to the GRUB core image being out of sync with its modules, which happens
sometimes for the reason I describe. We get bugs like this pretty much
every time we change the interface between the core image and modules* in
any way at all, although they've got much less frequent as the debconf
interface has been improved to increase the likelihood that people will
install GRUB to the right place’.





Cette note suivante de Wulfric me le semble également :





‘ .Purge grub from all installs


.Specifically install GRUB on MBR not on any Partition Boot Records and
especially not on logical partitions


. I was able to confirm the bug by installing on the PBR of a logical
partition on a different machine


.If you must install on PBR prefer physical partitions to logical partitions





Excellent guide to purging and installing grub


http://ubuntuforums.org/showthread.php?t=1581099




Hope this helps


If more people can confirm this maybe we could put this on the grub-dev
mailing list.


So far I have had this issue on two machines and each time purging and
reinstalling to MBR has worked.


I will try on some other hardware when I can.


Do mention your hard disk partitions in comments so we can see if there is
any pattern ’.





Merci.

LB

Le 4 décembre 2012 03:06, Simon Deziel <simon.deziel at gmail.com> a écrit :

> Bonsoir Louis,
>
> On 12-12-03 07:29 PM, Louis Bourque wrote:
> > Bonsoir Simon,
> >
> > Merci beaucoup pour ton aide attentive... Et proactive. J'ai exécuté la
> > commande et je trouve trois paramètres dont l'un contient la version 2.4
> > supposément chargée depuis Lenovo :
> >
> > SMBIOS 2.4 present.
> > BIOS Revision: 2.39
> >     Firmware Revision: 1.7
>
> La version du bios est:
>
>   Version: 79ETE7WW (2.27 )
>
> Ce numéro de version ainsi que la date de publication indiquent que tout
> est à jour.
>
> > J'ignore ce que signifie SMBIOS et BIOS Revision; mais bon;
>
> Je ne savais pas non plus ce que c'était exactement mais c'est expliqué
> là: http://en.wikipedia.org/wiki/System_Management_BIOS
>
> La commande "dmidecode -t bios" retourne les champs contenus dans les
> types 0 (BIOS Information) et 13 (BIOS Language Information).
>
> > Le bug pour lequel tu m'as orienté me préoccupe beaucoup.  Il m'oblige à
> > opérer sous disque de démarrage, ce qui est très limitant.
>
> Si le système ne démarre pas du tout (sauf en LiveCD) il vaut peut-être
> mieux utiliser le "boot repair" tel que suggéré par un Louis Brunet.
>
> > Il semble fastidieux pour moi qui ne connait pas bien l,architecture
> > système; je comprends très mal ce que désigne les informations
> > rapportées par une commande telle que debconf, par exemple. J'ai
> > commencé à lire attentivement les indications.
>
> En général, lire le "man page" devrait fournir un bon aperçu des
> fonctionnalités d'un programme. Dans ce cas, debconf-show sert à
> interroger la base de donné de configuration des paquets sous
> Debian/Ubuntu:
>
>   debconf-show - query the debconf database
>
> Voici ce qui est retourné par mon système:
>
> simon at simon-laptop:~$ sudo debconf-show grub-pc | grep install_devices
> * grub-pc/install_devices: /dev/disk/by-id/ata-HITACHI_HTS725050A9A364
>   grub-pc/install_devices_failed_upgrade: true
>   grub-pc/install_devices_empty: false
>   grub-pc/install_devices_failed: false
>   grub-pc/install_devices_disks_changed:
>
> L'interrogation de debconf n'est que pour valider le problème affectant
> grub-pc dans le bug en particulier. La commande pour corriger le
> problème est:
>
>   sudo dpkg-reconfigure grub-pc
>
> Cependant, puisque ton système ne démarre pas sans LiveCD reconfigurer
> le paquet grub-pc serait un brin compliqué donc utiliser le "boot
> repair" serait peut-être plus simple.
>
> > Je dois quitter pour la
> > soirée, et aimerais pouvoir te revenir demain sur le thème, après avoir
> > compris ce que je peux. Je souhaite que tu puisse m'aider. J'hésite à
> > essayer des outils ou des commandes avant d'avoir identifié la source
> > d'un problème.
>
> En effet, la prudence et la compréhension sont de mise :)
>
> > Merci bien, et bonne soirée!
>
> À toi aussi!
>
> Simon
>
> > Voici enfin tout ce que la commande m'a rendue.
> >
> > # dmidecode 2.11
> > SMBIOS 2.4 present.
> >
> > Handle 0x0000, DMI type 0, 24 bytes
> > BIOS Information
> >     Vendor: LENOVO
> >     Version: 79ETE7WW (2.27 )
> >     Release Date: 03/21/2011
> >     Address: 0xDC000
> >     Runtime Size: 144 kB
> >     ROM Size: 2048 kB
> >     Characteristics:
> >         PCI is supported
> >         PC Card (PCMCIA) is supported
> >         PNP is supported
> >         BIOS is upgradeable
> >         BIOS shadowing is allowed
> >         ESCD support is available
> >         Boot from CD is supported
> >         Selectable boot is supported
> >         BIOS ROM is socketed
> >         EDD is supported
> >         ACPI is supported
> >         USB legacy is supported
> >         BIOS boot specification is supported
> >         Targeted content distribution is supported
> >     BIOS Revision: 2.39
> >     Firmware Revision: 1.7
> >
> > Handle 0x0027, DMI type 13, 22 bytes
> > BIOS Language Information
> >     Language Description Format: Abbreviated
> >     Installable Languages: 1
> >         enUS
> >     Currently Installed Language: enUS
> >
> >
> > Le 3 décembre 2012 21:59, Simon Deziel <simon.deziel at gmail.com
> > <mailto:simon.deziel at gmail.com>> a écrit :
> >
> >     On 12-12-03 04:44 PM, Louis Bourque wrote:
> >     > Je crois que la mise à jour du BIOS a bien réussi ce matin; la
> >     > complétion fut indiquée, et la machine semble opérée normalement.
> >
> >     Pour confirmer la mise à jour en validant le numéro de version:
> >
> >       sudo dmidecode -t bios
> >
> >     > Je vous remercie tous très sincèrement.
> >
> >     Au plaisir,
> >     Simon
> >
> >     > Louis
> >     >
> >     >
> >     > Le 21 novembre 2012 19:42, Simon Deziel <simon.deziel at gmail.com
> >     <mailto:simon.deziel at gmail.com>
> >     > <mailto:simon.deziel at gmail.com <mailto:simon.deziel at gmail.com>>> a
> >     écrit :
> >     >
> >     >     On 12-11-21 02:26 PM, Louis Bourque wrote:
> >     >     > Je me demande où sont logés mes applications,
> >     >
> >     >     Dans /usr principalement qui, selon ton schéma de
> >     partitionnement est
> >     >     sur la même partition que /.
> >     >
> >     >     > préférences, et
> >     >
> >     >     Les préférences sont généralement stockées dans des
> >     dossiers/fichiers
> >     >     cachés dans ton home. "ls -la ~" devrait te les montrer. Si tu
> >     veux
> >     >     repartir à neuf pour une application donnée, tu peux
> >     simplement renommer
> >     >     le dossier de préférences. Pour avoir un profile vierge dans
> >     Firefox:
> >     >
> >     >       mv ~/.mozilla ~/backup.mozilla
> >     >
> >     >     > fichiers ressources (que l'on dit .dll).
> >     >
> >     >     Les librairies partagées sont des .so sous Linux et sont
> stockés à
> >     >     plusieurs endroit (/lib, /usr/lib, etc) mais pas dans /home
> >     donc pas de
> >     >     souci à ce niveau.
> >     >
> >     >     > Plus précisément,/je me demande
> >     >     > si je dois les purger pour éviter les conflits/ ou blocages
> >     avec les
> >     >     > applications qui seront installées par l'installateur
> >     Xubuntu, ou
> >     >     > ultérieurement par apt. /Ou si la réinitialisation
> >     (formatage) de la
> >     >     > partition / (système) se chargera d'ouvrir le chemin à une
> >     >     installation
> >     >     > correcte des applications./
> >     >
> >     >     Formater / devrait suffire. Si certaines applications ont un
> >     problème,
> >     >     tu peux simplement repartir à neuf tel qu'expliqué pour
> >     Firefox plus
> >     >     haut.
> >     >
> >     >     > Aussi, j'ai exécuté la commande sur ta recommandation :
> >     >     >
> >     >     > grep boot /etc/fstab
> >     >     >
> >     >     > et n'ai obtenu aucun résultat (''Aucun fichier ou dossier de
> ce
> >     >     type'').
> >     >
> >     >     "aucun résultat" n'est pas la même chose que l'erreur ''Aucun
> >     fichier ou
> >     >     dossier de ce type''. Si grep se plain qu'aucun fichier ou
> >     dossier de ce
> >     >     type existe c'est que tu as fait une erreur en tapant
> >     "/etc/fstab".
> >     >
> >     >     Dans tout les cas, c'est pas bien grave car apparemment tu
> >     n'as que 3
> >     >     partitions: /, swap et /home.
> >     >
> >     >     > Je dois en interpréter que le lancer (booter) n'est pas sur
> une
> >     >     > partition distincte et qu'il sera écrasé par la
> >     réinitialisation de la
> >     >     > partition racine (système).
> >     >
> >     >     Pour être précis, le bootloader (grub) est stocké dans le MBR
> >     et non
> >     >     dans un système de fichier. Une réinstallation s'occupera de
> tout
> >     >     réinitialiser.
> >     >
> >     >     > Enfin, /saurais-tu apprécier l'espace actuellement consacré
> >     à mes
> >     >     > partitions/, à l'allocation de mes 80 Gb :
> >     >     >
> >     >     > / (système) : 19 Gb
> >     >     > Swap : 2,7 Gb (pour 2 Gio de RAM)
> >     >     > /home : 58 Gb
> >     >
> >     >     Oui, ça me semble bien divisé. Avoir un swap plus grand que la
> >     RAM est
> >     >     recommandé dans le cas d'un portable pour supporter le mode
> >     hibernation.
> >     >
> >     >     Bonne journée,
> >     >     Simon
> >     >
> >     >
> >     >
> >     >     --
> >     >     Ubuntu-quebec mailing list
> >     >     Ubuntu-quebec at lists.ubuntu.com
> >     <mailto:Ubuntu-quebec at lists.ubuntu.com>
> >     <mailto:Ubuntu-quebec at lists.ubuntu.com
> >     <mailto:Ubuntu-quebec at lists.ubuntu.com>>
> >     >     https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec
> >     >
> >     >
> >     >
> >     >
> >
> >
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <https://lists.ubuntu.com/archives/ubuntu-quebec/attachments/20121204/d715eae7/attachment-0001.html>


Plus d'informations sur la liste de diffusion Ubuntu-quebec