Des geekeries, de la MAO, de tout et de rien…
Je suis
Charlie

SteamOS

Icône auteur nah, Icône canondrier 22 décembre 2013, Icône commentaire
Mots clés Icône catégorie geekeries, GNU/Linux, Jeux, Steam, SteamOS, Radeon, classé dans Icône catégorie Asrall, Geekeries, Linux, Jeux
Logo SteamOS

Tiens, comme c'est dimanche, si je testais SteamOS ?

Edit : Le tutoriel détaillé pour installer SteamOS en 2015 est présent ici : http://blog.chibi-nah.fr/tuto-installation-steamos



SteamOS ?

Il s'agit d'une distribution dérivée de Debian, créée par Valve Software (Half-Life, Steam, Portal, L4D…), et destinée à fonctionner sur les machines appelées "SteamBox". À noter, n'importe qui peut monter sa propre "SteamBox".

Installation.

J'avais une partition de 9 Go inutilisée, et une distrib debian sid sous la main.
Ne souhaitant pas suivre les instructions "officielles", car trop pénibles (nécessite un UEFI, un disque de 500 Go, une clé usb externe, effacera la totalité du disque dur, pas de dual boot, support des cartes nvidia uniquement…[1], faisons ça à la main, de manière artisanale.
Donc, utilisation de debootstrap, chroot, compilation d'un kernel 3.12.6 (j'en ai profité pour mettre à jour mon kernel sous sid dans la foulée), et création des paquets .deb.
Installation des paquets, configuration de grub sur la partition sda7, mise à jour de mon grub "principal", puis reboot.

Et là, c'est le drame.

Kernel panic ! Unable to mount root.

Bon, reboot sous sid, et regardons ce qui cloche.

