DEV Community: Damian Cyrus

Add Manjaro into WSL 2

Damian Cyrus — Mon, 03 Jun 2024 14:19:33 +0000

I like Manjaro Linux. Too bad it is my second system, as I still need Windows software every day, which might or not work on a Linux distribution.

For this I wanted to use it in WSL, and found this nice YouTube video: Arch Linux on Windows Subsystem for Linux (WSL) - YouTube.

Based on the steps from the video I made my decision to use it as a base. The only preparation for this was to find out which docker image to use. Everything else is the same. I guess other distributions will work similarly if there is a docker image.

Requirements

Windows 10/11 with WSL 2 support
docker cli
- Docker Desktop or
- Rancher Desktop with Container Engine: dockerd (moby) within the settings
Windows Terminal
Windows PowerShell Core (recommended)
Ubuntu (or any other available distribution from the Windows Store) on WSL installed

Step by step

This guide will not go much into details, as it should bring you fast to an up and running system.

At the end there will be a condensed version, too. Use it when you understand the topics well.

Preparations

Make sure about the requirements, and your Linux distribution can run docker within.

Login into WSL

Open Windows Terminal, go into your WSL distribution and run following steps:

Pull image from docker hub: docker pull manjarolinux/base
Create a Manjaro Linux container: docker create -i manjarolinux/base bash
Copy the first eight or ten characters from the output. Example: 83398c22...
Run the container: docker container start 83398c22
Run interactive shell with it: docker exec -it 83398c22 /bin/bash

Within the Linux distribution

You have run the bash shell and it should now show information by running: whoami. It will show your logged in user is root.

Initialize `pacman` keys

There might be an optional step, but I recommend it for Arch Linux distributions. This one is for Manjaro:

pacman-key --refresh-keys
pacman-key --populate archlinux manjaro

This can take time.

For more information see:

Add user and admin rights

Add a user within the wheel group and change its password:

useradd -m -G wheel cyrdam
passwd crydam

Why wheel group? The wheel group will get sudo privileges in the next steps.

Next, the packages need to be up to date, and applications installed for user accounts:

pacman -Syu
pacman -Syu sudo vim

This will install sudo and vim. You can choose any other shell editor if you like, this will go with the following.

Now we can add sudo privileges to the wheel group by running:

EDITOR=vim visudo

And remove the hash character on the following line:

# %wheel ALL=(ALL) ALL

should look like

%wheel ALL=(ALL) ALL

Save and close vim by typing: :wq

Exit the docker container with the command:

exit

Export the docker image

Create a directory on your hard drive from within the Linux distribution and go there. Then create a sub-folder for the .vhdx image file. You can choose whatever folder you like, but I recommend not to use a directory within the user directory.

Example:

cd /mnt/c/dev/wsl/
mkdir manjarolinux

The directory manjarolinux is there to store the .vhdx file and will be empty at this moment. Stay in the current folder and run this docker command:

docker export 83398c22 > /mnt/c/dev/wsl/manjarolinux.tar

It will take seconds to write the container into the file given by the path.

The container ID needs to be the same as at the beginning. You can get it by looking into the container list with: docker container ls.

Now exit your Linux distribution:

exit

Import the image into WSL

From the Windows Terminal you go to the created directory and check if everything looks fine:

cd C:\dev\wsl\
ls

There you see the .tar file and the empty directory manjarolinux.

It is time to import the image into WSL:

wsl --import Manjaro ./manjarolinux manjarolinux.tar

Explanation of the parts:

wsl --import: command to import a distribution
Manjaro: Name of the distribution in WSL (and Windows Terminal drop-down menu)
./manjarolinux: where to store the .vhdx image file
manjarolinux.tar: file to import

Restart Windows Terminal.

Update Windows Terminal settings

In Windows Terminal open the drop-down menu and run Manjaro from there. It will run the user as root. Nobody wants that. Add a little start command to change it each time we run the Terminal Window.

Go to the Windows Terminal settings and open the file version of the settings by clicking on the gear icon on the bottom left side of the window. Your editor for the file should open. Search for Manjaro. Add commandline into the settings:

{
    ...
    "name": "Manjaro",
    ...
    "commandline": "wsl.exe -u cyrdam -d Manjaro"
}

