Unionfs et clef agreg

Pause Café
#1

(évolution de clefagreg, projet)
Rappel: ClefAgreg est une clefUSB boutable qui utilise le système cloop de knoppix, très efficace en terme de compression mais qui est en lecture seul. Mon idée est d’avoir le beurre (la compression au 1/3 et l’argent du beurre, l’écriture possible) en utilisant unionfs.
J’ai adapté unionfs pour 2.6.23 du site à module assistant (afin que le module puisse être compilé en solo), le résultat se trouve sur

deb boisson.homeip.net/debian etch (ou sid) divers

Mon idée serait de surcharger une image cloop (read only et compressé à 37% en moyenne) avec un système de fichiers classique afin de permettre à un utilisateur d’installer un composant simplement. Mais mon souci est le suivant: Je tiens à ce que la clef soit utilisable normalement (comprendre elle doit rester sous FAT32), Il y aurait une méthode consistant à tester la présence d’une partition ext2/3 sur la clef et à la monter par dessus, une autre consistant à chercher d’autres fichiers cloop et à les monter dans l’ordre, il faudrait dans ce cas prévoir un script de fabrication de ces fichiers.

Si quelqu’un a des idées.

#2

Je ne comprends pas trop ton problême:
tu veux merger une partition sur quelle partie(s) du cloop ? tout / ? /usr+/etc uniquement ?
et quel problême tu vois avec le format de partition ?

#3

À l’heure actuelle, c’est un peu une usine à gaz:

Je boute sur un initrd, je cherche une clef USB, puis un CD IDE puis un CD SATA. Je cherche un fichier cloop que je monte sur un répertoire /AGREG et je fais les liens /usr -> /AGREG/usr, idem dans le répertoire /etc, etc. Ensuite je fais un

rm /linuxrc

echo “0x100” > /proc/sys/kernel/real-root-dev

et un exit ce qui remonte l’initrd comme la véritable racine et lance /sbin/init.
Compliqué mais efficace.

  1. unionfs me permettrait de faire la même chose en plus simple je pense (pas la peine de faire la batterie de liens).
  2. si j’ai bien compris, unionfs permettrait
  • de rajouter en plus dans un deuxième temps les fichiers que j’ai supprimé (/var/lib/dpkg parexemples)
  • de rajouter une couche par dessus tout ça, couche construite par l’utilisateur par exemple en rajoutant des paquets. Cette couche est donc rajoutée sur la racine elle même.

Mon problème est le système de fichiers de cette couche. Du vfat extrait de la clef me parait source de pbms infinis. D’où mon pbm:
-> image cloop construite par un script à partir des fichiers rajoutés
-> partition ext2/3 de la clef

mais je n’ai qu’une idée vague de ce que fait exactement unionfs, n’en connaissant que le principe en gros. J’avais aussi pensé reprendre e2compr que je connais bien (si tu regardes sur mon site, j’avais fait en son temps un couple de disquette de secours fondé sur e2compr puis un CD permettant un encombrement mémoire minimal (époque des ordis avec 16M RAM)) mais le projet patauge (et j’ai un très mauvais souvenir du portage sous le noyau 2.4.23) et ça ne me parait pas fondamentalement adapté.

#4

Ouais, ben désolé, mais tu dois avoir le nez dedans parceque je ne vois toujours pas le détail de ce qui t’ennuie…
Tu as regardé comment knoppix faisait pour ses installs persistantes ?

#5

Je ne souhaite pas faire une installation persistante sur une machine, ça c’est facile, il suffit de tout déplier et ne pose pas de problèmes majeurs. De plus, je ne vois pas l’intérêt par rappport à une installation d’une distribution linux quelconque. Je souhaite conserver le principe d’une clef autonome, puissante (grace à la compression) mais où un utilisateur peut rajouter un ou plusieurs paquets sans passer par la case déploiement sur un ordinateur comme c’est le cas à l’heure actuelle: le système est sur un seul fichier monté en cloop et modifiable certes mais difficilement. Avec unionfs, on ne le modifie pas, on rajoute un truc dessus.

