David Kinnvall wrote:
> Troy Dawson wrote:
>
>> Howdy,
>
>
> Hi Troy, and list,
>
>> I have gotten the yum section done for the "How To Upgrade To The Latest
>> Release".  I've also written an apt section, but I haven't tested that
>> yet.
>
>
> [openafs stuff]
>
>> It is at
>> https://plone.fnal.gov/Plone/Scientific%20Linux/sl.info/sl.about.howto/upgrade/view
>>
>>
>> If you try it and it works or doesn't, let me know.
>
>
> Tried it on my two SL machines with no major problems. Noticed
> two minor things:
>
> 1. The upgrade of SL_inittab_change produced an error:
>
> SL_inittab_change 100 % done 83/182
> mv: cannot stat `/etc/inittab.rpmsave': No such file or directory
> error: %post(SL_inittab_change-1.0-4) scriptlet failed, exit status 1
>
>  From reading the corresponding script, my guess is that the
> final statement "mv /etc/inittab.rpmsave /etc/inittab.old"
> should be moved inside the if/fi block, since the initial
> "mv /etc/inittab /etc/inittab.rpmsave" is inside it, which
> means that /etc/inittab.rpmsave is unlikely to exist unless
> the if-block is triggered - as the case was for me, since I
> already had the sulogin line in there.
>

Thanks for seeing that.  Yes, I don't know why that move statement was outside
the if/fi block.  I have fixed the rpm, but since this isn't a security fix,
just a reduction in error messages, this probrubly won't get in until our next
minor release (SL 303).

> 2. The second thing is /etc/redhat-release, which after the
> upgrade still contains "Scientific Linux SL release 3.0.1 (SL)"
> rather than the expected "Scientific Linux SL release 3.0.2 (SL)"
> and the rpm version is still at sl-release-3.0.1-9, which I
> guess is not the intended result?
>

Yup, I saw that one right before I left for home.  This looks like a 301 to
anything higher problem.  the sl-release of 301 was built as a i386.rpm, while
we changed it to a noarch.rpm for 302 and higher.  (This was because in 301,
we only had i386, but when we started doing other architecture's, we realized
it needed to be a no-arch)
We have yum set to 'exact arch' which means it won't change the arch on
something.  This saves alot of headache for things like glibc, but we
occasionally have problems like this.

After looking at the various ways to do the sl-release update, I believe the
easiest is to just do a straight rpm command.  So you need to do the following.

rpm -Uvh
ftp://ftp.scientificlinux.org/linux/scientific/302/i386/SL/RPMS/sl-release-3.0.2-9.2.noarch.rpm

I'll make some tweeks to the documentation.


> Apart from the above, which caused no actual problems for me,
> the upgrade went smoothly, including kernel install and grub
> config adjustment. After shutdown -r now the machines came up
> with the new kernel without a hitch. Thanks for the great work!
>
> Regards,
>
> David Kinnvall

Thanks for testing.
Troy

--
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________