WORKED AROUND - Cannot login to LXDE after recent update

luser · 2021-11-07 22:07:28

[This post edited to clarify that it's LXDE that isn't working. I don't think LXDM is involved, since lxdm.service is disabled.]

Hi, I update this system about once a week. Unfortunately, about a week ago, the update resulted in my not being able to log into tty1. I'm using LXDE, and normally, the system boots and provides me with a login prompt on tty1. I log in and it loads the LXDE by calling startlxde when .xinitrc runs. Now when I try it, I get the following message and it reverts to the login prompt, asking me to log in again.

 /etc/X11/xinit/xserverrc: line 2: /usr/bin/X : Success

I can log in on tty2, but, of course, that doesn't load LXDE. I've looked at the information about LXDE and LXDM, and I haven't seen anything obviously wrong to my eyes, and besides, everything was working perfectly till after the recent update. I have tried updating again after logging into tty2, but that hasn't helped.

This system is a laptop with an external monitor used almost exclusively with the laptop closed, running in a docking station. I disabled the lxdm.service to avoid running the GUI log in screen, because it often required opening the laptop lid to type into the login screen. I've had my current setup running that way for perhaps two years, but after applying the recent update and rebooting, I could no longer log in.

My .xinitrc is:

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then

    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then

    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

#twm &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
#exec xterm -geometry 80x66+0+0 -name login
numlockx &&
exec startlxde

My .bash_profile is:

 
#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

if [ -z "${DISPLAY}" ] && [ "${XDG_VTNR}" -eq 1 ]; then
  exec startx
fi

My .bashrc is:

#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ll='ls -l  --color=auto'
alias sudo='sudo -v; sudo '
PS1='[\u@\h \W]\$ '

And /bin/startlxde is as follows:

#!/bin/sh

if [ -z "$XDG_CONFIG_HOME" ]; then
        export XDG_CONFIG_HOME="$HOME/.config"
fi

if [ -z "$XDG_DATA_HOME" ]; then
        export XDG_DATA_HOME="$HOME/.local/share"
fi

# Ensure the existance of openbox config file
OPENBOX_CONF_DIR="$XDG_CONFIG_HOME/openbox"
if [ ! -f "$OPENBOX_CONF_DIR/lxde-rc.xml" ]; then
        mkdir -p "$OPENBOX_CONF_DIR"
        cp /etc/xdg/openbox/LXDE/rc.xml "$OPENBOX_CONF_DIR/lxde-rc.xml"
fi

# Ensure the existance of the 'Desktop' folder
if [ -e "$XDG_CONFIG_HOME/user-dirs.dirs" ]; then
        . "$XDG_CONFIG_HOME/user-dirs.dirs"
else
        XDG_DESKTOP_DIR="$HOME/Desktop"
fi
mkdir -p "$XDG_DESKTOP_DIR"

# Ensure the existance of the user applications folder
USER_APPS_DIR="$XDG_DATA_HOME/applications"
mkdir -p "$USER_APPS_DIR"

# Clean up after GDM (GDM sets the number of desktops to one)
xprop -root -remove _NET_NUMBER_OF_DESKTOPS -remove _NET_DESKTOP_NAMES -remove _NET_CURRENT_DESKTOP 2> /dev/null

# Enable GTK+2 integration for OpenOffice.org, if available.
export SAL_USE_VCLPLUGIN=gtk

# Launch DBus if needed
if test -z "$DBUS_SESSION_BUS_ADDRESS"; then
        if which dbus-launch >/dev/null; then
                eval "$(dbus-launch --sh-syntax --exit-with-session)"
        fi
else
        if which dbus-update-activation-environment >/dev/null; then
                dbus-update-activation-environment --systemd --all
        fi
fi

export XDG_MENU_PREFIX="lxde-"
export XDG_CURRENT_DESKTOP="LXDE"

# Start the LXDE session
exec /usr/bin/lxsession -s LXDE -e LXDE

A recent boot log run after failing to log in on tty1, then successfully logging in on tty2 produced this result:

http://codepad.org/GBPk9bnC

When I try to run startlxde after logging into tty2, it complains about not being able to open the display if I try to run xrandr, but perhaps that's normal, under the circumstances.

Anyone who thinks they can help, please chime in. I don't know what to try next.

Last edited by luser (2021-11-10 19:38:35)

seth · 2021-11-08 06:58:17

numlockx &&

Remove the extra "&" - what *could* happen is that numlockx returns false and since it's logically chained by "&&", "exec startlxde" isn't executed and xinit terminates at this point.

For further investigation:
1. don't "exec" startx in your xinitrc so the shell doesn't get replaced
2. next to removing the extra "&" replace "exec startxlxde" w/ "xterm" (provided you have that installed)
3. if this allows you to get an X11 server + xterm, try to run startlxde from there.

Edit: the posted journal is capped, try "sudo journalctl -b | curl -F 'f:1=<-' ix.io"

Last edited by seth (2021-11-08 06:59:19)

luser · 2021-11-09 03:49:08

Thanks for the help, Seth.
I tried to follow your instructions. I couldn't do it to the letter, because the call to startx isn't in my .xinitrc. It's in my .bash_profile, so I commented out the last 3 lines of that to remove the call to startx. I also replaced the && to a single & in my .xinitrc and found that I was able to log in. I had only changed the ampersand, and kept the call to startlxde. startlxde did not run, but I was logged in. I tried running startlxde, but it failed with the following output:

 **Message: 09:04:23.768: main.vala:102: Session is LXDE
**Message: 09:04:23.770: main.vala:103: DE  is LXDE
(lxsession: 456): Gtk-WARNING **: 09:04:23.773 cannot open display

Thanks for showing me how to use ix.io to easily pastebin something. Here's the link to my boot log:
http://ix.io/3Eq7

Next I changed .xinitrc to change "exec startlxde" to "exec xterm" and rebooted.

I was able to log in, but startlxde gave me the same output output as before, concluding with the Gtk WARNING about not being able to open the display.

I tried running xterm from the terminal and received the following output:

xterm: Xt error: Can't open display:
xterm: DISPLAY is not set

I may be a noob, but I'm starting to think that there's a problem with the display. (duh)

After looking around, I believe this complaint results from a failure to set the environmental variable called DISPLAY. This is supposed to be done automatically, but I'm not quite sure where. I believe it's supposed to be in whatever starts the X server, and I'm wondering if that means it should be done in my .bash_profile where startx is called, or perhaps startlxde is responsible?

I'm betting you can point me in the right direction, but I'll be looking for a solution in the meantime.

Last edited by luser (2021-11-09 04:38:33)

luser · 2021-11-09 05:06:06

It's still not precisely clear to me exactly which script or program is responsible for setting the DISPLAY environmental variable, but I note that my /bin/startx uses a lower case variable named display.

In case there could be something wrong with it, here's a link to startx: http://ix.io/3EsV

Last edited by luser (2021-11-09 05:08:23)

seth · 2021-11-09 07:53:35

so I commented out the last 3 lines of that to remove the call to startx

While not expressed verbatim, that was the idea ;-)

