Bonjour: personnellement, ma F17 64 KDE (pilote nouveau depuis F15 sur nvidia gtx360m) , kernel 3.4.0-1 fonctionne parfaitement, plus rapide, très stable ....au top de mon point de vue!!!! mais mon utilisation est peut-être plus "basique" ...
Ah oui, chez moi aussi, par rapport à mon utilisation F17 64 KDE tourne nickel également ! 🙂
Pour ma part, j'ai eu un moment un nb de pb assez important au début de F16 et j'ai décidé de limiter les mises à jours et de ne pas passer à F17.
Même si on peut considérer Fedora comme un laboratoire, pourquoi faire des Alpha, Beta, RC etc. pour lâcher une distrib qui pose pb.
Dans ce il faut revoir le cycle des release.

Mes connaissances ne sont pas celles de la plupart des membres du forum et chaque bug peut rapidement devenir un calvaire pour moi.
nIQnutn wrote:Pour ma part, j'ai eu un moment un nb de pb assez important au début de F16 et j'ai décidé de limiter les mises à jours et de ne pas passer à F17.
Même si on peut considérer Fedora comme un laboratoire, pourquoi faire des Alpha, Beta, RC etc. pour lâcher une distrib qui pose pb.
Dans ce il faut revoir le cycle des release.

Mes connaissances ne sont pas celles de la plupart des membres du forum et chaque bug peut rapidement devenir un calvaire pour moi.

Si tes connaissances sont limitées, et que tu ne sens pas à l'aise avec les bugs (et il y en a quelques uns sur F17), pourquoi ne pas choisir une autre distribution beaucoup plus stable, comme centOS ?
mais expliquez-moi maintenant comment il se fait que pour une distro de linux j'en suis à devoir lancer à la mano le service nfs idmapd
Tu as un message d'erreur pour ce service? 
$ systemctl status nfs-idmap.service
En théorie, systemd le onsidère comme une "dépendance" pour lancer nfs-server.
eclipseo wrote:
mais expliquez-moi maintenant comment il se fait que pour une distro de linux j'en suis à devoir lancer à la mano le service nfs idmapd
Tu as un message d'erreur pour ce service? 
$ systemctl status nfs-idmap.service
En théorie, systemd le onsidère comme une "dépendance" pour lancer nfs-server.
En fait maintenant je le lance automatiquement via un script au boot. mais normalement, en faisant 
$ systemctl enable nfs-idmap.service
une fois, je m'attends à ce qu'il démarre sans autre au prochain boot, d'autant plus que la commande marche et qu'il dit avoir créé le symlink mais dans les faits, je ne sais pas exactement ce qu'il se passe et je dois bien admettre que j'ai pas trop creusé le pb...

