For no very good reason this is what debian-cd does, and what the grub
config isobuilder generates still expects. It probably makes sense to
switch to 'vmlinuz' like every other arch apart from ppc64el does but
for now I want to maintain compatibility with the old ISOs.
There are case in CPC built images where we don't want to create an SBOM.
Add an argument in create_manifest which defaults to creating an SBOM, but can also skip generating an SBOM
A change in 2024 [0] was made to debootstrap in which the keyring is now
switched from ubuntu-archive-keyring.gpg to
ubuntu-archive-removed-keys.gpg after a given release goes EOL. This
means that the Release signature cannot be verified after EOL since the
Release is signed with the ubuntu-archive-keyring.gpg. It is expected
that we can continue to build any release even after the suite is
closed.
This change adds a debootstrap configuration to override this behavior
and ensure all of our images are verified against the main archive key.
Refs: [0] https://git.launchpad.net/ubuntu/+source/debootstrap/commit/?id=4f8b3405097b9f655938528ae7105ec534eb7d1b
Use consistent formatting across all architectures: 4-space indent,
two spaces after "linux", one space after "initrd". Also fix an extra
blank line before "fi" in amd64's UEFI section caused by f-string
interpolation.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Separate config generation from file I/O by having generate_grub_config()
and its helpers return strings. The base class make_bootable() now handles
writing grub.cfg.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The debian-cd scripts did this game of placing boot-related files in a
separate directory that was then passed to xorriso to include on the
ISO. Stop doing that and just put the files directly into the ISO root
that is already passed to xorriso.
Package contents were being extracted into subdirectories of the boot
tree (grub_dir, shim_dir), which meant the boot tree contained both
the final boot files and the raw package extractions. Extract packages
into scratch directories instead, copying only the needed files into
the boot tree. This also removes the grub_dir/shim_dir instance
variables and the create_dirs overrides, and moves copy_grub_modules
to a standalone function in grub.py.
Set MAKE_ISO=yes so ubuntu-mini-iso uses the standard isobuilder
flow in auto/build. The binary hook is simplified to just creating
kernel/initrd artifacts; isobuilder handles .disk metadata, boot
configuration, and ISO creation.
The mini-iso's custom grub.cfg (single iso-chooser-menu entry) is
generated by a project-specific path in AMD64BootConfigurator.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace the debian-cd git clone and shell script invocation in
ISOBuilder with the new Python boot configurators.
Key changes to builder.py:
- make_bootable() creates a boot configurator and calls its
make_bootable() method instead of cloning debian-cd
- make_iso() gets mkisofs_opts directly from the configurator
instead of reading a serialized file
- add_live_filesystem() links kernel/initrd with names expected
by the boot configurators (vmlinuz/initrd, hwe-vmlinuz/hwe-initrd)
- _extract_casper_uuids() updated for the new initrd naming scheme
- Refactor config storage to use a single _config dict
- Add limit_length parameter to Logger for long xorriso commands
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add architecture-specific boot configurators that translate the
debian-cd boot shell scripts (boot-amd64, boot-arm64, boot-ppc64el,
boot-riscv64, boot-s390x) into Python.
The package uses a class hierarchy:
- BaseBootConfigurator: abstract base with common functionality
- GrubBootConfigurator: shared GRUB config generation
- UEFIBootConfigurator: UEFI-specific shim/ESP handling
- Architecture classes: AMD64, ARM64, PPC64EL, RISCV64, S390X
A factory function make_boot_configurator_for_arch() creates the
appropriate configurator for each architecture.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Extract a download_direct() method from download() to enable downloading
packages to an arbitrary directory with an arbitrary specification string.
This will be used by the boot configuration code to download bootloader
packages.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ubuntukylin's /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg
contains a symlink to
"/usr/share/keyrings/ubuntukylin-archive-keyring.gpg" as an absolute
path. This obviously doesn't work when not chrooted into the chroot but
we don't need to copy it over to the apt config used to build the pool
as no package from any archive signed by this key is going to be
included in the pool...
The -map option requires two arguments: the source filesystem path and
the target path in the ISO. Without the "/" target, xorriso fails.
This only affects riscv64, which uses native xorriso mode rather than
mkisofs compatibility mode.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This adds a new tool, isobuild, which replaces the ISO-building
functionality previously provided by live-build and cdimage. It is
invoked from auto/build when MAKE_ISO=yes.
The tool supports:
- Layered desktop images (Ubuntu Desktop, flavors)
- Non-layered images (Kubuntu, Ubuntu Unity)
- Images with package pools (most installers)
- Images without pools (Ubuntu Core Installer)
The isobuild command has several subcommands:
- init: Initialize the ISO build directory structure
- setup-apt: Configure APT for package pool generation
- generate-pool: Create the package pool from a seed
- generate-sources: Generate cdrom.sources for the installed system
- add-live-filesystem: Add squashfs and kernel/initrd to the ISO
- make-bootable: Add GRUB and other boot infrastructure
- make-iso: Generate the final ISO image
auto/config is updated to:
- Set MAKE_ISO=yes for relevant image types
- Set POOL_SEED_NAME for images that need a package pool
- Invoke gen-iso-ids to compute ISO metadata
auto/build is updated to:
- Remove old live-build ISO handling code
- Invoke isobuild at appropriate points in the build
lb_binary_layered is updated to create squashfs files with
cdrom.sources included for use in the ISO.
Add a script to compute the values for .disk/info, the ISO volume ID,
and the "capproject" (capitalized project name) used in various places
in the ISO boot configuration.
This replaces the logic that was previously scattered across live-build
and cdimage.
Add systemd drop-in to wait for snapd seeding completion before starting the
display manager. This improves the user experience as users now wait in
Plymouth for the installer to finish being seeded, instead of in GDM with only
the wallpaper visible. When GDM starts, the installer launches with minimal
delay.
When developping and using snapd from edge on cross-team efforts like
TPM/FDE, allow snapd to reexec to the snap version unconditionnaly,
on live system.
.
This is commented so that the future revert to stable include it and
we don’t forget to readd that next time this kind of effort is needed.
We now filter snaps using jq rather than grep. The change has a slight impact
because snapd-desktop-integration was filtered out by "grep snapd" but isn't
filtered out anymore with jq.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
We have a mechanism in place to override a snap when building an image.
Unfortunately, we didn't factor this in when forcing optional components to be
included in the image.
This was okay before because the stable model and the dangerous model had the
same components declared.
But now that pc-kernel has different components in the stable and the dangerous
model, things are broken.
Indeed, when building the stable image, we tried to include the pc-kernel from
the stable model with the pc-kernel components from the dangerous model. But
they are not compatible.
Fixed by including components from the right model. If we're overriding a snap
with a definition from a different model, then pull the components from that
same model.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The pc-kernel version in 26.04/beta is kernel 6.17, which uses different
components from what is currently declared in the model.
This used to be necessary when there was no kernel in 26.04/stable, but now
there is a 6.8 version in 26.04/stable. The available components match what's
in the model.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
This allows netboot tarballs to be PXE booted on QEMU; previously, the tarball was missing bootloader.
Signed-off-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Because some snaps are not yet in their respective stable channel in 26.04, the
build fails. When preparing the image we can add --snap options to override the
channel of the different snaps. But we can only do that if we're building with
grade: dangerous. As a workaround this issue, we build with the non-dangerous
ISO with the dangerous model, but keep the snaps on their original channel
defined in the non dangerous model.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Update /etc/systemd/system/cloud-init-network.service override to
sync with latest netcat changes in Desktop images.
Resolve traceback:
netcat: /run/cloud-init/share/network.sock: Protocol wrong type for socket
LP: #2128887
To boot initrdless, the kernel supports a limited number of ways to
specify the location of the root filesystem[1]. One of them is to use
the PARTUUID (which will be different for every cloud-image), another is
to use the PARTLABEL (partition name). To allow the use of PARTLABEL in
the kernel command line and make our cloud-images more self-describing,
set the PARTLABEL to cloudimg-rootfs which is the same label we use for
the file system inside this partition.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/early-lookup.c#n217
To make our disk images more discoverable, we should use the correct
partition type for the root filesystem. This aligns with the
Discoverable Disk Image (DDI) specification developed by the UAPI
group[1] and makes our images more self-describing, e.g. with fdisk,
before:
Device Start End Sectors Size Type
/dev/nbd0p1 2324480 7339998 5015519 2.4G Linux filesystem
...
and now after:
Device Start End Sectors Size Type
/dev/nbd0p1 2324480 7339998 5015519 2.4G Linux root (x86-64)
...
[1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
/etc/default/grub.d/50-cloudimg-settings.cfg is currently overriding our
RISC-V specific configuration. Remove it.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since release 25.10 we require support for the rva23s64 profile.
Remove all code relating for boards that do not match this requirement.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In the ubuntu-cpc disk-image binary we need to avail of the ever increasing size
of packages. 2.2GB is now just a bit too small leading to `No space
left on device` errors when the binary hits `grub-install`. This commit
increases $imagesize to 2.5GB (in the binary as an override initially
implemented in ecaaf0484).
This commit also runs `df` just after the grub-pc && grub2-common
installs to make for easier debugging in the future.
Refs: LP: #2115811
netplan apply warns about any /etc/netplan/*.yaml file permissions which
are globally readable. Set permissions 600 for
/etc/netplan/01-network-manager.yaml in target chroot.
LP: #2119020
Questing is currently on kernel 6.17 so preseeding fails with a apparmor
feature mismatch given that the live-build/apparmor/generic tree is
used. Adding a 6.17 tree solves this.
* Fix daily-dangerous builds:
- Copy hooks.
- Mangle the channel of seeded snaps to use the edge risk of whichever
track they are taken from.
- Update the dangerous model to reference tracks that actually exist.
- Include providers of content plugs when seeding snaps and creating
TPMFDE system.
- Do not attempt to build an UEFI boot image or hyperv desktop image for
this project/subproject combination.
We cannot use After=snapd.service as user services cannot synchronize
with system services. Using `snap system wait seed.loaded` should work,
except for the fact that it requires polkit authentication to perform
this operation.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
LXD is going to support launching riscv64 virtual machines,
and for riscv64 virtual machines to be usable the console
needs to be properly set. This and other fixes are currently
done in the hook 999-cpc-fixes.chroot, which was disabled for
riscv64 and which this commit enables.
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
We want the firmware updater and security center pointing to edge too.
The model only allow to select it, but we need to invoke them by
default in snap prepare-image
We need edge on the live session too so that subiquity knows about
latest and greatest on TPM FDE support. We will revert that once snapd
is released to the stable channel.
layer construction involves rsync, and that process ignores times to
avoid some of the layers being larger than they would otherwise where
the only difference is times. This saves a small amount of space,
around 14MiB, but results in files in the layers having non-intended
time values. Ensure mtime and atime in the source chroot match what is
found in the destination chroot.
To get 25.10 Desktop ISOs with TPMFDE bits, we need matching pc-kernel
and snapd otherwise we get errors like so when running
`snap prepare-image`:
WARNING: the kernel for the specified UC20+ model does not carry
assertion max formats information, assuming possibly incorrectly the
kernel revision can use the same formats as snapd
error: snapd 2.68+ is not compatible with a kernel containing snapd
prior to 2.68
Use the "dangerous" model, which allows overriding the channel, and pick
up the matching pc-kernel which is not yet on 25.10/stable, where the
non-dangerous model would expect to find it.
Also see https://bugs.launchpad.net/cloud-images/+bug/2106729.
Since Oracular[1]:
Ubuntu’s systemd-networkd no longer sets UseDomains=true for managed
network interfaces. In effect, this means that search domains
configured in DHCP leases will not be reflected in /etc/resolv.conf
by default. This change aligns Ubuntu’s default behavior with that
of upstream. System administrators may choose to override this
default on a global, or per-interface basis. See systemd.network 4
for details.
The default in systemd is UseDomains=false. From systemd.network(5)[2]:
DHCP=
Furthermore, note that by default the domain name specified
through DHCP is not used for name resolution. See option
UseDomains= below.
UseDomains=
It is recommended to enable this option only on trusted
networks, as setting this affects resolution of all hostnames,
in particular of single-label names. It is generally safer to
use the supplied domain only as routing domain, rather than as
search domain, in order to not have it affect local resolution
of single-label names.
It has been reported to us by few clouds that this breaks local name
resolution. For instance, in Google Cloud Compute, users can no longer
reach instances in the same zone[3] nor Google Cloud services[4] by
their names.
Arguably, the security concerns for having this option disabled are not
valid in cloud environments. As one of our partners said:
IIUC, the motivation to disable UseDomains by default is that a
laptop might be used on an untrusted network where the domains
provided by DHCP can be a security issue, directing users to places
they don't intend.
But it's not possible for a cloud instance to be connected to an
untrusted network (barring a breached account).
The way I'm looking at this is that DHCP option 119 exists for the
express purpose of allowing a network administrator to configure the
DNS search path for computers on that network. I understand there's
a security concern if that network isn't a datacenter. But in the
cloud there's no concern (in some clouds, it's not even possible for
DHCP response packets to come from anywhere but the cloud's own
DHCP).
We should restore this setting in cloud images.
[1] https://discourse.ubuntu.com/t/oracular-oriole-release-notes/44878
[2] https://manpages.ubuntu.com/manpages/plucky/en/man5/systemd.network.5.html
[3] https://cloud.google.com/compute/docs/internal-dns
[4] https://cloud.google.com/compute/docs/metadata/overview
This model intentionally uses pc-kernel from a branch, for components
testing purposes. We'll have to update this again before release when
the desired pc-kernel is on a stable channel.
* Again in ubuntu-server builds, configure LAYERFS_PATH in the kernel layer
and ensure the initrd is freshly regenerated in that layer. LAYERFS_PATH
was being set to the layer below the kernel layer, which meant that the
live session did not get access to all the modules in the case that the
kernel had not been installed in the base layer, which in turn means that
installs fail. (LP: #2100148)
* While we're at it, delete any initrd from any other layer than a kernel
layer, as they just waste space on the ISO.
patch create_manifest to produce an sbom when called by an ubuntu-cpc
project. Patch all the ubuntu-cpc hooks and series files to include the
newly generated manifests, filelists, and sboms. Generates a number of
new artifacts in the builds. the snap utilized, cpc-sbom, is an open
source repo and a provided via a hidden snap. there is no intention of
publisizing the snap or how we generate sboms, however partners require
the ability to audit if required.
defensively checks if the snap is already installed, in the case of
multiple hooks being called in a single build (thus sharing a build
host), and only if called in an ubuntu-cpc project.
(cherry picked from commit 7c7b7df89dc96169db1f255d6bba901ebb63a43c)
Plucky is currently on kernel 6.12 so preseeding fails with a apparmor
feature mismatch given that the live-build/apparmor/generic tree is
used. Adding a 6.12 tree (which is identical with the 6.11 tree)
solves this.
U-Boot with distroboot has:
efi_dtb_prefixes=/ /dtb/ /dtb/current/
So we should install the device-trees into dtb/ and not dtbs/ on the EFI
system partition.
Fixes: 365435ad2dbe ("riscv: copy device trees to the ESP")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Commit f9c5020200ce ("riscv: directly copy device trees to /boot/dtbs")
incorrectly copied devicetrees into /boot/dtbs/$kvers instead of /boot/efi/dtbs,
inside the ESP and where U-boot expects them. This commit fixes this path.
Fixes: f9c5020200ce ("riscv: directly copy device trees to /boot/dtbs")
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
We are removing our different variants of wsl rootfs with the new
Microsoft format. We only keep one following the distribution policy:
- lts to lts
- intermediate release to next one
Co-authored-by: Carlos Nihelton <carlos.santanadeoliveira@canonical.com>
The previous Tegra kernel metapackage implementation (linux-nvidia-tegra-igx)
was initially planned to apply both for Jetson devices and IGX systems. It turned
out recently (LP: #2069179) that we now need to reserve the metapackage name
linux-nvidia-tegra-igx for IGX systems, and use the new linux-nvidia-tegra-jetson
metapackage for Jetson devices. For the sake of clarity, the image name, model,
sub-arch, variant should align with the kernel metapackage name.
LP:2083240
starting in noble, adduser no longer creates a homedir for system users.
The buildd user then does not have a home directory, causing snaps to be
unable to run, as well as possibly other issues from a missing assumed
homedir. Explicitly create /home/buildd
Version 1 of install-sources.yaml is a top-level list of the sources to
be offered.
Version 2 extends this by placing the list under a top-level key
`sources`, adding a `version` field, and adding a `kernel` field which
supplants the current kernel-meta-package file. `kernel.default` is
read to know which kernel to use - unless we need to fallback to the
bridge kernel.
This reverts commit c4e69348aed2e89bdef0187afe79da18d855eb8c as
the more debugging is needed for autopkgtest failures and is
therefore blocking apparmor fixes for cloud images.
In cloud-init version 24.3, single process mode where a shared python
systemd service cloud-init-main. In that release, cloud-init.service was
renamed cloud-init-network.service to better clarify cloud-init's
systemd unit names relative to the cloud-init boot stages.
This rename only applies to Oracular and newer releases.
See: https://discourse.ubuntu.com/t/announcement-cloud-init-perfomance-optimization-single-process/47505
functions drops in a complete override for cloud-init.service. That
override in /etc/systemd/system needs to be renamed and refreshed to
latest single process configuration.
LP: #2081325
kdump-tools uses ucf for config file management and naively
modifying the config file meant for the target system directly
will cause the file hash to not get updated in the ucf database.
This will then cause later modifications to fail because
"there's nothing to do". Although actually doing the modification
to the ucf database is messy. Let's just modify the file in the live
layer to get the behavior we want there.
We install the kdump-tools package to minimal layer via inclusion in the
desktop-minimal seed, but it is enabled by default. Include a new chroot
hook to set USE_KDUMP=0 to make sure it's disabled by default and let
the installer decide to enable it or not.
We install the kdump-tools package to minimal layer via inclusion in the
server-minimal seed, but it is enabled by default. Include a new chroot
hook to set USE_KDUMP=0 to make sure it's disabled by default and let
the installer decide to enable it or not.
By placing the kernel in minimal, we can achieve the following
improvements:
1. Space savings - there are redundant packages present in the ship-live
pool and in the live layer. Adding the kernel to minimal means that
the kernel is already in the live layer, and we don't then also need
it in the pool.
2. Time savings - informal vm testing suggests more than a minute
improvement to have the kernel preinstalled over installing it at
runtime.
As always, there is a cost tradeoff:
1. If a different kernel is desired, we need to be able to remove this
preinstalled kernel. Relevant curtin and subiquity changes are
already landed.
2. When installing that other kernel, it'll take longer than today due
to still needing to install a kernel at runtime + the time cost of
removing the preinstalled kernel.
Support some systems which don't handle partition numbers
higher than 15. (LP: #2072929)
Partition 16 was added for /boot to enable cloud FDE (commit a8b2a9b01)
Ubuntu Studio wants to add a minimal installation. The individual tasks
are metapackages that can be installed by the ubuntustudio-desktop task.
With that in mind, we would like to reintroduce
ubuntustudio-desktop-core as a minimal installation. This is made much
easier with the layered images compared to the package removal format
used by ubiquity. This also means ubuntustudio-desktop-core becomes the
base seed.
If I'm missing anything, please advise.
System override drop-ins cannot redact dependencies (Before or After) and
thus require a full unit override. Avoid writing the unit file delivered
by cloud-init deb package in /lib/systemd/system/cloud-init.service because
it will generate warnings fron debsums -c about modified files.
The correct place to provide a full unit override is in
/etc/systemd/system/cloud-init.service in order to drop
Before=sysinit.target from the packaged cloud-init.service file.
Note vigilance will be needed across cloud-init SRU boundaries to ensure
we sync any cloud-init.service unit changes that are introduced to
stable releases because livecd-rootfs is overriding the whole file.
LP: #2069391
The lowlatency kernel will eventually undergo deprecation. Rather than
wait for such a time to happen and be reactive, Ubuntu Studio would
rather be proactive about this now that the generic kernel can act as a
lowlatency kernel with certain command line parameters as outlined by
https://discourse.ubuntu.com/t/fine-tuning-the-ubuntu-24-04-kernel-for-low-latency-throughput-and-power-efficiency/44834.
As such, we have modified our `ubuntustudio-lowlatency-settings`
package, which installs `/etc/default/grub.d/ubuntustudio.cfg` with the
following line:
-GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT threadirqs"
+GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT preempt=full
nohz_full=all threadirqs"
Additionally, that same file used to set "GRUB_FLAVOUR_ORDER" which is
no longer needed.
unminimize is currently present at /usr/local/sbin/unminimize,
which is spit out by livecd-rootfs currently. We'd like to switch
that to use the packaged unminimize, which will be at
/usr/bin/unminimize instead.
There was a change made by me in https://code.launchpad.net/~philroche/livecd-rootfs/+git/livecd-rootfs/+merge/466388
as part of LP: #2066905 to remove references to LXD in the unminimize scripts
but I also removed the calls to `unminimize` in error.
This still needs to run but without any references to LXD which no longer
needs to be `unminimized` via snap installation.
The ubuntu-core-installer image is an installer that installs ubuntu
core. The environment the installer runs in is similar to the server
installer but it has a source catalog entry that points to the model
created in ubuntu-core-installer/hooks/05-prepare-image.binary, which
subiquity knows how to install.
With current kernel we need to specify the SBI driver
for the early console to work.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
fix: No longer install LXD snap in unminimize script (LP: #2066905)
The LXD snap is no longer seeded in any images since Noble+ so the LXD related unminimize logic in
./live-build/auto/build?h=ubuntu/noble and ./live-build/ubuntu-server/hooks/01-unminimize.chroot_early
is no longer required.
lxd-installer can remain installed.
MP: https://code.launchpad.net/~philroche/livecd-rootfs/+git/livecd-rootfs/+merge/466316
The LXD snap is no longer seeded in any images since Noble+ so the LXD related unminimize logic in
./live-build/auto/build?h=ubuntu/noble and ./live-build/ubuntu-server/hooks/01-unminimize.chroot_early
is no longer required.
lxd-installer can remain installed.
fix(HyperV desktop): Re-enable ability to build HyperV desktop images (LP: #2064280)
We have not built Hyperv desktop images since Jammy and with the re-introduction of HyperV for Noble we have encountered build issues caused by refactoring and removals of code assumed to be redundant but the HyperV desktop images were actually using these code paths.
In bbedffe6 we split the building of cloud images and non cloud to using an ddisk-image-uefi.binary and disk-image-uefi-non-cloud.binary respectively. In e38264ca there was a change which meant that any attempt to build hyperv images would result in incorrect disk size and incorrect disk label.
This has been fixed by ensuring that the ubuntu:desktop-preinstalled $PROJECT:$SUBPROJECT matches and sets the correct disk size and correct disk label.
A change in 76d79466 changed the logic of how the image size for amd64 images were being set. This overrode the sizes set for the desktop images incorrectly.
This MP ensures that hyperv desktop images can now be built and successfully launched with hyperv manager.
MP: https://code.launchpad.net/~philroche/livecd-rootfs/+git/livecd-rootfs/+merge/465288
For Ubuntu 24.04 and later cloud-init is included in desktop images. This is not applicable for Hyperv images so
we can disable cloud-init. This leaves the cloud-init package installed but disabled so users can still
use it if they want.
This is a documented way to disable cloud-init. See https://cloudinit.readthedocs.io/en/latest/howto/disable_cloud_init.html
A change in 8fb21808 also removed many of the dependencies that the hyperv images require.
This removal has been restored in this commit by adding them expliciltly in the hyperv hook.
We have not built Hyperv desktop images since Jammy and with the re-introduction of HyperV for Noble we have encountered build issues caused by refactoring and removals of code assumed to be redundant but the HyperV desktop images were actually using these code paths.
In bbedffe6 we split the building of cloud images and non cloud to using an ddisk-image-uefi.binary and disk-image-uefi-non-cloud.binary respectively. In e38264ca there was a change which meant that any attempt to build hyperv images would result in incorrect disk size and incorrect disk label.
This has been fixed by ensuring that the ubuntu:desktop-preinstalled $PROJECT:$SUBPROJECT matches and sets the correct disk size and correct disk label.
A change in 76d79466 changed the logic of how the image size for amd64 images were being set. This overrode the sizes set for the desktop images incorrectly.
This commit ensures that any desktop image being created uses the correct image size.
2024-04-30 18:00:07 +01:00
343 changed files with 5295 additions and 1379 deletions
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
