All you need to do is use an editor.
If you dont have nano installed you probably have something else … micro maybe ?
vi if you know how to use it?
If you are running KDE then you can just open the file in kate, and as it uses polkit, it will just ask you for permissions when you save.
Did you actually use capital S for sudo (it should be all lower case) ?
If I knew what the difference was I could also write a quick sed or awk command to do it.
All you need to do is use an editor. If you dont have nano installed you probably have something else .. micromaybe ? viif you know how to use it?
I did use neovim & was able to edit the file but was unable to save it. Not allowed to write to it. Everything I have tried won’t save.
Did you actually use capital S for sudo (it should be all lower case) ?
All is OK there. Wrote the wrong S s when typing here.
Did not do that. Missed it. That might be my issue. I had one update after a fresh install & I have installed xfce.
Looks like I might have to start again & this time pay more attention.
Just installed it on my laptop. How do I install tailscale and syncthing? Neither are on flatpak and distrobox doesn’t support systemd services as far as I can tell. These are key to me keeping this OS on for testing. Also need to install rclone.
You could use pacman to install additional packages you may miss. Else you might need to create your own variant of the OS and build your local images for it. We might provide documentation on how to do that soon.
Went back to gnome. Now I just have to find my way around. 
Left xfce on the system for now.
Sadly it’s not installed.
Wouldn’t that be the same thing? At least it would make sense for the gaming edition to have it installed. But i’m not that sure it does if you want a plain install.
@Hipster Just install the kate flatpak. As i mentioned earlier it can edit even root files. So be careful while using it.
@etrigan63 As @philm mentioned you can still use pacman to install software. It will ask you if you want to unlock the read-only partition for this session, but that’s it. It seems also that after building the image the manjaro track is changed to stable, so you might wonder why some packages are newer than those in the repo.
If you want to try a own spin you can do that pretty easy like mentioned here.
Open the terminal and move to a location you want to checkout git.
In my case it’s ~/Download and proceed as follows. I just used
git clone https://github.com/manjaro/arkdep-variants
because the mentioned variant gave me errors.
That should give you your first own created image. If you want to add some software, just edit the ../arkdep-build.d/test-manjaro-kde/package.list accordingly and repeat the procedure.
In case you want to give the kde variant a try you must edit the ../arkdep-build.d/test-manjaro-kde/bootstrap.list and replace everything linux69 related with linux610 because it not updated yet.
I don’t think the /etc/subuid and /etc/subgid will get created automatically(but i guess it should) so you’ll have to run
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 username
to be able to use /podman/distrobox/boxbuddy.
This will take just a few minutes and give a lot of room to play with( 
).
regards
Ps.: @dennis1248 @philm wouldn’t be more easier to maintain if every variant was just a diff of a base one.
For example just say there is a test-manjaro-basesystem with all files, configs, scripts etc. needed to have a nice cli version and the new variant just derives from that and adds the needed folders, scripts and so on.
Every new file with the same name would override the old one except package.list which should only extend the prior one.
That could be managed with config.build or something which state what variant should be used as a base for the now used one.
In theory that could be used to install different DE within one build just by linking them.
Just throwing my two cents in here. 
But at least you can always see at any stage what software was added or maybe removed by adding the package name again with an “-” or something.
I tried the variant build last night and was able to add the desired packages. Then I got crazy and gave COSMIC a spin. It will be very nice when finished. I may nuke/repave back to base Gnome image and then build a Gnome variant with the additional packages. Next stupid question: how are upgrades handled if I install a variant? Also, how are the distroboxen updated? topgrade will do it, but I don’t think it knows about arkdep yet.
I will start spending time on the desktop immutable again now that the gaming edition is mostly done. I will try to have a proper 2nd devel release done by the end of next month. The focus for this release will be polishing the overall user experience. No promises, but I will try to get it in to a daily drivable state and make sure it receives regular updates.
The gaming edition we are not releasing yet, the OS is in a really good state but OpenGamepadUI is not, we are waiting for the OGUI refactor to be finished before we will reevaluate if it is in a state suitable for an alpha release.
They are created by gnome-initial-setup, but there was a bug in Arkdep, these files were not migrated to new deployments. This is now fixed.
I considered it. But it would turn very ugly very quickly, the layers will start to diff from eachother and compatibility between them may break when installing from the latest packages.
So any update to any layer means that all layers are likely to be updated, to ensure they maintain compatibility.
Distros such as MocaccinoOS have this approach, but they are packaged specifically for it. The Arkdep approach instead works with existing packaging methods.
That is just traditional packaging again. With all the issues of traditional packaging.
Whenever you do a deployment without specifying a version it pulls the latest available version. You can can be on an old version of the GNOME image, it will pull the latest KDE one.
When updating it checks its config file to decide where (which variant) it should check for updates. If the latest available version is not deployed yet it considers it to be an update, it does not take variants in to consideration doing this, it only looks at version numbers.
Through the normal package manager inside of the Distrobox.
@RazorClaw Still no go. Can edit the file but it won’t save. That file is locked up good & proper. Anyway think I will wait for the gaming edition & just play around with immutable gnome. Thanks.
Yes, i think i have to apologize for my unspecific choosing of words. I didn’t mean to talk about combining image files or layers. That, what i wrote above, was about breaking down those project folders itself.
So in that case there would be a test-manjaro-bassystem project folder, with everything in it, what could be used, to create a fully CLI-Only based image.
But instead of creating an copy of that folder and rename it, to create an DE spin for example, just create a complete new project folder and add missing folders and files just needed for that DE spin.
Maybe with an extra config file, which would arkdep-build give the information, that this project folder is an incomplete one and everything missing should been taken from that base project folder, like an test-manjaro-basesystem.
So that, in the end, those combined project folders could be used to create an working image, just like test-manjaro-gnome for example.
(Every new file would override those of the base project, except package.list what would be used to append to the one of the base project.)
So every new project could state another project folder, to complete missing otherwise redundant parts or override them with new files of the same name.
I hope that idea is now more clear. It should guarantee every spin the same base functionality, without the need to edit every package.list file for every spin separately, while changing something of the basesystem itself.
regards
SmartVersion (CLI) might potentially be useful for what you seem to be describing. With it, one can create differential snapshots of an image which can be reintegrated, as needed.
For example; build a fully operational (CLI only) ISO, and use that ISO as the base to subsequently add each DE. Images can then be generated containing only the difference in data between the base and each completed DE image.
This has many obvious benefits including smaller file sizes; all one needs is the base and whichever differential DE image may be desired.
The SmartVersion is available for all platforms, and the executable smv is also scriptable. It is not open source, however is a long established product, and relatively inexpensive (and a surprisingly long trial period).
How useful it might actually be in this scenario, I can’t say. The executable would need to exist on the users machine to enable reintegrating the images to form the (hash accurate) ISO once again. That might introduce undesired complication.
Cheers.
Agreed, but i wasn’t talking about combining part of images into one.
Another example, let’s say you got two folders:
Folder A got a set video files, which would result in an entire movie.
Folder B only got a few additional video files, some not shown scenes etc. Like missing video files of an directors-cut.
While folder A would result into a complete movie(arkdeb-build A => complete system image), folder B would not(missing some essential files).
But combining them would result in the directors-cut (arkdeb-build (A+B) => complete system image).
So no i’m not talking about combining image snapshots, layers or something like that.
regards
Well, you are, though you might not realise it.
The only difference is that instead of folders, something like SmartVersion would process the finished ISO (or package) at different stages of construction.
I used the word snapshot only as a means to describe the differential states of respective completed and semi-completed ISOs.
Using your analogy to make it more understandable:
While Image A would result in the main feature movie (smv-build A => full movie), Image B would not (as it is missing additional content).
Combining both Image A and Image B results in the Directors-Cut (smv-build (A+B) => the full movie with the additional content).
Essentially the same thing.
Cheers.
Yes, i agree and i’m aware of the fact.
I just want to avoid those terms, so no one might think that i want to combine some image files itself. As it seemed that was not clear from my previous post.
In the end, if everything works correct, there should be no difference.
Afaik, way above, it was stated by @dennis1248 that combining image files is not a desired solution. That’s why i’m asking if to do that, with the project folders instead, is.
So yes, technically we’re both talking about the same results, but i want to avoid prebuild image files or, additional needed, software packages.
regards
Sharing configs between variants was something I have been eying myself recently also. Your comments on it made me spend some more time thinking on the topic, and I just finished implemented it.
Just an idea… Manjaro Quantum?
Arkdep seems very solid; it does what it is supposed to do without any problems. But what I definitely missed was the usual help page aka help|--help|-h and autocompletion. 
But there is a proper man page. 
In any case, I find the concept very interesting, especially since it was realized in Bash. Switching between GNOME and KDE was particularly pleasant. It couldn’t have been smoother. 
I have high hopes that this will establish itself in Manjaro and that arkdep will become an integral part of Manjaro and even replace the stable branch in the future.
@dennis1248 Would it be practical to import/export incremental snapshots as well? I see the arkdep is designed for full mode. Would that be something to tackle in the future?
Ah nice, will take a look and play with it asap.
Keep up the good work
Thank you.
Hello,
interesting approach.
My problem, which I had so far with all immutable operating systems, is the installation of my printer driver (Samsung Unified Printer Driver = ULD).
This is only offered in the form of a shell installation script and requires root access. I have no idea how to get a shell script installed in a read-only root.
I need my printer for work. That’s why no immutable operating system has come into question for me so far. Maybe there is a solution here?
While the root is read-only, an overlay makes it writable. That means changes to the root will be saved on the overlay, but it appears to be overwritten. You have to install the driver after every deployment/upgrade of the root. That’s it. That can be automated.
Totally wrong… it is much simpler. 
It just sets the property:
btrfs property set /arkdep/deployments/434782744792432789/rootfs ro false
btrfs property set /arkdep/deployments/434782744792432789/rootfs ro true