Reprise du message précédent :
ben pour le commun des noob... si
 
enfin.. d'apres ce que j'ai pu voir autour de moi

la seule différence qu'il peut y avoir, c'est si tu lis l'anglais ou pas.

et ça change (absolument) tout

moi je le lis, mais je comprends pas bien

Bon je pose un
 
J'ai l'idée de booter sur CF je n'ai pas encore réfléchi à comment gérer après :
- copie du système en ram à la façon d'un raid 1  
- simple utilisation de la carte (j'avais lu un calcul comme quoi ca avait une durée de vie de 9 ans, suffit de changer chaque année...)
- c'est pour juste booter un solaris pour avec support zfs et gérer un pool de 6 disques en raidz2 / une petite solution LAMP (d'ou l'utlisation d'un ramfs) / deux trois conneries.
 
J'envisage de commencer avec 2go de ram et monter à 4 voire plus après
 
Des idées ?

seul les vieilles CF ne tiennent pas longtemps. toute les mémoires flash possèdent un contrôleur qui permet d'éviter ce problème maintenant, sauf peut-être les noname...

Hop le détarrage, je viens de voir ceci dans les dépôts debian/ubuntu:
http://packages.debian.org/unstabl [...] -initramfs
 
Reste à trouver la manip pour faire le squashfs (mémoire de poisson pané )

lu
 
pas le temps de m'en occupé en ce moment, mais j'ai trouvé une solution. j'ai toujours pas résolu mon problème de réseau, ça ne serait tarder.

sur www.pendrivelinux.com, il y a tout le truc pour rendre une iso de cd bootable depuis une clé usb.... de la à le mettre sur CF....
 
Bon c'est pas modifiable.... mais !
 
Il y a auusi de quoi faire une version qui prend les MaJ pour se faire un OS complet sur clef usb et qui fonctionne partout... un OS vraiment portable en fait...
 
si tu l'optimises pour ta config ca pt etre pas mal... en revanche je n'ai pas regardé si la version modifiable était toujours chargé en ram...

Bonjour, je suis ce projet avec intéret, car j'ai une idée de bidouillage.
Mon problème est proche en fait:
J'aimerais pouvoir lancer linux depuis un disque dur, charger le plus de données possibles en ram (admettons que le linux soit super légé, enfin au pire il pourrait ralumer le dd en cas de besoin, mais le but est qu'une fois l'os lancé, sur une fonctionnalité le dd reste coupé, vu la machine sur quoi ça va tourner je pars sur du runlevel3 sans interface graphique) et éteindre le disque dur système. Ceci à afin de faire par exemple un firewall matériel (ou autre) avec un vieux p1 et 96mo de ram.
Possible ou pas??? J'ai essayé l'option copy2ram à passer à grub, mais si je coupe le dd système (via hdparm) il se rallume instantanément. Hors je voudrais pouvoir l'éteindre comme ce qu'il fait lors de l'arret du dd. (le but est bien d'avoir une machine qui fait des fonctions ne manipulant pas de données cruciales, du genre firewall, fonction particulière de calcul dédié en montant des partitions qui sont sur un autre pc etc) Y a moyen de faire ça??

J'ai un peu de mal de faire un tmpfs dans un autre tmpfs
 

synaptic me dis après dl des paquets qu'il ne trouve pas les .deb téléchargés (problème de lien truc truc).
 
Dés que l'on monte un système de fichier dans un dossier, le contenu de ce dossier est "écrasé temporairement" et dans mon  cas "efface temporairement" le dossier partial. Comment faire pour avoir les 2 tmpfs sans que cela ne pose problème ?

Les logs ont l'air d'être bien gérés par ramlog:
 

 
http://tofu3.szm.sk/ramlog/
http://freshmeat.net/projects/raml [...] _id=279333
 

Monte tmpfs sur / puis monte tout ce que tu ne veux PAS dans ton ramdisk ailleur ( /dev/sdaX )

