This introduces the beginnings of an image definition for Windows
Subsystem for Linux (WSL).
The package list is based on the core and standard grouplists. Some
packages, like the kernel, dracut, and so on, are omitted as they are
unnecessary. Others, like audit, don't work in the environment. Finally,
many packages are omitted since I thought "people probably won't want
that", so the package list is completely up for debate. This is just a
reasonable starting point that works.
Build/test instructions:
To build the tarball:
$ ./kiwi-build --image-profile=WSL-Base --image-type=tbz --output-dir=./build/
Get it to a Windows host with WSL installed. To boot it with cgroupsv2,
add the following to `.wslconfig` in the Windows host home folder:
[wsl2]
kernelCommandLine=systemd.unified_cgroup_hierarchhy=1 cgroup_no_v1=all
This assumes the latest WSL release is installed, at least version 2.4.4:
$ wsl --install --from-file .\path\to\the\fedora.tar.xz
Alternatively, if you're using something prior to version 2.4.4:
$ wsl --import --version=2 Fedora C:\path\to\storage\Fedora\ .\path\to\the\fedora.tar.xz
Finally, run it with:
$ wsl -d Fedora
If you are using 2.4.4+, you will be prompted for a username and then
dropped into an interactive shell with that user and passwordless sudo
access.
If you're using an older version, you need to do:
$ wsl -d Fedora -u root
# /usr/libexec/wsl/oobe.sh
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
Disk images are usually flashed to media which is much larger
than they are, and all that additional space goes unused until
the user intervenes.
Configure things so that systemd-repart, which runs by default,
automatically takes care of resizing the root partition.
systemd-growfs, which also runs by default, will subsequently
take care of resizing the filesystem to fill the newly-enlarged
partition.
Note that we don't do this for cloud images, since in that
case cloud-init takes care of resizing the root filesystem and
the underlying partition together with all the other setup
tasks.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We only really need i686/x86_64 libraries, and executables which do not exist
(or do not work equivalently) on the arm64 host system.
In particular, removing libexec avoids situations where random dbus services
are started under emulation for no reason.
This is loosely based on the Server kickstart and ELN descriptions.
This covers both the disk image for running on ARM hardware as well
as the VM image for running on various hypervisor platforms.
The vagrant user used in Vagrant images needs the ability
to use sudo with no restrictions. This is fine and expected
for Vagrant images, as they are only intended to be used
for development purposes.
Azure provides an optional "Accelerated Networking" feature. Enabling
this feature when creating a VM enables SR-IOV and provides the guest
with a virtual function.
Supporting this requires two changes. Firstly, the kernel-modules
package is required as it contains the Mellanox drivers required for the
VF provided to the guest. Secondly, the interface needs to be ignored by
NetworkManager or it'll try and fail to bring up the device and the VM
will be unreachable except by serial console. If this is observed, it's
likely new hardware has been deployed and additional drivers need to be
added to the NetworkManager config.
See https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview
for details.
Neal Gompa