unable to update packages

jerryDaBaaws · 2023-08-26 09:49:59

I left my pc unused for a month or so, I performed a system update once i come back ,
and almost on every package, I am getting errors that files related to that package already exist in file system.

i can use -- overwrite "*" to solve the error the update for that package, but this is now happening with every unupdated package which got an update .

as per arch wiki, reinstalling every package with overwrite should not be done, and should be a last resort only, any other way i can solve it ?

also sometimes i get this error as well

ldconfig: /usr/lib/libproxy.so.1 is not a symbolic link

Last edited by jerryDaBaaws (2023-08-26 10:14:56)

schard · 2023-08-26 10:14:58

Show us your pacman log, please.

jerryDaBaaws · 2023-08-26 10:17:58

https://gist.github.com/Iss-in/f93aac05 … 37ed3154df

created a gist since its too big

Last edited by jerryDaBaaws (2023-08-26 10:18:23)

dogknowsnx · 2023-08-26 10:36:23

FYI

schard · 2023-08-26 10:37:30

Those logs only go up until March.
If you have problems with the file size, try uploading to http://ix.io/ as described on that site.

jerryDaBaaws · 2023-08-26 10:42:11

last log is till 2023-02-14 , and this issue definitely happened a few months after it

i just tried updating devtools , and getting the same error

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (22) apr-1.7.3-1  apr-util-1.6.3-1  arch-install-scripts-28-1  breezy-3.3.3-1  fakeroot-1.32.1-1  jq-1.6-4  libutf8proc-2.8.0-1  libyaml-0.2.5-2  mercurial-6.5.1-1  oniguruma-6.9.8-1  parallel-20230822-1  procps-ng-4.0.3-1
              python-configobj-5.0.8-4  python-dulwich-0.21.5-1  python-fastbencode-0.2-2  python-merge3-0.0.13-2  python-patiencediff-0.2.13-2  python-urllib3-1.26.15-1  python-yaml-6.0.1-2  serf-1.3.9-8  subversion-1.14.2-9  devtools-1:1.0.3-2

Total Installed Size:  149.52 MiB

