LinuxQuestions.org - Problem Starting X

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Problem Starting X (https://www.linuxquestions.org/questions/slackware-14/problem-starting-x-4175705005/)

Problem Starting X

Excuse me posting a slightly off-the-wall issue here, but I feel fundamentally it is a Slackware problem.

On my Raspberry Pi 4, I have installed Slarm64. It's an unofficial compile of Slackware packages for Arm64bit sbcs generally. The RazPi 4 booting order is

SD Card
USB disks

Now if I put an sdcard in, X boots fine, and things work. It's set to boot to runlevel 4. I also rsync'ed the sdcard partitions to a real disk, and adjusted boot location & fstab accordingly, and that boots to runlevel 3. Then it says
Starting X11 Session Manager ...
Starting X11 Session Manager ...
Starting X11 Session Manager ...

repeating that line every 10 seconds. It never starts X. The disk is rsync'ed to the sd card, so it should start. I tried

Code:

grep -r mmcblk0 /etc/*

but it only showed in /etc/mtab (which is strange, actually, because there was no sdcard in it). /var/log/Xorg.0.log was from the previous boot of X.

Can someone point me to the script that's run to start runlevel 4 or employ their superior knowledge of boot procedures to diagnose my issue?

Quote:

Originally Posted by business_kid (Post 6309962)

Starting X11 Session Manager ...
Starting X11 Session Manager ...
Starting X11 Session Manager ...

This is where I'd hit ctrl+c and see the /var/log/Xorg*
It'd usually say where the EE (error) is, without that EE your bug could be basically anything.

Quote:

Originally Posted by elcore (Post 6309966)

This is where I'd hit ctrl+c and see the /var/log/Xorg*
It'd usually say where the EE (error) is, without that EE your bug could be basically anything.

I did. The old one hadn't been overwritten, so I conclude X hadn't started. There's some script(s) run, and I concluded X is stuck in one of those.

On my PC I tried

Code:

grep -inre 'session manager' /etc/rc.d/*

and the hit was line 13 of /etc/rc.d/rc.4, so it's looping on that, which it shouldn't. I'll have a hunt on the Pi this evening, and see how far I get.

There's also stuff in /etc/X11/xinit, where xinitrc is a symlink pointing at scripts for the multivarious window managers.

I got a bit further.

I mounted / on my disk as a partition while running from the sdcard, and rc.4 has that message about starting the Session Manager. Lightdm & xdm are present, so that should start.

I set up for runlevel 3, tried things and found the error. / on the disk is not mounting rw, but ro.
I can't see any errors, Now I had previously run

Code:

grep -inre 'mmcblk0' /etc/*

on this disk, and the only hit was from /etc/mtab:confused:. So I opened /etc/mtab in nano.

Code:

bash-5.1$ cat /mnt/tmp/etc/mtab

/dev/mmcblk0p2 / ext4 rw,noatime,nodiratime,data=writeback,errors=remount-ro 0 0

proc /proc proc rw 0 0

sysfs /sys sysfs rw 0 0

tmpfs /dev/shm tmpfs rw 0 0

shm /dev/shm tmpfs rw 0 0

bash-5.1$

Don't ask me why or how, but /etc/mtab must not get wiped on a Slackware shutdown. All my pc backups have things in /etc/mtab. So I ran my grep in /boot, and it's bad.

Code:

bash-5.1$ cd /mnt/tmp/boot

bash-5.1$ grep -r mmcblk0 *

grep: boot.scr: binary file matches

config:CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"

config-5.15.5:CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"

grep: Image: binary file matches

rebuild-initrd.sh:if [[ ! -z $(mount | grep -P "(mmcblk0|sd).1.*boot.*fat") ]]; then

grep: start4cd.elf: binary file matches

grep: start4db.elf: binary file matches

grep: start4.elf: binary file matches

grep: start4x.elf: binary file matches

grep: start_cd.elf: binary file matches

grep: start_db.elf: binary file matches

grep: start.elf: binary file matches

grep: start_x.elf: binary file matches

grep: vmlinuz-5.15.5: binary file matches

It was also in boot.cmd, some u-boot file, but I edited it out. I'm worried about it being in the kernel, though.

As a last resort, I checked /dev, which is empty. So I tried

Code:

ln -sf sda2 mmcblk0p2

making a symlink from mmcblk0p2 to point at sda2 - just in case. When you at the bottom, the only way is up:rolleyes: I'll have to wait to try it.