Reprise du message précédent :
ok et est-ce que tu as pu redémarrer ?
 
je vais essayer de démarrer via l'iso d'archlinux et de faire un chroot pour voir ce qui a merdé,
 
je vais essayer aussi de désactiver le lancement de Slim, pour que je puisse au moins avoir accès à la console

effectivement dans le locale.gen.pacnew , toutes les locales sont commentées, j'ai donc décommenté celles que j'utilise dans ce fichier, j'hésite à faire le merge ou à garder 2 fichiers identiques avec un .gen et un .gen.pacnew
 
Sans locale, glibc est planté.
 
Je pense que la solution la plus efficace serait de booter avec un livecd puis de rééditer les fichiers

 
j'ai pas essayé et je suis pas très chaud là parce que j'ai pas la possibilité de me permettre un plantage hard maintenant

tu avais mergé le .pacnew avec locale.gen ?

non justement, je n'ai rien fait concernant ce fichier pacnew,
 
j'ai juste executé le "pacman -Syu", j'ai vu que tout était ok donc je ne me suis pas inquiété,
 
j'ai ensuite rebooté et c'est là que l'écran noir est apparu au lieu de "Slim",
 
là je cherche maintenant à faire un chroot depuis le live cd d'archlinux pour justement désactiver le lancement du service "slim", quel est déjà la syntaxe pour faire cela avec systemctl ?

 
systemctl disable slim.service

ça ne fonctionne pas, j'ai le message :
 
operation failed: no such file or directory
 
il n'y a pas une autre méthode plus simple, en supprimant le script slim ?

même en faisant un "pacman -R slim" ça ne fonctionne pas, ça me met "target not found : slim",

c'est vraiment le bordel quand on est en chroot, j'ai dû oublier une manip

désolé mais là je sèche un peu
 
tu peux pas éditer le fichier locale.gen.pacnew directement depuis ton live environment ?

si je peux faire ça,
 
là j'ai desinstallé slim mais ça ne résout pas le problème, toujours ce maudit écran noir ( bien que systemd réussit à afficher ses propres message de boot )
 

 
slim est moins le soucis que glibc.
 
je pense qu'il faut que tu réédites le fichier locale.gen.pacnew, merger, et refaire un pacman -Syu pour réinstaller les paquets (glibc)

j'ai désactivé tout ce qui était gestionnaire de lancement de bureau graphique ( Slim, KDM ) et maintenant je peux acceder à la console de connexion texte,
 
du coup je me suis logué, puis tapé "startx" mais là X ne se lance pas,  j'ai les messages texte de lancement de X:
 
initializing built-in extension SHAPE
initializing built-in extension MIT-SHM
et ainsi de suite jusqu'à  
Loading extension GLX
 
et là plus rien, pas d'interface graphique, quand je selectionne la console tty7 je n'ai rien, et pas moyen d'utiliser une autre console tty, je suis bloqué en tty1

j'ai trouvé la solution :
 
ça venait des modules "virtualbox guest addition" qui n'est pas compatible avec la dernière version de glibc, il suffit de désactiver ces modules dans /etc/modules-load.d/ et de désactiver le service virtualbox avec systemctl
 
 
peut-être un bug avec les paquets virtualbox-guest-modules 4.2.6-3 et virtualbox-guest-utils 4.2.6-1,
 
donc magicpanda tu peux redemarrer, tu ne seras pas touché par le problème, sauf si tu utilises virtualbox et les guests additions,
 
cette mésaventure m'a permit au moins de tester le chroot avec l'iso d'installation d'archlinux