En fait ce qui m’ennuie est tout simple: unionfs permet de raccrocher un système de fichier à une arborescence. Bon, donc si je met un fat32, je raccroche du fat32 avec l’impossibilité de faire des liens, des droits primaires. En gros je souhaiterais un système où une personne fait un apt-get install par exemple, et sauvegarde ses modifications.

  • Soit l’installation se fait directement sur un système de fichiers montés en RW via unionfs. Dans ce cas, ce système ne peut être en fat32 car les liens ne fonctionneront pas, il y aura la pagaille dans les droits etc. De plus ça prendra de la place.

  • Soit l’installation se fait sur un système de fichier en RAM et un script permet d’«immortaliser» ces modifications dans un image cloop qui sera rajoutée à chaque démarrage. L’avantage est d’avoir une compression, des droits corrects mais nécessite un script de récupération. (Je me dirige plutôt vers cette méthode)

  • Soit une troisième méthode à laquelle je ne pense pas.

C’est plus clair. Ça n’est pas vraiment un ennui mais avant de me lancer, je regarde si il n’y a pas plus simple.

#6

Non, je parlais justement de ce que je pensais avoir vu sous knoppix, à savoir la possibilité depuis la distrib live en ro d’installer des softs supplémentaires en les stockant sur un support rw séparé (ce que tu veux faire). Ou était ce sous dsl ou sous slax ? Non, pas slax, puisque c’etait du apt-get.
Sinon, ta deuxiême solution me semble être ce qui avait été utilisé.
Sinon, pourquoi insistes tu pour utiliser du fat32 ?
Tu peux peut être avoir un filesystem ram / rw gèré comme tu dis dans ta deuxiême option, fusionné avec celui de ton cloop en ro, ET un montage d’une partoche fat32 de la clé dans le rep utilisateur ou ailleurs pour les échanges avec des machines sous windows.
Tiens au fait, une question que je me pose: tu as essayé de débrancher la clé alors qu’une machine tourne dessus ? Tu as quoi comme erreur ?

#7

C’est sur slax je pense, j’ai vu une clef fondée là dessus faite par un collègue. Le problème est que le système de fichiers n’est pas compressé mais je vais voir.

[edit: je confirme, c’est sur Slax]

Pourquoi le FAT32?

  • Parce que la plupart du temps, les clefs servent également de clef USB de stockage et doivent pouvoir être utilisées sous Windows. Mais ce que tu suggères est une solution.
  • Parce que ext2linux fonctionne mal (mais grub doit permettre de contourner le pbm sauf que je n’aime pas grub mais ça se soigne :slightly_smiling:)

Sinon, quand tu enlèves la clef, ça fige mais ta clef n’a pas d’erreur sauf si tu as explictiement écrit dessus en tant que root. Je me suis aperçu que les clefs USB n’aimaient pas du tout les petits cycles de lecture/ecriture sans arrêt. C’est pour cela que je centralise les écritures à la fin de la session lors de l’arrêt.

#8

Salut François :slightly_smiling:
Je n’ai pas tout compris à ce que tu disais, mais es-tu allé voir le projet debian live?Ils utilisent live-initramfs (qui apparement serait un fork de casper), un systeme de fichiers pour distribution autonome gérant la persistance.Live helper est un ensemble de script qui pourraient, peut-être, t’aider.

#9

J’ai jamais rien compris à debian live.

#10

[quote=“mattotop”]J’ai jamais rien compris à debian live.[/quote]Tout d’abord, Debian Live est le projet officiel de distribution autonome de Debian.Celui-ci s’appuie sur un ensemble de scripts permettant de créer son propre live-cd de manière très simple.Il est possible de générer une image toute simple avec des configurations préparées à l’avance, mais ceux qui veulent avoir un controle complet ne sont pas en reste : le nombre d’option de customisation est tout simplement impressionnant (cela va du bootstrap à la génération de l’image en passant par le chroot avec la possibilité d’arriver sur un shell du futur système).

J’avais pensé à un moment écrire un tuto dans T&A et puis la réalité m’a rattrappé et je n’ai toujours pas eu le temps de le faire.Pour une explication sommaire de l’utilisation, cf le wiki.

#11

