Created attachment 1876741 [details] Generic prompt although hostname and user are set. Description of problem: Normally, the Terminal shows the username and the hostname at the terminal prompt. The Terminal on the latest RC 1.3 does not do it and shows the generic prompt instead (see attachment). This is probably not caused by the underlying settings, because the tty terminal shows that info correctly (see attachment). Version-Release number of selected component (if applicable): gnome-terminal-3.44.0-1.fc36.x86_64 How reproducible: Always Steps to Reproduce: 1. Start the terminal and watch the prompt. Actual results: Terminal does not show hostname and username. Expected results: Terminal should show that info as it normally does. Additional info: See attachments.
Created attachment 1876742 [details] Tty prompt with correct info.
Was RC 1.2 fine? If so, then this regression must have been introduced by a freeze exception issue, right? We have seen this before actually. I remember Owen trying to debug it on Matrix recently.
Freshly installed F36 beta RC1.4 (https://download.fedoraproject.org/pub/fedora/linux/releases/test/36_Beta/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-36_Beta-1.4.iso), and I can't reproduce that bug. GNOME Terminal 3.44.0 using VTE 0.68.0 +BIDI +GNUTLS +ICU +SYSTEMD gnome-terminal-3.44.0-1.fc36.x86_64 see attached screenshot
Created attachment 1876768 [details] Everything looking fine with gnome-terminal from RC1.4, updated system
Created attachment 1876769 [details] RC 1.3 iso F36 workstation screencapture Can't reproduce that bug here.
What is the history of this system? Was it a fresh install? I debugged a similar bug with a user, and it turned out that the problem was /etc/skel was not properly copied into the users home directory, so ~/.bashrc and friends did not have the correct contents. I wasn't able to find out anything useful in the logs that I was able to obtain from the user. If that can be verified to be the case here, then it's definitely not a gnome-terminal bug.
I understand this is a race condition that does not *usually* occur. Pretty unfortunate, though. Especially since it cannot be fixed post-install: the affected user is permanently missing everything from /etc/skel and is likely to not notice and fix it properly even if the user manages to manually fix PS1. Suspicious components: accountsservice (calls usermod), shadow-utils (implements usermod), selinux-policy (always a good suspect whenever something goes wrong)
Lukas, is this Fedora-Workstation-Live-x86_64-36-1.3.iso that you simply installed, accepting defaults, and started? Or did you do anything else? Some unusual configuration in the installer, some tweaking after install? In my installations of Fedora-Workstation-Live-x86_64-36-1.3.iso I don't see this problem. Please attach your ~/.bashrc, and if it is missing, then also `ls -a ~` output. Also please try to create a new user, if it happens there as well.
Yeah, I remember that case Owen is talking about too. It happened a week or two back, IIRC, so nothing to do with recent changes. Looks like just a race that rarely gets 'lost', somewhere.
Wait, but there's something odd about that theory here: Lukas said it works fine at a tty. That shouldn't be the case if the problem is that /etc/skel wasn't correctly applied. Lukas, when you say it works at a tty - is that with the same user account, on the same install? i.e. if you login to GNOME with that user you get a bad terminal prompt, but if you log in to a tty as the same user, on the same install, you get a working one?
Fedora-KDE-Live-x86_64-36-1.3.iso is doing fine, no bug, at konsole.
Fedora-Workstation-Live-x86_64-36-1.3.iso clean install, all defaults at install time, and only one change (enable 3rd party repo) when in G-I-S. [chris@localhost-live ~]$ ls -la total 12 drwx------. 1 chris chris 236 May 3 14:19 . drwxr-xr-x. 1 root root 10 May 3 14:19 .. -rw-r--r--. 1 chris chris 18 Jan 19 17:12 .bash_logout -rw-r--r--. 1 chris chris 141 Jan 19 17:12 .bash_profile -rw-r--r--. 1 chris chris 492 Jan 19 17:12 .bashrc I'm curious what .bashrc looks like for folks having this problem? I'm pretty sure this time stamp behavior is consistent with rsync -t (anaconda uses rsync -pogAXtlHrDx), where atime, ctime, otime match the creation date of the file on the installation destination file system; but the original file's (?) mtime is transferred. So is this file present and does it have this time stamp behavior and what are its contents? I'm not seeing where this file comes from though... stat .bashrc File: .bashrc Size: 492 Blocks: 8 IO Block: 4096 regular file Device: 0,41 Inode: 263 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ chris) Gid: ( 1000/ chris) Context: unconfined_u:object_r:user_home_t:s0 Access: 2022-05-03 14:19:41.082363241 -0400 Modify: 2022-01-19 17:12:23.000000000 -0500 Change: 2022-05-03 14:19:38.794175496 -0400 Birth: 2022-05-03 14:19:38.794175496 -0400
It comes from /etc/skel . All the dotfiles in /etc/skel are - or should be - copied into the new user's home directory when one is created. In the IRC case Owen mentioned, somehow this had not happened, and the user was missing all of those things - not just .bashrc but also .bash_profile, the equivalents for ksh and zsh, and the empty .mozilla tree (I do not know why we ship that, actually?) I'm not convinced this is the same thing that happened to Lukas, though, if a tty works as expected.
OK yeah, `diff /etc/skel/.bashrc ~/.bashrc` returns nothing for me, as expected.
(In reply to Adam Williamson from comment #13) > I'm not convinced this is the same thing that happened to Lukas, though, if > a tty works as expected. Good catch. Hopefully Lukas did not destroy this VM and can still reproduce the issue. Hopefully....
I performed 6 default Workstation installs (Final RC1.3) in a VM and I haven't seen this problem. It seems that this time Lukas will be the local expert for race conditions...
Hello, sorry about the delay but I got involved with another RC. This happened on a fresh install of the RC 1.3. I can confirm that the problem was only visible in the GUI, while the tty on the same system did not have that issue. Unfortunately, I did indeed discard the VM, because I have done like ten new installations today and it totally slipped my mind that I should have kept it. Sorry about that. I am trying to reproduce the issues on RC1.4, the VM might have been created from the Everything netinst and not the usual WS Live. I will report back as soon as the installation finishes.
So far, I only performed a single installation of Workstation using netinst, I created a standard user in the installer, and this problem didn't occur.
I re-ran the installation, but this time created just the root account in installer, and a standard user later in gnome-initial-setup, and this bug still didn't occur.
I installed rc 1.4 (two vms for workstation and two kde spin) and so far didn't see this bug at any of them.
Just tested Fedora-Workstation-Live-x86_64-36-1.5.iso and Fedora-KDE-Live-x86_64-36-1.5.iso, live-sessions and installed at VMs. And in all cases cannot reproduce this bug.
(In reply to Adam Williamson from comment #10) > Wait, but there's something odd about that theory here: Lukas said it works > fine at a tty. That shouldn't be the case if the problem is that /etc/skel > wasn't correctly applied. The same effect occurs if you start /bin/sh instead of /bin/bash. The terminal *could* be configured to run /bin/sh, but I don't see how that could happen without conscious configuration.
riiiight, I knew there was another way to trigger this but couldn't remember what it was. We hit that in openQA occasionally.
(to be clear: we don't hit this specific bug, we hit odd codepaths for user creation which are known to result in a user whose shell is sh not bash)
At least for Workstation Live image, /home is completely empty following an installation. So, some kind of race in between g-i-s, PAM, and whatever other tools and libraries support that stack?
(In reply to Chris Murphy from comment #25) > At least for Workstation Live image, /home is completely empty following an > installation. So, some kind of race in between g-i-s, PAM, and whatever > other tools and libraries support that stack? Does this mean you just reproduced this issue?
-12 in https://pagure.io/fedora-qa/blocker-review/issue/806 , and rejected at today's go/no-go meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting/2022-05-05/f36-final-go_no_go-meeting.2022-05-05-17.00.html . Marking rejected.
(In reply to Kamil Páral from comment #26) > Does this mean you just reproduced this issue? I haven't reproduced it. I'm just emphasizing it can't be an installer or installation environment issue, it must be something happening (or not happening) in the first boot of the installation.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. 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 '36'. 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. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 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.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.