Bon finalement après tests, c'est pas une barette de RAM, mais un des slots de RAM qui part en vrille... 😕 J'ai ouvert le compartiment à RAM, j'ai interverti les barettes, testé chacune dans chaque emplacement, et conclusion, le slot du bas est mort...

C'est aussi confirmé par l'Apple Hardware Test, il me rapporte l'erreur suivante :

post/0/2048 SODIMM0/J25LOWER

Et en effet, c'est bien le connecteur du bas...

J'ai appelé donc AppleCare aujourd'hui, et ils m'envoient une boîte pour expédier la machine après-demain au plus tard. Et le mec me dit qu'elle pourrait être de retour avant la fin de la semaine (c'est en effet ce qui s'est passé la dernière fois).

Voilà, j'ai plus qu'à attendre la boîte, expédier et croiser les doigts...

Plone est un système de gestion de contenus open source et gratuit. C'est la technologie derrière mon site. Dernièrement, les gens de chez Plone ont sorti une nouvelle version, la 2.1, qui apporte quelques nouveautés et améliorations, dont l'adoption d'Archetypes en tant que base des types de contenus, à la place des types CMF (Content Management Framework), utilisés depuis les débuts de Plone.

De fait, la migration de Plone 2.0.5 (ou antérieur) à Plone 2.1 (et supérieur) implique la migration automatique des anciens types de contenus, ce qui peut être à la fois long et laborieux. Dans mon cas, il s'agissait de migrer 4 sites répartis sur deux instances.

Première instance, le site web de ma boîte, plus un petit site perso. Le site web a un contenu majoritairement statique, composés de documents (CMFDocument), avec quelques fichiers PDF stockés en CMFFile. Le site perso est très réduit en taille, avec des documents et quelques photos. Le Data.fs de l'instance pèse dans les 500 Mo.

Deuxième instance, le site intranet de ma boîte, plus un site communautaire sur un artiste vietnamien. Le site intranet est très lourd, et chargé à bloc de fichiers PDF stockés en CMFFile, ainsi que des CMDDocuments. Le site communautaire est composé de documents en CMFDocument, de photos en CMFPhoto et de quelques chansons en MP3 (CMFFile). Le Data.fs fait environ 1 Go.

