The anaconda environment uses tmux. Here is an early anaconda crash before tmux 2.2 landed: https://openqa.fedoraproject.org/tests/13043/modules/_boot_to_anaconda/steps/8 here is the same crash after 2.2 landed: https://openqa.fedoraproject.org/tests/14367/modules/_boot_to_anaconda/steps/7 It seems that with tmux 2.2, any time anaconda crashes early, instead of the error showing up on the console somehow, we just see a generic tmux error. This makes debugging errors harder - especially openQA ones as we have to reproduce the test manually and poke around in the environment to find the error.
Where can I find /usr/share/anaconda/tmux.conf without digging too deep into anaconda internals?
I think it's: https://github.com/rhinstaller/anaconda/blob/master/data/tmux.conf
For some further background on how anaconda uses tmux: boot.iso is created with anaconda.target as the default target, which runs anaconda.service, which is Type=forking and executes "tmux -u -f /usr/share/anaconda/tmux.conf start", and the tmux.conf has the detach-client command at the end. anaconda-tmux is activated once tty1 is setup. That one is Type=idle and runs "/usr/bin/tmux -u attach -t anaconda". The idea had been to start the tmux server and session in the console-less anaconda.service and then attach to it in the console service, but now it leaves us with a busted window saying "/usr/share/anaconda/tmux.conf:20: no current client", where line 20 is the detach-client. Commenting out the detach-client seems to make things work.
or rather, as wwoods noted on IRC, it makes the broken cases we happen to have run across so far work again, but there are lots of exciting known unknowns: are there are other broken cases? If so, does that fix them all? Are there other cases which are broken by removing the detach-client? Apparently there's a ton of potential corner cases here with serial line installs and weird s390 stuff and all the rest of it, and that line was presumably put in there for a reason.
(In reply to David Shea from comment #3) > anaconda-tmux is activated once tty1 is setup. That one is > Type=idle and runs "/usr/bin/tmux -u attach -t anaconda". So this last line is supposed to attach to the existing session and then actually start anaconda? Or is it supposed to attach to the existing session named 'anaconda'? If so - where is anaconda actually started then?
In tmux.conf, there is a line: > new-session -s anaconda -n main "anaconda" that starts the session named "anaconda", with a window named "main", and in that window it runs the program "anaconda". After that it creates some more windows with a shell and some logs and stuff. The attach directive in anaconda-tmux@<console>.service attaches to this session named "anaconda" that is already running.
tmux-2.2-1.fc24 has been pushed to the Fedora 24 stable repository. David, how is this going to be fixed in F24? I can see the following anaconda commit for the master branch, but I guess we will need it for f24-branch too https://github.com/rhinstaller/anaconda/pull/608 This is currently blocking installation on s390x, since user cannot select between vnc/text mode installation.
Cherry-picked to f24-branch
python-blivet-1.20.2-1.fc24 anaconda-24.13.5-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1a7f1df025
anaconda-24.13.5-1.fc24, python-blivet-1.20.2-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1a7f1df025
anaconda-24.13.5-1.fc24, python-blivet-1.20.2-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.