Les dernières mises à jour ont résolu le problème complètement. Hélas, je n'ai pas le temps de m'y pencher pour comprendre.

J'ai un compte administrateur et l'autre non. Avec un je pouvais modifier les utilisateurs pas avec l'autre. Avec l'un je pouvais installer des paquets depuis apper, pas avec l'autre... Avec un je pouvais mettre le profil icc pour tous les utilisateurs, pas avec l'autre ; sur ce dernier point, même root ne peut pas le faire. Je ne peux plus rien faire avec mon compte administrateur que je faisais avant.

Sinon, selinux est disabled. Je reste persuadé que polkit est à l'origine de mon problème.

Autre information, même depuis gdm, je n'ai plus la possibilité de rebooter ou arrêter la machine.

Les voilà mais je ne pense pas que cela vienne de là.

drwxr-xr-x. 90 stephan stephan 4096 23 sept. 20:42 .

Je n'ai pas détecté quand cela s'est résolu (est-ce au passage en F19 ?) mais je n'ai plus ce problème.

MarbolanGos wrote:fedup a besoin surtout d'une partition / assez grosse vu qu'il prépare toute l'installation.

C'est /var/tmp sauf erreur de ma part qu'il utilise pour mettre les paquets téléchargés. Et comme je mets :

tmpfs /var/tmp     tmpfs defaults,noatime,mode=1777 0 0

dans mon fstab, j'ai eu une surprise sur un PC avec peu mémoire. Il m'a fallu enlever le montage en mémoire. Mais rien de bien grave

pingou wrote:Tu l'as peut être fait à un moment où les mirroirs n'étaient pas vraiment synchro

C'est sûrement cela car les deux autres Fedora 18 que j'ai fait passer en 19 l'ont été 2 ou 3 jours avant. En tout cas, tout va bien en 19.

pingou wrote:pour moi ton problème c'est ça:
> --instrepo=fedora

ET pourtant ... La première erreur que j'ai eue était :

Error: can't get boot images.
The installation repo isn't available.
You need to specify one with --instrepo.

qui se résolvait selon les indications que j'avais trouvées par

--instrepo=fedora.

Je viens de l'enlever pour montrer l'erreur et là c'est parti.

Donc ... merci. Je passe en résolu quand c'est fini.

Le réseau est tout à fait disponible à ce moment-là notamment pour aller chercher sur Google de l'aide ou pour charger les primary_db, metalink des différents dépôts lors de la commande fedup donc juste avant de donner l'erreur que je remonte ou pour vérifier que les dépôts semblent correct (comme le montre la première ligne de la log). Ce n'est donc pas un problème d'accès réseau.

Bonsoir,

Je n'arrive pas à lancer la mise à jour vers la version 19 depuis une 18 à jour.

[root@localhost ~]# yum clean all
...
[root@localhost ~]# yum update
...
[root@localhost ~]# fedup-cli --network 19 -d --instrepo=fedora

J'obtiens alors :

...
fedup.yum INFO: repo updates-testing seems OK
fedup.yum DEBUG: repos.cache=0
getting boot images...
fedup.yum DEBUG: fetching .treeinfo from repo 'fedora'

Downloading failed: couldn't get boot images: No more mirrors to try.
Last error was: [Errno 14] curl#22 - "The requested URL returned error: 404 Not Found"
fedup INFO: Downloading failed: couldn't get boot images: No more mirrors to try.
Last error was: [Errno 14] curl#22 - "The requested URL returned error: 404 Not Found"
fedup DEBUG: Exception:
Traceback (most recent call last):
  File "/bin/fedup-cli", line 181, in <module>
    main(args)
  File "/bin/fedup-cli", line 120, in main
    kernel, initrd = f.download_boot_images() # TODO: force arch?
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 282, in download_boot_images
    raise YumBaseError(_("couldn't get boot images: %s") % err)
YumBaseError: couldn't get boot images: No more mirrors to try.
Last error was: [Errno 14] curl#22 - "The requested URL returned error: 404 Not Found"
fedup INFO: /bin/fedup-cli exiting at Wed Jul 10 20:51:01 2013

