Created attachment 1714822 [details] screenshot of when this occurs Description of problem: Booted live USB with Fedora-KDE-Live-x86_64-33-20200912.n.0.iso. Went into the "Network & Host Name" spoke of Anaconda and attempted to set the host name by typing new hostname into the box and clicking "Apply". Host name is not set by doing this as verified by both the "Current host name" field in Anaconda and by opening a terminal and viewing the output of the "hostname" command. Version-Release number of selected component (if applicable): Baremetal install of Fedora-KDE-Live-x86_64-33-20200912.n.0.iso How reproducible: Every time Steps to Reproduce: 1. Install Fedora-KDE-Live-x86_64-33-20200912.n.0.iso 2. Attempt to set host name in Anaconda Actual results: Host name is not set Expected results: Host name should change when the user clicks "Apply" Additional info: See attached picture for more info.
Proposed as a Freeze Exception for 33-beta by Fedora user coremodule using the blocker tracking app because: This is a noticeable issue that cannot be fixed with an update.
Note: I tried running this in a VM and got the same results.
Can you check how it behaves with Workstation live? Can you check if the installed system gets the specified host name?
Workstation live does not let you set hostname during installation.
As Neal stated above, Anaconda doesn't let the user set the host name during installation, so I tried this on Fedora-KDE-Live-x86_64-32-1.6.iso (Fedora 32 KDE Live) and Fedora-KDE-Live-x86_64-31-1.9.iso (Fedora 31 KDE Live) in a VM: same result. This leads me to believe that this is normal behavior. I will remove the proposed Freeze Exception status from this bug, but I am going to keep the bug open, and start a discussion on whether or not this behavior could be changed. I think that, as it stands right now, having the "Current host name" field next to the "Host name" text-entry box is very confusing if one doesn't know what the expected behavior should be.
yeah, if the intended behaviour is for it only to affect the installed system, I would agree the wording is very confusing, it very much reads like it should affect the live environment.
I have tried to reproduce this bug and I cannot confirm it in its entirety. For me, the hostname could be changed in Anaconda during installation of KDE Live, however there was some confusion: 1) When I booted KDE Live, I decided to try to change the hostname in the live system, so I ran `hostnamectl set-hostname parrot` on CLI (could not find a GUI to do it) and nothing happened, the prompt was still using the old hostname. I realized, that the hostname was set correctly and it needed to restart the Konsole application to propagate on CLI. So far so good. 2) Then I tried to install KDE Live to the disk and I looked into Network & Hostname plane. It said "Current hostname: parrot" (as it had been changed by me before) and also "localhost.localdomain" in the entry field. I did not hit "Apply", just "Done" and continued the installation. This resulted in an installed KDE system with the hostname set to "localhost.localdomain". I started to suspect that WHAT WAS IN THAT ENTRY FIELD COUNTED really. 3) I restarted the installation and this time I wrote "parrot" in the entry field and hit "Apply". The "Current hostname" was not updated. I did not care about it because I wanted to prove my point (see above) and finished the installation. The hostname indeed was set to "parrot" right from the start. See the beginning of the logs to prove. ~~~ -- Logs begin at Tue 2020-09-15 11:11:21 CEST, end at Tue 2020-09-15 11:19:27 CEST. -- Sep 15 11:11:21 parrot kernel: Linux version 5.8.6-301.fc33.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 1> Sep 15 11:11:21 parrot kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.8.6-301.fc33.x86_64 root=UUID=2e4c5026-25a0-4> Sep 15 11:11:21 parrot kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Sep 15 11:11:21 parrot kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Sep 15 11:11:21 parrot kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Sep 15 11:11:21 parrot kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Sep 15 11:11:21 parrot kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Sep 15 11:11:21 parrot kernel: BIOS-provided physical RAM map: Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved Sep 15 11:11:21 parrot kernel: BIOS-e820: [mem 0x0000000100000000-0x000000017fffffff] usable ~~~ The only misbehaviour, I can confirm, is that the "Current hostname" does not update when "Apply" is hit. But the hostname can be correctly set for the newly installed system. I believe that changing the actual underlying system's hostname (as coremodule found not to be working) is NOT IMPORTANT as far as the pre-set hostname is correct in the new system, which it is.
To add something to the discussion: I believe that ... * the hostname of the system being installed should be chosen according to "Current hostname" and not the entry field itself. * after hitting Apply, the Current hostname should change to the new value (no matter what the hostname of the underlying live system is)
Another funny stuff. I also tried with Workstation Live and realized: 1) Setting up the hostname in the Live system does not influence the hostname in the installed system. 2) In the freshly installed system, the hostname according to /etc/hostname is "localhost.localdomain", but in Settings, the hostname says "Fedora" 3) Changing the value in "Settings" makes the new hostname appear in /etc/hostname, too.
In Server Boot iso, the "Apply" button updates the "Current hostname" field accordingly.
(In reply to Lukas Ruzicka from comment #8) > I believe that ... > * after hitting Apply, the Current hostname should change to the new value > (no matter what the hostname of the underlying live system is) Thanks for all this additional testing. I would agree, the "Current hostname" field should be changed when the user hits apply. (In reply to Lukas Ruzicka from comment #10) > In Server Boot iso, the "Apply" button updates the "Current hostname" field > accordingly. This is very interesting, which would mean to me that we've probably had a regression in the KDE spin for at least two cycles, since both F31 and F32 (and F33) all behave the same, but it works fine in Server.
IIRC the main reason for offering the option to change the current hostname is using Network Spoke for re-conifguration in inital setup (on installed system), for example when using pre-configured images. (In reply to Lukas Ruzicka from comment #8) > To add something to the discussion: > > I believe that ... > * the hostname of the system being installed should be chosen according to > "Current hostname" and not the entry field itself. I don't agree. We've intentionally changed this behaviour, see https://bugzilla.redhat.com/show_bug.cgi?id=1290858 and commit messages of https://github.com/rhinstaller/anaconda/commit/99872b948cb58356004a00280fc937949ad841dc https://github.com/rhinstaller/anaconda/commit/5eb30a7a24a4cc21f5595b356b119b779b298de3 https://github.com/rhinstaller/anaconda/commit/9a4bf7d9ab04e07cb10f0848a5603cb186d45695 > * after hitting Apply, the Current hostname should change to the new value > (no matter what the hostname of the underlying live system is) Yes, we should try to fix this on Live environments (seems that on installation from installer iso, et netinstall, it works as expected). (In reply to Adam Williamson from comment #6) > yeah, if the intended behaviour is for it only to affect the installed > system, I would agree the wording is very confusing, it very much reads like > it should affect the live environment. Yes the wording is not good, maybe we could just use "Target system host name" (or "Installed system host name") instead of "Host name"
Lukas, could you point me to place when I get the Live ISOs (Workstation, KDE) for reproducing ?
Radek, Here is the link for the lasted F33 KDE Live: [0] And here is the link to the latest F33 Workstation Live [1] [0] https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-33/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-33-20200917.n.0.iso [1] https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-33/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-33-20200917.n.0.iso
> I don't agree. We've intentionally changed this behaviour, see > https://bugzilla.redhat.com/show_bug.cgi?id=1290858 and commit messages of > https://github.com/rhinstaller/anaconda/commit/ > 99872b948cb58356004a00280fc937949ad841dc > https://github.com/rhinstaller/anaconda/commit/ > 5eb30a7a24a4cc21f5595b356b119b779b298de3 > https://github.com/rhinstaller/anaconda/commit/ > 9a4bf7d9ab04e07cb10f0848a5603cb186d45695 Ok, I did not know it that it has been decided not to offer this behaviour. I am glad that we both feel there should be a follow-up reaction upon hitting the Apply button. > > Yes the wording is not good, maybe we could just use "Target system host > name" (or "Installed system host name") instead of "Host name" This would work for me.
(In reply to Lukas Ruzicka from comment #9) > Another funny stuff. > > I also tried with Workstation Live and realized: > > 1) Setting up the hostname in the Live system does not influence the > hostname in the installed system. > 2) In the freshly installed system, the hostname according to /etc/hostname > is "localhost.localdomain", but in Settings, the hostname says "Fedora" > 3) Changing the value in "Settings" makes the new hostname appear in > /etc/hostname, too. I think given Network Spoke is not available in Live Workstation installer, it would be reasonable to set the installed system's hostname to the hostname set in the live system (ie copy /etc/hostname to target system). I'd create a new BZ for this.
In Live KDE spin, unlike in Live Workstation user, password and network spoke are not removed (because base Fedora product configuration is used from /etc/anaconda/product.d), the Fedora Workstation Live product has [User Interface] hidden_spokes = NetworkSpoke PasswordSpoke UserSpoke in its config file. In the Fedora Workstation Live users are configured during gnome initial setup, for networking live environment tools should be used. For KDE hiding user and root (password) spoke perhaps don't make such sense as for Gnome environment, but we could consider hiding the network spoke. As for the Host name not being applied it is turned off for live OS in Anaconda internal configuration (btw the Apply button should be grayed-out in this case - which is not). One option hre would be to enable setting hostname. This patch: https://github.com/rvykydal/anaconda/commit/40b9072dd02e9fbcdf62638bcb42bc70fcca6486 would fix the issue in F32, but not in F33 where there seems to be some other factor in play - perhaps the systemd-resolved ? Maybe we need to use hostnamed's SetStaticHostname instead of SetHostname which we are using now. Here are the logs for the patch working in F32 and not working in F33: F32: Sep 21 04:24:09 localhost-live anaconda[2359]: anaconda: ui.common: Entered spoke: NetworkSpoke Sep 21 04:24:17 localhost-live systemd-hostnamed[2414]: Changed host name to 'rv' Sep 21 04:24:17 localhost-live audit[1140]: USER_AVC pid=1140 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=unconfined_u:system_r:install_t:s0-s0:c0.c1023 tclass=dbus permissive=1 exe="/usr/bin/dbus-broker" sauid=81 hostname=? addr=? terminal=?' Sep 21 04:24:17 localhost-live org.fedoraproject.Anaconda.Modules.Network[2381]: DEBUG:anaconda.modules.network.network:Current hostname is set to rv Sep 21 04:24:17 localhost-live org.fedoraproject.Anaconda.Modules.Network[2381]: DEBUG:anaconda.modules.network.network:Current hostname changed to rv Sep 21 04:24:36 localhost-live spice-vdagentd[1660]: Error getting active session: No data available Sep 21 04:24:36 localhost-live spice-vdagentd[1660]: Error getting active session: No data available Sep 21 04:24:36 localhost-live systemd[1]: Started Getty on tty2. Sep 21 04:24:36 localhost-live audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 21 04:24:36 localhost-live spice-vdagentd[1660]: closed vdagent virtio channel Sep 21 04:24:39 localhost-live systemd[1]: Started Getty on tty6. Sep 21 04:24:39 localhost-live audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty6 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' F33: Sep 21 04:41:22 localhost-live anaconda[2341]: anaconda: ui.common: Entered spoke: NetworkSpoke Sep 21 04:41:27 localhost-live systemd-hostnamed[2405]: Changed hostname to 'rv' Sep 21 04:41:27 localhost-live audit[1173]: USER_AVC pid=1173 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=unconfined_u:system_r:install_t:s0-s0:c0.c1023 tclass=dbus permissive=1 exe="/usr/bin/dbus-broker" sauid=81 hostname=? addr=? terminal=?' Sep 21 04:41:27 localhost-live org.fedoraproject.Anaconda.Modules.Network[2367]: DEBUG:anaconda.modules.network.network:Current hostname is set to rv Sep 21 04:41:27 localhost-live org.fedoraproject.Anaconda.Modules.Network[2367]: DEBUG:anaconda.modules.network.network:Current hostname changed to localhost-live Sep 21 04:41:29 localhost-live spice-vdagentd[1724]: Error getting active session: No data available Sep 21 04:41:29 localhost-live spice-vdagentd[1724]: Error getting active session: No data available Sep 21 04:41:29 localhost-live systemd[1]: Started Getty on tty2. Sep 21 04:41:29 localhost-live audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
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.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.