#777 PackageInUn workaround / opkgs use generic-setup
The version of PackageInUn in oscar-4.2.1 doesn't
appear to like having multiple RPMs in the opkg/RPMS/
directory. It sometimes picks the wrong arch, e.g., on
x86 it selects x86_64 RPMs, which fail to install.
This behaviour seems to occur for those opkgs that are
still using custom 'setup' scripts, instead of simply
calling "generic-setup" from their 'setup' scripts.
This has to do with the fact (in part) that
'generic-setup' just copies directly to '/tftpboot/rpm'
and not to opkg/RPMS/ (which subsequently get copied to
'/tftpboot/rpm')...ick...ick...ick.
To reproduce the problem, on oscar-4.2.1b5 on FC4/x86.
1) Fully install oscar-4.2.1b5.
2) Confirm all tests pass.
3) Exit Wizard and logout (for safe keeping).
4) Login again and re-run 'install_cluster'
5) Select Add/Del opkg (i.e., PackageInUn).
6) Select (uninstall) "PVM" from the PackageInUn
window selector
7) Confirm all tests pass. -- namely PVM shouldn't
appear.
8) Exit Wizard and logout (for safe keeping).
9) Login again and re-run 'install_cluster
10) Select Add/Del opkg (i.e., PackageInUn).
11) Select (install) "PVM" from the PackageInUn window
selector
12) You will see errors in the console, also 'pvm'
will not be installed on server/clients.
Discussion
Logged In: YES
user_id=288102
The proposed switch to 'generic-setup' will possibly help,
but only for the "included" packages. I'm also concerned
about other packages that might dump non x86 arch rpms to
/tftpboot/rpm.
The problem seems to be that the PackageInUn:get_rpm_list()
routine is bad. If I read it properly, it has issues when
(a) there are files in the opkg/RPMS/ dir., namely if there
are ia64 rpms...stripped out.
(b) it somehow selects the wrong rpms to be installed
(probably a regex, will check shortly). See example output
below:
Output taken from log on FC4/x86 install to install PVM
(previously uninstalled via PackageInUn successfully).
Notice the x86_64 RPMS that were selected from
/tftpboot/rpm, and ultimately fail. I removed any occurance
of the opkg/RPMS/ (i.e., did the aforementioned
generic-setup change) so the selection is totally based on
files that are in /tftpboot/rpm.
--> Running install on clients
RPMS that need to be installed:
- /tftpboot/rpm/pvm-modules-oscar-3.4.5+4-1.i686.rpm
- /tftpboot/rpm/pvm-3.4.5+4-1.x86_64.rpm
RPMS that will be installed:
- /tftpboot/rpm/pvm-modules-oscar-3.4.5+4-1.i686.rpm
- /tftpboot/rpm/pvm-3.4.5+4-1.x86_64.rpm
executing:/opt/c3-4/cexec --pipe c3cmd-filter mkdir -p
/tmp/tmpinstallrpm/
executing:/opt/c3-4/cpush
/tftpboot/rpm/pvm-modules-oscar-3.4.5+4-1.i686.rpm /tm
p/tmpinstallrpm/
executing:/opt/c3-4/cpush
/tftpboot/rpm/pvm-3.4.5+4-1.x86_64.rpm /tmp/tmpinstall
rpm/
executing:/opt/c3-4/cexec --pipe c3cmd-filter rpm -Uvh
/tmp/tmpinstallrpm/pvm-m
odules-oscar-3.4.5+4-1.i686.rpm
/tmp/tmpinstallrpm/pvm-3.4.5+4-1.x86_64.rpm
oscar_cluster oscarnode1: error: Failed dependencies:
oscar_cluster oscarnode1: libc.so.6()(64bit) is needed
by pvm-3.4.5+4-1.x8
6_64
oscar_cluster oscarnode1:
libc.so.6(GLIBC_2.2.5)(64bit) is needed by pvm-3
.4.5+4-1.x86_64
oscar_cluster oscarnode1: libc.so.6(GLIBC_2.3)(64bit)
is needed by pvm-3.4
.5+4-1.x86_64
Error: cannot install to the nodes.
Error: package (pvm) failed to install.
Error: cannot install to the nodes.
Error: package (pvm) failed to install.
....cut here....
Logged In: YES
user_id=288102
I added a bit of debug printing to track what's happening in
PackageInUn:get_rpm_list(). It appears the problem stems
from the use of an associative-array to do the lookup for
which RPM (path/filename) to use for installation.
Basically, you get {key} = {/path/to/file.rpm}. The key is
the "name" of the RPM, e.g., "pvm" or "pvm-modules-oscar".
When there is a key collision (same key, diff filename) the
files get mixed up. Thus, in some cases you'll have
i686.rpm and x86_64.rpm files selected (see below) because
of the sort/ording of keys in the associative-array (which
are not alpha sorted btw). ;)
I don't have a fix yet but this is the problem, that I'm
having with PVM, and probably others that are copying
multiple files down to /tftpboot/rpm, i.e., this bug isn't
specific to PVM.
Debug Output (FC4/x86 system):
DBGTJN-1064: rpm_list_database(pvm-modules-oscar pvm)
DBGTJN-1115: ELSE - WE READ FROM /tftpboot/rpm
DBGTJN-1116: - AND ENDED UP WITH
pvm-modules-oscar-3.4.5+4-1.x86_64.rpm
pvm-modules-oscar-3.4.5+4-1.i686.rpm
pvm-modules-oscar-3.4.5+4-1.x86_64.rpm
pvm-modules-oscar-3.4.5+4-1.i686.rpm
pvm-3.4.5+4-1.i686.rpm pvm-3.4.5+4-1.x86_64.rpm
DBGTJN-1171: WHAT THE HECK IS IN rpmlistref
$VAR1 = [
'/tftpboot/rpm/pvm-modules-oscar-3.4.5+4-1.i686.rpm',
'/tftpboot/rpm/pvm-3.4.5+4-1.x86_64.rpm'
];
DBGTJN-1173: WHAT THE HECK IS IN
rpm_list_database(pvm-modules-oscar pvm)
RPMS that need to be installed:
- /tftpboot/rpm/pvm-modules-oscar-3.4.5+4-1.i686.rpm
- /tftpboot/rpm/pvm-3.4.5+4-1.x86_64.rpm
...cut here...
Logged In: YES
user_id=505737
This is 2 bugs in one. Going to create a new bug for the
generic setup aspect. This bug now covers only the
PackageInUn problem of doing a dirread() on package/RPMS and
incorrectly picking the archictecture.
Also, bump to a 9.