[SOLVED] Intermittent issues with display manager/desktop environment

trout420 · 2023-06-09 14:57:22

I currently have set up sddm and awesome. I am working on my awesome config quite often and just got around to setting up xephyr for easy development, but have noticed a lot of weird behavior with my desktop environment when rebooting while working on my configuration.

One case involved me adding a section of code near the top of my awesome rc that caused my environment to break. A minor annoyance that is fixed by simply booting off of a usb mounting my home partition and editing my config back to a working state. The issue with this was when I accessed my config folder from the usb, all of my configuration was gone and replaced with the default. I have no idea why this happened, I recloned my config and rebooted into a working older state. From there I added some functionality that was not committed at the time, and noticed that my entire .config, and I think my entire home directory, had reverted to a previous state (for example my alacritty config had disappeared and my rofi config had reverted to default). This was not the first time this happened and occasionally in the past when I logged I would notice awesome reverting to the default, but after 1 or 2 restarts after that it would reset back to the state before reverting to default. An issue I ran into yesterday involved logging in into a blank gray screen with only a cursor. I once again booted on a usb and mounted my home, commented everything out of my ~/.xprofile except for the exec awesome, to no avail, I then created a ~/.xinitrc containing only 1 line with exec awesome, and that seemed to fix it. I then read up on what is loaded by sddm at login, and saw no mention of .xinitrc being run so I moved the file to be named "deleted" and rebooted and logged in with no problem. From there I actually deleted the file. This morning when logging in I ran into the same gray screen, so I booted yet again from a usb and recreated the .xinitrc and everything works fine now.

I am incredibly confused about this behavior, I am doubtful that the .xinitrc actually fixed the issue given that my filesystem seems to arbitrarily decide to jump forward or backward at boot. The only thing I think could be affecting this is it seems to revert more often when I use the physical reset button on my pc, so my shot in the dark is that its a dirty poweroff that forces the filesystem to load a backup? If this is remotely the case I think it might be important to note I do not have a swap partition.