Premier point, je compile mes noyaux sans initrd. Ce truc là sert à rien quand on compile ses propres noyaux, vu que les pilotes requis, genre, ext4, sont compilés en dur et non en tant que module (où est l'intérêt de les mettre en module ? faut monter une image intermédiaire qui contient le module pour monter la partition root pour charger les modules… bref).

Second point, cette andouille de GRUB, malgré l'option ROOT-UUID = false, a réussi à mettre un root=uuid=<UUID de la partition>. Pour que l'UUID soit reconnu, il faut charger l'initrd, qui va alors chercher quelle partition correspond à l'UUID passé en paramètre, puis va corriger la partition root. Encore un truc tordu écrit par je ne sais qui, et dont l'utilité est discutable. Re bref.

Je remet à jour grub, via update-grub (sachant qu'au départ, ce qui m'a fait basculer de lilo à grub, c'est la nécessité de mettre à jour lilo à chaque modif et que grub, suffisait d'enregistrer le fichier. Désormais, on change un paramètre de grub, faut lancer une commande qui va générer un fichier de config totalement incompréhensible. Cf un ancien article).

Cette fois, je vérifie que le grub.cfg ne contient pas d'UUID.

C'est bon ? On reboot ?

Qui a dit : pas de multiboot ?

Un redémarrage plus tard, arrivée sur Debian Wheezy SteamOS, suivi de Login:.

Bien.

Tiens, définissons un mot de passe root, c'est toujours utile.

Les utilisateurs et les dépots valve ont été configurés lors de l'installation, reste à finir les 2-3 trucs qui reste, genre pulse-audio, drivers…

Démarrage de lightdm, et … plaf ! Écran noir.

Vive openSSH

Connexion en urgence via ssh (une excellente idée de l'installer avant toute chose, au cas où), kill de lightdm, et constatation des dégats. Lightdm n'a pas arrêté de faire "start-error-respawn-error-respawn-error-respawn", en boucle. Suffisamment de quoi générer 10 Mo de log en 30 secondes.

Démarrage de X via startx, et arrivée sur le bureau Gnome 3.4, en mode "classique" (ou failsafe).
Steam demandant glx, vérifions que déjà, je suis sur la radeon (ah, tiens ? j'ai laissé DIGD au lieu de DDIS dans rc.local, corrigeons ça). Arrêt de gnome et X, basculons sur la radeon (sudo echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch), relançons X, et… toujours pas de glx (glxinfo : pas de DRI, pas de DRM, rien).

Bon, ajoutons debian wheezy en apt-pinning, puis mettons à jour les dépots.

Tant que j'y suis, ajoutons les paquets de base, genre htop, vim, mc, et de quoi configurer alsa.

Bizarre, j'ai bien le driver radeon libre dans les dépots steam, mon kernel est le même que sur sid, et j'ai pas de problèmes pour faire tourner UT2004 dessus. Doit manquer un paquet ou deux. Installons alors mesa, et tout ce qui concerne DRI-DRM et radeon.
Effectivement, il manquait quelques paquets.

La liste complète de tous les paquets installés. Certains ne sont pas disponible dans les dépots de valve ni de debian. Il s'agit des paquets liés au linux-*, spécifiques à ma machine.
À noter, j'ai commencé à faire le ménage dans les paquets, mais il reste des trucs à virer, genre, apache.

Ooooh, le beau troll gnome

Cette fois, gnome démarre en mode "normal", et me montre un beau bureau (/me tousse), en précisant bien que c'est la radeon qui tourne. glxinfo montre que DRI est bien actif, et également plein plein d'extensions GL*. Ça semble fonctionner.
Démarrons alors steam en mode "desktop". Ça marche.
Réactivons alors lightdm, un reboot et une mise à jour steam plus tard, voilà le mode "Big Picture". Entrons les informations de connexion, et explorons les menus.

Démarrage de SteamOS.
Animation du démarrage de Steam.
Steam, en mode Big Picture
Paramètres.
Et voilà, SteamOS avec une radeon. C'était pas si compliqué.
SteamOS avec le pilote radeon libre \o/

Quelques trucs vides ou encore en test, rien de grave. Quelques bugs bien pénibles, comme un crash de l'overlay steam (pas moyen d'en sortir, obligé de tuer steam via un tty), ou le redémarrage de steam quand on sort d'un jeu, et… pas de son.
C'est le moment de configurer correctement alsa, donc je commencer par jarter pulse-audio. Tant que la base ne marche pas, ça sert à rien de bidouiller la surcouche. Donc, dans /etc/default/pulse-audio, désactivons son démarrage auto, puis arrêt du service, /etc/init.d/pulse-audio stop.

Après une heure d'acharnement et de lecture de doc (mais pourquoi ça marche avec root mais pas avec les utilisateurs), je m'aperçois que c'est simplement le groupe "pulse" qu'il faut utiliser en plus d'audio ¬_¬'. Hop, usermod -aG pulse steam.

Reboot, et cette fois, j'ai le son. Je crois que j'ai oublié de réactiver pa. Je verrai ça plus tard.

Plus qu'à tester

Faisons quelques tests, en évitant d'appeler l'overlay en pleine partie, et ça marche. Musique, vidéo, interface "relativement" fluide (avec le driver radeon libre), et le petit plus : SteamOS fonctionnel avec une radeon, alors que ce n'est pas (encore) supporté.

Télécharger au format webm, 640x360, lisible par vlc

1 : http://store.steampowered.com/steamos/buildyourown

Commentaires

#1 Le 23 décembre 2013 à 10:12, bacardi55 a dit :

Super article, merci :)

#2 Le 23 décembre 2013 à 14:19, nah a dit :

@bacardi55 :
Pour l'installation, c'est "en gros" ce que j'ai fait. Après, vu que j'ai rédigé l'article après que tout fonctionnait, j'ai rédigé "de tête". N'hésite pas à me harceler sur IRC (quand je suis en ligne) si tu as besoin d'un coup de main.

#3 Le 27 décembre 2013 à 05:40, Meriadoc a dit :

J'suis content de voir qu'il y a des personnes qui, comme moi, sont assez peu convaincues par la seconde version de GRUB, et ses "avantages" (surtout en termes de la facilite a ecrire un ficher de configuration) par rapport a la premiere du nom... Cependant, bien que plus lourd et plus difficile d'utilisation (je passe sur la documentation, toujours plus furtive qu'un B-2 Spirit), il en ajoute pas mal, des avantages; comme (entre autres) le support de scripts (avec instructions conditionelles et fonctions), le support des plateformes non X86, le support universel des UUIDs, et le chargement dynamique de modules.

