Description of problem: After updating to Fedora 33, the hostname settings from dhcp are ignored. The shell prompt is displayed as: [ellert@localhost ~]$ The hostname and hostnamectl commands return: [ellert@localhost ~]$ hostname localhost.localdomain [ellert@localhost ~]$ hostnamectl Static hostname: localhost.localdomain Transient hostname: fedora And the hostname is displayed as "fedora" in the terminal window title. A recompiled systemd with the -Dfallback-hostname=fedora line removed from the specfile works as expected. The shell prompt is displayed as: [ellert@ellert ~]$ The hostname and hostnamectl commands return: [ellert@ellert ~]$ hostname ellert.physics.uu.se [ellert@ellert ~]$ hostnamectl Static hostname: localhost.localdomain Transient hostname: ellert.physics.uu.se And the hostname is displayed correctly in the terminal window title. I.e. everything works as expected. Version-Release number of selected component (if applicable): systemd-246.6-3.fc33.x86_64 systemd-libs-246.6-3.fc33.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure the machine to get hostname from dhcp Actual results: hostname from dhcp is ignored Expected results: hostname from dhcp is accepted Additional info:
What does "Configure the machine to get hostname from dhcp" mean? E.g. you didn't even say if you are using NetworkManager, systemd-networkd, initscripts-network, or something else. How did you configure the system to use the dhcp hostname (it's not the default, afaik)? What are the contents of /etc/hostname?
> What does "Configure the machine to get hostname from dhcp" mean? If you do not set a static hostname manually, NetworkManager will try to set the transient hostname to a name advertised by the DHCP server (if you have configured the server to advertise a name) or by performing a reverse DNS lookup. See "hostname-mode" in "man 5 NetworkManager.conf". > How did you configure the system to use the dhcp hostname (it's not the default, afaik)? Nothing. It was somehow the default for at least f31 and f32 (Workstation). > What are the contents of /etc/hostname? localhost.localdomain as initially set by the installer.
Whether dhcp provides a hostname or not is a server side setting, no special configuration has been needed to accept the provided hostname before. But after updating to Fedora 33 it stopped working. If systemd is recompiled without the -Dfallback-hostname=fedora setting, it starts working again on Fedora 33. So either this change in the fallback overrides the hostname provided by dhcp, or it interferes with the logic used by some other component that sets the hostname to the name provided by dhcp.
OK, I think I understand what is going on. The systemd docs say that things will happen is "a static hostname is not set", but actually the code tries to be smart and ignores the static hostname (sometimes) when it is "localhost" or "localhost.localdomain". Such "smarts" always bite us on the butt in the end. Some similar logic is implemented in NM apparently, and is broken in the same way. I guess the fix is to make the code (in both places) actually properly check that the hostname is transient instead of trying to figure out if it is based on patterns.
systemd-hostname will (in v248) export the origin of the hostname [1]: static, transient, or fallback. The logic to determine how to set the hostname has alos been simplified: the static hostname in /etc/hostname is used if present, and the transient hostname is used otherwise, and the fallback hostname if neither of the other two [2]. Anaconda will not configure /etc/localhost with "localhost.localdomain", so the logic in hostnamed is not blocked by a fake static hostname. [1] https://github.com/systemd/systemd/commit/60e4fb4240 [2] https://github.com/systemd/systemd/commit/d39079fcaa [3] https://github.com/rhinstaller/anaconda/pull/3044 With this preparation, we expose all information that is necessary for NetworkManager or other network management software to make appropriate decisions. That is still work in progress though.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Seeing this in F34 as well.
For now, I added: [main] ... dhcp=dhclient hostname-mode=dhcp and: cat >>/etc/dhcp/dhclient.d/hostname.sh <<EOF #!/bin/bash PROG="$(basename "$0")" hostname_config() { domain_portion="$(echo "${new_host_name}" | cut -s -d. -f2-)" [ -z "${domain_portion}" ] || return [ -n "${new_domain_name}" ] || return logger -p daemon.info -t "$PROG" "Setting domainname ${new_domain_name}" domainname "${new_domain_name}" } hostname_restore() { # nothing to do : } EOF chmod 755 /etc/dhcp/dhclient.d/hostname.sh But the script shouldn't be necessary.
Given that this bug is over a year old, and reproducible, what's the chance of getting it fixed?
I tried using the cloud image (Fedora-Cloud-Base-35-1.2.x86_64.raw.xz) and the iso (Fedora-Server-netinst-x86_64-35-1.2.iso), booting in libvirt. The hostname is injected with dnsmasq, adding in the libvirt network definition: <ip address='10.224.122.1' netmask='255.255.255.0'> <dhcp> <range start='10.224.122.11' end='10.224.122.100'/> <host mac='52:54:00:b7:3b:10' name='fedo72' ip='10.224.122.11'/> </dhcp> </ip> in both cases the name is properly picked up nov. 07 10:45:10 fedo72 NetworkManager[933]: <info> [1636278310.7557] policy: set-hostname: set hostname to 'fedo72' (from DHCPv4) nov. 07 10:45:10 fedo72 systemd-hostnamed[949]: Hostname set to <fedo72> (transient) nov. 07 10:45:10 fedo72 systemd-resolved[732]: System hostname changed to 'fedo72'. $ hostname fedo72 I can't reproduce.
All the work described in comment #5 has been merged and is present in F34. So at least from systemd side it is "done". François reports in comment #10 that the issue does not reproduce in F35, It'd be nice to also check in F34, and if it reproduces in a clean install, reassign the issue to dhcp.
Could this be related to https://bugzilla.redhat.com/show_bug.cgi?id=2021363?
(In reply to François Rigault from comment #10) > I tried using the cloud image (Fedora-Cloud-Base-35-1.2.x86_64.raw.xz) and > the iso (Fedora-Server-netinst-x86_64-35-1.2.iso), booting in libvirt. > > The hostname is injected with dnsmasq, adding in the libvirt network > definition: > > [snip] > > I can't reproduce. Given that the hostname is "dynamic" (as is everything in DHCP, hence the name), why would it go into a static definition such as the libvirt's XML definition of the domain?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #11) > [snip] > It'd be nice to also check in F34, and if it reproduces in a clean install, > reassign the issue to dhcp. This is 100% reproducible and I'm happy to collect whatever information is required to root-cause this.
Right now it's not clear where the bug is. As mentioned in comment #11, please reassign the issue to whatever component you think should pick up the dhcp hostname.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Apparently this was fixed in F35, but not F34, for unknown reasons.
*** Bug 1888447 has been marked as a duplicate of this bug. ***