Manjaro Summit public Alpha now available

Hello everyone! It has been some time since we shared an experimental version of Manjaro Immutable, since then we have been busy working on improving the technology and implementing some commonly requested features.

Manjaro Immutable is now called Manjaro Summit, and we are excited to release it in public Alpha!

What is Manjaro Summit?

Manjaro Summit is a semi-immutable (We’re calling it that for now because the term immutable is technically incorrect and controversial) distro with an atomic update system. Updates are done by downloading pre-made disk images, the root partition is read-only and only parts of the filesystem are migrated upon update.

The benefit of such a system is that everyone is running a near identical system configuration, this makes it easier to reproduce bugs and issues. Images can also be tested before being published. And should an update prove to be bad, you can simply roll back to an older unaffected version.

The immutability makes the system more resistant to user and software error, it also provides some limited protection against malware.

We are still unsure what Summit will eventually become, a stable rolling workstation distro, or an always moving distro chasing the latest and greatest in software.

The technology powering summit is purpose build to be as simple as possible, it is encouraged for people to start building and sharing images and configurations which fit their usecase or that of a wider community.

System requirements

  • UEFI
  • 4GB of RAM or more recommended
  • At least 32GB of storage
  • Network is required during installation

Systems with all drivers upstreamed in the kernel would provide the best user experience. Nvidia is not supported nor tested at this time, however it shouldn’t be hard to get these drivers installed and enabled using layering to install the packages and the overlay to load them in to the initramfs.

Download

Known issue: Ventoy will fail to boot the ISO.

We recommend gnome-boxes or QEMU+SPICE for the best experience inside of a virtual machine, guest tools for other VM solutions are not included.

ISO: https://download.manjaro.org/arkdep-gnome-installer/manjaro-summit-gnome-2025.04.14-x86_64.iso

Checksum: https://download.manjaro.org/arkdep-gnome-installer/manjaro-summit-gnome-2025.04.14-x86_64.iso.sha256

Notable changes since the experimental release

  • Support has been added for package layering.
  • We no longer use EFI variables for boot entry selection, boot priority is now defined using timestamps in the boot entry filename.
  • systemd-bless-boot support has been implemented, the system will now do an automatic rollback should a new image fail to boot.
  • The initramfs is now build with binaries from the new deployment and not the current root.
  • Various changes, improvements and fixes to the back-end.

What is still missing

  • A welcome app. Right now upon install you are dropped in to a mostly empty environment, we’d like to offer the user the option to install a default collection of apps as Flatpak on first boot.
  • GPG image signing. Currently image validity is checked using a checksum, Arkdep is already able to validate images using GPG, but this has not yet been implemented in our image build automation.
  • Automatic background system updates. Updates still have to be performed manually via the command line.
  • Right now only GNOME is supported. There are also configurations available for Plasma, XFCE and COSMIC. However, these are all untested and may break or lack basic functionality.
  • Sudoless Arkdep usage. We are still evaluating if we should allow sudoless system management using Arkdep for sudo users, this can be implemented via Polkit.
  • Limits on Arkdep’s system access. We’d like to limit Arkdep’s system access using Apparmor to prevent bugs from causing data loss and to limit the attack surface when running community-made images.
  • Improved update rollout. Right now images are pushed directly to “stable“ after being build with no testing.
  • Arkdep Bash and Zsh autocompletion.

What you can expect from the Manjaro Summit Alpha

  • Weekly updates. We will try to provide new weekly images build against Manjaro Unstable.
  • Tweaks and changes will be made to the configuration based on community feedback.
  • The above mentioned missing features will be added over time.
  • It should be stable enough to be daily driveable for people familiar with Linux.
  • Any major changes will be automatically applied through updates.

Getting started

Arkdep usage

Update

arkdep deploy

Rebase to another edition

Available vartiants are manjaro-summit-gnome, manjaro-summit-kde and manjaro-summit-xfce. Note that currently only the GNOME variant is actively developed.

To make a rebase permanent edit the /arkdep/config configuration file and change repo_default_image to match your preferred variant.

arkdep deploy manjaro-summit-kde

Layer packages

arkdep layer firefox

Removing a deployment

cat /arkdep/tracker
arkdep remove $DEPLOYMENT_ID

Workflow

Rely on Flatpaks and containers to install software, avoid layering packages if possible.

Distrobox

Distrobox and BoxBuddy are installed by default, using either you can install graphical apps to containers and make them available in your application list just like any natively installed application.

# Installing Firefox inside of a debian container
distrobox create -i debian:latest
distrobox enter debian-latest
sudo apt update && sudo apt install firefox-esr
distrobox-export -a firefox

Pacman

You can temporarily make changes which will be undone upon the next update by invoking pacman.

pacman -Sy firefox

How long will Summit remain in Alpha?

It may remain in Alpha for quite a long time. Many parts of the experience we’d still like to change or fully rework, and we need to gain confidence in the stability of the system before releasing it as stable.

How does it compare to other immutable/atomic distros?

