[arch-general] broken system after today upgrade
Dear list, testing repo is enabled on my box. Today upgrade of glibc, filesystem and Linux failed and leaves me with an unbootable machine. I boot with Archiso, then mount /, /boot and /user on /mnt/. From this directory, I then #pacman -Syu linux glibc filesystem with no success. Get excv unfound. I downgraded these 3 packages, then try again. It went with no errors. Booting my box leaves me to a Kernel panic with init not found. My grub config is clean and don't know why I should pass any extra kernel parameter. How can I deal with this issue? Thank you for help as my box is my working tool
On Jan 22, 2013 9:40 PM, "arnaud gaboury" <arnaud.gaboury@gmail.com> wrote:
Dear list,
testing repo is enabled on my box. Today upgrade of glibc, filesystem and Linux failed and leaves me with an unbootable machine. I boot with Archiso, then mount /, /boot and /user on /mnt/. From this directory, I then #pacman -Syu linux glibc filesystem with no success.
Get
excv unfound. I downgraded these 3 packages, then try again. It went with no errors. Booting my box leaves me to a Kernel panic with init not found. My grub config is clean and don't know why I should pass any extra kernel parameter. How can I deal with this issue?
Thank you for help as my box is my working tool
Do you get any output prior to the kernel panic? Thanks. =-Jameson
On Wed, Jan 23, 2013 at 12:26 AM, Jameson <imntreal@gmail.com> wrote:
On Jan 22, 2013 9:40 PM, "arnaud gaboury" <arnaud.gaboury@gmail.com> wrote:
Thank you for help as my box is my working tool
O_o You should'n do that, you know... As Jameson said, what are the logs? I didn't fully understand if you can or you cannot access your system after downgrading. If so please check your journal's log: # journalctl Also a dmesg could be useful.
On Jan 23, 2013 5:20 AM, "Martín Cigorraga" <msx@archlinux.us> wrote:
On Wed, Jan 23, 2013 at 12:26 AM, Jameson <imntreal@gmail.com> wrote:
On Jan 22, 2013 9:40 PM, "arnaud gaboury" <arnaud.gaboury@gmail.com> wrote:
Thank you for help as my box is my working tool
O_o You should'n do that, you know...
As Jameson said, what are the logs? I didn't fully understand if you can or you cannot access your system
after
downgrading. If so please check your journal's log: # journalctl Also a dmesg could be useful.
Good morning guys, Let me clarify a few things. 1- I didn't correctly understand the post from Allan about toolchain, thus my brocken update when #pacman - S filesystem 2- As a newbye, I usually pay lots attention to upgrades and this is my first serious issue. It was late and was totally under heavy stress. This lead me to some mistakes I realized this morning. 3-on Archiso, I mounted the wrong /usr (/dev/sdb4 when 3 was correct) + i didn't correctly #pacman - r with /mnt as target. So no surprise my system is borke. 4- back to Archiso this morning, I still can't #pacman - Syu filesystem glibc - r /mnt. Error: /mnt/usr/lib64 exist in filesystem. What am I supposed to do now? Thank you
Am 23.01.2013 11:10, schrieb arnaud gaboury:
Let me clarify a few things. 1- I didn't correctly understand the post from Allan about toolchain, thus my brocken update when #pacman - S filesystem
Then why do you use testing?
2- As a newbye,
Then why do you use testing?
On Wed, 23 Jan 2013 11:25:16 +0100, Thomas Bächler <thomas@archlinux.org> wrote:
Am 23.01.2013 11:10, schrieb arnaud gaboury:
Let me clarify a few things. 1- I didn't correctly understand the post from Allan about toolchain, thus my brocken update when #pacman - S filesystem
Then why do you use testing?
2- As a newbye,
Then why do you use testing?
Perhaps the OP needs a clarification. Arch Linux is a rolling release, you usually get latest software versions for a regular Arch install. For my taste sometimes the versions come to the repository too fast (at the moment I take a rest from Arch Linux, but I still recommend to use it and will use it in the future myself again). It's not comparable to testing of "release distros", were for stable releases software sometimes is outdated for the needs of some users and developers. When you are experienced using testing is helpful, to test new packages, since this would help the community. As long as you're a novice, you very unlikely will benefit from using testing. pacman -Syuu ;) Regards, Ralf
On Wed, Jan 23, 2013 at 11:44 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net>wrote:
On Wed, 23 Jan 2013 11:25:16 +0100, Thomas Bächler <thomas@archlinux.org> wrote:
Am 23.01.2013 11:10, schrieb arnaud gaboury:
Let me clarify a few things. 1- I didn't correctly understand the post from Allan about toolchain, thus my brocken update when #pacman - S filesystem
Then why do you use testing?
2- As a newbye,
Then why do you use testing?
Perhaps the OP needs a clarification. Arch Linux is a rolling release, you usually get latest software versions for a regular Arch install. For my taste sometimes the versions come to the repository too fast (at the moment I take a rest from Arch Linux, but I still recommend to use it and will use it in the future myself again). It's not comparable to testing of "release distros", were for stable releases software sometimes is outdated for the needs of some users and developers.
When you are experienced using testing is helpful, to test new packages, since this would help the community. As long as you're a novice, you very unlikely will benefit from using testing.
pacman -Syuu ;)
Regards, Ralf
Thank you Ralf, but this is my first ever serious issue when upgrading, so I will stick with dev enabled. Following Allan instructions, on Archiso, I #pacman -Qk and no missing files were returns. Then #mkinitcpio -p linux 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. Allan, I think this upgrade is worth a news, as you mentioned it this morning. I am always scare each time I run #pacman -Syu, as I know it could be tricky. I usually pay very much attention, and this particular upgrade was my first real issue leaving me with a broken system. I may think breaking/fixing our system is the only way we learn. Thank you for your great work to the Arch community. Regards.
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
On Thu, Jan 24, 2013 at 11:32:43AM +0100, Dennis Herbrich wrote:
by pacman -Ql|cut -d' ' -f2.
--quiet is our friend pacman -Qlq
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.
On Thursday 24 Jan 2013 10:21:12 arnaud gaboury wrote:
I am always scare each time I run #pacman -Syu, as I know it could be tricky. I usually pay very much attention, and this particular upgrade was my first real issue leaving me with a broken system. I may think breaking/fixing our system is the only way we learn.
I'm pretty confident I could tackle breakage, but I still avoid [testing] because I use my system for work, and troubleshooting these problems will usually take time that I can't justify. Breakage in the stable repositories is pretty rare, but manual intervention is required often enough that you gradually build skills and understanding, so you don't miss out on the learning experience. It sounds to me like it would be best for you to avoid [testing] until you feel more confident Paul
Accidentally sent this too soon; keyboard-shortcut-fail! On Thursday 24 Jan 2013 10:37:55 you wrote:
I'm pretty confident I could tackle breakage, but I still avoid [testing] because I use my system for work, and troubleshooting these problems will usually take time that I can't justify. Breakage in the stable repositories is pretty rare, but manual intervention is required often enough that you gradually build skills and understanding, so you don't miss out on the learning experience. It sounds to me like it would be best for you to avoid [testing] until you feel more confident
... in your understanding of the Archlinux tools and the system as a whole. It certainly doesn't mean you're missing out or not as 1337 or anything like that.
Paul
On Thu, 24 Jan 2013 10:21:12 +0100 arnaud gaboury <arnaud.gaboury@gmail.com> wrote:
On Wed, Jan 23, 2013 at 11:44 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net>wrote:
On Wed, 23 Jan 2013 11:25:16 +0100, Thomas Bächler <thomas@archlinux.org> wrote:
Am 23.01.2013 11:10, schrieb arnaud gaboury:
Let me clarify a few things. 1- I didn't correctly understand the post from Allan about toolchain, thus my brocken update when #pacman - S filesystem
Then why do you use testing?
2- As a newbye,
Then why do you use testing?
Perhaps the OP needs a clarification. Arch Linux is a rolling release, you usually get latest software versions for a regular Arch install. For my taste sometimes the versions come to the repository too fast (at the moment I take a rest from Arch Linux, but I still recommend to use it and will use it in the future myself again). It's not comparable to testing of "release distros", were for stable releases software sometimes is outdated for the needs of some users and developers.
When you are experienced using testing is helpful, to test new packages, since this would help the community. As long as you're a novice, you very unlikely will benefit from using testing.
pacman -Syuu ;)
Regards, Ralf
Thank you Ralf, but this is my first ever serious issue when upgrading, so I will stick with dev enabled.
Following Allan instructions, on Archiso, I #pacman -Qk and no missing files were returns. Then #mkinitcpio -p linux
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.
There is always a reason... but it's not /usr/lib64.
Allan, I think this upgrade is worth a news, as you mentioned it this morning.
I am always scare each time I run #pacman -Syu, as I know it could be tricky. I usually pay very much attention, and this particular upgrade was my first real issue leaving me with a broken system. I may think breaking/fixing our system is the only way we learn.
Thank you for your great work to the Arch community.
Regards.
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wednesday 23 Jan 2013 10:10:17 arnaud gaboury wrote:
Good morning guys,
Let me clarify a few things. 1- I didn't correctly understand the post from Allan about toolchain, thus my brocken update when #pacman - S filesystem 2- As a newbye, I usually pay lots attention to upgrades and this is my first serious issue. It was late and was totally under heavy stress. This lead me to some mistakes I realized this morning. 3-on Archiso, I mounted the wrong /usr (/dev/sdb4 when 3 was correct) + i didn't correctly #pacman - r with /mnt as target. So no surprise my system is borke. 4- back to Archiso this morning, I still can't #pacman - Syu filesystem glibc - r /mnt. Error: /mnt/usr/lib64 exist in filesystem.
What am I supposed to do now?
If you're really stuck, you can always create an empty directory, and extract the glibc package into it, and manually update the files from there. There's probably an easier way, though. Some first thoughts: have you found out what is in the existing /mnt/usr/lib64? Is it a symlink, or a real directory? What package owns the files that are in there? Paul
On Jan 23, 2013 12:04 PM, "Paul Gideon Dann" <pdgiddie@gmail.com> wrote: > > On Wednesday 23 Jan 2013 10:10:17 arnaud gaboury wrote: > > Good morning guys, > > > > Let me clarify a few things. > > 1- I didn't correctly understand the post from Allan about toolchain, thus > > my brocken update when #pacman - S filesystem > > 2- As a newbye, I usually pay lots attention to upgrades and this is my > > first serious issue. It was late and was totally under heavy stress. This > > lead me to some mistakes I realized this morning. > > 3-on Archiso, I mounted the wrong /usr (/dev/sdb4 when 3 was correct) + i > > didn't correctly #pacman - r with /mnt as target. So no surprise my system > > is borke. > > 4- back to Archiso this morning, I still can't #pacman - Syu filesystem > > glibc - r /mnt. Error: /mnt/usr/lib64 exist in filesystem. > > > > What am I supposed to do now? > > If you're really stuck, you can always create an empty directory, and extract > the glibc package into it, and manually update the files from there. There's > probably an easier way, though. > > Some first thoughts: have you found out what is in the existing > /mnt/usr/lib64? Is it a symlink, or a real directory? What package owns the > files that are in there? > > Paul I finally managed to finish the upgrade on Archiso by removing /mnt/usr/lib64 after I checked #pacman - Qo for each file/symlink. They all were not owned by any package. Now booting to my system still give me a Kernel panic. Not syncing No init found. Same when using fallback. It sounds to me my initramfa is broken. How shall I fix this issue?
On Wed, Jan 23, 2013 at 2:07 PM, arnaud gaboury <arnaud.gaboury@gmail.com> wrote:
I finally managed to finish the upgrade on Archiso by removing /mnt/usr/lib64 after I checked #pacman - Qo for each file/symlink. They all were not owned by any package. Now booting to my system still give me a Kernel panic. Not syncing No init found. Same when using fallback. It sounds to me my initramfa is broken.
How shall I fix this issue?
Maybe this can help https://wiki.archlinux.org/index.php/Kernel_Panics or, into ArchISO, change root (https://wiki.archlinux.org/index.php/Change_Root#Change_root) and execute: mkinitcpio -p linux -- $(Figue)
On Wed, Jan 23, 2013 at 1:07 PM, arnaud gaboury <arnaud.gaboury@gmail.com>wrote: > > On Jan 23, 2013 12:04 PM, "Paul Gideon Dann" <pdgiddie@gmail.com> wrote: > > > > On Wednesday 23 Jan 2013 10:10:17 arnaud gaboury wrote: > > > Good morning guys, > > > > > > Let me clarify a few things. > > > 1- I didn't correctly understand the post from Allan about toolchain, > thus > > > my brocken update when #pacman - S filesystem > > > 2- As a newbye, I usually pay lots attention to upgrades and this is > my > > > first serious issue. It was late and was totally under heavy stress. > This > > > lead me to some mistakes I realized this morning. > > > 3-on Archiso, I mounted the wrong /usr (/dev/sdb4 when 3 was correct) > + i > > > didn't correctly #pacman - r with /mnt as target. So no surprise my > system > > > is borke. > > > 4- back to Archiso this morning, I still can't #pacman - Syu filesystem > > > glibc - r /mnt. Error: /mnt/usr/lib64 exist in filesystem. > > > > > > What am I supposed to do now? > > > > If you're really stuck, you can always create an empty directory, and > extract > > the glibc package into it, and manually update the files from there. > There's > > probably an easier way, though. > > > > Some first thoughts: have you found out what is in the existing > > /mnt/usr/lib64? Is it a symlink, or a real directory? What package > owns the > > files that are in there? > > > > Paul > > I finally managed to finish the upgrade on Archiso by removing > /mnt/usr/lib64 after I checked #pacman - Qo for each file/symlink. They all > were not owned by any package. > Now booting to my system still give me a Kernel panic. Not syncing No init > found. Same when using fallback. > It sounds to me my initramfa is broken. > > How shall I fix this issue? > My issue maybe comes from the upgrade of glibc 2.17-2 from testing. I have now /lib --> usr/lib and lib64/ ----> usr/lib. /usr/lib64 ----> lib Is this the expected structure after the upgrade ?
On 24/01/13 00:08, arnaud gaboury wrote:
My issue maybe comes from the upgrade of glibc 2.17-2 from testing. I have now /lib --> usr/lib and lib64/ ----> usr/lib. /usr/lib64 ----> lib
Is this the expected structure after the upgrade ?
Yes Give the complete package list of what was upgraded. Allan
On Wed, Jan 23, 2013 at 2:12 PM, Allan McRae <allan@archlinux.org> wrote:
On 24/01/13 00:08, arnaud gaboury wrote:
My issue maybe comes from the upgrade of glibc 2.17-2 from testing. I have now /lib --> usr/lib and lib64/ ----> usr/lib. /usr/lib64 ----> lib
Is this the expected structure after the upgrade ?
Yes
Give the complete package list of what was upgraded.
Allan
Allan, thank your help. Please find all the pacman logs in chronoligal order with some explainations. Sorry for the long logs To summarize, I first upgraded on m system. [2013-01-22 19:38] kalu: synchronized database testing [2013-01-22 19:38] kalu: synchronized database core [2013-01-22 19:38] kalu: synchronized database extra [2013-01-22 19:38] kalu: synchronized database community-testing [2013-01-22 19:38] kalu: synchronized database community [2013-01-22 19:38] kalu: synchronized database multilib-testing [2013-01-22 19:38] kalu: synchronized database multilib [2013-01-22 19:38] kalu: starting sysupgrade... [2013-01-22 19:40] kalu: Failed to commit sysupgrade transaction: conflicting files [2013-01-22 19:43] Running 'pacman -Syu' [2013-01-22 19:43] synchronizing package lists [2013-01-22 19:43] starting full system upgrade [2013-01-22 20:04] Running 'pacman -S bash' [2013-01-22 20:05] Running 'pacman -S filesystem' [2013-01-22 20:05] Running 'pacman -S glibc' [2013-01-22 20:05] call to execv failed (No such file or directory) [2013-01-22 20:05] upgraded glibc (2.17-1 -> 2.17-2) The upgrade went bad, and I made the mistake to #pacman -S glibc. It broke immediatly my filesystem. Then I log out and boot with Ubuntu Live CD. I chroot and tried many things with no sucess. My bad, as I realized this morning I mounted the wrong /dev/sdb partition as /usr . I then boot my system on fallback. Here again, I tried to finish the upgrade with no sucess. I then boot with Archiso, and couldn-t finish as execv was not found. I then downgraded glibc and filesystem, and tried again to upgrade correctly, with no sucess. [2013-01-22 23:35] Running 'pacman -Sf filesystem' [2013-01-22 23:35] warning: directory permissions differ on home/ filesystem: 555 package: 755 [2013-01-22 23:35] error: problem occurred while upgrading filesystem [2013-01-22 23:35] upgraded filesystem (2012.12-1 -> 2013.01-1) [2013-01-22 23:35] Running 'pacman -Syu' [2013-01-22 23:35] synchronizing package lists [2013-01-22 23:35] starting full system upgrade [2013-01-22 23:36] Running 'pacman -Syu' [2013-01-22 23:36] synchronizing package lists [2013-01-22 23:36] starting full system upgrade [2013-01-22 23:37] upgraded bash (4.2.042-1 -> 4.2.042-2) [2013-01-22 23:37] upgraded icu (50.1.1-1 -> 50.1.2-1) [2013-01-22 23:37] upgraded boost-libs (1.50.0-3 -> 1.50.0-4) [2013-01-22 23:37] upgraded ca-certificates (20121105-1 -> 20130119-1) [2013-01-22 23:37] upgraded cairo (1.12.8-2 -> 1.12.10-1) [2013-01-22 23:37] upgraded firefox (18.0-2 -> 18.0.1-1) [2013-01-22 23:37] upgraded gnupg (2.0.19-3 -> 2.0.19-4) [2013-01-22 23:37] upgraded gpgme (1.3.1-4 -> 1.3.1-5) [2013-01-22 23:37] upgraded gptfdisk (0.8.5-2 -> 0.8.5-3) [2013-01-22 23:37] upgraded harfbuzz (0.9.9-2 -> 0.9.9-3) [2013-01-22 23:37] upgraded imagemagick (6.8.0.7-1 -> 6.8.1.9-1) [2013-01-22 23:37] upgraded lib32-sqlite (3.7.15.1-1 -> 3.7.15.2-1) [2013-01-22 23:37] upgraded libao (1.1.0-2 -> 1.1.0-3) [2013-01-22 23:37] upgraded libreoffice-common (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libreoffice-base (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libreoffice-calc (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libreoffice-draw (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libreoffice-gnome (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libreoffice-impress (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libreoffice-math (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libreoffice-writer (3.6.4-4 -> 3.6.4-5) [2013-01-22 23:37] upgraded libtracker-sparql (0.14.4-2 -> 0.14.4-3) [2013-01-22 23:37] upgraded libxi (1.6.1-1 -> 1.6.2-1) [2013-01-22 23:37] >>> Updating module dependencies. Please wait ... [2013-01-22 23:37] >>> Generating initial ramdisk, using mkinitcpio. Please wait... [2013-01-22 23:37] ==> Building image from preset: 'default' [2013-01-22 23:37] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img [2013-01-22 23:37] ==> Starting build: 3.7.4-1-ARCH [2013-01-22 23:37] -> Running build hook: [base] [2013-01-22 23:37] -> Running build hook: [udev] [2013-01-22 23:37] -> Running build hook: [autodetect] [2013-01-22 23:37] -> Running build hook: [block] [2013-01-22 23:37] -> Running build hook: [lvm2] [2013-01-22 23:37] -> Running build hook: [filesystems] [2013-01-22 23:37] -> Running build hook: [fsck] [2013-01-22 23:37] ==> ERROR: file not found: `fsck.btrfs' [2013-01-22 23:37] ==> WARNING: No fsck helpers found. fsck will not be run on boot. [2013-01-22 23:37] -> Running build hook: [usr] [2013-01-22 23:37] -> Running build hook: [usbinput] [2013-01-22 23:37] -> Running build hook: [shutdown] [2013-01-22 23:37] -> Running build hook: [modconf] [2013-01-22 23:37] ==> Generating module dependencies [2013-01-22 23:37] ==> Creating gzip initcpio image: /boot/initramfs-linux.img [2013-01-22 23:37] ==> WARNING: errors were encountered during the build. The image may not be complete. [2013-01-22 23:37] ==> Building image from preset: 'fallback' [2013-01-22 23:37] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect [2013-01-22 23:37] ==> Starting build: 3.7.4-1-ARCH [2013-01-22 23:37] -> Running build hook: [base] [2013-01-22 23:37] -> Running build hook: [udev] [2013-01-22 23:37] -> Running build hook: [block] [2013-01-22 23:37] -> Running build hook: [lvm2] [2013-01-22 23:37] -> Running build hook: [filesystems] [2013-01-22 23:37] -> Running build hook: [fsck] [2013-01-22 23:37] -> Running build hook: [usr] [2013-01-22 23:37] -> Running build hook: [usbinput] [2013-01-22 23:37] -> Running build hook: [shutdown] [2013-01-22 23:37] -> Running build hook: [modconf] [2013-01-22 23:37] ==> Generating module dependencies [2013-01-22 23:37] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img [2013-01-22 23:37] ==> Image generation successful [2013-01-22 23:37] upgraded linux (3.7.2-1 -> 3.7.4-1) [2013-01-22 23:37] upgraded linux-api-headers (3.7.1-1 -> 3.7.4-1) [2013-01-22 23:37] upgraded linux-headers (3.7.2-1 -> 3.7.4-1) [2013-01-22 23:37] upgraded nettle (2.5-1 -> 2.6-1) [2013-01-22 23:37] upgraded python2-simplejson (2.6.2-1 -> 3.0.7-2) [2013-01-22 23:37] upgraded qt (4.8.4-1 -> 4.8.4-2) [2013-01-22 23:37] upgraded qtwebkit (2.3git20130115-1 -> 2.3.beta1-1) [2013-01-22 23:37] upgraded raptor (2.0.8-2 -> 2.0.8-3) [2013-01-22 23:37] upgraded ruby (1.9.3_p362-1 -> 1.9.3_p374-1) [2013-01-22 23:37] upgraded webkitgtk2 (1.10.2-1 -> 1.10.2-2) [2013-01-22 23:37] upgraded weechat (0.3.9.2-4 -> 0.4.0-1) [2013-01-22 23:37] upgraded wpa_supplicant (1.0-2 -> 2.0-1) [2013-01-22 23:37] Running 'pacman -Syu glibc' [2013-01-22 23:37] synchronizing package lists [2013-01-22 23:37] starting full system upgrade [2013-01-22 23:38] Generating locales... [2013-01-22 23:38] en_US.UTF-8... done [2013-01-22 23:38] fr_CH.UTF-8... done [2013-01-22 23:38] fr_FR.UTF-8... done [2013-01-22 23:38] fr_FR.ISO-8859-15@euro... done [2013-01-22 23:38] Generation complete. [2013-01-22 23:38] upgraded glibc (2.17-2 -> 2.17-2) [2013-01-22 23:42] Running 'pacman -Syu -r /mnt/arch glibc filesystem linux' [2013-01-22 23:42] synchronizing package lists [2013-01-22 23:45] Running 'pacman -Syu -r /mnt/arch glibc filesystem linux' [2013-01-22 23:45] synchronizing package lists [2013-01-22 23:45] starting full system upgrade Finally this morning I managed to finish everything. BUT I still can not boot in my Arch. [2013-01-23 09:21] Running 'pacman -Syy -r /mnt' [2013-01-23 09:21] synchronizing package lists [2013-01-23 09:28] Running 'pacman -Syu -r /mnt linux glibc filesystem' [2013-01-23 09:28] synchronizing package lists [2013-01-23 09:28] starting full system upgrade [2013-01-23 09:29] >>> Updating module dependencies. Please wait ... [2013-01-23 09:29] >>> Generating initial ramdisk, using mkinitcpio. Please wait... [2013-01-23 09:29] ==> ERROR: /proc must be mounted! [2013-01-23 09:29] upgraded linux (3.7.4-1 -> 3.7.4-1) [2013-01-23 09:29] Generating locales... [2013-01-23 09:29] en_US.UTF-8... done [2013-01-23 09:29] fr_CH.UTF-8... done [2013-01-23 09:29] fr_FR.UTF-8... done [2013-01-23 09:29] fr_FR.ISO-8859-15@euro... done [2013-01-23 09:29] Generation complete. [2013-01-23 09:29] upgraded glibc (2.17-2 -> 2.17-2) [2013-01-23 09:29] error: problem occurred while upgrading filesystem [2013-01-23 09:29] upgraded filesystem (2013.01-1 -> 2013.01-1) [2013-01-23 09:31] Running 'pacman -Syu -r /mnt linux glibc filesystem' [2013-01-23 09:31] synchronizing package lists [2013-01-23 09:31] starting full system upgrade [2013-01-23 09:32] >>> Updating module dependencies. Please wait ... [2013-01-23 09:32] >>> Generating initial ramdisk, using mkinitcpio. Please wait... [2013-01-23 09:32] ==> Building image from preset: 'default' [2013-01-23 09:32] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img [2013-01-23 09:32] ==> Starting build: 3.7.4-1-ARCH [2013-01-23 09:32] -> Running build hook: [base] [2013-01-23 09:32] -> Running build hook: [udev] [2013-01-23 09:32] -> Running build hook: [autodetect] [2013-01-23 09:32] -> Running build hook: [block] [2013-01-23 09:32] -> Running build hook: [lvm2] [2013-01-23 09:32] -> Running build hook: [filesystems] [2013-01-23 09:32] -> Running build hook: [fsck] [2013-01-23 09:32] ==> ERROR: file not found: `fsck.btrfs' [2013-01-23 09:32] ==> WARNING: No fsck helpers found. fsck will not be run on boot. [2013-01-23 09:32] -> Running build hook: [usr] [2013-01-23 09:32] -> Running build hook: [usbinput] [2013-01-23 09:32] -> Running build hook: [shutdown] [2013-01-23 09:32] -> Running build hook: [modconf] [2013-01-23 09:32] ==> Generating module dependencies [2013-01-23 09:32] ==> Creating gzip initcpio image: /boot/initramfs-linux.img [2013-01-23 09:32] ==> WARNING: errors were encountered during the build. The image may not be complete. [2013-01-23 09:32] ==> Building image from preset: 'fallback' [2013-01-23 09:32] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect [2013-01-23 09:32] ==> Starting build: 3.7.4-1-ARCH [2013-01-23 09:32] -> Running build hook: [base] [2013-01-23 09:32] -> Running build hook: [udev] [2013-01-23 09:32] -> Running build hook: [block] [2013-01-23 09:32] -> Running build hook: [lvm2] [2013-01-23 09:32] -> Running build hook: [filesystems] [2013-01-23 09:32] -> Running build hook: [fsck] [2013-01-23 09:32] -> Running build hook: [usr] [2013-01-23 09:32] -> Running build hook: [usbinput] [2013-01-23 09:32] -> Running build hook: [shutdown] [2013-01-23 09:32] -> Running build hook: [modconf] [2013-01-23 09:32] ==> Generating module dependencies [2013-01-23 09:32] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img [2013-01-23 09:32] ==> Image generation successful [2013-01-23 09:32] upgraded linux (3.7.4-1 -> 3.7.4-1) [2013-01-23 09:32] Generating locales... [2013-01-23 09:32] en_US.UTF-8... done [2013-01-23 09:32] fr_CH.UTF-8... done [2013-01-23 09:32] fr_FR.UTF-8... done [2013-01-23 09:32] fr_FR.ISO-8859-15@euro... done [2013-01-23 09:32] Generation complete. [2013-01-23 09:32] upgraded glibc (2.17-2 -> 2.17-2) [2013-01-23 09:32] error: problem occurred while upgrading filesystem [2013-01-23 09:32] upgraded filesystem (2013.01-1 -> 2013.01-1) [2013-01-23 09:32] Running 'pacman -Syu -r /mnt linux' [2013-01-23 09:32] synchronizing package lists [2013-01-23 09:32] starting full system upgrade [2013-01-23 09:32] >>> Updating module dependencies. Please wait ... [2013-01-23 09:32] >>> Generating initial ramdisk, using mkinitcpio. Please wait... [2013-01-23 09:32] ==> Building image from preset: 'default' [2013-01-23 09:32] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img [2013-01-23 09:32] ==> Starting build: 3.7.4-1-ARCH [2013-01-23 09:32] -> Running build hook: [base] [2013-01-23 09:32] -> Running build hook: [udev] [2013-01-23 09:32] -> Running build hook: [autodetect] [2013-01-23 09:32] -> Running build hook: [block] [2013-01-23 09:32] -> Running build hook: [lvm2] [2013-01-23 09:32] -> Running build hook: [filesystems] [2013-01-23 09:32] -> Running build hook: [fsck] [2013-01-23 09:32] ==> ERROR: file not found: `fsck.btrfs' [2013-01-23 09:32] ==> WARNING: No fsck helpers found. fsck will not be run on boot. [2013-01-23 09:32] -> Running build hook: [usr] [2013-01-23 09:32] -> Running build hook: [usbinput] [2013-01-23 09:32] -> Running build hook: [shutdown] [2013-01-23 09:32] -> Running build hook: [modconf] [2013-01-23 09:32] ==> Generating module dependencies [2013-01-23 09:32] ==> Creating gzip initcpio image: /boot/initramfs-linux.img [2013-01-23 09:32] ==> WARNING: errors were encountered during the build. The image may not be complete. [2013-01-23 09:32] ==> Building image from preset: 'fallback' [2013-01-23 09:32] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect [2013-01-23 09:32] ==> Starting build: 3.7.4-1-ARCH [2013-01-23 09:32] -> Running build hook: [base] [2013-01-23 09:32] -> Running build hook: [udev] [2013-01-23 09:32] -> Running build hook: [block] [2013-01-23 09:32] -> Running build hook: [lvm2] [2013-01-23 09:32] -> Running build hook: [filesystems] [2013-01-23 09:32] -> Running build hook: [fsck] [2013-01-23 09:32] -> Running build hook: [usr] [2013-01-23 09:32] -> Running build hook: [usbinput] [2013-01-23 09:32] -> Running build hook: [shutdown] [2013-01-23 09:32] -> Running build hook: [modconf] [2013-01-23 09:32] ==> Generating module dependencies [2013-01-23 09:32] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img [2013-01-23 09:33] ==> Image generation successful [2013-01-23 09:33] upgraded linux (3.7.4-1 -> 3.7.4-1) [2013-01-23 09:33] Running 'pacman -Syu -r /mnt filesystem' [2013-01-23 09:33] synchronizing package lists [2013-01-23 09:33] starting full system upgrade [2013-01-23 09:33] error: problem occurred while upgrading filesystem [2013-01-23 09:33] upgraded filesystem (2013.01-1 -> 2013.01-1) [2013-01-23 09:33] Running 'pacman -Sf -r /mnt filesystem' [2013-01-23 09:33] error: problem occurred while upgrading filesystem [2013-01-23 09:33] upgraded filesystem (2013.01-1 -> 2013.01-1) [2013-01-23 09:37] Running 'pacman -U -r /mnt ./glibc-2.17-1-x86_64.pkg.tar.xz' [2013-01-23 09:38] Running 'pacman -U -r /mnt ./glibc-2.17-1-x86_64.pkg.tar.xz' [2013-01-23 09:39] Running 'pacman -U -r /mnt ./glibc-2.17-1-x86_64.pkg.tar.xz' [2013-01-23 09:39] Generating locales... [2013-01-23 09:39] en_US.UTF-8... done [2013-01-23 09:39] fr_CH.UTF-8... done [2013-01-23 09:39] fr_FR.UTF-8... done [2013-01-23 09:39] fr_FR.ISO-8859-15@euro... done [2013-01-23 09:39] Generation complete. [2013-01-23 09:39] upgraded glibc (2.17-2 -> 2.17-1) [2013-01-23 09:40] Running 'pacman -U -r /mnt ./filesystem-2012.12-1-any.pkg.tar.xz' [2013-01-23 09:40] call to execv failed (No such file or directory) [2013-01-23 09:40] upgraded filesystem (2013.01-1 -> 2012.12-1) [2013-01-23 09:42] Running 'pacman -U -r /mnt ./filesystem-2012.12-1-any.pkg.tar.xz' [2013-01-23 09:42] call to execv failed (No such file or directory) [2013-01-23 09:42] upgraded filesystem (2012.12-1 -> 2012.12-1) [2013-01-23 09:43] Running 'pacman -Syu -r /mnt filesystem glibc' [2013-01-23 09:43] synchronizing package lists [2013-01-23 09:43] starting full system upgrade [2013-01-23 09:45] Running 'pacman -Syu -r /mnt filesystem glibc' [2013-01-23 09:45] synchronizing package lists [2013-01-23 09:45] starting full system upgrade [2013-01-23 10:08] Running 'pacman -Syu -r /mnt filesystem glibc' [2013-01-23 10:08] synchronizing package lists [2013-01-23 10:08] starting full system upgrade [2013-01-23 12:45] Running 'pacman -Syu -r /mnt filesystem glibc' [2013-01-23 12:45] synchronizing package lists [2013-01-23 12:45] starting full system upgrade [2013-01-23 12:45] upgraded filesystem (2012.12-1 -> 2013.01-1) [2013-01-23 12:45] Generating locales... [2013-01-23 12:45] en_US.UTF-8... done [2013-01-23 12:45] fr_CH.UTF-8... done [2013-01-23 12:45] fr_FR.UTF-8... done [2013-01-23 12:45] fr_FR.ISO-8859-15@euro... done [2013-01-23 12:45] Generation complete. [2013-01-23 12:45] upgraded glibc (2.17-1 -> 2.17-2) [2013-01-23 12:45] upgraded cairo (1.12.10-1 -> 1.12.10-2) [2013-01-23 12:45] upgraded cracklib (2.8.19-1 -> 2.8.22-1) [2013-01-23 14:48] Running 'pacman -Syu' [2013-01-23 14:48] synchronizing package lists [2013-01-23 14:48] starting full system upgrade [2013-01-23 15:03] Running 'pacman -Syu glibc filesystem' [2013-01-23 15:03] synchronizing package lists [2013-01-23 15:03] starting full system upgrade [2013-01-23 15:03] Generating locales... [2013-01-23 15:03] en_US.UTF-8... done [2013-01-23 15:03] fr_CH.UTF-8... done [2013-01-23 15:03] fr_FR.UTF-8... done [2013-01-23 15:03] fr_FR.ISO-8859-15@euro... done [2013-01-23 15:03] Generation complete. [2013-01-23 15:03] upgraded glibc (2.17-2 -> 2.17-2) [2013-01-23 15:03] warning: directory permissions differ on sys/ filesystem: 755 package: 555 [2013-01-23 15:03] upgraded filesystem (2013.01-1 -> 2013.01-1)
On 24/01/13 00:29, arnaud gaboury wrote:
On Wed, Jan 23, 2013 at 2:12 PM, Allan McRae <allan@archlinux.org> wrote:
On 24/01/13 00:08, arnaud gaboury wrote:
My issue maybe comes from the upgrade of glibc 2.17-2 from testing. I have now /lib --> usr/lib and lib64/ ----> usr/lib. /usr/lib64 ----> lib
Is this the expected structure after the upgrade ?
Yes
Give the complete package list of what was upgraded.
Allan
Allan,
thank your help. Please find all the pacman logs in chronoligal order with some explainations. Sorry for the long logs To summarize, I first upgraded on m system.
[2013-01-22 19:38] kalu: synchronized database testing [2013-01-22 19:38] kalu: synchronized database core [2013-01-22 19:38] kalu: synchronized database extra [2013-01-22 19:38] kalu: synchronized database community-testing [2013-01-22 19:38] kalu: synchronized database community [2013-01-22 19:38] kalu: synchronized database multilib-testing [2013-01-22 19:38] kalu: synchronized database multilib [2013-01-22 19:38] kalu: starting sysupgrade... [2013-01-22 19:40] kalu: Failed to commit sysupgrade transaction: conflicting files [2013-01-22 19:43] Running 'pacman -Syu' [2013-01-22 19:43] synchronizing package lists [2013-01-22 19:43] starting full system upgrade [2013-01-22 20:04] Running 'pacman -S bash' [2013-01-22 20:05] Running 'pacman -S filesystem' [2013-01-22 20:05] Running 'pacman -S glibc' [2013-01-22 20:05] call to execv failed (No such file or directory) [2013-01-22 20:05] upgraded glibc (2.17-1 -> 2.17-2)
So there was a file conflict - not sure what, but for next time, just deal with that...
The upgrade went bad, and I made the mistake to #pacman -S glibc. It broke immediatly my filesystem. Then I log out and boot with Ubuntu Live CD. I chroot and tried many things with no sucess. My bad, as I realized this morning I mounted the wrong /dev/sdb partition as /usr . I then boot my system on fallback. Here again, I tried to finish the upgrade with no sucess. I then boot with Archiso, and couldn-t finish as execv was not found. I then downgraded glibc and filesystem, and tried again to upgrade correctly, with no sucess.
<snip> That is a lot of going around in circles... Make sure everything is updated, then run "pacman -Qk -r /mnt" to check all the files are ready. It seems you are using the Arch install CD, so run "arch-chroot /mnt" then "mkinitcpio -p linux". Then try booting. We need some details of what is happening when it fails to give any more help. Allan
participants (11)
-
Alessandro Doro
-
Allan McRae
-
arnaud gaboury
-
Dennis Herbrich
-
Figue
-
Jameson
-
Leonid Isaev
-
Martín Cigorraga
-
Paul Gideon Dann
-
Ralf Mardorf
-
Thomas Bächler