Reprise du message précédent :
c'est remoi.
J'ai voulu installer Arch sur mon ordi à côté de mon installation existante de elementary-OS (j'avais deux partitions de libre d'une vieille installation de Xubuntu).
Mon disque est partionné comme tel:
/dev/sdb1 - swap (commun aux deux linux)
/dev/sdb2 - Arch /
/dev/sdb3 - Arch /home
/dev/sdb4 - extended
/dev/sdb5 - eOS /
/dev/sdb6 - eOS /home
 
J'ai suivi le beginners' guide jusqu'à l'installation de grub.
Je n'ai pas fait : grub-install --recheck /dev/sda
A la place j'ai juste fait:

 
Seulement après avoir selectionné Arch dans le boot loader j'ai ça :
http://reho.st/self/ca84a7874b300d [...] f0060f.jpg
 
Manifestement il ne parvient pas à monter une des partitions, l'UUID qu'il cherche n'existe pas. Voilà mes uuid:

 
Et voilà le /etc/fstab de Arch:

 
Il n'a aucune raison de chercher cette partition "ad4103fa...".
Vous comprenez où est le problème ?

Ce path part du principe que t’es en LiveCD pour réparer et que t’as monté /boot dans /mnt.

Ok je vais essayer ça.
Je peux le faire à partir d'eOS ? (en ayant monté /dev/sbd2 quelque part).
Mais à quoi correspond la partition "ad4103fa" ?

En fait la carte n'est même pas reconnue par X :

Alors qu'il devrait afficher quelque chose comme ça (tiré du Wiki Arch de Prime) :

Bref il ne voit que le chip graphique Intel et pas l'AMD.

Et sinon, rien à voir mais ce matin je peux pas mettre à jour Arch :

 
Le paquet est dispo dans cette version depuis les dépôts (mis à jour aujourd'hui). Réessaye un peu plus tard, ou change de miroir.
 
Edit: python-pyasn1-modules est en version 0.0.6-1 depuis aujourd'hui, mais python-oauth2client demande encore explicitement la 0.0.5 (dernière màj le 1er juin). Va sans doute falloir une mise à jour du paquet... En attendant tu peux ignorer la mise à jour de python-pyasn1-modules et python2-pyasn1-modules et mettre à jour le reste.

Je crois qu'il faut quand même faire les deux (tu peux même te contenter d'un simple grub-install /dev/sda, mais il paraît que c'est sale, même si j'ai jamais eu de souci de cette manière).

Donc /boot c'était dans Arch ? Et comme tu as pas réinstallé grub dans le MBR, il doit donc toujours pointer vers le / d'eOs,  (sdb5) et dans ce cas tu n'aurais pas pu voir ta nouvelle config dans le menu de grub...
Y a un truc que je ne suis pas là... Tu es sur de bien avoir décrit ce que tu as fait

 
oui c'est pas bon signe,
 
est-ce que tu peux désactiver dans le bios du portable la carte graphique intel ?
 
c'est juste pour voir comment réagira archlinux, à priori xorg devrait planter et t'afficher l'invite de commande plutôt que le mode graphique, ou alors il va utiliser un pilote générique

Que donne un "pacman -Qs xf86-video" ?

perso j'ai ça avec ma radeon HD 4650 :
 

 
peut-être qu'il lui manque le paquet xf86-video-ati

Oui, Grub pointe toujours sur le / d'eOs.
En effet, je suis repassé par eOS et j'ai réactualisé grub pour qu'il prenne en compte Arch.
Ce n'est pas possible de continuer d'utiliser mon grub installé jusque là ?

Du coup c'est ce que j'ai fait, j'ai tapé : grub-install --recheck /dev/sdb.
Ça a écrasé mon ancien grub généré par eOS et ça fonctionne bien avec mes trois OS. Par contre je ne peux plus configurer le menu facilement comme je le faisais avec grub-customizer sur eOS (et celui d'eOS ne voit pas le grub d'Arch), je me doute que je pourrais le faire à un moment quand j'aurais installé un environnement graphique (et je peux surement d'ores et déjà le fait en cli), je n'ai pas encore regardé.

 
$ pacman -Qs xf86-video
local/xf86-video-ati 1:7.5.0-2 (xorg-drivers xorg)
    X.org ati video driver
