Voici la cinquante-neuvième version du tutoriel pour installer une Archlinux, que ce soit avec une machine virtuelle, utilisant un Bios ou un circuit UEFI. Cette version rend obsolète celle de septembre 2018.
Note : des versions plus dynamiques sont disponibles sur mes espaces github et framagit.
Pour les captures d’écran, je suis parti d’une image ISO intermédiaire créée avec l’outil Archiso. Au moment où j’envoie l’article en ligne, le 1er octobre vers 10 h 35 du matin, l’ISO d’octobre 2018 n’est pas encore disponible.
Si vous avez besoin d’une image ISO en 32 bits, le projet archlinux32 vous en proposera une.
Côté environnements : Gnome 3.30.1, Plasma 5.13.x, Xfce 4.12.0 et Mate-Desktop 1.20.3 en gtk3, Cinnamon 3.8.9 et Deepin 15.7. Sans oublier le rajout des microcodes pour AMD et Intel.
NB : si vous voulez faire une installation avec l’UEFI, il faut utiliser cgdisk, gfdisk ou gparted, et créer un partitionnement GPT. Sinon, ça plantera !
Ce n’est pas un tutoriel à suivre au pied de la lettre, mais une base pour se dégrossir. Le fichier au format zip contient :
- La version odt
- La version pdf
- La version ePub
- La version mobi (pour Kindle)
Le guide en question est sous licence CC-BY-SA 4.0 à compter du mois de mai 2016.
Bonne lecture et n’hésitez pas à me faire des retours en cas de coquilles !
C’est exactement ce que je cherchais. Merci 🙂
Et l’idée de convertir cela pour des liseuses électronique est une superbe idée que je n’ai pas vu ailleurs.
Bonjour Fred,
Pourrais tu faire une vidéo sur comment gérer les fichiers .pacnew et autre ?
Merci.
Je vais me pencher sur le problème, mais je ne promets rien.
Merci Fred pour les tutos très appréciés de tous.
J’ai réalisé ma première installation en UEFI d’Archlinux (Mate) début septembre en double boot avec W10 avec 3 disques.
– W10 sur SSD
– Archlinux sur HDD
– Un disque commun au deux OS HDD en NTFS pour les données communes (photos, musique…..)
Quelques remarques pour aider les lecteurs :
– Démarrage sur le Grub j’ai modifié le timer à 30s pour avoir le temps de choisir W10, au lieu de Arch.
– Horloges, soit on laisse tel quel, le décalage UTC, local, est corrigé automatiquement par les deux OS en moins de 4 min avec le ntp. Soit avec l’aide du wiki Archlinux on modifie la base de registre pour passer W10 en UTC. Attention avec une version 64 bits il faut un Qword et non un Dword comme indiqué, j’ai supprimé le ntp sur W10. j’ai laissé celui d’Archlinux qui s’occupe de la mise à la bonne heure.
– Accès à un HDD NTFS, ntfs-3g ne suffit pas, si le démarrage rapide de W10 est activé (par défaut), l’UEFI bloque l’écriture sur les disques utilisés par Windows. Il faut donc supprimer l’option démarrage rapide du disque système (inutile en fait sur SSD) et du disque commun. On peut alors écrire, mais les données écrites ne seront pas visibles sous W10, car il gère les droits NTFS (pas Linux). Il faut rendre le disque commun accessible à tous, en modifiant les droits de ce disque. Après cela, tout fonctionne.
Quelques remarques :
Le plus simple est encore de passer Arch Linux en localtime, et comme ça, même sans devoir désactiver le NTP sous Windows, il n’y a plus de problème de décalage d’horloge entre lui et Linux. Pour moi, c’est la méthode la plus propre (bien plus que la tienne, en tout cas, même si elle fonctionne aussi).
Pour les disques NTFS, rien à redire sur ton paragraphe. Mais si tu as installé Arch sur une partition ext, pense à installer le petit logiciel gratuit Ext2fsd sous Windows, pour accéder aux partitions ext depuis ce dernier. Évidemment, c’est moins nécessaire si tu as déplacé les dossiers utilisateurs sur un autre disque formaté en NTFS… Mais ça reste un outil à garder dans sa trousse.
J’avais déjà passer, une fois Archlinux en heure locale, mais il génère des warning, je pense que certaines taches fonctionnent mieux en UTC? Et le NTP de Windows se fiche de la base de Registres ! il faut donc le désactiver. J’attends l’heure d’hiver pour voir !
Merci pour l’info (Ext2fsd), mais dans mon cas, je n’ai pas besoin d’accéder aux partitions Ext4 du disque Linux.
Wut ? T’es sûr que c’est à cause de ça ? Parce que j’ai jamais observé ça de mon côté.
Merci Fred =)
Je me suis lancé sur cette distro grâce à ce guide il y a quelques mois et j’en suis plus que satisfait.
De rien. N’oublie pas cependant que c’est une distribution exigeante. Qu’il faut faire gaffe et avoir du temps libre pour déplanter un système lors de mises à jour chatouilleuses.
C’est assez rare, mais ça arrive !
On a rien sans rien comme on dit 🙂
J’en ai déjà rencontré quelques uns mais rien d’insolvable. J’ai des ISOs de secours, des clés USB, je ne débute pas non plus avec Linux et s’il faut arch-rooter, on arch-rootera =P
Bon week-end !
Surtout que parfois, c’est pas tellement la faute de la mise à jour, mais du matériel qui ne suit pas (ah, ce redémarrage sur un écran noir en mai, parce que la GT120 ne supportait pas encore X.org 1.20, et qu’il a fallu attendre un moment pour que NVIDIA sorte finalement une version compatible de ses pilotes 340xx…). Là, c’est plus embêtant, parce que la MAJ elle-même se fait sans souci, aucun message d’erreur, mais au redémarrage : surprise, ça marche plus sur telle configuration, alors que RAS sur d’autres. T’es content, de retrouver ton ordi HS, alors que rien ne laissait douter que ça se produirait…
Ça a eu l’avantage de me faire découvrir en vitesse (15 mn, avant même de prendre mon petit-déjeuner, donc encore seulement à moitié opérationnel) le fonctionnement de links et comment basculer rapidement du pilote NVIDIA au pilote Nouveau depuis une session en TTY pur, en attendant de rétrograder sur X.org 1.19 par la suite, et en bloquant ses mises à jour d’ici la résolution du problème (qui a eu lieu plusieurs semaines après).
Autre exemple plus récent : les premiers noyaux 4.19 qui foiraient le démarrage sur des Core 2 Duo (mais pas les Core 2 Quad de la même époque, ni les CPU des générations suivantes), stoppant net ce dernier juste après le démarrage de systemd, et avant même le montage de la moindre partition. Heureusement que le mode fallback existait et permettait un démarrage correct, pour aller récupérer le noyau 4.14 LTS en secours. Un bug remonté par les membres du forum d’Arch (seule distro touchée, bizarrement) et corrigé en upstream par les devs du noyau.