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.
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.
FS#4744 - loading package data... load_pkg: missing package name in /var/cache/pacman/pkg/[...]
Attached to Project:
Pacman
Opened by kongokris 2 (nut543) - Wednesday, 31 May 2006, 00:40 GMT
Last edited by Roman Kyrylych (Romashka) - Wednesday, 03 January 2007, 23:19 GMT
Opened by kongokris 2 (nut543) - Wednesday, 31 May 2006, 00:40 GMT
Last edited by Roman Kyrylych (Romashka) - Wednesday, 03 January 2007, 23:19 GMT
|
Detailsas experienced by these guys also:
http://bbs.archlinux.org/viewtopic.php?t=7830&highlight=loading+package+data+loadpkg+missing+package+name http://bbs.archlinux.org/viewtopic.php?t=16463&highlight=loading+package+data+loadpkg+missing+package+name http://bbs.archlinux.org/viewtopic.php?t=15067&highlight=loading+package+data+loadpkg+missing+package+name http://bbs.archlinux.org/viewtopic.php?t=12427&highlight=loading+package+data+loadpkg+missing+package+name http://bbs.archlinux.org/viewtopic.php?t=10369&highlight=loading+package+data+loadpkg+missing+package+name and maybe this one: http://bbs.archlinux.org/viewtopic.php?t=3319&highlight=loading+package+data+loadpkg+missing+package+name Nothing they tell in any of those threads solve the problem short off restarting the machine. I did a ps auxw. only thing "mysterious were: root 4936 0.0 0.0 0 0 ? S 00:38 0:01 [pdflush] root 5002 0.0 0.0 0 0 ? S 00:38 0:00 [pdflush] which i couldn't kill. My machine has been up for a few days, then started and been running for 3 hours if that somehow is relevant.. |
This task depends upon
Closed by Aaron Griffin (phrakture)
Monday, 12 February 2007, 00:24 GMT
Reason for closing: Not a bug
Additional comments about closing: This is a not really a pacman bug, but a corruption issue
Monday, 12 February 2007, 00:24 GMT
Reason for closing: Not a bug
Additional comments about closing: This is a not really a pacman bug, but a corruption issue
:: Synchronizing package databases...
:: current is up to date
error: anonymous login failed
:: extra is up to date
error: anonymous login failed
:: unstable is up to date
:: community is up to date
shadowhand [################] 100% 4K 8.0K/s 00:00:00
:: testing is up to date
:: gvim: local (7.0-1) appears to be newer than repo (current/6.4-3)
:: hawknl: local (168-1) appears to be newer than repo (community/1.68-1)
:: nvidia: local (1.0.8762-1) appears to be newer than repo (extra/1.0.8178-16)
:: opera-devel: local (20060502.6-1) appears to be newer than repo (shadowhand/9.0b2-1)
:: vim: local (7.0-1) appears to be newer than repo (current/6.4-2)
:: Above packages will be skipped. To manually upgrade use 'pacman -S <pkg>'
Targets: gnome-common-2.12.0-4 gstreamer0.10-bad-0.10.3-1
gstreamer0.10-swfdec-0.10.3-1 libxfce4util-4.2.3.2-3
Total Package Size: 0.4 MB
Proceed with upgrade? [Y/n]
checking package integrity... done.
loading package data... load_pkg: missing package name in /var/cache/pacman/pkg/gnome-common-2.12.0-4.pkg.tar.gz.
maybe that means something...
kris|~$ dmesg|grep -4 XFS
hda: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 < hda5 hda6 hda7 >
ide-floppy driver 0.99.newide
SGI XFS with ACLs, security attributes, large block numbers, no debug enabled
SGI XFS Quota Management subsystem
XFS mounting filesystem hda6
Ending clean XFS mount for filesystem: hda6
Freeing unused kernel memory: 244k freed
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.3
If that were the case it also means atleast 1, probably 2 and possibly everyone of the above thread people also should have had such a corruption.
The reason I listed the [pdflush] entries is because i usually never have them, if I remember correctly then I had them the last time I had this problem as well.
EDIT: Ignore that - package validation is on -A/-U operations. Still, pacman does validate with md5sums, but there's really nothing we can do about filesystem corruption.
I think this is closable.