local/xf86-video-intel 1:2.99.917+364+gb24e758-1 (xorg-drivers xorg)
    X.org Intel i810/i830/i915/945G/G965+ video drivers
 

 
Non, j'avais déjà essayé, le Bios n'offre aucune option pour activer / désactiver le chipset Intel.

Ah oui, en l'état ça me semble mal barré là...
Demande peut-être de l'aide sur le bbs.
Ça vaudrait aussi le coup de tester sans ces drivers spécifique, juste avec xf86-video-modesetting qui est inclus dans le serveur...

j'ai demandé sur le fil dédié sur bbs.archlinux.org :  
 
https://bbs.archlinux.org/viewtopic [...] 3#p1537843
 
Mais j'ai pas eu plus de succès, et un gars avec la même configuration n'a jamais réussi à faire fonctionner son AMD...

Va sur l'irc des devs de mesa/dri et demande là-bas si c'est au moins supposé marcher ou s'il manque des features. Au moins tu seras fixé

OK, je comprends rien aux IRC ; je suis sur le channel dri-devel mais je peux envoyer aucun messaeg ; il faut faire quoi ?

edit : OK, il faut s'inscrire. J'ai trouvé.

Y'a des channels ou faut etre identifie sur freenode pour pouvoir poster.
Ca devrait te le dire normalement.

Bon bin j'ai eu une réponse qui laisse un petit espoir :  
 

 
peut-être après le kernel 4.2 ?

Et si j'en crois la page Wikipedia :  
 
https://en.wikipedia.org/wiki/List_ [...] 2xx_Series
 
Ma carte est une R7 M260, "Modele name : Topaz", donc "codename : Iceland" :  
 
http://lists.freedesktop.org/archi [...] 84083.html
 

 
Bref, attendons et espérons...

Si t'es motivé, c'est tout chaud, ça a été mergé dans linux-next : https://git.kernel.org/cgit/linux/k [...] t-20150623
Doit bien y avoir un PKGBUILD linux-next sur AUR.
 
Et tu devras trouver la branche correspondante de mesa.
 
Je te conseille de te lancer que si tu es bien à l'aise avec tout ça... Sinon t'as juste 3 mois à attendre

Sur l'IRC on me dit :
 
[14:46] <mareko> Tromzy: it will be merged, but I don't know if it will be usable for users
[14:47] <Tromzy> why not ?
[14:49] <mareko> Tromzy: at this stage, GPU hangs are likely to occur
 
Donc ça ne présume rien de bon...

 
Merci Mais je préfère attendre...  

en mettant à jour aujourd'hui mon installation archlinux 32 bits sur un portable j'ai remarqué ce message d'erreur au boot juste avant que systemd affiche ses messages ( type [ok] en vert ) :

failed to get cgroup, directory not exist

vous avez eu la même chose ?

le bug n'apparait que sur la version 32 bits d'archlinux quand on installe le paquet systemd-221

car quand j'installe le même paquet en version 64 bits sur une installation d'archlinux il n'y a pas ce message d'erreur et le plus étonnant c'est qu'à l'écran on lit "started version 219" alors que c'est le paquet systemd en version 221 qui est installée  

je pense que je vais créer un rapport de bug

Quelle version de linux ? Une fois booté, vérifie ta version (uname -r) et renseigne-la ici.
On dirait que ton noyau ne sait pas gérer les cgroups. Tu es en stock ?

c'est le noyau 4.0.5, pas de testing chez moi, que des paquets venant des dépôts stables,

j'ai crée un rapport de bug mais le modérateur a fermé mon rapport de bug en disant que c'est normal :

https://bugs.archlinux.org/task/45434

mais comme sa réponse ne me satisfait pas j'ai crée un autre rapport de bug concernant la différence de comportement entre la version i686 du paquet systemd et la version x86_64, sur la version 64 bits il n'y a pas ce message d'erreur et encore plus étonnant la version affichée de systemd est "219" au lieu de "221" au boot,

