Reprise du message précédent :
attention pour ceux qui utilisent KDE, à cause de l'hybridation "KDE4/applications KF5" j'ai découvert que le programme "kdesu" permettant de lancer des applications GUI en mode root ne marche plus ( le programme kdesu n'existe plus dans /usr/bin, même si on a installé le paquet kdesu   )
 
la solution constitue à installer le paquet "kde-cli-tools" :
 
https://bbs.archlinux.org/viewtopic.php?id=196227
 
il n'y a eu aucune news ou message d'information de la part de pacman vis à vis de ce problème

Pourtant kde-cli-tools est une dépendance de plasma-workspace, tu dois donc pas encore être passé sur plasma 5 ?
Dans ce cas tu aurais juste du rester sur kdesu4.

il n'a jamais été installé ce paquet kdesu4, j'ai regardé dans mon fichier pacman.log qui a un historique remontant jusqu'à novembre 2013,
 
il a été crée quand ce paquet kdesu4 ?
lorsque les mainteneurs se sont aperçus du problème kdesu en version KF5 ?
 
si aucune news/info n'est émise par pacman lors d'un "pacman -Syu" pour avertir l'utilisateur alors ça peut expliquer le manque de popularité de ce paquet kdesu4
 
je n'ai toujours pas installé plasma 5, je suis toujours sous kde4 avec la cohabitation forcée des applications KF5 voulue par les mainteneurs de archlinux

Oui, je pense aussi que cette migration n'est pas 100% transparente ni réussie, mais Arch s'en sort pas trop mal quand même.

Depuis Dimanche, j'ai mon iptables qui est parti en vrille sur un serveur, il me zappe une partie de mes connexions, j'ai du passer en catastrophe sur nftables (et les docs très .... disparates, franchement, à des années lumière de celles de pf il y 8 ans quand il est sorti, bref), personne d'autre n'a de soucis ?

Faut être un peu kamikaze pour utiliser Arch sur un serveur plus ou moins critique quand même

Hey, je ne suis pas en testing
 
Et après faut être kamikaze pour mettre des versions préhistoriques de plein de choses su des distributions "serveur", d'ailleurs j'avais fait un honeypot à base d'ubuntu, ça a été trèèèsss moche, en 40 jours, vérolée  (machine à spam)

Si tu penses à des distro style debian stable/oldstable, tu te trompes. Ce n'est parce que ce n'est pas la toute dernière version "feature" que le soft en question 'est pas maintenu et patché.

pas de souci chez moi avec iptables, un "systemctl status iptables" indique que tout est normal,

il faudrait regarder si ton fichier de configuration de iptables est correct, peut-être que la syntaxe a changé avec la dernière version de iptables, des mots clés devenus obsolètes,

si ton serveur sert pour le travail ou à générer de l'argent alors il vaut mieux mettre du debian dessus, un truc figé labellisé "stable" qui a été testé mille fois par les mainteneurs,

car le souci d'une rolling release c'est que plein de petits bugs et de regressions peuvent se glisser incognito, on le voit déjà si on est un utilisateur desktop sous archlinux, par exemple KDE avec les applications KF5 qui merdent, le noyau linux qui déconne sur certains modules

après s'il s'agit d'un serveur "domestique" sans lien avec ton travail professionnel alors tu peux mettre ce que tu veux si on aime bien les sensations fortes, le coté kamikaze, les mains dans le cambouis tout ça

 
J'ai connu des failles qui ont mis trop de temps à être patchées chez debian (à une époque) et mon HoneyPot à base de Ubuntu LTS 12.04 out-of-the-box avec mises à jour standard a pourtant fini en émetteur de spam en 40 jours, enfin il a rien envoyé car il y a un firewall devant pour bloquer le SMTP par cette machine. J'ai beau me "tromper" mais parfois comme il y a des versions paléolithiques de certains softs, les backport de sécurité sont plus complexes à mettre en place (enfin ça dépend du soft), un backport c'est pas magique, celui qui pense ça n'en a jamais fait (moi si).
 
Sinon pour mon problème d'iptables, le seul truc qui a changé c'est le passage en 4.0.2, et mes règles n'ont pas changé, et tout ce qui est userland à ce niveau n'avait pas évolué non plus, et en plus c'est plutôt pourri car on aurait dit un problème de rate-limit (tout n'est pas bloqué par IP source en plus), enfin ça m'a forcé a passer plus vite que prévu à nftables qui a le bon gout d'être certes pas encore aussi complet qu'iptables mais avec une gestion plus dans le genre pf / ipf, parce que les scripts iptables c'est gentil, mais comment dire... c'est risible face à pf par exemple.

