4alpha2 KDE LiveCD build 1 (1st September) I think this could be difficult to reproduce but I'll check when I've installed other ISOs as it *may* be due to the mirror and give unpredictable results. I noticed some 'couldn't get media info' messages when it added the medias during finish-install but clicked through them without paying too much attention. There is no detail in the journal and it is a wired connection. When adding the online medias it didn't add any URL for Core Release. There are URLs added for Core Updates, Nonfree Release and Nonfree Updates. Could it be that if it failed to download the bit it needs from the mirror it doesn't properly add the URL or try another mirror? Additionally and possibly unrelated, it left the Live ISO medias enabled, Live Core & Live Nonfree. Reproducible: Steps to Reproduce:
CC: (none) => thierry.vignaud, tmb
This is likely due to several very large packages that were built on cauldron yesterday, so the repo was being updated on the selected mirror, which prevents it from being added. ll -Srh|grep 'Sep 1'|tail -n 5 -rw-r--r-- 1 2000 2000 19M Sep 1 07:52 libffmpeg-static-devel-2.0.1-3.mga4.i586.rpm -rw-r--r-- 2 2000 2000 25M Sep 1 09:47 w3af-1.5-3.mga4.noarch.rpm -rw-r--r-- 1 2000 2000 32M Sep 1 10:37 xmoto-0.5.10-6.mga4.i586.rpm -rw-r--r-- 2 2000 2000 125M Sep 1 22:21 hedgewars-data-0.9.19.3-1.mga4.noarch.rpm -rw-r--r-- 2 2000 2000 459M Sep 1 10:49 alienarena-data-7.65-2.mga4.noarch.rpm The only way this can prevented would be shut down the build system while iso's are in testing.
CC: (none) => davidwhodgins
Not really Dave. The URL could be added from mirrorlist anyway and the media updated later.
Here is a directory listing that shows the cause of the problem This is from distrib/cauldron/i586/media/core/release/media_info lrwxrwxrwx 1 2000 2000 18 Sep 3 09:11 20130903-131125-changelog.xml.lzma -> changelog.xml.lzma lrwxrwxrwx 1 2000 2000 14 Sep 3 09:11 20130903-131125-files.xml.lzma -> files.xml.lzma lrwxrwxrwx 1 2000 2000 9 Sep 3 09:11 20130903-131125-hdlist.cz -> hdlist.cz lrwxrwxrwx 1 2000 2000 13 Sep 3 09:11 20130903-131125-info.xml.lzma -> info.xml.lzma lrwxrwxrwx 1 2000 2000 19 Sep 3 09:11 20130903-131125-synthesis.hdlist.cz -> synthesis.hdlist.cz lrwxrwxrwx 1 2000 2000 18 Sep 3 10:49 20130903-144934-changelog.xml.lzma -> changelog.xml.lzma lrwxrwxrwx 1 2000 2000 14 Sep 3 10:49 20130903-144934-files.xml.lzma -> files.xml.lzma lrwxrwxrwx 1 2000 2000 9 Sep 3 10:49 20130903-144934-hdlist.cz -> hdlist.cz lrwxrwxrwx 1 2000 2000 13 Sep 3 10:49 20130903-144934-info.xml.lzma -> info.xml.lzma lrwxrwxrwx 1 2000 2000 19 Sep 3 10:49 20130903-144934-synthesis.hdlist.cz -> synthesis.hdlist.cz -rw-r--r-- 1 2000 2000 1839498 Sep 3 10:49 changelog.xml.lzma -rw-r--r-- 1 2000 2000 14736206 Sep 3 10:49 files.xml.lzma -rw-r--r-- 1 2000 2000 136721901 Sep 3 10:49 hdlist.cz -rw-r--r-- 1 2000 2000 1445603 Sep 3 10:49 info.xml.lzma -rw-r--r-- 1 2000 2000 576 Sep 3 10:49 MD5SUM -rw-r--r-- 60 2000 2000 1666 Feb 9 2011 pubkey -rw-r--r-- 1 2000 2000 2254618 Sep 3 10:49 synthesis.hdlist.cz As shown, while a mirror is syncing, both the new and old symlinks point to the same files, only one of which is correct. Until these files finish syncing, and the old symlinks are deleted, any one trying to add the repo will be unable to. It would make more sense to me, to have the $date-hdlist.cz files be regular files, and have the hdlist.cz be a symlink pointing to the files. That way, it would only take a few seconds to replace the symlinks, after all of the files have been transferred, provided there is some way to ensure rsync syncs the symlinks last.
Priority: Normal => HighCC: (none) => ennael1, sysadmin-bugsSeverity: normal => major
Claire, is it still valid?
Keywords: (none) => NEEDINFO
Difficult to reproduce. I suppose it would be but no real way to test other than by chance.
Closing then
Status: NEW => RESOLVEDResolution: (none) => OLDSource RPM: drakxtools ? => (none)