:: Proceed with installation? [Y/n] 
(22/22) checking keys in keyring                                                                                                                         [##############################################################################################] 100%
(22/22) checking package integrity                                                                                                                       [##############################################################################################] 100%
(22/22) loading package files                                                                                                                            [##############################################################################################] 100%
(22/22) checking for file conflicts                                                                                                                      [##############################################################################################] 100%
error: failed to commit transaction (conflicting files)
fakeroot: /etc/ld.so.conf.d/fakeroot.conf exists in filesystem
fakeroot: /usr/bin/faked exists in filesystem
fakeroot: /usr/bin/fakeroot exists in filesystem
fakeroot: /usr/lib/libfakeroot/libfakeroot-0.so exists in filesystem
fakeroot: /usr/lib/libfakeroot/libfakeroot.so exists in filesystem
fakeroot: /usr/share/doc/fakeroot/README exists in filesystem
fakeroot: /usr/share/man/de/man1/faked.1.gz exists in filesystem
fakeroot: /usr/share/man/de/man1/fakeroot.1.gz exists in filesystem
fakeroot: /usr/share/man/es/man1/faked.1.gz exists in filesystem
fakeroot: /usr/share/man/es/man1/fakeroot.1.gz exists in filesystem
fakeroot: /usr/share/man/fr/man1/faked.1.gz exists in filesystem
fakeroot: /usr/share/man/fr/man1/fakeroot.1.gz exists in filesystem
fakeroot: /usr/share/man/man1/faked.1.gz exists in filesystem
fakeroot: /usr/share/man/man1/fakeroot.1.gz exists in filesystem
fakeroot: /usr/share/man/nl/man1/faked.1.gz exists in filesystem
fakeroot: /usr/share/man/nl/man1/fakeroot.1.gz exists in filesystem
fakeroot: /usr/share/man/pt/man1/faked.1.gz exists in filesystem
fakeroot: /usr/share/man/pt/man1/fakeroot.1.gz exists in filesystem
fakeroot: /usr/share/man/sv/man1/faked.1.gz exists in filesystem
...
and so on

but in pacman logs , all ive for this operation is

[2023-08-26T16:13:17+0530] [PACMAN] starting full system upgrade
[2023-08-26T16:14:08+0530] [PACMAN] Running 'pacman -Syu devtools>=1:1.0.0-1'
[2023-08-26T16:14:08+0530] [PACMAN] synchronizing package lists

Last edited by jerryDaBaaws (2023-08-26 10:46:14)

seth · 2023-08-26 12:30:58

If you're running pacman now and get entries in the log, why does the provided log stop in march?

cat /var/log/pacman.log | curl -F 'file=@-' 0x0.st

jerryDaBaaws · 2023-08-28 18:14:55

not sure about that part, but this problem def just started in last 2 months only

http://0x0.st/H9Rt.txt

also, os install was done in mid feb

Last edited by jerryDaBaaws (2023-08-28 18:19:35)

Trilby · 2023-08-28 18:51:29

You had successful updates on the 23rd and 25th. And perhaps one after that just updating one package. So what's the problem?

You also started using yay right from the start which I would strongly advise against, though I see no real reason to conclude that yay is related to the one actual error about libproxy. You should reinstall libproxy with an overwrite flag for that one specific file.

EDIT: oops I misread - I wrongly inferred that updates were failing (edit 2, this is what the thread title says). But you are getting a lot of file exists errors when an update succeeds. Please post the complete output from a system update with pacman.

Last edited by Trilby (2023-08-28 18:54:44)

seth · 2023-08-28 19:04:49

Also "pacman -Qikk fakeroot", I assume you always get /that/ error about file collisions in fakeroot - which was installed on [2023-02-14T07:53:16+0000], the day where you suspected your logs end (while they don't) and has no update in the repos since.

This is gonna be some yay issue.

jerryDaBaaws · 2023-08-30 15:03:09

most likely its a yay error now i presume, pacman full update completed successfully without any issue

also weirdly theres no fakeroot package, but when i try to install it via pacman , i get those old files exist in filesystem

Last edited by jerryDaBaaws (2023-08-30 15:03:48)

seth · 2023-08-30 15:07:06

Install it "--dbonly" first, then fully.

Trilby · 2023-08-30 15:30:24

I stand corrected. I already had an obscenely low opinion of yay, but it can still surprise me by just how much if can screw things up that it really shouldn't even be possible for it to screw up. It's earning a place up there with OMZ.

Last edited by Trilby (2023-08-30 15:31:30)

seth · 2023-08-30 15:44:49

base-devel is an implicit dependency of the AUR. yay probably wants to build some AUR package and unconditionally installs base-devel, this will cause an attempt to install fakeroot (as the package isn't in the database) and that runs into the file collisions.
It's not clear whether yay is responsible for the database corruption; but while the above is speculation, it's not the dumbest thing an AUR helper might do.

jerryDaBaaws · 2023-08-30 18:04:35

thanks, using --dbonly worked, ig gotta do for all packages whenever this error comes

problem is that i have no idea how many packages got purged from db, even base-devel i had to install again using --dbonly

until the database is fixed, i am guessing none of packages will be updated in a full system update, any way to fix this ?

loqs · 2023-08-30 18:14:17

jerryDaBaaws wrote:

until the database is fixed, i am guessing none of packages will be updated in a full system update, any way to fix this ?

Possibly Tips_and_tricks#Identify_files_not_owned_by_any_package.

jerryDaBaaws · 2023-09-02 11:41:47

seems like half the executables in /usr/bin are ownerless now, (~2000) I recognize a very few

/usr/share/desktop
/usr/share/themes/
many python modules in site packages
and many others, whom i dont even know the package name

any way to salvage this, or do fresh install

seth · 2023-09-02 11:48:48

https://wiki.archlinux.org/title/Pacman … l_database

Arch Linux

#1 2023-08-26 09:49:59

unable to update packages

#2 2023-08-26 10:14:58

Re: unable to update packages

#3 2023-08-26 10:17:58

Re: unable to update packages

#4 2023-08-26 10:36:23

Re: unable to update packages

#5 2023-08-26 10:37:30

Re: unable to update packages

#6 2023-08-26 10:42:11

Re: unable to update packages

#7 2023-08-26 12:30:58

Re: unable to update packages

#8 2023-08-28 18:14:55

Re: unable to update packages

#9 2023-08-28 18:51:29

Re: unable to update packages

#10 2023-08-28 19:04:49

Re: unable to update packages

#11 2023-08-30 15:03:09

Re: unable to update packages

#12 2023-08-30 15:07:06

Re: unable to update packages

#13 2023-08-30 15:30:24

Re: unable to update packages

#14 2023-08-30 15:44:49

Re: unable to update packages

#15 2023-08-30 18:04:35

Re: unable to update packages

#16 2023-08-30 18:14:17

Re: unable to update packages

#17 2023-09-02 11:41:47

Re: unable to update packages

#18 2023-09-02 11:48:48

Re: unable to update packages

Board footer