Next I changed .xinitrc to change "exec startlxde" to "exec xterm" and rebooted.
I was able to log in, but startlxde

If you're running startlxde from the console login, you're doing it wrong.
The plan was to
- "exec xterm" in the xinitrc and
- from the console run "startx",
- hopefully receive an X11 server w/ an xterm and
- in that xterm run startlxde

You're receiving the DISPLAY errors because there's no running X11 server (and apparently startlxde doesn't conditionally start one either)

luser · 2021-11-09 13:38:32

OK. I've modified my .xinitrc and .bash_profile as follows:

.xinitrc

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then

    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then

    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

#twm &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login
#numlockx &
#exec startlxde

.bash_profile

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

#if [ -z "${DISPLAY}" ] && [ "${XDG_VTNR}" -eq 1 ]; then
#  exec startx
#fi

When I ran "startx" from the console, I received the following output:

/home/luserz/.xserverrc: line 2: /usr/bin/Xorg: Success
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

I also tried .xinitrc with twm:

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then

    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then

    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

twm &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login
#numlockx &
#exec startlxde

However, the output was the same.

So, what should I try next, I wonder. . .

seth · 2021-11-09 13:40:20

Post /home/luserz/.xserverrc

luser · 2021-11-09 15:25:53

#!/bin/sh
exec /usr/bin/X -nolisten tcp "$@"
Actually, when the problem originated, I didn't have a /home/luserz/.xserverrc. There was only /etc/X11/xinit/xserverrc. I created the user file, because I was getting an error with the file in /etc/X11/xinit, so I thought it might help. Now that I'm running startx from the command line, I get the same error messages whether I'm running with .xserverrc or it's removed and the one under /etc/X11/xinit is used.

errors:

xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

.xserverrc

#!/bin/sh
exec /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR

/etc/X11/xinit/xserverrc

#!/bin/sh
exec /usr/bin/X -nolisten tcp "$@"

seth · 2021-11-09 15:31:14

Xorg log?
Should be ~/.local/share/xorg/Xorg.0.log

luser · 2021-11-09 15:42:59

I note that ~/.local/share/xorg/Xorg.0.log has a modification date from November 3.

http://ix.io/3Evz

Last edited by luser (2021-11-09 15:50:54)

seth · 2021-11-09 15:44:55

There's also some garbage at the tail of the file.
Try to run "Xorg", no xinit/startx/nothing, and look out for error messages.

luser · 2021-11-09 15:58:20

Running Xorg immediately after logging in produces no error messages.

I don't know how the garbage got to be at the end of the log file. The original file ends as shown minus the garbage.

Last edited by luser (2021-11-10 14:50:56)

seth · 2021-11-09 16:00:44

And the server starts?
Can you "xinit" instead of "startx"?

luser · 2021-11-09 16:09:38

I don't think the X server starts when Xorg runs. DISPLAY is still not set.

xinit produces the same results as startx, whether I:
$ xinit
or I
$ xinit -- :1

results:

xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

edited for clarity

Last edited by luser (2021-11-10 15:07:29)

luser · 2021-11-10 19:37:16

OK, this was taking way too long to resolve, so I used a Clonezilla backup from September 11, 2021. Ater restoring from the backup, the only change I made was to change the && in my .xinitrc to a & after the call to numlockx before the call to exec startlxde. I SERIOUSLY doubt that this change made any difference. Changing it before the restore didn't help, and the && must have been that way for a year or more before I had any problem.

After booting and starting LXDE, I ran a full system update with Pacman, and I was able to reboot and load LXDE successfully. I don't store any important data on this installation, because it's thumb drive based, and used and maintained for the purpose of fixing any issues that might arise on the OS on the hard drive. Restoring from a two month old backup didn't really cause me to lose anything important, except for a few pacman updates, which turned out to be easily fixed with one update.

Since this was never really solved, but it was worked around, I'll mark it that way. I still have no idea why I couldn't load LXDE when the problem first appeared.

edited to explain what was done in more detail

Last edited by luser (2021-11-10 20:54:45)

seth · 2021-11-10 22:01:22

I'm actually very certain that the stray ampersand wasn't the cause - it's just wrong and had the very real potential to be the cause, so we had to rule that out and you did so yesterday.

I ran a full system update with Pacman, and I was able to reboot and load LXDE successfully. I don't store any important data on this installation, because it's thumb drive based

Since the update didn't re-trigger the original problem and because of "thumb drive based" you might have ended up w/ a broken sector on the drive and the attempt to run Xorg (just reading the binary or a dependent library) lead to stalling IO errors.
Unfortunately we won't figure that, but you want to be cautious about the drive because usb keys are not meant for perpetual writes as will occur eg. by the journal.

luser · 2021-11-11 02:32:18

I always test that I'm fully able to load the operating system and desktop environment after updating Arch, because I've been working with removable media since 5.25" floppy disks were the norm. I don't really trust them. Now, thumb drives are a whole lot better than floppies were in every way, but foolproof, they are not. Particularly in this case, because it's a two thumb drive system, doubling the potential for failure.

My original install was on one thumb drive, but the laptop is old and limited to USB 2 hardware internally. I have a USB 3 capable Renesas cardbus card in it to get USB 3, but it requires firmware and drivers to be loaded by the OS, so it's not possible to boot from it. After seeing how infuriatingly slow it was to work with Gparted running on a single USB 2 thumb drive, I installed Arch on two thumb drives with the USB 3 capable thumb drive in the Renesas card as / and the other thumb drive in a built-in port mounted at /boot which contains the necessary drivers and firmware, so / can be mounted. This actually gave much better performance overall, and I've been using the same two drives for a year or two, maybe more. However, I don't use them much; mostly they're used once a week to make sure they're up to date. They're there to be used for real if there's a hardware or software problem with my hard drive, or if I decide to get a bigger hard drive and need to mess with partitions or other disk utilities.

Because I'm aware of their frailty, I back them up with Clonezilla, usually more frequently than once every two months.This episode is a reminder to do it more frequently.

If you're disappointed that we didn't get to the bottom of the problem, I can restore the backup I made BEFORE I restored the prior backup that fixed things, and we can continue trying to fix it. {;>) I did that in case the restore followed by the update induced the same or worse problems. At least I could get back where I was.

Last edited by luser (2021-11-11 02:59:37)

seth · 2021-11-11 07:37:34

I've been working with removable media since 5.25" floppy disks

Ftr, those OS were loaded into RAM and then you could just remove the floppy (and insert the game floppy, what was the entire purpose of booting the OS itfp :-P )
It's not comparable to the situation of a "modern" OS.

If you're disappointed

Nope. Your system, your situation.
I just wanted to point out a possible cause of the previous problem and issue a caution about abusing flash drives as pseudo-SSDs

Arch Linux

#1 2021-11-07 22:07:28

WORKED AROUND - Cannot login to LXDE after recent update

#2 2021-11-08 06:58:17

Re: WORKED AROUND - Cannot login to LXDE after recent update

#3 2021-11-09 03:49:08

Re: WORKED AROUND - Cannot login to LXDE after recent update

#4 2021-11-09 05:06:06

Re: WORKED AROUND - Cannot login to LXDE after recent update

#5 2021-11-09 07:53:35

Re: WORKED AROUND - Cannot login to LXDE after recent update

#6 2021-11-09 13:38:32

Re: WORKED AROUND - Cannot login to LXDE after recent update

#7 2021-11-09 13:40:20

Re: WORKED AROUND - Cannot login to LXDE after recent update

#8 2021-11-09 15:25:53

Re: WORKED AROUND - Cannot login to LXDE after recent update

#9 2021-11-09 15:31:14

Re: WORKED AROUND - Cannot login to LXDE after recent update

#10 2021-11-09 15:42:59

Re: WORKED AROUND - Cannot login to LXDE after recent update

#11 2021-11-09 15:44:55

Re: WORKED AROUND - Cannot login to LXDE after recent update

#12 2021-11-09 15:58:20

Re: WORKED AROUND - Cannot login to LXDE after recent update

#13 2021-11-09 16:00:44

Re: WORKED AROUND - Cannot login to LXDE after recent update

#14 2021-11-09 16:09:38

Re: WORKED AROUND - Cannot login to LXDE after recent update

#15 2021-11-10 19:37:16

Re: WORKED AROUND - Cannot login to LXDE after recent update

#16 2021-11-10 22:01:22

Re: WORKED AROUND - Cannot login to LXDE after recent update

#17 2021-11-11 02:32:18

Re: WORKED AROUND - Cannot login to LXDE after recent update

#18 2021-11-11 07:37:34

Re: WORKED AROUND - Cannot login to LXDE after recent update

Board footer