ah super, merci

 
Je n'ai jamais activé les modules de VB via ce truc depuis que je suis sous systemd, tu l'as fait à la mano ? Parce que l'installation via pacman des guest additions ne m'a jamais trop posé ce genre de problème, alors que je suis en testing pourtant (et que j'update un peu compulsivement 2/3 fois par jour minimum xD)

à l'époque où j'avais installé pour la première fois les guests addition je n'utilisais pas systemd ( c'était il y a plus d'un an ),

dans le wiki il est bien indiqué qu'il faut créer un fichier conf dans /etc/modules-load.d :

https://wiki.archlinux.org/index.ph [...] _Additions

ça permet de charger ces modules ( vboxguest, vboxsf, vboxvideo ) au démarrage,

un rapport de bug a été crée :

https://bugs.archlinux.org/task/332 [...] &sort=desc

la version "testing" des guests modules est différente de la version stable ( 4.2.6-4 au lieu de 4.2.6-3 ) c'est peut-être pour ça que tu n'a pas eu le problème avec la dernière version de gcc-lib et glibc

bon ca a marché mon reboot

en fait l'astuce pour ne pas avoir de problèmes serait une touche de raccourci au boot permettant de dire à systemd de ne pas lancer automatiquement GDM/KDM/Slim au boot,
 
car dans le cas présent ce qui entrainait le blocage c'était le fait que le lancement automatique d'une session X entrainait un écran noir avec le clavier désactivé,  d'où l'obligation de faire un chroot pour désactiver le service GDM/KDM/Slim ( ce qui est contraignant car faut avoir un livecd linux sous la main ),
 
donc peut-être une idée de développement pour l'auteur de systemd, une touche "panic" pour shunter systemd et obtenir une console texte de connexion minimale permettant de faire des manips sur le système, un peu l'équivalent de la touche "F8" sous windows quand on voulait un démarrage spécial ( mode sans échec )

le rescue mode existe déjà
 
systemd.unit=rescue.target
 
à ajouter à la ligne de démarrage du noyau il y a d'autres cibles)

 
intéressant, je vais regarder ça de plus près et mettre en place cette option de boot minimale    
 
je pensais m'orienter plutôt vers un grub 2.0 qui chargerait le fichier iso d'installation d'archlinux :
 

Il existe un peu plus simple : ajouter emergency (ou rescue) dans la ligne de boot du noyau, ça se fait facilement à la volée avec grub et syslinux. Bon avec ce dernier j'ai carrément fait une entrée de boot supplémentaire étant donné la propreté et maintenabilité du fichier de conf.
 
Différence entre les deux : The emergency.target has no corresponding sysvinit runlevel, and would just boot your machine to a shell with really nothing started. rescue.target is like the old single user or runlevel 1 from sysvinit

ça choque personne le fait qu'on ai pas eu de mise à jour du noyau linux depuis le 14 décembre ?

on est bloqué en 3.6.10 alors que la version stable sur le site kernel.org est la 3.7.1,

ce 3.7.1 est uniquement disponible sur le dépot testing d'archlinux, il doit y avoir des bugs là-dedans pour qu'on soit bloqué sur la 3.6.10

Ca m'a etonne aussi, je viens d'arriver sur la distrib et je pensais que ca tournait plus vite que ca
gentoo est en 3.7.1

normalement quand tout va bien on a quasiment chaque semaine une mise à jour du paquet concernant le noyau sous archlinux,
 
mais bizarrement depuis le 14 décembre on est bloqué à cette version 3.6.10, aucune explication sur le forum officiel

 
problèmes de fiabilité / compatiblité, si t'es en testing faut s'inscrire à la mailing list pour suivre les news

il s'agit de cette mailing list ? :
 
https://mailman.archlinux.org/piper [...] ev-public/

yep

j'ai regardé les messages dans les archives de décembre 2012 et janvier 2013 mais j'ai pas vu de messages concernant des problèmes particuliers pour le noyau 3.7.1

https://mailman.archlinux.org/piper [...] /date.html

tu peux peut-être faire un copier-coller ici des mails que tu as reçu concernant les problèmes du noyau 3.7.1, j'ose pas installer la version testing

sinon ils viennent de mettre sur  le dépot core la version 3.6.11-1

https://bbs.archlinux.org/viewtopic.php?id=154625

https://bbs.archlinux.org/viewtopic.php?pid=1217910

une des particularités d'archlinux c'est la fréquence des mises à jour beaucoup plus nombreuse qu'une distribution classique,

du coup à force de faire chaque jour des "pacman -Syu" et des "pacman -Sc" est-ce qu'il y a un risque d'augmenter la fragmentation des fichiers ?

je sais qu'on raconte que le système de fichier ext4 est résistant à la fragmentation, est-ce qu'il y a une commande qui permet de vérifier le taux de fragmentation des fichiers ? Ce qui permettrait de comparer par rapport à d'autres distributions ( j'ai une machine virtuelle archlinux et debian )

 
Bah dans une VM du genre Virtualbox, la fragmentation c'est pas spécialement chiant.  
 
Par contre, ce qui peut l'être c'est que ton VM.vdi fasse 20Go alors que tu n'as que 10Go réellement sur le disque de cette VM. C'est normal dans le cas où il y a pas mal de création / suppression de fichiers surtout dans le cas évoqué plus haut (pacman -Syu et -Sc), parce que lorsque tu remplaces un firefox 18.0-2 par un 18.0.1-1 tu augmentes la taille du vdi par la taille du 18.0.1-1, donc avec kernel linux et autres joyeusetés qui sont souvent mise à jour, ça monte relativement vite (surtout en testing).
 
La solution dans ce cas c'est d'utiliser zerofree et la commande VBoxManage modifyhd --compact VM.vdi pour récupérer l'espace libre et consolider l'image. Certains utilisent aussi le clonage de Virtualbox mais je préfère le faire avec zerofree en mode "emergency" (avec des e2fsck -f avant quand même) avec un script prévu pour.

j'ai aussi un pc portable avec archlinux d'installé dessus, cette fois pas de machine virtuelle ici,
 
du coup dans ce cas d'utilisation est-ce que la fragmentation peut grimper ?
 

Le noyau 3.7 est enfin dans core

 
On est en avance avec fedora

ouai ba le nouveau fichier d'install 2013 est tout pourri, noyau corrompu du coup je pense que je vais mettre un bsd sur mon desktop pour voir

T es pas cense tester les noyaux linux maintenant que t'es le patron du topic?  

j'ai arch sur mon laptop quotidien mais sur le desk c'est variable (j'ai longtemps eu windows xp meme, excel oblige)

Allan McRae <allan@archlinux.org> 07:22 (Il y a 1 heure) à Public

Sinon, un nouvel déviré d'Arch : http://archbsd.net/

ca va être foireux, parce que systemd est dans arch, et peut pas se porter sur bsd ...