La procédure normale de migration de Plone (sur FreeBSD, ou d'autres Unix) est de tout d'abord, faire une sauvegarde complète du site, avec tous les produits (on sait jamais), télécharger le tarball de la nouvelle version de Plone sur leur site, placer les produits nouveaux et mis à jour dans le répertoire Products de l'instance, et lancer la mise à jour dans la ZMI par l'outil portal_migration, qui sait détecter la version installée, et qui effectue la migration tout seul comme un grand.

La migration en elle-même effectue la mise à jour des produits de support de Plone, comme Archetypes, et met à jour le site Plone en lui-même (avec les changements de paramètres, nouvelles variables, etc). Mais la migration en version 2.1 effectue une étape importante supplémentaire : elle convertit les éléménts CMFTypes du site en éléments Archetypes. Ça consiste en fait à prendre un objet CMFType, créer un nouvel objet Archetype équivalent, et à répliquer tous les paramètres et données au nouvel objet, et détruire l'objet CMFType. Ainsi on obtient un objet Archetype d'apparence identique à l'ancien objet CMFType.

Le script effectuant cette manœuvre recatalogue le site, trouve les objets CMFTypes à partir du portal_catalog, et les convertit. Or cette opération est longue et consommatrice de mémoire et d'espace disque temporaire.

La première erreur que j'ai eue, c'est No space left on device... En effet, l'interprêteur python qui effectuait la mise à jour a saturé le répertoire /tmp de la machine. En même temps, ce n'était pas très difficile, la taille par défaut de la partition abritant /tmp sur FreeBSD est de 256 Mo. Ce qui est suffisant pour la plupart des cas, mais là, les devs de Plone recommendaient au moins la taille du Data.fs pour la migration. Là, j'en étais loin... Normalement, python utilise tour à tour les répertoires /tmp, /var/tmp, /usr/tmp et le répertoire courant (et peut-être un autre, je sais plus) pour stocker les fichiers temporaires, et ne devrait théoriquement jamais se trouver à court d'espace disque avant la saturation totale de tous les disques. Mais là, il semble qu'il n'y a qu'un seul fichier utilisé pour la migration, et qui grossit pendant toute la durée de l'opération. Donc pas de fallback possible...

Du coup, j'ai monté une machine dédiée à la migration, avec une seule partition couvrant tout le disque. Plus de problème d'espace disque. Mais j'ai été confronté à des erreurs de type Memory Error... Et c'est à peu près les pires erreurs qu'on peut rencontrer dans Zope/Plone, ça veut dire en gros qu'il y a eu une erreur de lecture/écriture sur le Data.fs irrécupérable...

Au bout de deux ou trois échecs de migration directe, je me suis dit que je ne pouvais pas continuer comme ça : il y a tellement de choses qui sont faites dans la migration que je ne sais pas où s'est produit l'erreur, et l'opération met tellement de temps que j'en aurais pour des semaines avant de dépatouiller la chose à ce rythme.

J'ai alors essayé de comprendre la procédure. Et c'est pas bien sorcier. D'abord, essayer de nettoyer et alléger le fichier Data.fs pour faciliter la migration. Rien de compliqué, recataloguer le site (<site>/portal_catalog, onglet Advanced, Update Catalog),recompresser le fichier (Control_Panel/Database/main, onglet Database, Pack).

Ensuite, mettre à jour les produits déjà installés (par portal_quickinstaller. Ensuite, installer les nouveaux produits dont Plone a besoin (toujours par portal_quickinstaller). La version 2.1 apporte les produits suivants :

• ATContentTypes
• ATReferenceBrowserWidget
• Archetypes
• CMFActionIcons
• CMFCalendar
• CMFFormController
• CMFQuickInstallerTool
• GroupUserFolder
• MimetypesRegistry
• PloneErrorReporting
• PloneLanguageTool
• PortalTransforms
• PortalTransport
• ResourceRegistries
• kupu

Tout réinstaller/installer, sauf ATContentTypes. Une fois que les autres produits sont installés sans erreurs, on passe au point crucial, ATContentTypes.

ATContentTypes, c'est le produit qui apporte les types de contenus Archetypes (comme son nom l'indique). Or ça implique de recataloguer le site avant, et de créer un double Archetype de chaque objet CMFTypes du site, et enfin de supprimer les objets CMFTypes. Et c'est long !

A l'installation du produit, il y a un Update Catalog qui se fait, ça prend un moment (surtout si le site est grand). Une fois le produit installé, il faut passer aux choses sérieuses : portal_atct. C'est un outil placé par ATContentTypes à la racine du site. La première fois, si vous aviez déjà installé Archetypes avant, l'outil vous indiquera que l'instance n'est pas à jour. Il faudra passer par Version Migration pour ce faire.

Une fois que l'instance est à jour, il faut passer à la migration des types, dans Type Migration. Comme l'indique l'outil, pour cette étape, il vaut mieux lancer Zope en mode debug, ou consulter régulièrement le log de Zope, pour voir ce qu'il fabrique. Un clic sur Migrate lance la migration des types. Là j'ai connu l'enfer, avec des Memory Error inexplicables (pas de veleur d'erreur...).

Mais j'ai fini par voir qu'il y a au début du log le chemin complet de l'objet en cours quand l'erreur s'est produite. Pour moi, c'était à peu près tous les objets binaires (type octet-stream), comme des fichiers exécutables ou des fichiers Zip stockés en tant que CMFFile. Il est possible que notre utilisation de TextIndexNG2, un produit permettant une indexation plus fine des langues non latines, ait contrinué à cette erreur, car les index sont également regénérés lors de la migration des types. Peut-être que TextIndexNG2 n'a pas trouvé de "lecteur" approprié pour ces types et qu'il s'est emmêlé les pinceaux...

En tous cas, supprimer ces objets a suffi pour que la migration des types se fasse sans erreurs (mais bon, il faut relancer la migration de types autant de fois qu'il y a de fichiers problématiques).

Une fois les types migrés, c'est gagné. Il suffit d'utiliser l'outil portal_migration, et lancer la migration Plone. Il va alors repasser les étapes qu'on a déjà effectué, mais il ne fera rien ou presque, vu que tout est installé et migré côté Archetypes (mais la mise à jour du catalog va quand même se faire, et ça prend du temps...). Il va donc mettre à jour l'instance Plone, et le site sera opérationnel sous la nouvelle version !

Merci d'avoir lu jusqu'ici, c'est brouillon parce que mes tentatives de migration ont été brouillonnes, mais j'espère que ça pourra vous aider si vous rencontrez des problèmes pendant la migration.

Ça faisait longtemps que j'avais pas parlé de mon PowerBook. 🙂

Pendant les vacances, je m'ét&is; rendu compte que la batterie du PowerBook semblait se décharger plus vite que d'habitude. Je me suis dit que c'était peut-être parce que je m'en servais moins et que je le laissais plus souvent débranché.

Or maintenant je découvre que la batterie ne tient plus les 2 jours du week-end en veille. Alors qu'au début, il pouvait tenir une semaine ouvrée en veille facilement.

J'ai essayé de reset le PMU, la PRAM, et je n'ai pas l'impression d'avoir amélioré la situation. Aujourd'hui, j'ai déchargé et rechargé la batterie à 2 reprises. Comme le graphique ci-dessous (par X-Charge) le montre, ça met 1 h 30 à charger, et autant à décharger (utilisation normale, je lis des pages web, je tape du texte, j'envoie des mails).

Courbe de charge

Du coup je vais devoir tenter ma chance chez Apple. J'ai réussi à négocier une batterie neuve pour les iBooks, je devrais pouvoir en avoir une pour le PowerBook. Sinon faudra que j'économise pour une nouvelle batterie, environ 130 €... J'aimerais éviter cette dernière solution.

Après avoir écrit ma brève du jour, je consultais le web, quand j'ai vu les caractéristiques des nouveaux PowerBook. J'ai remarqué qu'ils avaient 128 Mo de RAM vidéo, et je me suis demandé si j'avais la possibilité d'avoir cette option (qui est en série maintenant).

Je lance donc Informations Système pour vérifier, et par curiosité, je clique sur Diagnostic. Là, je découvre ça :

Diagnostic

Une des barettes de RAM ne marche plus ! 🙁 J'ai fait un test avec les utilitaires de diagnostic, il me dit que la barette est morte au boot, mais que l'autre va bien (j'ai 2 fois 512 Mo).

J'ai pas d'outils adaptés pour ouvrir le compartiment à RAM, je vais le faire ce soir, pour voir s'il n'y a pas juste un faux contact, ou si elle est pas un peu déboîtée.

Mais dans mon malheur, il y a quand même un peu de bon : la barette a l'air d'être celle d'Apple d'origine. Donc elle rentre dans mon contrat AppleCare de 3 ans ! Donc je vais avoir une barette neuve au pire. Et même si c'est pas celle d'origine, l'autre est achetée chez Crucial, qui garantie à vie et a l'air sérieux.

Ça se trouve c'est ça qui a merdé la batterie et la consommation ?