You could also do it over GUI for the Manjaro profile.

Close the editor for the file, restart Windows Terminal and open Manjaro again. Check the user with whoami. It should show you your defined user (in my case cyrdam).

Optional step (aka signature)

To have a pleasant view and proof of running Manjaro within WLS you can install archey3 and present the output of your system, showing you also the kernel version from Microsoft. Run following commands:

sudo pacman -Syu archey3
archey3

See running Manjaro Linux in WSL on Windows.

My output:

$ archey3

               +                OS: Arch Linux x86_64
               #                Hostname: name of the machine
              ###               Kernel Release: 5.15.79.1-microsoft-standard-WSL2
             #####              Uptime: 1:13
             ######             WM: None
            ; #####;            DE: None
           +##.#####            Packages: 151
          +##########           RAM: 1436 MB / 15856 MB
         #############;         Processor Type: 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
        ###############+        $EDITOR: None
       #######   #######        Root: 798M / 1007G (0%) (ext4)
     .######;     ;###;`".
    .#######;     ;#####.
    #########.   .########`
   ######'           '######
  ;####                 ####;
  ##'                     '##
 #'                         `#

Improvement thoughts

To make this less time taking it would be possible to automate this entire process by a script with input capabilities. That means we would also run commands within the terminal and containers directly.

I do not know how this could work, but here is a summary of all steps.

Within Linux distribution

Run Windows Terminal with your Linux distribution, then start with the commands.

# Download image and create container
docker pull manjarolinux/base
docker create -i manjarolinux/base bash
# Copy the first eight characters of the output (example: 83398c22)
# Run the container
docker container start 83398c22
# Login into the container with the bash shell
docker exec -it 83398c22 /bin/bash

Within docker container

# Update pacman keys (can take a while)
pacman-key --refresh-keys
pacman-key --populate archlinux manjaro
# Add user
useradd -m -G wheel cyrdam
passwd crydam
# Update packages, install sudo and editor
pacman -Syu
pacman -Syu sudo vim
# Add user group to sudo user
EDITOR=vim visudo
# Edit the line: '# %wheel ALL=(ALL) ALL' > '%wheel ALL=(ALL) ALL'
# Exit vim
:wq
# Exit docker container
exit

Back in Linux distribution

# Create the folder first if not available then go to
cd /mnt/c/dev/wsl/
mkdir manjarolinux
# Use the ID from before or search for it with: `docker container ls`
docker export 83398c22 > /mnt/c/dev/wsl/manjarolinux.tar
# Exit the Linux distribution
exit

Within Windows PowerShell

cd C:\dev\wsl\
# Check directory content for .tar file and empty folder
ls
# Import image
wsl --import Manjaro ./manjarolinux manjarolinux.tar

Within Windows Terminal settings

# Update settings for 'Manjaro' profile by adding following line
"commandline": "wsl.exe -u cyrdam -d Manjaro"
# Restart terminal
# Open 'Manjaro' and check user is not root
whoami

Within Manjaro

sudo pacman -Syu archey3
archey3

Summary

If someone knows how to make this automated:

adding the image name (dynamic)
adding the distribution name for WSL (dynamic)
running all commands without issues or destroying anything

then please share your knowledge. Is there a better solution?

Currently, I can export my Manjaro Linux and share it on other machines if necessary:

wsl --export <distributionsname> <TAR-file>
wsl --import <distributionsname> <directory path to vhdx file> <TAR-file>

But be careful: you will also copy every file within the distribution, that also means project files that might not be for sharing because of legal reasons.

My journey of four years at diconium

Damian Cyrus — Fri, 26 May 2023 11:12:28 +0000

After my graduation and work as a 3D artist in 2011 I started my career as a professional web developer in an international publishing company and after seven years I quit there. Why? - actually, for many reasons, it accumulated: While the payment could have been better and the technology became less engaging over time, I saw it as an opportunity to broaden my horizons and work with a new tech stack. Plus, I was excited about the prospect of collaborating with others who shared my passion for this direction.

I accepted a recruiter´s offer for a company called diconium in Stuttgart. I agreed to go to the interview.

Job interview

The job interview had three parts:

