Commit Graph

20 Commits

Author SHA1 Message Date
Jenkins
d450751617 Merge "yum-minimal: leave behind dummy /etc/resolv.conf" 2015-12-22 20:16:05 +00:00
Ian Wienand
1f499360fc yum-minimal: do not configure eth0 & eth1 for DHCP automatically
Add an environment variable to control the creation of eth0/1
interface enablement scripts.

With a tool such as glean, the presence of these scripts will indicate
the interface is configured and configuration-drive settings will not
be applied.  This means in a non-dhcp situation like on Rackspace,
network is broken.

On Fedora, where later systemd provides "predictable network interface
names" [1] eth0 & eth1 ironically aren't predictable so this just
confuses things.  You really need cloud-init or glean or something to
bring up your interfaces in a sane fashion.

This maintains the status-quo on centos-minimal, but disables creation
for fedora-minimal.

[1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Change-Id: I3f1ffeb6de3b1f952292a144efab9554f7f99a5f
2015-12-22 08:39:04 +11:00
Ian Wienand
5f3855f6f5 yum-minimal: leave behind dummy /etc/resolv.conf
As described in the comment, systemd will create a broken
/etc/resolv.conf link if there is no file in the base-image (as you
can read in the bug, it is debated if this is a bug or a feature).

The solution is to leave a dummy /etc/resolv.conf file in the image.
Whatever network manager you choose (NetworkManager, glean,
cloud-config, etc) will overwrite this anyway.

It's just that some tools, such as dhclient, get confused with the
broken symlink.  This affects you if you're using glean to configure
the network in a DHCP situation, for example -- dhclient won't
configure nameservers and everything goes to heck.

Change-Id: I734834d03e7fdb13f9ab2e86f877b07bf4a84ff9
2015-12-21 15:28:52 +11:00
Ian Wienand
ce781fbbc4 Fix fedora-minimal on CentOS builds
As described in the comments, CentOS overrides the "distroverpkg"
variable in yum.conf.  This is the package that yum queries to
establish the value of the $releasever variable.  On other platforms,
this defaults to "redhat-release" (which "fedora-release" provides) so
everything works.  It is only when the base-system "distroverpkg"
refers to a package not in the chroot we hit the issue.

We can avoid this by setting the releasever variable via the
commandline.

Change-Id: I231c3277960992cd479b8aff7838f246397936f2
2015-12-02 12:16:43 +11:00
Ian Wienand
1d476dd994 Remove fedora-minimal/install.d/99-ramdisk
When the kernel gets installed on Fedora, the rpm post scripts call
"/bin/kernel-install" [1] to install it.  This is a script provided by
systemd.

However, in [2], Fedora ships a patch to kernel-install that makes a
call-out to /sbin/new-kernel-pkg -- the install script provided by
grubby [3]

Without grubby installed, systemd's kernel-install script goes off and
runs dracut plugins directly [4], which eventually creates the initrd.
For reasons that are not clearly explained, the initrd will end up in
a a "machine-id" sub-directory of /boot (possibly, so you can symlink
it?).  It is also called "initrd", even though it's an initramfs, for
historical reasons in dracut I think.

It is at this point that I think 99-ramdisk has been written to move
the generated initrd file back into /boot.  Later on, when we build
the image, we run grub-install and it picks up the kernel and the
initrd and installs everything.

grubby's new-kernel-pkg [6] it's very similar -- it uses dracut to
make the initramfs ... but in this case it is put in /boot and is
actually called initramfs.

The subtle change that led me down this path is that dracut has been
modified to have a "Recommends" for grubby for >F22 [7].  After
discussing this change with the author, it turns out it was *always*
intended to use the grubby-based kernel install scripts for Fedora --
our builds have been incorrect in not including the package.  The
author got sick of people removing the package and making unbootable
systems, hence the change.

Thus this removes the workarounds in 99-ramdisk and replace it with an
install of the grubby package.  grubby's kernel install script will
put the kernel & generated initramfs in /boot, and it will be
installed correctly via the usual grub install later when we build the
disk image.

I have built F22 & F23 fedora-minimal images with this and they boot.

[1] http://pkgs.fedoraproject.org/cgit/kernel.git/tree/kernel.spec#n1832
[2] http://pkgs.fedoraproject.org/cgit/systemd.git/tree/kernel-install-grubby.patch
[3] http://linux.die.net/man/8/new-kernel-pkg
[4] https://github.com/haraldh/dracut/blob/master/50-dracut.install
[5] 81516adcb7
[6] https://github.com/rhinstaller/grubby/blob/master/new-kernel-pkg
[7] 47ff68e78b

Change-Id: I1a6e45d04755515286b3d49f8280c16b527e2f48
2015-11-19 21:03:45 +11:00
Jenkins
5e571d9f44 Merge "Fixup RPM db path when building Fedora on Ubuntu" 2015-11-10 11:03:22 +00:00
Ian Wienand
3f3850aa0f 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-11-10 08:54:44 +00:00
Ian Wienand
8ee21cb9fd Remove unused RELEASE_RPMS variable
It was noticed during reviews of
Ic7aa8cbe13e4347b447e84bb9c12483a4e125228 these are unused

Change-Id: I9e0fa9d3e4864e54c6fe23f8b6e781e8d5d24bda
2015-11-10 07:17:52 +00:00
Jenkins
e90be5a595 Merge "Fix fedora-minimal kernel-install on older platforms" 2015-11-10 05:14:28 +00:00
Jenkins
654d80a40f Merge "Define a default for $YUM" 2015-11-03 20:33:38 +00:00
Ian Wienand
f307bb4d8b Fix fedora-minimal kernel-install on older platforms
fedora-minimal fails to build on Ubuntu Trusty due do being unable to
find the initrd (see Id4c04d7ae20068643df34d2fa31068e8a917a52d).

This is a rather obscure problem that comes from the intersection of
several things.

The first thing to note is that the post-install scripts of the
kernel-core package use kernel-install [1].  For whatever reason, this
installs the kernel to /boot/MACHINE-ID/KERNEL-VERSION

MACHINE-ID comes from /etc/machine-id; a UUID that should have been
created by the systemd post-inst scripts with systemd-machine-id-setup
[2].

The chroot environment provided for root.d elements has no kernel
file-systems like /proc or /dev mounted.  This is where differences in
the base-system come into play -- on more recent systems that
implement getrandom() systemd does not need /dev/urandom to generate
the machine-id [3]; we get a value and /etc/machine-id is populated.

On older platforms (Trusty), systemd-machine-id-setup fails (unable to
access /dev/urandom) and we end up with a blank /etc/machine-id.  This
ends up making kernel-install (the script) fail during yum's
installation of kernel-core, which means the initrd is not installed
correctly.

We end up bailing out in fedora-minimal/install.d/99-ramdisk, where we
try to put the installed ramdisk in /boot for the later grub install
scripts to find.

The solution here is to mount the standard kernel file-systems within
the chroot before we try installing.

[1] http://www.freedesktop.org/software/systemd/man/kernel-install.html
[2] http://www.freedesktop.org/software/systemd/man/systemd-machine-id-setup.html
[3] https://github.com/systemd/systemd/blob/master/src/basic/random-util.c

Change-Id: Ibcce35da928f64e6a719b070bcc833346ee7ee92
2015-11-04 06:23:17 +11:00
Jenkins
449b4e205e Merge "Preserve env when calling yum with sudo" 2015-11-03 10:36:33 +00:00
Ian Wienand
94a7a7cf67 Create YUM_CACHE_DIR in yum-minimal
yum-minimal/root.d/08-yum-chroot runs before yum/root.d/50-yum-cache,
and thus if run on a completely fresh system will fail in
08-yum-chroot as the YUM_CACHE directory isn't made.

This is probably hidden by testing & nodepool builds, because it sets
DIB_IMAGE_CACHE.  It was hidden from me because locally I have done
builds using the "yum" element previously, which had created the
cache.

Change-Id: I333f5f7e67d198f75a522cc296c118c2e94a5ecb
2015-10-23 15:17:18 +11:00
Derek Higgins
63641aa2ce Preserve env when calling yum with sudo
In particular we need [http|https]_proxy to be preserved.

Change-Id: I5bcd1b1deac917a1be8d8155f1283e330e3d5862
2015-10-16 17:36:09 +01:00
Derek Higgins
614661ec5b Define a default for $YUM
This is set by elements that require it not to be yum.

Change-Id: Ie01f357eef382bd1549fbe2b911129a3c48818e0
2015-10-16 09:55:00 +01:00
Ian Wienand
c40aa76d83 Remove extra install of release pkgs in fedora-minimal
I'm not sure why we try to do an extra install of these, it is done
inside the chroot in _install_repos.  Currently it just gets skipped
saying the packages are already installed.

Change-Id: Ic7aa8cbe13e4347b447e84bb9c12483a4e125228
2015-10-14 06:36:06 +11:00
Ian Wienand
ebdf48623e Add Fedora 22 support to yum-minimal
Add basic F22/dnf support to yum-minimal path.  We extract common
code, add some comments and reduce duplication.

Change-Id: If4bd5f88e26bd6f2168958f1ec1efff1072de7ba
2015-10-14 06:35:22 +11:00
Ian Wienand
829d626f0a Move yum-based install into function
Move yum-based install into a function, to make way for a second
related function where use dnf later

Change-Id: Iad09f3753ecdfa0c10cb8a0970a3c8e5a2dccab1
2015-10-09 12:03:19 +11:00
Ian Wienand
afaba5b42d Use --nodeps when installing fedora-release
fedora-release >= 22 has acquired a dependency on /bin/sh.  This comes
from a %posttrans section of the spec file, which is symlinking the
os-release file.

As discussed in [1], the links are setup correctly in the rpm, so the
post-install script isn't doing anything.  Thus we can safely ignore
the dependency with --nodeps

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1265873

Change-Id: Icf17c84580a75d42d8e90d5d6e81ae7f5f576c32
2015-09-24 21:03:36 +10:00
Monty Taylor
b5bcb3b60e Add a yum-minimal element that just uses yum
The centos-minimal approach of using rinse does not, it turns out, work
on centos. That's a bummer. It's also rather heavyweight. Instead, with
minor machinations, we can just use yum itself pointed at a chroot.

Also adding fedora-minimal element which creates a fedora image using
the new yum-minimal approach.

Co-Authored-By: Gregory Haynes <greg@greghaynes.net>

Change-Id: I026fd9d323e786dae5bb67824c6501067e1ceaa3
2015-04-14 13:39:18 -04:00