BetaBlocker +1

DNS resolution is... important.

BetaBlocker +1

My understanding is DNS still works, just not the way it was intended to in a post systemd-resolved by default world, and unfortunately we don't have a "inadavertantly reverted a previously accepted feature" criteria. Since nothing is really broken, I don't see how this can be a blocker, at least through this process.

BetaBlocker -1

My understanding is DNS still works, just not the way it was intended to in a post systemd-resolved by default world, and unfortunately we don't have a "inadavertantly reverted a previously accepted feature" criteria. Since nothing is really broken, I don't see how this can be a blocker, at least through this process.

For Fedora 35 I have added the following script to kickstart %post section because otherwise DNS doesn't work (hostname resolution failed, hostname not found).

    if [[ ! -h /etc/resolv.conf ]] ; then
        # Link setzen
        ln -fsv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
    fi

Now I have run a test kickstart installation with Fedora 36 Rawhide 20220205.n.1 nightly compose. I have not run the script above

After the reboot file /etc/resolve.conf is a plain text file created (or updated?) by NetworkManager (# Generated by NetworkManager).
NetworkManager.service and systemd-resolved.service are both running.

So some commands and libaries and system calls use /etc/resolve.conf and some use systemd-resolved to do DNS name and ip resolution. This may lead to different results / answers depending on the configuration and the selected dns servers. It is not a consistent configuration.

But it is true: host and dig for example works resolving dns names, but both use the first dns server listed in /etc/resolve.conf .

If I remove file /etc/resolve.conf and reboot the system, then /etc/resolve.conf is a symbolic link to ../run/systemd/resolve/stub-resolv.conf .

But this symbolic link is created both with systemd-resolved.service and systemd-resolved.service not running (disabled). In the last case the symbolic link refers to a nonexistent file! Something (*) creates the symbolic link if the file doesn't exist even if systemd-resolved will not be started!

(*) Something is tmpfiles:

/usr/lib/tmpfiles.d/systemd-resolve.conf

But if systemd-resolved is not running, the symbolic link shoud not exists, at least it should not refer to a nonexistent file. In this case NetworkManager should create /etc/resolve.conf as in earlier Fedora versions.

It seams that if the file /etc/resolve.conf exists either as plain file or symbolic link, it isn't changed. If the file doesn't exist, a symbolic link to the stub file is created.

But this is not a consistent and useful behavior. It may be right to not block the beta release, but I think this problem should not go to the final Fedora 36 release.

My understanding is DNS still works, just not the way it was intended to in a post systemd-resolved by default world, and unfortunately we don't have a "inadavertantly reverted a previously accepted feature" criteria. Since nothing is really broken, I don't see how this can be a blocker, at least through this process.

For Fedora 35 I have added the following script to kickstart %post section because otherwise DNS doesn't work (hostname resolution failed, hostname not found).

[Snip]

So I just tested the 20220205.n.1 Rawhide compose, aarch64 minimal and server x86_64, both of which exhibit the issue, but I still can't find anything I can point to as broken in such a way a blocker criteria applies? I admit I'm probably lacking creativity, but at the same time, this has apparently been broken since F35 and people aren't shouting about it from the rooftops.

I do however agree 100% it is in fact broken, and should absolutely be fixed before F36 release.

But this is not a consistent and useful behavior. It may be right to not block the beta release, but I think this problem should not go to the final Fedora 36 release.

Agreed 100%, the current behavior is absolutely wrong. But I don't see a matching basic or beta criteria to mark it as a blocker. If someone points at one I'll gladly change my vote. In my opinion this should be handled via the "Bugs designated as blockers by FESCo" clause of the automatic blockers criteria, and we should visit adding a "reversion of previously completed changes breaking expected functionality" criterion in the future.

Agreed. Not blocking for Beta.

BetaBlocker -1

Please note that I reported bug 2022816 last November about this problem in Fedora 35.
And a similar problem was described in bug 1921057 in Janary 2021.

I didn't shouting about it from the rooftops because I have found a workaround using a script in kickstart configuration files which works for me, but it is a workaround, not a solution.

Please note that I reported bug 2022816 last November about this problem in Fedora 35.
And a similar problem was described in bug 1921057 in Janary 2021.

I didn't shouting about it from the rooftops because I have found a workaround using a script in kickstart configuration files which works for me, but it is a workaround, not a solution.

Sorry if that came off as an attack. I meant it as "there aren't all these things we have broken that obviously make it a blocker" not "nobody has even reported it". I should have been clear.

I didn't feel it as an attack. All is fine. I just wanted to notice that this problem was already reported some time ago for Fedora 35 and it should not continue to be in Fedora 36.

For Fedora 35 I have added the following script to kickstart %post section because otherwise DNS doesn't work (hostname resolution failed, hostname not found).
...snip...

Hi @imsedgar, thanks for debugging, but please provide that information in the bugzilla to the developers, and let's keep this ticket related just to the blocker discussion, thanks.

Hi @imsedgar, thanks for debugging, but please provide that information in the bugzilla to the developers, and let's keep this ticket related just to the blocker discussion, thanks.

You are right, I already thought this while I wrote my comment, but I wanted to describe why I had voted that is should be a blocker.
Now I posted the information in the bug report.

BetaBlocker -1

It's unfortunate, but doesn't violate existing criteria.

Discussed during the 2022-02-07 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as we don't think this qualifies as a blocker under the release criteria currently, but there seems to be a strong case for FESCo to declare it a blocker as the current state is not at all how we want things to be, and this is an important area. At this time, instead of rejecting, we will file a ticket for FESCo to consider declaring it a blocker (as they are allowed to do).

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-07/f36-blocker-review.2022-02-07-17.00.txt

Discussed during the 2022-02-14 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as per last week's meeting. We don't think this is a blocker under the criteria but believe FESCo should consider it, a ticket has now been filed for FESCo: https://pagure.io/fesco/issue/2760, so we will wait for them to consider it.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-14/f36-blocker-review.2022-02-14-17.01.txt

BetaBlocker +1

Inconsistency across variants is really painful and this should not be difficult to fix.

Release F36 is no longer tracked by BlockerBugs, closing this ticket.