Up to now we have used u-boot-menu for preinstalled images for the SiFive
HiFive Unmatched and Unleashed boards and GRUB for all other RISC-V images.
The choice was made because RISC-V GRUB was not available when the SiFive
boards where released.
Let the Unmatched and Unleashed board preinstalled images use GRUB.
Simplify the code.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Canonical Public Cloud's project seems a bad place to build images for
hardware devices however this is how things were done a we now need to
maintain this.
The recent change to mount the ESP on /boot breaks those images, instead
of adding more hacky things in the hook, create a dedicated target for
those images and use a different hook to build UEFI images.
This is required by the new UEFI binary hook as we mount the ESP on
/boot and the ESP filesystem doesn't support symlinks.
We keep symlinks for s390x images which do not use UEFI anyway.
This is driven by online encryption scenarios. In order to efficiently
encrypt the root filesystem without modifying the partition layout, the
kernel should sit in an un-encrypted /boot partition. Instead of
creating a new partition that would change the default partition layout,
we mount the ESP on /boot. We also need to then bind mount /boot on
/boot/efi because that's where Grub expects the ESP to be located.
missing a && between icicle and visionfive, led to /boot/efi still being
in place, and grub-install running instead of exiting the func.
fixes LP:2015750
SUBARCH=visionfive2 is used to build images for the StarFive VisionFive 2
boards. For the device-tree we assume board revision 1.3B.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
For the SiFive HiFive Unmatched board we create a pre-installed image using
u-boot-menu. Increase the watchdog threshold in this case too.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
This allows to consolidate linux-kvm and linux-generic kernel
flavours. This brings the perfomance benefit of linux-kvm flavour to
all cloud and pre-installed images. It does trade data-safety.
LP: #2006511
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
According to the EBBR specification the GPT partitions for firmware should
have attribute bit 0 (Required Partition) set.
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.
The cloud-init bug (see LP:1968873) got fixed now so using a sshd
config snippet should work now.
This partly reverts commit aa1be5eaaa1fdbb4c31104cc49e54b15f66c3343
but uses now 60-cloudimg-settings.conf instead of
10-cloudimg-settings.conf .
While merging the VisionFive support, we removed the installation of
u-boot-menu for the Unmatched by mistake: fix this by reinstating it.
Fixes: ce9f5caccadf ("riscv: Add support for StarFive VisionFive")
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
This change triggered a bug in cloud-init (see LP:1968873). cloud-init
does not recongnize sshd options set in /etc/ssh/sshd_config.d/ and
cloud-init modifies directly /etc/ssh/sshd_config which gets then
overwritten by settings from /etc/ssh/sshd_config.d/ .
This reverts commit b54d24ff3310f7ace00ab08e0dacfdc89e026f1c.
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>
