So now that we have tmux handling consoles for us, the rules for console stuff have changed a little. Basically, anything in anaconda that deals directly with VTs or /dev/tty* should be considered deprecated.
tmux has a fairly robust command set that will let you manipulate its state (and thus what's shown on the user's console). For example, here are some common tasks and possible replacements:
Old and busted: Sending log output to tty{3,4,5...} New hotness: Send log output to log files; tail log in tmux window
Old: Run debugger in a new VT (e.g. tty6) New: Run debugger in a new window: `tmux new-window -n pdb "[debugger-command]"`
Old: Activate (switch to) debugger on tty6 New: Not needed (new-window automatically switches)
Old: Switch back to tty1 using isys.vtActivate New: Switch back to first window: `tmux select-window -t anaconda:1`
(Note that when you're specifying a window by hand, you can probably get away with just `tmux selectw -t 1`, but in scripts inside anaconda we probably want to specify the full [session-name]:[index])
For more details, consult the man page. Here's a link to it on the web: http://www.openbsd.org/cgi-bin/man.cgi?query=tmux&sektion=1
-w
Old and busted: Sending log output to tty{3,4,5...} New hotness: Send log output to log files; tail log in tmux window
This is probably really easy but pretty tedious. We reference tty5 all over the place, but at least they're easy to remove. Probably just modifying our logging code and iutil.py is enough as a start.
Old: Run debugger in a new VT (e.g. tty6) New: Run debugger in a new window: `tmux new-window -n pdb "[debugger-command]"`
Old: Activate (switch to) debugger on tty6 New: Not needed (new-window automatically switches)
Old: Switch back to tty1 using isys.vtActivate New: Switch back to first window: `tmux select-window -t anaconda:1`
Will these work given that we're running the graphical installer?
- Chris
I have basically the same concern that Chris has.
On Wed, 2012-08-15 at 10:57 -0400, Will Woods wrote:
So now that we have tmux handling consoles for us, the rules for console stuff have changed a little. Basically, anything in anaconda that deals directly with VTs or /dev/tty* should be considered deprecated.
Correct me if I'm wrong, but from what I've seen during testing, Anaconda's GUI is running on a tty6 outside of tmux. So in the GUI installation the basic initial step before everything else would be switching to tty1 where tmux runs. This is, however, not possible because Anaconda doesn't "own" tty1 and is not in the same process group as tmux (not sure if that'd help).
tmux has a fairly robust command set that will let you manipulate its state (and thus what's shown on the user's console). For example, here are some common tasks and possible replacements:
Old and busted: Sending log output to tty{3,4,5...} New hotness: Send log output to log files; tail log in tmux window
Old: Run debugger in a new VT (e.g. tty6) New: Run debugger in a new window: `tmux new-window -n pdb "[debugger-command]"`
I'm affraid this is not applicable to our case because we need to pass stack to pdb as we are running the post-mortem session (might be possible to dump it somewhere and load it again in pdb), but again python-meh's GUI (which runs the debugger) runs on a tty6 and thus would need to switch to tty1 before anything else.
Old: Activate (switch to) debugger on tty6 New: Not needed (new-window automatically switches)
Old: Switch back to tty1 using isys.vtActivate New: Switch back to first window: `tmux select-window -t anaconda:1`
Again, not applicable for the GUI running on the tty6, not anaconda:6.
On Thu, 2012-08-16 at 10:05 +0200, Vratislav Podzimek wrote:
I have basically the same concern that Chris has.
On Wed, 2012-08-15 at 10:57 -0400, Will Woods wrote:
So now that we have tmux handling consoles for us, the rules for console stuff have changed a little. Basically, anything in anaconda that deals directly with VTs or /dev/tty* should be considered deprecated.
Correct me if I'm wrong, but from what I've seen during testing, Anaconda's GUI is running on a tty6 outside of tmux. So in the GUI installation the basic initial step before everything else would be switching to tty1 where tmux runs. This is, however, not possible because Anaconda doesn't "own" tty1 and is not in the same process group as tmux (not sure if that'd help).
Ah, jeez. Good point. Surprised I forgot that X is actually on a different VT.
But here's the thing: if anaconda (which doesn't own tty1) can run X, and X can switch to tty6, then (in theory) anaconda should be able to make it switch back, right?
So - what's the actual error message/return code from the ioctl?
As a bonus - here's some more detail about how the tmux setup works, for reference.
Early in system startup, anaconda-generator does two things:
1) find the actual console device 2) set up anaconda-shell@.service on tty2 + the first virt console found of (hvc[01], xvc0, hvsi[012])
Normal system startup continues after that, leading up to anaconda.target.
Once we've reached anaconda.target, anaconda.service starts tmux. tmux starts anaconda, a shell, and the log windows, as configured in tmux.conf:
+---------------+ | tmux (server) |------- +---------------+ \ / | \ \ +----------+ +-------+ +-----+ +------+ | anaconda | | shell | | log | | etc. | .... +----------+ +-------+ +-----+ +------+
After that, anaconda-tmux@.service runs a tmux client on the actual console device, e.g. tty1:
+------+ +---------------+ +---------------+ | tty1 |<--| tmux (client) |-->| tmux (server) |---... +------+ +---------------+ +---------------+ / | \ ... ... ...
So, anaconda runs with a pty as its controlling terminal rather than a real tty; the tmux client has the tty.
-w
On Thu, 2012-08-16 at 15:45 -0400, Will Woods wrote:
But here's the thing: if anaconda (which doesn't own tty1) can run X, and X can switch to tty6, then (in theory) anaconda should be able to make it switch back, right?
What happens when starting X is a mystery to me, but switching to new tty is usually not a problem.
So - what's the actual error message/return code from the ioctl?
errno is 22: "Invalid argument". Which seems like problem with the file descriptor (0) used in the ioctl call -- I think it happens because:
"So, anaconda runs with a pty as its controlling terminal rather than a real tty; the tmux client has the tty."
which means descriptor 0 is not the tty1 anymore. However, I've tried to use the 'chvt' command and it works. So we could:
a) move vtActivate to iutil.py and implement it as a chvt call b) try to patch isys.vtActivate to use a new file descriptor (to tty1)
Since I'm not sure b) would work, I'm for a). Opinions?
As a bonus - here's some more detail about how the tmux setup works, for reference.
Early in system startup, anaconda-generator does two things:
- find the actual console device
- set up anaconda-shell@.service on tty2 + the first virt console found of (hvc[01], xvc0, hvsi[012])
Normal system startup continues after that, leading up to anaconda.target.
Once we've reached anaconda.target, anaconda.service starts tmux. tmux starts anaconda, a shell, and the log windows, as configured in tmux.conf:
+---------------+ | tmux (server) |------- +---------------+ \ / | \ \
+----------+ +-------+ +-----+ +------+ | anaconda | | shell | | log | | etc. | .... +----------+ +-------+ +-----+ +------+
After that, anaconda-tmux@.service runs a tmux client on the actual console device, e.g. tty1:
+------+ +---------------+ +---------------+ | tty1 |<--| tmux (client) |-->| tmux (server) |---... +------+ +---------------+ +---------------+ / | \ ... ... ...
So, anaconda runs with a pty as its controlling terminal rather than a real tty; the tmux client has the tty.
Thanks for the explanation. I believe it would be good to place it somewhere on our FedoraWiki pages together with a list of basic tmux commands/hotkeys.
On Mon, Aug 20, 2012 at 01:56:15PM +0200, Vratislav Podzimek wrote:
a) move vtActivate to iutil.py and implement it as a chvt call b) try to patch isys.vtActivate to use a new file descriptor (to tty1)
Since I'm not sure b) would work, I'm for a). Opinions?
I agree, I'm all for removing code and using methods that are more likely to keep working in the future.
Hi,
did anybody think about the reason we did simpler no-curses text mode in the first place? It seems to me that tmux just violated all that...
I understand what we gained by using it, but will it work on dumb consoles or s390?
If I missed the discussion because of my PTO, then consider this email as just ranting :)
Martin
----- Original Message -----
So now that we have tmux handling consoles for us, the rules for console stuff have changed a little. Basically, anything in anaconda that deals directly with VTs or /dev/tty* should be considered deprecated.
tmux has a fairly robust command set that will let you manipulate its state (and thus what's shown on the user's console). For example, here are some common tasks and possible replacements:
Old and busted: Sending log output to tty{3,4,5...} New hotness: Send log output to log files; tail log in tmux window
Old: Run debugger in a new VT (e.g. tty6) New: Run debugger in a new window: `tmux new-window -n pdb "[debugger-command]"`
Old: Activate (switch to) debugger on tty6 New: Not needed (new-window automatically switches)
Old: Switch back to tty1 using isys.vtActivate New: Switch back to first window: `tmux select-window -t anaconda:1`
(Note that when you're specifying a window by hand, you can probably get away with just `tmux selectw -t 1`, but in scripts inside anaconda we probably want to specify the full [session-name]:[index])
For more details, consult the man page. Here's a link to it on the web: http://www.openbsd.org/cgi-bin/man.cgi?query=tmux&sektion=1
-w
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.stg.fedoraproject.org