Re: [lmi] yum: "Multilib version problems found."

[Greg Chicares]

On 2020-02-05 17:39, Vadim Zeitlin wrote:
> On Wed, 5 Feb 2020 17:30:35 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> It's a new year, so I'm trying again to build lmi on a redhat server.
> 
>  Did this work last year? I.e. has anything changed or had you simply not
> tried doing it before?

Short answer: It worked last year, and today I simply reinvoked the
same commands that were still in zsh history from last October.

More details: Instead of using a tmpfs for /srv, I've now formatted
and mounted /srv/chroot to hold the debian chroot where we do the
actual work (but today's failure occurs long before any chroot is
created). And last year's work was only a proof of concept (IIRC,
some msw code was built, and some tests were run, but I'm not sure
we achieved a full production build).

Although I tried to capture every useful step in shell scripts that
reside in the lmi repository, along the way I took many experimental
steps that were not immortalized in scripts. Thus, I can't say why
we have any i686 code that isn't in a chroot: it might have been
part of the prebuilt server we were given, or I might have installed
multiarch stuff as part of an experiment that didn't work.

> GC> The steps are simple--just run the latest script in git as root:
> GC> 
> GC> $cd /opt/lmi/src/lmi
> GC> $sudo sh
> GC> $git pull
> GC> $ ./install_redhat.sh >/home/mm53451/rhlog_$(date -u +%Y%m%dT%H%MZ) 2>&1
> GC> 
> GC> ...but I quickly encounter the problem below: the command
> GC>   yum --assumeyes install ca-certificates curl nss-pem
> GC> fails, apparently because I have multiple architectures installed.
> [...]
> GC> Vadim--Are you familiar enough with rhel that you can immediately
> GC> see how to fix this?
> 
>  No, unfortunately I don't really know much about multilib handling on
> RPM-based systems. I could try setting up a similar system here and
> experimenting with it, but

I'd hesitate to waste your time that way. With your help, last year
I created a centos chroot on my own computer, which is intended to
simulate the redhat server; I'd try to duplicate the problem there
first. I might find that all the i686 stuff in the redhat system
(and, if present, in the centos chroot) is useless, and that the
solution is to purge it.

I suppose it's possible that rhel-7.6 is inherently a dual-arch
system, and that purging the i686 parts might be harmful, but I
really doubt that.

> GC> If not, I'll go through the advice that's readily found with a web
> GC> search.
> 
>  It looks like the advice is to install both 64- and 32-bit versions of the
> package, e.g.
> 
>       yum install nss-pem.{i686,x86_64}
> 
> and this seems logical, at some level, but I also wonder why doesn't it do
> it automatically if this is all it needs. In any case, if this does work, I
> see no problem with updating the original command in install_redhat.sh to
> do it.

I tried that, as two separate commands:
  yum install nss-pem.i686
  yum install nss-pem.x86_64
and both failed with the same error message reported earlier.

And I tried
  yum-complete-transaction
but it said there were no incomplete transactions.

Then I tried
  yum update nss-pem
and everything seemed to work. In particular, whereas earlier I saw:

nss-pem.i686                        1.0.3-5.el7_6.1          @rhel-7-server-rpms
nss-pem.x86_64                      1.0.3-5.el7_6.1          @rhel-7-server-rpms

now I have 1.0.3-7 for both.

The conclusion seems to be that, when
  yum install PKG
has already run successfully,
  yum update PKG && yum install PKG
works, but
  yum install PKG
fails. Searching the web, I find no indication that this should be
true, while I do find indications that it should not be true, but
for now at least I'm going to add this magical nonsense to the script.
And it does indeed get farther: now I'm up to
  Failed to change to directory '/tmp': Permission denied
which looks easier to debug than this 'yum' stuff.