No description
2d47d4157c
This reverts I2701260d54cf6bc79f1ac765b512d99d799e8c43,
Idf2a471453c5490d927979fb97aa916418172153 and part of
Iecf7f7e4c992bb23437b6461cdd04cdca96aafa6 which added special flags to
update kernels via grubby.
These changes actually ended up reverting the behaviour on Fedora 35,
which is what led me to investigate what was going on more fully.
All distros still support setting GRUB_DEVICE in /etc/default/grub;
even the BLS based ones (i.e. everything !centos7).
The implementation *is* confusing -- in earlier distros each BLS entry
would refer to the variable $kernelopts; which grub2-mkconfig would
write into /boot/grub2/grubenv. After commit [1] this was reverted,
and the kernel options are directly written into the BLS entry.
But the real problem is this bit from [2]
get_sorted_bls()
{
if ! [ -d "${blsdir}" ] || ! [ -e /etc/machine-id ]; then
return
fi
...
files=($(for bls in ${blsdir}/${machine_id}-*.conf; do
...
}
i.e., to avoid overwriting BLS entries for other OS-boots (?),
grub2-mkconfig will only update those BLS entries that match the
current machine-id.
The problem for DIB is that we are clearing the machine-id early in
finalise.d/01-clear-machine-id, but then running the bootloader update
later in finalise.d/50-bootloader.
The result is that the bootloader entry generated when we installed
the kernel (which guessed at the root= device, etc.) is *not* updated.
Even more annoyingly, the gate doesn't pick this up -- because the
gate tests run on a DIB image that was booted with
"root=LABEL=cloudimg-rootfs" the kernel initially installed with
"install-kernel" (that we never updated) is actually correct. But
this fails when built on a production host.
Thus we don't need any of the explicit grubby updates; these are
reverted here. This moves the machine-id clearing to after the
bootloader setup, which allows grub2-mkconfig to setup the BLS entries
correctly.
[1]
|
||
|---|---|---|
| .zuul.d | ||
| bin | ||
| contrib | ||
| diskimage_builder | ||
| doc | ||
| playbooks | ||
| releasenotes | ||
| roles | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| bindep.txt | ||
| LICENSE | ||
| lower-constraints.txt | ||
| pylint.cfg | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
Image building tools for OpenStack
==================================
``diskimage-builder`` is a flexible suite of components for building a
wide-range of disk images, filesystem images and ramdisk images for
use with OpenStack.
This repository has the core functionality for building such images,
both virtual and bare metal. Images are composed using `elements`;
while fundamental elements are provided here, individual projects have
the flexibility to customise the image build with their own elements.
For example::
$ DIB_RELEASE=bionic disk-image-create -o ubuntu-bionic.qcow2 vm ubuntu
will create a bootable Ubuntu Bionic based ``qcow2`` image.
``diskimage-builder`` is useful to anyone looking to produce
customised images for deployment into clouds. These tools are the
components of `TripleO <https://wiki.openstack.org/wiki/TripleO>`__
that are responsible for building disk images. They are also used
extensively to build images for testing OpenStack itself, particularly
with `nodepool
<https://docs.openstack.org/infra/system-config/nodepool.html>`__.
Platforms supported include Ubuntu, CentOS, RHEL and Fedora.
Full documentation, the source of which is in ``doc/source/``, is
published at:
* https://docs.openstack.org/diskimage-builder/latest/
Copyright
=========
Copyright 2012 Hewlett-Packard Development Company, L.P.
Copyright (c) 2012 NTT DOCOMO, INC.
All Rights Reserved.
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.