https://bugs.archlinux.org/task/45435

essaie de faire le test chez toi en mettant à jour ta distribution, reboot et regarde si la version affichée de systemd au boot est bien la 221,  tu verras ça sur une installation 64 bits, une erreur de numéro de version :

comme miroir j'utilise " http://archlinux.polymorf.fr/$repo/os/$arch", je me demande si c'est pas ce miroir qui bogue au niveau de la version du paquet systemd ?
 

Si les paquets sont les mêmes sur les différents miroirs...
 
Pour systemd qui n'affiche pas le bon numéro de version, ça l'avait déjà fait avec la 216 (qui continuait à afficher 215).

finalement il y a une explication logique concernant le numéro de version de systemd qui ne correspond pas à la version installée :

il faut régénérer l'initrd ou bien réinstaller le noyau linux qui régénérera l'initrd,

car le paquet systemd quand il s'installe ne régénère pas l'initrd ( l'espèce de fichier dans /boot qui correspond à un système minimal linux ), ce fichier initrd aura le numéro de version de systemd correspondant au moment où il a été généré quand le paquet du noyau linux s'est installé, d'où le problème de numéro de version si dans votre mise à jour ( le pacman -Syu  ) une mise à jour de systemd apparait sans qu'il soit suivi d'une mise à jour du noyau linux, l'initrd ne sera alors pas régénéré,

donc pour corriger le problème il suffit de taper cette commande en root :

ou réinstaller votre noyau linux,

pour éviter ce problème il faudrait que la mise à jour de systemd soit faite en même temps que le noyau linux, ou bien que dans le paquet systemd un script lance automatiquement une regénération de l'initrd

en plus il y avait déjà un rapport de bug pour ce problème :

https://bugs.archlinux.org/task/44938

En même temps c'est pas vraiment conseillé de mettre systemd dans l'initramfs...

j'ai rien modifié à ce niveau, c'est la configuration par défaut d'archlinux il me semble,

udev et systemd semblent être intimement liés non ?

Nope, à ma connaissance c'est pas par défaut et pas vraiment recommandé.

dans mon mkinitcpio.conf j'ai que ces lignes d'activées :

le "udev" a sans doute un numéro de version qui suit celui de systemd, quand on lit "starting version 221" ça fait sans doute référence à udev

My bad.
A cause de ce changement de versionnement d'udev, je pensais que c'était systemd qui s'initialisait.
On peut remplacer le hook udev par systemd, et ça c'est pas recommandé.
 
Du coup tout le monde est affecté en fait, c'est sale

J'ai acheté un SSD pour le portable de ma copine qui commence à dater un peu (le portable, pas ma meuf ). Et qui dit nouveau DD dit réinstallation ; elle tourne actuellement sur Chakra, vous pensez que je peux lui foutre Arch, si je m'occupe de la maintenance après ? Ou vaut-il mieux lui mettre un truc un peu plus Michu-compliant (mais quand même basé sur Arch), style Manjaro / KaOs / Chakra...

Sachant qu'elle tourne sur KDE 4 et que j'aimerais bien lui mettre Plasma 5.

Question : elle a quel niveau en informatique ? Parce qu'Arch Linux, c'est quand même du "yaourt -Syua" tous les matins (ou, au pire, une fois par semaine minimum) dans le Terminal (il y a certainement moyen d'automatiser ça en tâche de fond mais là, c'est moi qui suis encore trop novice pour le faire).
 
En gros, sur le spectre Debian (maintenance minimale pendant 5 ans) ◄► Arch Linux (MAJ quotidiennes), elle se situe où et que peut-elle accepter avant de trouver que tu lui monopolises trop sa machine ?

Non mais arch, j'ai ça chez mes parents, je fais un pacman -Syu tous les deux mois, ya aucun problème.

Tu es surtout trop novice pour te rendre compte que c'est une très mauvaise idée

Non mais actuellement elle est sur Chakra, elle ne s'occupe pas des mises à jour, c'est moi qui fait un "sudo pacman -Syu" de temps en temps. Ça devrait pas changer grand-chose.