| Age | Commit message (Collapse) | Author |
|
This lets us free up the space allocated for the partition and gives
us dynamically allocated space for boot data like we have with the
rest of the operating system.
We do not do this for s390x because zipl does not support it.
Reference: https://fedoraproject.org/wiki/Changes/BtrfsBootForCloud
|
|
With the increase in content in initramfs, a long-overdue raise
of the default size for /boot is warranted.
Reference: https://fedoraproject.org/wiki/Changes/2GbootPartition
|
|
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.
|
|
updates for "virtual image" usable under KVM
- don't use 4k block size
- don't use CDL partitioning
- don't use DASD related kernel parameters
|
|
|
|
systemd 256 added a new feature which wants to create users on
boot if none exist yet:
https://github.com/systemd/systemd/commit/3ccadbce3358ba1db7ce5fa3f8dd17c627ffd93b
We don't want that, cloud-init handles this situation. So let's
disable it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
|
|
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>
|
|
|
|
Use consistent network device names for network devices instead of
forcing the old "ethX" names from pre-2017. This ensures that
specialized network devices, such as SR-IOV devices, are easy to
recognize and configure inside a Fedora instance on a public cloud or
OpenStack cloud.
FESCo ticket: https://pagure.io/fesco/issue/3190
Change proposal: https://fedoraproject.org/wiki/Changes/EnableConsistentDeviceNamingCloud
Signed-off-by: Major Hayden <major@redhat.com>
|
|
Fixes booting the Generic image on systems without any video device.
ref. https://github.com/teemtee/tmt/issues/2771
|
|
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>
|
|
This allows building cloud images for Z systems.
|
|
Anything lower than that causes performance problems.
|
|
This ensures that the correct variant packages are installed.
|
|
This allows building cloud images for POWER systems.
|
|
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).
|
|
This makes it easier to read what all the settings are.
|
|
This pulls in a number of services to integrate a guest running under
Hyper-V. These services are all automatically activated via udev rules.
|
|
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.
|
|
In the event that there's an issue with early boot, setting
earlyprintk=ttyS0 ensures that the messages are routed to the serial
console so it can be debugged.
This particular option is documented as required in the Azure VM
certification FAQ[0].
[0] https://learn.microsoft.com/en-us/partner-center/marketplace/azure-vm-certification-faq#linux-test-cases
|
|
This realigns the configuration into separate files/folders that
would be modified by specific teams (e.g. WGs and SIGs).
|