Reprise du message précédent :

Ah ben merde j'ai fait une install toute fraîche hier et j'avais le bug. Du coup je suis passé à Syslinux.

D'un autre coté, syslinux est tellement plus sympa a utiliser !

syslinux c'est le bien

En parlant de cela, que pensez-vous de Gummiboot?  
Je demande parce que j'hésite à installer Arch sur mon PC principal vu qu'il sur une carte mère UEFI. J'ai toujours eu une expérience merdique avec les bootloaders à tel point que j'ai du arrêter linux à cause de cela.

drap

je pense qu'il faut rester sur les 2 valeurs sures : grub et syslinux,

le moindre bug sera normalement vite corrigé vu qu'il y a une plus grande communauté,

en général il n'y a pas de souci sur les gestionnaires de boot tant qu'on lit bien le mode d'emploi et qu'on ne cherche pas à monter des usines à gaz en terme de boot

quelqu'un sait s'il faut installer un pilote sous archlinux pour qu'il reconnaisse les smartphones connectés en USB ?

j'ai un smartphone acer "liquid e2" ( android 4.2.2 ) et quand je le connecte en USB mon archlinux ne le reconnait pas ( je ne vois pas de périphérique USB monté dans mon explorateur de fichiers dolphin de KDE ),

quand je fais un lsusb je vois pourtant qu'il reconnait un périphérique USB :

mais c'est tout, je ne vois aucun lecteur USB de monté,

à noter que mon smartphone sur l'écran affiche la mention "connecté en tant qu'appareil multimédia", preuve que lui il voit mon PC,

comment résoudre ce problème ?

Il faut installer kio-mtp-git (le seul support MTP pour Dolphin)

de ce que j'ai compris c'est qu'il faut installer un paquet android-udev sur le dépot AUR pour qu'archlinux reconnaisse le smartphone comme un "multimedia device",

