Re: [lmi] debian chroot in redhat

[Greg Chicares]

On 2019-09-25 01:15, Vadim Zeitlin wrote:
> On Fri, 20 Sep 2019 19:01:10 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-09-20 18:45, Greg Chicares wrote:
> GC> > On 2019-09-20 17:40, Vadim Zeitlin wrote:
> GC> [...]
> GC> >> Of course, there is always the "when all you have is
> GC> >> Debian, any Linux looks like an OS where you can install it in a 
> chroot"
> GC> >> approach, i.e. you could use debootstrap to create a chroot of Buster 
> on
> GC> 
> GC> Bullseye now. I may be a parochial debian fan, but I do upgrade
> GC> from time to time. Right now, I'm using buster as my main system,
> GC> because 'stable' means "stable", but I'm doing my lmi work in a
> GC> bullseye chroot.
> GC> 
> GC> >> this machine and just do everything inside it with minimal drawbacks 
> (a few
> GC> >> hundred of extra MiB of disk consumption).
> GC> > 
> GC> > Is that feasible? If so, it sounds like an excellent idea.
> 
>  I, or rather Ilya, who has tested this, can confirm that this is indeed
> feasible and _almost_ works -- there is just one mysterious problem
> remaining.
> 
>  The installation was pretty straightforward:
> 
>       # rpm -ivh 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
>       # yum install -y debootstrap.noarch
> 
>       # mkdir -p /srv/chroot/debian-stable
>       # debootstrap stable /src/chroot/debian-stable 
> http://deb.debian.org/debian/
> 
> (note that you need to have "curl" and "ca-certificates" packages installed
> for this to work, but this should already be the case on any normal RHEL
> system, even though it wasn't in my minimal CentOS installation).

Please help--I'm stuck.

What I've done so far is here:
  https://git.savannah.nongnu.org/cgit/lmi.git/tree/install_centos.sh
which gives me a working centos chroot, closely following your
instructions here:
  http://www.tt-solutions.com/en/articles/install_centos_in_debian_chroot
except that I'm using centos-7.7 instead of 7.6 because the handful of
US mirrors I checked don't offer 7.6 .

After running that script as root on my debian-10.1 base system, I log in
and install curl and ca-certificates:

#schroot --chroot=centos7 --user=root --directory=/tmp
[root@ugolyok]/tmp# yum --assumeyes install ca-certificates curl
...
Installed:
  ca-certificates.noarch 0:2018.2.22-70.0.el7_5             curl.x86_64 
0:7.29.0-54.el7            
...
Complete!

But now I observe this failure on the command to install EPEL:

[root@ugolyok]/tmp# rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Retrieving 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
curl: (77) Problem with the SSL CA cert (path? access rights?)
error: skipping 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - 
transfer failed

I wasn't sure whether I needed to be in an 'scl enable' shell,
so I tried that:

[root@ugolyok]/tmp# scl enable devtoolset-8 rh-git218 $SHELL

and repeated the command above, but it failed in the same way.

I tried the following suggestions:

# https://stackoverflow.com/questions/27987091/ssl-ca-cert-path-access-rights
# doesn't help:
rm -f /etc/ssl/certs/ca-bundle.crt && yum reinstall -y ca-certificates

# 
https://stackoverflow.com/questions/7179216/php-problem-with-the-ssl-ca-cert-path-access-rights
# doesn't help:
yum reinstall openssl ca-certificates -y

and both those commands ran successfully, but the 'rpm' command
still failed exactly as quoted above.

I tried s/https/http/ :

rpm -ivh http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

but it failed as shown in the lengthy screen copy that ends this
email. Any other ideas?

[root@ugolyok]/tmp# rpm -ivh 
http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Retrieving http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
warning: /var/tmp/rpm-tmp.Y1jb9f: Header V3 RSA/SHA256 Signature, key ID 
352c64e5: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:epel-release-7-12                ################################# [100%]
[root@ugolyok]/tmp# yum install -y debootstrap.noarch
Loaded plugins: fastestmirror, keys, protectbase
Loading mirror speeds from cached hostfile


 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
        or
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Cannot retrieve metalink for repository: epel/x86_64. Please verify its path 
and try again