2015-03-22 14:04:46 +00:00
|
|
|
#!/bin/bash
|
|
|
|
#
|
|
|
|
# Copyright 2015 Hewlett-Packard Development Company, L.P.
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
|
|
# not use this file except in compliance with the License. You may obtain
|
|
|
|
# a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
|
|
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
|
|
# License for the specific language governing permissions and limitations
|
|
|
|
# under the License.
|
|
|
|
#
|
2016-04-08 05:46:21 +00:00
|
|
|
|
|
|
|
# dib-lint: disable=safe_sudo
|
|
|
|
|
2015-03-22 14:04:46 +00:00
|
|
|
if [ "${DIB_DEBUG_TRACE:-0}" -gt 0 ]; then
|
|
|
|
set -x
|
|
|
|
fi
|
|
|
|
set -eu
|
|
|
|
set -o pipefail
|
|
|
|
|
|
|
|
if [ -f ${TARGET_ROOT}/.extra_settings ] ; then
|
|
|
|
. ${TARGET_ROOT}/.extra_settings
|
|
|
|
fi
|
|
|
|
ARCH=${ARCH:-x86_64}
|
|
|
|
if [ $ARCH = amd64 ]; then
|
|
|
|
ARCH=x86_64
|
|
|
|
fi
|
|
|
|
# Calling elements will need to set DISTRO_NAME and DIB_RELEASE
|
|
|
|
DIB_YUMCHROOT_EXTRA_ARGS=${DIB_YUMCHROOT_EXTRA_ARGS:-}
|
|
|
|
YUMCHROOT_TARBALL=$DIB_IMAGE_CACHE/yumchroot-${DISTRO_NAME}-${DIB_RELEASE}-${ARCH}.tar.gz
|
|
|
|
# TODO Maybe deal with DIB_DISTRIBUTION_MIRROR
|
|
|
|
http_proxy=${http_proxy:-}
|
2015-10-15 18:16:44 +00:00
|
|
|
YUM=${YUM:-yum}
|
2015-03-22 14:04:46 +00:00
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
WORKING=$(mktemp --tmpdir=${TMP_DIR:-/tmp} -d)
|
|
|
|
EACTION="rm -r $WORKING"
|
|
|
|
trap "$EACTION" EXIT
|
2015-03-22 14:04:46 +00:00
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
YUM_CACHE=$DIB_IMAGE_CACHE/yum
|
2015-10-23 04:17:18 +00:00
|
|
|
mkdir -p $YUM_CACHE
|
2015-03-22 14:04:46 +00:00
|
|
|
|
Fixup RPM db path when building Fedora on Ubuntu
On Debian/Ubuntu installs of RPM, /usr/lib/rpm/macros sets
%_dbpath %(echo $HOME/.rpmdb)
which makes quite a bit of sense, because RPM is not the system
packager and thus RPM is setup to install things into a hierarchy in
the users homedir.
However, this messes things up when building a Fedora chroot on an
Ubuntu platform.
We use RPM & yum from the base-system to bootstrap the Fedora chroot.
While both obey --root flags, they still pick up the %_dbpath macro
and so end up creating the RPM database in <chroot>/home/user/.rpmdb
After we have bootstrapped yum/dnf, we execute further installation
commands from inside the chroot -- where we now have the Fedora
version of /usr/lib/rpm/macros and hence have _dbpath set to
/var/lib/rpm -- except there is no rpm database there.
Should anyone be finding this in the future, the actual issue that
appears is
$ sudo chroot /opt/dib_tmp/image.b6B5S3f6/mnt dnf makecache
Error: Failed to synchronize cache for repo 'fedora' from \
'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': \
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink
Note the issue there is that $releasever is not expanded, because the
rpmdb where this info is kept is not populated.
The trick is to make sure we override this value when using the host
rpm/yum to setup the chroot. The bare rpm calls, which we use to
install the repos, have a --dbpath argument where we can override
this. yum does not however, so we override this in the global
~/.rpmmacros while we are installing the packaging tools and
dependencies into the chroot.
Copious comments are included, because this is super-confusing.
Change-Id: I20801150ea02d1c64f118eb969fb2aec473476f7
2015-10-23 04:42:00 +00:00
|
|
|
# Note, on Debian/Ubuntu, %_dbpath is set in the RPM macros as
|
|
|
|
# ${HOME}/.rpmdb/ -- this makes sense as RPM isn't the system
|
|
|
|
# packager. This path is relative to the "--root" argument
|
|
|
|
_RPM="rpm --dbpath=/var/lib/rpm"
|
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
# install the [fedora|centos]-[release|repo] packages inside the
|
|
|
|
# chroot, which are needed to bootstrap yum/dnf
|
|
|
|
#
|
|
|
|
# note this runs outside the chroot, where we're assuming the platform
|
|
|
|
# has yum/yumdownloader
|
|
|
|
function _install_repos {
|
2016-02-11 04:42:10 +00:00
|
|
|
local packages
|
2016-11-10 03:22:17 +00:00
|
|
|
local rc
|
2016-02-11 04:42:10 +00:00
|
|
|
|
|
|
|
# pre-install the base system packages via rpm. We previously
|
|
|
|
# just left it up to yum to drag these in when we "yum install
|
|
|
|
# yum" in the chroot in _install_pkg_manager. This raised a small
|
|
|
|
# problem that inside the empty chroot yum went ahead and did a
|
|
|
|
# mkdir for /var/run to put some pid file in, which then messed up
|
|
|
|
# the "filesystem" package making /var/run a symlink to /run
|
|
|
|
# ... which leads to odd issues with a running system.
|
|
|
|
#
|
|
|
|
# TODO: these packages still have some small %posttrans stuff that
|
|
|
|
# depends on other packages (see rhbz#1306489) ... maybe the idea
|
|
|
|
# is that they are only installed in one big transaction with the
|
|
|
|
# rest of the system? but we don't want to use yum to do this
|
|
|
|
# (see above) so ...
|
|
|
|
packages="basesystem filesystem setup "
|
2015-09-24 04:55:48 +00:00
|
|
|
|
2016-02-11 04:42:10 +00:00
|
|
|
packages+="${DISTRO_NAME}-release "
|
2015-09-24 04:55:48 +00:00
|
|
|
# after fedora21, this is split into into a separate -repos
|
|
|
|
# package
|
2016-02-11 04:42:10 +00:00
|
|
|
if [ $DISTRO_NAME = fedora ]; then
|
|
|
|
packages+="${DISTRO_NAME}-repos "
|
2015-03-22 14:04:46 +00:00
|
|
|
fi
|
2015-09-24 00:14:18 +00:00
|
|
|
|
2016-11-10 03:22:17 +00:00
|
|
|
# yumdownloader puts repo xml files and such into a directory
|
|
|
|
# ${TMPDIR}/yum-$USER-random. Since we don't need this once the
|
|
|
|
# initial download happens, redirect TMPDIR for this call so we
|
|
|
|
# can clean it up nicely
|
|
|
|
local temp_tmp
|
|
|
|
temp_tmp=$(mktemp -d)
|
|
|
|
TMPDIR=${temp_tmp} yumdownloader \
|
2016-02-11 04:42:10 +00:00
|
|
|
--releasever=$DIB_RELEASE \
|
|
|
|
--setopt=reposdir=$TMP_HOOKS_PATH/yum.repos.d \
|
|
|
|
--destdir=$WORKING \
|
2016-11-10 03:22:17 +00:00
|
|
|
${packages} && rc=$? || rc=$?
|
|
|
|
rm -rf ${temp_tmp}
|
|
|
|
if [[ ${rc} != 0 ]]; then
|
|
|
|
die "Failed to download initial packages: ${packages}"
|
|
|
|
fi
|
2016-02-11 04:42:10 +00:00
|
|
|
|
2015-09-24 00:14:18 +00:00
|
|
|
# --nodeps works around these wanting /bin/sh in some fedora
|
|
|
|
# releases, see rhbz#1265873
|
Fixup RPM db path when building Fedora on Ubuntu
On Debian/Ubuntu installs of RPM, /usr/lib/rpm/macros sets
%_dbpath %(echo $HOME/.rpmdb)
which makes quite a bit of sense, because RPM is not the system
packager and thus RPM is setup to install things into a hierarchy in
the users homedir.
However, this messes things up when building a Fedora chroot on an
Ubuntu platform.
We use RPM & yum from the base-system to bootstrap the Fedora chroot.
While both obey --root flags, they still pick up the %_dbpath macro
and so end up creating the RPM database in <chroot>/home/user/.rpmdb
After we have bootstrapped yum/dnf, we execute further installation
commands from inside the chroot -- where we now have the Fedora
version of /usr/lib/rpm/macros and hence have _dbpath set to
/var/lib/rpm -- except there is no rpm database there.
Should anyone be finding this in the future, the actual issue that
appears is
$ sudo chroot /opt/dib_tmp/image.b6B5S3f6/mnt dnf makecache
Error: Failed to synchronize cache for repo 'fedora' from \
'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': \
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink
Note the issue there is that $releasever is not expanded, because the
rpmdb where this info is kept is not populated.
The trick is to make sure we override this value when using the host
rpm/yum to setup the chroot. The bare rpm calls, which we use to
install the repos, have a --dbpath argument where we can override
this. yum does not however, so we override this in the global
~/.rpmmacros while we are installing the packaging tools and
dependencies into the chroot.
Copious comments are included, because this is super-confusing.
Change-Id: I20801150ea02d1c64f118eb969fb2aec473476f7
2015-10-23 04:42:00 +00:00
|
|
|
sudo $_RPM --root $TARGET_ROOT --nodeps -ivh $WORKING/*rpm
|
2015-09-24 04:55:48 +00:00
|
|
|
}
|
2015-03-22 14:04:46 +00:00
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
# _install_pkg_manager packages...
|
|
|
|
#
|
|
|
|
# install the package manager packages. This is done outside the chroot
|
|
|
|
# and with yum from the build system.
|
|
|
|
# TODO: one day build systems will be dnf only, but we don't handle
|
|
|
|
# that right now
|
|
|
|
function _install_pkg_manager {
|
|
|
|
# Install into the chroot, using the gpg keys from the release
|
|
|
|
# rpm's installed in the chroot
|
|
|
|
sudo sed -i "s,/etc/pki/rpm-gpg,$TARGET_ROOT/etc/pki/rpm-gpg,g" \
|
|
|
|
$TARGET_ROOT/etc/yum.repos.d/*repo
|
2015-03-22 14:04:46 +00:00
|
|
|
|
Fixup RPM db path when building Fedora on Ubuntu
On Debian/Ubuntu installs of RPM, /usr/lib/rpm/macros sets
%_dbpath %(echo $HOME/.rpmdb)
which makes quite a bit of sense, because RPM is not the system
packager and thus RPM is setup to install things into a hierarchy in
the users homedir.
However, this messes things up when building a Fedora chroot on an
Ubuntu platform.
We use RPM & yum from the base-system to bootstrap the Fedora chroot.
While both obey --root flags, they still pick up the %_dbpath macro
and so end up creating the RPM database in <chroot>/home/user/.rpmdb
After we have bootstrapped yum/dnf, we execute further installation
commands from inside the chroot -- where we now have the Fedora
version of /usr/lib/rpm/macros and hence have _dbpath set to
/var/lib/rpm -- except there is no rpm database there.
Should anyone be finding this in the future, the actual issue that
appears is
$ sudo chroot /opt/dib_tmp/image.b6B5S3f6/mnt dnf makecache
Error: Failed to synchronize cache for repo 'fedora' from \
'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': \
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink
Note the issue there is that $releasever is not expanded, because the
rpmdb where this info is kept is not populated.
The trick is to make sure we override this value when using the host
rpm/yum to setup the chroot. The bare rpm calls, which we use to
install the repos, have a --dbpath argument where we can override
this. yum does not however, so we override this in the global
~/.rpmmacros while we are installing the packaging tools and
dependencies into the chroot.
Copious comments are included, because this is super-confusing.
Change-Id: I20801150ea02d1c64f118eb969fb2aec473476f7
2015-10-23 04:42:00 +00:00
|
|
|
# See notes on $_RPM variable -- we need to override the
|
|
|
|
# $HOME-based dbpath set on debian/ubuntu here. Unfortunately,
|
|
|
|
# yum does not have a way to override rpm macros from the command
|
|
|
|
# line. So we modify the user's ~/.rpmmacros to set %_dbpath back
|
|
|
|
# to "/var/lib/rpm" (note, this is taken relative to the
|
|
|
|
# --installroot).
|
|
|
|
#
|
|
|
|
# Also note, we only want this done around this call -- this is
|
|
|
|
# the only place we are using yum outside the chroot, and hence
|
|
|
|
# picking up the base-system's default rpm macros. For example,
|
|
|
|
# the yumdownloader calls above in _install_repos want to use
|
|
|
|
# ~/.rpmdb/ ... there is nothing in the build-system /var/lib/rpm!
|
2015-12-01 20:26:26 +00:00
|
|
|
#
|
|
|
|
# Another issue we hit is having to set --releasedir here. yum
|
|
|
|
# determines $releasevar based on (more or less) "rpm -q
|
|
|
|
# --whatprovides $distroverpkg". By default, this is
|
|
|
|
# "redhat-release" (fedora-release provides redhat-release) but
|
|
|
|
# some platforms like CentOS override it in /etc/yum.conf (to
|
|
|
|
# centos-release in their case). You can't override this (see
|
|
|
|
# [1]), but setting --releasever works around this.
|
|
|
|
#
|
|
|
|
# [1] https://bugzilla.redhat.com/show_bug.cgi?id=1287333
|
Fixup RPM db path when building Fedora on Ubuntu
On Debian/Ubuntu installs of RPM, /usr/lib/rpm/macros sets
%_dbpath %(echo $HOME/.rpmdb)
which makes quite a bit of sense, because RPM is not the system
packager and thus RPM is setup to install things into a hierarchy in
the users homedir.
However, this messes things up when building a Fedora chroot on an
Ubuntu platform.
We use RPM & yum from the base-system to bootstrap the Fedora chroot.
While both obey --root flags, they still pick up the %_dbpath macro
and so end up creating the RPM database in <chroot>/home/user/.rpmdb
After we have bootstrapped yum/dnf, we execute further installation
commands from inside the chroot -- where we now have the Fedora
version of /usr/lib/rpm/macros and hence have _dbpath set to
/var/lib/rpm -- except there is no rpm database there.
Should anyone be finding this in the future, the actual issue that
appears is
$ sudo chroot /opt/dib_tmp/image.b6B5S3f6/mnt dnf makecache
Error: Failed to synchronize cache for repo 'fedora' from \
'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': \
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink
Note the issue there is that $releasever is not expanded, because the
rpmdb where this info is kept is not populated.
The trick is to make sure we override this value when using the host
rpm/yum to setup the chroot. The bare rpm calls, which we use to
install the repos, have a --dbpath argument where we can override
this. yum does not however, so we override this in the global
~/.rpmmacros while we are installing the packaging tools and
dependencies into the chroot.
Copious comments are included, because this is super-confusing.
Change-Id: I20801150ea02d1c64f118eb969fb2aec473476f7
2015-10-23 04:42:00 +00:00
|
|
|
(
|
|
|
|
flock -w 1200 9 || die "Can not lock .rpmmacros"
|
|
|
|
echo "%_dbpath /var/lib/rpm" >> $HOME/.rpmmacros
|
2016-04-19 23:42:42 +00:00
|
|
|
|
2016-06-23 06:02:16 +00:00
|
|
|
_lang_pack=""
|
|
|
|
|
|
|
|
if [ $DISTRO_NAME = "fedora" -a $DIB_RELEASE -le 23 ]; then
|
|
|
|
# _install_langs is a rpm macro that limits the translation
|
|
|
|
# files, etc installed by packages. For Fedora 23 [1], the
|
|
|
|
# glibc-common package will obey this to only install the
|
|
|
|
# listed locales, keeping things much smaller (we still have
|
|
|
|
# to clean up locales manually on centos7). We install just
|
|
|
|
# en_US because people often ssh in with that locale, but
|
|
|
|
# leave out everything else. Note that yum has an option to
|
|
|
|
# set this from the command-line [2], but the yum in trusty we
|
|
|
|
# are using is too old to have it. So we set it directly in
|
|
|
|
# the macros file
|
|
|
|
#
|
|
|
|
# [1] http://pkgs.fedoraproject.org/cgit/rpms/glibc.git/commit/glibc.spec?h=f23&id=91764bd9ec690d4b8a886c0a3a104aac12d340d2
|
|
|
|
# [2] http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=26128173b362474456e8f0642073ecb0322ed031
|
|
|
|
echo "%_install_langs C:en_US:en_US.UTF-8" >> $HOME/.rpmmacros
|
|
|
|
elif [ $DISTRO_NAME = "fedora" -a $DIB_RELEASE -ge 24 ]; then
|
|
|
|
# glibc on F24 has split locales into "langpack" packages.
|
|
|
|
# Yum doesn't understand the weak-dependencies glibc now
|
|
|
|
# uses to get the minimal-langpack and chooses a
|
|
|
|
# random(ish) one that satisfies the locale dependency
|
|
|
|
# (rhbz#1349258). Work-around this by explicitly requring
|
2016-07-15 03:24:32 +00:00
|
|
|
# the minimal and english (for en_US.UTF-8) pack.
|
|
|
|
_lang_pack="glibc-minimal-langpack glibc-langpack-en"
|
Rework yum-minimal locale cleanup
It turns out our manual locale cleanup is causing issues (see
I54490b17a7f8b2f977369044fcc6bb49cc13768e). Upon further
investigation, I think this is a better approach than manually
deleting repos.
glibc on Fedora obeys the %_install_langs macro for reducing the
installed locales (as mentioned in the comments, F24 has moved to
having different packages, but worry about that later).
So our existing clear-out is really only required for CentOS, whose
glibc does not have any way to indicate to build less locales.
However, %_install_langs is still correct there, as it restricts some
of the translation files and other things installed with the %lang
macro in spec files.
This is complicated by us having to set this at glibc-common install
time, which happens with the "yum" from outside the chroot (i.e. on
trusty). Since this is too old to have flags to pass this, we need to
fiddle with rpmmacros.
I've tested this with fedora-minimal builds and the locales file is
about 2MiB, which is what it was after the cleanups, and the listed
locales are only those we expect (i.e. it appears to be working).
Change-Id: I528a68beeb7b2ceec25ccbec1900670501608158
2016-05-31 04:53:05 +00:00
|
|
|
fi
|
|
|
|
|
Fixup RPM db path when building Fedora on Ubuntu
On Debian/Ubuntu installs of RPM, /usr/lib/rpm/macros sets
%_dbpath %(echo $HOME/.rpmdb)
which makes quite a bit of sense, because RPM is not the system
packager and thus RPM is setup to install things into a hierarchy in
the users homedir.
However, this messes things up when building a Fedora chroot on an
Ubuntu platform.
We use RPM & yum from the base-system to bootstrap the Fedora chroot.
While both obey --root flags, they still pick up the %_dbpath macro
and so end up creating the RPM database in <chroot>/home/user/.rpmdb
After we have bootstrapped yum/dnf, we execute further installation
commands from inside the chroot -- where we now have the Fedora
version of /usr/lib/rpm/macros and hence have _dbpath set to
/var/lib/rpm -- except there is no rpm database there.
Should anyone be finding this in the future, the actual issue that
appears is
$ sudo chroot /opt/dib_tmp/image.b6B5S3f6/mnt dnf makecache
Error: Failed to synchronize cache for repo 'fedora' from \
'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': \
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink
Note the issue there is that $releasever is not expanded, because the
rpmdb where this info is kept is not populated.
The trick is to make sure we override this value when using the host
rpm/yum to setup the chroot. The bare rpm calls, which we use to
install the repos, have a --dbpath argument where we can override
this. yum does not however, so we override this in the global
~/.rpmmacros while we are installing the packaging tools and
dependencies into the chroot.
Copious comments are included, because this is super-confusing.
Change-Id: I20801150ea02d1c64f118eb969fb2aec473476f7
2015-10-23 04:42:00 +00:00
|
|
|
sudo -E yum -y \
|
2016-09-19 23:18:00 +00:00
|
|
|
--disableexcludes=all \
|
2015-03-22 14:04:46 +00:00
|
|
|
--setopt=cachedir=$YUM_CACHE/$ARCH/$DIB_RELEASE \
|
|
|
|
--setopt=reposdir=$TARGET_ROOT/etc/yum.repos.d \
|
2015-12-01 20:26:26 +00:00
|
|
|
--releasever=$DIB_RELEASE \
|
2015-03-22 14:04:46 +00:00
|
|
|
--installroot $TARGET_ROOT \
|
2016-06-23 06:02:16 +00:00
|
|
|
install $@ ${_lang_pack} && rc=$? || rc=$?
|
2016-04-19 23:42:42 +00:00
|
|
|
|
|
|
|
# We modified the base system - make sure we clean up always!
|
|
|
|
rm $HOME/.rpmmacros.dib.lock
|
Rework yum-minimal locale cleanup
It turns out our manual locale cleanup is causing issues (see
I54490b17a7f8b2f977369044fcc6bb49cc13768e). Upon further
investigation, I think this is a better approach than manually
deleting repos.
glibc on Fedora obeys the %_install_langs macro for reducing the
installed locales (as mentioned in the comments, F24 has moved to
having different packages, but worry about that later).
So our existing clear-out is really only required for CentOS, whose
glibc does not have any way to indicate to build less locales.
However, %_install_langs is still correct there, as it restricts some
of the translation files and other things installed with the %lang
macro in spec files.
This is complicated by us having to set this at glibc-common install
time, which happens with the "yum" from outside the chroot (i.e. on
trusty). Since this is too old to have flags to pass this, we need to
fiddle with rpmmacros.
I've tested this with fedora-minimal builds and the locales file is
about 2MiB, which is what it was after the cleanups, and the listed
locales are only those we expect (i.e. it appears to be working).
Change-Id: I528a68beeb7b2ceec25ccbec1900670501608158
2016-05-31 04:53:05 +00:00
|
|
|
# sed makes it easy to remove last line, but not last n lines...
|
|
|
|
sed -i '$ d' $HOME/.rpmmacros; sed -i '$ d' $HOME/.rpmmacros;
|
2016-04-19 23:42:42 +00:00
|
|
|
if [ $rc != 0 ]; then
|
|
|
|
die "Initial yum install to chroot failed! Can not continue."
|
|
|
|
fi
|
Fixup RPM db path when building Fedora on Ubuntu
On Debian/Ubuntu installs of RPM, /usr/lib/rpm/macros sets
%_dbpath %(echo $HOME/.rpmdb)
which makes quite a bit of sense, because RPM is not the system
packager and thus RPM is setup to install things into a hierarchy in
the users homedir.
However, this messes things up when building a Fedora chroot on an
Ubuntu platform.
We use RPM & yum from the base-system to bootstrap the Fedora chroot.
While both obey --root flags, they still pick up the %_dbpath macro
and so end up creating the RPM database in <chroot>/home/user/.rpmdb
After we have bootstrapped yum/dnf, we execute further installation
commands from inside the chroot -- where we now have the Fedora
version of /usr/lib/rpm/macros and hence have _dbpath set to
/var/lib/rpm -- except there is no rpm database there.
Should anyone be finding this in the future, the actual issue that
appears is
$ sudo chroot /opt/dib_tmp/image.b6B5S3f6/mnt dnf makecache
Error: Failed to synchronize cache for repo 'fedora' from \
'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': \
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink
Note the issue there is that $releasever is not expanded, because the
rpmdb where this info is kept is not populated.
The trick is to make sure we override this value when using the host
rpm/yum to setup the chroot. The bare rpm calls, which we use to
install the repos, have a --dbpath argument where we can override
this. yum does not however, so we override this in the global
~/.rpmmacros while we are installing the packaging tools and
dependencies into the chroot.
Copious comments are included, because this is super-confusing.
Change-Id: I20801150ea02d1c64f118eb969fb2aec473476f7
2015-10-23 04:42:00 +00:00
|
|
|
) 9>$HOME/.rpmmacros.dib.lock
|
2016-04-19 23:42:42 +00:00
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
# Set gpg path back because subsequent actions will take place in
|
|
|
|
# the chroot
|
|
|
|
sudo sed -i "s,$TARGET_ROOT/etc/pki/rpm-gpg,/etc/pki/rpm-gpg,g" \
|
|
|
|
$TARGET_ROOT/etc/yum.repos.d/*repo
|
|
|
|
}
|
2015-03-22 14:04:46 +00:00
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
if [ -n "$DIB_OFFLINE" -o -n "${DIB_YUMCHROOT_USE_CACHE:-}" ] && [ -f $YUMCHROOT_TARBALL ] ; then
|
|
|
|
echo $YUMCHROOT_TARBALL found in cache. Using.
|
|
|
|
sudo tar -C $TARGET_ROOT --numeric-owner -xzf $YUMCHROOT_TARBALL
|
|
|
|
else
|
2015-10-27 04:10:30 +00:00
|
|
|
# Note this is not usually done for root.d elements (see
|
|
|
|
# lib/common-functions:mount_proc_dev_sys) but it's important that
|
|
|
|
# we have things like /dev/urandom around inside the chroot for
|
|
|
|
# the rpm [pre|post]inst scripts within the packages.
|
|
|
|
sudo mkdir -p $TARGET_ROOT/proc $TARGET_ROOT/dev $TARGET_ROOT/sys
|
|
|
|
sudo mount -t proc none $TARGET_ROOT/proc
|
|
|
|
sudo mount --bind /dev $TARGET_ROOT/dev
|
|
|
|
sudo mount --bind /dev/pts $TARGET_ROOT/dev/pts
|
|
|
|
sudo mount -t sysfs none $TARGET_ROOT/sys
|
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
# initalize rpmdb
|
|
|
|
sudo mkdir -p $TARGET_ROOT/var/lib/rpm
|
Fixup RPM db path when building Fedora on Ubuntu
On Debian/Ubuntu installs of RPM, /usr/lib/rpm/macros sets
%_dbpath %(echo $HOME/.rpmdb)
which makes quite a bit of sense, because RPM is not the system
packager and thus RPM is setup to install things into a hierarchy in
the users homedir.
However, this messes things up when building a Fedora chroot on an
Ubuntu platform.
We use RPM & yum from the base-system to bootstrap the Fedora chroot.
While both obey --root flags, they still pick up the %_dbpath macro
and so end up creating the RPM database in <chroot>/home/user/.rpmdb
After we have bootstrapped yum/dnf, we execute further installation
commands from inside the chroot -- where we now have the Fedora
version of /usr/lib/rpm/macros and hence have _dbpath set to
/var/lib/rpm -- except there is no rpm database there.
Should anyone be finding this in the future, the actual issue that
appears is
$ sudo chroot /opt/dib_tmp/image.b6B5S3f6/mnt dnf makecache
Error: Failed to synchronize cache for repo 'fedora' from \
'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': \
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink
Note the issue there is that $releasever is not expanded, because the
rpmdb where this info is kept is not populated.
The trick is to make sure we override this value when using the host
rpm/yum to setup the chroot. The bare rpm calls, which we use to
install the repos, have a --dbpath argument where we can override
this. yum does not however, so we override this in the global
~/.rpmmacros while we are installing the packaging tools and
dependencies into the chroot.
Copious comments are included, because this is super-confusing.
Change-Id: I20801150ea02d1c64f118eb969fb2aec473476f7
2015-10-23 04:42:00 +00:00
|
|
|
sudo $_RPM --root $TARGET_ROOT --initdb
|
2015-09-24 04:55:48 +00:00
|
|
|
|
|
|
|
# this makes sure that running yum/dnf in the chroot it can get
|
|
|
|
# out to download stuff
|
|
|
|
sudo mkdir $TARGET_ROOT/etc
|
2015-03-22 14:04:46 +00:00
|
|
|
sudo cp /etc/resolv.conf $TARGET_ROOT/etc/resolv.conf
|
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
# Bind mount the external yum cache inside the chroot. Same logic
|
|
|
|
# as in the yum element to provide for yum caching copied here
|
|
|
|
# because the sequencing is wrong otherwise
|
2015-03-22 14:04:46 +00:00
|
|
|
sudo mkdir -p $TMP_MOUNT_PATH/tmp/yum
|
|
|
|
sudo mount --bind $YUM_CACHE $TMP_MOUNT_PATH/tmp/yum
|
2015-09-24 04:55:48 +00:00
|
|
|
|
|
|
|
_install_repos
|
|
|
|
|
2016-06-23 06:02:16 +00:00
|
|
|
# install dnf for >= f22
|
2015-09-24 04:55:48 +00:00
|
|
|
if [ $DIB_RELEASE -ge 22 ]; then
|
|
|
|
_install_pkg_manager dnf dnf-plugins-core yum
|
|
|
|
else
|
|
|
|
_install_pkg_manager yum
|
|
|
|
fi
|
|
|
|
|
2016-02-18 00:44:05 +00:00
|
|
|
# we just installed yum/dnf with "outside" tools (yum/rpm) which
|
|
|
|
# might have created /var/lib/[yum|rpm] (etc) that are slighlty
|
|
|
|
# incompatible. Refresh everything with the in-chroot tools
|
|
|
|
sudo -E chroot $TARGET_ROOT rpm --rebuilddb
|
|
|
|
sudo -E chroot $TARGET_ROOT ${YUM} clean all
|
|
|
|
|
Rework yum-minimal locale cleanup
It turns out our manual locale cleanup is causing issues (see
I54490b17a7f8b2f977369044fcc6bb49cc13768e). Upon further
investigation, I think this is a better approach than manually
deleting repos.
glibc on Fedora obeys the %_install_langs macro for reducing the
installed locales (as mentioned in the comments, F24 has moved to
having different packages, but worry about that later).
So our existing clear-out is really only required for CentOS, whose
glibc does not have any way to indicate to build less locales.
However, %_install_langs is still correct there, as it restricts some
of the translation files and other things installed with the %lang
macro in spec files.
This is complicated by us having to set this at glibc-common install
time, which happens with the "yum" from outside the chroot (i.e. on
trusty). Since this is too old to have flags to pass this, we need to
fiddle with rpmmacros.
I've tested this with fedora-minimal builds and the locales file is
about 2MiB, which is what it was after the cleanups, and the listed
locales are only those we expect (i.e. it appears to be working).
Change-Id: I528a68beeb7b2ceec25ccbec1900670501608158
2016-05-31 04:53:05 +00:00
|
|
|
# populate the lang reduction macro in the chroot
|
|
|
|
echo "%_install_langs C:en_US:en_US.UTF-8" | \
|
|
|
|
sudo tee -a $TARGET_ROOT/etc/rpm/macros.langs > /dev/null
|
|
|
|
|
2016-02-18 00:44:05 +00:00
|
|
|
# bootstrap the environment within the chroot; bring in new
|
|
|
|
# metadata with an update and install some base packages we need.
|
|
|
|
sudo -E chroot $TARGET_ROOT ${YUM} -y update
|
2015-10-16 16:32:35 +00:00
|
|
|
sudo -E chroot $TARGET_ROOT ${YUM} -y \
|
2015-03-22 14:04:46 +00:00
|
|
|
--setopt=cachedir=/tmp/yum/$ARCH/$DIB_RELEASE \
|
2016-11-23 22:52:28 +00:00
|
|
|
install systemd passwd findutils sudo util-linux-ng
|
|
|
|
|
|
|
|
# This package is split out from systemd on >F24, dracut is
|
|
|
|
# missing the dependency and will fail to make an initrd without
|
|
|
|
# it; see
|
|
|
|
# https://bugzilla.redhat.com/show_bug.cgi?id=1398505
|
|
|
|
if [ $DISTRO_NAME = "fedora" -a $DIB_RELEASE -ge 24 ]; then
|
|
|
|
sudo -E chroot $TARGET_ROOT ${YUM} -y \
|
|
|
|
--setopt=cachedir=/tmp/yum/$ARCH/$DIB_RELEASE \
|
|
|
|
install systemd-udev
|
|
|
|
fi
|
2015-03-22 14:04:46 +00:00
|
|
|
|
2015-12-14 07:12:09 +00:00
|
|
|
# Put in a dummy /etc/resolv.conf over the temporary one we used
|
|
|
|
# to bootstrap. systemd has a bug/feature [1] that it will assume
|
|
|
|
# you want systemd-networkd as the network manager and create a
|
|
|
|
# broken symlink to /run/... if the base image doesn't have one.
|
|
|
|
# This broken link confuses things like dhclient.
|
|
|
|
# [1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204
|
|
|
|
echo -e "# This file intentionally left blank\n" | \
|
|
|
|
sudo tee $TARGET_ROOT/etc/resolv.conf
|
|
|
|
|
2016-07-15 03:24:32 +00:00
|
|
|
# set the most reliable UTF-8 locale
|
|
|
|
echo -e 'LANG="en_US.UTF-8"' | \
|
|
|
|
sudo tee $TARGET_ROOT/etc/locale.conf
|
|
|
|
# default to UTC
|
|
|
|
sudo -E chroot $TARGET_ROOT ln -sf /usr/share/zoneinfo/UTC \
|
|
|
|
/etc/localtime
|
|
|
|
|
2015-09-24 04:55:48 +00:00
|
|
|
# cleanup
|
2015-10-27 04:10:30 +00:00
|
|
|
# TODO : move this into a exit trap; and reconsider how
|
|
|
|
# this integrates with the global exit cleanup path.
|
2015-09-24 04:55:48 +00:00
|
|
|
sudo umount $TMP_MOUNT_PATH/tmp/yum
|
2015-10-27 04:10:30 +00:00
|
|
|
sudo umount $TARGET_ROOT/proc
|
|
|
|
sudo umount $TARGET_ROOT/dev/pts
|
|
|
|
sudo umount $TARGET_ROOT/dev
|
|
|
|
sudo umount $TARGET_ROOT/sys
|
2015-09-24 04:55:48 +00:00
|
|
|
|
2015-03-22 14:04:46 +00:00
|
|
|
# RPM doesn't know whether files have been changed since install
|
|
|
|
# At this point though, we know for certain that we have changed no
|
|
|
|
# config files, so anything marked .rpmnew is just a bug.
|
|
|
|
for newfile in $(sudo find $TARGET_ROOT -type f -name '*rpmnew') ; do
|
|
|
|
sudo mv $newfile $(echo $newfile | sed 's/.rpmnew$//')
|
|
|
|
done
|
|
|
|
|
|
|
|
echo Caching result in $YUMCHROOT_TARBALL
|
2015-09-24 04:55:48 +00:00
|
|
|
sudo tar --numeric-owner \
|
|
|
|
-C $TARGET_ROOT \
|
|
|
|
-zcf $YUMCHROOT_TARBALL --exclude='./tmp/*' .
|
2015-03-22 14:04:46 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
sudo rm -f ${TARGET_ROOT}/.extra_settings
|