Reprise du message précédent :
bon installe faite mais je me fais jeter au reboot, y a une cagade dans un coin
 
je pense qu'il a gardé la clé usb comme boot dans le fstab

Je doute que fstab soit impliqué dans le boot de bas niveau. Regarde plutôt dans les fichiers de conf de ton bootloader, suivant lequel tu utilises.

dans le grub alors? merci de la piste

Merci d'avoir répondu
 
 
 
C'est ce que je pensais, sauf que mon /boot n'était composé que d'un dossier grub initialement, quand j'ai fais cette commande, il a crée 2 fichiers dans le /boot ( normal ) en plus. Je ne suis même pas sur qu'ils sont utilisés par mon grub.
 
 
 
Ouais surtout que lors du make, j'ai une erreur de compilation, et le dossier /tmp s'efface à chaque extinction ( normal ) mais obligé de tout retélécharger à chaque fois.
 

Pas seulement HD, mais en effet!  
Et maintenant, grace au 3.11 on a aussi DPM sur radeon (non actif par defaut).

arch installé!! j'ai un peu bataillé avec grub mais bon ^^
 
ces UUID quand t'as pas l'habitude ^^

Utilise des labels, c'est tellement plus simple

J'ai jamais utilisé les labels, mais avant je ne mettais dans le fstab que /dev/sdx, et c'est une mauvaise idée. Un jour, j'ai installé arch sur un PC avec deux disques, et une fois sur deux, suivant l'ordre de détection par le bios, les sda et sdb étaient échangés. Donc une fois sur deux ça bootait pas (et j'ai pas compris tout de suite le problème...). Avec l'uuid, plus de problème.
 
Les labels offrent la même rebostesse que l'uuid ?

Je crois bien.
Il y a moins de chance que le label soit unique qu'un uuid je pense mais bon...

Surtout que l’UUID se calcule, alors que le label, tu le choisis.

Ok, c'est bien ce que j'avais cru comprendre, du coup j'en prends bonne note.

Me semble que l'uuid peut être affecté (oui bon tu le choisis pas vraiment mais ça peut servir en cas de crash de disque ou clone d'os ou autre).
Perso j'utilise ça depuis un moment et je trouve pas ça très compliqué, pas super lisible mais certes mais pas compliqué.

Je me sers des UUID parce que je me rappelle jamais la commande pour affecter un label à une partition, alors que l'UUID est généré automatiquement. C'est une raison qui vaut ce qu'elle vaut, mais bon

Perso, j’y vais à la feignasse et j’utilise Gparted pour ce faire.

C'est la meilleure méthode.

Bordel, j'ai refait une install, y'avait longtemps. Y'a plus de script d'install. Ça me dérange pas, j'aime bien "closer to the metal", mais la courbe d'entrée pour les nouveaux

qu'entends-tu par l'expression "closer to the metal" ?
 
sinon c'est un moindre mal le fait qu'il n'y ait plus d'install semi-auto d'arch linux, ça forcera l'utilisateur à prendre conscience qu'il n'est pas sur une distribution user friendly de type ubuntu et ça l'incitera à lire le wiki d'arch linux, de bonnes habitudes pour plus tard

C'est surtout qu'il n'y a pas de dev / mainteneur volontaire...

Moins d'abstraction, plus proche du hardware.

Ba le snoobs ont le wiki, je trouve ça plutôt bien comme challenge d'entrée, une sorte de préselection    
 
Sinon le bare metal en général je crois qu'on en parle plutôt pour les softs qui tournent très très bas niveau sans noyau derrière, comme les noyaux ou les bootloaders par exemple.

 
Ouaip, cela dit si la doc était aussi bien que la doc de gentoo, ce serait encore mieux pour les noobs    

La doc de la Arch est loin d'être nulle pour l'installation, faut pas déconner.

 
La doc est très bien, mais la doc de gentoo est encore un cran au dessus pour moi.
Sur gentoo il y a une doc officielle, versionnée et traduite dans beaucoup de langues et un wiki communautaire.
Sur arch, il n'y a que les wiki, avec leurs défauts (vieilles traductions, contenu outdated, etc). Après dans le wiki, toute la doc principale est bonne, oui

En fait la doc d'arch est très inégale selon les contenus.
 
Le guide d'installation est rigoureux, c'est pour les autres aspects que c'est plus fait " a la volée" mais c'est aussi parce que les mailing list et forums sont plus actifs sur arch !

