- coreos-status - Fedora mailing-lists

System console changing to platform-specific defaults
by Benjamin Gilbert 16 Sep '22

16 Sep '22

Hi all, Over the next couple months, we'll be rolling out a change to the Fedora CoreOS default console. The current default depends on the CPU architecture: - On x86_64, the first serial port ttyS0 is the primary console and the graphical console is secondary. - On other architectures, Fedora CoreOS generally does not configure a particular console, leaving the bootloader and kernel to follow their own defaults. This typically means that a graphical console is used if one is available, and a serial console otherwise. The new defaults will depend on both the CPU architecture and platform. The exact configuration is in [1]; in summary: - On many architecture/platform pairs, Fedora CoreOS will allow GRUB and the kernel to follow their own defaults. On x86_64, this causes the graphical console to be selected, even if no video card is available. In particular, *x86_64 bare metal installs will no longer use a serial console by default*. - On platforms that expect specific system consoles to be used, such as AWS, Azure, and GCP, Fedora CoreOS will select those consoles by default. - The QEMU image will continue to select ttyS0 as the primary console and the graphical console as secondary. These changes will be introduced to the Fedora CoreOS `next` stream the week of October 3, `testing` the week of November 28, and `stable` the week of December 12. The changes will only affect new Fedora CoreOS installations; upgraded systems will retain their current console settings. If the new defaults aren't appropriate for your environment, you can override them in several ways: - For bare metal machines installed with coreos-installer 0.16.0+, use the `--console` install option to specify the desired consoles using kernel command-line syntax [2]. This will configure both the GRUB bootloader and the kernel. For example, to retain the previous console behavior, install with `--console tty0 --console ttyS0,115200n8`. To customize the --console parameter in a live image, use `iso customize --dest-console` or `pxe customize --dest-console`. - For machines launched directly from an OS image, use the Butane kernel_arguments section to configure the desired console kernel arguments. For example: variant: fcos version: 1.4.0 kernel_arguments: # Order is significant, so treat these as a single argument should_exist: ["console=tty0 console=ttyS0,115200n8"] Note that this will not affect the consoles used by the bootloader. - For the unusual case of a virtual machine installed with coreos-installer, be sure to use the `--platform` install option to specify the virtualization platform, such as `vmware`. coreos-installer 0.15.0+ will automatically configure the default console for that platform. If the Fedora CoreOS console configuration is important for your environment, please test the new defaults in the `next` stream after October 6. If you have any questions or concerns, contact us in #fedora-coreos on Libera.Chat or open an issue in the Fedora CoreOS tracker [3]. --Benjamin Gilbert, for the Fedora CoreOS team [1]: https://github.com/coreos/fedora-coreos-config/pull/1781/files [2]: https://www.kernel.org/doc/html/v4.14/admin-guide/serial-console.html [3]: https://github.com/coreos/fedora-coreos-tracker/issues/new/choose

1 0

Fedora CoreOS next stream rebased to Fedora Linux 37
by Dusty Mabe 13 Sep '22

13 Sep '22

Fedora Linux 37 Beta was released today [1]. Our Fedora CoreOS `next` stream has been migrated to Fedora Linux 37 content. Existing nodes on the `next` stream will update as normal over the following days. The Fedora Project accepted changes for Fedora 37 are at [2] and the Fedora CoreOS analysis of each change is documented in the tracker issue ticket #1222 [3]. Please test out the `next` stream over the coming month and report any issues in our issue tracker [4]. Thank you to everyone helping find issues by running the `next` stream! The Fedora CoreOS Team [1] https://fedoramagazine.org/announcing-fedora-37-beta/ [2] https://fedoraproject.org/wiki/Releases/37/ChangeSet [3] https://github.com/coreos/fedora-coreos-tracker/issues/1222 [4] https://github.com/coreos/fedora-coreos-tracker/issues

1 0

Format change for Nutanix artifact
by Sohan Kunkerkar 19 May '22

19 May '22