mais j'aimerai que mon smartphone s'identifie comme un "usb mass storage", à priori l'option devrait exister dans le menu "paramètres" de mon smartphone, un menu qui permet de selectionner le mode d'identification du smartphone ( "multimedia device" ou "usb mass storage", l'usb mass storage ayant comme avantage de ne pas necessiter de pilote ou de règles udev ),

comment retrouver ce menu de selection dans mon smartphone ?

on dirait qu'acer l'a viré ce menu, je suis sous android 4.2.2, il y a peut-être une application android qui permet de restaurer ce choix ?

Oublie le USB Mass Storage avec un périphérique Android 4.0 ou plus (et ça vient pas d'Acer), c'est que MTP maintenant

en effet j'ai vu que google avait completement retiré le support de l'USB mass storage, avec du 4.2.2 c'est uniquement du MTP
 
bref pour résumer la solution que j'ai trouvé c'est d'installer le paquet kio-mtp pour que KDE detecte et monte automatiquement les périphériques MTP :
 
 
https://wiki.archlinux.org/index.ph [...] _KIO_Slave
 
même pas besoin du paquet android-udev,
 
ça permet d'avoir le même type de notification que les clés USB avec montage dans l'explorateur de fichier dolphin

yop,  
 
je suis nouveau sur arch (je suis pas un grand spécialiste unix mais j'ai déjà tourné sur ubuntu un petit moment).
 
 
j'ai un soucis avec arch en essayant d'installer ma carte wlan. (rtl8188)
 
j'ai download le driver sur une autre de mes partitions et j'ai essayé de lancer l'install (make, make install)
 
Mais quand je fais make j'ai ce message :

effectivement je n'ai pas de build dans le dossier
( au passage la commande tar fichier.tar ne fonctionne pas, comment installer tar?   )

Hum, va y avoir du boulot    
 
Bonjour à toi.
 
Pour commencer, es-tu sur que d'installer un module pour ta carte est la solution ?
Si oui, l'installer à la main ? As-tu vérifié l'AUR ?
 
Il te manque les headers, du paquet linux-headers pour le problème du make.
 
Pour ta question sur tar, je pense que tu fais erreur.
Tu as forcément tar, tu dois mal l'invoquer. "ne fonctionne pas" c'est pas très précis comme erreur
 
Bon courage  

et puis la règle numéro 1 avec les distributions modernes linux c'est de ne jamais installer de logiciel en mode "old school" ( le fameux "make install" ),  
 
il vaut mieux passer par le gestionnaire de paquets de sa distribution, et si le paquet n'existe pas ( peu probable avec archlinux, comme indiqué il faut jeter un coup d'oeil sur le dépôt "AUR" ) alors il suffit de créer le paquet, c'est très facile sous archlinux, tu prends un fichier pkgbuild générique et tu fous dedans les commandes qui servent à compiler et installer le paquet,
 
penses à lire le wiki archlinux ( version française et anglaise ) avant toute décision, souvent la solution aux problèmes s'y trouve, sans oublier les forums archlinux,
 
autre règle numéro 1: ne jamais utiliser l'option "--force" du gestionnaire pacman, sauf news officielle sur le site d'archlinuxn
 
commence déjà par lire la page wiki sur  le wifi et à installer les paquets nécessaires pour la gestion du wifi :
 
http://wiki.archlinux.fr/Wifi
 
si tu as du rtl8188eu :
 
https://wiki.archlinux.org/index.ph [...] #rtl8188eu
 
mais il semble que le pilote soit déjà présent dans le noyau 3.12, du coup il n'y a peut-être rien à installer

Merci beaucoup à vous 2.
 
J'ai installé un pacquet AUR prévu pour ma carte et tout est rentré dans l'ordre sans aucun soucis  
Je n'ai pas encore "le reflexe".
 
Ma carte est bien une rtl8188eu, mais j'ai quand même du l'installer. (avant l'install le system ne la reconnaissait pas)
 
Par contre je me rend compte à quel point je ne connait pas unix (même en ayant été sur ubuntu pendant 3 ans pratiquement et utilisé un peu de ligne de commande)  
Quel bonheur d'installer le system entièrement à la main !    
 
Pour tar, pas de problème non plus... je devais être fatigué et saisir autre chose...  

yo grosse merde le rtl8188 si, je te conseille d'installer le paquet 8192cu dkms via yaourt

vous étiez au courant que le démon cron n'était plus activé par défaut en cas d'installation fraiche d'archlinux ? :

https://bugs.archlinux.org/task/382 [...] &sort=desc

j'ai remarqué ça en constatant que les scripts cron n'étaient jamais activés ( mon installation d'archlinux date d'il y a moins d'un mois )

à priori il faut remplacer cron par systemd qui est capable d’exécuter le même type de tâche, mais il faut tout récréer à la main les fichiers :

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

Moi j'ai juste "activé" cronie.

il me semble qu'avec l'ancien installateur ( celui semi-graphique ) on avait pas besoin d'activer crond, il était déjà par défaut    
 

Ça m'étonnerait car à l'époque arch était pas encore passé à systemd

cron était activé via rc.d/sysvinit, comme la plupart des autres démons il me semble,
 
en tout cas je constate que sur ma machine virtuelle ( installée à l'époque où systemd n'était pas utilisé par archlinux ) que crond est lancé automatiquement au démarrage

A l'époque du rc.conf il y était sûrement dans la liste par défaut.

avec KDE 4.12 avez-vous remarqué un bug sous dolphin quand on essaie de copier un fichier d'un disque dur vers une clé USB ?
 
j'ai essayé de copier une vidéo de 700 Mo d'un disque dur interne vers une clé USB et je remarque que la pop-pup de notification de vitesse se plante sur le taux de vitesse, ça affiche un taux de 70 Mo/sec alors que la clé USB n'écrit en réalité qu'à 3 Mo/sec,  
 
du coup lorsque la copie est terminée la pop-up continue d'afficher un taux de copie à 0 ko/sec et on ne peut plus démonter la clé ( umount ou via l'icone de démontage de KDE dans la barre des tâches ),  ça indique "cible occupé", vu que la pop-up de copie de fichier est toujours en cours ( bloqué à 0 octet/seconde alors que la copie est déjà terminée )

ça me le fait aussi en utilisant la commande "cp" dans une console, et en utilisant une autre clé USB,

ça semble donc être un bug du kernel concernant l'USB Mass Storage

ça intéresserait si quelqu'un pouvait faire le test avec une clé USB formatée en FAT32, copiez dessus un fichier vidéo de 700 Mo, vous remarquerez que la copie prend un temps fou alors que tous les bits ont déjà écris sur la clé USB, et la led de la clé continuera à s'allumer pendant plusieurs minutes avant que la copie soit enfin terminé

Je crois avoir le même bug qui semble lié à la gestion du cache en écriture. Après une copie d'un gros fichier sur une clef usb, je fait un sync (qui prend un peu de temps) comme ça je suis sûre que tout est écris.
 
J'ai ce bug sur ma debian stable (noyeau 3.2 donc) avec kde 4.8 mais pas sur archlinux à jours.

dans dmesg j'ai ça :
 

à mon avis je pense que c'est en fait un bug de KDE qui affiche un taux d'écriture largement sur-estimé pour la clé, et du coup il donne l'impression que la copie est déjà terminée ( Dolphin affiche 700 Mo pour le fichier copié, le tout en moins d'une minute, ce qui est surréaliste vu que le taux d'écriture d'une clé USB est de 3 à 4 mo/sec ),

visuellement l'utilisateur a l'impression que la copie est terminée ( la fenêtre pop-up de KDE affiche 0 octets/sec ) mais en réalité elle continue de se faire, ça met trois minutes à se copier mais en fait c'est normal vu le taux d'écriture ( 3 mo/sec ) et la taille du fichier à copier ( 700 Mo )

Sur ma Debian, j'ai aussi "Assuming drive cache: write through" dans le dmesg et sur archlinux (où je n'ai aucun problème), j'ai :  
 

 
Je pense, pour ma part, qu'il s'agisse d'un problème de write cache trop grand par rapport à la vitesse du support. Il faudrait peut-être écrire une règle udev pour monter la clef sans cache d'écriture, genre : https://bbs.archlinux.org/viewtopic.php?pid=1124855

pour info voici les options de montage utilisées automatiquement par le composant qui fait office d'automount pour l'USB :

ce n'est pas moi qui ait spécifié ces options de montage, j'ai juste obtenu ces infos en tapant "mount" dans une console pour voir quelles étaient les options utilisées par le bidule qui fait l'automount

J'ai essayé de faire :  

Ça marche, mais la copie est extrêmement lente (~100kio/s) et non recommandé car provoque des écritures supplémentaires.
 
Je n'ai pas trouvé de solution à part faire, avant de démonter la clef  :

Lorsque l'on démonte la clef sous Kde, celui-ci nous laisse croire que la clef est bien démonté (quasiment instantané) alors qu'il reste beaucoup de données dans le cache :

Presque 1 minute pour écrire l'entièreté du cache au rythme de ~5(Mio/s), ça fait un buffer d'environ 300 Mo.
 
PS : je me suis trompé dans mon précédent message avec la sortie de dmesg : j'ai le même résultat entre Debian et Archlinux.

Oui ce bug de cache est connu. Il est ouvert chez arch je crois.

un bug plutôt sérieux car l'utilisateur va croire que la copie est déjà terminée, du coup il va retirer sa clé USB avec le risque de perte de fichiers ( vu que la progress bar de copie de KDE est en avance sur la copie réelle )

les rapports de bug :

https://bugs.launchpad.net/ubuntu/+ [...] ug/1001579
https://bugzilla.kernel.org/show_bug.cgi?id=41472#c12
https://bugs.kde.org/show_bug.cgi?id=281270

pour connaitre réellement la progression de la copie une solution de contournement serait d'utiliser l'utilitaire iotop ( utilisable uniquement sous le compte root ) pour voir si un processus écrit quelque part, quand la clé USB ne possède pas de LED d'activité c'est utile

Non car umount bloque.

Sauf si l'utilisateur retire sa clé sans démonter, ce qui arrive bien plus souvent qu'on ne le pense.
Madame en a fait les frais récemment sur sa clé d'autoradio, je la lui ai réparée et elle a pigé maintenant l'importance de l'opération.

ca le fait aussi sous gnome shell.
Et en plus de ça le fait de faire de l'asynchrone (en sync c'est d'une lenteur déconcertante) via un script écrit les fichiers dans n'importe quel sens sur la clef, ce qui fait que mon autoradio (qui est un peu con et se base sur l'ordre d'écriture pour faire son tri) tri les fichiers n'importe comment.
j'ai été obligé de me faire un script de synchro (de toutes façons je ne garde pas la même arbo/nommage que sur le pc sinon c'est pas utilisable) qui après chaque écriture de fichier va faire un sync sur ce dernier via cette commande magique glanée sur le web:

