Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix weirdness with boot sequence/console server #45

Closed
perlun opened this issue Aug 23, 2015 · 2 comments
Closed

Fix weirdness with boot sequence/console server #45

perlun opened this issue Aug 23, 2015 · 2 comments
Assignees
Labels
Milestone

Comments

@perlun
Copy link
Contributor

perlun commented Aug 23, 2015

Updated suggestion

  • When opening a console, the process opening it should provide a flag saying "should we switch to this console?"
  • Cluido should set this flag to true
  • All other programs should set this flag to false

This would solve the problem with cludio appearing at e.g. console 3, which happens at the moment. To get chaos to a usable state in Docker also, running in curses mode, this would be quite important to get fixed.

Original text

There is something fishy going on: if I place cluido very late in the GRUB config, its console doesn't seem to become "active" upon bootup. Instead, I seem to be getting the log console (and both the kernel and system logs are completely empty btw).

I want to be able to place cluido last and have its console "take over" the active console on startup. Also, there seems to be some random weirdness when switching consoles - sometimes, I cannot see what I type in cluido (the cursor is moving but no output is written except for the "banner screen" which is shown on startup).

Ideally, some of this would be taken care of by the boot server but it seems to be (for the time being) not finished yet. Some critical parts of it seem missing...

@perlun perlun self-assigned this Aug 23, 2015
@perlun perlun changed the title Fix weirdness with boot sequence Fix weirdness with boot sequence/console server Sep 5, 2015
@perlun
Copy link
Contributor Author

perlun commented Feb 14, 2016

This happens from time to time (the random weirdness when switching consoles). Very annoying.

@perlun perlun added this to the 0.1.0 milestone Feb 15, 2016
@perlun perlun added the bug label Apr 8, 2016
@perlun perlun removed this from the 0.1.0 milestone Oct 4, 2017
@perlun perlun added this to the 1.0.0 milestone Dec 25, 2017
perlun added a commit that referenced this issue Dec 25, 2017
This is related to, but does not really fix, #45.

It was needed to resolve #102.
perlun added a commit that referenced this issue Nov 10, 2018
This flag is to be used by cludio, and by cluido only, to ensure that
the cluido console is always made visible when created; other servers
have a lower pirority. This is important to give the user a decent
experience when running e.g. the chaos Docker container, using a
pre-compiled chaos .iso image etc.

Closes #45; there are still some issues with the kernel log console (as
being created by the log server) not being visible, but I will create a
separate issue for that before merging this one.
perlun added a commit that referenced this issue Nov 10, 2018
This flag is to be used by cludio, and by cluido only, to ensure that
the cluido console is always made visible when created; other servers
have a lower pirority. This is important to give the user a decent
experience when running e.g. the chaos Docker container, using a
pre-compiled chaos .iso image etc.

Closes #45; there are still some issues with the kernel log console (as
being created by the log server) not being visible, but I will create a
separate issue for that before merging this one.
perlun added a commit that referenced this issue Nov 10, 2018
This flag is to be used by cludio, and by cluido only, to ensure that
the cluido console is always made visible when created; other servers
have a lower pirority. This is important to give the user a decent
experience when running e.g. the chaos Docker container, using a
pre-compiled chaos .iso image etc.

Closes #45; there are still some issues with the kernel log console (as
being created by the log server) not being visible, but I will create a
separate issue for that before merging this one.
perlun added a commit that referenced this issue Nov 10, 2018
This flag is to be used by cludio, and by cluido only, to ensure that
the cluido console is always made visible when created; other servers
have a lower pirority. This is important to give the user a decent
experience when running e.g. the chaos Docker container, using a
pre-compiled chaos .iso image etc.

Closes #45; there are still some issues with the kernel log console (as
being created by the log server) not being visible, but I will create a
separate issue for that before merging this one.
perlun added a commit that referenced this issue Nov 10, 2018
This flag is to be used by cludio, and by cluido only, to ensure that
the cluido console is always made visible when created; other servers
have a lower pirority. This is important to give the user a decent
experience when running e.g. the chaos Docker container, using a
pre-compiled chaos .iso image etc.

Closes #45; there are still some issues with the kernel log console (as
being created by the log server) not being visible, but I will create a
separate issue for that before merging this one.
perlun added a commit that referenced this issue Nov 10, 2018
This flag is to be used by cluido, and by cluido only, to ensure that
the cluido console is always made visible when created; other servers
have a lower priority. This is important to give the user a decent
experience when running e.g. the chaos Docker container, using a
pre-compiled chaos .iso image etc.

Closes #45; there are still some issues with the kernel log console (as
being created by the log server) not being visible, but I will create a
separate issue for that before merging this one.
@perlun
Copy link
Contributor Author

perlun commented Nov 12, 2018

Fixed now, but filed #139 about an issue still remaining with the consoles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant