The Command class creates namedtuple to store the result
of the call. That tuple is created inside of the Command
namespace. If called inside of a __del__ destructor which
is often the case in kiwi classes I recently observed an
exception from python saying:
File "/usr/lib64/python3.6/collections/__init__.py", line 429, in namedtuple
File "<string>", line 1, in <module>
ModuleNotFoundError: import of builtins halted; None in sys.modules
I do not understand why this is a problem for python now
and only found the solution in making the command_type variable
a global namedtuple.
Most Linux distributions offer the pyxattr module, including
openSUSE Tumbleweed. Going forward, we will use the pyxattr
module by default as a dependency and only switch back to the
other xattr module when on older SUSE Linux distributions that
lack the pyxattr module.
Note that because kiwi uses setuptools to create the CLI entry
points, kiwi checks the Python dependencies before executing,
so we change the dependency in the setup.py accordingly so that
it will not fail to start.
On suse systems the python-xattr module is used. On any other
distribution the python-pyxattr module is used. This commit
modifies the spec file to reflect the Requires tag appropriately.
On CentOS there is currently no pyxattr build available. Thus we
provide that package for this target in the KIWI Staging area
at Virtualization:Appliances:Staging. There is an ongoing effort
to bring pyxattr to EPEL which would make it available on CentOS
and would obsolete the custom build we did.
Move to multibuild, build one standard(uncompressed) filesystem
image and one compressed version. In any case we expect only
one compression process either on the filesystem file or on
the archive creation. This is related to Issue #1039
This commit is two fold:
* Refactor PXE builder to make use of the ArchiveTar instead of
directly calling tar command.
* Do not compress PXE tarball if the contained image is already
compressed according the type's compressed attribute.
Related to #1039
This was a broken coding for the construction of a
FileSystemBuilder instance in the PxeBuilder implementation.
The unit testing did not fail due to mocking code.
Integration testing however showed it immediately
Along with the fsmountoptions attribute there is now also the
fscreateoptions attribute which allows to control the options
used for creating the filesystem. Please note, it's not kiwi's
task to validate that the given option string is supported
by the selected filesystem. This means providing wrong values
here will cause the build to fail at the time the filesystem
gets created. This Fixes#1109
Most of the components of the *.install.tar.xz file of a PXE install
image are already compressed, thus it doesn't make much sense to
recompress them again.
Fixes#1032
vagrant-libvirt expects that the parameter virtual_size from metadata.json is an
integer and not a string.
Supplying a string results in a backtrace when the user provides a different
value for libvirt.machine_virtual_size (as the integer is then compared to
string).
The changes introduced in #1113 will use the configured bootloader
e.g grub to boot the ISO image in BIOS and EFI mode. The creation
process works flawlessly if xorriso is used. However if cdrtools
are configured the options passed to e.g mkisofs were wrong. In
addition it's not possible to create a hybrid ISO based on
isohybrid if the loader is not isolinux. If cdrtools are in use
the process to make an ISO hybrid bootable is always based on
isohybrid and thus only works with isolinux. This patch also
covers this case with a warning message and the consequence that
we have to skip the hybrid setup in this case.
The BootLoaderConfig class interface writes several files
e.g etc/sysconfig/bootloader, boot/grub2/grub.cfg and more.
Depending on the image type some of those files belongs
into the root directory and some belongs into the boot
directory. For standard images both locations points to
the same master root entry point. However for special
types like live systems the root tree and the boot tree
are different targets. For example live root filesystems
are a squashfs compressed image file whereas the plain
booting information lives outside. Because of that this
patch introduces a refactoring of the BootLoaderConfig
class to allow to distinguish between root_dir and
boot_dir paths. In addition the live image builder makes
use of the new concept and thus Fixes#1112
Python2 is announced to be unmaintained from Jan 2020.
KIWI supports Python 2.7 and it should not support any python version that
is not maintained upstream. This Fixes#1036
- Refactor VagrantConfigTemplate to no longer require a base_mac by default
- Move _random_mac() to Virtualbox subclass
- Include config.vm.base_mac in Virtualbox boxes via
get_additional_vagrant_config_settings()
This fixes#1119
The method get_persistent_device_from_unix_node takes a device
path and looks up it's basename to be present as persistent
variant below the given schema, e.g by-id. However if the
method receives an already persistent device path e.g from
/dev/mapper the persistent schema representation will only
match a numbered dm-N device and not the map name. The method
then returns nothing but should return the original device
path. This caused bad after effects like reported in
Issue SUSE-Enceladus/azure-li-services#163
- Document the usage of the `vagrantconfig.embedded_vagrantfile` attribute
- Remove the suggestion to generate the ssh keys during image creation (this
results in **all** boxes having the same ssh host keys, which is pretty
dangerous if someone would use a vagrant box in a production environment.)
- Stop recommending veewee, this project is dead
- Replace forgotten hard coded number with {schema_version}
This element allows the user to specify a relative path to an alternative
Vagrantfile that will be embedded inside the finished Vagrant box.
- update XML schema
- add additional logic to DiskFormatVagrantBase.create_image_format
- add unit test for the custom Vagrantfile
- fix other vagrant unit tests
The unit test for the RuntimeConfig class are also testing the default values in
some functions. To work around a possibly existing ~/.config/kiwi/config.yml,
several functions change the value of HOME. This is unfortunately not
sufficient if a /etc/kiwi.yml exists, as that one is taken as a fallback *if*
~/.config/kiwi/config.yml isn't present.
This issue is fixed by creating a default_runtime_config with os.path.exists
patched to return False. Thereby none of the runtime configuration files will be
taken into account.