et je termine en balançant un coup de "fatsort" à la racine de ma clef pour trier les répertoires comme il faut...
du coup la copier est un poil longue (mais je sais pas si c'est plus long que de tout balancer en vrac??) mais ça marche au poil!

Dans ce cas c'est mérité

Habitude windowsienne pour certain(e)s.

car quand je dis "retirer" c'est retirer la clé de manière physique

vu que l'utilisateur va être perplexe ( la barre de progression de copie indique 100% mais il n'arrive pas à démonter la clé via la pop-up de KDE ) alors il va être vénère et conclura à un bug de KDE, il va alors retirer la clé physiquement en se disant que de toutes façons le fichier a été copié,

ce cas de figure arrivera probablement lorsque le fichier à copier est de type vidéo 700 Mo ~1 Go, sur une clé lambda la copie prendra 3 à 5 minutes mais KDE va donner l'impression à l'utilisateur que la copie s'est faite en moins d'une minute, d'où le risque de malentendu et de retirage de clé prématurée,

c'est vraiment un bug vicieux qui va faire une mauvaise pub à l'utilisateur qui découvre linux

c'est un reflexe qu'on retrouve quelque soit la nature de l'OS, on avait déjà ce problème du temps du lecteur de disquette, malgré la led allumée les gens étaient pressés et retiraient parfois la disquette avant que la copie soit terminée

C'est ce qui m'embête avec ce genre de bug d'un autre temps. C'est déjà pas toujours facile de faire comprendre à des gens pourquoi le monde Linux est attractif sans rentrer dans des histoires techniques ou morales, ça c'est typiquement le truc qui te fout en l'air des heures de pédagogie, à base de "mouais c'est d'la merde ton truc, ma clé uhèssebé elle fonctionne même pas dessus".

décidement grub est maudit, nouvelle version mais encore un bug :
 
https://bugs.archlinux.org/task/384 [...] &sort=desc
 
c'est moins grave cette fois, mais ça crée des doublons dans le menu grub.cfg quand on le génère
 
et un autre bug concernant grub et btrfs :
 
https://bugs.archlinux.org/task/384 [...] &sort=desc

Vous savez si c'est possible de chainload un MBR depuis un grub lancé en UEFI ?