Re: [lmi] debian chroot in redhat

[Greg Chicares]

On 2019-10-03 11:25, Vadim Zeitlin wrote:
> On Thu, 3 Oct 2019 02:18:12 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> [root@ugolyok]/tmp# yum install nss-pem
> GC> ...
> GC> One of the configured repositories failed (Unknown),
> GC> 
> GC> Rerunning with the EPEL repository suppressed momentarily:
> GC> 
> GC> [root@ugolyok]/tmp# yum install --disablerepo=epel nss-pem       
> GC> ...
> GC> Warning: RPMDB altered outside of yum.
> GC> ** Found 30 pre-existing rpmdb problem(s), 'yum check' output follows:
> GC> coreutils-8.22-24.el7.x86_64 has missing requires of ncurses
> 
>  Are these warnings normal? I haven't seen either of them in my chroot.

AFAICT, the answers are as follows:

> GC> Warning: RPMDB altered outside of yum.

Yes, that's normal. We used the low-level 'rpm', going behind the
back of the high-level 'yum'. See:

  https://www.centos.org/forums/viewtopic.php?t=636

> GC> ** Found 30 pre-existing rpmdb problem(s), 'yum check' output follows:
> GC> coreutils-8.22-24.el7.x86_64 has missing requires of ncurses

I'm afraid that might be a normal consequence, too. Now that I
have code that successfully debootstraps debian, I see these
warnings after this sequence of events:

+ rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
...
+ yum install -y debootstrap.noarch
...
Warning: RPMDB altered outside of yum.
** Found 28 pre-existing rpmdb problem(s), 'yum check' output follows:
coreutils-8.22-24.el7.x86_64 has missing requires of ncurses

I suppose that means the EPEL rpm gave us a new 'coreutils'
that wants an 'ncurses' upgrade.

I'm not sure whether there's any actual problem, but let's see
if we can solve it anyway:

  # yum history sync

That runs successfully. However:

  # yum check

That still reports errors. Experimenting...

  # yum update

That updated krb5-libs, rsyslog, and tzdata, and installed libverto
to resolve a dependency. But the 'yum check' errors persist.

  # yum upgrade

"No packages marked for update"

Let's try these ideas:
  
https://stackoverflow.com/questions/19418301/yum-error-package-is-a-duplicate-with

  # yum-complete-transaction

That doesn't do anything either: "No unfinished transactions left."

  # package-cleanup --dupes

There are no dupes.

  # yum reinstall package-newest-version

Let's try something different. The first problem reported by
'yum check' is
  coreutils-8.22-24.el7.x86_64 has missing requires of ncurses
and if we address that directly:

  # yum install ncurses

and then rerun 'yum check', that particular problem is no longer
reported. Addressing some of the other "missing" errors:

  # yum install default-yama-scope shared-mime-info nss-tools pyliblzma pyxattr 
python-kitchen

reduces the output of 'yum check' to less than one full page.
But one hopes for a less manual process. We have six 'neon' errors:

neon-0.30.0-4.el7.x86_64 has missing requires of libgnutls.so.28()(64bit)
neon-0.30.0-4.el7.x86_64 has missing requires of 
libgnutls.so.28(GNUTLS_1_4)(64bit)
neon-0.30.0-4.el7.x86_64 has missing requires of 
libgnutls.so.28(GNUTLS_2_12)(64bit)
neon-0.30.0-4.el7.x86_64 has missing requires of 
libgnutls.so.28(GNUTLS_3_0_0)(64bit)
neon-0.30.0-4.el7.x86_64 has missing requires of libpakchois.so.0()(64bit)
neon-0.30.0-4.el7.x86_64 has missing requires of libproxy.so.1()(64bit)

so let's try:

  # yum install neon

  Package neon-0.30.0-4.el7.x86_64 already installed and latest version
  Nothing to do

  # yum reinstall neon

That resolved the "missing requires" of neon.

Proceeding with outrageous pertinacity:

  # yum reinstall crontabs initscripts pam pygpgme rpm rpm-python util-linux

and now we have a "solution", for the record:

[root@ugolyok]/tmp# yum check                                                   
            
Loaded plugins: fastestmirror, keys, protectbase
check all
[root@ugolyok]/tmp# echo $?
0

I've read through all the links I find in a web search for
  yum check "has missing requires"
stopping only when non-indo-european-language pages begin to
predominate, but found no automated way of doing this.

[...snip other fascinating redhat stuff...]
> So the only firm conclusion I can make is that I don't really understand
> how do package specifications work in RedHat world.

I begin to wonder whether {yum,rpm} are markedly inferior to {apt,dpkg}.

>  But, anyhow, the summary is that the required package should have been
> installed as a dependency of curl and there is still the question about how
> could you end up with curl but without nss-pem. However if your automated
> chroot installation script contains "yum install -y curl", it should work.

I think 'curl' is not enough, and 'nss-pem' must also be installed.

Here's a throwaway patch to the script I've been using (so '+' in
the left margin indicates added commands):

 yum --assumeyes install ca-certificates curl
+rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm || yum 
--assumeyes install nss-pem
+rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm || yum 
--assumeyes install openssl
+
 rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

And here's the result (where '+' in the left margin indicates
actual commands because of 'set -vx', and I've snipped much of
the extremely verbose output...I'm pasting from 'less -N', so
the line numbers indicate that snippage):

   1251 + yum --assumeyes install ca-certificates curl

That "succeeded", but 'curl' doesn't yet work as hoped:

   1320 rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm || yum 
--assumeyes install nss-pem
   1321 + rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
   1322 curl: (77) Problem with the SSL CA cert (path? access rights?)
   1323 error: skipping 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - 
transfer failed
   1324 Retrieving 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
   1325 + yum --assumeyes install nss-pem

...so my script proceeds to install 'nss-pem':

   1364 Complete!
   1365 rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm || yum 
--assumeyes install openssl
   1366 + rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
   1367 warning: /var/tmp/rpm-tmp.0kWRLH: Header V3 RSA/SHA256 Signature, key 
ID 352c64e5: NOKEY
   1368 Retrieving 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
   1369 Preparing...                          
########################################
   1370 Updating / installing...
   1371 epel-release-7-12                     
########################################

...and now everything has worked.

Here's a minor nuisance: when we subsequently reach the line that
installs EPEL:

rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
+ rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
warning: /var/tmp/rpm-tmp.BdWz34: Header V3 RSA/SHA256 Signature, key ID 
352c64e5: NOKEY
Retrieving 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Preparing...                          ########################################
        package epel-release-7-12.noarch is already installed

it fails (the exit code is nonzero), so 'set -evx' has made the
script fail. I would have expected to 'rpm -i' to be idempotent,
but it's not, and neither is 'rpm -U'.

But I think we have what we need in order to proceed to the next
step, which is creating a debian chroot inside centos, which
should get us back to terra cognita.