Je dois avouer que je ne trouve aucune solution alors que je viens de passer deux autres PC (dont un dans un configuration très proche puisque j'ai cloné le disque il y quelques semaines).

Si vous aviez une idée, cela m'arrangerait.

Merci d'avance

Je confirme que le problème est bien le disque. Je viens de mettre un Samsung 840 Pro à la place de l'ancien et le fonctionnement est meilleur avec la journalisation que l'ancien sans la journalisation qui était sans commune mesure par rapport au même disque avec journalisation. Changement fait sans aucun regret.

Mon problème est résolu ... enfin pas complètement. Le même problème est soulevé par d'autres utilisateurs du même portable que le mien.
Il a suffi que j'enlève la journalisation de mes systèmes de fichiers pour retrouver un PC rapide en toutes circonstances. Tant pis, je prends un risque mais il est acceptable vis-à-vis du gain énorme de vitesse.

50% pour la partition système et environ 70% pour les partitions utilisateurs. Et le problème existe depuis le début de l'installation propre, donc avant ces taux de remplissages.

J'ai un problème similaire avec mon SSD de très fort ralentissement lors d'écritures massives (exemple lors de mise à jour du système). J'ai forcé le montage en data=writeback au lieu de data=ordered mais le problème reste toujours le même. Une mise à jour de système importante (plusieurs centaines de paquets) peut me prendre plusieurs heures ! Le simple fait de mettre à jour automatiquement le cache des paquets me ralentit voire me bloque le PC (suivi avec iotop). Lorsque j'utilise Evolution, le temps de filtrer 30 ou 40 mails (je vois l'accès disque permanent pendant ce temps), peut me bloquer Evolution pendant 2 à 3 minutes.
Pourtant lors de l'usage classique je n'ai aucun problème de lenteur ; j'ai un pentium B950@2,1 GHz avec 8 Gio de mémoire et une machine virtuelle XP se lance en moins de 10 secondes ; ouvrir dans The Gimp un panorama au format tiff de 150 Mpixels prend 5 à 6 secondes. Le problème semble venir uniquement de l'écriture.

Si quelqu'un avait une piste à me donner, cela m'aiderait beaucoup.

En fait le deuxième panneau est remplacé par un onglet (ou plusieurs). Les opérations de copie/déplacement se font avec du drag&drop du fichier ou des fichiers sélectionnés vers l'onglet de destination (Ctrl en plus pour copie). Si on ne maintient pas le clic de souris, le fichier est déposé dans le répertoire de l'onglet ; si on maitient, l'onglet s'ouvre, et on peut choisir un répertoire où déposer le fichier.

En fait, lors de la première installation, je n'avais pas demandé à réinstallé le chargeur de démarrage (qu'il n'avait pas trouvé). J'ai demandé une réinstallation en installant le chargeur et tout va bien.

Bonjour,

Je viens d'upgrader ma F14 en F15 beta et je n'arrive pas à booter.
Le message d'erreur est :

Warning: No root device "block:/dev/mapper/vg_kulta00-lv_root" found
Dropping to debug shell.
sh: can't access tty; job control turned off

Pendant le boot, je vois que dracut m'annonce que le vg est inactif.

J'ai essayé :

dracut# lvm vgchange -ay
[.....] now active
dracut# exit

sans succès.

Pourtant, lorsque j'essaye :

dracut# mkdir /tmp/root
dracut# mount /dev/mapper/vg_kulta00-lv_root /tmp/root

le système de fichiers est bien monté. Idem si j'essaye avec /dev/root et /dev/dm-0.

/dev/root pointe bien vers dm-0
/dev/mapper/vg_kulta00-lv_root pointe bien vers ../dm-0

Que faut-il que je regarde pour trouver la solution ?

Merci d'avance

Stéphan

Pour résoudre le problème de Digikam (je suis sous Gnome), il faut installer akonadi et ses dépendances pour que le logiciel fonctionne. Bon, ça progresse.