je voulais faire comme dans retour vers le futur ^^
mais ça peux pas marcher comme ça oui.
Non en effet ca ne peut pas 
Qu’est ce que tu utilises pour gérer test snapshots?
J’avais vu qlqs softs qui le faisait mais rien de bien concluant pour le moment.
LDC 4TW
aucun, je fait des snapshots ro pour “backup”, rsync pour restaurer, ou des snapshots rw pour faire des experiences.
ok. je fais pariel.
3.19 avec rien de bien important pour moi dedans.
Ce topic a été crée il y a qlqs temps “le 13 Févr. 03 à 18h52”
Linus est encore un train d’y réfléchir mais il avait dit que le 3.20 serait en fait un 4.0
Ca ne change rien à rien. Le 4.0 ne sera pas une version plus spéciale qu’une autre. C’est juste pour eviter de se retrouver avec des numéros de version trop grand.
Une autre idée dans l’air étant aussi de faire un 4.1 qui ne serait qu’une release bugfix. AUCUNE nouveauté ne serait acceptée entre le 4.0 et le 4.1…mais là aussi Linus n’est pas certain de le faire car le devel risquent de raler sur le mode “rien de nouveau alors on ne fait rien pour cette release”.
4.0.1 L’idée de la version “bugfix” est passé à la trappe.
j’ai eu un evenement un peu flippant avec btrfs (linux 3.12, debian jessie), il semble KP systematiquement si je reboot via kodi (utilisateur via consolekit qui devrais plus être là, avec systemd mais pas le choix)
après ça, plus possible de monter la partoche btrfs sur une wheezie, mais fsck relève aucun problème.
mais après reboot de jessie, aucun problème visible sur le FS, j’ai pas retenté le montage sur la wheezie après un arret propre de jessie.
Les gens de btrfs sont clairs sur un point : si on veut la meilleure stabilité possible avec leur fs alors il faut utiliser le dernier noyau en date (et la dernière version de btrfs-tools).
3.12 c’est de l’histoire ancienne pour btrfs.
4.0.2 out. :jap:
on peux pas toujours maintenir soit-même le noyal à jour
bref c’est bon après un arrêt propre, plus de soucis.
j’ai pu me sortir d’une semaine de galère sous debian jessie grâce aux snapshots (le passage à systemd est encore trop frais et pose pas mal de problèmes dans mon cas) ^^
root@Pi:~# btrfs sub list /
ID 260 top level 5 path snapshots/wheezy
ID 261 top level 5 path snapshots/jessie
j’attends quelques jours avant de les supprimer, au cas où.
je sais pas si c’est rsync ou btrfs ou le couple des deux mais la restauration a été super rapide sur une carte sd.
C’est bien gentil les kernel de ce ppa kernel.ubuntu.com… mais comment installer les linux-tools pour avoir cpupower
tu les fait plus toi-même ?
les noyo? Ca dépend mais ça ne change rien à la question :
Comment recompile t on les linux-tools pour un noyo qui n’est pas packagé officiellement?
Pourquoi a t on par exemple un paquet officiel “linux-tools-3.19.0-15” ?? Car ces API ne sont pas stables?
Ok mais cpupower de “linux-tools-3.19.0-15” fonctionne avec un 4.0.4…à condition de bricoler pour passer outre les checks versions dans /usr/bin/cpupower.
En clair, la question est "comment installer proprement cpupower quand on compile ses noyo ou qu’on passe par un ppa?
(je n’ai jamais été expert en packaging de .deb)
Ca ne semble pas encore utilisé mais on peut maintenant patché le noyo en live.
Ca doit permettre de corriger des failles de sécu sans rebooter mais j’avoue que je n’ai pas regardé les détails…il doit bien y avoir certaines limitations
il me semble que c’est possible depuis un certains temps déjà.
rebooter le noyau sans reset la machine, aussi.
Heu les patchs n’étaient pas dans le noyaux officiel je crois.
“rebooter le noyau”? Qu’est ce que tu veux dire exactement?
je crois que c’est un peu plus compliqué que ce que j’ai dit en fait ^^ mais c’est kexec dans les deux cas je pense. qui permet de lancer une nouvelle instance kernel depuis l’ancienne, sans passer par la case reboot.
Je préfère appliquer le 1er commandement : dans le doute, reboot !
:paf:
et ce genre d’outils “patch live” existe depuis que kexec existe en fait mais aucun intégré à la branche officielle.