My filesystem is on an nvme drive consisting of a grub partition, root partition and home partition. I have not configured sddm at all. and as far as I can tell my /etc/x11/xinit/* is all default.

Any ideas on how to debug this would be very helpful, please let me know any additional information that would be pertinent to solving this issue.
Thank you.

Last edited by trout420 (2023-06-10 14:25:07)

V1del · 2023-06-09 15:09:36

Post your fstab and in your working condition the output of

mount

. Regarding the "unexplained reversal" do you have a btrfs setup and are potentially mounting a wrong snapshot/subvol that does not contain your changes when you go via the live usb?

Also FWIW this is an incredibly round about way of fixing your GUI. You can just switch to another VT that isn't occupied by the xorg server with e.g. Ctrl+Alt+F2 fix stuff from the terminal and use Ctrl+Alt+F1 to jump pack to SDDM/run systemctl restart sddm to relaunch sddm after changing something that you'd need to restart xorg for.

Since indeed your .xinitrc should be irrelevant if you indeed boot via SDDM it's also plausible you might be running into a modesetting race, but that's all just guessing. From "broken" if you can switch a VT post

sudo journalctl -b

as well as your xorg.log https://wiki.archlinux.org/title/Xorg#General

https://wiki.archlinux.org/title/List_o … n_services

You should also not willy nilly add exec awesome to random files and I strongly suggest you remove it from .xprofile as you wouldn't need to have it there.

Last edited by V1del (2023-06-09 15:11:10)

trout420 · 2023-06-09 15:16:33

fstab:

# <file system>                                 <dir>       <type>      <options> <dump> <pass>
# /dev/sda2
UUID=0361808b-ad94-4d86-8f80-d95d3f875a89	    /         	ext4      	rw,relatime	0 1

# /dev/sda1
UUID=6FDC-A0F3      	                        /boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/sda3
UUID=850ebda0-2263-4ad3-b057-bba47db13fd8	    /home     	ext4      	rw,relatime	0 2

# /dev/sdb1
UUID=66E81D5FE81D2F35                           /mnt/hdd   ntfs3        rw,relatime 0 1

as shown in the fstab I am running ext4, so shouldn't be btrfs issue. I am aware of switching to other ttys, however once I login and get the gray screen pressing ctrl + alt +F* does nothing, as far as I can tell no keyboard input is being read.

V1del · 2023-06-09 15:24:35

After producing a failed condition and force rebooting, can you get to a terminal by adding systemd.unit=multi-user.target to the kernel parameters? And if you do, what's the output of

sudo journalctl -b-1

trout420 · 2023-06-09 15:54:17

here is the pastebin of the output of journalctl -b-1: 0x0.st/HcBG.txt

some notes about the process:
rebooted from a working state into the usb and removed my ~/.xinitrc and the exec awesome line from my .xprofile, leaving it blank
reboot and added the kernal param, got the gray screen as usual, was able to switch tty's but when logging in as my user on any tty it gave me the gray screen (despite having no ~/.xinitrc), so I logged in as root
I was only able to get back to a working desktop env after adding back the .xinitrc and the exec to xprofile.

Last edited by trout420 (2023-06-09 15:55:13)

V1del · 2023-06-09 16:09:21

Did you setup autologin into awesome/startx/xinit via bash/shellrc files? There's a bunch of stuff here that simply doesn't match up. That journal doesn't read complete and there's no startup of sddm nor any graphical component for that matter, so either you uploaded this incompletely (or not immediately after a crashing reboot involving sddm), or the system died in such an early state that nothing was written to the journal --- and if it is then you likely have disk or RAM problems.

Last edited by V1del (2023-06-09 16:12:04)

trout420 · 2023-06-09 16:24:38

I uploaded the file via this command in the link you posted:

command | curl -F 'file=@-' 0x0.st

replacing command with journalctl -b-1, is it possible it was cut off by the pager?

This was run as root logged in on the tty, but I am unsure that matters.

I do not have any sort of autologin, I boot into sddm and type my password. I double checked my system wide configs for X, bash and zsh, the only thing that seems weird that I found is a startx in my /etc/zsh/zprofile.

V1del · 2023-06-09 16:40:54

The pager shouldn't get triggered when a pipe is involved. The startx in your zprofile will be the autostart of xorg and be at least the reason for why you were unable to login to a TTY and might in further extension be the reason for your issues in the first place. Why was that there? Did you use some "easy ZSH setup" stuff like lukesmith or ohmyzsh ?

trout420 · 2023-06-09 16:55:19

That startx is probably the result of ohmyzsh then. I removed it and rebooted but still got the gray screen on all ttys as my user. I restarted twice and saw the same behavior, interestingly on the third restart I logged into a tty as root and touched my user .xinitrc and .xprofile and rebooted. After that I was able to log into a working environment.

Just to be sure I should be calling startx from my system wide xinitrc, correct?

Edit: just confirmed that the process of touching the .xinitrc and .xprofile from the root shell in tty consistently solves my issue. If I log into a gray screen, touch, and reboot it works. Just rebooting does not fix the issue without touching the files. Also after rereading the wiki page on xinit it seems to imply I should not call startx from the xinitrc, but removing it did not fix my issue.

Last edited by trout420 (2023-06-09 17:01:41)

seth · 2023-06-09 19:45:18

My filesystem is on an nvme drive consisting of a grub partition, root partition and home partition.

# /dev/sda2
UUID=0361808b-ad94-4d86-8f80-d95d3f875a89	    /         	ext4      	rw,relatime	0 1

Jun 09 11:39:46 box kernel: Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=0361808b-ad94-4d86-8f80-d95d3f875a89 rw rootfstype=ext4 loglevel=3 quiet
…
Jun 09 11:39:46 box kernel: EXT4-fs (nvme0n1p2): mounted filesystem 0361808b-ad94-4d86-8f80-d95d3f875a89 with ordered data mode. Quota mode: none.

Jun 09 11:39:46 box kernel: ata2.00: Enabling discard_zeroes_data
Jun 09 11:39:46 box kernel:  sda: sda1 sda2 sda3
Jun 09 11:39:46 box kernel: sd 1:0:0:0: [sda] supports TCG Opal
Jun 09 11:39:46 box kernel: sd 1:0:0:0: [sda] Attached SCSI disk
Jun 09 11:39:46 box kernel: ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jun 09 11:39:46 box kernel: ata5.00: ATA-11: ST4000NE001-2MA101, EN01, max UDMA/133
Jun 09 11:39:46 box kernel: ata5.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32), AA
Jun 09 11:39:46 box kernel: ata5.00: Features: NCQ-sndrcv
Jun 09 11:39:46 box kernel: ata5.00: configured for UDMA/133
Jun 09 11:39:46 box kernel: scsi 4:0:0:0: Direct-Access     ATA      ST4000NE001-2MA1 EN01 PQ: 0 ANSI: 5
Jun 09 11:39:46 box kernel: sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
Jun 09 11:39:46 box kernel: sd 4:0:0:0: [sdb] 4096-byte physical blocks
Jun 09 11:39:46 box kernel: sd 4:0:0:0: [sdb] Write Protect is off
Jun 09 11:39:46 box kernel: sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Jun 09 11:39:46 box kernel: sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 09 11:39:46 box kernel: sd 4:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes
Jun 09 11:39:46 box kernel:  sdb: sdb1 sdb2
Jun 09 11:39:46 box kernel: sd 4:0:0:0: [sdb] Attached SCSI disk

You're indeed booting from nvme, but the fstab has sda references and those partitions actually exist.

lsblk -f

The issue with this was when I accessed my config folder from the usb, all of my configuration was gone and replaced with the default. I have no idea why this happened, I recloned my config and rebooted into a working older state.

Did you mayhaps clone the partitions to the nvme?

Edit: just confirmed that the process of touching the .xinitrc and .xprofile from the root shell in tty consistently solves my issue.

I currently have set up sddm and awesome.

xinitrc is irrelevant to SDDM, please post the .xprofle

Also after rereading the wiki page on xinit it seems to imply I should not call startx from the xinitrc, but removing it did not fix my issue.

IMPLY? Post your xinitrc as well.
What garbage tutorial did you follow to install archlinux?

Also I'm pretty sure that the journal is short because you reboot w/ the power button, preventing the filesystem to be synced?

Finally: https://wiki.archlinux.org/title/Solid_ … leshooting

Edit: and everything ~/.z* (zshenv, zprofile, zshrc)

Last edited by seth (2023-06-09 19:46:42)

trout420 · 2023-06-09 21:30:14

ahh okay I think this is due to moving my install from my sda drive to my nvme drive, but never wiping the sda drive. I can see edits I made when I thought it reverted on this drive, confirming what you showed about it being mounted as my home partition. I am okay with now wiping the sda drive, but is there anything I have to do to ensure that everything points to my partitions on the nvme drive?

Did you mayhaps clone the partitions to the nvme?

to clarify I cloned the git repo of my awesome config onto the nvme partition.

My local xinitrc contains only an exec awesome, and my system xinit is the default. I made sure of this. My local xprofile is all commented out currently except for the exec awesome.

IMPLY?

The wiki page does not explicitly say not to do this so I would consider that implicit

What garbage tutorial did you follow to install archlinux?

When I first installed arch on this machine I used the archwiki, upon moving to the nvme drive I used the archinstall script. I've gone through a good couple different setups throughout my learning experience so I am sure there is a non-zero amount of garbage config from trial and error and other, no longer used setups.

seth · 2023-06-09 21:37:29

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855

By your description, your xinitrc and xprofile would both be broken/false/nonsense, you did neither comment nor show your zsh config files and to understand what's been going on and comment on what might be necesary to sanitize the partition references, please post the "lsblk -f" output *before* you "wipe" sda.

And no, the wiki doesn't explicitly state to not turn xinit into a forkbomb…

trout420 · 2023-06-09 22:07:49

sorry for paraphrasing, but as I said these files don't do much of anything currently

here is my system wide xinit: 0x0.st/HcSf.sh
I recognize that this makes reference to system wide and local xmodmap and xresources, I have no system wide or local xmodmap and xresources. my xinitrc.d contains only the 50-systemd-user.sh I can post that too if you want.

$ cat ~/.xinitrc
exec awesome

$ cat ~/.xprofile
#!/bin/sh

#export PATH=${PATH}:$HOME/.scripts
#export PATH=${PATH}:$HOME/games
#~/.screenlayout/monitor_tv_.sh &

#mouseserver &

#xcompmgr -c &

exec awesome

~/.zshrc: 0x0.st/HcSW.txt
~/.zprofile: 0x0.st/HcS4.txt
/etc/zsh/zprofile: 0x0.st/HcSJ.txt
/etc/profile: 0x0.st/iROr.txt

unfortunately I got a little excited thinking wiping my sda drive was the solution and went ahead and overwrote the drive. After writing all 0s to the drive the output of lsblk -f is as follows:

NAME        FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0                                              
sda                                                
sdb                                                
├─sdb1                                             
└─sdb2                                             
sdc                                                
├─sdc1                                             
└─sdc2                                             
nvme0n1                                            
├─nvme0n1p1                                        
├─nvme0n1p2                            4.9G    69% /
└─nvme0n1p3                             66G    81% /home

Note: not sure if it matters but this was run after mounting my nvme root and home partitions and running arch-chroot on a live usb.

seth · 2023-06-09 22:13:52

As mentioned, both, xinitrc and xprofile are broken.
xprofile isn't meant to start any kind of session and for the xinitrc see the last link below and pay attention to the note what to include at least.
The xinitrc in /etc is irrelevant as long as there's an ~/.xinitrc
(But also, xinit is irrelevant as long as you use SDDM)

lsblk doesn't work properly in the chrooted environment, so leave that and repost it (though now w/ sda gone it's of little use anyway)

And remove startx from ~/.zprofile, it has absolutely no business being there.
Edit, inb4: "because you're using SDDM" - and you would no want that unconditioanlly in any event.

Last edited by seth (2023-06-09 22:16:37)

trout420 · 2023-06-09 22:26:47

lsblk -f from live usb:

NAME        FSTYPE   FSVER            LABEL                        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs 4.0                                                                                      0   100% /run/archiso/airootfs
sda                                                                                                                    
sdb                                                                                                                    
├─sdb1                                                                                                                 
└─sdb2      ntfs                      HDD                          66E81D5FE81D2F35                                    
sdc         iso9660  Joliet Extension arcolinuxb-awesome-v23.03.01 2023-02-15-08-03-39-00                              
├─sdc1      iso9660  Joliet Extension arcolinuxb-awesome-v23.03.01 2023-02-15-08-03-39-00                     0   100% /run/archiso/bootmnt
└─sdc2      vfat     FAT16            ARCHISO_EFI                  28A4-1671                                           
nvme0n1                                                                                                                
├─nvme0n1p1 vfat     FAT32                                         6FDC-A0F3                                           
├─nvme0n1p2 ext4     1.0                                           0361808b-ad94-4d86-8f80-d95d3f875a89                
└─nvme0n1p3 ext4     1.0                                           850ebda0-2263-4ad3-b057-bba47db13fd8     66G    81% /home/liveuser/drive

I have replaced my .xinitrc to contain only the if statment regarding /etc/X11/xinit/xinitrc.d, and have removed the startx from my zprofile.

seth · 2023-06-09 22:33:50

I have replaced my .xinitrc to contain only the if statment regarding /etc/X11/xinit/xinitrc.d

That's nonsensical. Just remove ~/.xinitrc, you're not using it anyway.
Also remove the ~/.xprofile

Since there's apparently a windows installation, see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

The update the status quote (do you still see weird things w/ the filesystem where old files suddenly show up and "logging in into a blank gray screen with only a cursor"?)

trout420 · 2023-06-09 23:12:02

There is not a windows partition, the ntfs drive is only for mass storage. I first dual-booted arch in 2020 and have been windows free since 2021.
Unfortunately after wiping my sda drive the computer will not boot into arch. I get the following error on boot:

[FAILED] Failed to mount /root
[DEPEND] Dependency failed for Locl File System
[FAILED] Failed to mount /mnt/hdd

This follows with the standard message "You are in emergency mode" instructing me to enter my root password for maintenance but it seems the emergency shell cannot read any of my keyboard input. (sorry for paraphrasing yet again) This is why I've been running the last few commands over a live usb.

Edit: I guess I should also note that /mnt/hdd is for the ntfs drive, I set up a rule to auto mount that at start.

Last edited by trout420 (2023-06-09 23:13:02)

seth · 2023-06-10 05:52:39

/mnt/hdd is sdb1, but /root doesn't show up in the fstab you posted before, but chances are that the installed and booted kernel are out of sync.
Compare "uname -a" in the emergency shell (not! from the installation iso) w/ "pacman -Q linux" after chrooting into the system.
At the chroot, make sure to mount the /boot partition (check the output of "mount") and re-install the kernel.

trout420 · 2023-06-10 14:01:38

How unwise would it be to reinstall the kernel without comparing the the installed and booted kernel? I spent a good amount of time digging into the keyboard issue last night and could not get keyboard input to work. There were a couple of "solutions" I did not try because they seemed to be pointed at specific issues of other users rather than the general issue of no keyboard in the emergency shell.
I also went ahead and edited my fstab to point to the UUID's of the nvme partitions for the corresponding mount points since having an fstab pointing to UUIDs that no longer exist is probably not a good idea.

seth · 2023-06-10 14:07:51

The fstab you posted had the correct UUIDs?
I guess the remaining one on the nvme had wrong ones?

Either way, re-installing the kernel will not make your situation worse - it'd just be good to understand the problem before approaching it.
Worst case, it won't help. In that case inspect the /boot partition and the /boot mountpoint (ie. the directory when nothing is mounted there) and check the versions of present kernels ("file vmlinuz-linux*" will tell you the version)

trout420 · 2023-06-10 14:21:08

Yea I think that the fstabs on the different drives were not the same, but either way I atleast made the comments more accurate. You were indeed right the boot and installed kernels were different versions and reinstalling the kernel from the chroot allows me to boot. My desktop environment seems to be working fine.

A little curious as to how the boot and installed kernel got out of sync, was it just a case of the boot directory being the sda partition and the root directory being the nvme partition (or vice versa) at the time of install?

At any rate, thank you both for your time and help, I definitely feel as though I understand a good bit more about the initialization of X and system boot in general after this fun experience.

seth · 2023-06-10 14:38:08

I think the main issue was that you had two sets of partitions w/ the same UUIDs - at least for the root partition and ended up randomly booting one or the other.
Whenever you update the kernel w/o the boot partition mounted, you'll end up booting a dated kernel and having various modules that are required for proper functionality.
Or in your case, in addition you may have properly updated the kernel, but the modules ended on the root partition you were not using on the next boot.

Arch Linux

#1 2023-06-09 14:57:22

[SOLVED] Intermittent issues with display manager/desktop environment

#2 2023-06-09 15:09:36

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#3 2023-06-09 15:16:33

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#4 2023-06-09 15:24:35

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#5 2023-06-09 15:54:17

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#6 2023-06-09 16:09:21

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#7 2023-06-09 16:24:38

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#8 2023-06-09 16:40:54

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#9 2023-06-09 16:55:19

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#10 2023-06-09 19:45:18

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#11 2023-06-09 21:30:14

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#12 2023-06-09 21:37:29

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#13 2023-06-09 22:07:49

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#14 2023-06-09 22:13:52

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#15 2023-06-09 22:26:47

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#16 2023-06-09 22:33:50

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#17 2023-06-09 23:12:02

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#18 2023-06-10 05:52:39

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#19 2023-06-10 14:01:38

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#20 2023-06-10 14:07:51

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#21 2023-06-10 14:21:08

Re: [SOLVED] Intermittent issues with display manager/desktop environment

#22 2023-06-10 14:38:08

Re: [SOLVED] Intermittent issues with display manager/desktop environment

Board footer