Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#7520 - could not open file error in pacman 3.0.5-2

Attached to Project: Pacman
Opened by Vlastimil K (w0c45_0x1) - Tuesday, 26 June 2007, 12:06 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 27 June 2007, 23:20 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.05 Duke
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Pacman gives me errors like "error: could not open file /var/lib/pacman/community//xloadimage-4.1-4/depends: No such file or directory" ....etc. Always another package, but I think, everytime in Community. More info in attached file pacman-debug.log, and some in pacman.log :)


Additional info:
* pacman 3.0.5-2

Steps to reproduce: just e.g. pacman -Syu ...see logs
   pacman-debug.log (4.6 KiB)
   pacman.log (17.2 KiB)
This task depends upon

Closed by  Dan McGee (toofishes)
Wednesday, 27 June 2007, 23:20 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Issue with user's filesystem in a /var/lib/pacman loopback mount.
Comment by Roman Kyrylych (Romashka) - Wednesday, 27 June 2007, 10:10 GMT
The log is full of /var/lib/pacman/community//xrestop-0.4-1/
I wonder what double slash is doing here. I remember similar report, but AFAIR it was fixed. :-/
Comment by Dan McGee (toofishes) - Wednesday, 27 June 2007, 13:43 GMT
pacman.conf would be helpful as well.
Comment by Vlastimil K (w0c45_0x1) - Wednesday, 27 June 2007, 16:59 GMT
Ok, there is :) ....but its IMHO defacto default
   pacman.conf (1.2 KiB)
Comment by Vlastimil K (w0c45_0x1) - Wednesday, 27 June 2007, 17:40 GMT
update... its not just in Community repo...
   pacman-freenx.log (0.8 KiB)
Comment by Vlastimil K (w0c45_0x1) - Wednesday, 27 June 2007, 20:16 GMT
update... its not just in Community repo...
   pacman-freenx.log (0.8 KiB)
Comment by Xavier (shining) - Wednesday, 27 June 2007, 20:55 GMT
Just a sanity check : do you have enough free space ?
Also, what is your partition layout ? (is /var on a separate partition, which filesystem, etc)
Comment by Vlastimil K (w0c45_0x1) - Wednesday, 27 June 2007, 21:44 GMT
I have /var/lib/pacman mounted as loop device... can it be a problem?

Mount:
/dev/sda2 on / type ext3 (rw,noatime,commit=256)
/var/lib/pacman.img on /var/lib/pacman type reiserfs (rw,loop=/dev/loop0)
Df:
/dev/sda2 110G 89G 16G 86% /
/var/lib/pacman.img 192M 47M 146M 24% /var/lib/pacman

Comment by Dan McGee (toofishes) - Wednesday, 27 June 2007, 21:50 GMT
I have a feeling this could be part of the issue here. Anyway you can copy your directory out of the loopback device and see if it works normally then? I'd like to eliminate as many variables as possible here.
Comment by Xavier (shining) - Wednesday, 27 June 2007, 21:52 GMT
Is it easy to revert to a normal partition ?
It would be interesting to see whether it helps or not.
Comment by Vlastimil K (w0c45_0x1) - Wednesday, 27 June 2007, 22:28 GMT
You're right.... on normal partiton work it without errors... but earlier (IMHO before 3) versions of pacman worked on loopback ok.
Comment by Vlastimil K (w0c45_0x1) - Wednesday, 27 June 2007, 22:38 GMT
I have deleted everything except local/ ...run fsck.reiserfs ....ane everything worked again on loopback...

I'm sorry for my _no_ bug report :(
Comment by Dan McGee (toofishes) - Wednesday, 27 June 2007, 22:53 GMT
Did the fsck find something? I know a lot of people use loopback so I want to make sure this isn't related to that, and is a result of some small corruption or something somewhere.
Comment by Vlastimil K (w0c45_0x1) - Wednesday, 27 June 2007, 23:15 GMT
Yes, many many messages like this:
fsck_tree_check_stat: The objectid (28134) is marked free, but used by an object [28131 28134 0x0 SD (0)]
fsck_tree_check_stat: The objectid (28135) is marked free, but used by an object [28131 28135 0x0 SD (0)]

And finally:
100%
vpf-10630: The on-disk and the correct bitmaps differs. Will be fixed later.
Checking Semantic tree...
There are on the filesystem:
Leaves 1013
Internal nodes 8
Directories 4621
Other files 9978
Data block pointers 1878 (0 of them are zero)
Safe links 0
No corruptions found

Comment by Dan McGee (toofishes) - Wednesday, 27 June 2007, 23:19 GMT
We'll call this a filesystem-related issue then. Thanks for reporting though and giving us good feedback- these are the kind of bugs that drive us crazy when we don't know what is happening.

Loading...