MAJ systemd

fassil a écrit :Salut ewolnux,

Tu as raison, je me suis un peu emballé sur grub (2.02.beta2-6 à nôtre àge & à l'heure qu'il est, toujours pas finalisé ? ) mais la seule chose Unifiée du monde Linux ne me fait + rêver & m'a fait perdre trop de temps à essayer de comprendre son fonctionnement "usinesque, voire à gaz".

Est-ce pour autant que grub n'est pas utilisable et ne serait pas stable ? Usine à gaz ? Disons que grub offre de multiples possibilités, et je trouve qu'il fait plutôt très bien ce pourquoi on l'installe.
D'ailleurs pourquoi autant de distributions l'utilisent ?

Je rebondit un peu sur ces histoires de Grub, car j'ai une question quand il y a une mise à jour de noyau

Deux OS d'installés A : ArchLinux et B : Manjaro ( par ex)
Grub est installé par A
Il y a une mise à jour du noyau de Manjaro : la procédure d'installation du nouveau noyau ne va t-elle pas aller écrire dans le grub et ainsi prendre la main sur le grub (un grub géré soit par A soit par B au gré des maj de noyau) ?

Dans l'absolu cela ne me gène pas du moment que tous les OS soient reconnus !

patri-arch a écrit ::salut:
Je rebondit un peu sur ces histoires de Grub, car j'ai une question quand il y a une mise à jour de noyau
Deux OS d'installés A : ArchLinux et B : Manjaro ( par ex)
Grub est installé par A
Il y a une mise à jour du noyau de Manjaro : la procédure d'installation du nouveau noyau ne va t-elle pas aller écrire dans le grub et ainsi prendre la main sur le grub (un grub géré soit par A soit par B au gré des maj de noyau) ?
Dans l'absolu cela ne me gène pas du moment que tous les OS soient reconnus !

Bonjour

La mise à jour de grub (chez manjaro et arch) ne fera qu'un simple update-grub et en aucun cas un grub-install.
Donc le proprio du grub reste le proprio. Il te suffira de rebooter sur le proprio du grub et de faire un simple update-grub.

C'est valable dans quasi toutes les distros, sauf, je l'ai dit plus haut, chez Rosa. Chez eux, un upgrade de noyau se fait par un grup-install + update-grub. Pas moyen d'y échapper.

ewolnux a écrit :
patri-arch a écrit ::salut:
Je rebondit un peu sur ces histoires de Grub, car j'ai une question quand il y a une mise à jour de noyau
Deux OS d'installés A : ArchLinux et B : Manjaro ( par ex)
Grub est installé par A
Il y a une mise à jour du noyau de Manjaro : la procédure d'installation du nouveau noyau ne va t-elle pas aller écrire dans le grub et ainsi prendre la main sur le grub (un grub géré soit par A soit par B au gré des maj de noyau) ?
Dans l'absolu cela ne me gène pas du moment que tous les OS soient reconnus !

Bonjour

La mise à jour de grub (chez manjaro et arch) ne fera qu'un simple update-grub et en aucun cas un grub-install.
Donc le proprio du grub reste le proprio. Il te suffira de rebooter sur le proprio du grub et de faire un simple update-grub.

C'est valable dans quasi toutes les distros, sauf, je l'ai dit plus haut, chez Rosa. Chez eux, un upgrade de noyau se fait par un grup-install + update-grub. Pas moyen d'y échapper.

Merci pour ces précisions , donc update-grub va juste toucher les fichiers qui sont sous le /boot/... de la version concernée.

On va finir par tout comprendre des mystères de Grub ( l'outil favori de Fassil :rire

)

Oui, le update-grub ne va que générer qu'un nouveau /boot/grub/grub.cfg mais ne va pas toucher à grub installé à la racine du disque.

Pour fassil, il faudra penser peut-être à des cours particuliers :sourire:

update-grub n'est que l'alias de

# grub-mkconfig -o /boot/grub/grub.cfg

Exemple pratique : j'ai 2 HDD, mon OS principal sur le premier qui pilote et met à jour son grub sur le sda
mon OS de secours sur le 2° HDD qui a installé et pilote son grub sur le sdb
...et le Bios qui, à tout moment, peut booter sur le 2° HDD même si, par défaut je lui ai indiqué le 1er.

Bon, mais tout ça va devenir obsolète avec l'UEFI, je tremble au boulot que je vais devoir faire sur la prochaine bécane (on va reculer à 2016, hein ?)

waitnsea a écrit :Bon, mais tout ça va devenir obsolète avec l'UEFI, je tremble au boulot que je vais devoir faire sur la prochaine bécane (on va reculer à 2016, hein ?)

L'UEFI n'est pas inévitable. J'ai une bécane récente avec gestion de l'UEFI et je continue d'installer en mode Legacy (bios).

vitesse et sécurité de boot, chef... :biere:

bah j'ai grub et pourtant bios est en uefi, les disques en gpt (çà c'est logique... :gsourire:

). Pas de souci lors des mises à jour d'un coté comme de l'autre.

Aîe,

hwdb.bin does not exist, please run udevadm hwdb --update

Va sans doute bientôt apparaître en haut à gauche de l'écran au démarrage suite à cette maj de systemd.
Au bout de deux trois boot (le temps de lire & de s'apercevoir que c'est sans conséquence aucune) l'on essayera la solution proposée (run blabla) qui ne donne rien & un p'tit tour dans la forêt de Archwood en mode "bulletin board system" pour ceux que ça défrisent règlera le problème (juste ajouter le numéro de noyau courant dans la dernière commande -> linux317 par ex.)
Ca été un brin + long pour moi qui me suis passé des entrées "fallback" avec syslinux (trois systèmes installés, c'est déjà au moins deux plans B) & si quelqu'un est dans le même cas, il n'a qu'a dire :clindoeil:

Restera juste ensuite un "starting version 217" moins agaçant...

Salut fassil

J'en parlais ici. Une prochaine màj corrigera ça ; en attendant on peut zapper.

O_ops, je n'avais pas vu :siffle

Pas grave, une piqûre de rappel n'est jamais inutile :clindoeil:

j'ai eu la même chose sur arch, en fait ont peu ajouter hwdb.bin dans initramfs, en modifiant le mkinitcpio.conf, mais apparemment ça ne vaut pas la peine, dans la version 218 de systemd ce message sera rétrogradé en message de débogage, et ne sera plus visible au boot.

leeroyke a écrit :j'ai eu la même chose sur arch, en fait ont peu ajouter hwdb.bin dans initramfs, en modifiant le mkinitcpio.conf, mais apparemment ça ne vaut pas la peine, dans la version 218 de systemd ce message sera rétrogradé en message de débogage, et ne sera plus visible au boot.

systemd 217-7 à résolu ce problème dans la branche unstable :bien

Erwan a écrit : systemd 217-7 à résolu ce problème dans la branche unstable

Dans la branche stable (arch) déjà hier.