Bug 826668

Summary: gridengine uninstall script(s) failed, causing preupgrade to abort, cannot upgrade to f17 cleanly
Product: [Fedora] Fedora Reporter: Hin-Tak Leung <htl10>
Component: gridengineAssignee: Orion Poplawski <orion>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: orion
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-10 01:32:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hin-Tak Leung 2012-05-30 18:04:32 UTC
Description of problem:
using preupgrade to upgrade from f16 to f17. During the clean-up stage towards the end, gridengine's uninstall failed. This causes preupgrade to abort, and system does not finishe upgrade - leaving behind the grub2 'upgrade' items, does not put new kernel in the grub2 menu (although new kernel is apparently installed). All in all, it is a mess in the rpm database, and the grub2 menu.

Version-Release number of selected component (if applicable):
The two versions left behind, according to rpm -q gridengine, 
gridengine-6.2u5p2-7.fc16.3
gridengine-2011.11-3.svn131.fc17

How reproducible:
Once (obvious this is unpleasant enough I don't want to see again...)

Steps to Reproduce:
1. install older gridengine
2. try to upgrade to new with yum
3.
  
Actual results:
yum aborted.


Expected results:
yum continues, and preupgrade continues to do the clean-up and also tidy up the boot menu, put the new kernel into the boot menu, etc.

Additional info:

Comment 1 Orion Poplawski 2012-05-30 19:31:52 UTC
Are there any logs that recorded what the error was?  Are there any other gridengine rpms installed (-execd, -qmon, etc)?

Comment 2 Hin-Tak Leung 2012-05-30 19:39:23 UTC
Unfortunately preupgrade does not keep much record around; but 
I keep a list of packages before and after upgrade (rpm -qa).

$ grep gridengine beforelist
gridengine-devel-6.2u5p2-7.fc16.3.x86_64
gridengine-6.2u5p2-7.fc16.3.x86_64
gridengine-qmon-6.2u5p2-7.fc16.3.x86_64
gridengine-qmaster-6.2u5p2-7.fc16.3.x86_64
gridengine-execd-6.2u5p2-7.fc16.3.x86_64

$ grep gridengine afterlist
gridengine-6.2u5p2-7.fc16.3.x86_64
gridengine-devel-2011.11-3.svn131.fc17.x86_64
gridengine-2011.11-3.svn131.fc17.x86_64
gridengine-qmaster-2011.11-3.svn131.fc17.x86_64
gridengine-qmon-2011.11-3.svn131.fc17.x86_64
gridengine-execd-2011.11-3.svn131.fc17.x86_64

Seems that only the main package failed to clean up (and caused the rest of preupgrade to be unfinished).

Comment 3 Orion Poplawski 2012-05-30 22:33:34 UTC
Can you attach /root/upgrade.log?

Comment 4 Hin-Tak Leung 2012-05-30 23:31:56 UTC
(In reply to comment #3)
> Can you attach /root/upgrade.log?

Argh, you got it... The last two lines of that is:

/usr/bin/qsub-ge has not been configured as an alternative for qsub
error: %preun(gridengine-6.2u5p2-7.fc16.3.x86_64) scriptlet failed, exit status 2

# ls -l /etc/alternatives/qsub
lrwxrwxrwx. 1 root root 20 May 24 19:32 /etc/alternatives/qsub -> /usr/bin/qsub-torque

# ls -l /usr/bin/qsub*
lrwxrwxrwx. 1 root root      22 May 24 19:32 /usr/bin/qsub -> /etc/alternatives/qsub
-rwxr-xr-x. 1 root root 1701448 Apr 17 18:36 /usr/bin/qsub-ge
-rwxr-xr-x. 1 root root   54352 Feb  5 13:31 /usr/bin/qsub-torque

I have torque also. (for development purposes...)

Comment 5 Orion Poplawski 2012-05-31 02:21:04 UTC
Can you please attach the entire upgrade.log to this report?  Thanks.

I'm starting to think that the whole alternatives system may not have been taken into consideration with the usrmove feature.  We'll see.

Comment 6 Orion Poplawski 2012-05-31 02:30:57 UTC
Well, usrmove has nothing to do with it I think.

Comment 7 Orion Poplawski 2012-05-31 03:17:25 UTC
Any chance you have a backup of /var/lib/alternatives from before the upgrade?

Comment 8 Hin-Tak Leung 2012-05-31 09:38:20 UTC
(In reply to comment #7)
> Any chance you have a backup of /var/lib/alternatives from before the
> upgrade?

What you saw in comment 4 was essentially before the upgrade (I only started it late 29th May). 

# ls -l /var/lib/alternatives/q*
-rw-r--r--. 1 root root 858 May 24 19:32 /var/lib/alternatives/qsub

Its content only talks about torque.


# rpm -q --scripts gridengine
...
preuninstall scriptlet (using /bin/sh):
alternatives --remove qsub /usr/bin/qsub-ge
...

I assume this is where it failed - the packager did not think of somebody installing two grid-computing packages simultaneously... it probably should do

alternatives --remove qsub /usr/bin/qsub-ge || /bin/true

instead, or something?

Comment 9 Fedora Update System 2012-05-31 22:36:17 UTC
gridengine-6.2u5-10.fc15.5 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/gridengine-6.2u5-10.fc15.5

Comment 10 Fedora Update System 2012-05-31 22:36:28 UTC
gridengine-6.2u5p2-7.fc16.4 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/gridengine-6.2u5p2-7.fc16.4

Comment 11 Fedora Update System 2012-06-01 16:56:05 UTC
Package gridengine-6.2u5-10.fc15.5:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gridengine-6.2u5-10.fc15.5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-8688/gridengine-6.2u5-10.fc15.5
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2012-06-10 01:32:34 UTC
gridengine-6.2u5-10.fc15.5 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2012-06-10 01:35:35 UTC
gridengine-6.2u5p2-7.fc16.4 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.