mise à niveau à partir du CD

[Avell Diroll]

On 11/01/11 12:49, spir wrote:
> On 01/10/2011 08:46 PM, Avell Diroll wrote:
>> On 10/01/11 18:30, spir wrote:
>> (snip)
>>> Lorsque je fais une màj par le "update manager" (oar ex 10.04 -->
>>> 10.10), donc via internet, la mise à niveau ne fait que fait que cela:
>>> une mise à niveau.
>> (snip)
>> Il y a deux raisons pour lesquelles une migration peut mal se passer:
>> -> un souci matériel ou une coupure de courant pendant la migration
>> -> lancer une migration sur un système "patouillé"
(snip)
> -> défaut dans le logiciel gérant la procédure
> non?

non, pour l'utiliser depuis plus de 10 ans (j'utilisais apt sous debian 
avant la création d'ubuntu), le système de migration est très robuste 
quand on le laisse gérer les logiciels/lib ... mais cela veut aussi dire 
que toute interférence peut potentiellement casser cette gestion 
automatisée ... car le système n'est alors plus géré par apt, mais 
manuellement (je grossis un peu le trait, mais pas tant que ça ... à 
partir du moment où l'on modifie quelque chose dans /usr il faut en 
comprendre les tenant et les aboutissant et avoir bien conscience que 
cela va poser des soucis à apt ... le simple ajout d'un fichier *est* 
une modification).

