Sous Manjaro il existe un meta-paquet s'appelant linux-latest qui permet de mettre à jour automatiquement le noyau si celui qui est installé est un noyau en fin de vie. La démarche est louable, mais il se trouve que je préfère gérer mes noyaux manuellement, donc ce meta-paquet n'est pas installé sur mon système. Il se trouve que lors de la dernière mise à jour, j'étais sur le noyau 5.7, il a été détecté que j'avais le 5.6 encore installé et ça me demandait si je voulais installer linux-latest.
La seule chose qui est détectée est la présence du paquet du noyau en fin de vie et non si on a un noyau plus récent d'installé ou si on l'utilise.
Si quelqu'un à une idée pour empêcher cette détection de noyau obsolète, paramètre dans un fichier de conf quelque part ou une variable d'environnement à modifier (ou même une piste sur la façon dont ça fonctionne), je lui en serai reconnaissant.
Effectivement il est préférable de l'enlever afin d'avoir le contrôle sur la gestion des noyaux. Ce paquet est plutôt destiné à simplifier cette gestion pour l'utilisateur qui ne veut pas s'embêter . Perso, je l'ai viré peu de temps après son arrivée dans les dépôts.
Manjaro-Xfce-Compiz 64
Desktop
CPU amd-phenom-64(pci=nomsi dans grub)
CG nvidia GeForce GT 730
Ram : 4 Go
kernel : 54 branche : stable, driver GPU : Nvidia-non-libre
stephane a écrit : ↑il y a 3 ans
il suffit de retirer le paquet linux-latest
sudo pacman -Rs linux-latest
Comme je le précisais :
donc ce meta-paquet n'est pas installé sur mon système
C'est pourquoi j'ai eu droit aux questions me demandant si je voulais installer linux-latest et linux-latest-headers, mais je voudrais savoir comment la détection du noyau EOL se fait sans linux-latest installé et comment éviter d'avoir ces propositions d'installation des paquets latest.
J'avoue que ce n'est pas simple et que je n'ai pas de réponse fiable...
Je l'ai viré sitôt une nouvelle installation.
Par contre , j'ai du nettoyer à la main /etc/mkinitcpio.d/ des noyaux pourtant déjà supprimés via mhwd-kernel -r
Edit : Je pense qu'il y a un lien . https://forum.manjaro.org/t/pamac-wants ... u=lemust83
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
oui, cette action est déclenchée lorsque le noyau n'est plus dans les dépôts (à vérifier ? donc pas de véritable lien avec EOL )
pacman sait que nous avons linux"XX" et puisque qu'il n'est pas dans les dépôts va le chercher .... dans la DB pacman et trouve ... linux-latest
ce méta paquet a une ligne type (Replaces : linux318 linux420 linux50 linux51 linux52 linux53 ...)
et donc pacman fait le lien "inverse" et nous propose de remplacer notre paquet inexistant par latest
Comme le dernier post du fil n'est pas de toi, tu n'as sans doute pas encore résolu le problème...
Une piste peut-être mais non automatique du tout, réutiliser syslinux qui a un fichier de config -> syslinux.cfg avec la version du noyau souhaité, non je déconne !
LABEL archbase
MENU LABEL Manjaro Base
LINUX /boot/vmlinuz-4.14-x86_64
APPEND root=/dev/sda1 rw quiet intel_pstate=disable vga=773
INITRD /boot/initramfs-4.14-x86_64.img
LABEL arch
MENU LABEL Manjaro Light
LINUX /boot/light/vmlinuz-4.19-x86_64
APPEND root=/dev/sda3 rw quiet vga=773
INITRD /boot/light/initramfs-4.19-x86_64.img
La partie juste nécessaire -> c'est moins imbitable que grub, n'est-il pas..!
J'ai un multiboot (mais sans redmondie) qui tourne toujours comme une horloge depuis des lustres avec
Par contre, à chaque mise à jour noyau, il fait remplacer initramfs-blabla & vmlinuz-blabla dans /boot par les nouveaux.
J'ai un script qui fait ça & que j'envoie à la main dès que je vois/oupas une maj noyau
& de mémoire il y a un dans /boot ficher de version non nécessaire pour moi mais avec lequel il y a peut-être moyen pout toi de leurrer grub (si c'est lui le responsable...) !
"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher"
Antoine de Saint-Exupéry
la présence de linux-latest bascule le noyau nouveau automatiquement ,
or il s'est produit sur la version 5.8.0-1 ,
on sait très bien que dans les premières versions tout n'est pas présent
- il peut manquer des drivers wifi ou bluetooth
- il peut manquer des firmware
- je ne parle pas pour ceux qui ont un souci réel au démarrage
en réalité on devrait laisser sur la version 5.7.x précédente , et lorsque la stabilité s’améliore on bascule sur le nouveau en prévenant de la montée de version
il suffit de voir le chancelog des 2 dernières versions des patchs importants sont proposés depuis 2 semaines et cela n'est a mon avis pas terminé
nb pour le BTRFS , je me pose la question QUAND ils auront fini de corriger les erreurs ....
a chaque montée de version , on doit aussi ajouter les headers , le firmware , le microcode et on espère un virtualbox qui puisse fonctionner ( toujours en retard ).
"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher"
Antoine de Saint-Exupéry
Le problème, c'est qu'il faut tenir compte du décalage entre linux.org et Arch, puis entre Arch et Manjaro stable, comme on peut le voir, le 5.7 est EOL.
Smurf a écrit : ↑il y a 3 ans
vérifier les commits sur Gitlab
Ce paquet n'est pas forcément mis à jour au bon moment (la dernière fois une issue car oublié)
je pense que la première info sur les EOL manjaro arrive dans les annonces de maj testing
Aujourd'hui 57 marqué EOL dans annonce testing mais est encore latest sur gitlab
---
OOPS oubli impardonnable de ma part
en fait il faut utiliser (l'api) compare-branches :
* si pas de version en unstable (ou testing) il va disparaître en stable
Par contre l'annonce testing à l'inter est en avance sur branche-compare
Idée de réutiliser branch-compare transmise aux dev, le json est trop gros il faut donc en créer un autre et après voir quel outil pour alerter (msm,pamac,pacman hook...)...
écrit le script test avec les branches (pour l'instant linux57 est encore dans unstable)
#!/usr/bin/python
import subprocess
import urllib.request, json
# curl -s "https://manjaro.org/branch-compare/datas.x86_64.txt" | python3 -m json.tool | less
url = "https://manjaro.org/branch-compare/datas.x86_64.txt"
response = urllib.request.urlopen(url)
data = json.loads(response.read())['data']
# pkg only in stable and in "core" repo
data = [p for p in data if (p[2] == "n/a" or p[3] == "n/a") and p[4] == "core" ] # good is "repo"
eofs = set([p[0] for p in data]) # want only names
#eofs.add('linux58') # for test
outk = subprocess.run('mhwd-kernel -li | grep -o "linux.*"',
stdout=subprocess.PIPE,
shell=True,
text=True).stdout.replace(')','')
kernels_user = set(outk.splitlines())
currentk = subprocess.run('mhwd-kernel -li | grep -o "(linux.*)"',
stdout=subprocess.PIPE,
shell=True,
text=True).stdout
currentk = currentk[1:-2]
print("EOF:", eofs, end="\n\n")
print("User kernels:", kernels_user)
print("current kernel:", currentk, end="\n\n")
diff = eofs.intersection(kernels_user)
if diff:
print("common packages:", diff, " Warning kernel installed and EOL")
if any([ currentk in i for i in eofs]):
print(f"ALERT, you use a EOL kernel {currentk}")
pour test, truqué et ajouté linux58, le résultat donne
EOF: {'linux58'}
User kernels: {'linux58', 'linux57', 'linux419'}
current kernel: linux58
common packages: {'linux58'} Warning kernel installed and EOL
ALERT, you use EOL kernel linux58
Effectivement il est préférable de l'enlever afin d'avoir le contrôle sur la gestion des noyaux. Ce paquet est plutôt destiné à simplifier cette gestion pour l'utilisateur qui ne veut pas s'embêter 
. Perso, je l'ai viré peu de temps après son arrivée dans les dépôts. 