Get to know
Technical interview
Personal Manager interview

My future director interviewed me first, also as a get to know. The vibe between us was good and I said I would take the job. The technical interview was around the normal path of: do you know this and that? - OK, that is fine, and if not, you will learn it on the way.

It felt different, like your word had a meaning and trust to the persons on the other side.

New job, new life

After the switch it took time to get into the unfamiliar environment from a PHP developer with HTML and CSS skills into a full JavaScript environment. It was a tremendous change for me. At that time, I never used JavaScript so heavily and tried to avoid it wherever I could.

My first task was to learn for an Angular project. That took time, but on the way, it changed to a React project.

I stayed with that project. With two other developers we created a demo shop within two months before the presentation. We proved that we could deliver what the customer wanted. I dedicated myself to creating something great, went on as the lead developer of the team.

Jack of all trades

At the beginning I was doing like everything: coding, Jenkins Pipeline, composition and integration, discussions about concepts and architecture and code quality, because it was necessary for the project. It was a good start, but not everybody liked this pace. The lack of experience also made it hard for others to work together, as there was a demand to have a stricter workflow than they were comfortable with. As a team we decided to concentrate more on coding and less on people management to deliver code quality. The client liked it. It was decided to increase the team.

I experienced separating parts of the work and bringing the responsibility to others more suited for it. We split the teams because of size, added more lead developers, created groups of core members to control the projects vision with multiple teams and continued.

Then scrum game came

As we went on with our work there was a change coming: we had to use an agile way for all teams: SAFe with scrum. I liked what I saw, we left the "lead developers" and put our trust to the agile way. I got my certification and continued to use the framework to our needs.

On the way I learned a considerable number of things, what it means to be agile, and how I need to adapt with my own workflow. To my surprise I worked already in an equivalent way but having a framework to show you with images made it again a nice addition.

Agile is not making the development process faster, but a little rounder. Why a little? Because it was more transparent than expected. It was a struggle at the beginning. Developers without the experience to change their workflow could not adapt and left.

The team found a way to adapt to our unfamiliar environment. There were people who adapted well, they understood the parts what that agile framework was for and how to use it.

This helped me personally to achieve a great deal of points:

You can link everything
It gets clearer on who manages what
I do not know everything
Others do not know everything
People need your opinion
Start talking to each other as soon as possible
The planning is working when you make it transparent
Adapt fast to changes
Learn and improve ourselves for the bright future (tickets)
Learn from the (dark) past
You develop slow at the beginning and get faster with time
Stories get better with time: tests, descriptions, tasks, acceptance criteria, splitting, structure/templates, refinement
We can communicate and react faster to changes on the way

Before I moved to another team

After our first demo presentation I wanted to improve the product but was disappointed for a long time. I presented simple future issues from time to time. People were not seeing the issues at the time. In my mind issues were increasing. Then I realized: it was only in my mind. We could have planned these things, but the project members were not there in mind, until things started really to crumble. We mentioned this to a big round, that we needed to improve.

The team found a way to communicate with others. There was a way for all of us to make things transparent without getting on the bad side of the client. It took the fear out of everyone to talk with others, rather than stay within the team.

It still took quite a while until this was set in motion, which put me again in a disappointed state. Of course, we needed to achieve other topics, create new features, and evolve the product. Because of the complexity of the code base, it got worse again. It felt impossible to fix the developer experience for everyone all alone.

Yes, everyone wanted to have it better, but the teams did not plan it, so: will not do. Sometimes it felt to me that people were scared because of reasons unspoken.

I talked to other developers about it. The team itself seemed to have no power to change this situation. What power? The teams have the power! Why do we not use it? Trying to make the customer happy is of course our job, but that does not mean the customer does not need to see that we are struggling until it boils up and we then are fixing the breaks on the speedway. When the developers are happy, then the customers will be happy too.

I got triggers to move on.

The triggers

There were multiple components that I created. Multiple of these lasted for a year, just updated like an extension, not changing anything. This made me think, as I saw the changes in the MR: my components are still alive, is that now boring or impressive?

In another part I fought with the pipeline, unit tests, linting, workflows, and got angry about it. I tried to fix it, but in the end, I got the answer to the task: the client did not allow it within the planning. We had it planned in the Definition of Done (DoD), but:

