With Radeon GPUs and kernel 5.19 a soft lockup was observed.
Increase the watchdog threshold.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Using numbered configuration fragments makes the order of application
easier to track
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since version 2022.10 U-Boot SPL and U-Boot are installed onto the same partition.
Package nezha-boot0 is not needed anymore.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
RISC-V boards tend to boot slowly.
We should provide progress information when booting.
Use 'efi=debug earlycon' on the Linux command line via new file
/etc/default/grub.d/cmdline.cfg.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The Nezha and the LicheeRV boards do not have enough memory for an initrd
with most modules. Therefore the number of included modules has to be
reduced.
Create file /etc/initramfs-tools/conf.d/modules_list.conf
to set MODULES=list.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Remove redirections of type
command &1>2
Executing the command in the background and creating and empty file '2'
was never intended.
As the messages are information only redirecting to stderr would not make
sense either.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The LicheeRV Dock board comes with only 512MB of DRAM so the only difference
with a Nezha image is the fact that we have to remove
cryptsetup-initramfs package which makes the initrd too big for the
board to boot.
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Current Kinetic GCE image builds are failing with the following error:
update-initramfs: Generating /boot/initrd.img-5.19.0-1004-gcp
zstd: error 25 : Write error : No space left on device (cannot write compressed block)
E: mkinitramfs failure zstd -q -1 -T0 25
Seems like after `linux-gcp` update from 5.15 to 5.19 `linux-modules` package
has gotten ~40MB larger and with that GCE image builds are over the edge wrt
available disk space in chroot.
Bumped up disk image size for amd64 to 3.5GB to match the sizes used by armhf
and generic images.
While merging the VisionFive support, we removed the installation of
u-boot-menu for the Unmatched by mistake: fix this by reinstating it.
Fixes: ce9f5cacca ("riscv: Add support for StarFive VisionFive")
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
3.5G is not enough for riscv64 preinstalled as the creation of the initrd fails
with the following error:
Creating config file /etc/default/grub with new version
Processing triggers for initramfs-tools (0.140ubuntu13) ...
update-initramfs: Generating /boot/initrd.img-5.15.0-1011-generic
zstd: error 25 : Write error : No space left on device (cannot write compressed block)
E: mkinitramfs failure zstd -q -1 -T0 25
update-initramfs: failed for /boot/initrd.img-5.15.0-1011-generic with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
The image created uses a UEFI bootflow, so we install grub for this board
only. We also need flash-kernel to install the dtb where grub can find
it.
This image is specifically architectured so that it can be installed on
a "factory" board, meaning using the u-boot firmware which was
originally implemented for Fedora, so we need the p3 partition that
embeds a uEnv.txt file to tell u-boot what/where to load next stage.
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Define the image layout for the Nezha board.
The U-Boot SPL based boot0 may be installed starting in sector 16 or 256.
As sector 16 is incompatible with GPT partitioning use sector 256.
The primary U-Boot image is expected to start at sector 32800 and its
backup in sector 24576.
Cf. https://linux-sunxi.org/index.php?title=Allwinner_Nezha&oldid=24469
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This reverts part of a change causing regression with vmware import due to the
cdrom getting moved to SCSI while shifting controller IDs. (LP: #1970795)
LP: 1969664 tracks an issue related to the deprecation of rsa+ssh on
Jammy+ openssh server, coupled with upstream vagrant bugs, that cause
Jammy vagrant images fail to bootstrap due to ssh negotiation issues.
Moving to a different key algo from the upstream insecure key matches
Jammy's expectations, and works with older vagrant versions.
vagrant >= 2.2.16 hosts are unaffected by the issue, as an upstream
change was made. This change keep compatibility with newer vagrant
versions as well.
Readding this file per reviewer's request until CPC splits the
pipelines. Removing this file would make CPC image builds fail.
Co-authored-by: Didier Roche <didrocks@ubuntu.com>
Due to how `disk-image` file is structured, it builds BIOS and UEFI
images at the same time. However, certain images (e.g., GCE images)
require only UEFI image to be built, BIOS image is being simply
discarded. This results in longer build times.
Splitting out `disk-image-uefi` would allow images to use it instead of
`disk-image` and thus avoid building unused BIOS images.
`disk-image` now depends on `disk-image-uefi` for backward
compatibility.
Currently the RISC-V preinstalled server images come with partitions that
are only 1 KiB aligned. Ext4 may use 4 KiB block size. The existing
misalignment leads to decreased performance.
Decrease the size of the loader2 partition by 34 512-byte blocks. This
results in 1 MiB alignment of the EFI and root partitions.
The remaining loader2 partition size of close to 4 MiB is still large
enough for U-Boot or a future EDK II.
Fixes: a808b28d47 ("riscv64: build preinstalled riscv64 image with uboot SPL and CIDATA.")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Current jammy builds fail with:
dpkg: error processing archive /var/cache/\
apt/archives/grub-common_2.04-1ubuntu48_armhf.deb (--unpack):
cannot copy extracted data for './usr/share/grub/unicode.pf2' \
to '/usr/share/grub/unicode.pf2.dpkg-new': \
failed to write (No space left on device)
It hangs during booting when upgrading hardware
version ESXi after deploying image in groovy.
(Current default version is 10)
It could be resolved by adding serial port in VM
when vm version is larger than 10.
Seriaol port1 has been configured as default so
we need to change setting serial0 as false.
As wsl is an image target of ubuntu-cpc, the base seed is hardcoded to
ubuntu-server instead of wsl one. For now, add it, as for the other
cpc images, in hooks.
groovy hangs during boot on ESXi when the version is greater than
10. Adding a serial port by default fixes this specific bug - increasing
the HW version will be for another branch.
This is because more investigation is needed into whether it is possible to
increment ddb.virtualHWVersion without disrupting Oracle VirtualBox images.