You are not logged in.
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
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
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
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.
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.
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
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:
Running "pacman-key --init" takes a long time to finish. I tried to took the advice I found in the forum/wiki, which are:
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
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"
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?
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
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.
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
Thanks headkase and Trilby, the problem is largely solved now. Well except the VBox/Arch guest crash thing.
Offline