Arkdep: If you maintain a 15MB/s download speed, Arkdep will download a 1.7GB image in 2 minutes and spend less than 30 seconds deploying it.

Silverblue/rpm-ostree: Is efficient with bandwidth, but heavy on the CPU. It downloads only ~300MB of data on the average update, but then spends 5 minutes blasting the CPU on a reasonably specced system to deploy it.

SUSE MicroOS/Aeon: Efficient on bandwidth and fast to deploy, but it is just taking a system snapshot and doing a traditional system upgrade. It is more comparable to Timeshift than image-based distros.

ChimeraOS/frzr: Mostly the same as Arkdep, it shares the same underlying technology. Bandwidth heavy but simple and fast.

Additional documentation

For additional documentation and information on Arkdep, refer to the Arkane Linux Arkdep documentation.

12 Likes

I have installed SUMMIT with KVM as en_US.
thank you.

It seems to be going pretty well.

extra user work
  • add ja_JP input environment > OK.
    • no ibus, use fcitx5 and mozc.
  • add ja_JP keyboard > OK
1 Like

I am currently reading up on Fcitx5, is picking it over ibus personal preference or are there functional differences?

@dennis1248
thank you.

There are differences.
From what perspective are you seeking opinions?
The way things are perceived differs depending on the language. Even if we limit our discussion to Chinese and Japanese, I feel that there is a big gap in opinions.
If I express my honest opinion, it may hurt people who speak other languages, so I will refrain from expressing it in words.

However, according to my observations, I think that many users of archlinux-based distributions are ja_JP users of fcitx5.
On the other hand, ubuntu-based distributions have the input method perfectly set with ibus without any hassle. Therefore, the trend may be that ibus is more popular.
My impression in my language.

*I do not want user-friendly defaults in Manjaro with using input method. I would like that to be the case, but it seems like it would be difficult to get the resources.

Please forgive my strange English. I don’t have time.

Downloaded, installed in a Qemu VM and works fine. Since Gnome is not for me, I tried to install Kde with sudo arkdep deploy manjaro-summit-kde but all I get is a BSOD, as you can see here there (may be can be helpful for you):

https://pixhost.to/show/5058/588215676_pantalla.jpg

Tomorrow I’ll try to reinstall again and see what happens.

While trying to edit /arkdep/config I missed an editor like vi or nano already installed in the system. So installed nano and fd command as a layer, although I’m not entirely sure how it works. Will nano and fd stay installed forever or will they ever disappear?

Also miss an arkdep --help option to see commands available instead of having to go to arkdep webpage.

The installation leaves a “locale.conf” file in / (contains “LANG=en-US.UTF-8”, and I use es-ES.UTF-8). Is this file necessary or can I delete it?

If cat /arkdep/tracker lists two or more deployments, is there any way to know which is the active one and which corresponds to each deployment? Something like an arkdep -list command wouldn’t be bad.

I also saw that one of them ends in a % sign, does that mean anything?

Thank you for your work. I will keep testing summit and comment what I see.