il faut penser aussi à lire la version anglaise de la doc, souvent elle est plus complète que la version française grâce à un plus grand nombre de contributeurs, c'est un peu comme la version anglaise de wikipédia

Salut,
Je vais changer de carte mère (autre modèle), sachant que mon fstab est rempli avec les UUID, est-ce que je risque d'avoir des surprises avec mon install ? Est-ce que je dois faire un truc particulier ?

Nope ça devrait booter direct, par contre attention aux drivers inclus dans ton initram.
Et si c'était de l'UEFI faudra re-renseigner l'ESP

Faudra juste démarrer en fallback et relancer mkinitcpio une fois la nouvelle carte mère installée    
Après je suis pas spécialiste des problématiques liées au UEFI  

 
 
Actuellement ma CM est UEFI et la prochaine le sera aussi, mais je boot avec syslinux (qui ne supporte pas l'UEFI). Je ne sais pas trop pourquoi ça fonctionne et ce qu'installer GRUB, qui supporte l'UEFI, m'apporterais.

faut pas trop se prendre la tête concernant l'UEFI, l'interêt est très mince pour l'utilisateur lambda, tu peux garder tes anciennes habitudes

Ce sujet qui revient à chaque page  

 
Merci

Un jour, faudra bien se prendre la tête avec l'UEFI, quand il n'y aura plus de mode d'émulation BIOS ... Ce qui devrait arriver d'ici a milieu 2014 pour les premières cartes mères vendues sans émulation BIOS
Mon conseil : apprenez a utiliser rEFInd et a faire des kernels avec initram intégrés, ça vous évitera beaucoup de soucis quand faudra "shimer" vos kernels.
Parce que quand il faudra passer au signatures ça vous fait déjà 1 pkkey pour rEFInd et une 1pkkey pour shim (non réductible) auquel on ajoute 1 oskey pour kernel + init (si intégré) ou bien 1 pkkey + 1 oskey pour init et 1 oskey pour kernel (soit 1 key de plus a intégrer a l'UEFI + 2 key a intégrer dans shim, c'est relou ^^)
 
Bref, autant s'habituer tout de suite et comprenne qui pourra mon laïus sur les clés ! xD

D'ailleurs à ce propos, noter le (plus si) récent e-mail de Greg KH sur la ml arch-dev
Il a également écrit un blog post là-dessus.
 
Je m'y mettrai... un jour

 
tu as un lien qui indique la fin de la compatibilité mbr dès 2014 ?
 

Attention si vous utilisez le fichier /etc/sysctl.conf : http://archlinux.fr/news/depreciat [...] ysctl-conf

pour ceux qui utilisent KDE 4.11.1 avez-vous remarqué ce problème depuis la dernière mise à jour de systemd sortie aujourd'hui ? ( systemd 207-3 ) :
 
https://bugs.archlinux.org/task/369 [...] &sort=desc
 
concretement si j'utilise kdesu pour lancer un programme en mode root ( comme kdesu kwrite ) je remarque ensuite qu'à la fermeture d'archlinux il y a un délai supplémentaire de 10 secondes à cause du processus kdesud ( systemd est obligé de le fermer brutalement à l'aide d'un SIGKILL )
 
est-ce que vous avez le même problème après avoir fait la mise à jour de systemd ?
 
 

apparemment mon problème provient d'un bug avec la dernière version de systemd ( 207-3), car en downgradant la version du paquet je n'ai plus le problème ( version 203 ),

une version 207 qui provoque au passage d'autres bugs très divers pouvant aller d'un simple problème de type "SIGKILL" ( mauvais pilotage des processus ) jusqu'à un problème plus grave de type "kernel panic" d'après les rapports de bug, tout dépend de la configuration

Bizarre j'ai rien remarqué de tel

ça me fait penser aux bugs KDE de la version 4.10, t'as eu des gens qui n'ont pas eu de problèmes, d'autres qui ont eu des problèmes mais à condition d'être en i686, ou encore les 2 architectures qui ont eu les problèmes mais avec des effets et des résolutions de bug très différentes  

vu que systemd est quelque chose de très complexe c'est peut-être normal que tu ne sois pas touché, toutes les conditions du bug ne sont peut-être pas réunies chez toi,

c'est là que ma machine virtuelle archlinux i686 m'est très utile, très souvent j'arrive à reproduire les mêmes problèmes par rapport à mon portable pentium4, je sais alors si c'est un vrai bug ou quelque chose d'isolé à mon portable,

il me manque juste une machine virtuelle x64

 
Juste pour confirmation, il faut lancer la commande suivante ?