kdestartupconfig4 does not exist or fails. The error code is 127.
 

I got a problem with my Slackware installation after upgrading to slackware-current. I made a clean 13.1 install on my laptop, then I logged in as root, connected to the net and upgraded to slackware-current. Then, after rebooting, I try to log in to kde as root but I get this error: After getting these errors, I made a completely new fresh installation but I got the same errors again.

I even added another user with the adduser command just in case that was the problem but that didn't help. I can't log in to KDE.

Can anyone help?

Can you show us what your /etc/fstab looks like?
Also, if you are dual booting, please provide your /boot/grub/menu.lst.
There may be a problem with your partition UUIDs.

Just shot in the dark here:

Current has upgraded aaa_elflibs
but slackpkg has that blacklisted by default.
So check the blacklist and change
aaa_elflibs
to
# aaa_elflibs

then I would do:
slackpkg update
slackpkg clean-system
slackpkg install-new
slackpkg upgrade-all

EDIT:
I also had to install the nvidia driver for kde to work but I'm useing 4.5.3

I think this problem has been raised and addressed in at least two other threads in this forum, but it not clear to me that you have exactly the same problem.

The error does look like the one I've received on each of the two computers that I've recently upgraded. I've also received an error on the console that "liblzma.so.0" could not be found.

The solution (which I found in one of the other threads on this forum) appears to be to create a link named liblzma.so.0 that points to liblzma.so.5.0.0. This link should be in the same directory as liblzma.so.5.0.0, either /lib or /lib64 as appropriate.

It solved my problems on both systems, one running Slackware(32)-current and one running Slackware64-current.

the correct solution is to upgrade aaa_elflibs which is now being upgraded in -Current tree
it's in blacklist by default for -Stable system, but if you upgrade to -Current, you should upgrade this package as well

aaa_elflibs did not correct the missing liblzma.so.0 dependency problem for me. (I built the package using the SlackBuild script from a freshly downloaded "source" directory, just in case I still had an old one. I won't install the binary, as all my packages have been locally compiled. Possible the aaa_elflibs SlackBuild isn't updated or correct for x86_64)

I just manually symlinked it (in /lib64 in my case)

liblzma.so.0 -> liblzma.so.5.0.0

KDE (4.5.1) starts again now.

hm..... i don't see any problem report on this one on LQ
if it's truly incorrect, i would see many report on this

So nobody thinks I'm nutz, I just exploded my aaa_elflibs package built from slackware64-current/source and the prebuilt one from slackware64-current/slackware64

Mine does not get a liblzma.so.0.0.0 and the corresponding liblzma.so.0 symlink (no doinst.sh command to create it, either)

The prebuilt one, with the binaries of the libraries has them.

In the SlackBuild, in the symlinks-to-tracked-libraries file, it's there as /lib/liblzma.so.0 but it's not in tracked-files, which only consists of:

/lib/libdb-3.1.so
/lib/libdb-3.3.so
/lib/libdb-4.2.so
/lib/libdb-4.4.so
/lib/libdevmapper.so.1.02
/usr/lib/libcups.so.2
/usr/lib/libcupsimage.so.2
/usr/lib/libgcc_s.so.1
/usr/lib/libtalloc.so.2

It looks like only the symlinks-to-tracked-files got updated in the SlackBuild.

So that's why my aaa_elflibs package didn't work. Upgradepkg warned me that my gtk+2 and friends libraries had changed since the installation of the old aaa_elflibs package, then echoed their removal commands. That explains why that happened too. (It didn't seem to remove them as they do belong to other packages, but I did upgradepkg --reinstall on the corresponding packages anyway now that I understand what happened)

I think that sometimes people don't eat their own dog food. I have found SlackBuilds that don't (couldn't possibly) work. Those may not actually be used to build some of the packages. For one recent example, glibc. If I step through the patch commands, run the same ./configure commands and run make manually it will compile with make 3.82 yet it fails with the script, even after the make 3.82 diff was added. It fixes ONE problem with the Makefile for the manual, but the other only occurs with the SlackBuild script. It all proceeds like clockwork if make 3.81 (now in pasture) is used.