I just did a new install with the 19/9 iso. No problem. Then I did the by octopi recommended updates, systemd went from 242 to 243. The machine didn't boot anymore , stopped somewhere in between.
The reason for the new install was that to my old installation which I've kept always uptodate happened exactly the same yesterday. Luckily I have a second ssd which backed up my personal datas. So there will be no loss.
But now I think I will do a second new install but won't make the updates.

  • demm replied to this.

    Don't hijack existing threads with unrelated issues, open your own, split off for you this time.

    wolf51 stopped somewhere in between.

    https://kaosx.us/docs Make sure to post logs, let those who are willing to help know what your issue is. Where does it stop? What do you mean by stop? Black screen? Mouse pointer visible? Hangs on some text?
    When installing form the Sept ISO, there are no recommended updates, KaOS is fully rolling, the only way to maintain the system is to always fully update, partial updates are not supported and installing new packages on an old system is partial updating and will break the apps/system. What logs/messages did you see to know it was systemd? You updated almost the complete system, including new toolchain, all new Frameworks, Plasma, KDE Apps and replaced most of core.

    wolf51 but won't make the updates

    That is complete unsupported, see the above

        Sorry, I didn't intent to hijach that thread, thanks for splitting off. The system stopped with some acpi-error on screen which somehow looked common to me, - no mouse pointer. What striked me was the duplicity of the event with my former installation and the new from iso 19/9 after doing the latest updates with octopi. Apparently I don't understand the exact functionality of rolling updates. But nevertheless it seems as if I have to avoid the update presently.
        I wonder if there are logs, anyway I would have to find them with a live usb-systemstick.

        OK, that can be a known issue for some Intel CPUs, please post the output of inxi -F. If this is an Intel system, then you probably don't have a stop, but the kernel & systemd waiting for enough entropy (which will timeout after some time, for some 3 minutes others maximum 5 hours, don't ask me why they set the timeout to 5 hours.....), this can for some be fixed by adding CONFIG_RANDOM_TRUST_CPU=y to the kernel boot line. Again, will need system info to tell you how to add that (depending on UEFI or BIOS system).
        When you have the above hang, then you can almost always just start the system by going to TTY2 too and restart sddm in TTY2. And for some, just moving the mouse or typing on the keyboard gets the system the needed entropy. Kernel & Systemd devs are still at odds as to where the fix should be made.
        https://systemd.io/RANDOM_SEEDS.html
        https://wiki.debian.org/BoottimeEntropyStarvation

        demm, I read the links in the previous post and with google got to an Arch wiki called microcode - https://wiki.archlinux.org/index.php/Microcode. I have an intel SU3500 processor so I installed the
        intel-ucode package via octopi and rebooted.
        Well, I still get the blackscreen during boot, but it reach the desktop enviroment much faster, I would say 1 min 30 sec or so. It is a huge improvement than before

        If it can help others

        • demm replied to this.

          Christo61 This is not ArchLinux, and your perceived change is bogus, just installing ucode packages does zero, it needs to be either build into the kernel or added as an extra entry in the bootloader. You already had the intel-ucode, KaOS builds it into the kernel, so there is nothing you need to do to get the latest, and it certainly is complete useless to install ucode or read some wiki from another (unsupported) distro.

          Please keep it in your own thread too, your issue has nothing to do with this thread. (forum software doesn't let me merge these last 2 post back to the correct thread).

            Me too, I did some progress, but still have problems.
            I have amd-kaveri radeon, so no intel problem. Indeed I could login to tty2 and found that apparently the xserver shut down. The log-file - just before removing devices - shows " Failed to open authorization file "/var/run/sddm/{------}": No such file or directory". After googling "sudo systemctl restart sddm" started successfully the xserver. After rebooting same problem again. So this seems to be a sddm - problem. What to do?

            Please post the full journalctl log since the boot, sudo journalctl -r -b and /var/log/Xorg.0.log. This still can be an entropy issue. You mention X server shutting down, then sddm problem, without logs no-one can help you or figure how you come up with these conclusions.