You are not logged in.

#1 2012-05-29 17:18:51

jarhead70
Member
Registered: 2012-05-29
Posts: 7

[Solved] Failed to commint transaction when updating Pacman

Hi,

I'm following the "Unofficial Beginners' Guide" to install Arch under VirtualBox. The install process was fine, but when it come to the updating the system step, Pacman won't update. After issuing "pacman -Syu", Pacman request to update itself, which I allow. Then after successfully downloading the necessary packages, I got this:

(14/14) checking package integrity  100%
(14/14) checking for file conflicts  100%
error: failed to commit transaction (conflicting files)
glibc: /usr/bin/tzselect exists in filesystem
glibc: /usr/sbin/zdump exists in filesystem
glibc: /usr/sbin/zic exists in filesystem
Errors occured, no packages were upgraded

The only thing extra I selected is the package selection step of the installation is "zlib", and prior to issuing the "pacman -Syu" command, I did these things per the Guide's instruction:

pacman -Syy
pacman -S filesystem --force
rm /etc/profile.d/locale.sh

Note: when updating the filesystem, pacman also ask to upgrade, which also failed, which I retry and this time I said no to upgrade itself.

How can I resolve this issue?

Thanks

PS: The guide also said to temporarily edit "/etc/pacman.conf" file and set "SigLevel" to "Never", however I can't find the corresponding line in the file, so I skipped it. Has this any effect on my current problem?

Last edited by jarhead70 (2012-06-08 18:38:04)

Offline

#2 2012-05-29 17:27:11

headkase
Member
Registered: 2011-12-06
Posts: 1,983

Re: [Solved] Failed to commint transaction when updating Pacman

You can find out which package owns the file by doing:

pacman -Qo /path/to/file

So,

pacman -Qo /usr/bin/tzselect

and repeat for the other files.

Then post which package owns the files here in your thread.

Offline

#3 2012-05-29 17:28:50

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 30,330
Website

Re: [Solved] Failed to commint transaction when updating Pacman

Welcome to the forums.  Given the title I thought I was going to hate this post, but you've done your homework and seem to have done all the proper trouble shooting steps.

First, the "saying no" to the pacman update was the right step at that point.  Allegedly this option will be removed and default to NO in future versions.

Next, the SigLevel business is not relevant for this problem.  Those lines do not exist yet because they are new with the upgrade of pacman which hasn't been completed on your system yet.  Also the errors would be different.

At least some of those may be do to the extra package you added during the install, but something went wrong for it not to be listed in the pacman database.

The next step in trouble shooting would be to run

pacman -Qo /usr/bin/tzselect

and similar for each of those files.  Odds are it will report that they are not owned by any package, but this should be checked first.

A generally good step in such situations is to move/rename the existing conflicting files to /usr/bin/tzselect.bak or something else memorable.  Then the update should go fine and if there are no problems, the .bak files could be deleted.


"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman

Offline

#4 2012-05-29 21:33:51

jarhead70
Member
Registered: 2012-05-29
Posts: 7

Re: [Solved] Failed to commint transaction when updating Pacman

Trilby wrote:

Welcome to the forums.  Given the title I thought I was going to hate this post, but you've done your homework and seem to have done all the proper trouble shooting steps.

Thanks. I found ArchWiki is superbly written, more so than any other distro wiki I've looked at. Might be because Arch's underlying philosophy.

headkase wrote:

You can find out which package owns the file by doing:

pacman -Qo /path/to/file

So,

pacman -Qo /usr/bin/tzselect

and repeat for the other files.

Then post which package owns the files here in your thread.

Trilby wrote:

The next step in trouble shooting would be to run

pacman -Qo /usr/bin/tzselect

and similar for each of those files.  Odds are it will report that they are not owned by any package, but this should be checked first.

Here's the output for each files:

pacman -Qo /usr/bin/tzselect
/usr/bin/tzselect is owned by tzdata 2011h-1

pacman -Qo /usr/sbin/zdump
/usr/sbin/zdump is owned by tzdata 2011h-1

pacman -Qo /usr/sbin/zic
/usr/sbin/zic is owned by tzdata 2011h-1
Trilby wrote:

A generally good step in such situations is to move/rename the existing conflicting files to /usr/bin/tzselect.bak or something else memorable.  Then the update should go fine and if there are no problems, the .bak files could be deleted.

At first I'm inclined to remove the "tzdata" package altogether, but upon checking the site's Package Database, it listed there that it's used for "glibc" and "archboot", so I did what you've suggested instead, renaming the offending files. The update now works.

There's slight problems after that:

  1. Running "pacman-key --init" takes a long time to finish. I tried to took the advice I found in the forum/wiki, which are:

    1. Waving the mouse and/or typing something, still take very long; actually at one instance doing that in another TTY (TTY-2) made VirtualBox crash

    2. Install "mg-tools" and made some modifications to the conf file, but I can't find the "mg-tools" package; "pacman -S mg-tools" returns error "no such package"

    3. Make a large file by issuing "dd if=/dev/zero of=file.txt count=1024 bs=1000000" which said make initializing pacman-key finish after 30s or so, but in my case it didn't

    Are there anyways to speed up the process?

  2. While running "pacman -Syu", VirtualBox also crash several times. I can resume the process after rebooting the VM, but I wonder why it happens. I suspected that the screensaver (Arch's, not the host system) interfere with pacman operations. In the last run, I pressed spacebar intermittently to stop the screensaver from kicking in, and the system updated successfully. Is there anyway I can control when the screensaver kicks in?

There's also this error when booting/initializing udev:

SMBus base address uninitialized - upgrade bios or use force_addr=0xaddr

Can it be it effect no #2 of the above?

Thanks

Offline

#5 2012-05-29 21:44:57

headkase
Member
Registered: 2011-12-06
Posts: 1,983

Re: [Solved] Failed to commint transaction when updating Pacman

In VirtualBox with an Arch guest,

For "SMBus base address..":

cd /etc/modprobe.d/
sudo nano piix.conf

In that file:

blacklist i2c_piix4

Control+o to write changes, Control+x to quit.

Regenerate your initial ramdisk:

sudo mkinitcpio -p linux

That will prevent the message from appearing.  It is only cosmetic however, you don't really need to do that but it doesn't hurt.

As for VirtualBox crashing?  My experience with it and Arch guests is that it just does that.  Randomly.  Bleeping thing. wink

For the files being in the system and conflicting in the first place?  Whenever I install Arch I always do the net-install.  Instead of choosing "core-local" choose "core-remote."  Not only do you download the latest packages to start off your system but also there are very fewer issues when creating your initial system that way as you bypass most of the advisories simply by starting from the get-go with the newest packages.

Last edited by headkase (2012-05-29 21:59:37)

Offline

#6 2012-06-08 18:40:10

jarhead70
Member
Registered: 2012-05-29
Posts: 7

Re: [Solved] Failed to commint transaction when updating Pacman

Thanks headkase and Trilby, the problem is largely solved now. Well except the VBox/Arch guest crash thing.

Offline

Board footer

Powered by FluxBB