Reprise du message précédent :

Script qui n'est jamais appelé dans ton dos, heureusement d'ailleurs, car j'édite le .cfg final aussi
 

Bien joué, je ne connaissais pas connman, ça semble être le truc utilisé par defaut sur Ubuntu, non ?

ha ça je sais pas
Pourtant j'ai été un bon moment sur ubuntu et comme j'ai toujours utilisé networkmanager, je ne savais pas ce qu'il y avait derrière.
 
Un souci que je cherche à résoudre pour connman : la sortie de veille, pour le moment je dois relancer le service ; je sais pas encore comment m'y prendre

Ah
Soit tu attends que le bug soit corrigé ou la feature soit implémentée*, soit tu bidouilles en scrutant les événements de mise en vieille pour le relancer le service au retour de veille
soit tu réécris l'unit systemd pour qu'elle soit en conflit avec la target de veille ( y a eu un journal là-dessus sur linuxfr il y a quelques semaines) soit avec un démon style acpid tu dois pouvoir te débrouiller...

*Tu peux aussi voir si c'est un bug qui n'a pas été rapporté

J'ai voulu suivre le wiki pour la modification liée à Intel ucode, mais les chemins qu'ils expriment et les miens sont différents, du coup je ne sais pas trop ce qu'il faut que je fasse exactement, d'autant plus que vu que ça touche au bout, j'ai pas envie de faire une boulette. Sinon comment je joue à Hearthstone après ?

 
Ce qui me gave avec cette histoire, c'est que le mainteneur propose la solution de bricoler dans le fichier /boot/grub/grub.cfg alors que c'est un fichier généré par grub-mkconfig dont la conf est dans /etc/default/grub et /etc/grub.d...

C'est idiot-proof : Si le mec a déjà changé son grub.cfg pour une autre raison, et qu'il modifie le default/grub et regénère le grub.cfg il risque de perdre ses anciennes modifications.

Et il ne faut pas oublier que le paquet est pas obligatoire hein.
Si ca vous emmerde, vous faites pas la modif, vous viviez bien sans jusque là

Connman, c’est pas pour LXDE ou Enlightenment ?

Ou alors on l'avait déjà et ça marchait tout seul !

Elbarto, il faut le mettre où le bout de code que tu as posté ?

C'est un peu une vaste blague cette update, ça marchait trop bien avant en fait, c'est ça ?

il faut modifier le fichier /etc/grub.d/10_linux
 
 

 
la modification commence à la ligne 136, ça doit donner ça une fois les lignes modifiées :
 

 
puis tu lances la commande en root :
 

suite à la mise à jour du paquet gtk3 il y a une semaine un paquet "adwaita-icon-theme" s'est installé de manière vicieuse sans demander l'autorisation de l'utilisateur ( il est devenu une dépendance obligatoire de gtk3 ),

la conséquence c'est que maintenant au boot le serveur X va utiliser par défaut les curseurs du paquet adwaita-icon-theme juste avant d'afficher le gestionnaire de connexion graphique, c'est l'espèce de truc circulaire en bas à droite de l'image :

