Et quand tu changes de version du noyau, il faut que tu remettes à jour ce script à la main.
Avant, le script de Debian pour Grub 0.9 te le faisait pour toutes les entrées, non ?
Avant je perdais tout et il fallait que je me souvienne de mes modif' (ou que je maintienne un diff).
Le problème avec Grub 0.9, c’était que chaque distrib devait faire sa tambouille pour ajuster le fichier de config lors des mises à jour du noyau.
On est d'accord.
Grâce à Grub 2 (enfin les scripts qui viennent avec), c’est pris en charge directement… mais partiellement seulement.
C'est déjà un mieux, non ?
Et pourtant la solution existait sur certaines distributions et était simple : que l’installation du noyau maintienne un lien nommé par exemple vmlinuz sur le dernier noyau et vmlinuz.old sur le précédent (il suffit de renommer l’ancien vmlinuz ; je passe sur la version moins tapette et encore plus simple d’Arch, qui considère qu’un seul noyau suffit).
La solution Arch est profondément idiote. Il m'arrive de m'amuser avec de la compilation de noyau. Je crée des paquets je les installe, je reboot ça marche super, ça marche pas je boot sur le précédent.
Avoir 2 noyaux ça peut être limite. Personnellement j'aime bien savoir sur le quel je boot. Me dire "le dernier" et "le précédent" ça ne me plaît pas.
En général j'ai 3 noyaux d'installé, celui de la distrib', le dernier que j'ai coupilé et le précédent que je garde jusqu'à ce que je compile le suivant. Au final j'ai un 2.6.32, un 3.2 et un 3.3. C'est un usage particulier de gars tordu ? Peut être mais pour mon cas d'usage je suis content de ce que propose par défaut ma distrib.
Pour ton cas d'usage grub2 s'adapte facilement :
#!/bin/shLINUX_VERSION=$(...)# ici tu cherche le numéros de version de ton dernier noyau# sur ma Debian je ferrais ça :# ls /boot/vmlinuz-* | cut -c 15- | sort | tail -n1
cat <<EOFmenuentry 'Debian GNU/Linux, avec Linux ${LINUX_VERSION} sans e4rat' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod ext2 set root='(hd0,msdos2)' search --no-floppy --fs-uuid --set 348f2f55-a3ec-450f-9968-143f0e0b7825 linux /boot/vmlinuz-${LINUX_VERSION} root=UUID=348f2f55-a3ec-450f-9968-143f0e0b7825 ro init=/sbin/init quiet initrd /boot/initrd.img-${LINUX_VERSION}}EOF
à mettre dans un fichier de /etc/grub.d/. Ça pourrait être donné par dans ta distrib'.
Au final par rapport à ce qu'il y avait avant : un fichier unique qui a des conflits entre nos modifications et celles du système et une solution différente par distribution. On a un système qui pose des bases qui gère 80% des utilisations et qui peut facilement s'adapter par les distributions ou l'utilisateur pour des cas d'usage particulier sans aller à l'encontre de l'upstream. Il est même possible de remonter à l'upstream c'est scripts et amélioration.
Franchement qu'est ce qu'il faudrait de plus ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Grub
Posté par barmic . En réponse au journal Arch et le tournant. Évalué à 1.
Avant je perdais tout et il fallait que je me souvienne de mes modif' (ou que je maintienne un diff).
On est d'accord.
C'est déjà un mieux, non ?
La solution Arch est profondément idiote. Il m'arrive de m'amuser avec de la compilation de noyau. Je crée des paquets je les installe, je reboot ça marche super, ça marche pas je boot sur le précédent.
Avoir 2 noyaux ça peut être limite. Personnellement j'aime bien savoir sur le quel je boot. Me dire "le dernier" et "le précédent" ça ne me plaît pas.
En général j'ai 3 noyaux d'installé, celui de la distrib', le dernier que j'ai coupilé et le précédent que je garde jusqu'à ce que je compile le suivant. Au final j'ai un 2.6.32, un 3.2 et un 3.3. C'est un usage particulier de gars tordu ? Peut être mais pour mon cas d'usage je suis content de ce que propose par défaut ma distrib.
Pour ton cas d'usage grub2 s'adapte facilement :
à mettre dans un fichier de
/etc/grub.d/. Ça pourrait être donné par dans ta distrib'.Au final par rapport à ce qu'il y avait avant : un fichier unique qui a des conflits entre nos modifications et celles du système et une solution différente par distribution. On a un système qui pose des bases qui gère 80% des utilisations et qui peut facilement s'adapter par les distributions ou l'utilisateur pour des cas d'usage particulier sans aller à l'encontre de l'upstream. Il est même possible de remonter à l'upstream c'est scripts et amélioration.
Franchement qu'est ce qu'il faudrait de plus ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)