[pacman] Err. avec filesystem mise à jour > 6 mois (résolu)

[papa6]

Bonjour,
je dois mettre à jour un autre ordinateur différent de celui concerné par un post précédent qui m'a un peu refroidi (ne pas trop bricoler).

Je n'arrive pas à mettre mon système à jour (-Suyy), et j'obtiens les erreurs :

Code : Tout sélectionner

filesystem : /lib est déjà présent dans le système de fichiers
filesystem : /var/lock est déjà présent dans le système de fichiers
filesystem : /var/run est déjà présent dans le système de fichiers

Habituellement, on trouve des réponses sur le forum pour "glibc: /lib est déjà présent", et on répond par :

Code : Tout sélectionner

yaourt -Su --ignore glibc
yaourt -Su

Mais là, ça ne marche pas dans mon cas.

Dans mon installation, /lib est toujours un répertoire, /var/lock pointe sur /run/lock et /var/run sur /run.

J'ai lu le wiki qui ne m'a rien apporté car /lib, /var/lock et /var/run sont des répertoires et non des fichiers.
Faut-il que j'efface /var/lock et /var/run ?
/run/lock est vide, mais bien sûr pas /run.

Merci à vous pour vos idées

[papa6]

Il y a ce post, en anglais :
http://archlinux.2023198.n4.nabble.com/ ... 25i20.html