et mon pc en f17 est juste client nfs, le serveur tourne sur une bécanne en ubuntu 10.10 server (qui marche superbement bien d'ailleurs).

ceci dit, comme je le disais, j'arrive toujours à contourner les problèmes d'une manière ou d'une autre sauf dans le cas du boot sur le kernel 3.4.0. mais là non plus, je n'ai pas encore pris la peine de chercher (faut dire que quand t'as plus de signal sur les moniteurs, ça devient compliquer d'aller voir dmesg et la log d'autant plus que du coup, j'ai même pas accès aux terminaux en plein écran). j'ai juste essayé de me connecter via ssh depuis un mac mais apparemment, sshd n'est même pas démarré. donc voilà, une énigme de plus à résoudre quand j'aurais le courage de m'y atteler...

merci en tout cas pour vos réponses.
chepioq wrote: Si tes connaissances sont limitées, et que tu ne sens pas à l'aise avec les bugs (et il y en a quelques uns sur F17), pourquoi ne pas choisir une autre distribution beaucoup plus stable, comme centOS ?
j'y songe depuis un moment, mais je pense me tourner vers Debian qui correspond plus à mes besoins.
Pour le moment, je reste sous F16 jusqu'à la fin du support et après j'aviserai.
Pour infos, j'ai résolu le problème du boot sur le kernel 3.4.0 en installant... les kmod-nvidia. conclusion: y'a du avoir une régression quelque part dans les drivers nouveau. pour une fois que j'avais pas installé les drivers propriétaires parce que nouveau marchait bien, je me suis fait avoir.

Linux madP9X79 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

et concernant le problème nfs, au boot voilà ce que j'ai:
systemctl status nfs-idmap.service
nfs-idmap.service - NFSv4 ID-name mapping daemon
          Loaded: loaded (/usr/lib/systemd/system/nfs-idmap.service; enabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/nfs-idmap.service
il est donc bien enabled et, d'après la doc, il devrait démarrer automatiquement au boot. ceci dit, je ne sais pas si c'est particulier à ce service ou si ça se produit avec d'autres.
5 jours plus tard
Il y a eut un sujet sur nfs4 qui n'avait justement plus besoin de ce service coté client:
http://lists.fedoraproject.org/pipermail/test/2012-April/107449.html

Du coup j'ai pas bien compris si c'est encore nécéssaire. Sur mon desktop (nfs client uniquement), le service n'est effectivement pas démarré et j'ai bien les droits correct sur mes montages nfs.
Note: Le serveur nfs est en EL6.
Je vais regarder s'il y a quelque chose de spécial que je n'aurais pas vu... mais, perso, sans idmapd c'est nobody:nobody de partout et quand tu fais du rsync en présérvant owner/group, ça fait vraiment très mal!

ceci dit, juste pour infos également, doit y avoir un pb qq part avec la gestion du réseau. voilà un exemple assez édifiant, c'est une copie de mon terminal:
[root@madP9X79 bin]# gem update
Updating installed gems
WARNING:  Error fetching data: SocketError: getaddrinfo: Name or service not known (http://rubygems.org/latest_specs.4.8.gz)
Nothing to update
[root@madP9X79 bin]# gem update
Updating installed gems
WARNING:  Error fetching data: SocketError: getaddrinfo: Name or service not known (http://rubygems.org/latest_specs.4.8.gz)
Nothing to update
[root@madP9X79 bin]# gem update
Updating installed gems
Updating minitest
ERROR:  While executing gem ... (Gem::GemNotFoundException)
    Could not find a valid gem 'minitest' (3.1.0) locally or in a repository
[root@madP9X79 bin]# gem update
Updating installed gems
Updating minitest
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    SocketError: getaddrinfo: Name or service not known (http://rubygems.org/gems/minitest-3.1.0.gem)
[root@madP9X79 bin]# gem update
Updating installed gems
Updating minitest
Fetching: minitest-3.1.0.gem (100%)
Successfully installed minitest-3.1.0
Gems updated: minitest
Installing ri documentation for minitest-3.1.0...
Installing RDoc documentation for minitest-3.1.0...
[root@madP9X79 bin]#
comme on peut le voir, j'ai du lancer 5 fois la commande gem update pour que ça veuille bien marcher, chaque fois il y a une erreur différente jusqu'à ce que ça finisse par passer.

et c'est encore pire avec yum: il y a une erreur de curl (hostname not found) pratiquement pour chaque repository et au final, je suis chaque fois obligé de faire un yum clean all et de refaire un update après, ce qui veut dire qu'à chaque fois, tu te retouves à downloader l'intégralité des bases de yum ce qui prend un temps non négligeable... sans compter que j'ai régulièrement des notifications du daemon de yum qui me signalent qu'il n'y a plus de repository à essayer. et je sais que ce n'est ni ma machine, ni mon réseau qui débloquent, ça marche parfaitement bien avec les autres distros, j'ai ça depuis f16...

enfin voilà, encore un "détail" prodigieusement énervant spécifique à fedora. je n'ai pas regardé si d'autres ont le même pb, je dois l'avouer 😉
Dernières nouvelles du front: maintenant j'ai mes user/group corrects sans lancer idmapd et sans avoir rien fait de spécial si ce n'est des yum update.

Donc ça remarche mais sans savoir pourquoi ça ne marchait pas avant, mais bon, on va pas se plaindre, non?

🙂