Reprise du message précédent :
assez d'accord, l'install n'est pas simple mais le nouvel iso aide grandement

J'avais un boot sur 2 qui fonctionnait.  Les boots suivants n'ont jamais abouti.

Pour avoir été plus de 3 ans à utiliser une archlinux, je peux dire que je connais très bien ses fondements et rouages

(j'entends par là utilisation quotidienne : mises à jour via pacman, configurer les fichiers de config, créer des paquetages)

Pour l'installation, Je trouve que c'est plus technique que linux lui-même car il faut connaitre son matériel.  ça n'aide pas lorsqu'on a une carte mère + proc de moins de 6 mois d'âge.

Commencez donc par installer une Gentoo depuis un stage 1 (si ça existe encore?), après ça vous trouverez l'installeur ArchLinux au top

 
Ne soyons pas pervers, l'install de arch équivaut à un stage 3  

avec Arch en plus le kernel est déjà précompilé, trop facile

Boot de l'ISO ou d'arch après l'installation?
 
Enfin c'est plus un problème matériel qui dépend plus du noyau proposé par Arch qu'un problème avec la nouvelle installation, à mon avis

Montez vous une LFS et maintenez la pendant 1 ans sans break et vous trouverez que n'importe quelle distro est simple (gentoo comprise)

 
C'est pas vraiment dur, y'a plein de doc pour lfs, pour gentoo, etc   Ce qui change, c'est surtout le temps nécessaire pour maintenir un système.  
Et comme je fais déjà de l'admin sys linux toute la journée au taff  

C'est bien le sens de ma réponse : le soucis, c'est la maintenance sans break (et j'ai bien dit que gentoo est une distro, source, mais distro quand même )

Et la «nouvelle» du jour : http://mailman.archlinux.org/piper [...] 23389.html

 
Vivement que ça se fasse. Je suis assez surpris de voir autant de résistance au changement sur la ml arch-general.

perso je me suis desabbo de la general tellement c etait risible !

 
Gros avantage de systemd, je vais m'améliorer en C  

Pourquoi ?

J'aurai sûrement l'occasion de lire les sources

effectivement, vu sous cette angle

Si j'ai bien suivi, Systemd c'est désormais inévitable à terme sous Arch ? Si oui, est-il aujourd'hui suffisamment fiabilisé sous Arch pour réaliser la migration dès à présent ?

Absolument!
Je tourne dessus sur une de mes 2 machines depuis des mois et cela sans soucis.
 
Les fichiers services sont plus facile a changer que les bash precedants, a part cela, je ne sais pas trop quelles ont ete les differences pour moi...

oui systemd est le standard pour fedora depuis 3 versions, ca roule

Je suis donc en train de migrer vers systemd.

Actuellement, j'ai créé les fichiers requis sous /etc, et activé les services de base pour pouvoir me servir de la machine, à savoir NetworkManager et KDM. En revanche, je ne comprends pas comment activer certains services que je démarrais auparavant via rc.conf. Pour me rendre compte de ce qui tourne ou pas avec systemd, j'ai renommé rc.conf en rc.conf.bak.
Résultat : Apache, MySQL, Cups, et d'autres ne fonctionnent plus.

Je tente systemctl enable http-daemon.target, systemd me répond "The unit files have no [Install] section. They are not meant to be enabled using systemctl.". Comment puis-je donc activer le lancement (par exemple) d'Apache lors du boot ?

EDIT : trouvé pour Apache, MySQL et cpufreq. Je bute sur CUPS encore.

T'as essayé cups.service ou cupsd.service ? (systemctl enable ...)

Oui, justement, j'ai vu dans le wiki une page de correspondance entre services initscripts et systemd, mais je n'ai aucun des deux services. J'ai peur que ça vienne de la version de Cups que j'utilise (cups-usblp) nécessaire pour mon imprimante (une Samsung 3180CLX de tête).

Ah oui. Chez moi ces deux services appartiennent au package cups.
 
Il y a un commentaire sur AUR qui laisse à penser que ton imprimante pourrait fonctionner avec le nouveau cups.
 
Sinon il va te falloir toucher au PKGBUILD: un mélange entre celui de cups and celui de cups-usblp.

Es-tu bien sûr d'avoir besoin de cups-usblp? Il me semble que maintenant on peut charger le module usblp sans que ça pose problème avec cups (si c'est le problème)
 
PS : avec le paquet samsung-unified-driver (dispo sur AUR) et cups j'ai pas de problème particulier avec ma Samsung ML-1865 (reconnue et configurée des le branchement sur le port USB )  
De plus :

 
 
C'était nécessaire lorsque j'ai eu l'imprimante, ce n'est effectivement peut être plus le cas aujourd'hui. Je vais essayer de la réinstaller avec le CUPS normal et voir si ça permet de lancer correctement CUPS par systemd.

Ben moi je vais attendre qu'il y ait un tuto clair sur ce qu'est systemd, pourquoi switcher dessus et comment le faire sans tout péter  

https://wiki.archlinux.org/index.php/Systemd

EDIT : ou http://wiki.archlinux.fr/Systemd

Dites les amis,
 
je suis tombe sur unRaid et SnapRaid par hasard et ca a l'air interessant.
Y'a-t-il quelqu'un qui utilise cela sur Arch Linux et/ou a des commentaires la-dessus?
 
Merci!

 
Perso, j'ai été un peu vite tête baissée, d'où mon premier post où je ne trouvais pas comment relancer Apache/MySQL ou d'autres services. Tout se trouve dans le Wiki.
 
En revanche, je pense que certains paquets ne sont pas encore à jour et mériteraient de rapidement se voir rendu compatible avec Systemd notamment en livrant le .service nécessaire. Pour ma part, je sais lire un Wiki (quand je prend le temps de le faire correctement), je pratique un peu le système et je n'ai pas peur de la CLI (ce qui va avec Arch sous laquelle je tourne maintenant depuis un peu plus de trois ans), donc ça me va.
 
En revanche, j'avais pris pour habitude d'installer Arch sur les machines des personnes dont j'entretiens la machine et que j'ai réussi à convaincre d'essayer Linux (soit trois personnes aujourd'hui, plus une que je vois rarement et que j'ai mis sous Ubuntu par facilité). Je connais cette distribution, et jusqu'à présent, en dehors d'une ou deux MAJ où il fallait taper deux lignes de commandes sans risque, Arch s'entretenait très bien. Avec les mises à jour de ces derniers temps (/lib, GRUB sous peu, Systemd à venir) pas toujours aisées, avec des risques potentiels de blocage du système et manipulations assez lourdes, je pense qu'à l'avenir je resterai sous Arch personnellement mais j'installerai Debian ou au pire Ubuntu sur ces machines.
 
Je reste attaché à Arch parce que cette distribution avec ses avantages correspond à mon utilisation (un peu orienté power user, maitrise du système, toujours à jour avec le principe rolling, etc). Mais si les MAJ pénibles doivent avoir lieu tous les 15 jours, ça ne va plus être possible pour les machines de mes proches.
 
Je ne dis pas que c'est la distrib qui est en train de se perdre, et on peut considérer que c'est moi qui a fait une erreur en installant une distrib de ce type chez des néophytes dont j'entretiens la machine. Reste que ça ne posait pas de problème jusqu'à peu car les MAJ prenaient un maximum en charge les modifications profondes impliquées par un changement de direction impliqué par une mise à jour de paquet. Là, j'ai l'impression que c'est moins automatisé quand bien même cela aurait été possible (le cas de /lib qui devient un symlink le montre) et autant ça reste viable dans le cas d'une machine isolée, autant ça pose problème avec un parc de machines plus large, même s'il ne représe que trois machines.
 
J'ai l'impression de me trouver à mi chemin entre les inconditionnels d'Arch qui resteront sur la distrib quoi qu'il arrive ou presque, et ceux qui commencent à être sérieusement inquiets des derniers choix réalisés pour la distribution. Je n'incrimine en tout cas personne et reste convaincu que ces choix sont justifiés, même si certains pourraient à mon sens être mieux accompagnés techniquement parlant.

c'est parce que arch fait en rolling des modifications qui sont faites sur des versions majeur sous fedora, avec les memes risques de mise à jour si on ne réinstalle pas.
 
Debian ne passera pas à systemd, donc ubuntu vraisemblablement pas non plus. (ce qui est une erreur à mon avis)
 
Je crois qu'ils ne sont pas non plus qu'ils ont /lib en symlink
 
donc faut voir aussi techniquement les conséquences.
Je pense que si on ne veut plus de arch, la seconde distro la plus simple à proposer des solutions techniques similaires, c'est fedora

 
   mais j'avais déjà vu. Mais je ne vois pas pourquoi ça change, ni s'il y a une dead line, ce qu'on risque à rester comme actuellement et ce qu'on risque à passer sous systemd. Mon système est stable et je n'ai pas la motivation de risquer de le casser en ce moment (mais ça viendra   ).
 

 
Ça ne me dérange pas de mettre les mains dedans, au contraire j'aime arch pour ça, ça oblige à comprendre comment ça fonctionne. Mais je suis un peu perdu sur le pourquoi des changements et les conséquences.
De plus, pour des changements comme ça qui ont l'air profonds, je suis plus tenté par une réinstall histoire d'être sur d'avoir un système propre que par un bidouillage qui fait cohabiter des trucs et qui va me laisser un paquet de déchets derrière (ou pas). D'ailleurs, il y a une commande pour faire le ménage ? (virer les paquets, les fichiers de config, etc. qui ne servent à rien)

Je sais tout ça, c'est juste une réflexion que je me suis faite, à savoir Arch à titre perso c'est nickel, mais pour un parc de machines, aussi petit soit-il et surtout quand on le fait sur son temps libre et bénévolement, si ça doit se passer comme ça ça va devenir tendu. Ca reste ma distrib préférée pour plusieurs raisons, mais voila quoi.
 
Quand à passer sur Fedora, à moins qu'ils se décident à remplacer leur gestionnaire de paquets lent à mourir, c'est hors de question.

 
J'ai décidé de migrer sous Systemd pour gagner du temps et anticiper la migration, histoire de pas me retrouver à faire ça dans l'urgence lorsque que la bascule deviendra inévitable. Rien n'y oblige pour le moment. En revanche, Linux permet la souplesse de réaliser ce genre de manipulation sans réinstaller, je trouve dommage, surtout lorsqu'on s'oriente sur une distrib comme Arch, de profiter d'une réinstallation pour réaliser ce genre de manipulation.
 
Sinon, pour checker les paquets qui ne sont plus requis par un autre et qui n'ont pas été installés volontairement (dépendance d'un autre paquet plus sur le système ou qui ne l'a plus en dépendance), tu as pacman -Qdt, mais attention, ce n'est pas parce que aucun paquet ne dépend d'eux qu'ils ne sont pas nécessaires, donc il faut savoir ce qu'on fait lorsqu'on les vire.

Pour quelqu'un qui ne s'y connait pas je ne suis pas convaincu qu'Arch soit une bonne idee, meme si tu maintiens la machine toi-meme.
 
Si tu appelles Dell ou une compagnie de ce genre, ils connaissent Ubuntu (au moins de nom), Arch probablement pas... C'est probablement mieux pour un neophyte d'utiliser quelque chose que les autres connaissent.
Possiblement pareil pour Fedora ou Suse.

• http://fr.wikipedia.org/wiki/Systemd
• Pas de deadline à ma connaissance
• De plus pouvoir faire les mises à jour du système
• Peu de risque à mon avis, cette mise à jour sera testée et retestée

J4ai l'erreur de /lib déjà présent dans le système lors d'une maj :

J'ai tenté de suivre le wiki mais ça n'a pas marché.
Que dois-je faire?

J'ai tout ça dans /lib :

edit : j'ai déplacé le dossier firmware, mais même erreur.

Le soucis, c'est un fichier qui n'appartient à aucun paquet dans /lib
 
Donc hop:
 
for i in `ls -c1 /lib` ; do pacman -Qo $i ; done

 
J'avais déjà lu, mais merci car j'ai suivi des liens et compris d'autres trucs    
 
Je ferai la maj après les vacances histoire de pas me retrouver en rade de pc pendant.

 
De même    
En revanche, j'ai des paquets à adapter sur AUR et si quelqu'un a des infos sur la façon d'adapter les anciens scripts d'init (on continue à utiliser /etc/rc.d ?) avec les fichiers unit, ça m'intéresse fortement !

C'est sensé faire quoi?
Donner l'appartenance des fichiers dans /lib à un paquet?
Tous les fichiers présents dans mon lib appartiennent à glibc 2.16.0-1

Tu as bien mis à jour ton système sans mettre à jour glibc? Y compris les paquets issus de AUR?
À mon avis, tu aurais pas dû déplacer /lib/firmware à moins qu'il contenait aucun fichier appartenant à un paquet...