The serial device name on Arm is ttyAMA, not ttyS. This splits the
configuration for Cloud images based on the architecture and adjusts the
kernel command line.
Note that prior to this change, aarch64 would still output kernel logs
to the ttyAMA0 console (on Azure, at least) due to the ACPI SPCR table.
On aarch64 the console in this table, if it's present, is _always_
configured as the kernel's default console. However, systemd logs would
not be sent to the serial console because it seems it was honoring the
kernel command line configuration which had ttyS0 as the default.
Also see: https://pagure.io/cloud-sig/issue/394
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1661288
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
This became necessary with 10.0.13 / after merging
https://github.com/OSInside/kiwi/pull/2535 but doesn't seem to
noticeable effects besides miisin "GRUB_ENABLE_BLSCFG=true" in
/etc/default/grub.
Most of the changes are self-explanatory and just follow what's
already happening for existing architectures.
Two things are worth pointing out:
* we need to use shim-unsigned instead of shim-signed because
riscv64 is not fully integrated into Fedora yet and so we
can't do Secure Boot signing for the time being;
* we use ext4 as bootfilesystem since in most cases the
underlying firmware is going to be U-Boot, which needs to be
able to load the board's DTB from /boot and doesn't support
XFS.
Signed-off-by: David Abdurachmanov <davidlt@rivosinc.com>
This package is intended to be the place for Azure utilities along with
the various udev rules that currently live in the WALinuxAgent package.
At the moment it just contains the `azure-nvme-id` binary and udev rules
for providing symlinks in /dev/disk/azure/ for local, data, and
OS disks.
The amazon-ec2-utils package includes udev rules that make it easier to
identify block storage devices and sets some configuration for other
storage devices.
Users can run awscli2 to manage their AWS cloud resources.
The ec2-instance-connect package allows one click console access to a
Fedora instance from the AWS console (website).
Signed-off-by: Major Hayden <major@redhat.com>
It was previously being pulled in via weak dependencies of fwupd,
but we removed fwupd in #47 and now it's not there any more. It
is needed for the first boot resize by cloud-init to work, since
we use a btrfs filesystem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's the *Google* image that's required to have a 10 GB root
for performance reasons, not the EC2 image, as the comment says,
but the change was inadvertently applied to the EC2 image not
the Google one. This means our Google image is slow and our EC2
images are failing to be published as AMIs.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Most of the Fedora Cloud-owned profiles are limited to a subset of
architectures, generally x86_64 and aarch64 (with the exception of
the VirtualBox Vagrant image, which is x86_64 only).
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