JeOs cannot open CDE due to xorg problems.

Hello there, i downloaded the Virtual Box version of the JeOs (leap 15.1) and wanted to install CDE (Common desktop environment) to it however im having xorg errors. I did download all the dependencies they said in their site, i also downloaded xorg-x11 package however when i type the command to open it it gives me this:

and here is the log:

then i tried to open with dtlogin (again in the suggested way in their own site) which gave me this:

Tried to install Lightdm and GDM too both just made the screen flicker and after a minute closed themselves.

Also i don’t think it has anything to do with but only other thing i installed to the system was twin desktop manager with its dependencies (which also doesn’t work) and virtualbox guest things.

Try removing the nomodeset, in saying that not sure how it would go in virtualbox. When you say twin isn’t working, this is for command line and ncurses, what errors are shown?

Hello Malcolm, Sorry about the twin thing there was a little misinformation from my part. The VM that couldn’t open twin wasn’t this, this one is just not able to work with cursor (which is the expected behavior by the devs themselves)

I did remove the word nomodeset from the grub file at /etc/default/ However nothing has changed. All the errors looking the same.

I see the following;

cat .dt/startlog
--- Fri Mar 27 12:13:39 CDT 2020
--- /usr/dt/bin/Xsession starting...
--- Xsession started by xinit
--- setting font path...
--- sourcing /root/.dtprofile...
--- starting /usr/dt/bin/dthello -file /usr/dt/copyright &
--- starting /usr/dt/bin/dtsearchpath -ksh
/usr/dt/bin/dtsearchpath: error while loading shared libraries: cannot open shared object file: No such file or directory
--- starting /usr/dt/bin/dtappgather &
--- execing /usr/dt/bin/dtsession ...
not execing /root/.profile (see /root/.dtprofile)
/usr/dt/bin/dtdbcache: error while loading shared libraries: cannot open shared object file: No such file or directory
/usr/dt/bin/dtappgather: error while loading shared libraries: cannot open shared object file: No such file or directory
/usr/dt/bin/ttsession: error while loading shared libraries: cannot open shared object file: No such file or directory

So run the command (as root user) ldconfig, seems the spec doesn’t call this as part of the post install routine and doesn’t see the libs in /usr/dt/lib. Tested in qemu machine with GNOME installed, not JeOS. I also note the xorg-x11-fonts-misc is missing…

Hello Malcom, i did the things you suggested, sadly everything is still the same here is the new log: one other think i want to ask is did you also tried running twin first, i had an antix system that worked normally until i installed and ran twin on tty, i am going to remove all the extra packages that installed for twin and try again.

I would say it’s probably something like the vmware driver since I see a segfault there, like I said, qemu and gpu passthrough (nvidia) card working fine. If I was going to run something it would be cage with the Xorg option enabled. I was running that with the likes of Luakit on a JeOS kiwi image.


Thank you for your time Malcolm, I’ll try on quemu and see how that will go, if you have other recommendations (for windows host) please share them.

I use qemu for everything, but also on Tumbleweed as my primary desktop, I use WinX via qemu, but I use real hardware for the virtual machines, both gpu and sata controller and disks…

Could try virtualbox and see if that works better on a Windows Host?

It has no effect until /boot/grub2/grub.cfg is subsequently updated.

Not following the complete story, and not sure if it is relevant, but I get errors like:

/usr/dt/bin/dtdbcache: error while loading shared libraries: cannot open shared object file: No such file or directory
/usr/dt/bin/dtappgather: error while loading shared libraries: cannot open shared object file: No such file or directory

I first check if I can find those libraries on the root file system using:

find / -xdev -name 'libtt.*'

If that does not find anything I try to find the package that is supposed to install this and add it to the system.

Those errors are seen because the command ldconfig has not been run in the post install rpm scripts, you need to run it manually as root user to add the config file line /usr/dt/lib to the ldcache file.