Qui me conseillerait (dans mon cas, je n'ai pas de message d'erreur de glibc, donc je ne l'ignore pas) :

Code : Tout sélectionner

pacman -Syu --ignore filesystem
pacman -S --force filesystem

Mais j'ai vraiment peur de l'option force

[tuxce]

Une rolling release, c'est mieux de la mettre à jour souvent ...
Là tu accumules les mise à jour à risque, glibc qui change de dossier, filesystem, systemd, glibc encore ... ça en fait des trucs à surveiller.

Je n'ai pas de solution toute faite, mais là comme ça, je crois que je commencerai par enlever d'éventuels paquets AUR du système (pour ne pas se retrouver avec un paquet qui n'a pas suivi les mise à jour).
Normalement, sans paquet AUR, tout devrait bien se passer mais tu seras obligé d'utiliser le --force et le souci, c'est que si ça se passe mal, il y a de grandes chances que le système ne redémarre pas.
Donc je te conseillerais plutôt de mettre à jour à des dates intermédiaires en utilisant ARM

(sinon, tu as aussi l'erreur glibc, le /lib non vide, c'est glibc )

[FoolEcho]

+1 (mais ça vaudrait quasiment le coup de réinstaller une Arch avec la dernière iso...).
Pour les dates intermédiaires, repère-toi avec les annonces (les plus critiquees étant liés à filesystem, glibc, feu-initscripts et systemd): http://archlinux.fr/category/news.

[papa6]

Merci à vous 2

Depuis la réponse hier de tuxce je suis sur les mises à jour.

----
Une parenthèse pour ceux qui atterrissent sur le forum en voulont rétrograder des paquets :

J'ai un problème avec la mise à jour de glibc, je vais donc rechercher la version et la date du programme installé (et j'en profite aussi pour la version du noyau :

Code : Tout sélectionner

yaourt -Qi glibc
yaourt -Qi linux

Sur http://arm.konnichi.com/search/, je regarde la version supérieure à celle que j'ai.

Par exemple, j'ai glibc en version 2.15.10, je vais donc rechercher la 2.16, et regarder sa date (2/7/12). Je prends une date quelques jours après : cette version est sortie le 2 juillet 2012, je choisis le 04/07/12

Je modifie mon /etc/pacman.d/mirrorlist en ajoutant en premier choix konnichi (pas besoin de commenter les autres dépôts) :

Code : Tout sélectionner

Server = http://arm.konnichi.com/2012/07/04/$repo/os/$arch

Je lance la mise-à-jour rétrogradée :

Code : Tout sélectionner

yaourt -Syyuu

Même message d'erreur, je me place un mois avant dans la mirrorlist : Server = http://arm.konnichi.com/2012/06/06/$repo/os/$arch

Toujours une erreur...
J'installe le paquet 2.16 séparément (et là ça marche, comme toutes les installations de paquets individuels) :

Code : Tout sélectionner

yaourt -U monrep/glibc-2.16.0-1-i686.pkg.tar.xz

Puis je remets une date légèrement supérieure au paquet qui vient de s'installer, soit arm.konnichi.com/2012/07/04/$repo/os/$arch et un nouveau yaourt (ou pacman) -Syyuu

-----
Mais dans mon cas, dès que je fais un -Syyuu, j'ai toujours la même erreur :

Code : Tout sélectionner

filesystem : /lib est déjà présent dans le système de fichiers
filesystem : /var/lock est déjà présent dans le système de fichiers
filesystem : /var/run est déjà présent dans le système de fichiers

(c'est bien "filesystem" et non pas "glibc", même avec une version du premier semestre 2012...

Je suis partant pour passer du temps sur ce problème, en installant paquet après paquet ceux qui sont les plus importants.

Je voudrais éviter une ré-installation complète (ça serait certes beaucoup plus rapide, mais ça colle moins avec l'usage d'une Arch

Merci pour vos idées


PS :
Une fausse idée qui faisait (avant) que je ne mettais pas toujours les versions à jour, c'est que
-1- je me disais que c'était mieux de ne pas surcharger les serveurs (quand on a un torrent, on a pas de scrupule, mais là, ce n'est pas le cas)
et -2- je prennais l'exemple d'autres distributions qui sortent tous les 6 mois.

Enfin, et c'est encore une mauvaise raison, quand une mise à jour ne se faisait pas à cause d'un problème quelconque, je repoussais à plus tard

Tout ça est erroné. Donc, lecteurs du forum, n'hésitez plus à faire des mises à jour toutes les semaines ou 15 jours

[tuxce]

J'aurais pas cru que tu t'y lancerais
Au cas où, j'avais écrit un script pour m'aider à faire ce genre de downgrade / upgrade vers une date précise, si ça peut t'aider : https://gist.github.com/tuxce/1335005 ex:

Code : Tout sélectionner

rollback -c 20120606

Pour les erreurs, la mise à jour de filesystem qui modifie les /var/lock et /var/run demande obligatoirement le --force
Tu peux par exemple exécuter (que ça ne t'empêche pas de vérifier, c'est toujours +/- délicat ces trucs de vielles maj):

Code : Tout sélectionner

rollback -c 20120607
rollback -c 20120608 -Syyuu --ignore filesystem
# rm -rf /var/run /var/lock # seulement si c'est des dossiers
rollback -c 20120608 -S --force filesystem

filesystem qui modifie les /var/lock et /var/run apparait le 08/06/2012 si je me base sur ARM

(pas obligé d'utiliser le script, en gros, il crée un pacman.conf temporarire pour y faire pointer le serveur vers http://arm.konnichi.com/<date>/$repo/os/$arch/ )

[papa6]

Merci beaucoup, c'est la bonne piste

l'erreur semble vraiment tourner autour de ça : mon système est resté bloqué juste avant que filesystem modifie les /var/lock et /var/run.

Je viens donc d'installer la version tout juste supérieure avec un --force. Ça a marché, avec un avertissement :

Code : Tout sélectionner

(1/1) mise à jour de filesystem                    [######################] 100%
Avertissement : Les permissions pour le répertoire sys/ sont différentes
système de fichier : 755 paquet : 555

Mais ensuite, le -Syyuu ne passe pas, ni tout seul, ni avec --ignore filesystem ou --ignore filesystem,glibc

Je veux bien utiliser ton script, mais je ne sais pas comment le lancer (je l'ai mis dans le /usr/bin/ et j'ai essayé avec un sudo devant, à cause des droits, mais ce n'est pas une commande...)

[tuxce]

Parce que c'est un script Il faut lui donner les permissions d'exécution :

Code : Tout sélectionner

chmod +x rollback

Sinon, c'est quoi la nouvelle erreur ?

[papa6]

(merci pour le +x)

Ça y est, je crois cerner un dysfonctionnement : quand j'utilise rollback -c 20120606 ou le dépôt konnichi de juin 2012, dans la liste des paquets qui vont être mis à jour se trouve filesystem-2013.01-3...

Je ne comprends pas pourquoi ni comment il va chercher cette version de 2013...

La seule erreur qui persiste est :
filesystem : /lib est déjà présent dans le système de fichiers

Les versions installées sont linux 3.3.4-2 (2 mai 2012 -- avec un message lors de Qi qui indique un conflit avec kernel26 ?...), filesystem 2012-6.2 (6 juin 2012), glibc 2.15-7 (1er mars 2012).

Si je lance rollback -c 20120606 --ignore filesystem, j'ai "Erreur option invalide" (mais ça c'est lié au script ?)
Je lance pacman -Syyuu --ignore filesystem
Là, j'ai une vingtaine de lignes identiques :

Code : Tout sélectionner

glibc: requires filesystem>=2013.01

Vraiment bizarre, car toutes mes versions installées sont de la mi-2012...
Je lance pacman -Syyuu --ignore filesystem,glibc Et là :

Code : Tout sélectionner

error: failed to prepare transaction (unexpected error)

Donc on revient sur la même erreur qu'avec rollback

[tuxce]

Si je lance rollback -c 20120606 --ignore filesystem, j'ai "Erreur option invalide" (mais ça c'est lié au script ?)

Normal, rollback prend les options de pacman, il faut lancer :

Code : Tout sélectionner

rollback -c 20120606 -Syyuu --ignore filesystem

Sinon, pour qu'on puisse suivre :
- Tu dis que

Je viens donc d'installer la version tout juste supérieure avec un --force. Ça a marché, avec un avertissement :

De quelle date on parle ? Si tu as utilisé --force, c'est que tu as installé filesystem 2012.6-1 or ce dernier date de 08/06/2012
- Après tu parles de 20120606 ... ?

Pour info :

Code : Tout sélectionner

$ rollback 20120607 -Syyi core/filesystem
:: Synchronisation des bases de données de paquets...
 core                                        103,7 KiB  56,2K/s 00:02 [######################################] 100%
 extra                                      1401,3 KiB   150K/s 00:09 [######################################] 100%
 community                                  1679,2 KiB   159K/s 00:11 [######################################] 100%
 multilib                                     89,0 KiB  43,4K/s 00:02 [######################################] 100%
Dépôt                 : core
Nom                   : filesystem
Version               : 2012.2-5
URL                   : http://www.archlinux.org
Licences              : GPL
Groupes               : base
Fournit               : --
Dépend de             : iana-etc  bash  coreutils
Dépendances opt.      : --
Est en conflit avec : --
Remplace              : --
Taille du téléchargement :    3,98 KiB
Taille installé :  76,00 KiB
Paqueteur             : Tom Gundersen <teg@jklm.no>
Architecture          : any
Compilé le            : mer. 02 mai 2012 13:49:07 CEST
somme MD5             : 4e745ba7a7bfe87c896f62f312c83c25
Somme de contrôle SHA256      : d3437f662f47452a9e1427cdf1b2c6f67c3f1b1ed637c0429630928a92bedef3
Signatures	  : Oui
Description           : Base filesystem

$ rollback 20120608 -Syyi core/filesystem
:: Synchronisation des bases de données de paquets...
 core                                        103,8 KiB  56,2K/s 00:02 [######################################] 100%
 extra                                      1400,5 KiB   156K/s 00:09 [######################################] 100%
 community                                  1680,2 KiB   176K/s 00:10 [######################################] 100%
 multilib                                     89,0 KiB  43,4K/s 00:02 [######################################] 100%
Dépôt                 : core
Nom                   : filesystem
Version               : 2012.6-2
URL                   : http://www.archlinux.org
Licences              : GPL
Groupes               : base
Fournit               : --
Dépend de             : iana-etc  bash  coreutils
Dépendances opt.      : --
Est en conflit avec : --
Remplace              : --
Taille du téléchargement :    4,09 KiB
Taille installé : 312,00 KiB
Paqueteur             : Dave Reisner <dreisner@archlinux.org>
Architecture          : any
Compilé le            : mer. 06 juin 2012 12:13:51 CEST
somme MD5             : 0ea50a2e1756b07f1a5bc0fad43d2773
Somme de contrôle SHA256      : 1bebfd20f3e2fd51fafb5acdb2619052bc4e721c7fc7de1e3ff9d0a05ed4efac
Signatures	  : Oui
Description           : Base filesystem

Pour le coup, je vois pas trop comment tu peux avoir du filesystem 2013 et encore moins une base bancale qui demanderait du 2013 mais ne le trouverait pas.

[EDIT]remarque, je suis en x86_64, possible que filesytem 2012.6 ait été mis avant pour i686 ... tu es en i686 ? [/EDIT]

[papa6]

Oui, je suis en i686, et j'avais utilisé --force pour filesystem.
Pour le reste, je repars tenter avec tes indications, et je poste bientôt les résultats.

[papa6]

Ça y est, je crois que je viens de bousiller mon système...

La date qui posait problème était autour du 2 mai 12.
Je m'étais listé les versions installées, avec les dates du dernier dépôt, ainsi que de la version suivante.

Versions installées :
gcc-libs 4.7.0-5, 17/4/12, dépend de glibc>=2.15
binutils 2.22-7, 2/5/12, dépend de glibc>=2.15 et zlib
filesystem 2012.2-5, 2/5/12
glibc 2.15-7, 1/3/12 (...)
linux 3.3.4-2, 2/5/12
---
Versions suivantes :
linux 3.3.5-1, 8/5/12
glibc 2.16-0, 2/7/12
gcc-libs 4.7.0-6, 7/5/12
filesystem 2012.6-2, 6/6/12
binutils 2.22-8, 2/7/12

Du coup, j'ai, à tatons, testé :

Code : Tout sélectionner

rollback -c 20120502 -Syyuu --ignore filesystem

puis comme ça ne marchait pas (il y avait un pavé de paquets liés ne pouvant pas être mis à jour), j'en suis arrivé à :

Code : Tout sélectionner

rollback -c 20120502 -Syy --ignore filesystem,glibc,gcc-libs,binutils,gcc

Mon dernier message d'erreur est

Code : Tout sélectionner

sh: /lib/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib/libncursesw.so.5)

(je ne comprends pas pourquoi il demande une version de juillet 2012 alors que tous les paquets sont de mai 2012).

Mais maintenant pacman/yaourt ne se lance plus...
Je n'ose même pas éteindre mon ordi (s'il crashe, je n'ai pas de lecteur CD pour le lancer un live...)
,glibc,gcc-libs,b

[tuxce]

J'arrive pas à comprendre comment t'arrives à te mélanger comme ça ...
Déjà, c'est pas une question de versions mais de date ! ARM correspond à des dépôts à une date donnée. Il n'y a pas de mélange de version. Si tu mets ton système à une date X, les paquets seront cohérents tels qu'ils l'étaient à la date X.

Au départ c'était pas si compliqué (déjà fait sur 2 systèmes, ça fonctionne sans souci). En supposant que la première mise à jour critique à faire est celle de filesystem :
1. déterminer la date ou on passe à filesystem 2012.6-2 (qui correspond à la version décrite dans 1er news décrivant une mise à jour délicate : http://archlinux.fr/news/mise-a-jour-de ... le-requise )
En suivant les -Si que j'ai donné plus haut, il s'avère que c'est le 08/06/2012 (pour i686 aussi)
2. mettre à jour à la date juste avant pour être prêt à suivre la news : rollback 20120607 -Syyuu
3. suivre la news :

Code : Tout sélectionner

rollback -c 20120608 -Syyuu --ignore filesystem
# rm -rf /var/run /var/lock # seulement si c'est des dossiers
rollback -c 20120608 -S --force filesystem

4. faire pareil pour toutes les autres mise à jour demandant éventuellement une action utilisateur :
http://archlinux.fr/news/le-repertoire- ... symbolique
http://archlinux.fr/news/fontconfig-2-1 ... le-requise
http://archlinux.fr/news/mettre-a-jour- ... 2-ensemble

Je ne sais pas comment t'en arrivé à déduire qu'ignorer la plupart des paquets critiques du système allait faire du bien à l'ordi

Je ne peux que supposer mais à mon avis, à un moment ou un autre, t'as eu un pacman.conf avec des dépôts de date différente. Par contre, t'aurais du y aller pas à pas et surtout poster les sorties de pacman.

[papa6]

Merci pour tout le temps que tu as consacré...

Pour ce que j'appelais "version", tu as raison, ce sont des dates qui comptent. J'avais simplement mis de côté quelques paquets pour les installer le cas échéant avec -U

Pour fontconfig, je n'en avais pas parlé, mais j'avais déjà corrigé avec --force

Pour filesystem-2013.01-1 et glibc-2.17-2, je n'y suis pas encore.

Par contre, à cause du glibc qui ne marche pas, je ne peux plus rien faire (ls, pacman, etc. ne se lancent plus).

Je suis donc bon (façon de parler) pour une réinstallation, c'est bien ça ?

[papa6]

Pour info, voici le pavé qui m'a fait ignorer plusieurs paquets essentiels glibc, libutils, gcc, etc :

Code : Tout sélectionner

[moi@myhost ~]$ rollback -c 20120607 -Syyuu --ignore filesystem,glibc

[...]

:: Début de la mise à jour complète du système...
Avertissement : apvlv : retourne à la version antérieure (0.1.4.20121023-1 => 0.1.4-1)
Avertissement : aqbanking : retourne à la version antérieure (5.0.25-1 => 5.0.21-1)
:: Remplacer dbus-core par core/dbus ? [O/n] 
Avertissement : desktop-file-utils : retourne à la version antérieure (0.21-1 => 0.19-1)
[...]
:: Remplacer libusb par core/libusbx ? [O/n] 
:: Remplacer procps par core/procps-ng ? [O/n] 
:: Remplacer udev par core/systemd ? [O/n] 
[...]
résolution des dépendances...
Avertissement : ignore le paquet glibc-2.17-3
Avertissement : impossible de résoudre « glibc>=2.17 », une dépendance de « gcc-libs »
[idem, plus de 300 fois...]
Avertissement : ignore le paquet glibc-2.17-3
Avertissement : impossible de résoudre « glibc>=2.17 », une dépendance de « gcc-libs »
:: Les paquets suivants ne peuvent pas être mis à jour à cause de dépendances qui ne peuvent êtres satisfaites :
      apr  apvlv  aqbanking  automake  binutils  ca-certificates
      ca-certificates-java  cairo  cifs-utils  cloog  clutter  colord
      consolekit  coreutils  cryptsetup  cups  curl  db  dbus
      desktop-file-utils  device-mapper  djvulibre  e2fsprogs  evince  fakeroot
      ffmpeg  file-roller  firefox  flashplugin  gcc  gcc-libs  gettext
      ghostscript  gimp  glib-networking  glib2  gmp  gnome-desktop
      gnome-keyring  gnome-menus  gnucash  gnutls  grep  groff
      gsettings-desktop-schemas  gtk3  gvfs  gwenhywfar  hedgewars  hplip  icu
      imagemagick  inetutils  intel-dri  iproute2  iputils  kdelibs  krb5
      ktoblzcheck  ldns  less  libarchive  libatasmart  libcups  libegl
      libevent  libgl  libldap  libmp4v2  libmpc  libmysqlclient  libofx
      libproxy  libpulse  libreoffice-base  libreoffice-calc
      libreoffice-common  libreoffice-draw  libreoffice-extension-pdfimport
      libreoffice-gnome  libreoffice-impress  libreoffice-kde4
      libreoffice-math  libreoffice-postgresql-connector  libreoffice-sdk
      libreoffice-sdk-doc  libreoffice-writer  libspectre  libssh2  libtool
      libtracker-sparql  libva  linux  lvm2  lxdm  lxpanel  lxterminal  man-db
      mencoder  menu-cache  mesa  mkinitcpio  mpfr  mplayer  mupdf  mysql
      mysql-clients  nautilus  net-snmp  netcfg  nfs-utils  nfsidmap  ntfsprogs
      openjdk6  openssh  openssl  pam  pcmciautils  pcre  perl  perl-xml-parser
      php  php-apache  php-mcrypt  phpmyadmin  pkg-config  polkit  poppler
      poppler-glib  postgresql-libs  ppl  pulseaudio  python2-gobject2  qt
      qtwebkit  rasqal  reiserfsprogs  rsync  shadow  smbclient  soprano  sudo
      sysvinit  taglib  thunar  tor  systemd  udisks  unrar  util-linux
      v4l-utils  vlc  wpa_supplicant  xf86-video-intel  xfconf  xfsprogs
      xorg-docs  xorg-server  xournal  xulrunner

Voulez-vous ignorer les paquets ci-dessus pour cette mise à jour ? [o/N]

[tuxce]

Je sais pas si t'en as encore la possibilité, mais je suis curieux de voir la tête du pacman.conf que te sort rollback.
Parce que glibc-2.17-3, c'est tout sauf un paquet du 7 juin.

Pour ce qui est de la réparation, je crois bien qu'une réinstallation sera plus simple.

[EDIT]
je viens de remarquer ça :

Code : Tout sélectionner

Avertissement : apvlv : retourne à la version antérieure (0.1.4.20121023-1 => 0.1.4-1)

apvlv à été compilé le 6 Nov 2012 en version 0.1.4.20121023-1, c'est la version actuellement disponible sur les dépôt et c'est la version qui est installée sur ton système... alors que normalement, tu devais y aller étape par étape dans les mise à jour

Enfin bref, t'es bon pour une réinstallation, désolé
[/EDIT]

[papa6]

Bonjour,
Ok pour la ré-installation.
En attendant, voici mon pacman.conf :

Code : Tout sélectionner

#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives

#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir     = /
#DBPath      = /var/lib/pacman/
#CacheDir    = /var/cache/pacman/pkg/
#LogFile     = /var/log/pacman.log
HoldPkg     = pacman glibc
# If upgrades are available for these packages they will be asked for first
SyncFirst   = pacman pacman-color yaourt package-query pyalpm
XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#XferCommand = /usr/bin/curl -C - %u > %o
#CleanMethod = KeepInstalled
Architecture = auto
SigLevel = Never
#SigLevel     = Optional TrustAll
#SigLevel = Optional TrustedOnly

# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg   =
#IgnoreGroup =

#NoUpgrade   =
#NoExtract   =

# Misc options
#UseSyslog
#ShowSize
#UseDelta
#TotalDownload
CheckSpace

#
# REPOSITORIES
#   - can be defined here or included from another file
#   - pacman will search repositories in the order defined here
#   - local/custom mirrors can be added here or in separate files
#   - repositories listed first will take precedence when packages
#     have identical names, regardless of version number
#   - URLs will have $repo replaced by the name of the current repo
#   - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
#       [repo-name]
#       Server = ServerName
#       Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#

# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.

 
#[testing]
#Include = /etc/pacman.d/mirrorlist

[core]
#SigLevel = PackageRequired
Server = ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/$arch
Include = /etc/pacman.d/mirrorlist

[extra]
#SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist

#[community-testing]
#Include = /etc/pacman.d/mirrorlist

[community]
#SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist

# An example of a custom package repository.  See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///home/custompkgs

[archlinuxfr]
#Server = http://repo.archlinux.fr/i686
Server = http://repo.archlinux.fr/$arch

Ce qui s'était passé, je pense, sur mon ordi depuis les derniers mois, c'est que la mise à jour générale n'avait pas pu se faire, par contre, quand j'installais de nouveaux paquets, il y avait des mises à jour ponctuelles.
D'où l'apvlv à jour...

Merci à tous, problème résolu par un abandon... [EDIT]NON, je n'abandonne pas, je reprends le sujet[/EDIT]

[papa6]

Bonjour à vous tous !
Je reprends le sujet, une Arch cassée, ça se répare, non ?

J'ai redémarré mon EEE avec l'iso Arch sur une clé Usb.

J'ai tenté un chroot, qui n'a pas fonctionné. Ce n'est pas grave, j'ai mis à jour les paquets comme indiqué par tuxce.

1- /etc/pancman.d/mirrorconf, avec une seule ligne :

Code : Tout sélectionner

Server = http://arm.konnichi.com/2012/06/07/$repo/os/$arch

Code : Tout sélectionner

pacman -r /mnt -Syyuu

Et ça marche

2- Idem avec 2012/06/08
Ça ne marche pas. Donc :

Code : Tout sélectionner

pacman -r /mnt -Syyuu --ignore filesystem

Ok.
/mnt/var/lock était vide, je l'ai effacé, et maintenant il pointe vers ../run/lock
Par contre /mnt/var/run contenait un répertoire lxdm et 2 fichiers dhclient-eth0. Je n'y ai donc pas touché.

Code : Tout sélectionner

pacman -r /mnt -Sf filesystem

Échec...
Par contre /mnt/var/lock pointe maintenant vers ../run/lock et /mnt/var/run est inchangé.

Si je devais modifier quelque chose, ce serait :
- de déplacer le contenu de /mnt/var/run vers /mnt/run
- de créer un lien /mnt/var/run vers ../run
- de relancer le pacman -r /mnt -Sf filesystem (à la date du 8 juin 12, sa version actuelle étant la 2012.6-2 du 6 juin)

Mais pour l'instant je ne touche plus à rien sans vos avis.
Merci

[tuxce]

Tu peux vider le /var/run d'un système non démarré sans problème.
C'est un dossier qui comporte des infos sur ce qui tourne. Le contenu est recréé à chaque démarrage/lancement d'applications.
D'ailleurs, le /run vers lequel il pointera est un tmpfs (volatile)

[papa6]

YES YES YES
La solution était toute simple (comme d'hab ' ), pas besoin de tout réinstaller, on est sur Arch, par sur d'autres machins-choses...

Le système était complètement planté, même "ls" ne marchait pas.

Solutions :
Démarrez avec une clé Usb ou un CD live avec l'iso d'arch.

Essayez de chrooter. (loadkeys fr, la série de mount puis le chroot).
* Si le chroot marche, vous êtes sur votre propre disque, modifiez les dépôts pour revenir en arrière quand il faut, faites un pacman -Syyuu. Puis changez la date pour finalement arriver à maintenant...

* Si le chroot ne marche pas, ce n'est pas grave.
Vous pouvez quand même mettre vos paquets à jour en utilisant l'option -r /mnt --noscriptlet. C'est moins bien que le chroot, mais ça marche quand même.
D'abord, modifiez l'/etc/pacman.d/mirrorlist : créez-en une nouvelle avec une seule ligne : Server = http://arm.konnichi.com/AAAA/MM/JJ/$repo/os/$arch (AAAA/MM/JJ à adapter bien sûr...)
Puis :

Code : Tout sélectionner

pacman -r /mnt --noscriptlet -Syyuu

Avancez avec des dates assez rapprochées, pour ne pas avoir d'un coup trop de changements.
Puis videz votre cache, pour vous attaquer à une date suivante :

Code : Tout sélectionner

rm /var/cache/pacman/pkg/*

Modifiez à nouveau la mirrorlist en avançant par exemple d'un mois.
Etc.

À la fin, tentez quand même de rebouter et de chrouter. Depuis le chroot, un dernier pacman avec les bons dépôts (en ayant supprimé cette fois konnichi) et -Syu ne devrait pas faire de mal.

(Et merci tuxce)