Persistent LiveCD : encore une suite…

Comme toutes les méthodes testées précédemment pour mettre en place un LiveCD avec un mode persistant qui marche n’ont pas abouti, j’ai choisi de modifier le initrd.gz à la main (comme d’habitude), mais de le reformer en utilisant

update-initramfs -k all -u

pendant un chroot, plutôt qu’un classique :

find . | cpio -o -H newc | gzip -9 > initrd.gz

comme il a pu être testé plus bas.

On obtient alors une image qui va se mettre dans le répertoire “/boot” (on est toujours en chroot). Il faudra le placer judicieusement (dans “/casper”).

Pour info, comme ci-dessous, j’ai modifié les scripts “init” et “scripts/casper”.

a priori, le package casper a pourtant dû être mis à jour quand on suit les directives indiquées ici et donc il ne devrait pas y avoir besoin de modifier les scripts dans /casper ? Mais ça n’a pas l’air de fonctionner comme ça…

Quelqu’un mentionne “casper-new-uuid” dans le rapport de bug de hardy heron à propos du mode persistant pour gérer le initrd.gz. Je ne sais pas trop comment ça fonctionne, ça peut être une piste à suivre également.

Si ça ne marche toujours pas, il sera toujours possible de reprendre l’install décrite dans pendrivelinux en modifiant le syslinux en isolinux pour pouvoir l’utiliser sur un CD au lieu d’une clef USB…

———–

D’ailleurs, ça ne marche toujours pas…

Hop, technique Pendrive Linux. On reprend de zéro. C’est parti. C’est ici.

• Déjà, on remarque qu’on nous fait charger le répertoire “/isolinux” de l’image à la racine du volume live. étonnant. Ça à l’air de pouvoir marcher.
• par contre, on nous propose de télécharger un “syslinux.cfg”. On va plutôt modifier notre “isolinux.cfg” comme on en a l’habitude. En plus, sinon, on est confronté au problème de “/cdrom” qui est présent dans notre version mais ne l’est pas dans la version USB.
• On change le “initrd.gz” en téléchargeant celui proposé.
• On reforme l’iso (voir la page personaliser un liveCD, à modifier en tenant compte du fait que les fichiers de isolinux sont maintenant à la racine du nouveau volume)
• Test en machine virtuelle : ça boote, mais comme d’habitude, le volume persistant n’est pas retrouvé. Et voilà… On n’a pas avancé d’un chouïa.

Le problème ne serait-il pas ailleurs que là où on le cherche ?

Dans le log de casper (”/var/log/casper.log”), il semblerait qu’un script cherche un fichier sans nom par exemple… peut-être dans “casper-premount” ; à creuser…

La solution