Hello Malcolm, I didn’t quite get what you mean by that but I already was using virtualbox on windows to run my jeos if that’s what you mean.

Hello mrmazda, thank you for the reminder, i did forgot about that actually. However updating the cfg sadly didn’t change anything.

My bad, thought you were running VMware… So you could try qemu on the Windows host, for me always been a Linux host :wink:

Now the other option is building a kiwi JeOS image and running as a live USB? SUSE Studio Express

I have found over the years that because various JeOS are built differently, sometimes you can but other times you can’t install a graphical environment, and the primary reason in the past has been a particular pattern (name escapes me at the moment) which used to be installed to provide certain functionality whenever a graphical environment wasn’t installed from the beginning. I understand the architecture has changed so this pattern shouldn’t be seen anymore, but of course if the JeOS was built along original specs… You could still see it.

The big question is why you’re even trying to install a graphical environment in a JeOS in the first place, the two choices are diametirically opposite.
If you want to install a graphical desktop, you should be using a standard install ISO and selecting the “system” role which installs a text-mode system, or you can install your choice of Window Manager (if you select only the Common Desktop option without further installing a full DE) or whatever else you want.

I don’t remember all the details, but the main diff today between a JeOS and the “system” role in a standard install include the following which can be removed if you wish…
python and Ruby to support YaST

IMO JeOS is mainly for extremely minimal Production deployment of single purpose systems, it’s not for such things as graphical environments, developing solutions, testing, troubleshooting.


Sure it is for graphical targets, I use a JeOS kiwi image and cage just to run luakit, another one is the broadway backend to run apps in a browser… more to minimize cruft that is not needed…

Tried to install cinnamon with lightdm on a clean install on quemu. I can confirm just like tsu2 says, the version of JeOS I have just doesn’t work. Thanks everyone and especially Malcolm for everything.

My reason for installing JeOS was seeing how lightweight can a SUSE system be when using twin and have YaST2 at my disposal. i have achieved 40mb ram usage with Debian based Antix with working mouse pointer. So for comparison I wanted to use the lightest SUSE distribution as possible, which OpenSUSE JeOS looked like the perfect solution however after i saw that twins mouse pointers didn’t worked on jeos i started to use it as a test dummy and installing and using tinywm was always in my todo list and see the minimal ram usage ofc. Since that also didn’t work I wanted to try one last thing, which was CDE. And that’s how i end up here. The weird thing is antix started to give me the same errors after the first time i ran twin on it (on tty) so I decided to ask somewhere and since SUSE community is bigger and better I opened it here using the JeOS version. I did also asked on few subreddits but none answered. Sorry for all the confusion I have created.

So was the gpm systemd service started and running, that should be all that is needed for the console mouse support?

Well, twin used dev version of gpm and apperantly it’s really rare to see it working correctly. Even in the projects main page it says, The mouse support won’t work on tty version and even if it works it will lack things like dragging.
Funnily enough when open under Antix tty, mouse does work perfectly but like I say it kills X never to be used again. I am tying to find the reason.

A JeOS made through Kiwi won’t necessarily be anything close to the same as a JeOS VMware image… or any other JeOS that didn’t originate the same way (from your specific Kiwi build).

Years ago, I complained (yes, it’s somewhere submitted as a bug) that there was no standardized way JeOS were built. At the time, I was extremely impressed by the work that was done to create the first Docker JeOS images and I was interested in re-building other JeOS to similarly slim down, but I never received any response from anyone (including the author) to share their recipe so that it could be converted into a standard approach to JeOS.


As Malcolm suggested, I’d also recommend building your own based on a Kiwi JeOS so you know what’s in it. Or, possibly build on a Docker JeOS, I haven’t looked at many JeOS for a long time, but that was one I was impressed with… Practically no extras, and <it works>.

Maybe Kubic MicroOS could be a candidate, I haven’t looked at it closely but know it’s one of the most recent creations as far as minimalist versions of openSUSE go.