[root@imagine root]# up2date -u --nox For this beta release of Red Hat Linux, the up2date program has been configured to point to a different Red Hat Network server. This server (beta.rhns.redhat.com) can be used to obtain updated packages for the duration of this Red Hat Linux beta test ONLY. After the beta test has been completed, this Red Hat Network server will no longer be available for use. Retrieving list of all available packages... ######################################## Removing installed packages from list of updates... ######################################## Getting headers for available packages... ######################################## Removing packages with files marked to skip from list... ######################################## Testing package set / solving RPM inter-dependencies... ######################################## RPM conflict error. The message was: Test install failed because of package conflicts: package glibc-2.2.4-11 is for a different architecture [root@imagine root]# uname -a Linux imagine 2.4.7-2 #1 Wed Aug 29 11:42:47 EDT 2001 i586 unknown [root@imagine root]# ... Listing the available packages shows duplicates for kernel and glibc; I assume these are the i386 and i686 versions. (CPU is an AMD K6, which runs i386/i586, correct?)
Same here (I also have a 586). My problem occurred with up2date version 2.6.0-7.x.37 . My guess would be up2date matches both glibc packages, and objects to the i686 one. Would it be possible for there to be some means to explicitly ask for the i386 version of glibc at the command line?
Please run the following magic: rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}:%{EPOCH}.%{ARCH}\n" kernel glibc (as a single line of course) Then you'll see exactly what arch versions are installed. Could you please post the output to bugzilla?
I get (having given up and resorted to the GUI interface) kernel-2.4.7-2:(none).i386 kernel-2.4.7-6:(none).i386 glibc-2.2.4-11:(none).i386
I belive this is a bug that should be fixed already. The next version of the client should avoid this (basically, now I only select new pacakges that match the arch of the installed version of the package).