si on veut retrouver le curseur classique par défaut du serveur X ( un truc basique en noir et blanc, une espèce de montre en noir et blanc pour l'icône "patience" ) il suffit d'éditer le fichier /usr/share/icons/default/index.theme et mettre en commentaire la ligne "Inherits=Adwaita"

ou bien mettre un autre thème de curseur, celui par exemple de KDE, Oxygen_White :

Merci beaucoup, tu es un chef, c'est OK

formid!

J'avais vu le thème passé en loucedé et, au redémarrage, j'ai trouvé que c'était une amélioration dans mon cas.

tiens ce matin en démarrant le PC il y a eu un blocage à la toute première étape de boot :

- après avoir sélectionné "archlinux Linux avec Linux" dans le gestionnaire de boot de grub le boot se bloque après cette mention :

triggering uevents... ( pas sûr à 100% de la syntaxe )

en gros 4 à 5 lignes de texte tout en haut de l'écran et ensuite plus rien, comme si le kernel était pris dans une boucle infinie, à ce moment là systemd n'a pas encore pris la main,

j'ai dû faire un reset pour relancer le boot qui s'est alors passé normalement, depuis je n'ai pas réussi à reproduire le bug,

je me demande si cela ne serait pas lié au kernel 3.17-1 et aussi à la modification liée au paquet intel-ucode ( mis à jour du micro-code du CPU dès l'étape de boot avec grub ) ?

En parlant de cela, j'adore le "archlinux Linux with Linux".
Y'a pas un moyen de reparer le nom? Il y a 3 fois Linux tout de meme...

Bof, ca a du sens, c'est pas "cassé", pas besoin de "réparer". Et si ca te gêne vraiment, oui tu peux le changer
nom_distro + Flavor_kernel(linux,freebsd,hurd...) + package_contenant_le_dit_kernel

Je ne crois pas que c'etait ainsi il y a 2 ans, me trompe-je?

Ça doit être dans les scripts de découverte des noyaux de grub2, donc si il y a deux ans tu avais grub legacy, ou si tu avais pas utilisé grub-mkconfig depuis un bail, non

Je comprends mieux pourquoi je ne voyais pas de quoi vous parliez, j'ai quasiment que du syslinux  

Hmmmm je crois que c'etait deja en grub2 mais tu as peut etre raison.

attention cups est arrivé en version 2.0 dans les dépôts officiels, il faudra faire une manip avec systemctl pour prendre en compte le nouveau nom de service de cups,

la manip est indiquée dans la sortie console de pacman quand vous ferez la mise à jour,

sur le site d'archlinux il n'y a aucune news sur cette intervention manuelle, donc pensez à lire la sortie console de pacman

Et faire un trigger sur un paquet qui contrôle si cups est démarré au boot et faire la manip pour le user c'était pas possible

une solution aurait été d'utiliser la fonction post_upgrade() d'un fichier cups.install du paquet,

et dans cette fonction on fait un test pour savoir si le service cups.service a été activée par l'utilisateur lors de la précédente installation de cups, si oui alors le script procédera à la mise à jour du nom de service en supprimant l'ancien service et en activant le nouveau :

pas sûr de la syntaxe du if mais ça doit être possible de faire des "if" dans une fonction post_upgrade(), un if en mode script shell,

les "echo" pour les messages d'avertissement ne sont peut-être pas indispensables si le service cups avant de s'arrêter finalise les impressions en cours ( pas de risque de perdre des impressions en cours )

Petit problème pour moi depuis hier, où j’ai tenté un dualboot Arch64) / Debian (32).
Le problème en question m’empêche d’accéder à ma Debian, du coup je poste ici.
----
Donc, j’ai voulu créer un dual boot.
Voilà le plan de partitionnement :
sda1 : /boot/efi : 1Go : Fat32
sda2 : /boot/ : 1Go : Ext3
sda3 : / (arch) : 40Go : Ext3
sda4 : / (debian) : 40Go : Ext3
sda5 : swap : : 4Go
sda6 : /home (commun) (le reste) : reiserfs
 
Arch a été installée en preum's et donc Debian en second.
Que je boot sur Arch ou Debian (selon le menu), il à l’air de booter uniquement sur la racine de Arch.
Les ID de partoches dans le grub.cfg généré sont corrects pour l’entrée Debian régulière. Pour TOUTES les autres entrées, l’ID est celui de la root de Arch.
 
Des idées ?

Passe par un boot manager un poil plus performant que grub.
 
Grub, en EFI va vérifier si  
/boot/efi/EFI/debian existe  
et /boot/efi/EFI/arch aussi.
 
Grub va donc aller s'installer dans  
/boot/efi/EFI/debian/grubx64.efi  
et dans /boot/efi/EFI/arch/grubx64.efi
 
Tu va donc avoir deux grub, que ton gestionnaire EFI doit lancer séparément et dans ton /boot tu aura les kernels. Il faut bien que tes kernels soient repérés, sinon tu risque d'avoir du bordel et que les deux versions de grub soient compatibles l'un avec l'autre.
 
Ca, c'est pour la version dual grub full automatique.
 
Il y a sinon une autre solution : n'avoir qu'un seul grub d'installer, au moment d'installer grub sur l'une ou l'autre des installations, tu zappe et tu ne l'installe pas. Tu modifie ensuite /etc/grub.d/jesaipasquelfichier pour ta version et tu doit avoir un os prober ou un linux a modifier pour prendre en compte ta debian.

J’ai oublié de préciser que c’est précisément ce que j’ai fait
Donc, si je te suis bien, je laisse tomber Grub pour mon cas.
Je vais voir du coté de EFIbootmgr et l’autre dont le nom m’échappe (Refind ?).
Merci pour les conseils

les kernels stockés dans /boot sont configurés avec l'efi stub ?
custom ?
Si oui, tu passe les paramètres, si non tu doit garder grub.
 
Faut pas oublier également de passer le "real root" a l'initramfs, sinon il te bootera systématiquement sur le root de ton grub, et oui, hormis sous gentoo ou tu peu lui faire faire tout se que tu veux, les manager de paquet sur les distro ont pas pris en compte que tu peut installer de multiples linux sur une seule et même machine et souvent le realroot est laissé sur la distro d'installation de grub, donc tu te retrouve avec un kernel debian et ton userland/root arch.
 
Dans le pire des cas, envoie moi ton grub.cfg je vais tacher de voir se que je peut faire pour corriger ça
 
Edit : faut que tu check en fait ton fichier "xx_custom" et que tu rajoute :
menuentry "Debian" {
 set root=(hd0,4)
 linux /boot/vmlinuz root=/dev/sda4 (chemin vers le noyau de ta debian)
 initrd /boot/initrd.img (chemin vers l'initram de ta debian)
}

Je… ne crois pas.
En relisant mon pdf, je vois que je mélange du grub et de l’efibootmgr. Pakool

Je ne pense pas.

J’ai testé ça sur /etc/grub.d/40_custom ainsi qu’une modification de set root en 0,3, me souvenant que grub comptait en décalé.
Aucune de ces deux solutions n’a fonctionné. Du coup, je vais me replonger dans le wiki d’Arch.
Merci de t’être pris la tête.

j'ai eu à nouveau un freeze au boot avec le kernel 3.17.1-1,
 
voici ce que je vois lorsque ça freeze ( pas vraiment un freeze mais une attente dans une boucle infinie ) :
 

 
parfois quand le bug se produit je n'ai pas la ligne "tsc: Fast TSC calibration failed"
 
ça se semble se produire tous les 10 à 15 boots environ, et je pense que c'est lié au fait que la mise à jour intel-ucode a lieu maintenant très tôt en amont au niveau du boot ( au niveau de grub ), je pense que ça crée un bug lorsque le timing de la synchronisation n'est pas bon dans le processus de mise à jour du CPU, ça crée un conflit quelque part, une "collision"

 
 
"tsc: Fast TSC calibration failed" est tout sauf grave, tu auras ça à 100% avec VB par exemple !

le noyau en version 3.17.2-1 est disponible dans les dépôts officiels, j'espère que ça va corriger le bug aléatoire du freeze au boot

Je me suis débrouillé en me chrootant la Debian (à partir d’un Live Gentoo  ) et en installant « efilinux » (ou un nom approchant) et Grub (il me semble).
Du coup, ça m’a assez salopé le menu de Grub (j’ai une liste d’entrées longue comme un jour sans pain juste pour deux O.S.) mais bon, ça marche.
Merci MystX

le bug est toujours présent avec le noyau 3.17.2-1

le blocage apparait aux toutes premières secondes, parfois avant l'apparition des messages de systemd, parfois 2 secondes après,

je crois que je vais ouvrir un rapport de bug sur le bugzilla du kernel, je suis persuadé que ça vient du nouveau mode de chargement du paquet intel-ucode, ça fout le boxon avec certains CPU ou une certaine configuration matérielle

Bah vire le initrd du microcode et vois si ça continue ?

c'est ce que je vais faire

Ok, t'as pris la solution dual boot en rajoutant une touche hardcore en conservant le /boot unique. Ca marche aussi mais c'est grave pas propre.

bon finalement le problème ne vient pas de intel-ucode parce que même désactivé j'ai encore le freeze aléatoire,
 
quand le freeze apparait avant que systemd ne prenne la main je n'arrive pas à voir de message de debug, il ne se passe rien,
 
mais quand le bug apparait une fois que systemd est chargé là il y a des choses intéressantes, quand ça bloque et que j'attends 120 secondes j'ai un message du kernel "call trace", j'ai pris une photo de l'écran :
 
https://bugzilla.kernel.org/attachment.cgi?id=156341

C'est systèmd qui foire comme dans fedora

Qu’est-ce qui te met sur cette voie ?