> Je ne sais pas ce qui plante la mise à jour sur mon ordi. L'install se
> passe bien, donc ce n'est certainement pas un pb matériel. Encore moins
> une coupure de courant (je m'en sers tous les jours sans souci majeur,
> et j'habite en ville). Et mon système n'est pas patouillé (pour la
> raison que l'organisation du filesystem unix est absurde pour moi, je
> n'y retrouve jamais rien, j'ai laissé tomber).
C'est expliqué en détail dans la FHS (Filesystem Hierarchy Standard):
http://doc.ubuntu-fr.org/fhs
pour plus de détails: http://www.pathname.com/fhs/
C'est une lecture très intéressante pour toute personne qui souhaite 
gérer correctement son installation *nix.
Par ailleurs cette organisation est en grande partie responsable de la 
"coopération" des différents projets et des différentes libs sous unix.

> Il est très personnalisé
> côté "userland", mais absolument brut côté système. Point de vue
> paquets, ditto: en dehors des repos officiels, je n'ai que qq .deb
> fournis pour certains logiciels libres (pour lesquels ubuntu ne fournit
> rien ou une version trop ancienne), et 2/3 trucs compilés sur place,
> genre Wesnoth. Je ne vois pas de rapports avec le plantage de la mise à
> jour, encore moins avec l'amorçage/grub.
> Donc, d'après moi et contrairement à tes affirmations, c'est "just" un bug.
> Pour info, ce coup-ci ça a planté alors que le process était en train de
> réécrire le grub, ou qq chose du genre à propos de grub. Tout s'est
> alors figé, le compteur de temps restant bloqué à 13 min si mes
> souvenirs sont corrects. J'avais plus la main, forcé d'éteindre par le
> bouton d'arrêt matériel.

un seul paquet mal fait (ou ciblant une version différente) ; une seule 
compilation installée dans /usr qui empiète sur un logiciel/une lib 
suffit à casser apt ... que celà survienne à la fin est normal, c'est 
lors de la post-install que des divergences sont remarquées ... vu qu'à 
la préinstallation le système n'annonçait pas ce qui était réellement 
sur le disque.
Pour avoir le détail du problème il suffit d'afficher les logs de la 
migration, qui signaleront la/les erreurs survenues.
Donc oui, j'aurais tendance a appeler ça un système "patouillé" et 
j'aurais du mal à ne pas considérer ceci comme la source du problème 
tant que les logs ne diront pas le contraire (surtout si par exemple il 
y a une version compilée de Wesnoth qui vient "recouvrir" une version 
installée par apt - c'est une manière sûr de perdre apt).

> En ce qui concerne les petits problèmes qui s'accumulent avec le temps,
> un exemple: depuis qq mois (et sans prévenir, ni manip sournoise de ma
> part), mon ordi s'arrêtait au démarrage sur un login en mode texte. A
> l'écran apparemment une tentative ratée de login (par le sys de
> démarrage lui-même sans doute). (Heureusement j'avais qq anciens
> souvenirs dont la clé pour en sortir "startx".) J'ai cherché en ligne,
> en ai parlé sur cette liste: no solution à l'horizon.
Ce genre de mésaventure est souvent arrivé aux gens ayant tenté de 
personnaliser/modifier plymouth, le boot graphique arrivé avec lucid. En 
effet ce dernier nécessitait une configuration très strict pour être 
modifié et de nombreux apprentis sorciers ont posté des tutos sans 
réaliser que les mises à jour suivantes risquaient de casser leur 
configuration.

> Mais je suis
> certain qu'une réinstall de "réparation" aurait résolu le pb. D'ailleurs
> la màj l'a fait.
J'ai l'impression que cette "réinstall de "réparation"" serait une 
opération magique capable d'identifier toute seule d'où vient un 
problème et de ne pas toucher à toutes les autres modifications qui n'en 
posent pas ... un système de vérification ne peut identifier que ce qui 
est d'origine où ce qui ne l'est pas, si quelqu'un codait un tel système 
je pense qu'il serait utilisé sur chaque machine ... mais cela relève de 
l'imaginaire ... si quelqu'un veut se lancer dans un tel projet, grand 
bien lui en fasse, ça économisera énormément de temps passé en support 
technique ... hélas j'ai peur que ça ne puisse voir le jour avant un bon 
moment, mais ce n'est que mon avis.

(snip)
> J'ai cherché l'alternate et trouvé: CD
> http://www.ubuntu.com/desktop/get-ubuntu/alternative-download.
> Est-ce bien ce dont tu parles?
(snip)
C'est bien ça.

(snip)
>> Pour réinstaller sans perdre de temps, il est nécessaire d'avoir un home
>> séparé et d'avoir sauvegardé /etc,
(snip)
> Alors justement, en temps normal j'ai /home sur une partition à part;
> mais là (sûrement because un peu énervé et pressé), j'ai laissé
> l'install choisir et elle m'a tout mis sur la même partition
> --apparemment-- sauf la swap bien sûr.
> Y a-t-il un moyen simple et sûr de créer une nv partition une fois le
> système installé, d'y migrer /home et de faire en sorte que ledit
> système reconnaisse que /home a migré la-bas?
Il suffit de créer ou d'avoir une partition disponible sous un 
filesystem unix (gestion des droits) et d'y avoir copié une architecture 
contenant les dossiers des users que le système s'attend à y trouver (en 
copiant l'existant (attention aux droits/permissions) ou en récupérant 
une sauvegarde d'un système précédent).
Ensuite il suffit d'éditer /etc/fstab et de créer une nouvelle ligne 
pointant /home vers la partition ciblée (en ayant au préalable renommé 
/home en /home_save pour éviter les interférence). Idéalement ces 
opérations sont fait depuis un liveCD où un liveUSB afin d'éviter les 
effets de bords (même si en théorie ce n'est pas nécessaire).

(snip)
> Merci encore. Mais ça c'est pour moi c une goutte d'eau. Je réinstalle
> les logiciels au fur et à mesure, et tous ne peuvent pas être simplement
> des dépots pour raison de version ou pas fournis du tout.
> Mais le plus long, et pénible, c'est la masse de réglages à retrouver
> (sans lesquels l'usage est frustration permanente, voire quasi
> impossible). Voir ci-dessous.
(snip)
>> Puis, il suffit de remettre en place les réglages de la sauvegarde /etc
(snip)
> Voilà, bien justement, c'est le point qui coince pour moi: les nouvelles
> version d'un système, de ses éléments, de logiciels qui tournent dessus,
> tout ça s'accompagne forcément de configs, réglages, personnalisations
> différentes. Oui?
> Donc comme tu le suggères à mi-mots écraser les dossiers/fichiers de
> réglage avec ceux de l'ancienne version est certainement une très
> mauvaise idée. Et c'est justement *pour çà* que *la mise-à-jour* prend
> tout son sens et est nécessaire: elle est sensée reprendre les configs
> existantes en les adaptant aux nv versions.
> Ce n'est que pour des softs que je connais très bien que je me lancerais
> à 'forcer' une ancienne config sur une nouvelle version en me fiant à
> mon flair pour y coller les 'diffs'.
Si comme dit plus haut, "[le système] est très personnalisé côté 
"userland", mais absolument brut côté système", l'intégralité des 
réglages en question sont enregistrés dans les fichiers cachés à la base 
du $HOME et non dans /etc (qui contient les réglages "systèmes" - 
périphériques, servers, initialisation du système, ...). Tous les 
réglages des logiciels "userland" sont enregistrés dans les $HOME/.* ... 
c'est en supprimant /home que tu as perdu tous ces réglages, pas en 
réinstallant.

Seuls les fichiers de configuration présent dans /etc sont à manipuler 
avec des pincettes ... en général les fichiers de configuration 
"logiciels userland" présent dans /home ont leur migration de gérer 
directement par le logiciel (la migration de la distro ne touche 
absolument pas à /home, c'est au logiciel, à son premier lancement dans 
sa nouvelle version, de vérifier/migrer, si il y a lieu, ses propres 
fichiers de configuration)

(snip)
> Tout-à-fait d'accord. Justement, pourquoi Ubuntu ne propose-t-il pas une
> mise-à-niveau / mise-à-jour à partir du CD standard? Pourrais-tu poser
> la question? Ce serait aussi utile pour "rafraichir" le système en cas
> de pépin ou lorsque les petits ennuis commencent à s'accumuler (voire
> ci-dessus mon pb de démarrage).
> Peut-être que la procédure standard d'install brutale, de zéro, qui est
> la seule proposée, date de l'époque où quasiment toutes les installs
> linux se faisaient sur un ordi vierge, ou qui tournait sous win. Là, ça
> prend sens d'installer de zéro (à côte du système existant ou n prenant
> tout l'espace). Mais sur un ordi qui a déjà ubuntu, pour moi c'est
> stupide et destructeur à la fois.
Je n'ai pas besoin de "poser la question", tes prémices sont tout 
simplement fausses ... pendant longtemps les liveCD étaient des outils 
séparés, d'aide à la résolution de problème. En effet un liveCD n'était 
pas installable en l'état, arrivant avec les paramètres permettant de le 
faire tourner en RAM et ne permettant pas son adaptation à une 
environnement sur disque.
Ce qui a changé et rendu les liveCD directement installables c'est la 
présence d'un script d'installation qui "transforme" la gestion en ram 
du système en une installation classique lors de sa copie "brutale" sur 
le disque. Il est important de comprendre qu'une installation par liveCD 
ne passe pas par une installation par paquet (ce qui est beaucoup plus 
souple, d'où la popularité de l'alternate malgré l'absence de 
"graphisme"). Une installation depuis un liveCD sera toujours "brutale", 
à moins que celui-ci ait suffisamment de place pour avoir le système 
live et les paquets correspondant sur le CD, ce qui n'est pas le cas du 
liveCD d'ubuntu.

Enfin, comme je le disais plus haut, je ne sais pas d'où vient cette 
idée qu'il existe un système capable d'identifier automatiquement les 
erreurs et les corriger (et surtout capable de différencier une erreur 
d'une personnalisation), crois bien que si un tel système existait il 
serait utilisé et que 90% des gens qui font actuellement du support 
n'auraient plus qu'à se tourner les pouces.

Bonne continuation.

Ju
-- 
The most utterly lost of all days, is that in which you have not once 
laughed.