J'ai un peu contourné le problème, je crée le dossier à la connexion de l'utilisateur (testé sur un linux mint 6/gnome-session-properties, mais il faut faire la manip pour chaque utilisateur ).

crée un script shell...

J'en découvre chaque jour:
http://www.slitaz.org/
 
Une petite distrib pour mettre en mémoire vive.

Petit retour après quelques semaines d'utilisation.

Avoir un système sur CF est bien possible, les 3.73Go de ma CF sont suffisants, mais j'atteins une limite actuellement. Je n'ai aucune partition pour le système (hors DD dans /media) et j'ai du mal par moment à savoir ce qui me ronge petit à petit les quelques Mo au fil des jours. Il y a une semaine environ, j'étais à 0.96Go de libre (sur /, comprenant donc tout sauf /media), et je suis maintenant à 0.84Go de libre.
J'ai bien fait quelques mises à jour, j'ai tenté de limiter les paquets inutiles, passer un bon coup de gtkorphan et vérifier mon /home (le cache mozilla surtout).

Je pourrais économiser un peu si, par exemple certaines données temporaires (/tmp, /var/cache/apt/archives) pouvaient être "purgées" à la volée via un tmpfs ou équivalent. Mais voila, je ne sais pas trop quels fichiers surveiller. Mon /home peut être facilement suivi, mais pour ce qui touche des dossiers importants du système, je suis un peu perdu.

Je n'ai pas poussé à fond l'utilisation de la ram, et je pense qu'il serais temps de le faire. Pour une utilisation classique j'obtiens environ 350Mo (bureau xfce, principalement du surf et visionnage film/playlist FAI) sur les 1.5Go totaux (500 sont alloués au chispet).

Quelqu'un à t-il des conseils à me donner avant que je ne fasse une fausse manip ? J'ai relu récemment un article sur unionfs, mais j'ai des doutes sur sa mise en oeuvre. D'ailleurs, n'existe t-il pas une autre technique plus accessible ou plus simple à comprendre (je me suis perdu dans les déclarations de ro et rw de l'article) ?

Bref, comment utiliser mon Go de ram en "trop" tout en limitant les écritures "inutiles" ?

c'est zarb, il me semblait que l'avantage de tmpfs sur les ramdisk "a l'ancienne" était justement de pouvoir gerer la place prise en ram, de manière dinamic et donc on peut supposer "sans d'écraser les uns les autres"... j'aurais mal pigé ?

Je me suis mal exprimé.
 
Actuellement, je n'ai que /tmp et /var/cache/apt/archives en tmpfs.
Je me demande si il existe d'autres dossiers du système qui peuvent être vidés régulièrement sans poser de problèmes. Evitant ainsi des écritures inutiles sur la CF.

ben tu peux te fairee un script ds le cron (chaque jour par ex.) a base de "du" pour plusieurs repertoires et voir le quel dérive...
au debut sur repertoire du /
apres 1 semaine tu précises l avec les sous repertoire de clui ciblé et ainsi de suite... tu finiras bien par voir le quel dérive...
 
sinon plus rapide du de tous les sous rep... mais gros fichier de log...
 
evidement il faut que le resultat soit posé dans /tmp... sinon ca va remplir la CF.
 
As tu regardé du coté des log ? logrotate ? ou truc du genre ?

J'ai fait qq recherches de mon coté pour installer un système linux sur une CF et j'avais trouvé ce site:
http://jazzslider.wordpress.com/20 [...] as-part-4/
Le cron y est expliqué...

J'ai regardé le dossier log, mais il semble tout à fait normal, ou au moins pas alarmant  (6.4Mo pour 99 éléments).
 
Par exemple /var/cache/apt contient des listes de paquets, comment faire pour vérifier que ces fichiers sont à jour et ne contiennent pas des données obsolètes ?
/usr/share/locale est pas mal gros et contient de multiples sous dossier de langue, comment faire pour ne garder que les "utiles" ?
 
Ca dépasse un peu le sujet du topic quand même

apt-get +
autoclean
clean  
autoremove

