Status SL6.1

Mine (see earlier post)!!

I was sitting enjoying a lovely steak, blissfully unaware SL6.0 was carrying out the update process automatically.

The update worked perfectly.

Talk about stress-free

No, mine is easier (local SL mirror and all computers point to that one)

I just did it lemonzest's way. After the update I reset the priorities of the sl repo files to what they were and then deleted the old .repo files and renamed the .rpmnew and .rpmsave files. All seems well. I noticed also a new elrepo.repo (elrepo.repo.rpmnew) which I treated as above.

The epel repository has the dreaded ": Cannot retrieve metalink for repository: epel." problem, so I will need to sort that out - yum clean all must have done that.

Hope I didn't muck up with the repo files.

All's well - no problems. Just copied the epel files from /var/cache/yum/x86_64/6.0/epel to the 6.1 directory.

I have had no luck with my update to SL6.1 on my EeePC. It failed due to package conflicts. I had installed VLC and gstreamer-plugins from atrpms repo (in March when SL 6.0 came out) but then too many SL RPMs have been overwritten. Uninstalling VLC and gstreamer plugins (with yum erase --remove-with-leaves) did not help. Conclusion: beware of the atrpms repo or use it only in combination with yum-plugin-protectbase or -priorities.

So I decided for a new installation with a self-made LiveCD. But the installation from the LiveCD (icon "Install to Hard Drive") fails due to a Python exception in setCapsLockLabel (selected was german keyboard layout). Same happens with the official SL 6.1 LiveCD. Fortunately the Installation can be started also from the boot menu of the LiveCD - and this is working though the installer has a 2nd bug: if LiveCD is installed to an USB stick with LiveUSB Creator, the installer mounts the LiveCD as /boot/efi by default which can - of cause - not work and aborts the installation. But it is possible and necessary to clear the mount point in the "Create Custom (partition) Layout" dialog.

After these 2 workarounds the installation worked fine as usual.

upgrade from 6.0 to 6.1 result:

yum clean all
yum --relasever=6.1 distro-sync


installed, updated, reboot... kernel panic
segfault in 4 ip 00e0ed16 sp bfd7e 304 error 4 in in ld-2.12.so (dff000+1e000)
attempted to kill init


anyone has an idea what could possibly go wrong?

The ld-2.12.so file comes from the glibc file.
Not sure what happened here.
I do remember reading upgrading glibc before the rest when going from one subversion of CentOS to another one (CentOS 5.x to 5.y). Of course I never did and there were never problems. Perhaps something happened here?

Provided, it is not a hardware problem (disk full or defect? power failure during update?) one possible cause could be kdump. kdump is known to cause kernel panics on system with "low" memory. I have encountered this problem on my very first SL 6.0 installation attempt. Since then I have disabled and uninstalled kdump service on my SL 6 installations.

Can you boot with a previous kernel and/or start in run level 2 or 3?
If not, can you boot from the SL 6.1 or SL 6.0 LiveCD?

Note: if /boot/grub/grub.conf contains a line "timeout=0" (which is default) you will not get into the GRUB menu. Then you have to boot from a LiveCD and edit /boot/grub/grub.conf and change it to e.g. timeout=4

I couldn't save it, there was no way to boot that machine up.
i've tried to boot older kernels but always ended up with same error.
then i tried to boot with sl 6.0 rescue environment, i wasn't able to repair the damage.
so, i reinstalled it in the end.
this is my first scientific linux install. so far i was using centos. with centos i never had to type anything but "yum update -y". after that all updates were done, all upgrades were done. i am surprised that SL guys didn't do it that way too.

Great news to see SL 6.1 finalized. I will probably update soon myself but for now I'm kicking back with 6.0 until I have the time to schedule to baby sit it for any problems. Looks like for the most part everyone is upgrading okay.

Schmidt, that error sure is strange. Unfortunate that you got caught by whatever happened there. Not saying it couldn't be a problem with the SL update process but I have to wonder as well if maybe your disk is going bad somewhere? :\ I'd be interested to see SMART info just out of curiosity.

You can't expect SL to follow the same path CentOS uses because they are both clones of RHEL. CentOS aims to be 100% identical to RHEL. SL has a different approach. They use the same sources, but add/change things that suit their needs (to be used within CERN and Fermilab). SL is officially not intended/created for the outside world (something many don't know or ignore). Another big difference is the support for each (sub) version. When CentOS releases a new subversion (6.1, 6.2), support for the previous subversion is dropped. SL continues to support the previous subversion.

Of course I can't say what happened with your system, but since 6.1 came out all systems running 6.0 (i386, x86_64, server, workstations and laptops) have been updated by using "yum update" (the -y flag won't ask for yes/no) and did not have any problem.

mmm.. unless misunderstood, could be a problem?
Consider this simplified scenario:

1. Install 6.0 ex DVD
2. #> yum --delete $nowants ..............(simplified case)
3. = customised SL6 .......(usual custom configuration + 6.0)
4. Manually edit repos replacing every "6.0" with "6x" (safest?)
5. UPGRADE
A#> yum clean all
B#> yum update
C#> ??
6. = customised SL6 .......(usual custom configuration + 6.1)


QUESTION: At 5C must I repeat the command at 2 to get 6 correctly?
Or have I misinterpreted what happens in terms of above quote?

Just edit the repo files and let it point to 6x.
That way you will always have the latest updates.

Yes, thanks, I got that part. What I am really asking is if I get more than I want and then need to re-customise. There may be packages I have removed etc for specific reasons and dont want installed. Could they get re-installed behind my back so to speak?

If you remove a package and nothing else follows with it there should be no dependency. Updating the system will only install a previous remove package IF another/updated package would require it. And since we are talking about a subversion (6.0 -> 6.1) the updated packages will be improved but also on a subversion level.

Ah .. so it is an intelligent upgrade! That's exactly what I was hoping for. Thanks indeed. I did have some mysterious goings on in relation to a local-repo derived from DVD but think I can figure it out now! (Actually, the local-repo went to sleep during the 3 hour upgrade download and then wasn't available when needed by yum for the dependencies located there).

On a side note: I see torrents are now out for 6.1 over at OSST finally: http://www.osst.co.uk/Download/scientific/6.1/?id=28

Seeding all of the files

I'm just now getting to upgrade to 6.1 x64, from a hotel room in Bismarck, ND. I've been on the road the last 3 weeks and internet has been flaky....but now everything is going smoothly. Yee haaa.