quote="yoshi"
J’avais pensé à un moment écrire un tuto dans T&A et puis la réalité m’a rattrappé et je n’ai toujours pas eu le temps de le faire.Pour une explication sommaire de l’utilisation, cf le wiki.[/quote]Tu l’as dit yoshi ! Les grands principes sont faciles à comprendre, mais comme tu dis le wiki est sommaire, et c’est comme souvent pour les trucs un peu riches en fonctionnalités et nouveaux sous debian plus une carte de réfèrence pour des gens qui cherchent des détails en connaissant les bases qu’un truc pour neophyte qui veut aborder le sujet.
Enfin peut être que c’est mieux organisé que les premières fois que j’y ai mis le nez…

#12

Ouais, ben le bon exemple, c’est la page sur la persistance, justement:
wiki.debian.org/DebianLive/Howto/Persistence
si tu peux traduire…

#13

Ouais bon on va dire qu’ils vont à l’essentiel, il faut faire encore quelques recherches après pour, par exemple, arriver sur la manpage de live-snapshot.
Le problème c’est que ce projet est jeune et ne dispose pas encore d’une bonne documentation.Un peu de patience je m’y remettrai et je te ferai un zoli tuto tout plein d’explication 8)

#14

Effectivement, a posteriori ça conviendrait sauf que là, j’ai un système qui marche et que je maitrise parfaitement. Adapté unionfs devrait se faire sans problème, et je n’ai pas le temps de passer 1 mois pour maitriser Debian live alors que mon système fonctionne. Par ailleurs, mon problème n’est pas de faire une clef customisée, c’est déjà fait et j’ai même fait une base très simple d’emploi pour qui veut en faire une (à mon avis plus simple à comprendre que debian live). Mon problème est de faire une clef modifiable à la volée pour quelqu’un qui sait faire apt-get.

#15

Bon, ben j’ai un unionfs qui marche sauf que le montage d’unionfs fonctionne parfaitement une fois la machine lancée mais juste avant le pivot_root :frowning:, je vais voir ça de plus près…

#16

Suite: C’est bizarre unionfs, une fin comme suit dans le linuxrc ne marche pas:

[code]cd /
mount -t unionfs unionsfs /ROOT -o dirs=/ramdisk=rw:/AGREG=ro

le pivot root

mkdir /ROOT/oldroot
cd /ROOT
pivot_root . oldroot
exec chroot . sh -c ‘exec /sbin/init’ <dev/console >dev/console 2>&1
[/code]

Je suis en fait obligé de finir le linuxrc afin de faire sortir le noyau puis de mettre une étape avnt le /sbin/init:

lancement avec init=/etc/init, linuxrc se termine par

echo "Initialisation du système" mkdir /ROOT cd / echo "Starting init process." rm -f /linuxrc exit 0

et /etc/init contient

[code]#!/bin/bash
PATH=/sbin:/usr/sbin:/bin:/usr/bin
cd /
mv /dev /ramdisk
mount -t unionfs unionsfs /ROOT -o dirs=/ramdisk=rw:/AGREG=ro
mkdir /ROOT/oldroot
if [ ! -d /ROOT/proc ] ; then
mkdir /ROOT/proc
fi
if [ ! -d /ROOT/sys ] ; then
mkdir /ROOT/sys
fi
chroot /ROOT mount /proc
chroot /ROOT mount /sys
umount /proc
umount /sys
cd /ROOT
pivot_root . oldroot

exec /bin/bash

exec chroot . sh -c ‘exec /sbin/init’ <dev/console >dev/console 2>&1
[/code]
mais je ne comprends pas pourquoi ça coince avec la première méthode :frowning: (il ne veut pas faire le unionfs et répond que l’option dirs=/ramdisk=rw:/AGREG=ro n’est pas connue)

#17

tu es sûr que le mount.unionfs de l’initrd et celui de la distrib sont les mêmes ?

#18

Oui, puisqu’à ce stade j’utilise le même système de fichier mais avec des liens (bin -> AGREG/bin, sbin->AGREG/sbin, etc…), et que lorsque /etc/init s’éxécute, c’est exactement la même racine (root=/dev/ram0)