On Thu, Jan 24, 2013 at 11:32 AM, Dennis Herbrich <dennis@archlinux.org>wrote:
On Thu, Jan 24, 2013 at 10:21:12AM +0100, arnaud gaboury wrote:
I was thereafter happy to log into my system, with no kernel panic ! I decided to reinstall all packages from the "broken" upgrade.
Nevertheless, everything is not fine. Somme apps are broken, and do not know why. I guess it is because of the /usr/lib64 issue. For example, offlineimap and log are broken with no reasons, as they used to work perfectly.
Hello Arnaud.
When you system is thought to be inconsistent, the recommended course of action is to bring it back into a well-known state. Yeah, I know, stating the obvious.
A consistent state can be reached by reinstalling, of course, but we do not want to take this option. ;)
Alternatively, consistency really boils down to "1) all files that are supposed to be installed must be installed, and 2) nothing should be installed that is not either part of one of the installed packages, or willfully and correctly installed manually by the admin."
To check both, some pacman and scripting magic makes life easier:
1) pacman -Qk should have checked that already. A "historic" alternative was to simply explicitly reinstall all currently installed packages. Get a list of all packages with pacman -Q, munge the output, and use pacman -S to install each package again, with it's version explicitly given as "<pkgname>=<pkgver>" to pacman.
2) All files that SHOULD be installed (through package management) can be listed by pacman -Ql|cut -d' ' -f2. Pipe this (sorted) to a file, and you've got your list to check against. Then run find on /, excluding directories like /home, /dev, /proc and /sys, and diff/comm both results to get an idea if there may be extra files on your disk where they shouldn't be. Honorable mention goes to rogue or missing libraries in /usr/lib, which may cause all kinds of annoying failures. The 'comm' tool is especially useful here.
At the very least you should recursively check /bin, /boot, /opt, /sbin, /usr and /var for stray files, with /etc coming next. Be aware that /opt and /etc may very well include "stray files" that are supposed to be there. That's really something you must know and decide for yourself, though.
Did I mention that pacman is awesome? Combined with the Arch Rollback Machine, it's insanely powerful and flexible. :)
Good luck! Dennis -- "Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen." Dr. Wolfgang Schäuble, Bundesinnenminister (14.10.08, TAZ-Interview)
0D21BE6C - F3DC D064 BB88 5162 56BE 730F 5471 3881 0D21 BE6C
Dennis, thank you so much for your full and detailed explanations. I totally agree it is a very bad idea to let a system in an inconsistent state. It will certainly lead to huge problems in the future. Here is what I did : -1 #pacman -Qk -----> no missing files -2-#pacman -Qq | grep -vxFf <(pacman -Qqm) | sudo pacman -S -----> reinstall ALL packages excepted AUR -3- #pacman -U each AUR one by one (ouf !!) -4 run this script found in the wiki: #!/bin/sh tmp=${TMPDIR-/tmp}/pacman-disowned-$UID-$$ db=$tmp/db fs=$tmp/fs mkdir "$tmp" trap 'rm -rf "$tmp"' EXIT pacman -Qlq | sort -u > "$db" find /bin /etc /lib /sbin /usr \ ! -name lost+found \ \( -type d -printf '%p/\n' -o -print \) | sort > "$fs" comm -23 "$fs" "$db" $ pacman-disdowned > non-db.txt Then carefully rm OR rename when in doubt all uneeded files. My system is working not bad, but still two obvious issues: -log files do not log anymore. Maybe not so important as $journalctl seems our new friend. -I use offlineimap + msmtp + mutt on a gmail accound. [gabx@magnolia:~]$ offlineimap OfflineIMAP 6.5.4 Licensed under the GNU GPL v2+ (v2 or any later version) Account sync Gmail: *** Processing account Gmail Establishing connection to imap.gmail.com:993 Creating new Local Status db for Gmail_local:INBOX-journal ERROR: While attempting to sync account 'Gmail' file is encrypted or is not a database *** Finished account 'Gmail' in 0:01 ERROR: Exceptions occurred during the run! ERROR: While attempting to sync account 'Gmail' file is encrypted or is not a database I do not understand what has changed about my ~/Mail/gmail database. Is it on my side, or gmail side? I will investigate deeper. NOW next step is to buy a new HD, install a fresh Archlinux without testing and dual boot. My box has changed from the "to hobby" status to "working tool" due to a radical change in my job (from trader to developper !). I can not any more afford break, as a lot of Java dev and a big website are ahead. Thank you again for your support. Once more, the open source model proved to be efficient.