un truc dans le genre pour faire le menage des vieux package...
 
sinon mon idé c'était surtout pour voir quel dossier devenanit de plus en plus gros

Petit retour sur flashybrid 0.15. C'est pas mal, ca me remplace quelques définitions dans fstab.

Par défaut, flashybrid se lance en runlevel 5 ( dans /etc/rc5.d/ pour la suite), mais après gdm se qui provoque un semi freeze de l'ouverture de session (le thême de gdm passe à la poubelle et après authentification, la souris se retrouve toute seule).

Petit tour dans les dossiers /etc/rc?.d/ pour comprendre que flashybrid se lance en dernier, ce n'est pas le mieux. Donc je renomme S06flashybrid en S05flashbryd et la session se lance correctement. Mais je me prend un message comme quoi hal n'est pas correctement initialisé

Bon on répète la manip et S05flashybrid deviens S01flashybrid et se lance donc dés le passage en runlevel 5 (mais encore après dmakms).
Ce n'est pas encore parfait car le niveau sonore n'est pas totalement sauvegardé au reboot et a tendance à me cracher dans les oreilles. Certains logs n'ont pas l'air de bien aimer ce chargement en runlevel 5 aussi.
Par exemple:

Dans l'affaire, flashybrid (via les fichiers /etc/flashybrid/ramstore et /etc/flashybrid/ramtmp) me crée ces quelques tmpfs:

Ce n'est pas grand chose en ram, mais c'est un début:

J'ai un peu modifié le script /etc/init.d/flashybrid pour tenter de forcer la création du dossier /var/cache/apt/archives/partial, sans quoi une mise à jour est impossible (apt/aptitude... râlent).
Mais sur ce point, apt/aptitude ne sont toujours pas content

Ou me sors une erreur de lien croisé  

http://www.linux-live.org/?howtos

Pour en revenir au sujet, Je vais tenter cette méthode: http://www.logicsupply.com/blog/20 [...] ux-system/
[edit] Ca semble marcher, mais du coup c'est un OS qui ne conserve aucun changement. Intéressant pour quelques utilisations (ou utilisateurs). Manque le coté update/upgrade du système
[re-edit] ah crotte, mon disque en ext3 sur /media ne veut pas être monté/lu.
[re-3] Attention, ce tuto ne parle pas de revenir sur un OS en lecture/écriture, gardez toujours un autre kernel sous la main (ou la possibilité de revenir à l'ancien inird.old)

J'ai aussi trouvé ca, reste à tester:
https://help.ubuntu.com/community/a [...] OnUsbFlash

Bon flashybrid c'est sympa, mais ca ne fait pas propre d'avoir des "doublons" dans l'arborescence et dans RAMMOUNT. Sans compter le jardinage qu'il faut faire pour le lancer au bon moment pour avoir l'OS qui tourne bien.
 
La méthode (1) est plus simple, pas besoin d'aller jardiner dans les rc?.d, mais trop expéditive car le système deviens alors readonly au prochain reboot, sans possibilité de démarrer sur le même kernel en lecture/écriture.
 
La méthode (2) à l'air de combler la lacune de la méthode (1) en permettant au boot de modifier les arguments du boot et de revenir au besoin à un OS en lecture/écriture. Manque de pot, la mise à jour de l'inird ne semble pas bien se faire et n'intègre donc pas aufs. J'ai comparé les 2 méthodes, pourtant très similaires, et même tenté un mix des deux, sans succès. Dommage Sur un poste en accès libre ou pour des utilisateurs non expérimentés ca aurait été bien sympa.
 
Il manque aussi une synchronisation à l'extinction, rien que pour garder des logs (ou alors les déplacer ailleurs que sur la partition aufs).

Nouvelle version de slitaz.
Sinon ça semble être l'idéal quand même puisque c'est un os en ram et qu'on peut couper le dd! Donc possible de faire des saveugardes quand on veut ou autre.  
Bref ça me semble l'idéal pour ce genre de projet.