Or seemingly.
A while ago I asserted that yum's performance is glacial, in the face of claims it was much improved.
yum might not be the problem. Here is some evidence. My update of 184 packages on an otherwise unloaded HP DC7700 SFF ran from 17:58 to 20:07, a little over two hours. Presumably those are actual install times we're looking at, not time retrieving them across my (wireless) LAN.
[root@potoroo ~]# rpm -qa --last 2>/dev/null | grep 'Sun Apr 6' | wc -l 164 [root@potoroo ~]# rpm -qa --last 2>/dev/null | grep 'Sun Apr 6' | head -2 kdeartwork-4.0.3-3.fc9 Sun Apr 6 20:07:45 2008 extragear-plasma-4.0.1-5.fc9 Sun Apr 6 20:07:24 2008 [root@potoroo ~]# rpm -qa --last 2>/dev/null | grep 'Sun Apr 6' | tail -2 audit-libs-1.7-3.fc9 Sun Apr 6 17:58:18 2008 alsa-lib-1.0.16-3.fc9 Sun Apr 6 17:58:10 2008 [root@potoroo ~]#
Here is my yum.conf: despite the debug level, the information that might be helpful in tuning yum is written only to the console where it scrolls off and is lost; it's not, AFAIK, recorded anywhere safe. [main] cachedir=/var/cache/yum keepcache=1 debuglevel=3 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 metadata_expire=1800 installonly_limit=8 installonlypkgs=kernel* #exclude= *.?86
The machine specs: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz 2 Gbytes RAM 320 Gbytes SATA (dual boot) [root@potoroo ~]# hdparm -t /dev/sda
/dev/sda: Timing buffered disk reads: 142 MB in 3.02 seconds = 47.05 MB/sec [root@potoroo ~]# hdparm -t /dev/sda{,,}
/dev/sda: Timing buffered disk reads: 188 MB in 3.06 seconds = 61.46 MB/sec
/dev/sda: Timing buffered disk reads: 190 MB in 3.01 seconds = 63.09 MB/sec
/dev/sda: Timing buffered disk reads: 190 MB in 3.01 seconds = 63.17 MB/sec [root@potoroo ~]#
I would expect a fresh install to go faster than this.
John Summerfield wrote:
Or seemingly.
A while ago I asserted that yum's performance is glacial, in the face of claims it was much improved.
yum might not be the problem. Here is some evidence. My update of 184 packages on an otherwise unloaded HP DC7700 SFF ran from 17:58 to 20:07, a little over two hours. Presumably those are actual install times we're looking at, not time retrieving them across my (wireless) LAN.
[root@potoroo ~]# rpm -qa --last 2>/dev/null | grep 'Sun Apr 6' | wc -l 164 [root@potoroo ~]# rpm -qa --last 2>/dev/null | grep 'Sun Apr 6' | head -2 kdeartwork-4.0.3-3.fc9 Sun Apr 6 20:07:45 2008 extragear-plasma-4.0.1-5.fc9 Sun Apr 6 20:07:24 2008 [root@potoroo ~]# rpm -qa --last 2>/dev/null | grep 'Sun Apr 6' | tail -2 audit-libs-1.7-3.fc9 Sun Apr 6 17:58:18 2008 alsa-lib-1.0.16-3.fc9 Sun Apr 6 17:58:10 2008 [root@potoroo ~]#
Here is my yum.conf: despite the debug level, the information that might be helpful in tuning yum is written only to the console where it scrolls off and is lost; it's not, AFAIK, recorded anywhere safe. [main] cachedir=/var/cache/yum keepcache=1 debuglevel=3 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 metadata_expire=1800 installonly_limit=8 installonlypkgs=kernel* #exclude= *.?86
The machine specs: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz 2 Gbytes RAM 320 Gbytes SATA (dual boot) [root@potoroo ~]# hdparm -t /dev/sda
/dev/sda: Timing buffered disk reads: 142 MB in 3.02 seconds = 47.05 MB/sec [root@potoroo ~]# hdparm -t /dev/sda{,,}
/dev/sda: Timing buffered disk reads: 188 MB in 3.06 seconds = 61.46 MB/sec
/dev/sda: Timing buffered disk reads: 190 MB in 3.01 seconds = 63.09 MB/sec
/dev/sda: Timing buffered disk reads: 190 MB in 3.01 seconds = 63.17 MB/sec [root@potoroo ~]#
I would expect a fresh install to go faster than this.
Again, so far it's been running for over twelve hours, and showing no progress, It's got this far, and stopped: ---> Package totem.x86_64 0:2.23.1-1.fc9 set to be updated
---> Package fedora-release.noarch 0:8.93-1 set to be updated
---> Package rhythmbox.x86_64 0:0.11.5-9.fc9 set to be updated
---> Package bittorrent.noarch 0:4.4.0-6.fc9 set to be updated
---> Package mlocate.x86_64 0:0.20-1 set to be updated
---> Package selinux-policy-devel.noarch 0:3.3.1-33.fc9 set to be updated
---> Package gtk2.i386 0:2.12.9-5.fc9 set to be updated
---> Package nscd.x86_64 0:2.8-1 set to be updated
---> Package mono-web.x86_64 0:1.9-7.fc9 set to be updated
---> Package totem-nautilus.x86_64 0:2.23.1-1.fc9 set to be updated
---> Package lm_sensors.x86_64 0:3.0.1-5.fc9 set to be updated
---> Package eclipse-ecj.x86_64 1:3.3.2-9.fc9 set to be updated
---> Package libuser.x86_64 0:0.56.9-1 set to be updated
---> Package system-config-services.noarch 0:0.99.15-1.fc9 set to be updated
---> Package selinux-policy-targeted.noarch 0:3.3.1-33.fc9 set to be updated
---> Package system-config-network.noarch 0:1.5.6-1.fc9 set to be updated
--> Running transaction check
---> Package kdepim.x86_64 6:3.5.9-8.fc9 set to be updated
--> Processing Dependency: xine-lib = 1.1.10.1 for package: xine-lib-extras-nonfree
---> Package kdebase3-pim-ioslaves.x86_64 0:3.5.9-10.fc9 set to be updated
---> Package fedorawaves-kdm-theme.noarch 0:1.1-1.fc9 set to be updated
[summer@potoroo ~]$
It's using these files: [summer@potoroo ~]$ sudo lsof -c yum | grep -Ev ' /(usr|lib)'
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
yum 29574 root cwd DIR 253,0 4096 58294273 /root
yum 29574 root rtd DIR 253,0 4096 2 /
yum 29574 root mem REG 253,0 24576 7332989 /var/lib/rpm/__db.001
yum 29574 root mem REG 253,0 1318912 7332994 /var/lib/rpm/__db.002
yum 29574 root mem REG 253,0 663552 7332995 /var/lib/rpm/__db.003
yum 29574 root 0u CHR 4,2 509 /dev/tty2
yum 29574 root 1u CHR 4,2 509 /dev/tty2
yum 29574 root 2u CHR 4,2 509 /dev/tty2
yum 29574 root 3u unix 0xffff81000e17a5c0 3805141 socket
yum 29574 root 4w REG 253,0 14966 7308388 /var/log/yum.log
yum 29574 root 5ur REG 253,0 32847872 36503718 /var/cache/yum/development.Mirror/primary.sqlite
yum 29574 root 6r REG 253,0 100597760 7307274 /var/lib/rpm/Packages
yum 29574 root 7r REG 253,0 90112 7307275 /var/lib/rpm/Name
yum 29574 root 8r REG 253,0 659456 7307277 /var/lib/rpm/Providename
yum 29574 root 9r REG 253,0 10887168 7307279 /var/lib/rpm/Basenames
yum 29574 root 10r REG 253,0 905216 7307281 /var/lib/rpm/Requirename
[summer@potoroo ~]$ rpm -q yum
yum-3.2.14-2.fc9.noarch
[summer@potoroo ~]$ ls -l /var/run/yum.pid ;date -rw-r--r-- 1 root root 5 2008-04-18 16:08 /var/run/yum.pid Sat Apr 19 05:00:44 WST 2008 [summer@potoroo ~]$
The repo it's using is on my LAN.
Rex Dieter wrote:
John Summerfield wrote:
Again, so far it's been running for over twelve hours, and showing no progress
Something (else) is apparently way-wrong with your box, and it isn't yum.
It's beyond dispute that something is wrong with the box, but yum really ought not hang forever, whatever might be wrong.
Network connectivity is fine; I control both ends and the intervening link, and everything is working file (else my mail wouldn't be coming and going).
That said, yum doesn't seem to be using anything outside the box. The box isn't particularly busy: [summer@potoroo ~]$ uptime
07:24:16 up 4 days, 12:03, 11 users, load average: 0.88, 0.58, 0.86
[summer@potoroo ~]$
From top: Tasks: 142 total, 2 running, 140 sleeping, 0 stopped, 0 zombie Cpu(s): 2.9%us, 1.3%sy, 0.0%ni, 95.6%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 2012232k total, 1951568k used, 60664k free, 308800k buffers Swap: 1572848k total, 240k used, 1572608k free, 953400k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29574 root 20 0 335m 99m 7700 S 0.0 5.1 0:35.65 yum
It's not running any other programs, so far as I can see: [summer@potoroo ~]$ ps fttty2 PID TTY STAT TIME COMMAND 2783 tty2 Ss 0:02 -bash 29574 tty2 S+ 0:35 _ /usr/bin/python /usr/bin/yum --disablerepo=rawhide* -y upgrade [summer@potoroo ~]$
It's still hung. Here are all the files it's using: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME yum 29574 root cwd DIR 253,0 4096 58294273 /root yum 29574 root rtd DIR 253,0 4096 2 / yum 29574 root txt REG 253,0 8504 44239563 /usr/bin/python yum 29574 root mem REG 253,0 915648 47218754 /lib64/libglib-2.0.so.0.1600.3 yum 29574 root mem REG 253,0 1491424 41254923 /usr/lib64/libpython2.5.so.1.0 yum 29574 root mem REG 253,0 152888 47218694 /lib64/ld-2.7.90.so yum 29574 root mem REG 253,0 1834840 47218695 /lib64/libc-2.7.90.so yum 29574 root mem REG 253,0 619432 27688997 /lib64/libm-2.7.90.so yum 29574 root mem REG 253,0 23208 27492353 /lib64/libdl-2.7.90.so yum 29574 root mem REG 253,0 147728 27688982 /lib64/libpthread-2.7.90.so yum 29574 root mem REG 253,0 88976 27492423 /lib64/libz.so.1.2.3 yum 29574 root mem REG 253,0 53800 47251492 /lib64/librt-2.7.90.so yum 29574 root mem REG 253,0 169880 47218696 /lib64/libexpat.so.1.5.2 yum 29574 root mem REG 253,0 196152 44239900 /usr/lib64/libgpgme.so.11.6.4 yum 29574 root mem REG 253,0 93184 27492400 /lib64/libresolv-2.7.90.so yum 29574 root mem REG 253,0 17640 47251500 /lib64/libcap.so.2.06 yum 29574 root mem REG 253,0 1408920 57901146 /usr/lib64/libxml2.so.2.6.31 yum 29574 root mem REG 253,0 17928 47251496 /lib64/libutil-2.7.90.so yum 29574 root mem REG 253,0 69016 47251493 /lib64/libbz2.so.1.0.4 yum 29574 root mem REG 253,0 82664 44243789 /usr/lib64/libelf-0.133.so yum 29574 root mem REG 253,0 12448 27492421 /lib64/libcom_err.so.2.1 yum 29574 root mem REG 253,0 9816 27492398 /lib64/libkeyutils-1.2.so yum 29574 root mem REG 253,0 1443136 27688999 /lib64/libcrypto.so.0.9.8g yum 29574 root mem REG 253,0 38808 47251494 /lib64/libpopt.so.0.0.0 yum 29574 root mem REG 253,0 15552 27492429 /lib64/libgpg-error.so.0.4.0 yum 29574 root mem REG 253,0 134152 27492355 /lib64/libtinfo.so.5.6 yum 29574 root mem REG 253,0 237440 2392073 /lib64/libnspr4.so yum 29574 root mem REG 253,0 14256 47251488 /lib64/libplds4.so yum 29574 root mem REG 253,0 18672 47251489 /lib64/libplc4.so yum 29574 root mem REG 253,0 1348640 47251491 /lib64/libnss3.so yum 29574 root mem REG 253,0 121896 47251490 /lib64/libnssutil3.so yum 29574 root mem REG 253,0 112192 47218699 /lib64/libselinux.so.1 yum 29574 root mem REG 253,0 154688 44242937 /usr/lib64/libk5crypto.so.3.1 yum 29574 root mem REG 253,0 195720 44243203 /usr/lib64/libgssapi_krb5.so.2.2 yum 29574 root mem REG 253,0 37016 44239616 /usr/lib64/libkrb5support.so.0.1 yum 29574 root mem REG 253,0 668008 44243202 /usr/lib64/libkrb5.so.3.3 yum 29574 root mem REG 253,0 327552 47218835 /lib64/libssl.so.0.9.8g yum 29574 root mem REG 253,0 455592 44250202 /usr/lib64/libsqlite3.so.0.8.6 yum 29574 root mem REG 253,0 93416 27492425 /lib64/libgcc_s-4.3.0-20080404.so.1 yum 29574 root mem REG 253,0 162560 41648141 /usr/lib64/librpmbuild-4.4.so yum 29574 root mem REG 253,0 423736 41648138 /usr/lib64/librpmio-4.4.so yum 29574 root mem REG 253,0 1178528 41648139 /usr/lib64/librpmdb-4.4.so yum 29574 root mem REG 253,0 397920 41648140 /usr/lib64/librpm-4.4.so yum 29574 root mem REG 253,0 251680 47218700 /lib64/libdbus-1.so.3.4.0 yum 29574 root mem REG 253,0 79222096 44264603 /usr/lib/locale/locale-archive yum 29574 root mem REG 253,0 132968 44763710 /usr/lib64/python2.5/site-packages/rpm/_rpmmodule.so yum 29574 root mem REG 253,0 238808 47218927 /lib64/libsoftokn3.so yum 29574 root mem REG 253,0 341368 47218918 /lib64/libfreebl3.so yum 29574 root mem REG 253,0 20328 31719679 /usr/lib64/python2.5/lib-dynload/timemodule.so yum 29574 root mem REG 253,0 25448 31719676 /usr/lib64/python2.5/lib-dynload/stropmodule.so yum 29574 root mem REG 253,0 19112 31719651 /usr/lib64/python2.5/lib-dynload/cStringIO.so yum 29574 root mem REG 253,0 27488 31719653 /usr/lib64/python2.5/lib-dynload/collectionsmodule.so yum 29574 root mem REG 253,0 58096 31719641 /usr/lib64/python2.5/lib-dynload/_socketmodule.so yum 29574 root mem REG 253,0 17536 31719643 /usr/lib64/python2.5/lib-dynload/_ssl.so yum 29574 root mem REG 253,0 76304 31719650 /usr/lib64/python2.5/lib-dynload/cPickle.so yum 29574 root mem REG 253,0 31968 31719644 /usr/lib64/python2.5/lib-dynload/_struct.so yum 29574 root mem REG 253,0 36968 31719667 /usr/lib64/python2.5/lib-dynload/operator.so yum 29574 root mem REG 253,0 22120 31719683 /usr/lib64/python2.5/lib-dynload/zlibmodule.so yum 29574 root mem REG 253,0 42192 31719662 /usr/lib64/python2.5/lib-dynload/itertoolsmodule.so yum 29574 root mem REG 253,0 21640 31719635 /usr/lib64/python2.5/lib-dynload/_localemodule.so yum 29574 root mem REG 253,0 21232 31719648 /usr/lib64/python2.5/lib-dynload/binascii.so yum 29574 root mem REG 253,0 13736 31719632 /usr/lib64/python2.5/lib-dynload/_hashlib.so yum 29574 root mem REG 253,0 18088 31719664 /usr/lib64/python2.5/lib-dynload/mathmodule.so yum 29574 root mem REG 253,0 12840 31719639 /usr/lib64/python2.5/lib-dynload/_randommodule.so yum 29574 root mem REG 253,0 14216 31719658 /usr/lib64/python2.5/lib-dynload/fcntlmodule.so yum 29574 root mem REG 253,0 34288 31719649 /usr/lib64/python2.5/lib-dynload/bz2.so yum 29574 root mem REG 253,0 72960 44729181 /usr/lib64/python2.5/site-packages/gpgme/_gpgme.so yum 29574 root mem REG 253,0 9080 31719660 /usr/lib64/python2.5/lib-dynload/grpmodule.so yum 29574 root mem REG 253,0 42296 31719630 /usr/lib64/python2.5/lib-dynload/_elementtree.so yum 29574 root mem REG 253,0 40040 31719646 /usr/lib64/python2.5/lib-dynload/arraymodule.so yum 29574 root mem REG 253,0 49480 31719670 /usr/lib64/python2.5/lib-dynload/pyexpat.so yum 29574 root mem REG 253,0 9744 31719618 /usr/lib64/python2.5/lib-dynload/_bisect.so yum 29574 root mem REG 253,0 7208 31719645 /usr/lib64/python2.5/lib-dynload/_weakref.so yum 29574 root mem REG 253,0 78056 31719655 /usr/lib64/python2.5/lib-dynload/datetime.so yum 29574 root mem REG 253,0 69832 31719642 /usr/lib64/python2.5/lib-dynload/_sqlite3.so yum 29574 root mem REG 253,0 42248 3571751 /usr/lib64/python2.5/site-packages/_sqlitecache.so yum 29574 root mem REG 253,0 26042 44305671 /usr/lib64/gconv/gconv-modules.cache yum 29574 root mem REG 253,0 75264 31719629 /usr/lib64/python2.5/lib-dynload/_cursesmodule.so yum 29574 root mem REG 253,0 191472 27492376 /lib64/libncursesw.so.5.6 yum 29574 root mem REG 253,0 143560 36995075 /usr/lib64/python2.5/site-packages/_dbus_bindings.so yum 29574 root mem REG 253,0 208480 50167823 /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so yum 29574 root mem REG 253,0 24576 7332989 /var/lib/rpm/__db.001 yum 29574 root mem REG 253,0 1318912 7332994 /var/lib/rpm/__db.002 yum 29574 root mem REG 253,0 663552 7332995 /var/lib/rpm/__db.003 yum 29574 root 0u CHR 4,2 509 /dev/tty2 yum 29574 root 1u CHR 4,2 509 /dev/tty2 yum 29574 root 2u CHR 4,2 509 /dev/tty2 yum 29574 root 3u unix 0xffff81000e17a5c0 3805141 socket yum 29574 root 4w REG 253,0 14966 7308388 /var/log/yum.log yum 29574 root 5ur REG 253,0 32847872 36503718 /var/cache/yum/development.Mirror/primary.sqlite yum 29574 root 6r REG 253,0 100597760 7307274 /var/lib/rpm/Packages yum 29574 root 7r REG 253,0 90112 7307275 /var/lib/rpm/Name yum 29574 root 8r REG 253,0 659456 7307277 /var/lib/rpm/Providename yum 29574 root 9r REG 253,0 10887168 7307279 /var/lib/rpm/Basenames yum 29574 root 10r REG 253,0 905216 7307281 /var/lib/rpm/Requirename
On Sun, 2008-04-20 at 07:31 +0800, John Summerfield wrote:
Rex Dieter wrote:
John Summerfield wrote:
Again, so far it's been running for over twelve hours, and showing no progress
Something (else) is apparently way-wrong with your box, and it isn't yum.
It's beyond dispute that something is wrong with the box, but yum really ought not hang forever, whatever might be wrong.
Network connectivity is fine; I control both ends and the intervening link, and everything is working file (else my mail wouldn't be coming and going).
That said, yum doesn't seem to be using anything outside the box. The box isn't particularly busy: [summer@potoroo ~]$ uptime
07:24:16 up 4 days, 12:03, 11 users, load average: 0.88, 0.58, 0.86
[summer@potoroo ~]$
From top: Tasks: 142 total, 2 running, 140 sleeping, 0 stopped, 0 zombie Cpu(s): 2.9%us, 1.3%sy, 0.0%ni, 95.6%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 2012232k total, 1951568k used, 60664k free, 308800k buffers Swap: 1572848k total, 240k used, 1572608k free, 953400k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29574 root 20 0 335m 99m 7700 S 0.0 5.1 0:35.65 yum
It's not running any other programs, so far as I can see: [summer@potoroo ~]$ ps fttty2 PID TTY STAT TIME COMMAND 2783 tty2 Ss 0:02 -bash 29574 tty2 S+ 0:35 _ /usr/bin/python /usr/bin/yum --disablerepo=rawhide* -y upgrade [summer@potoroo ~]$
strace -p it - tell me if it is futex_wait, and if not, what it is doing.
-sv
seth vidal wrote:
On Sun, 2008-04-20 at 07:31 +0800, John Summerfield wrote:
Rex Dieter wrote:
John Summerfield wrote:
Again, so far it's been running for over twelve hours, and showing no progress
Something (else) is apparently way-wrong with your box, and it isn't yum.
It's beyond dispute that something is wrong with the box, but yum really ought not hang forever, whatever might be wrong.
Network connectivity is fine; I control both ends and the intervening link, and everything is working file (else my mail wouldn't be coming and going).
That said, yum doesn't seem to be using anything outside the box. The box isn't particularly busy: [summer@potoroo ~]$ uptime
07:24:16 up 4 days, 12:03, 11 users, load average: 0.88, 0.58, 0.86
[summer@potoroo ~]$
From top: Tasks: 142 total, 2 running, 140 sleeping, 0 stopped, 0 zombie Cpu(s): 2.9%us, 1.3%sy, 0.0%ni, 95.6%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 2012232k total, 1951568k used, 60664k free, 308800k buffers Swap: 1572848k total, 240k used, 1572608k free, 953400k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29574 root 20 0 335m 99m 7700 S 0.0 5.1 0:35.65 yum
It's not running any other programs, so far as I can see: [summer@potoroo ~]$ ps fttty2 PID TTY STAT TIME COMMAND 2783 tty2 Ss 0:02 -bash 29574 tty2 S+ 0:35 _ /usr/bin/python /usr/bin/yum --disablerepo=rawhide* -y upgrade [summer@potoroo ~]$
strace -p it - tell me if it is futex_wait, and if not, what it is doing.
-sv
How much do you want, and where should I put it. It's very busy doing this: read(5, "\r\0\0\0\2\0\327\0\2A\0\327\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7164928, SEEK_SET) = 7164928 read(5, "\r\0\0\0\2\0\246\0\2;\0\246\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7168000, SEEK_SET) = 7168000 read(5, "\r\0\0\0\2\0y\0\2X\0y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7182336, SEEK_SET) = 7182336 read(5, "\r\0\0\0\1\2%\0\2%\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7185408, SEEK_SET) = 7185408 read(5, "\r\0\0\0\1\0\220\0\0\220\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7188480, SEEK_SET) = 7188480 read(5, "\r\0\0\0\1\0A\0\0A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7189504, SEEK_SET) = 7189504 read(5, "\r\0\0\0\1\2\236\0\2\236\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7190528, SEEK_SET) = 7190528 read(5, "\r\0\0\0\1\1_\0\1_\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7191552, SEEK_SET) = 7191552 read(5, "\r\0\0\0\1\1>\0\1>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7192576, SEEK_SET) = 7192576 read(5, "\r\0\0\0\1\1\265\0\1\265\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7196672, SEEK_SET) = 7196672 read(5, "\r\0\0\0\1\1U\0\1U\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7203840, SEEK_SET) = 7203840 read(5, "\r\0\0\0\2\0;\0\1\227\0;\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7211008, SEEK_SET) = 7211008 read(5, "\r\0\0\0\1\1\313\0\1\313\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7213056, SEEK_SET) = 7213056 read(5, "\r\0\0\0\1\1\27\0\1\27\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7215104, SEEK_SET) = 7215104 read(5, "\r\0\0\0\2\0\22\0\2i\0\22\0\0\0\0\0\0\204S\224J\35\0]\31\31\23\17\27\201\1"..., 1024) = 1024 lseek(5, 7218176, SEEK_SET) = 7218176 read(5, "\r\0\0\0\1\1/\0\1/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7222272, SEEK_SET) = 7222272 read(5, "\r\0\0\0\1\1n\0\1n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7223296, SEEK_SET) = 7223296 read(5, "\r\0\0\0\2\0009\0\0026\0009\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7226368, SEEK_SET) = 7226368 read(5, "\r\0\0\0\1\2Q\0\2Q\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(5, 7229440, SEEK_SET) = 7229440 read(5, "\r\0\0\0\1\0\253\0\0\253\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
I presume this is the file:
yum 29574 root 5ur REG 253,0 32847872 36503718 /var/cache/yum/development.Mirror/primary.sqlite
Could it have corrupted the file? I did run out of space while it was running.
It also seemed to have problems downloading the metadata a couple of times, I think my rsync might have timed out beforehand.
There is no possibility of it completing, the source repo has been updated several times since it started.
John Summerfield wrote:
There is no possibility of it completing, the source repo has been updated several times since it started.
The strace interfered with it, and it's ended: ---> Package kdebase3-pim-ioslaves.x86_64 0:3.5.9-10.fc9 set to be updated ---> Package fedorawaves-kdm-theme.noarch 0:1.1-1.fc9 set to be updated file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno 5] OSError: [Errno 4] Interrupted system call: '/net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2' Trying other mirror. Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 236, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 152, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 624, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 657, in resolveDeps for po, dep in self._checkFileRequires(): File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 862, in _checkFileRequires if not self.tsInfo.getOldProvides(filename) and not self.tsInfo.getNewProvides(filename): File "/usr/lib/python2.5/site-packages/yum/transactioninfo.py", line 411, in getNewProvides for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems(): File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 295, in getProvides return self._computeAggregateDictResult("getProvides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 447, in _computeAggregateDictResult sackResult = apply(method, args) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 721, in getProvides return self._search("provides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 700, in _search for pkg in self.searchFiles(name, strict=True): File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
real 3595m13.383s user 0m31.697s sys 0m6.462s [root@potoroo ~]# [summer@potoroo ~]$
John Summerfield wrote:
John Summerfield wrote:
There is no possibility of it completing, the source repo has been updated several times since it started.
The strace interfered with it, and it's ended: ---> Package kdebase3-pim-ioslaves.x86_64 0:3.5.9-10.fc9 set to be updated ---> Package fedorawaves-kdm-theme.noarch 0:1.1-1.fc9 set to be updated file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno 5] OSError: [Errno 4] Interrupted system call: '/net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2' Trying other mirror. Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 236, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 152, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 624, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 657, in resolveDeps for po, dep in self._checkFileRequires(): File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 862, in _checkFileRequires if not self.tsInfo.getOldProvides(filename) and not self.tsInfo.getNewProvides(filename): File "/usr/lib/python2.5/site-packages/yum/transactioninfo.py", line 411, in getNewProvides for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems(): File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 295, in getProvides return self._computeAggregateDictResult("getProvides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 447, in _computeAggregateDictResult sackResult = apply(method, args) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 721, in getProvides return self._search("provides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 700, in _search for pkg in self.searchFiles(name, strict=True): File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
real 3595m13.383s user 0m31.697s sys 0m6.462s [root@potoroo ~]# [summer@potoroo ~]$
After that marathon, it seemed likely to do it again, so I tried to trace it again. Following some output from "ps xf" is the entire trace:
13465 ? Ss 0:00 _ sshd: root@pts/4 13470 pts/4 Ss 0:01 _ -bash 13673 pts/4 S+ 0:00 _ screen -L 13674 ? Ss 0:00 _ SCREEN -L 13675 pts/7 Ss+ 0:01 _ /bin/bash 13706 pts/10 Rs 0:01 _ /bin/bash 17920 pts/10 R+ 0:00 | _ ps xf 13874 pts/12 Ss 0:01 _ /bin/bash 13907 pts/12 S+ 0:01 _ /usr/bin/python /usr/bin/yum --disablerepo=rawhide* -y upgrade 2258 ? Ss 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid 2281 ? Ss 0:00 rpc.rquotad 2320 ? Ss 0:00 rpc.mountd 2351 ? Ss 0:32 sendmail: accepting connections 2375 ? Ss 0:03 crond 2381 ? Ss 0:00 /usr/sbin/atd 2441 ? S 0:00 /usr/sbin/dnsmasq --keep-in-foreground --strict-order --bind-interfaces --pid-file --conf-file --listen-address 192.168.122.1 --except-interface lo - 2443 ? S 0:00 libvirtd --daemon 2460 ? Ss 0:14 cupsd 2478 ? Ssl 0:02 /usr/sbin/console-kit-daemon 2603 tty4 Ss+ 0:00 /sbin/mingetty tty4 2604 tty5 Ss+ 0:00 /sbin/mingetty tty5 2605 ? Ss 0:00 login -- root 2783 tty2 Ss+ 0:06 _ -bash 2606 ? Ss 0:00 login -- summer 2607 ? Ss 0:00 login -- summer 2609 tty6 Ss+ 0:00 /sbin/mingetty tty6 19889 ? Ss 0:02 gpm -m /dev/input/mice -t exps2 19979 ? Ss 0:00 kdm -nodaemon 19982 tty7 Rs+ 416:24 _ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-lQgwzs 21879 ? S 0:00 _ -:0 22006 ? Sl 173:01 _ /usr/libexec/kde4/kdm_greet 22029 ? S 0:00 dbus-launch --autolaunch 1fbf779aa8e6990011358700471be2ed --binary-syntax --close-stderr 22035 ? Ss 0:00 /bin/dbus-daemon --fork --print-pid 7 --print-address 9 --session [root@potoroo ~]# strace -p 13907 Process 13907 attached - interrupt to quit write(2, "file:///net/cdm/home/mirror/linu"..., 192) = 192 write(2, "Trying other mirror.\n", 21) = 21 write(2, "Error: Cannot retrieve repositor"..., 129) = 129 unlink("///var/run/yum.pid") = 0 close(4) = 0 munmap(0x2aaaaf4ce000, 4096) = 0 close(3) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {0x30692ea800, [], SA_RESTORER, 0x319c00f110}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x30692ea800, [], SA_RESTORER, 0x319c00f110}, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(1) = ? Process 13907 detached [root@potoroo ~]#
And the entire output: [root@potoroo ~]# time yum --disablerepo=rawhide* -y upgrade Loaded plugins: refresh-packagekit, refresh-updatesd Config time: 0.778 repo time: 0.003 Yum Version: 3.2.14 COMMAND: yum --disablerepo=rawhide* -y upgrade Installroot: / Reading Local RPMDB rpmdb time: 0.001 Setting up Package Sacks file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 4] Interrupted system call: '/net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/repomd.xml' Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: development.Mirror. Please verify its path and try again
real 921m51.582s user 0m1.246s sys 0m0.480s [root@potoroo ~]#
I'm reluctant to try to repair this, if someone wants the info.
On Mon, 2008-04-21 at 20:27 +0800, John Summerfield wrote:
John Summerfield wrote:
John Summerfield wrote:
There is no possibility of it completing, the source repo has been updated several times since it started.
The strace interfered with it, and it's ended: ---> Package kdebase3-pim-ioslaves.x86_64 0:3.5.9-10.fc9 set to be updated ---> Package fedorawaves-kdm-theme.noarch 0:1.1-1.fc9 set to be updated file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno 5] OSError: [Errno 4] Interrupted system call: '/net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2' Trying other mirror. Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 236, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 152, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 624, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 657, in resolveDeps for po, dep in self._checkFileRequires(): File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 862, in _checkFileRequires if not self.tsInfo.getOldProvides(filename) and not self.tsInfo.getNewProvides(filename): File "/usr/lib/python2.5/site-packages/yum/transactioninfo.py", line 411, in getNewProvides for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems(): File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 295, in getProvides return self._computeAggregateDictResult("getProvides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 447, in _computeAggregateDictResult sackResult = apply(method, args) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 721, in getProvides return self._search("provides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 700, in _search for pkg in self.searchFiles(name, strict=True): File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
real 3595m13.383s user 0m31.697s sys 0m6.462s [root@potoroo ~]# [summer@potoroo ~]$
After that marathon, it seemed likely to do it again, so I tried to trace it again. Following some output from "ps xf" is the entire trace:
13465 ? Ss 0:00 _ sshd: root@pts/4 13470 pts/4 Ss 0:01 _ -bash 13673 pts/4 S+ 0:00 _ screen -L 13674 ? Ss 0:00 _ SCREEN -L 13675 pts/7 Ss+ 0:01 _ /bin/bash 13706 pts/10 Rs 0:01 _ /bin/bash 17920 pts/10 R+ 0:00 | _ ps xf 13874 pts/12 Ss 0:01 _ /bin/bash 13907 pts/12 S+ 0:01 _ /usr/bin/python /usr/bin/yum --disablerepo=rawhide* -y upgrade 2258 ? Ss 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid 2281 ? Ss 0:00 rpc.rquotad 2320 ? Ss 0:00 rpc.mountd 2351 ? Ss 0:32 sendmail: accepting connections 2375 ? Ss 0:03 crond 2381 ? Ss 0:00 /usr/sbin/atd 2441 ? S 0:00 /usr/sbin/dnsmasq --keep-in-foreground --strict-order --bind-interfaces --pid-file --conf-file --listen-address 192.168.122.1 --except-interface lo - 2443 ? S 0:00 libvirtd --daemon 2460 ? Ss 0:14 cupsd 2478 ? Ssl 0:02 /usr/sbin/console-kit-daemon 2603 tty4 Ss+ 0:00 /sbin/mingetty tty4 2604 tty5 Ss+ 0:00 /sbin/mingetty tty5 2605 ? Ss 0:00 login -- root 2783 tty2 Ss+ 0:06 _ -bash 2606 ? Ss 0:00 login -- summer 2607 ? Ss 0:00 login -- summer 2609 tty6 Ss+ 0:00 /sbin/mingetty tty6 19889 ? Ss 0:02 gpm -m /dev/input/mice -t exps2 19979 ? Ss 0:00 kdm -nodaemon 19982 tty7 Rs+ 416:24 _ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-lQgwzs 21879 ? S 0:00 _ -:0 22006 ? Sl 173:01 _ /usr/libexec/kde4/kdm_greet 22029 ? S 0:00 dbus-launch --autolaunch 1fbf779aa8e6990011358700471be2ed --binary-syntax --close-stderr 22035 ? Ss 0:00 /bin/dbus-daemon --fork --print-pid 7 --print-address 9 --session [root@potoroo ~]# strace -p 13907 Process 13907 attached - interrupt to quit write(2, "file:///net/cdm/home/mirror/linu"..., 192) = 192 write(2, "Trying other mirror.\n", 21) = 21 write(2, "Error: Cannot retrieve repositor"..., 129) = 129 unlink("///var/run/yum.pid") = 0 close(4) = 0 munmap(0x2aaaaf4ce000, 4096) = 0 close(3) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {0x30692ea800, [], SA_RESTORER, 0x319c00f110}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x30692ea800, [], SA_RESTORER, 0x319c00f110}, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(1) = ? Process 13907 detached [root@potoroo ~]#
And the entire output: [root@potoroo ~]# time yum --disablerepo=rawhide* -y upgrade Loaded plugins: refresh-packagekit, refresh-updatesd Config time: 0.778 repo time: 0.003 Yum Version: 3.2.14 COMMAND: yum --disablerepo=rawhide* -y upgrade Installroot: / Reading Local RPMDB rpmdb time: 0.001 Setting up Package Sacks file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 4] Interrupted system call: '/net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/repomd.xml' Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: development.Mirror. Please verify its path and try again
real 921m51.582s user 0m1.246s sys 0m0.480s [root@potoroo ~]#
I'm reluctant to try to repair this, if someone wants the info.
Is your /var/cache/yum directory mounted on a non-local or extremely slow disk?
and what is this mirror of: ///net/cdm/home/mirror/...
-sv
seth vidal wrote:
On Mon, 2008-04-21 at 20:27 +0800, John Summerfield wrote:
John Summerfield wrote:
John Summerfield wrote:
There is no possibility of it completing, the source repo has been updated several times since it started.
The strace interfered with it, and it's ended: ---> Package kdebase3-pim-ioslaves.x86_64 0:3.5.9-10.fc9 set to be updated ---> Package fedorawaves-kdm-theme.noarch 0:1.1-1.fc9 set to be updated file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno 5] OSError: [Errno 4] Interrupted system call: '/net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2' Trying other mirror. Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 236, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 152, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 624, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 657, in resolveDeps for po, dep in self._checkFileRequires(): File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 862, in _checkFileRequires if not self.tsInfo.getOldProvides(filename) and not self.tsInfo.getNewProvides(filename): File "/usr/lib/python2.5/site-packages/yum/transactioninfo.py", line 411, in getNewProvides for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems(): File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 295, in getProvides return self._computeAggregateDictResult("getProvides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 447, in _computeAggregateDictResult sackResult = apply(method, args) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 721, in getProvides return self._search("provides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 700, in _search for pkg in self.searchFiles(name, strict=True): File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
real 3595m13.383s user 0m31.697s sys 0m6.462s [root@potoroo ~]# [summer@potoroo ~]$
After that marathon, it seemed likely to do it again, so I tried to trace it again. Following some output from "ps xf" is the entire trace:
13465 ? Ss 0:00 _ sshd: root@pts/4 13470 pts/4 Ss 0:01 _ -bash 13673 pts/4 S+ 0:00 _ screen -L 13674 ? Ss 0:00 _ SCREEN -L 13675 pts/7 Ss+ 0:01 _ /bin/bash 13706 pts/10 Rs 0:01 _ /bin/bash 17920 pts/10 R+ 0:00 | _ ps xf 13874 pts/12 Ss 0:01 _ /bin/bash 13907 pts/12 S+ 0:01 _ /usr/bin/python /usr/bin/yum --disablerepo=rawhide* -y upgrade 2258 ? Ss 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid 2281 ? Ss 0:00 rpc.rquotad 2320 ? Ss 0:00 rpc.mountd 2351 ? Ss 0:32 sendmail: accepting connections 2375 ? Ss 0:03 crond 2381 ? Ss 0:00 /usr/sbin/atd 2441 ? S 0:00 /usr/sbin/dnsmasq --keep-in-foreground --strict-order --bind-interfaces --pid-file --conf-file --listen-address 192.168.122.1 --except-interface lo - 2443 ? S 0:00 libvirtd --daemon 2460 ? Ss 0:14 cupsd 2478 ? Ssl 0:02 /usr/sbin/console-kit-daemon 2603 tty4 Ss+ 0:00 /sbin/mingetty tty4 2604 tty5 Ss+ 0:00 /sbin/mingetty tty5 2605 ? Ss 0:00 login -- root 2783 tty2 Ss+ 0:06 _ -bash 2606 ? Ss 0:00 login -- summer 2607 ? Ss 0:00 login -- summer 2609 tty6 Ss+ 0:00 /sbin/mingetty tty6 19889 ? Ss 0:02 gpm -m /dev/input/mice -t exps2 19979 ? Ss 0:00 kdm -nodaemon 19982 tty7 Rs+ 416:24 _ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-lQgwzs 21879 ? S 0:00 _ -:0 22006 ? Sl 173:01 _ /usr/libexec/kde4/kdm_greet 22029 ? S 0:00 dbus-launch --autolaunch 1fbf779aa8e6990011358700471be2ed --binary-syntax --close-stderr 22035 ? Ss 0:00 /bin/dbus-daemon --fork --print-pid 7 --print-address 9 --session [root@potoroo ~]# strace -p 13907 Process 13907 attached - interrupt to quit write(2, "file:///net/cdm/home/mirror/linu"..., 192) = 192 write(2, "Trying other mirror.\n", 21) = 21 write(2, "Error: Cannot retrieve repositor"..., 129) = 129 unlink("///var/run/yum.pid") = 0 close(4) = 0 munmap(0x2aaaaf4ce000, 4096) = 0 close(3) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {0x30692ea800, [], SA_RESTORER, 0x319c00f110}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x30692ea800, [], SA_RESTORER, 0x319c00f110}, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(1) = ? Process 13907 detached [root@potoroo ~]#
And the entire output: [root@potoroo ~]# time yum --disablerepo=rawhide* -y upgrade Loaded plugins: refresh-packagekit, refresh-updatesd Config time: 0.778 repo time: 0.003 Yum Version: 3.2.14 COMMAND: yum --disablerepo=rawhide* -y upgrade Installroot: / Reading Local RPMDB rpmdb time: 0.001 Setting up Package Sacks file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 4] Interrupted system call: '/net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/repomd.xml' Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: development.Mirror. Please verify its path and try again
real 921m51.582s user 0m1.246s sys 0m0.480s [root@potoroo ~]#
I'm reluctant to try to repair this, if someone wants the info.
Is your /var/cache/yum directory mounted on a non-local or extremely slow disk?
No.
and what is this mirror of: ///net/cdm/home/mirror/...
Local, the other side of my wireless link. If there's a problem there, I will notice, the machine "cdm" is my Internet gateway.
It's about this fast: [root@potoroo ~]# ls -l /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm -h -rw-r--r-- 1 1004 1004 4.3M Mar 12 03:36 /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm [root@potoroo ~]# time cp \ /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm \ /tmp/
It's mirrored from a local mirror of rsync://mirror.3fl.net.au/fedora-linux-development/*6*: 12:48 [summer@numbat ~]$ rsync \ rsync://mirror.3fl.net.au/fedora-linux-development/*6* Welcome to mirror.3fl.net rsync service IP Address: 203.31.12.18 Connections: Max 20 Location: Perth, Australia Admin: 3FL Mirror Team mirror@3fl.net
drwxr-xr-x 4096 2008/04/16 14:14:26 i386 drwxr-xr-x 4096 2008/04/16 14:14:27 x86_64
real 0m2.483s user 0m0.003s sys 0m0.118s [root@potoroo ~]#
On Tue, 2008-04-22 at 12:49 +0800, John Summerfield wrote:
and what is this mirror of: ///net/cdm/home/mirror/...
Local, the other side of my wireless link. If there's a problem there, I will notice, the machine "cdm" is my Internet gateway.
It's about this fast: [root@potoroo ~]# ls -l /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm -h -rw-r--r-- 1 1004 1004 4.3M Mar 12 03:36 /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm [root@potoroo ~]# time cp \ /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm \ /tmp/
It's mirrored from a local mirror of rsync://mirror.3fl.net.au/fedora-linux-development/*6*: 12:48 [summer@numbat ~]$ rsync \ rsync://mirror.3fl.net.au/fedora-linux-development/*6* Welcome to mirror.3fl.net rsync service IP Address: 203.31.12.18 Connections: Max 20 Location: Perth, Australia Admin: 3FL Mirror Team mirror@3fl.net
drwxr-xr-x 4096 2008/04/16 14:14:26 i386 drwxr-xr-x 4096 2008/04/16 14:14:27 x86_64
real 0m2.483s user 0m0.003s sys 0m0.118s
So 2MB/s?
During the transaction the rpms are used FROM that location directly. I wonder if that's causing the slow down.
-sv
seth vidal wrote:
On Tue, 2008-04-22 at 12:49 +0800, John Summerfield wrote:
and what is this mirror of: ///net/cdm/home/mirror/...
Local, the other side of my wireless link. If there's a problem there, I will notice, the machine "cdm" is my Internet gateway.
It's about this fast: [root@potoroo ~]# ls -l /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm -h -rw-r--r-- 1 1004 1004 4.3M Mar 12 03:36 /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm [root@potoroo ~]# time cp \ /net/cdm/home/mirror/linux/fedora/x86_64/os/Packages/zhcon-0.2.6-8.fc9.x86_64.rpm \ /tmp/
It's mirrored from a local mirror of rsync://mirror.3fl.net.au/fedora-linux-development/*6*: 12:48 [summer@numbat ~]$ rsync \ rsync://mirror.3fl.net.au/fedora-linux-development/*6* Welcome to mirror.3fl.net rsync service IP Address: 203.31.12.18 Connections: Max 20 Location: Perth, Australia Admin: 3FL Mirror Team mirror@3fl.net
drwxr-xr-x 4096 2008/04/16 14:14:26 i386 drwxr-xr-x 4096 2008/04/16 14:14:27 x86_64
real 0m2.483s user 0m0.003s sys 0m0.118s
So 2MB/s?
Well, 1.5 or so. The wireless isn't that fast, but it's not tediously slow either.
During the transaction the rpms are used FROM that location directly. I wonder if that's causing the slow down.
I haven't seen any evidence ot it having an rpm open over the network.
I've had a couple of interruptions to service, once to change BIOS settings, once when some klutz (not me) put foot to power.
I also ran yumdownloader to ensure I have the latest kernel; it runs fine.
yum has changed its behaviour:
--> Running transaction check ---> Package fedorawaves-kdm-theme.noarch 0:1.1-1.fc9 set to be updated ---> Package kdepim.x86_64 6:3.5.9-8.fc9 set to be updated ---> Package kdebase3-pim-ioslaves.x86_64 0:3.5.9-10.fc9 set to be updated --> Processing Dependency: xine-lib = 1.1.10.1 for package: xine-lib-extras-nonfree filelists.sqlite.bz2 | 12 MB 00:07 file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno -1] Meta data file does not match checksum Trying other mirror. Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 236, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 152, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 624, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 657, in resolveDeps for po, dep in self._checkFileRequires(): File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 862, in _checkFileRequires if not self.tsInfo.getOldProvides(filename) and not self.tsInfo.getNewProvides(filename): File "/usr/lib/python2.5/site-packages/yum/transactioninfo.py", line 411, in getNewProvides for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems(): File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 295, in getProvides return self._computeAggregateDictResult("getProvides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 447, in _computeAggregateDictR esult sackResult = apply(method, args) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 721, in getProvides return self._search("provides", name, flags, version) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 700, in _search for pkg in self.searchFiles(name, strict=True): File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 39, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
real 2m46.220s user 1m58.910s sys 0m2.303s [root@potoroo ~]#
Here is how it started: [root@potoroo ~]# time yum --disablerepo=rawhide* -y upgrade Loaded plugins: refresh-packagekit, refresh-updatesd Config time: 0.526 repo time: 0.022 Yum Version: 3.2.14 COMMAND: yum --disablerepo=rawhide* -y upgrade Installroot: / Reading Local RPMDB rpmdb time: 0.000 Setting up Package Sacks pkgsack time: 24.739 Setting up Upgrade Process Building updates object up:Obs Init time: 2.479 up:simple updates time: 0.229 up:obs time: 0.006 up:condense time: 0.000 updates time: 12.290 Resolving Dependencies --> Running transaction check ---> Package PackageKit-libs.x86_64 0:0.1.12-1.20080412git.fc9 set to be updated ---> Package kdenetwork.x86_64 7:4.0.3-5.fc9 set to be updated ---> Package system-config-network.noarch 0:1.5.6-1.fc9 set to be updated ---> Package lohit-fonts-malayalam.noarch 0:2.2.0-1.fc9 set to be updated ---> Package glibc-devel.x86_64 0:2.8-1 set to be updated ---> Package selinux-policy.noarch 0:3.3.1-33.fc9 set to be updated
I'm going away for a few days; when I return there should be a new kernel for me to try. If that works, I want to clear this up (and I assume "yum clean something" will do it) so that I can get all my updates installed and get to evaluating the prospective f9.
Is there a sound way to save stuff, to allow us to continue sorting this out, and how should I do it? Disk space is getting short, but I think I can filch some from my 500 Gb NTFS drive. Or delete a VM or two.
When I'm back, I'll contemplate making my repo accessible by http (prospective fight with selinux) and/or make it my side of the wireless network, if you still think it's worth trying.
On Wed, 23 Apr 2008 14:19:07 +0800, John Summerfield wrote:
yum has changed its behaviour:
filelists.sqlite.bz2 | 12 MB 00:07 file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno -1] Meta data file does not match checksum Trying other mirror.
Pardon? This is something bad at your end, in your local repo if you get metadata checksum errors with your own mirror.
File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
Looks much like you've got corrupted sqlite metadata in your yum cache.
Michael Schwendt wrote:
On Wed, 23 Apr 2008 14:19:07 +0800, John Summerfield wrote:
yum has changed its behaviour:
filelists.sqlite.bz2 | 12 MB 00:07 file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno -1] Meta data file does not match checksum Trying other mirror.
Pardon? This is something bad at your end, in your local repo if you get metadata checksum errors with your own mirror.
You'd think so, but I'm not sure. According to rsync, I have a correct and complete copy of my IAP's mirror. While it's possible that mirror is crook, the folk who care for it do update it regularly with rsync. It should be okay[1]
File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
Looks much like you've got corrupted sqlite metadata in your yum cache.
Quite possibly, but if so then yum should diagnose it. I'm not referring to _this_ run where it crashed, but others where it (apparently) looped.
[1] Well well well. Well. It doesn't really explain why the problem has arisen, but it looks like the mirror hasn't been updated in a while. [root@mail.js.id.au ~]# rsync rsync://mirror.3fl.net.au/fedora-linux-development/*6*/os/repodata/ Welcome to mirror.3fl.net rsync service IP Address: 203.31.12.18 Connections: Max 20 Location: Perth, Australia Admin: 3FL Mirror Team mirror@3fl.net
rsync: opendir "/i386/os/repodata/.~tmp~" (in fedora-linux-development) failed: Permission denied (13) drwxr-xr-x 4096 2008/04/17 10:06:28 . drwx------ 4096 2008/04/17 10:06:28 .~tmp~ -rw-r--r-- 1309343 2008/04/13 17:12:41 comps.xml -rw-r--r-- 304708 2008/04/13 17:12:40 comps.xml.gz -rw-r--r-- 10792151 2008/04/13 17:00:45 filelists.sqlite.bz2 -rw-r--r-- 8990614 2008/04/13 16:47:28 filelists.xml.gz -rw-r--r-- 3504574 2008/04/13 16:49:14 other.sqlite.bz2 -rw-r--r-- 3625910 2008/04/13 16:47:28 other.xml.gz -rw-r--r-- 6411031 2008/04/13 17:12:39 primary.sqlite.bz2 -rw-r--r-- 3616243 2008/04/13 16:47:28 primary.xml.gz -rw-r--r-- 2424 2008/04/13 17:12:41 repomd.xml rsync error: some files could not be transferred (code 23) at main.c(1146) [root@mail.js.id.au ~]#
It seems that the source of the files I should mirror while I wasn't looking. I've changed that, and it's updating now.
I'm curious as to how I got an apparently corrupt repo though. Yum appeared to know what files it should be updating, the update list from an official mirror (pacific.net.au) seemed to be much the same.
On Wed, 2008-04-23 at 22:14 +0800, John Summerfield wrote:
Michael Schwendt wrote:
On Wed, 23 Apr 2008 14:19:07 +0800, John Summerfield wrote:
yum has changed its behaviour:
filelists.sqlite.bz2 | 12 MB 00:07 file:///net/cdm/home/mirror/linux/fedora/x86_64/os/repodata/filelists.sqlite.bz2: [Errno -1] Meta data file does not match checksum Trying other mirror.
Pardon? This is something bad at your end, in your local repo if you get metadata checksum errors with your own mirror.
You'd think so, but I'm not sure. According to rsync, I have a correct and complete copy of my IAP's mirror. While it's possible that mirror is crook, the folk who care for it do update it regularly with rsync. It should be okay[1]
File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 450, in searchFiles cur = cache.cursor() AttributeError: 'NoneType' object has no attribute 'cursor'
Looks much like you've got corrupted sqlite metadata in your yum cache.
Quite possibly, but if so then yum should diagnose it. I'm not referring to _this_ run where it crashed, but others where it (apparently) looped.
This particular bug was fixed by James Antill in yum upstream. It hasn't made it to rawhide, yet.
-sv
seth vidal wrote:
This particular bug was fixed by James Antill in yum upstream. It hasn't made it to rawhide, yet.
Okay, I'll proceed as if this problem doesn't exist. By Sun (when I'm back) my kernel bug might be fixed and all will be well again.
John Summerfield wrote:
seth vidal wrote:
This particular bug was fixed by James Antill in yum upstream. It hasn't made it to rawhide, yet.
Okay, I'll proceed as if this problem doesn't exist. By Sun (when I'm back) my kernel bug might be fixed and all will be well again.
The update that worked took 68 minutes. Compared with a new install it's pretty slow, and might not be too flash on a Pentium III (this is an Intel vPro system, new SATA disks.
The update that worked was helped by a preceding one that downloaded everything and then muttered something about dependency problems regarding some xine package and died.
On Thu, 2008-04-24 at 08:16 +0800, John Summerfield wrote:
John Summerfield wrote:
seth vidal wrote:
This particular bug was fixed by James Antill in yum upstream. It hasn't made it to rawhide, yet.
Okay, I'll proceed as if this problem doesn't exist. By Sun (when I'm back) my kernel bug might be fixed and all will be well again.
The update that worked took 68 minutes. Compared with a new install it's pretty slow, and might not be too flash on a Pentium III (this is an Intel vPro system, new SATA disks.
Where was the 68 minutes being used?
The update that worked was helped by a preceding one that downloaded everything and then muttered something about dependency problems regarding some xine package and died.
More specifics would be helpful.
-sv
seth vidal wrote:
On Thu, 2008-04-24 at 08:16 +0800, John Summerfield wrote:
John Summerfield wrote:
seth vidal wrote:
This particular bug was fixed by James Antill in yum upstream. It hasn't made it to rawhide, yet.
Okay, I'll proceed as if this problem doesn't exist. By Sun (when I'm back) my kernel bug might be fixed and all will be well again.
The problem with the sqlfiles stuff recurred; I then changed to a different (local) mirror, _my_ side of the wireless link, and ran "yum clean metadata" which I expected to clear the problem.
Those two actions did indeed clear it.
The update that worked took 68 minutes. Compared with a new install it's pretty slow, and might not be too flash on a Pentium III (this is an Intel vPro system, new SATA disks.
Where was the 68 minutes being used?
Beginning to end. Where would I get better info now the system's been powered down for some days?
The update that worked was helped by a preceding one that downloaded everything and then muttered something about dependency problems regarding some xine package and died.
More specifics would be helpful.
Fair request, I was in a rush and didn't have the info before me. xine's not likely relevant to the thread. It seems that the above actions cleared this too.
?? While running a new update to try to reproduce the problem, I see it's installing lots of unwanted 386 packages. This leads to the question, why did yum-basearchonly get removed? [root@potoroo ~]# grep yum-basearchonly /var/log/yum.log* .bash_history /var/log/yum.log:Apr 09 10:04:03 Erased: yum-basearchonly /var/log/yum.log-20080225:Feb 24 08:23:07 Updated: yum-basearchonly - 1.1.11-1.fc9.noarch /var/log/yum.log-20080327:Mar 10 22:31:01 Updated: yum-basearchonly-1.1.11-5.fc9.noarch /var/log/yum.log-20080327:Mar 27 01:01:57 Updated: yum-basearchonly-1.1.13-2.fc9.noarch .bash_history:rpm -qi yum-basearchonly .bash_history:yum install yum-basearchonly.noarch .bash_history:rpm -qi yum-basearchonly.noarch [root@potoroo ~]#
It looks to have happened as part of an upgrade, not as a moment of my stupidity: Apr 09 09:58:39 Updated: system-config-display-1.0.51-9.fc9.noarch Apr 09 09:58:43 Updated: gnome-desktop-devel-2.22.1-1.fc9.x86_64 Apr 09 09:58:54 Updated: orca-2.22.1-2.fc9.x86_64 Apr 09 10:04:03 Erased: yum-basearchonly Apr 09 10:09:12 Updated: kernel-xen-2.6.25-0.18.rc8.fc9.x86_64 Apr 09 10:09:13 Updated: kernel-2.6.25-0.204.rc8.git4.fc9.x86_64 Apr 11 21:46:55 Updated: kernel-2.6.25-0.218.rc8.git7.fc9.x86_64
There were quite a few updates that day, I won't bore you with the whole list: [root@potoroo ~]# grep 'Apr 09 ' /var/log/yum.log | wc -l 177 [root@potoroo ~]#
It's only resulted in an extra 55 packages so far. but still ....
Package yum-basearchonly is obsoleted by yum, trying to install yum-3.2.14-10.fc9.noarch instead Package yum-3.2.14-10.fc9.noarch already installed and latest version Nothing to do [root@potoroo ~]#
Oh, so that's why it got removed. Shame about the loss of my expressed preference. Is this worth reporting to bz? Where is the documentation on how to do that now (I have looked at the supplied documentation)?
John Summerfield wrote:
seth vidal wrote:
The update that worked was helped by a preceding one that downloaded everything and then muttered something about dependency problems regarding some xine package and died.
More specifics would be helpful.
Fair request, I was in a rush and didn't have the info before me. xine's not likely relevant to the thread. It seems that the above actions cleared this too.
Well just look at this! ---> Package anaconda-runtime.x86_64 0:11.4.0.76-1.fc9 set to be updated ---> Package totem-gstreamer.x86_64 0:2.23.2-2.fc9 set to be updated --> Finished Dependency Resolution xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 from installed has depsolving problems --> Missing Dependency: xine-lib = 1.1.10.1 is needed by package xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 (installed) Depsolve time: 67.050 Error: Missing Dependency: xine-lib = 1.1.10.1 is needed by package xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 (installed)
real 2m9.731s user 2m8.378s sys 0m1.968s
The commandline is this: time (yes '' | yum --disablerepo=rawhide* upgrade --exclude=*.i386) 2>&1 | tee /tmp/yum-log
The change is the addition of "--exclude=*.i386."
On Sun, 2008-04-27 at 14:03 +0800, John Summerfield wrote:
John Summerfield wrote:
seth vidal wrote:
The update that worked was helped by a preceding one that downloaded everything and then muttered something about dependency problems regarding some xine package and died.
More specifics would be helpful.
Fair request, I was in a rush and didn't have the info before me. xine's not likely relevant to the thread. It seems that the above actions cleared this too.
Well just look at this! ---> Package anaconda-runtime.x86_64 0:11.4.0.76-1.fc9 set to be updated ---> Package totem-gstreamer.x86_64 0:2.23.2-2.fc9 set to be updated --> Finished Dependency Resolution xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 from installed has depsolving problems --> Missing Dependency: xine-lib = 1.1.10.1 is needed by package xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 (installed) Depsolve time: 67.050 Error: Missing Dependency: xine-lib = 1.1.10.1 is needed by package xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 (installed)
real 2m9.731s user 2m8.378s sys 0m1.968s
The commandline is this: time (yes '' | yum --disablerepo=rawhide* upgrade --exclude=*.i386) 2>&1 | tee /tmp/yum-log
The change is the addition of "--exclude=*.i386."
if you run:
yum --skip-broken ...
does it work?
-sv
seth vidal wrote:
On Sun, 2008-04-27 at 14:03 +0800, John Summerfield wrote:
John Summerfield wrote:
seth vidal wrote:
The update that worked was helped by a preceding one that downloaded everything and then muttered something about dependency problems regarding some xine package and died.
More specifics would be helpful.
Fair request, I was in a rush and didn't have the info before me. xine's not likely relevant to the thread. It seems that the above actions cleared this too.
Well just look at this! ---> Package anaconda-runtime.x86_64 0:11.4.0.76-1.fc9 set to be updated ---> Package totem-gstreamer.x86_64 0:2.23.2-2.fc9 set to be updated --> Finished Dependency Resolution xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 from installed has depsolving problems --> Missing Dependency: xine-lib = 1.1.10.1 is needed by package xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 (installed) Depsolve time: 67.050 Error: Missing Dependency: xine-lib = 1.1.10.1 is needed by package xine-lib-extras-nonfree-1.1.10.1-1.lvn8.x86_64 (installed)
real 2m9.731s user 2m8.378s sys 0m1.968s
The commandline is this: time (yes '' | yum --disablerepo=rawhide* upgrade --exclude=*.i386) 2>&1 | tee /tmp/yum-log
The change is the addition of "--exclude=*.i386."
if you run:
yum --skip-broken ...
does it work?
Yes. I like it so well that I added skip_broken=1 to yum.conf.
Might I mention that skip_broken isn't mentioned in yum.conf(5)?
Thanks Seth.
It's just taken 6m51.780s to download and install 14 packages amounting to 32 Mbytes.
On Mon, 2008-04-28 at 19:32 +0800, John Summerfield wrote:
Yes. I like it so well that I added skip_broken=1 to yum.conf.
Might I mention that skip_broken isn't mentioned in yum.conf(5)?
Thanks Seth.
It's just taken 6m51.780s to download and install 14 packages amounting to 32 Mbytes.
If you can run this command again run it like this:
echo 'y' | yum -d 3 whatever | grep 'time:'
and post the output, please
I'd like to see how long each piece is taking.
and pleas be sure to post that w/o the packages in the cache.
-sv
seth vidal wrote:
On Mon, 2008-04-28 at 19:32 +0800, John Summerfield wrote:
Yes. I like it so well that I added skip_broken=1 to yum.conf.
Might I mention that skip_broken isn't mentioned in yum.conf(5)?
Thanks Seth.
It's just taken 6m51.780s to download and install 14 packages amounting to 32 Mbytes.
If you can run this command again run it like this:
echo 'y' | yum -d 3 whatever | grep 'time:'
That's a shame. I have the equivalent to '-d 3' in yum.conf since you mentioned it last time, and the output wasn't that great. It's gone though, I can't find it in any of my "xterms."
and post the output, please
I'd like to see how long each piece is taking.
and pleas be sure to post that w/o the packages in the cache.
There are no updates pending at present, but I guess that when there are, I should precede the update with "yum clean <something>." Is there anything better than "all" from your POV?
I did note that rpm took a long time to install a kernel the other day; I've favoured using yumdownloader to get the latest kernel, then rpm to install it.
When I wondered what it was up to, it was running mkinitrd, but there's nothing to say that it hadn't just got there.
-sv
On Tue, 2008-04-29 at 21:31 +0800, John Summerfield wrote:
That's a shame. I have the equivalent to '-d 3' in yum.conf since you mentioned it last time, and the output wasn't that great. It's gone though, I can't find it in any of my "xterms."
the output is just adding a handful of debug information and it outputs all the times that each of the operations take.
There are no updates pending at present, but I guess that when there are, I should precede the update with "yum clean <something>." Is there anything better than "all" from your POV?
You don't need to 'yum clean all' you can just 'yum clean packages'
I did note that rpm took a long time to install a kernel the other day; I've favoured using yumdownloader to get the latest kernel, then rpm to install it.
That makes no sense at all. Seriously, I don't know how exactly you've determined that running the transaction with rpm is faster but it makes no sense.
-sv
seth vidal wrote:
That makes no sense at all. Seriously, I don't know how exactly you've determined that running the transaction with rpm is faster but it makes no sense.
Speed wasn't the concern.
I had a kernel bug, and was anxious to test the latest. Yum, despite my configuration, insisted on deleting the only working kernel. Someone said that there was a yum bug and that a fix was forthcoming, so I simply ran yumdownloader regularly and then rpm to install the kernel.
And just in case, I removed a working kernel from the rpm database.
Speed was completely unimportant, though not downloading lots of stuff I didn't want, by not doing an regular yum upgrade didn't bother me at all. Makes good sense to me.
John Summerfield wrote:
I had a kernel bug, and was anxious to test the latest. Yum, despite my configuration, insisted on deleting the only working kernel. Someone said that there was a yum bug and that a fix was forthcoming, so I simply ran yumdownloader regularly and then rpm to install the kernel.
Do you have a reference to the yum bug you are mentioning? Was a bug report filed?
Rahul
Rahul Sundaram wrote:
John Summerfield wrote:
I had a kernel bug, and was anxious to test the latest. Yum, despite my configuration, insisted on deleting the only working kernel. Someone said that there was a yum bug and that a fix was forthcoming, so I simply ran yumdownloader regularly and then rpm to install the kernel.
Do you have a reference to the yum bug you are mentioning? Was a bug report filed?
I don't, and I have no idea. Since it was alleged to be under control, I simply worked around it as outlined above.
John Summerfield wrote:
Rahul Sundaram wrote:
John Summerfield wrote:
I had a kernel bug, and was anxious to test the latest. Yum, despite my configuration, insisted on deleting the only working kernel. Someone said that there was a yum bug and that a fix was forthcoming, so I simply ran yumdownloader regularly and then rpm to install the kernel.
Do you have a reference to the yum bug you are mentioning? Was a bug report filed?
I don't, and I have no idea. Since it was alleged to be under control, I simply worked around it as outlined above.
Well, I wouldn't count on random claims on issues under control unless I see a associated bug report. That's a good way to lose track of problems.
Rahul
Rahul Sundaram wrote:
John Summerfield wrote:
Rahul Sundaram wrote:
John Summerfield wrote:
I had a kernel bug, and was anxious to test the latest. Yum, despite my configuration, insisted on deleting the only working kernel. Someone said that there was a yum bug and that a fix was forthcoming, so I simply ran yumdownloader regularly and then rpm to install the kernel.
Do you have a reference to the yum bug you are mentioning? Was a bug report filed?
I don't, and I have no idea. Since it was alleged to be under control, I simply worked around it as outlined above.
Well, I wouldn't count on random claims on issues under control unless I see a associated bug report. That's a good way to lose track of problems.
Maybe, but my concerns (getting to play with virtualisation) are different from yours. For my needs, a "random claim" describing observed behaviour is a sufficient justification for doing something different. I'd had to resort to a recovery disk to get a working system, the imperative was to avoid a recurrence of that condition.
seth vidal wrote:
On Tue, 2008-04-29 at 21:31 +0800, John Summerfield wrote:
That's a shame. I have the equivalent to '-d 3' in yum.conf since you mentioned it last time, and the output wasn't that great. It's gone though, I can't find it in any of my "xterms."
the output is just adding a handful of debug information and it outputs all the times that each of the operations take.
There are no updates pending at present, but I guess that when there are, I should precede the update with "yum clean <something>." Is there anything better than "all" from your POV?
You don't need to 'yum clean all' you can just 'yum clean packages'
This is what I did: [root@potoroo ~]# time (yum clean packages && yum update -d 3 -y ) 2>&1 | tee /tmp/yum-update-2008-04-30 Loaded plugins: refresh-packagekit, refresh-updatesd Config time: 0.184 Yum Version: 3.2.14 COMMAND: yum clean packages Installroot: / Ext Commands:
packages 4018 package files removed Loaded plugins: refresh-packagekit, refresh-updatesd Config time: 0.170 Yum Version: 3.2.14 COMMAND: yum update -d 3 -y Installroot: / ...
Complete!
real 22m24.203s user 2m11.413s sys 0m24.832s [root@potoroo ~]#
[root@potoroo ~]# grep -i time: /tmp/yum-update-2008-04-30 Config time: 0.184 Config time: 0.170 rpmdb time: 0.000 pkgsack time: 0.934 up:Obs Init time: 2.308 up:simple updates time: 0.866 up:obs time: 0.005 up:condense time: 0.000 updates time: 6.952 Depsolve time: 49.684 rpm_check_debug time: 1.624 Transaction Test time: 29.972 Transaction time: 450.790 [root@potoroo ~]#
Crude measure of disk speed:
[root@potoroo ~]# hdparm -t /dev/sda
/dev/sda: Timing buffered disk reads: 208 MB in 3.00 seconds = 69.28 MB/sec [root@potoroo ~]#
On Wed, 2008-04-30 at 10:26 +0800, John Summerfield wrote:
real 22m24.203s user 2m11.413s sys 0m24.832s [root@potoroo ~]#
[root@potoroo ~]# grep -i time: /tmp/yum-update-2008-04-30 Config time: 0.184 Config time: 0.170 rpmdb time: 0.000 pkgsack time: 0.934 up:Obs Init time: 2.308 up:simple updates time: 0.866 up:obs time: 0.005 up:condense time: 0.000 updates time: 6.952 Depsolve time: 49.684 rpm_check_debug time: 1.624 Transaction Test time: 29.972 Transaction time: 450.790 [root@potoroo ~]#
okay - during this: "Depsolve time: 49.684"
I'm betting it downloaded filelists.sqlite for all the repos.
But even so according to the above all the time where yum alone was working was: 63s.
when rpm was working (transaction test and transaction): 479s
So that means the download time (given your total time listed above) was 778s (or about 12 minutes and change)
I'd be curious how much stuff was downloaded but there you have it.
-sv
seth vidal wrote:
On Wed, 2008-04-30 at 10:26 +0800, John Summerfield wrote:
real 22m24.203s user 2m11.413s sys 0m24.832s [root@potoroo ~]#
[root@potoroo ~]# grep -i time: /tmp/yum-update-2008-04-30 Config time: 0.184 Config time: 0.170 rpmdb time: 0.000 pkgsack time: 0.934 up:Obs Init time: 2.308 up:simple updates time: 0.866 up:obs time: 0.005 up:condense time: 0.000 updates time: 6.952 Depsolve time: 49.684 rpm_check_debug time: 1.624 Transaction Test time: 29.972 Transaction time: 450.790 [root@potoroo ~]#
okay - during this: "Depsolve time: 49.684"
I'm betting it downloaded filelists.sqlite for all the repos.
I'd not think that necessary, I started an upgrade first to confirm that updates were available, then said "n" to cancel it. I then ran the commands I showed.
But even so according to the above all the time where yum alone was working was: 63s.
when rpm was working (transaction test and transaction): 479s
So that means the download time (given your total time listed above) was 778s (or about 12 minutes and change)
I'd be curious how much stuff was downloaded but there you have it.
Transaction Summary ============================================================================= Install 1 Package(s) Update 39 Package(s) Remove 0 Package(s)
Total download size: 159 M Downloading Packages: http://mirror.pacific.net.au/linux/fedora/linux/development/x86_64/os/Packag...: [Errno 12] Timeout: <urlopen error timed out>
On Wed, 2008-04-30 at 15:54 +0800, John Summerfield wrote:
seth vidal wrote:
On Wed, 2008-04-30 at 10:26 +0800, John Summerfield wrote:
real 22m24.203s user 2m11.413s sys 0m24.832s [root@potoroo ~]#
[root@potoroo ~]# grep -i time: /tmp/yum-update-2008-04-30 Config time: 0.184 Config time: 0.170 rpmdb time: 0.000 pkgsack time: 0.934 up:Obs Init time: 2.308 up:simple updates time: 0.866 up:obs time: 0.005 up:condense time: 0.000 updates time: 6.952 Depsolve time: 49.684 rpm_check_debug time: 1.624 Transaction Test time: 29.972 Transaction time: 450.790 [root@potoroo ~]#
okay - during this: "Depsolve time: 49.684"
I'm betting it downloaded filelists.sqlite for all the repos.
I'd not think that necessary, I started an upgrade first to confirm that updates were available, then said "n" to cancel it. I then ran the commands I showed.
But even so according to the above all the time where yum alone was working was: 63s.
when rpm was working (transaction test and transaction): 479s
So that means the download time (given your total time listed above) was 778s (or about 12 minutes and change)
I'd be curious how much stuff was downloaded but there you have it.
Transaction Summary
Install 1 Package(s) Update 39 Package(s) Remove 0 Package(s)
Total download size: 159 M Downloading Packages: http://mirror.pacific.net.au/linux/fedora/linux/development/x86_64/os/Packag...: [Errno 12] Timeout: <urlopen error timed out>
So you downloaded the files at roughly .22MB/s
okay, so what part of the transaction is it you think is too slow?
-sv
On Apr 26, 2008, at 10:41 PM, John Summerfield wrote:
?? While running a new update to try to reproduce the problem, I see it's installing lots of unwanted 386 packages. This leads to the question, why did yum-basearchonly get removed?
If memory serves, it's been obsoleted by the multilib_policy feature in yum. It defaults to 'best', so 'yum install PKG' already does what you want it to - only installs PKG.x86_64, not PKG.i386.
See here: http://skvidal.wordpress.com/2008/01/30/long-wanted-feature-added-to-yum/ also: http://www.redhat.com/archives/fedora-devel-list/2008-February/msg00168.html
-w
Will Woods wrote:
On Apr 26, 2008, at 10:41 PM, John Summerfield wrote:
?? While running a new update to try to reproduce the problem, I see it's installing lots of unwanted 386 packages. This leads to the question, why did yum-basearchonly get removed?
If memory serves, it's been obsoleted by the multilib_policy feature in yum. It defaults to 'best', so 'yum install PKG' already does what you want it to - only installs PKG.x86_64, not PKG.i386.
See here: http://skvidal.wordpress.com/2008/01/30/long-wanted-feature-added-to-yum/ also: http://www.redhat.com/archives/fedora-devel-list/2008-February/msg00168.html
Thanks Will. According to the second, it defaults to "all" which I think means "worst" or "bloated":-)
Now, if someone could _document_ it. In the package, not some place in the longlostweb..
John Summerfield wrote:
Thanks Will. According to the second, it defaults to "all" which I think means "worst" or "bloated":-)
This was before the change has been made. The current default is best as Will Woods explained.
Now, if someone could _document_ it. In the package, not some place in the longlostweb..
man yum.conf
Rahul
Rahul Sundaram wrote:
John Summerfield wrote:
Thanks Will. According to the second, it defaults to "all" which I think means "worst" or "bloated":-)
This was before the change has been made. The current default is best as Will Woods explained.
That is not the behaviour I saw.
Now, if someone could _document_ it. In the package, not some place in the longlostweb..
man yum.conf
So it is. I did look, quite hard, and didn't see it.
My failings (eg impending senility) aside, "multilib_policy" isn't something that bears any similarity to "yum-basearchonly," the name of the package it replaced, nor is it in any way self-explanatory to ordinary users. I don't think many users will recognise it either.
I must confess, that apart from some explanatory text in the config file (which, as one who upgraded I'd not have got) I'm short of good ideas on how to make it grab users.
John Summerfield wrote:
Rahul Sundaram wrote:
John Summerfield wrote:
Thanks Will. According to the second, it defaults to "all" which I think means "worst" or "bloated":-)
This was before the change has been made. The current default is best as Will Woods explained.
That is not the behaviour I saw.
Then you must have been using a older version of yum. This is a relatively recent change.
Rahul
Rahul Sundaram wrote:
John Summerfield wrote:
Rahul Sundaram wrote:
John Summerfield wrote:
Thanks Will. According to the second, it defaults to "all" which I think means "worst" or "bloated":-)
This was before the change has been made. The current default is best as Will Woods explained.
That is not the behaviour I saw.
Then you must have been using a older version of yum. This is a relatively recent change.
Rahul
[root@potoroo ~]# grep yum /var/log/yum.log | tail Apr 07 09:21:39 Updated: yum-packagekit-0.1.11-1.fc9.x86_64 Apr 09 09:57:11 Installed: yum-3.2.14-2.fc9.noarch Apr 09 10:04:03 Erased: yum-basearchonly Apr 24 00:41:27 Updated: yum-3.2.14-10.fc9.noarch Apr 24 00:42:45 Updated: yum-packagekit-0.1.12-4.20080416git.fc9.x86_64 Apr 27 19:22:00 Updated: yum-packagekit-0.1.12-7.20080425.fc9.x86_64 [root@potoroo ~]#
Somewhere after Apr 09 10:04:03 Erased: yum-basearchonly I got some .i386 packages installed.
The link Will mentioned described the behaviour I saw.
On Apr 28, 2008, at 4:08, John Summerfield <debian@herakles.homelinux.org
wrote:
Will Woods wrote:
On Apr 26, 2008, at 10:41 PM, John Summerfield wrote:
?? While running a new update to try to reproduce the problem, I see it's installing lots of unwanted 386 packages. This leads to the question, why did yum-basearchonly get removed?
If memory serves, it's been obsoleted by the multilib_policy feature in yum. It defaults to 'best', so 'yum install PKG' already does what you want it to - only installs PKG.x86_64, not PKG.i386. See here: http://skvidal.wordpress.com/2008/01/30/long-wanted-feature-added-to-yum/ also: http://www.redhat.com/archives/fedora-devel-list/2008-February/msg00168.html
Thanks Will. According to the second, it defaults to "all" which I think means "worst" or "bloated":-)
Now, if someone could _document_ it. In the package, not some place in the longlostweb..
--
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Fedora configs default to best. I could have sworn that this was documented in the yum or yum.conf man pages.
--jes
Jesse Keating wrote:
On Apr 28, 2008, at 4:08, John Summerfield debian@herakles.homelinux.org wrote:
Will Woods wrote:
On Apr 26, 2008, at 10:41 PM, John Summerfield wrote:
?? While running a new update to try to reproduce the problem, I see it's installing lots of unwanted 386 packages. This leads to the question, why did yum-basearchonly get removed?
If memory serves, it's been obsoleted by the multilib_policy feature in yum. It defaults to 'best', so 'yum install PKG' already does what you want it to - only installs PKG.x86_64, not PKG.i386. See here: http://skvidal.wordpress.com/2008/01/30/long-wanted-feature-added-to-yum/
also: http://www.redhat.com/archives/fedora-devel-list/2008-February/msg00168.html
Thanks Will. According to the second, it defaults to "all" which I think means "worst" or "bloated":-)
Now, if someone could _document_ it. In the package, not some place in the longlostweb..
Fedora configs default to best. I could have sworn that this was documented in the yum or yum.conf man pages.
--jes
I did not recognise this description (in the man page) as what I wanted: multilib_policy Can be set to 'all' or 'best'. All means install all possible arches for any package you want to install. Therefore yum install foo will install foo.i386 and foo.x86_64 on x86_64, if it is available. Best means install the best arch for this platform, only.
As you can see, it doesn't describe what the default is. I think the whole description is flawed, both the key word and its description will go over the heads of most users, even those who know to read the man page.
On Tue, 2008-04-29 at 21:41 +0800, John Summerfield wrote:
I did not recognise this description (in the man page) as what I wanted: multilib_policy Can be set to 'all' or 'best'. All means install all possible arches for any package you want to install. Therefore yum install foo will install foo.i386 and foo.x86_64 on x86_64, if it is available. Best means install the best arch for this platform, only.
As you can see, it doesn't describe what the default is. I think the whole description is flawed, both the key word and its description will go over the heads of most users, even those who know to read the man page.
Documentation patches are welcome.
-sv
-
Jesse Keating -
John Summerfield -
Michael Schwendt -
Rahul Sundaram -
Rex Dieter -
Seth Vidal -
Will Woods