File systems is read only

I am testing KDE OS, version 2025-09-25, and I ran into a little problem: I cannot create a symlink(?) in the directory /lib64 to a file in /lib. I cannot run any of my custom programs unless I create this symlink, but KDE OS refuses to let me create the symlink saying “file system is read only”. I’ve tested over a dozen Linux OSes and KDE OS is that only OS that won’t let me do this. Is this just a limitation of the alpha is it is an OS policy? Can I reasonably override this restriction? Is it a bug? I don’t know.

Yes, that is by design. KDE Linux (not KDE OS) is immutable, which means you cannot modify the base system. This includes lib directories.

If you really, REALLY need to make changes to these directories, KDE Linux is not the OS you are looking for.

HOWEVER

There are ways to make things like what you want to do work (sort of): look into sysext. It may hold the solution you are looking for.

Good luck!

2 Likes

Thanks for the prompt and accurate reply, Paul_Brown.

Since I have no idea how to decipher sysext into plaintext English, I guess KDE Linux is not the OS I am looking for, but I would sure like to think it is the OS I am looking for … for other reasons of course. So maybe I should be more specific about my problem? I am new to Linux, and just like for Windows, I write pure assembly language programs in NASM. In that last two years I’ve been distro-surfing so much I’ve only had time to write five apps, one of them being like my test app called AlarmClock, consisting of 760 lines of pure NASM (it would be a lot more if I didn’t use macros). They all compile but none of them run. Linux gives errors like “cannot execute: required file not found”, so I did some research and translating that into plaintext English, I found that “required file not found” occurs because I use GCC ld as a linker, and it links my app to a non-existent .so called ld-linux-x86-64.so.2, instead of directly linking to Linux’s loader ld64.so, I haven’t found a way to get ld to link directly to ld64.so, on the command line, so what I do instead is symlink it. None of the forums have been useful in resolving this issue so far.

And that’s my real problem in a nutshell. If I can find a solution to that, KDE Linux very definitely could be the OS I am looking for (for other reasons too of course).

The upstream documentation for systemd extensions is quite horrible. It took me a long time to figure out what any of it meant.

We have simpler, more user-comprehensible documentation: KDE Linux/Add or override content in /usr - KDE Community Wiki

It might also be worth identifying whether the modification you’d like to make is something that we should do in the base system so it works automatically, out of the box. “works out of the box” is the name of the game for KDE Linux; we very specifically want to minimize the amount of tinkering people need to do to perform their tasks.

The link you gave me is dead, but I think you are talking about using /usr/local/bin to create my symlink, right? I don’t know, I just Googled “add override content in usr” and Google’s “responses could include mistakes”.

“It might also be worth identifying whether the modification you’d like to make is something that we should do in the base system so it works automatically, out of the box”

Wow! Nice, but what if what is happening is all my fault? Afterall, I am a Linux noobee, just getting started.

Sorry, bad link. I’ve corrected it in the original post, and here it is again for posterity: KDE Linux/Add or override content in /usr - KDE Community Wiki

If you’re writing software in assembly, I would hardly call you a noobee!

1 Like

I followed the instructions but KDE Linux still responds with filesystem is read only. I guess that means no program is allowed to directly access /lib/ld64.so.1 in KDE Linux unless KDE Linux gives permission, so I think you are right, KDE Linux is not for me. That is so discouraging though, since the one thing in common that I found in all the best distros I’ve tried is KDE Plasma. I thought the best distro should therefore be KDE Neon, but KDE Neon doesn’t support the open-source Nouveau driver, so I can’t play all my games in Steam, so that’s a no go. Then I saw KDE Linux in the works, but now that too is a no go.

FYI: My next test would have been using EDB flatpak to debug my program, but I doubt that would have worked too, because every distro that uses the flatpak version of EDB is unable to debug any of my (or any other) programs. I tried setting permissions in EDB using flatseal to allow everything, and it still wouldn’t work.

PS – One of the great things about KDE Linux was they incorporated something like flatseal into System Settings for flatpaks, which was a really great idea that I have not seen in any other distro, which is another loss for me which is also discouraging.

But thanks for all your excellent and friendly help ngraham.

Maybe it is just not installed by default elsewhere?

I have it on Neon but don’t remember if I had to install it manually

I didn’t check KDE Neon, but all the other dozen distros I tested that support flatpaks don’t have anything built-in like KDE Linux does. Typically you have to manually install flatseal (when it should be automatic), a policy which doesn’t make sense since a large number of flatpaks won’t work unless you change permissions on them. For noobies, the only thing we can experience is flatpaks that don’t work out-of-the-box, which makes flatpaks seem like a really bad idea. That is why I suggest that no Linux noobie use any distro that only supports flatpaks (or a mixture of flatpaks and standard installs like Kubuntu).

Typical flatpak issues I have seen:

  • Thunderbird flatpak doesn’t let computer Shut Down cleanly.
  • Some flatpaks won’t work with autostart.
  • EDB flatpak won’t work at all.

On Neon the package is called kde-config-flatpak

Would be surprising if the other distros don’t package it as well

What KDE Linux has that no other distro has, is if you go to System Settings –> Application Permissions, there is an option to “Manage Flatpak Permissions” directly there.

That’s weird. I use the Thunderbird Flatpak on KDE Linux and I don’t have this issue.

As @krake mentioned, this actually isn’t specific to KDE Linux. It’s a standard thing, and all distros need to do is pre-install it. One of the goals of KDE Linux is to avoid this kind of mistake and show other distros how to offer better Plasma sessions themselves! :slight_smile:

1 Like