Hi all, The format of the Fedora CoreOS Nutanix image will change [1] in the next release of the Fedora CoreOS `next` and `testing` streams. Current releases ship the Nutanix image as a qcow2 file wrapped with xz compression (`qcow2.xz`). Future releases will switch to a qcow2 file without any wrapper (`qcow2`), internally compressed with qcow2's built-in compression support. Following the usual release schedule, this change will promote to the `stable` stream two weeks after the `next` and `testing` releases. We are making this change to support direct uploading of Fedora CoreOS images into Nutanix AHV using the Nutanix Prism API. This allows users to avoid manually downloading, decompressing, and re-uploading Fedora CoreOS images when adding them to Nutanix Prism Central. If you use the Nutanix image, you will need to adjust your workflow [2] for adding Fedora CoreOS images to Nutanix AHV. If you do not use the Nutanix image, this change will not affect you. If you have any questions or concerns, or expect this change to break a critical workflow, please contact us via `#fedora-coreos` on Libera.Chat or file an issue in the Fedora CoreOS tracker [3]. --Sohan Kunkerkar, for the Fedora CoreOS team [1]: https://github.com/coreos/coreos-assembler/pull/2848 [2]: https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-nutanix/#_u… [3]: https://github.com/coreos/fedora-coreos-tracker/issues/new/choose

1 0

Ignition config accessible to unprivileged software on VMware
by Benjamin Gilbert 19 May '22

19 May '22

Hi all, Unprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment. If the Ignition config contains secrets, this can result in the compromise of sensitive information. Starting with next week's Fedora CoreOS `testing` and `next` releases, Ignition will delete the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot. This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor. Existing machines will likewise delete the config when first upgraded to a new release. This change will be promoted to Fedora CoreOS `stable` after two weeks, as usual. Note that in general, we do not recommend storing secrets in Ignition configs [1]. In addition to VMware, many cloud platforms allow unprivileged software in a VM to retrieve the Ignition config from a networked cloud metadata service. While platform-specific mitigation is possible, such as firewall rules that prevent access to the metadata service, it's better to store secrets in a dedicated platform such as Hashicorp Vault [2]. If you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent deletion by masking ignition-delete-config.service. For newly-launched machines: variant: fcos version: 1.0.0 systemd: units: - name: ignition-delete-config.service mask: true To prevent upgrades from affecting existing machines: $ sudo systemctl mask ignition-delete-config.service If you have any questions or concerns, contact us in #fedora-coreos on Libera.Chat or open an issue in the Fedora CoreOS tracker [3]. --Benjamin Gilbert, for the Fedora CoreOS team [1]: https://coreos.github.io/ignition/operator-notes/#secrets [2]: https://www.vaultproject.io/ [3]: https://github.com/coreos/fedora-coreos-tracker/issues/new/choose

1 0

Fedora CoreOS streams rebasing to Fedora Linux 36
by Dusty Mabe 09 May '22

09 May '22

Following our scheduling policy around Fedora major version releases [1] we will be rolling out the Fedora Linux 36 rebase over the next few weeks. This will start tomorrow with the `testing` stream. During this development cycle we continued to follow the Fedora Change process more closely [2] in order to provide a smoother transition of incoming Fedora Changes. We also closely watched our package additions/removals [3] to carefully evaluate any changes and determine if they were intentional. Current known issues: - network device IP doesn't get displayed to console [4] Notable transitions in the Fedora 36 rebase: - Podman 4.0, with some backwards incompatible changes [5] - iptables nft by default, along with auto-migration [6] Some highlights of recently added features/improvements: - added a VirtualBox artifact [7] and updated documentation [8] - added a Nutanix artifact [9] - added support for a minimal ISO image [10] - updated the VMWare OVA to use UEFI/SecureBoot by default [11] - added CI testing for Azure [12] Thanks to everyone who participated in the test week [13] and to everyone that follows the `testing` and `next` streams to help us identify and fix issues before they get to `stable`. Dusty Mabe, for the Fedora CoreOS team [1] https://github.com/coreos/fedora-coreos-tracker/blob/main/Design.md#major-f… [2] https://github.com/coreos/fedora-coreos-tracker/issues/918 [3] https://github.com/coreos/fedora-coreos-tracker/issues/1128 [4] https://github.com/coreos/fedora-coreos-tracker/issues/1153 [5] https://discussion.fedoraproject.org/t/fedora-coreos-moving-to-podman-v4/37… [6] https://discussion.fedoraproject.org/t/fedora-coreos-moving-to-iptables-nft… [7] https://github.com/coreos/fedora-coreos-tracker/issues/1008 [8] https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-virtualbox/ [9] https://github.com/coreos/fedora-coreos-tracker/issues/1007 [10] https://github.com/coreos/fedora-coreos-tracker/issues/868 [11] https://github.com/coreos/fedora-coreos-tracker/issues/1140 [12] https://github.com/coreos/fedora-coreos-tracker/issues/1020 [13] https://github.com/coreos/fedora-coreos-tracker/issues/1123#issuecomment-10…

1 0

Fedora CoreOS dropping libvarlink-utils from base OSTree
by Gursewak Singh 04 Apr '22

04 Apr '22

We have decided to remove `varlink` (provided by the `libvarlink-utils` package) from Fedora CoreOS. Podman was the primary consumer of this package and the use of it was removed in Podman v3.0 and later [1]. At the moment, we are not aware of any other consumers of libvarlink-utils on FCOS. The package will initially be removed from the `next` stream. It will be followed by `testing` and `stable` after it has been removed from `next` for at least a month. The Fedora CoreOS Team [1] https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice.html…

1 0

Fedora CoreOS next stream rebased to Fedora Linux 36
by Dusty Mabe 29 Mar '22

29 Mar '22

Fedora Linux 36 Beta was released today [1]. Our Fedora CoreOS `next` stream has been migrated to Fedora Linux 36 content. Existing nodes on the `next` stream will update as normal over the following days. In addition to the Fedora Project accepted changes for Fedora 36 [2], there are a few Fedora CoreOS recent announcements to consider with this update: - Fedora CoreOS moving to podman v4 [3] - Fedora CoreOS moving to iptables-nft [4] Please test out the `next` stream over the coming month and report any issues in our issue tracker [5]. Thank you to everyone helping find issues by running the `next` stream! The Fedora CoreOS Team [1] https://fedoramagazine.org/announcing-fedora-36-beta/ [2] https://fedoraproject.org/wiki/Releases/36/ChangeSet [3] https://discussion.fedoraproject.org/t/fedora-coreos-moving-to-podman-v4/37… [4] https://discussion.fedoraproject.org/t/fedora-coreos-moving-to-iptables-nft… [5] https://github.com/coreos/fedora-coreos-tracker/issues

1 0

Changes to VMware OVF metadata
by Micah Abbott 24 Mar '22

24 Mar '22

We have planned some changes to the OVF metadata inside the Fedora CoreOS VMware OVA. Scheduled for the next cycle of `testing` and `next` releases: - OVF metadata will select UEFI firmware by default - OVF metadata will enable Secure Boot by default - OVF metadata will identify the OS as Fedora instead of RHEL 7 These changes will flow into `stable` the week of April 11. You can track the status of this change at https://github.com/coreos/fedora-coreos-tracker/issues/1140. Scheduled for after October 15, when vSphere 6.5 and 6.7 will reach end of life: - OVF metadata will update from hardware version 13 to version 17 You can track the status of this change at https://github.com/coreos/fedora-coreos-tracker/issues/1141. If these changes break your deployment workflow, please follow up in the issues listed above or open a new issue. Micah Abbott, for the Fedora CoreOS team

1 0

Latest kernel update can cause NFS mount failures
by Dusty Mabe 14 Mar '22

14 Mar '22

The most recent kernel update to 5.16.13-200.fc35 has been reported to cause failures for NFS clients connecting to some QNAP NAS systems. Details of the issue as well as links to upstream forum posts and downstream bug reports can be found in our issue tracker: https://github.com/coreos/fedora-coreos-tracker/issues/1121 Fortunately this bug was caught in our `testing` stream. Unfortunately, we do need to proceed promoting this kernel into our `stable` stream because the update will fix CVE-2022-0847 (known as "dirty pipe"). If you will be affected by this bug, the easiest workaround is to switch the mount options for the mount to add `vers=4.0` for NFS 4.0. You can then follow progress in the tracker issue to know when to revert the change. Dusty Mabe for the Fedora CoreOS Team

1 0

Fedora CoreOS moving to podman v4
by Jonathan Lebon 01 Mar '22

01 Mar '22

In the coming months, the Podman container runtime will be upgraded from v3 to v4. This is a major release [1] that introduces backward incompatible changes to configuration files and APIs. The full release notes for Podman v4 are available at [2]. Here is a brief summary of how this will impact Fedora CoreOS nodes: - Existing containers will be preserved without any change required. - Compatibility for the Docker API is fully preserved. - Users of the Podman remote API will need matching server/client versions. - Rollbacks to a version with Podman v3.x will require manual action. - Only new installations will use the new network stack by default. For more details, see the Major Changes page in the Fedora CoreOS documentation [3]. This change will be rolled out together with the rebase to Fedora 36: - the `next` rebase is targeted for 2022-03-15 - the `testing` rebase is targeted for 2022-04-19 - the `stable` stream will follow `testing` as usual Thanks, Jonathan Lebon, for the Fedora CoreOS team [1] https://podman.io/releases/2022/02/22/podman-release-v4.0.0.html [2] https://github.com/containers/podman/releases/tag/v4.0.0 [3] https://docs.fedoraproject.org/en-US/fedora-coreos/major-changes/#_podman_v…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

coreos-status