Is there something wrong with sl-indexhtml?
# yum install sl-indexhtml Loaded plugins: priorities, refresh-packagekit, security 44 packages excluded due to repository priority protections Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package sl-indexhtml.noarch 0:6-6.5.sl6.1 will be installed --> Finished Dependency Resolution ... Error unpacking rpm package sl-indexhtml-6-6.5.sl6.1.noarch error: unpacking of archive failed on file /usr/lib/firefox/defaults/preferences/firefox-branding.js;52f3e263: cpio: lstat Verifying : sl-indexhtml-6-6.5.sl6.1.noarch 1/1 Failed: sl-indexhtml.noarch 0:6-6.5.sl6.1 -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Re: Is there something wrong with sl-indexhtml?
On Thu, 6 Feb 2014, ToddAndMargo wrote: # yum install sl-indexhtml Loaded plugins: priorities, refresh-packagekit, security 44 packages excluded due to repository priority protections Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package sl-indexhtml.noarch 0:6-6.5.sl6.1 will be installed --> Finished Dependency Resolution ... Error unpacking rpm package sl-indexhtml-6-6.5.sl6.1.noarch error: unpacking of archive failed on file /usr/lib/firefox/defaults/preferences/firefox-branding.js;52f3e263: cpio: lstat Verifying : sl-indexhtml-6-6.5.sl6.1.noarch 1/1 Failed: sl-indexhtml.noarch 0:6-6.5.sl6.1 Do you know which exact repo this was gotten from? -Connie Sieh
Re: Is there something wrong with sl-indexhtml?
On 02/06/2014 12:13 PM, Connie Sieh wrote: On Thu, 6 Feb 2014, ToddAndMargo wrote: # yum install sl-indexhtml Loaded plugins: priorities, refresh-packagekit, security 44 packages excluded due to repository priority protections Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package sl-indexhtml.noarch 0:6-6.5.sl6.1 will be installed --> Finished Dependency Resolution ... Error unpacking rpm package sl-indexhtml-6-6.5.sl6.1.noarch error: unpacking of archive failed on file /usr/lib/firefox/defaults/preferences/firefox-branding.js;52f3e263: cpio: lstat Verifying : sl-indexhtml-6-6.5.sl6.1.noarch 1/1 Failed: sl-indexhtml.noarch 0:6-6.5.sl6.1 Do you know which exact repo this was gotten from? -Connie Sieh Hi Connie, Suppose I should have included that. :'[ -T Dependencies Resolved PackageArch VersionRepository Size Installing: sl-indexhtml noarch 6-6.5.sl6.1sl-security84 k Transaction Summary -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Glitch in autoupdate from 6.4 to 6.5
Hi, there! As you may know, current SL6.4 default installation configures yum for "6.x". In this mode, when 6.5 comes out, the system will automatically self-update. While new to SL, SLC (CERN) have done it this way since the 5.x days with good effect. For example, the few computers I run at CERN just recently self-updated to 5.10 and 6.5 without any issues. So, with some trepidation, I was waiting for SL6.5 to show up and see if my computers will self-update successfully or crash and burn in flames. So 6.5 is here, and I am so disappointed because exactly nothing happened. And a few glitches I need to report: a) the self update to 6.5 is not happening because "yum" broke - the error is: Error: failure: repodata/b2f5801fbcee3722b2bd03d00d2a725c211a795bcdb6918c45558d9fb5499f7d-filelists.sqlite.bz2 from triumfcs-mirror-sl-devtoolset: [Errno 256] No more mirrors to try. I guess some kind of mismatch in the devtoolset repository. To get past this this error, I do "yum clean all". (nightly scripts used to do a "yum clean", but that was taken out recently?) b) next glitch is with the configuration of our local mirror of SL repositories. "yum update" runs correctly, but then starts downloading packages from the main SL site instead of using the local mirror. It turns out that the local mirror is defined like this: [triumfcs-mirror-sl] name=Scientific Linux $releasever - $basearch baseurl=file:///triumfcs/mirror/SL/$releasever/$basearch/os So until sl-release is updated, it points to the previous release ($releasever). A fix is to "yum update sl-release", then "yum update" starts using the local mirror and the reset of the update runs successfully. Since 6.4 and 6.5 are "frozen" I doubt anything can be done to fix these glitches, but maybe for 6.6 something can be done? Certainly glitch (b) is kind of nasty as everything appears to work correctly, except for overloading the central SL distribution servers and for running up unnecessary network traffic charges. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Glitch in autoupdate from 6.4 to 6.5
On 2014-02-06 21:35, Konstantin Olchanski wrote:
> Hi, there! As you may know, current SL6.4 default installation configures yum
> for "6.x". In this mode,
> when 6.5 comes out, the system will automatically self-update. While new to
> SL, SLC (CERN)
> have done it this way since the 5.x days with good effect. For example, the
> few computers I run
> at CERN just recently self-updated to 5.10 and 6.5 without any issues.
>
> So, with some trepidation, I was waiting for SL6.5 to show up and see if my
> computers
> will self-update successfully or crash and burn in flames.
>
> So 6.5 is here, and I am so disappointed because exactly nothing happened.
>
> And a few glitches I need to report:
>
> a) the self update to 6.5 is not happening because "yum" broke - the error
> is: Error: failure:
> repodata/b2f5801fbcee3722b2bd03d00d2a725c211a795bcdb6918c45558d9fb5499f7d-filelists.sqlite.bz2
> from triumfcs-mirror-sl-devtoolset: [Errno 256] No more mirrors to try.
>
> I guess some kind of mismatch in the devtoolset repository.
>
> To get past this this error, I do "yum clean all". (nightly scripts used to
> do a "yum clean", but that was taken out recently?)
>
> b) next glitch is with the configuration of our local mirror of SL
> repositories. "yum update"
> runs correctly, but then starts downloading packages from the main SL site
> instead of using the local mirror.
>
> It turns out that the local mirror is defined like this:
>
> [triumfcs-mirror-sl]
> name=Scientific Linux $releasever - $basearch
> baseurl=file:///triumfcs/mirror/SL/$releasever/$basearch/os
>
> So until sl-release is updated, it points to the previous release
> ($releasever).
>
> A fix is to "yum update sl-release", then "yum update" starts using the local
> mirror and
> the reset of the update runs successfully.
>
> Since 6.4 and 6.5 are "frozen" I doubt anything can be done to fix these
> glitches, but maybe for 6.6 something can be done?
>
> Certainly glitch (b) is kind of nasty as everything appears to work
> correctly, except for
> overloading the central SL distribution servers and for running up
> unnecessary network traffic charges.
>
There is hope,
try running
$ yum --releasever=${RELVER} update sl-release
Since I'm running also a internal mirror the first thing I do is to
disable all external repos with by extending the site conf with 'enabled=0'.
The second is to install a conf file pointing to my mirror and and using
explicit release ver.
Updating is done with a small script this way
#!/bin/sh
RELVER=6.5
# allow yum to install everything without asking
YesToAll="-y"
yum clean all
# scientific update to latest release
yum ${YesToAll} --releasever=${RELVER} update sl-release
yum ${YesToAll} clean all
yum ${YesToAll} update glibc\* yum\* rpm\* python\*
yum ${YesToAll} install yum-plugin-downloadonly
yum ${YesToAll} clean all
yum ${YesToAll} --downloadonly update
#yum ${YesToAll} update
#shutdown -r now
--
Regards,
olli
