1

I was not able to put Solus Linux in place because - as it needed a first big upgrade after installation - this first upgrade crashed and the system would stuck and not boot after that. This happened several times, twice in Solus Budgie and once in Gnome. The problem is also mentioned here.

I have fixed it as said here: not only I have avoided installing anything before this first full upgrade, but I have run the full upgrade command in from a TUI login session (i.e. a virtual terminal login session) instead of from a terminal emulator running in a(n X) GUI login session.

Everything went fine in this way.

As other systems use full upgrades - like between versions (Ubuntu, Mint), I thought I should ask about this, as such upgrades involve risks that maybe could be avoided in this way.

Is this procedure safer? Why?

If yes: why is it not more largely recommended?


UPDATE after comments, answers and edits by others than OP:

I was asked What do you call tty and how it differs from terminal? - but that is what I am trying to know, what I am asking here. I don't know what tty1 etc essentially is, I have just used it sometimes (Ctrl-Shift-F1, F2 etc) to kill a process or to log out forcibly when the desktop was stuck in Linux because I have read about all those steps when needed.

There is no point in underlying the similarities between tty or what's its name and terminal: my point is that during upgrade in normal terminal the aforementioned system used to crash completely. As stated at the link I posted, "the XOrg system would crush". I guess tty1 (I mean the out-of-desktop, out-of-Xorg CLI environment accessed with Ctrl-Alt-F1 ...F6) puts you out of the context that entailed the problem, and thus avoids the latter.

That is at least one big difference between the two (tty and terminal) ways of upgrading, isn't it? - I didn't have problems usually with terminal upgrades, but sometimes I did, and most certainly with the case described above; and now I wander whether that could be avoided through tty in a more general manner - more general than the specific problem that was avoided.


Basically what happened is that I fixed a problem and I want to know what I did - and why. I want to learn something out of it. - (The same case with this other question.)


TUI (what I had initially called "tty") is accessible with Ctrl+Alt+some F key. That may vary between machines. On my present one it's Ctrl+Alt+F2 to F6, while Ctrl+Alt+F1 is to go back to desktop.

closed as primarily opinion-based by Rui F Ribeiro, Romeo Ninov, Thomas Dickey, umläute, steve Apr 20 '18 at 19:21

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Your question isn't clear. What do you call tty and how it differs from terminal? If you have problems with nvidia you still should be able to disable KMS and boot into bare console (single user mode or target) with out of X. – user996142 Apr 19 '18 at 17:25
  • Virtual console (tty1 etc, the ones you get with ctrl-alt-F1) vs. under X and a terminal emulator? Third option would be over SSH, but I'm not sure if you meant you're physically at the machine, or over the network. – ilkkachu Apr 19 '18 at 17:26
  • PS: Please read Please read linusakesson.net/programming/tty to understand what is tty and what is terminal. Then, rephrase your question – user996142 Apr 19 '18 at 17:34
  • 1
    @cipricus By using a VT (Ctrl+Alt+F1) for system updates, you're reducing the risk of breaking the system since GUIs crash more often than VTs. Note that the same robustness can be achieved by running the upgrade with screen or tmux (e.g., from xterm) since those processes will survive a GUI crash (or SSH disconnection) as well. – dsstorefile1 Apr 19 '18 at 21:53
  • 1
    It means that the upgrade will continue in the background and the admin can reconnect to tmux or screen at their leisure to check on the upgrade progress. – dsstorefile1 Apr 20 '18 at 7:59
0

By using a VT (Ctrl+Alt+F1) for system updates, you're reducing the risk of breaking the system since GUIs crash more often than VTs.

Note that the same robustness can be achieved by running the upgrade with screen or tmux since those processes will survive a GUI crash or SSH disconnection as well. After the GUI crashes or the SSH connection breaks, the upgrade will continue running in the background and the admin can reconnect to tmux or screen at their leisure to check on the upgrade progress.

1

For any reason, if ssh becomes unavailable, your box/server becomes remotely bricked. Debian clearly recommends to avoid doing dist-upgrade while connected via ssh, for this very reason. If you attempt anyway, debian sets up a backup ssh server on a different port, for installation recovery purposes.

So, as far as debian is concerned, this is clearly the recommended procedure.

1

There is one important detail: in some cases Xorg may crash or restart (e.g. Xorg or video driver updates). In this case GUI updater may be terminated (it is what you really don't want).

So answer is yes, it is more safe to use console outside of Xorg.

0

The last several times I've upgraded one of my Debian boxes I've done so from an xterm (not counting my VPS as I don't have X on that) without any problems. I don't know Solus, but if the upgrade procedure and packages are well-made I can't see why it would cause problems.

  • I am sure that it does not matter which terminal emulator (ssh client, virtual console, xterm or even real terminal) you are using to upgrade your system. Btw, you can ssh with X11 forwarding to your VPS, run xterm there and it will be displayed on your screen while running in VPS, so tehnically your do not need X server on VPS to run xterm there) – user996142 Apr 19 '18 at 17:29
  • my question is not about the fact that in most cases there are no problems with various ways of upgrading but that one specific problem with upgrade in a GUI terminal was fixed when the upgrade was done outside that (in "tty"). I didn't have problems usually with terminal upgrades, but sometimes I did, and now I wander whether that could be avoided through tty. – user32012 Apr 19 '18 at 20:25