Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun == Summary == The Fedora workstation livecd is the default Fedora variant getfedora.org advices people to download. As such most Fedora workstation installs will be done from the livecd. This means that any package which is part of the livecd will be part of the default install for most users. Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service, which waits for all device-detection to be done + some extra waiting just to be sure. This significantly slows down booting on various systems. Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service. The other package is device-mapper-multipath see [[Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD|Remove device-mapper-multipath from the Fedora workstation livecd]]. Dmraid is necessary to support firmware-raid (motherboard BIOS built-in RAID support) for non Intel firmware RAID sets. These RAID sets are quite rare and we have never supported configuring these RAID sets after the installation without manually setting it up. Since we only support these sets when they are already configured in the BIOS at installation time, we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. Note then when installing from the server or everything netboot isos, dmraid depending on the obsolete udev-settle service is not a problem, because then it will not be installed at all. Anaconda (the installer) adds storage related packages such as dmraid to the installation package-set as necessary for the storage found at installation time. This means that for such installs, if a dmraid set is later configured, the user manually needs to install dmraid to be able to use the RAID set. This change adds a similar requirement to livecd installs, there the user will now need to do a "systemctl enable dmraid.service" if a dmraid set is added to the system later. There has been [https://bugzilla.redhat.com/show_bug.cgi?id=1795014 a bug] open against dmraid for this issue for a while now. As pointed out there, this change can easily be implemented with some small changes to the shell script which gets started by the dmraid service. == Benefit to Fedora == systemd-udev-settle.service causes a significant and sometimes quite long delay during boot. Removing / disabling the last 2 services depending on this long obsolete helper service will remove the unnecessary boot delay. == Scope == * Proposal owners: ** Prepare the suggested dmraid activation script changes and push out a new dmraid package with these changes added ** Coordinate this with the dmraid maintainers * Other developers: ** I will make sure that the dmraid maintainers are aware of and agree with these changes. I will take care of these changes myself. * Release engineering: [https://pagure.io/releng/issue/9559 #9559] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == After upgrading, if no dmraid sets are found on the first boot with the new package, the dmraid service will disable itself, just as it will on new F33 installs. == How To Test == # Install F33 on a machine / VM without dmraid # Boot the installed system # Reboot the installed system # Do "systemctl status dmraid.service", the output should be "loaded (...; disabled; ...)" and "inactive (dead)" == User Experience == Faster booting Fedora when installed from the livecd. == Dependencies == There are no other changes / package updates this Change depends on; or which this change impacts. == Contingency Plan == * Contingency mechanism: Revert the activation script changes if they cause problems * Blocks release? No == Documentation == This change does not require any documentation. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD == Summary == The Fedora workstation livecd is the default Fedora variant getfedora.org advices people to download. As such most Fedora workstation installs will be done from the livecd. This means that any package which is part of the livecd will be part of the default install for most users. device-mapper-multipath is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service, which waits for all device-detection to be done + some extra waiting just to be sure. This significantly slows down booting on various systems. Multipath support is only necessary for installations in data-centers or other enterprise setups, as such having device-mapper-multipath on the livecd is not really necessary. For installations which do actually need this device-mapper-multipath the server installation iso can be used and this is a better fit for such installations. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == device-mapper-multipath is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service. The other package is dmraid see [[Changes/DisableDmraidOnFirstRun|Disable dmraid.service on first run]]. Multipath support is only necessary for installations in data-centers or other enterprise setups, as such having device-mapper-multipath on the livecd is not really necessary. For installations which do actually need this device-mapper-multipath the server installation iso can be used and this is a better fit for such installations. Note then when installing from the server or everything netboot isos, device-mapper-multipath depending on the obsolete udev-settle service is not a problem, because then it will not be installed at all. Anaconda (the installer) adds storage related packages such as device-mapper-multipath to the installation package-set as necessary for the storage found at installation time. So any installs done through the netinst isos already will not have device-mapper-multipath installed. == Feedback == == Benefit to Fedora == systemd-udev-settle.service causes a significant and sometimes quite long delay during boot. Removing / disabling the last 2 services depending on this long obsolete helper service will remove the unnecessary boot delay. == Scope == * Proposal owners: ** Change the livecd packagelist (comps) to no longer include the device-mapper-multipath package * Other developers: ** No action is required by other developers ** Except if another package still brings in device-mapper-multipath through dependencies, then this needs to be solved / coordinated with that other packages maintainers * Release engineering: [https://pagure.io/releng/issue/9560 #9560] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This only affects new installs, upgrades of installs which have device-mapper-multipath installed will still have it installed after the upgrade. == How To Test == # Install F33 on a machine / VM # Do "rpm -q device-mapper-multipath", the output should be "device-mapper-multipath" is not installed == User Experience == Faster booting Fedora when installed from the livecd. == Dependencies == There are no other changes / package updates this Change depends on; or which this change impacts. == Contingency Plan == * Contingency mechanism: Re-add device-mapper-multipath to the livecd if the dropping of it causes problems. * Blocks release? No == Documentation == This change does not require any documentation. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Cleanup GNOME Hidden Boot Menu Integration - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration == Summary == GNOME integrates with Fedora's [[Changes/HiddenGrubMenu|hidden boot menu feature]] to signal to the bootloader that boot was successful and to request the menu to be shown the next boot when "Boot Options" is selected in the Shutdown/Reboot dialog. Currently Fedora carries downstream patches for this, which directly call the Fedora specific grub2-set-bootflag helper. The goal of this change is to replace these downstream patches with a clean bootloader agnostic solution which can be submitted upstream. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == GNOME has 2 integration points with the [[Changes/HiddenGrubMenu|hidden boot menu feature]]: # Requesting the menu to be shown the next boot when "Boot Options" is selected in the Shutdown/Reboot dialog. # Signalling the bootloader that the boot was successful. To replace our downstream patches for 1. we can use the new(ish) systemd DBUS API used by "systemctl reboot --boot-loader-menu=60". This currently only works with sd-boot, but systemd has hooks to allow integration with other bootloaders, see the [https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU env. variable documentation]. So we can support this in grub2 with some relatively simply changes and then replace our downstream patches for this with new patches using the systemd DBUS API for this. Replacing our downstream patches for 2. with an upstreamable bootloader agnostic solution is somewhat involved. systemd has its [https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ Automatic Boot Assessment] feature, which is somewhat similar in that it to deals with boot success detection, but its behavior on failure is different (auto fallback to an older kernel) and it is a sd-boot specific feature. Still we can use some parts of this. The boot-complete.target and the concept of having a systemd-bless-boot.service which Requires that target to be reached before it runs. So replacing out downstream patches for 2. will consists of 2 parts: # grub2 changes: Add a grub2-bless-boot.service which Requires boot-complete.target and which does the equivalent of "grub2-set-bootflag boot_success" when that target is reached # GNOME changes: Add a oneshot gnome-wait-for-boot-success.service to boot-complete.target, this will start a simple helper which listens on a unix socket until signalled, thus delaying the completion of boot-complete.target until it is signalled; and in the places where the downstream patches are currently directly calling "grub2-set-bootflag boot_success" signal (write a byte) this unix socket instead. Also see this [https://lists.freedesktop.org/archives/systemd-devel/2020-June/044800.html mailinglist discussion]. == Benefit to Fedora == This change will remove some technical-debt in the form of a couple of quick-and-dirty downstream patches from Fedora and will align GNOME's integration with the [[Changes/HiddenGrubMenu|hidden boot menu feature]] with our upstream first policy. == Scope == * Proposal owners: Create the necessary changes ASAP and submit these to Fedora's [https://github.com/rhboot/grub2/ grub2] and [https://gitlab.gnome.org/GNOME/ GNOME] upstreams. * Other developers: The bootloader team needs to do a new grub2 build with the changes added and the desktop team needs to add the GNOME changes to the GNOME packages. I will coordinate this with both teams. * Release engineering: [https://pagure.io/releng/issue/9557 #9557] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This change does not impact upgrades, the interface between the OS and grub2 still goes through the same unmodified grubenv settings. The only changes are in how we make the grubenv changes and all parts involved in that will be updated together. == How To Test == # Tests ## Install Fedora Workstation in a fresh vm or select reclaim diskspace -> delete all in the installer (do a single os install). ## Boot the system the grub menu should NOT show ## Login, wait 2 minutes then presss "CTRL + ALT + F6" followed by "CTRL + ALT + DEL" to do a reboot from the text-console without going through the GNOME reboot dialog. The grub menu should NOT show on the new boot. ## Reboot from the GNOME reboot dialog inside gdm. The grub menu should NOT show on the new boot. ## Open the GNOME reboot dialog, then press alt to change the "Reboot" button into "Boot Options" and click the "Boot Options" button (while keeping alt pressed). You should now get the grub menu, with a countdown of 60 seconds. ## Boot the system and then press "CTRL + ALT + F6" followed by "CTRL + ALT + DEL" to do a reboot from the text-console without logging in, this counts as a failed boot, so
NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
== Summary ==
Change the default settings plugin of NetworkManager so that new
profiles will be created in keyfile format instead of ifcfg-rh format.
== Owner ==
* Name: [[User:Thaller| Thomas Haller]]
* Email:
== Detailed Description ==
NetworkManager supports settings plugins to persist connection
profiles to disk. There is the native ''keyfile'' format and the
Fedora/RHEL specific ''ifcfg-rh'' format originally from initscripts.
The keyfile plugin is always enabled in NetworkManager and can handle
any supported type of profile. It stores profiles under
`/{etc,usr/lib,run}/NetworkManager/system-connections` and is
documented in
[https://developer.gnome.org/NetworkManager/stable/nm-settings-keyfile.html
nm-settings-keyfile manual]. The ifcfg-rh format is in part compatible
with the network-scripts package from initscripts, however both
network-scripts and NetworkManager define their own extensions
([https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html
[1]]). Since network-scripts and NetworkManager are fundamentally
different, the same ifcfg file is not treated exactly the same by both
systems. In the past, having the ifcfg-rh format made it easier for
users familiar with initscripts to migrate to/from NetworkManager.
The settings plugins are configurable in
[https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
NetworkManager.conf] via the `"main.plugins"` option. Multiple plugins
can be configured and on Fedora 32 and older, the compile time default
for the option is `"ifcfg-rh,keyfile"`. This means, that when
NetworkManager stores a new profile to disk, it will first try to
persist it in ifcfg-rh format before falling back to keyfile format,
if the ifcfg-rh plugin doesn't support the profile type. When reading
profiles from disk, NetworkManager will read and expose profiles from
both settings plugins and when modifying an existing profile, it will
update the existing file and preserve the settings plugin.
This Change is about to change the default for `"main.plugins"` from
`"ifcfg-rh,keyfile"` to `"keyfile,ifcfg-rh"`.
== Feedback ==
This was brought up on the NetworkManager mailing list
([https://mail.gnome.org/archives/networkmanager-list/2020-May/msg2.html
[1]]]).
Fedora CoreOS doesn't use ifcfg-rh files at all, only keyfile. Also,
RHEL CoreOS uses the `"main.plugins=ifcfg-rh,keyfile"` configuration
too. For CoreOS this of course is simpler, because they don't deal
with existing user configurations and tools that would break during
upgrade.
== Benefit to Fedora ==
The long term goal of NetworkManager is to move away from ifcfg-rh
files. That will be difficult as it affects existing installations and
will require migration of existing configurations. This change is only
a first step and affects how NetworkManager by default persists new
profiles to disk.
The ifcfg-rh format arguably has an uglier syntax and, contrary to
keyfile, does not support all profile types. Also, keyfile plugin is
available on every NetworkManager installation because that is the
only plugin that supports all profiles. Having multiple plugins and
file formats is confusing. By now, initscripts' `network-script`
package is deprecated in Fedora and upstream wants to move away from
that format in the long term. Also maintaining multiple settings
plugins is a maintainance burden, and in the past there were subtle
bugs where ifcfg-rh did not implement all settings (e.g.
[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10754
CVE-2020-10754]). On other Linux distributions NetworkManager uses the
keyfile format by default. It is a general goal that NetworkManager
works similar on all distributions.
== Scope ==
* Proposal owners: The default settings for `"main.plugins"` can
already be selected at compile time. This only requires building the
package with a different default
([https://src.fedoraproject.org/rpms/NetworkManager/blob/a06b38bcbe8f9a38badab4f37e8c6fae240428b7/f/NetworkManager.spec#_759
[3]]).
* Other developers: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This affects most users, unless they explicitly set the option in
NetworkManager.conf configuration. The biggest effect of this change
is that new profiles will now preferably be persisted in keyfile
format. This changes behavior for users who expect NetworkManager to
write ifcfg-rh files, or who have scripts or tools that expect that.
What will still work is that existing ifcfg files are loaded after
upgrade. Users who only use the D-Bus API (via one of the client
applications like nmcli or the GUI), shouldn't notice the difference.
As before, users still can explicitly configure the settings plugins
in NetworkManager.conf. This only affects the default, but it affects
existing
List of long term FTBFS packages to be retired in August
Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 33 approximately one week before branching (August 2020). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Note that some listed packages are orphaned and hence may be retired even sooner. The packages in rawhide were not successfully built at least since Fedora 31. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers Latest build OpenCoarrays jussilehtolaFedora 30 gpscorrelate tillFedora 30 js-jquery-jqplot xavierb Fedora 30 js-jquery1 nodejs-sig, patches, vondruch Fedora 30 js-jquery2 vondruchFedora 30 js-sizzle nodejs-sig, patches, vondruch Fedora 30 nodejs-path-type jsmith, nodejs-sig Fedora 30 nodejs-temp-write jsmith Fedora 30 nodejs-unique-stream jsmith, nodejs-sig Fedora 30 ocaml-pxp orphan Fedora 30 ocaml-ulex orphan Fedora 30 orpie bowlofeggs, jaredwallaceFedora 30 rubygem-ruby-hmac humaton, mmorsi Fedora 30 xvarstar orphan Fedora 30 The following packages require above mentioned packages: Depending on: gpscorrelate (1) foxtrotgps (maintained by: bubeck) foxtrotgps-1.2.2-5.fc33.x86_64 requires gpscorrelate = 1.6.1-27.fc30 Depending on: js-jquery-jqplot (1) sympa (maintained by: xavierb) sympa-6.2.56-1.fc33.src requires js-jquery-jqplot = 1.0.9-3.fc30 sympa-6.2.56-1.fc33.x86_64 requires js-jquery-jqplot = 1.0.9-3.fc30 Depending on: js-jquery1 (69) R-profvis (maintained by: qulogic) R-profvis-0.3.6-3.fc33.src requires js-jquery1 = 1.12.4-7.fc30 R-profvis-0.3.6-3.fc33.x86_64 requires js-jquery1 = 1.12.4-7.fc30 R-rmarkdown (maintained by: qulogic) R-rmarkdown-2.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 R-rmarkdown-2.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30 copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup) copr-frontend-1.166-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 ghc-pretty-show (maintained by: mathstuf) ghc-pretty-show-1.9.5-3.fc32.x86_64 requires js-jquery1 = 1.12.4-7.fc30 mkdocs (maintained by: cheeselee) mkdocs-1.1.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 mkdocs-1.1.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30 python-XStatic-jQuery (maintained by: mrunge, openstack-sig, rdopiera) python3-XStatic-jQuery-3.4.1.0-2.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 python-sphinx-bootstrap-theme (maintained by: besser82, sic) python3-sphinx-bootstrap-theme-0.8.0-3.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30 rubygem-apipie-rails (maintained by: jaruga, ruby-packagers-sig, vondruch) rubygem-apipie-rails-0.5.5-6.fc32.noarch requires js-jquery1 = 1.12.4-7.fc30 R-BiocFileCache (maintained by: spot) R-BiocFileCache-1.12.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-DBItest (maintained by: qulogic) R-DBItest-1.7.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-V8 (maintained by: qulogic) R-V8-3.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-broom (maintained by: qulogic) R-broom-0.5.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-cellranger (maintained by: qulogic) R-cellranger-1.1.0-6.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-clipr (maintained by: qulogic) R-clipr-0.7.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-dbplyr (maintained by: qulogic) R-dbplyr-1.4.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-devtools (maintained by: qulogic) R-devtools-2.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-diffobj (maintained by: qulogic) R-diffobj-0.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33 R-dplyr (maintained by: qulogic)
java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")
Current stats from my testing samples: 408 failing 263 passing That is huge improvement. Thank you all. I'm now running last rebuild n copr, and in week or two an mass rebuild will be taken in koji. There was an discussion what the border will be, when to force this change, or when to step away. 50% of passed? 80%? But afaik no metric is valid here, because - sorry to say it - there is no longer any javastack... Since f29, about 1000 java packages died or were orphaned. I was removing packages where upstream is dead and are orphaned (so no chance to make them reliable working with jdk11), and I found that wildfly, jenkins, jboss, half of maven plugins, elastic search, apach-emina, infinispan, cassandra, hibernate All are dead. What is javastack for now (no blame or evil in that)? So maybe the system jdk11 can be used as just last death-blow to java stack, rethink it, and stat rebuilding on pretty fresh field J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