Nobody reads the Definition of Done.

This was an important statement within the team. We had that DoD ready, but no one used it, even if they should. Why was that so? Team members needed to set up more workflows = need to remember more things rather than coding. The process of remembering and doing more, rather than working on code only, made developers ignore the DoD.

Not everyone liked to do more than coding. That is understandable, but that was our role in this agile project. And I understood that even if I did this way of work, I would never be able to change the team, as single individuals did not want to change. The team stood still, and steps of improvement took a long, long time.

After three years on this project, I did not want to give up. I can be very stubborn. But I learned my lesson. There was a way, a trigger to move on.

There was a new team created from within the project, but with a slightly different goal: A design system team. I love these things. You create a design system, and it gets boring when you have it running. That wording feels negative, but thinking about my old components, that still lived on, it was exactly the thing I wanted: a stable code base standing and not failing anyone.

I asked to join the team and went on.

The new team

The design system team had a bunch of people with separate roles: UI, UX, developer, tester, product owner, scrum master. There was everything within it. It felt great. I could concentrate, improve, and learn the things I saw were important.

Next to the new experience I received, I looked at the other teams, and they saw improvements in the code. This was unexpected and it felt like their mindset changed. People saw us achieving things and getting a moment that the others were missing.

The design system team did remarkable things. We adapted new processes to improve our pace. I dove more into design systems and tried to make our product what we dreamed about as a team, not as an individual.

Other tasks

Next to the main work I had other tasks, like:

writing blog posts
help others with writing blog posts
enrich on-boarding processes
creating knowledge within the unit as a whole

All these tasks made me open to people. They started to see me as someone not too strict anymore on all that process stuff, but as someone who wants to improve the developer experience and make the client happy. To reach that it took time - time - I liked to invest.

The end

My personal priorities started to change over time. I looked over my life and decided that it was time to move on. The time I spent on the first team felt wasted, personally. The reason was quite simple: it took exceptionally long to reach the state I had in mind. The general project developed into the direction I imagined that I did not want to.

With the design system team, I was more than happy, and I still feel great to have been a part of them. It was the most fun time I ever had since working as a developer. But that is it. It was the highest state I could achieve. There were more things I wanted to do and might even reach higher levels of what I am now, but I knew I had to move on.

I felt lucky with the team I joined so heart-fully. I will not deny it was a hard decision and I do not regret the move. I understood my reasons well.

Things I learned on this journey

Ask questions
- anything that is unclear
- when you are struggling
- when you do not understand
- because there is never something like knowing everything
- people will help you
- it is not stupid
There are people
- I like to work with
- compatible with me
- better than me
- understanding what I want to say
- that let me learn to grow
Try to understand
- the company, its structure, and clients as good as you can
- the co-workers, each is a hero within your reach
- bottlenecks, try to figure out how we could remove them
- ways for improvement
Before you start something
- think before you start anything
- use whiteboards, notes, or words to display anything, it helps best to focus
- talk to people
Slow down
- you cannot know everything from day one
- each process might be bigger than it looks like
- split tasks into smaller pieces to move on faster
- understand the big picture
- figure out issues by analyzing and understanding it first before debugging
- structure your notes
Talk to people in general
- they know what is going on
- consider their opinions, be open minded
- figure out where they stay and why
Try to challenge yourself
- by projects/tasks
- view on issues
- help others by sharing experience rather than solutions only
Do not try to
- fix everything yourself
- push your own programming onto others
- move an elephant all alone

The next thing

In my new job I wanted to do things with something in mind which I could not achieve before. From here on I want to evolve further, see myself in a higher light within the next year. This is something I want; this is something I need. A goal that motivates me to push myself. I saw the time was right, and I had the motivation to do so.

Each change brings new challenges, meeting new people, creating new possibilities and the growing not only as a developer, but also as a person in general. I thank you all for that.

The greatest thank you goes to my family: especially my wife, for pushing me to move faster towards new challenges and solutions, and our kids who made me completely rethink and readjust communication skills, looking inside and outside of the given frame. It was not an easy decision, but I know it was the right one.

Let us look ahead into a great future, together. ♥