D'ailleurs venons-en au chargement dynamique de modules... Bien qu'il soit parfois une bonne idee de compiler son propre noyau de facon statique et sans aucun module (et donc par la de supprimer la necessite de l'initrd), le passage a un systeme modulaire ne s'est pas fait sans raisons: il offre l'avantage de pouvoir supporter des materiels differents avec le meme noyau, et la meme configuration. Il offre aussi l'avantage de pouvoir mettre a jour certaines sous-parties sans avoir a devoir remettre a jour tout le noyau (avec les soucis que cela peut comporter). Et l'inverse est tout aussi vrai: il offre l'avantage de pouvoir mettre a jour le noyau sans devoir mettre a jour TOUS les modules.

Bien sur, la solution modulaire n'est pas ideale, car elle rajoute (plus ou moins) beaucoup d'overhead, mais a mon sens, ce n'est pas dans le noyau et dans le bootloader qu'elle est plus problematique: beaucoup de languages de programmation recents (i.e. ruby et cie) seraient a re-considerer avant meme de penser a changer un seul octet du software bas-niveau.

#4 Le 06 avril 2014 à 12:55, nah a dit :

@Meriadoc :
(Réponse un peu tardive, je le reconnais).

Pour l'UUID, cela n'a rien à voir avec GRUB2, GRUB et LILO le reconnaissaient. l'UUID est passé comme paramètre au noyau, et c'est au script dans l'init.rd qui va monter la partition / après avoir fait la correspondance uuid->partition.

Franchement, mis à part sur un serveur avec des disques durs échangeables à chaud, et n'utilisant pas de RAID matériel ni LVM (les fous), et ne définissant pas de disque prioritaire à booter (re : au fou), et collant GRUB sur le 4e disque, le tout en s'amusant à déplacer les disques tous les jours, alors, là, je suis d'accord, le montage de / par UUID est utile.

C'est comme la gestion des sièges (ou multi-seat, 2 écrans, 2 claviers/souris, 2 utilisateurs sur un PC, on a pas attendu systemd et son écosystème pour mettre ça en place, même si j'ai jamais vu ça en pratique, encore moins sur un laptop. Ce que j'ai vu et qui s'en approche le plus, c'est le schéma classique mainframe -> terminaux X ou RDesktop stupides).

Après, je n'ai jamais dit que je compilais tout en statique. Tout ce qui est branchable à chaud est compilé comme module. Ce que je colle en statique, c'est tout ce qui permet un boot fonctionel (donc, système de fichiers, contrôleurs HID, etc)… (très drôle d'ailleurs quand l'initrd se vautre et donne la main alors qu'il n'a pas chargé les modules pour le clavier usb, redémarrage barbare requis :D).

Enfin, je n'ai pas compris la possibilité de mettre à jour le noyau sans mettre à jour les modules… quand on met à jour le noyau, on met à jour les modules en même temps, c'est ce que fait (entres autres) virtualbox, au boot (ou à l'installation d'un nouveau noyau), ou DKMS.
Bon courage pour utiliser un noyau 3.13.8 avec des modules du 3.13.6 (kernel panic powered).

Pour l'overhead, suffit de regarder que maintenant, la moitié des logiciels libres pour des trucs relativement lourds sont écrits en python ou ruby. D'accord, c'est beaucoup plus facile à écrire que du C/C++, mais quand je vois qu'un clavier virtuel sous Linux (genre, OnBoard ?) bouffe plus de 30 Mio de ram sur un téléphone (là où les ressources sont limitées), je me dit qu'il y a un problème (je ne parlerai pas d'Android, ce système étant un troll à lui tout seul).