I suspect that either the deployment bugged and corrupted, or the bootloader is not configured properly. What are the contents of /boot/loader/entries/*-4aeea929384fe209e2b6b4b1c323ba6bb2eafdbf1a.conf? These are the type of bugs I never encounter despite daily driving this system for 2 years already, it might be a Btrfs bug if it failed the deployment.

Neovim and nano are installed by default on GNOME, I will make sure all other variants also have these installed.

That local.conf file is not supposed to be there I also see it on my end on my XFCE test deployment. It is weirdly not present on my KDE and GNOME deployments. Good bug report, thanks!

To see which deployment is currently booted you can cat /proc/cmdline. It is high up on the to-do list to add an arkdep info or similar command to provide such information.

The % sign in the tracker file is just your shell telling you there is no new line character on this line. I’ll clean this up to avoid confusion.

1 Like

I can’t see conf file because yesterday reinstalled the VM, but today I tried installing KDE again and it worked, so maybe the issue was on my side. If it happens again, I’ll try to get more information to post it here.

Nvim works, but nano…

Captura de pantalla_20250416_010948

In a Gnome VM newly installed. Pacman -Q nano returns nothing. It’s not a problem now I know nvim is installed, but without knowing it, the first thing I would always try to use is vi or nano and I suppose the same thing will happen to many people.

Thanks for the hint.

Also the boot menu is neither pretty nor very helpful… hard to see which is Gnome and which is Kde. :wink:

Captura de pantalla_20250416_005402

2 posts were split to a new topic: Regarding the development of Manjaro Summit

Installed summit in a VM in Gnome Boxes
Installation is straigth forward - no issues.

  1. Gnome shell integration is not installed by default - think in a Gnome environment this would be a must.
  2. No browser installed by default - is this wanted?

Will play around more

I encourage to instead use the extension manager from Flathub to download and install extensions.

Yes, there is no browser installed since they are beefy packages and should not be dependant on image updates to update. Install the browser as a Flatpak. In the future a welcome application will ask about installing default apps such as a browser.

1 Like

The first image update is up.

Use sudo arkdep deploy to upgrade.

Fixes:

  • locale.conf in root.

Improvements:

  • Images now have pretty version names.
  • neovim and nano now installed on all images.
  • vi and vim are symlinked to neovim.

The KDE and XFCE images seems to be bricked at the moment. I recommend against using them until that is fixed. This is likely caused by a major refactor we did to the configs.

Or install the old versions;

# KDE
sudo arkdep deploy manjaro-summit-kde 0f0e9a412f483704be0b5e75a2a58f3c76b0eac780

# XFCE
sudo arkdep deploy manjaro-summit-xfce 6943b6a50452c6ee32c583d5d6ac696555c5e82588
2 Likes

Another image update is up. The KDE and XFCE images are now fixed.

3 Likes

Updated and works fine. While deploying the update appears an error message from dracut (dracut[E]: Module ‘cifs’ depends on module ‘network’, which can’t be installed). I don’t know if it’s important or if I can ignore it.

Copying var/db
Copying etc/localtime
Copying etc/locale.gen
Copying etc/locale.conf
Copying etc/NetworkManager/system-connections
Copying etc/ssh
--> Locking new root partition
--> Installing kernel image to boot
Copying 6.14.0-1-MANJARO/vmlinuz
--> Checking for CPU microcode updates
--> Generating initramfs
dracut[E]: Module 'cifs' depends on module 'network', which can't be installed
Creating group 'nobody' with GID 65534.
Creating group 'adm' with GID 999.
Creating group 'utmp' with GID 997.
Creating group 'audio' with GID 996.
Creating group 'disk' with GID 995.
Creating group 'input' with GID 994.
Creating group 'kmem' with GID 993.
Creating group 'kvm' with GID 992.
Creating group 'lp' with GID 991.
Creating group 'optical' with GID 990.

The dracut error can be safely ignored. It does this because we excluded the network module from the initramfs. I’ll see if we can also exclude cifs to prevent this error.

1 Like

I’ve just seen some errors in journal regarding some “tss” user and group that seems not to exist. There’s one tss entry in /etc/gshadow, but not in files /etc/shadow nor /etc/group.

Also a warning about /srv for being a link instead a directory.

abr 19 20:20:35 manjaro systemd-tmpfiles[206]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:2: Failed to resolve user 'tss': No such process
abr 19 20:20:35 manjaro systemd-tmpfiles[206]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:4: Failed to resolve user 'tss': No such process
abr 19 20:20:35 manjaro systemd-tmpfiles[206]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:6: Failed to resolve group 'tss': No such process
abr 19 20:20:35 manjaro systemd-tmpfiles[206]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:7: Failed to resolve group 'tss': No such process
abr 19 20:20:35 manjaro systemd-udevd[287]: /usr/lib/udev/rules.d/60-tpm-udev.rules:3 Unknown user 'tss', ignoring.
abr 19 20:20:35 manjaro systemd-udevd[287]: /usr/lib/udev/rules.d/60-tpm-udev.rules:4 Unknown group 'tss', ignoring.
abr 19 20:20:47 summit systemd-tmpfiles[612]: "/srv" already exists and is not a directory.

System user accounts live in /usr/lib/{passwd,shadow,group}, they are updated with the system.

/srv is a symlink to /var/srv, it is symlinked because root is read-only, /var is a separate subvolume and is writable. The same trick is done with /usr/local. The error can be safely ignored.

I suspect those tss errors occure before it switches sysroot, likely a dracut issue, maybe it dislikes us having two separate user/group files, but it is probably nothing to worry about as it does not seem to impact functionality in any way.

1 Like

Hi,

Congratulations for the hard work.
I don’t find a link to download the KDE image, I would like to test it on a dedicated device for the next months.

There is no KDE installer, you will have to install the GNOME version and then rebase to KDE.

1 Like

Been trying Summit out for the last couple of days and just wanted to say great job so far guys.

I really liked the technical design of Silverblue/U-Blue when I tested them, but I am just NOT fan of Fedora or rpms.

So, I think this could be huge for the Arch-community.

I have tested both Gnome, and KDE deployments so far and its been pretty well put together. I know you have other stuff to add and refinements to do, but from what I can tell the bones and framework are very solid.

I have just a couple suggestions so far, feel free to ignore them.

  1. It would be nice if it would auto-switch your default deployment if you install kde or something without having to manually edit the /arkdep/config file.

  2. I think probably it might be better to up the number of deployments kept by default to maybe like 5 instead of 3, especially during the dev period when it might be handy to have previous versions to go back to.

  3. Frankly, I think enable_overlay should be set to 0 by default and force the user to change it in the config before they can do layered packages because of the possible risks and problems that can create and they should really be avoided. I have seen from the Fedora community, far to many try to use overlay packages way around the ideas of immutability, and then had many problems with their system.

Anyway, great job team, keep going!

2 Likes

I have a working calamares for arkdep for over a month now, if you really want KDE iso I can make it today/tomorrow when I have time

2 Likes