Tu es le premier que je vois raconter ça, ça m'étonne très fortement vu la réputation de debian...

Je suis le premier a me plaindre d'un backport "lent" ? Bah si tu as envie de t'éplucher les ML concernées, tu vas t'amuser (ou pas)...
 
Debian, je l'utilisais depuis la 2.0r2, et crois moi qu'il y a eu par moment du laxisme dans du fix se sécurité sur tout ce temps. Mais comme professionnellement j’utilisais du BSD, je suis passé la dessus il y a très longtemps pour un retour sous Linux en plus depuis quelques années et la Arch.
 
Enfin bon, on est HS la  
 
Et puis nftables, c'est quand même moins archaïque qu'iptables !

quand je compile le paquet linux à partir du pkgbuild officiel je remarque qu'à chaque fois la taille des fichiers est plus grosse par rapport à la version du dépôt officiel :

quelle est la raison de cette augmentation de taille ( ici j'écrase le paquet linux officiel 4.0.4 par ma propre recompilation ) ?

normalement il ne devrait pas y avoir de différence, j'utilise les valeurs par défaut dans makepkg.conf, excepté que j'ai ajouté "MAKEFLAGS="-j2"" pour utiliser les 2 cores de mon CPU pour la compilation

Peut-être la compression finale qui est plus agressive chez le mainteneur que chez nous.
J'ai la même problématique soit dit en passant.

en fait ici il s'agit de la taille des fichiers une fois le paquet décompressé ( en gros les binaires, les fichiers modules ), systématiquement les fichiers générés par ma compilation sont un peu plus volumineuses que celui du mainteneur,

à mon avis le mainteneur doit utiliser des options de compilation différentes de ceux par défaut du fichier makepkg.conf, mais impossible de savoir lesquelles,

il y a aussi le fait que les mainteneurs des paquets officiels compilent dans un mode spécial "clean chroot", ils ont en fait une installation minimale d'archlinux dans un dossier séparé qui sert uniquement à créer des paquets archlinux :

https://wiki.archlinux.org/index.ph [...] ean_Chroot

un système qui sert en théorie à créer des paquets "propres" sans risque d'avoir des paquets AUR qui foutent la merde, mais il se peut que cet excès de sécurité ait des effets pervers, un "clean chroot" pas aussi clean que ça

Decompresse les 2 a cote de l'autre, et fait un diff, tu veras bien ou est la difference.

AUR 4, git-based:
https://lists.archlinux.org/piperma [...] 30724.html

Verifie d'avoir gcc 5.1  
Je crois que ca a été corrigé, mais il y a peu, ou avait accès au 4.0, qui demandait gcc 5.1 accessible uniquement sur le testing xD!

Normalement, aur est complètement indépendant de ta config système.
 
Je viens de tester aur4, ayant déjà des paquets sur github, j'ai voulu importer l'historique...  
AUR4 a des hooks pour vérifier que chaque commit est bien conforme aux guidelines. Par exemple, j'ai jamais versionné le .SRCINFO, donc si je veux pusher mes vieux commit git, je dois faire un rebase de tous les commits pour intégrer le .SRCINFO généré avec mksrcinfo...

Il m'arrive un phénomène étrange, depuis quelque temps. J'ai installé Arch Linux il y a deux mois, déjà, sur mon PC portable. Tout allait impeccablement (démarrage en 30 secondes, arrêt en 5). Mais depuis... l'arrivée du noyau Linux 4.0.x, j'ai l'impression que l'OS n'aime plus les démarrages à froid : Grub met plusieurs secondes à afficher le menu de démarrage (alors que c'était immédiat au début), la partie systemd met des heures et passe en mode verbose. Bref, il m'arrive de devoir attendre plus de 2 minutes avant d'avoir l'écran de connexion LightDM après ça, tout roule).
 
