[SOLVED] loving Mageia But: startx doesn't start X on tty7?

[jtwdyp]

In topic https://forums.mageia.org/en/viewtopic.php?f=4&t=5427 I was asked to confine my topics to one problem at a time and to open a new one for this topic. ...

I'm a startx user. With systemd that means I set default.target to multi-user.target rather than graphical.target, and when/if I'm ready for X to start I use startx from the tty command line...

Used to be that no mater which one of the 6 tty (virtual consoles) set up by default in most distros I'm using when I initialize X with startx, X's display screen would effectively be on tty7... That is if I used <ctrl>+<alt>+<Fkey> {where <Fkey> was any one of the first six Fkeys} I would find myself in the corresponding tty, IE <ctrl>+<alt>+<F3> would put me in tty3.

Once in one of the tty, I no longer needed to use the <ctrl> key but could switch from one tty to the next with just <alt>+<Fkey>... But if I did an <alt>+<F7> I'd find myself back on the X server's screen.

I's also worthy of note that If I locked up my desktop so bad that I couldn't logout, I could (if the <ctrl>+<alt>+<Fkey> shortcut was still working) switch back to the tty from which I'd run startx and kill the X server with a ^C...

In recent months I've noticed that some distros will sometimes hijack one of the 6 tty's (or at least it's <alt>+<Fkey> shortcut leaving me with just 5 viable tty including the one busy running the startx command...

But Mageia 3 is the first distro that I've seen consistently reuse the SAME tty that I ran startx on for the X server's screen Making it impossible to switch back to it and interrupt the X server with ^C... Though nothing stops me from logging in to one of the other tty as root and using the kill command...

My question is: was this done deliberately? If so why?

For the other issue, startx is not supported anymore, as systemd is used for login session control.

Then you would have X server on tty1, by the way.

systemd may not support runlevel methods of starting with a console login... But as I mentioned above, "I set default.target to multi-user.target rather than graphical.target" This means that since the default.target symlink points to the multi-user.target, no display manager is started.

It may well be that the decision has been made to not support startx anymore. But using systemd isn't, in my opinion, a good reason...

Still you probably hit on the cause of the difference. {Though I note that with Mageia, it's only tty1 if I was using tty1 when I ran startx. If I remember right, when I ran startx on tty4, X used tty4...} However the tendency to reuse an configured tty rather than adding a virtual tty7 for X on so many recent Linux systems could well be due to the phasing in of systemd.
Before I learned to avoid display managers, Whenever I was looking at a gui login I could still log into any of the 6 configured virtual consoles including, with <crtl>+<alt>+<F1>, tty1...

Though it's true that was certainly before I'd ever heard of Mageia. So perhaps mageia always used tty1 for that{even before systemd???

But please start a separate thread for that, as advised already by isadora.

Lesson learned... new thread...

[doktor5000]

Well, i don't really get what your problem is with display managers.
I use kdm with autologin, it uses tty1 by default and i can always switch to tty2 - tty7.
Why would i want to start multi-usermode and then run X manually?

[jtwdyp]

Well, i don't really get what your problem is with display managers.

I guess it boils down to personal taste... I also detest splash screens, preferring {when I can so configure} to watch ALL the scary {to windows users} boot messages scroll by (with Mageia the "MageiaLinux-nonfb" grub selection works wonders for that... And I make a point of using text based grub menus rather than put up with any annoying background graphics distracting me from the all important textual boot selection.

I use kdm with autologin, it uses tty1 by default and i can always switch to tty2 - tty7.

Interesting. With my copy of Mageia3, it doesn't offer tty7, neither before nor after I run startx...

Why would i want to start multi-usermode and then run X manually?

Why would YOU want to? No clue, Most users today learned on gui login systems. It's what their subconscious expects. But as to why I would want to:
Again personal taste. I don't always run the gui. If I'm only going to extract some info from a text file and or read/write some email {using alpine of course } I might not even go there at all. But if I find a reason to fire up the gui, I don't want to have to login again to do it. Also I use my ~/.bash_profile to set some basic user environmental settings and Display manager initialized logins don't source it. Plus, I learned to like *nix on an actual vt100 terminal loging into a non-privileged account on a SunOS system at a {now defunct} warehouse job I used to have when I used to work for a {now defunct} telcom manufacturing company. And when I first discovered Linux could be installed to the {now defunct} 386 I used to hate running win95 on, the login was on the virtual console. And if my subconscious doesn't see something like this login text sequence:

Code: Select all

Mageia release 3 (Official) for x86_64
Kernel 3.8.13-desktop-1.mga3 on a x86_64 / tty4
Mageia2013 login: joker
Password:
Last login: Sat Jun 29 16:32:43 on tty5
aWildcard -> /home/joker
>

On a plain black screen, or if I couldn't move from login to password prompt with the enter key, it thinks I must be using windows or something so much like it that I get so uncomfortable that I no longer have any desire to use the computer.

Yes I know some of that isn't completely logical. But the fact is, I don't want ANY graphics untill I'm ready enough for them to issue a command such as startx. It's just the way I am.

[doktor5000]

I use kdm with autologin, it uses tty1 by default and i can always switch to tty2 - tty7.

Interesting. With my copy of Mageia3, it doesn't offer tty7, neither before nor after I run startx...

Sorry, wrote from memory, it's tty2 - tty6. Still more than enough, and when you want more, you can just define more gettys.

And maybe you should try to use systemd to start the X server, with

Code: Select all

systemctl start graphical.target

or define an alias for that like xstart or so.

[jtwdyp]

Interesting. With my copy of Mageia3, it doesn't offer tty7, neither before nor after I run startx...

Sorry, wrote from memory, it's tty2 - tty6. Still more than enough, and when you want more, you can just define more gettys.

True enough. This was more a case of wanting to understand what was different, rather than needing a way around it...

Though this stuff about startx not being supported makes me nervous.

And maybe you should try to use systemd to start the X server, with

Code: Select all

systemctl start graphical.target

or define an alias for that like xstart or so.

Wouldn't that simply put a "gui login" {aka display manager} screen on whatever tty it chose to use for X???

In which case, wouldn't I still need to log in to the gui, even though I was already logged in on a virtual console? And how would I get my gui login session to source the personal environmental settings in my ~/.bash_profile? Or otherwise inherit them from my user session on the virtual console? Which {not being root} would, I think, need to "su -c" or "sudo" the systemctl command. And it's my user's environmental settings I want, NOT root's...

[davidwhodgins]

I also prefer using startx, even though it isn't officially supported.
To get the gui on tty7 leaving the messages on tty1, use "startx -- vt7".
Works for now.

[davidwhodgins]

Oops. Using "startx -- vt7", while it does work for getting the gui to start on vt7, it also breaks
the permission setting, so there is no sound output.

Probably better to get used to having the gui on vt1.

[colin]

For what it's worth we deliberately try to start the X server on the current tty. This is needed to ensure that various permissions and ACLs remain in place. If we let startx pick it's own tty, then the currently logged in session will become inactive and ACLs will be removed for the user against various hardware devices. This includes things like sound cards and some USB devices etc. (ultimately everything tagged with "uaccess" tag in the udev config). Now, on a single user system, this can be worked around by adding the user to various groups, but all of this is beyond the scope of typical support.

Note that the primary problem is that we cannot register a new, graphical session from an existing session. We could, theoretically at least, totally rewrite startx to operate completely differently. In this new world order, startx would simply ask systemd to start an auto-login session for the current user. This will likely be something we will do eventually as we adopt systemd for the user sessions. In such a future the traditional startx and custom Xsession managers baked into the various DEs will become unsupported. This solution will also mean that the user will not likely see the X output anyway so if the reason to have a new TTY was to leave debug info behind, then this won't really help anyway. Of course all the debug info will ultimately end up in the user's journal anyway, kept for future inspection and available both within the started X session and anywhere else the user happens to login.

And also keep in mind that in the Mageia 4 or possible 5 timeframe, Wayland may be the default graphical system anyway, in which case "startx" definitely won't be supported.

So the only thing that is certain, is change, but overall, we hope the long term changes will be ultimately beneficial for the majority.

I should also point out that this is not new in Mageia 3. This structure has been in place since Mageia 2.

[colin]

Also for reference, the patch to startx is here: http://svnweb.mageia.org/packages/cauld ... iew=markup

I even go out of my way to print a message in the terminal about how supplying a vt number manually could affect user permissions, as Dave found out the hard way

[davidwhodgins]

Colin, just fyi. I got into the habit of using run level 3, and startx, as the monitor
I was using was an old crt that did not return any edid info, so I often had prblems
gettins X to start. By logging in to run level 3, and then using startx, if it didn't work,
it was easy to run XFdrake.

Also, when using my old i686 system I'd use "startx VirtualBox", at times, to run a guest with as little host overhead as possible.

[jtwdyp]

For what it's worth we deliberately try to start the X server on the current tty. This is needed to ensure that various permissions and ACLs remain in place. If we let startx pick it's own tty, then the currently logged in session will become inactive and ACLs will be removed for the user against various hardware devices. This includes things like sound cards and some USB devices etc. (ultimately everything tagged with "uaccess" tag in the udev config). Now, on a single user system, this can be worked around by adding the user to various groups, but all of this is beyond the scope of typical support.

Well now I know why I can't just grep /etc/group for the user account set up by a Linux installer to see what groups I might need my personal user account to join when I install an new distro anymore... And that not only answers my question about if it was done on purpose, it tells me something about why. Thanks!

Note that the primary problem is that we cannot register a new, graphical session from an existing session. We could, theoretically at least, totally rewrite startx to operate completely differently. In this new world order, startx would simply ask systemd to start an auto-login session for the current user. This will likely be something we will do eventually as we adopt systemd for the user sessions. In such a future the traditional startx and custom Xsession managers baked into the various DEs will become unsupported.

In which case will there be a way to get that auto-login session to source my ~/.bash_profile or some other ~/file in which I can put some personal environmental settings and/or get said systemd initialized auto login session to inherit environmental values from the shell on the virtual console that ran such a rewritten startx???

Here is an extract of some of the things I expect a LOGIN shell to do...

Code: Select all

# User specific environment and startup programs

# set PATH so it includes user's private bin(s) if they exist
# Note we do this here rather than in .bashrc because we don't want multiple references to these "bin"s
# to appear in the $PATH of subshells...

#This bin we want searched before the system defined path. 
if [ -d ~/bin1st ] ; then
    PATH=~/bin1st:"${PATH}"
fi
 
# this bin needs to be searched after the system defined path.
if [ -d ~/bin2nd ] ; then
    PATH="${PATH}":~/bin2nd
fi

export PATH

# Note, Thanks to /etc/udev/rules.d/99-local-disk.rules user jtwdyp retains "ownership" of personal data partitions
# Rem, for some reason, even though my data partitions are setup to let non-root "owner" mount/umount at will,
# as non-root I must refer to them by the mount point rather than by the unique LABEL... Go figure

# mount LABEL=Jimages_desk-9
mount  /home/jtwdyp/images/desk-9
# mount LABEL=J10_desk-10
mount  /home/jtwdyp/desk-10
# mount LABEL=jSTUFF_desk-11
mount  /home/jtwdyp/STUFF/desk-11


This solution will also mean that the user will not likely see the X output anyway so if the reason to have a new TTY was to leave debug info behind, then this won't really help anyway. Of course all the debug info will ultimately end up in the user's journal anyway, kept for future inspection and available both within the started X session and anywhere else the user happens to login.

Not an issue. I was mostly only curious to know why Mageia used the same tty that started X. That is untill it was explained that startx wasn't supported...

And also keep in mind that in the Mageia 4 or possible 5 timeframe, Wayland may be the default graphical system anyway, in which case "startx" definitely won't be supported.

So in which case I'm thinking I'll be stuck with some {many expletives deleted} gui login screen? :sigh: In which case, is there a ~/.somefilename where I can put my "User specific environment and startup programs" in a bash script like format, that will be sourced when I login to the gui???

So the only thing that is certain, is change, but overall, we hope the long term changes will be ultimately beneficial for the majority.

Yeah, But I never seem to be in any majority unless you count the unofficial order of stubborn idiots...

I should also point out that this is not new in Mageia 3. This structure has been in place since Mageia 2.

In my defense, I only ever heard that Mageia even existed less than two months ago. So to me, this was new...

[ghmitch]

Although I seldom use it, I have to admit that I really like startx. And, I would certainly hope that as we make our way to wayland, there will be a "startwayland" command available for those who spend 80 or 90% of their time on the console. So I hope there ends up being a happy solution to this startx issue.

[jtwdyp]

Although I seldom use it, I have to admit that I really like startx. And, I would certainly hope that as we make our way to wayland, there will be a "startwayland" command available for those who spend 80 or 90% of their time on the console. So I hope there ends up being a happy solution to this startx issue.

AMEN

Still, as much as I hope I'll still be Initializing the gui from the non-root, console command line, I'm more concerned with getting my personal environmental settings currently set in my ~/.bash_profile honored by whatever it is in the gui login that is equivalent to the login shell in bash.

I do suppose that like it or not, I could adapt to using a separate {eyuch}GUI login dialog for when I'm going to actualy use the gui. But If and when I actually have to do that, then on those occasions when I know at boot time that I'm going to use some GUI application, I'm likely to just login to the GUI and save the console login for when I'm going to actualy use it.

In which case I'd find it frustraiting if my personal data partitions {that I'm so used to initially mounting when my login shell sources my ~/.bash_profile} Aren't mounted yet...

Though I suppose, if I really had to give up on using startx, and the GUI was never ever going to inherit the environmental settings made in said ~/.bash_profile, I suppose I could duplicate those settings in my ~/.xinitrc... But will Wayland still honer an ~/.xinitrc?

I include a few things in that now, that I really want initialized at GUI start, Like where:

Code: Select all

Screen 0: minimum 8 x 8, current 1024 x 768, maximum 4096 x 4096
VGA-0 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 380mm x 300mm
   1280x1024      60.0 +   75.0 
   1280x960       60.0 
   1024x768       75.0*    70.1     60.0 
   800x600        75.0     72.2     60.3 
   640x480        75.0     72.8     59.9 
TV-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)


I include:

Code: Select all

xrandr -s 2

Which I do with xrandr because as much as I like E17, It's current screen setup module just {expletive deleted}. And the default resolution makes me squint too hard at any text (such as application menus) That I can't easily enlarge. and I don't just peg it in my xorg.conf because I sometimes like to change it on the fly.

Hmmmnnn Would a wayland based system still honor an xorg.conf and/or would xrandr still function??

Then there is this item which I never could get E17 itself to launch on startup correctly:

Code: Select all

konsole --workdir ~/mail --name F2alpine  --profile BlackGray -e alpine &

Though most of the time I can get E17's "Window Remembers" module to automatically place it on the Workspace area that corresponds to my keyboard shortcut of <ctrl>+<F2>

And because I don't have the manual dexterity to use my laptop's touchpad mouse at all until I disable all the advanced features of the touchpad with:

Code: Select all

synclient TouchpadOff=2

I include that in my ~/.xinitrc there...

[davidwhodgins]

Try renaming ~/.bash_profile to ~/.profile

That will get sourced by bash, if logging in to run level 3, or by /etc/X11/Xsession,
if logging in to run level 5.

[jtwdyp]

Try renaming ~/.bash_profile to ~/.profile
That will get sourced by bash, if logging in to run level 3, or by /etc/X11/Xsession,
if logging in to run level 5.

Are you sure of that... I peeked at Xsession, and I couldn't spot it. So I decided to let grep search ot for any strings containing "profile":

Code: Select all

 ~
UnderTree=-> grep profile /etc/X11/Xsession
. /etc/profile.d/10lang.sh
 ~
UnderTree=->


But if there is some other mechanisim involved Like maybe some other script called by Xsession in turn sources ~/,profile, would it work to just:

Code: Select all

ln -s ~/.bash_profile ~/.profile

instead of actualy renaming it?

[davidwhodgins]

Sorry, wrong file
/etc/X11/gdm/Xsession
or
/usr/share/config/kdm/ssion
or
/etc/lxdm/Xsession

[jtwdyp]

Sorry, wrong file
/etc/X11/gdm/Xsession
or
/usr/share/config/kdm/ssion
or
/etc/lxdm/Xsession

None of which exist on my system :sigh:

Code: Select all

 /
UnderTree=-> ls /etc/X11/gdm/Xsession
ls: cannot access /etc/X11/gdm/Xsession: No such file or directory
 /
UnderTree=-> ls /etc/X11/gdm
custom.conf
 /
UnderTree=-> ls /usr/share/config/kdm
ls: cannot access /usr/share/config/kdm: No such file or directory
 /
UnderTree=-> ls /etc/lxdm
ls: cannot access /etc/lxdm: No such file or directory
 /
UnderTree=->


Probably because I dislike Display Managers so much that I don't think I installed any. And if the installer did, it was never used because at some point there was a choice about starting the gui on boot which resulted in:

Code: Select all

 /
UnderTree=->
UnderTree=-> ls -l /etc/systemd/system/default.target
lrwxrwxrwx 1 root root 36 Jun 21 10:42 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target
UnderTree=-> ls -l /lib/systemd/system/runlevel3.target
lrwxrwxrwx 1 root root 17 Jun 21 07:40 /lib/systemd/system/runlevel3.target -> multi-user.target
 /etc/systemd/system
UnderTree=->


I know it had to be the installer that put this in place for me, cause I wouldn't have bothered with the runlevel3.target symlink (hadn't known it existed before) I would have symlinked default.target directly to multi-user.target...

But any way, no Display manager has ever {so far so good} had the chance to sully my system whith it's {expletive deleted} crap.

But I do hope your right that the logic of the Xsession files provided by at least three Display managers would source the user's ~/.profile... So in case startx stops working someday, and I'm forced to use a Display Manager, I've gone ahead and symlinked my ~/.bash_profile to ~/.profile Like I described in my previous post.

[jtwdyp]

I'd still like to here more about what will happen when if wayland takes over... And with there be a startx like method for those who prefer to start and end with a console session...

But since my original question about: Why X not opening on tty7 has been answered I'm marking this thread solved.