Ce matin, encore : Grub me fait une "read error". Redémarrage, et là, c'est systemd qui échoue à lancer le service de login (cool !). La 3e tentative fut la bonne.
 
Ce genre de chose vous arrive aussi, si, comme moi, vous éteignez votre PC tous les soirs ?

il faudrait activer le mode verbose par défaut, comme ça tu auras en détail les messages de systemd ( avec un Ok vert, ou un Fail en rouge s'il y a un souci, et éventuellement un message d'erreur ),

tu peux aussi regarder les fichiers log ( dmesg ), le journal de systemd ( journalctl -b, systemctl --failed --all ), le fichier log de xorg,

vérifie aussi la santé de ton disque dur, les données SMART, il y a l'utilitaire du fabricant qui s'execute au démarrage ( sur une clé USB ou un CD-R ) ou le programme smartmontools dont le paquet existe sur les dépôts officiels d'archlinux

Pas de problèmes chez moi. Par contre, il y aurait un problème avec les gens en raid.  
Concernant LightDM, j'avais un problème qui faisait que la boite de dialogue n'apparaissait pas (écran blanc). c'est résolu.
Pour Systemd, rien à signaler mais j'ai cru lire quelques parts que, sur certains postes, il avait une vérif du dd à chaque lancement.

pour le problème raid c'est ici :
 
https://archlinux.fr/news/corruptio [...] de-discard

Tu peux aussi faire un petit systemd-analyze blame/time.
 
systemd-analyze — Analyze system boot-up performance

Alors...
 

Ça s'affiche justement quand ça met du temps à démarrer.
 

Là, je ne saurais pas trop comment comprendre tout ce qui est marqué... ^^
 

Le disque dur est tout neuf : je l'ai acheté la veille de l'installation. Et je ne suis pas en RAID.
 
Ce qui est bizarre, c'est qu'un reboot ultérieur ne pose aucun souci.
 
Pour le systemd-analyze :
 

Je vois rien d'anormal ici.

J'aurais tendance a privilégier une cause matériele vu que ça semble impacter le temps d'affichage du menu de GRUB. Le noyau semble hors de cause.

On peut imaginer un problème avec le disque comme déjà évoqué, l'alimentation (les tensions fournis) ou que sais-je encore. Si seul le disque dur est récent, nous avons statistiquement un joli suspect

Le PC portable en question va fêter ses 6 ans dans un mois (un HP Pavilion DV6 de 2009, qui marche super bien sous Windows 8.1 installé sur le disque dur d'origine, bien qu'AMD ne veuille pas fournir de pilotes vidéos pour la Radeon Mobility HD4500 qui l'équipe et dont le pilote MS n'aime ni OpenGL, ni Flash ; en revanche, pour Direct3D et le reste, c'est bon).
 
À noter que ce mardi, il n'y a eu aucune lenteur anormale à signaler. C'est assez aléatoire.

Bonjour,  
J'utilise Arch depuis un bon moment, mais j'ai un petit soucis, pour le réinstallé xD!
 
Je pense que cela vient de ma carte Graphique. J'avais une GT 640, lors de la premiere install. tous les drivers d'installer, etc. J'ai changé de carte graphique, PAS DE SOUCIS.
Mais lorsque, maintenant, je veux réinstaller, lors du boot CD, ecran noir. Si a l'aveugle j'ecris 'reboot'. Bah ca reboot.
Comment contourner ca?
 
Merci d'avance.

quelle est donc cette nouvelle carte graphique ?
c'est un élément sensible dans une configuration sous linux, un modèle trop récent de carte graphique peut être mal supporté par le noyau linux, un pilote libre bogué ou un support incomplet,

l'écran noir apparait donc si tu démarres avec la dernière iso d'archlinux ?

il se peut que ce soit un bug du noyau linux présent dans cette image iso, une solution serait de télécharger une version plus ancienne de l'image iso archlinux qui n'aura pas ce problème, par exemple celle du mois d'avril :

http://mir.archlinux.fr/iso/

autre solution : réutiliser temporairement ta nvidia GT640 pour faire la nouvelle installation, et poster un rapport de bug en précisant le modèle de carte vidéo qui pose problème au noyau si c'est le pilote libre qui est en cause,

il devrait aussi être possible de forcer un pilote vidéo générique type vga/vesa, l'affichage sera dégradé mais au moins tu verras quelque chose à l'écran

Je verrais plus en détail demain.  
La seule Iso que j'ai, c'est la toute dernière.  
 
La nouvelle carte graphique est précisément: nVidia gtx 750 Strix OC 2Gb
 
 
Comment forcé le pilote générique ?

OU un chipset intégré en attendant si tu as.
Il y a sûrement un switch kernel à utiliser, encore faut-il savoir lequel.
Tu peux regarder sur le tracker si il y a pas déjà un cas documenté.

J'ai pensé au chipset xD!
Mais mon ecran a pas de VGA, ni d'HDMI. Et j'ai pommé l'adaptateur VGA/DVI .
Je verrais déjà avec les ISO d'avril, et mai.
Je les télécharge au taf, et les essaye ce soir .
Je tiendrais au courrant.

Après au pire... doit y avoir moyen de démarrer un autre live cd d'une autre distro qui marche chez toi, éventuellement se chrooter sur un loopback de l'iso d'arch et bootsraper le système minimal, mais ça risque d'être un poil couillu

Ca me fait surout vachement chier de tout demarché, quoi.  
J'aime bien arch,, et l'un de ses avantages, c'est quand même l'install rapide..

Tu es quand même dans un cas marginal, j'ai jamais eu de problème sur les live CD d'arch même si je réinstalle pas non plus tous les quatre matins

Bah j'me suis dis qu'avec tout le bordel que j'ai foutu, le changement de la CG, etc... C'était plus propre. Du coup, j'suis decu xD!
Marchais bien avant :<!
Je tiendrais au courant dès ce soir

l'avantage du système linux c'est que tu peux entrer en contact très facilement avec les développeurs, tu fais ton rapport de bug en donnant les détails du problème et il y a de fortes chances qu'un patch correctif soit crée dans les jours qui suivent

<taunt>Surtout Arch... Parce que Debian...</taunt>
On verra. Dans tout les cas, j'leurs enverrais mon probleme. Corrigé, ou non.

Ahaha! Bon, du coup, j'ecris via 'elinks' xD!
 
Donc c'est en effet le boot de juin (01.06.2015) qui ne gere pas ma carte graphique (je pense)
Je leurs ferait remonter tous ca avant juiller !
 
Merci de cette aide! xD
(Que je trouve ridicule, mais merci! )

J'ai installé Arch ARM sur mon Pi1 (pour tester un site Django@home et Arch est une des seules distri pour Raspberry Pi à proposer facilement du Python 3.4) et j'aime assez.  
Je commence à me tâter à l'installer aussi sur mon desktop (actuellement sur Elementary OS)... bon, en fait ça me tente de puis longtemps mais j'ai jamais osé passé le cap.

Salut !
 
Sincèrement ça vaut le coup, pour le desktop, c'est vraiment une très bonne distro et le wiki est vraiment excellent (Beginners' guide / General recommendations).
 
Après si t'es pas sur de toi au niveau de l'installation et de la configuration générale de l'os, tu peux toujours commencer par une machine virtuelle. Ça te permettra de passer le cap en toute sécurité.