Earlier in 2024 Red Hat announced “Image Mode” for Red Hat Enterprise Linux. Currently Image Mode is in “Technology Preview” for RHEL. This is powered by Bootable Containers (or bootc for short). Fedora is also using this new technology, and they have great documentation.

To summarize what bootc does,
from the Fedora Documentation:

The bootc documentation summarizes bootable containers as “transactional, in-place operating system updates using OCI/Docker container images”. In other words, updates to the operating system (OS) are shipped by using container images. That implies that the Linux kernel, the bootloader, drivers, etc. are all part of the container image which renders the container image “bootable”.

These deployments are atomic, meaning they are (mostly) read-only by default.

Updates are easy, just re-build the Container Image and by default the bootc host will update (and reboot) on it’s own.

What makes bootc so exciting?

One Container Image to rule them all.
Sorry, I meant to say: One Container Image to keep every server up to date, automatically.

Every server automatically checks for a new container image. When there’s a new image, the server automatically updates. If the update or reboot fails, no problem. It will “auto-heal”. (there’s a buzz word I haven’t heard in a while!)

There is also no chance of a different package version being installed during a rolling update of many servers (when external repositories are not in your control).

If you need more than one image (if you have many different workloads on your servers then don’t put everything into one image!), it’s pretty simple to have a single “base image” and many specialized images built from that.

What could be better?

• Updates require a reboot.. for any update, any package install.
• There is still possibility for configuration drift in /etc
• Initial install can be difficult.
• Can’t easily add extra (non-root) disk (via the Dockerfile/Containerfile).
• Some packages can’t be installed into a Container.
• No release notes or changelog to see what packages change.
• Day 2 configuration changes are somewhat painful. Redeploying the entire OS isn’t great if you want to be truly immutable.
• Ansible doesn’t detect a bootc server any different from a normal RHEL or Fedora installation. But trying to install a package on a bootc server will obviously fail the Ansible Playbook. This makes re-using Ansible Roles difficult.
• Simple things like user management are not simple considering issues with drift. This means using Ansible for User Management doesn’t really make sense anymore.
• Advanced automatic update mechanism not included, like rolling updates of a 5 node cluster.

Conclusion

I think bootc has the potential for amazing things in 2025 (and beyond). An Atomic server OS that scales. Even with the above somewhat long list of needed improvements, I’m still very excited. Is it too early to start using Bootable Containers in production? I don’t think so.

The post bootc (Bootable Containers): One Container Image to rule them all appeared first on Ryan Daniels.

I find this useful for my infrastructure as code configuration with terraform. Each directory is a different environment or site, and I can use different versions of terraform based on the name of the directory.

This is for bash shell on Linux. Tested on bash version 4.3 or newer. Might work on older version too.

Add this code to your .bashrc file:

function terraform () {
  case "${PWD##*/}" in
    *env-2023*) ~/terraform_1.6.2 "$@";;
    *) ~/terraform_0.11.15 "$@";; # default case
  esac
}

Then log out and log back in.

What is this doing?

When you run the command “terraform”, your current directory is checked. If you are in a directory that has “env-2023” anywhere in it, then terraform_1.6.2 will run. Otherwise the (really) old version will run.

Conclusion

With this in your .bashrc file, you can have multiple directory patterns in the case syntax, each running a specific version of an application. I find this helpful when in the process of upgrading terraform config for all of my different environments for my infrastructure as code.

Here are some more Linux related posts.

The post Run different Linux program based on current directory (using Bash shell) appeared first on Ryan Daniels.

Raspberry Pi 3 B+

The ARM architecture uses minimal power. It’s only 1GB of RAM and a slow 4-core CPU. But for a small project, it’s perfect. Plus it has great Linux support (for an ARM based architecture).

Pi 3 B+ works great for Pi-hole and PiVPN (with OpenVPN or WireGuard)! Check out my old post about setting up PiVPN with OpenVPN.

Raspberry Pi 4

What About the Pi 4? It depends. It does have a faster CPU, and more RAM options compared to a Pi 3B+. But I don’t want active cooling. And the Pi 4 needs a fan.

Raspberry Pi 5 – Only HEVC GPU video decoding

The Raspberry Pi 5 only supports HEVC decoding. And no hardware encoding at all! HEVC is also known as “H.265”. This means no “H.264” (AVC) GPU decoding. Why does this matter? H.264 is still widely used. And that means the Pi 5 needs the use the CPU to decode H.264 (AVC), which uses more power and causes more heat in the Pi.

Raspberry Pi 5 Alternatives – Beelink Mini S12 Pro (x86)

I want a quiet and small headless home server type of solution that fits behind my TV.
I found the Beelink Mini S12 Pro works great for me. It’s actually about the same price as a Pi 5 with a basic setup! (with a case, sd card, power from CanaKit for $214.95). I got my Beelink Mini S12 Pro from Amazon currently on sale for $219 (CAD). Plus you can actually get this today, and not on pre-order like the Pi.
The Beelink Mini S12 Pro has:

• 4 core x86 CPU (Intel 12th Gen Processor Alder Lake N100)
• 16GB RAM
• 500GB NVMe disk for storage!
• 6W TDP

I’d recommend re-installing the OS though.
Linux installs and works on it just fine (tried with Linux Kernel 6.5, and 6.6). But note that WiFi and Bluetooth don’t work because of the Intel AX101 chip’s terrible Linux support. But for me that wasn’t an issue, I just use Ethernet.
This will give you way more power than a Pi 5, and not much more power usage. Yes it does use active cooling (fan), but I’ve never heard it.

However, if you don’t want to spend that much, then instead get a cheap laptop. Trade off is that it will likely use more power.

Conclusion

Stick with a Raspberry Pi 3B+ for any small projects. If you need something more powerful, go x86. Something like a Beelink Mini S12 Pro from Amazon, or even a cheap laptop will be better than a Raspberry Pi 5.

The post Raspberry Pi 3 B+ is the last Raspberry Pi you need (Why the Raspberry Pi 5 sucks) appeared first on Ryan Daniels.

Problem with running a newer OS (like RHEL 9)

Wow, RHEL 9 is using a modern kernel and toolchain. Ok, now I can continue.

Some newer Linux Operating Systems are moving away from iptables and changing to nftables. This can be a problem when an app is expecting iptables. Normally the OS can load the older iptables, but you can run into problems when running containers.

Error from GitLab Runner

It’s even more fun trying to figure out what’s going on when running on a GitLab Runner.

This is the error from a GitLab Runner job:

ERROR: error during connect: Get https://docker:2376/v1.40/info: dial tcp: lookup docker on 8.8.8.8:53: server misbehaving

Error when running Docker container

This is the error when running a container using Docker:

# docker run --rm -it --privileged --name dind docker:19.03-dind

...
INFO[2023-03-18T21:03:46.764203869Z] Loading containers: start.                   
WARN[2023-03-18T21:03:46.774269934Z] Running iptables --wait -t nat -L -n failed with message: `iptables v1.8.4 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.`, error: exit status 3 
INFO[2023-03-18T21:03:46.801647539Z] stopping event stream following graceful shutdown  error="<nil>" module=libcontainerd namespace=moby
...
failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.8.4 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
 (exit status 3)

So here we can see the problem. Our container is trying to use iptables and it’s not working.

But, if you run a newer Docker in Docker (DinD) container, it works! And then the old container also starts to work (this is, until a reboot of the host). The culprit? iptables, and a clever trick in newer DinD containers to workaround this issue..

Enable iptables from inside a Container

If you run a container as privileged, you can actually trigger the host OS to load the iptables kernel modules!

This was found from Docker in Docker (DinD) adding a custom modprobe script (called from the entrypoint script), which is essentially just running this command:

# ip link show ip_tables

The Docker in Docker modprobe script gives credit to:

Enable iptables on Red Hat Enterprise Linux 9

But if your container isn’t using this ‘ip link show ip_tables’ trick, the container will have problems. You need to enable the iptables legacy module on your host OS.

To have iptables loaded and ready to go, you can also run the above trick directly on the host. But the “proper” way is to use modprobe when the OS boots.

# modprobe ip_tables

That will dynamically enable the older iptables. But after a reboot the change is gone, so to make a persistent change:

echo ip_tables > /etc/modules-load.d/ip_tables.conf

Reboot and check:

# lsmod|grep -E "^ip_tables|^iptable_filter|^iptable_nat"
ip_tables              28672  0

Now the older containers will also work (that need iptables (legacy).

Conclusion

Red Hat doesn’t recommend running Docker (instead they recommend Podman). Probably for these reasons. And I wonder if this problem also has something to do with the underlying and undocumented way that Docker uses iptables INPUT chain.

The post Docker and Trouble with Red Hat Enterprise Linux 9: iptables appeared first on Ryan Daniels.

Let’s discuss the background of firewall issues with Docker, and a working solution for my use case (either setup manually or using Ansible). By the end we will use a firewall on the server to lock down everything by default, only allowing my trusted IPs! With the option to open specified ports publicly (like SSH).

Note: This solution works with CentOS 7, RHEL 7, Ubuntu 18.04, and Ubuntu 20.04.

Background

Firstly, even if you were using a firewall like iptables, Docker makes that useless. Docker punches a whole right through your firewall!

And if you try another firewall, like firewalld? Docker Swarm (and even regular Docker) with firewalld is a complete mess. Restart the firewalld service, or change the firewalld config, and you lost all the config that Docker needed. Now you have to restart Docker! What happens if the firewalld service failed and restarted? That Docker Swarm node is out of service.

Keep in mind, when I mention Docker, it means the regular Docker Engine. Docker Swarm means SwarmKit, which is the newer way of using Swarm. (The old way is the standalone solution which is old and not referenced at all here).

There are many attempts to solve this problem by users of Docker. Unfortunately the Docker team has been pretty quiet about these issues. They recommend a manual user solution, and to disable Docker’s use of iptables. I’m speculating here, but it seems like any future change from Docker will likely be a breaking change since this is a complicated issue to fix.

The attempted solutions (from users) are not very straight forward for a normal Docker user. And that’s the real issue. On top of that, out of the box (after you start one service with a published port), there is no security at the network layer. Anyone can connect to an exposed container’s port. Most importantly, even if you think you have a firewall protecting you.. Wrong, you don’t! With normal Docker, you can bind your service to your localhost which helps. But what about Docker Swarm? Nope, that doesn’t work.

There’s a great article about “The problem of forcing users to make choices (in security).” Definitely worth the read!

Roll your own solution

Until this is actually addressed in Docker, our only hope is to find the simplest solution possible. And turning off iptables integration in Docker is unacceptable (which is constantly recommended by the Docker developers). The other option is to move on from Docker and/or Docker Swarm. I hear this thing called Kubernetes is pretty great. Anyways, back to Docker.
Many people have spent hours trying to learn, and figure out iptables as a solution to this. You need to roll your own solution apparently! So iptables is probably the best approach, since that is what Docker needs to use to do it’s magic (and most other firewalls are just a wrapper for iptables anyway depending on your OS).

Something fun I found out while testing this, Docker Swarm uses iptables in an undocumented way. Docker Swarm uses the iptables INPUT chain! It’s only for encrypted overlay networks. But it’s not very fun realizing that! All of a sudden rules are being appended to the INPUT chain.

Okay, enough backstory. On with my futile attempt to roll my own solution. This took way longer than I thought it would! But it does work! Currently it works at least.. (That’s why I use the word futile!)

Problems I need to solve

1. Only allow traffic from multiple “trusted” IP addresses to my servers. Not all of these IPs will be in the same “IP block/range” either. This will be to all services running directly on the server, and also all of the Docker containers.
2. Let only specific ports be publicly accessible, like SSH.
3. I’m not managing which containers are accessible through the firewall. Meaning, I’m not manually adding ports into my firewall solution. That kind of manual work is not happening. I need a dynamic, and flexible solution that blocks by default except to my trusted IPs.
4. The firewall solution must be simple. More complex means more room for error.
5. The firewall solution must not impact performance significantly.
6. Restarting the firewall won’t break Docker.
7. Restarting Docker won’t break the firewall.
8. No impact to running server processes or Docker services when making a change. Things need to keep working!
   Firewall changes need to happen online and not impact Docker. Meaning I can’t be restarting Docker because I made a firewall change.
   Docker “changes” need to happen online. Meaning I can’t be restarting the firewall because I made a Docker change. (A Docker “change” means starting/stopping a container).

That sounds very simple! Unfortunately, it is not with Docker (and Docker Swarm).

Solution – Docker firewall with iptables and ipset

If you don’t know much about iptables, or ipset, that’s okay. You don’t really need to know. You should have some basic understandings though, so you don’t break your servers! The Arch Linux wiki has great information about iptables. Including this helpful visual about the iptables flow.

Note: This solution works with CentOS 7, RHEL 7, Ubuntu 18.04, and Ubuntu 20.04.

High level summary

iptables with ipset will handle all of this for us. And keep our servers, and Docker locked down from the network level.

In this solution, we will use the iptables INPUT chain to jump to another chain (let’s call our custom chain FILTERS), but return if there’s some legitimate looking traffic, so the Swarm overlay can do whatever it wants in INPUT with IPSEC, or whatever it is appending to INPUT.
Inside our custom chain FILTERS, we drop everything that doesn’t match our trusted list of IPs. We also allow our SSH port and the basic default iptables stuff.. You can also add any OS port to be publicly accessible.
The DOCKER-USER chain only needs a few entries. Any internal Docker traffic is returned, and it will drop any other traffic that’s not in our allowed IP list. You can also add any container port to be publicly accessible.

One of the dangers with this approach is if Docker changes it’s behaviour our firewall could break, or our Docker services could stop working. Since Docker doesn’t offer any solution for their users, we need our own solution. So keep in mind that you need to test this when upgrading to a new version of Docker. That is the trade-off with a “roll your own” solution. But what choice do we have?

I’ve created an Ansible Role: iptables for Docker, on GitHub and Ansible Galaxy.

Warnings

Warning: Be sure you have everything needed in your configuration. Once the iptables firewall is started it blocks anything that wasn’t added! Don’t lock yourself out of your server. Be sure to have another way to connect, like a console.

Disclaimer: Keep in mind, you should test all of this in your lab or staging environments. I can’t guarantee this will be 100% safe and can’t be held responsible for anything going wrong!

SELinux Bug: If using SELinux, currently there’s a bug with SELinux which prevents saving the iptables rules to the iptables.save file.
Impact: Saving the iptables rules a 2nd time will silently fail. Workaround has been added so SELinux allows chmod to interact with the iptables.save file. See notes on GitHub for SELinux workaround steps. Alternatively you could disable SELinux, but that’s not recommended. Bug report: https://bugs.centos.org/view.php?id=12648

The manual way

Run the commands below. These commands are only for CentOS/RHEL 7. If you don’t want to do this manually, jump to the Automatic section, using Ansible (which also works with Ubuntu).

Prep

Make note of what you already have in iptables (if you are already using it). Be sure you have some background with iptables, since you could break things!

# iptables -nvL --line-numbers

Install the required packages for CentOS / RHEL:

# yum install iptables iptables-services ipset ipset-service

Configure ipset

ipset allows you to add a list of IPs that you can use with iptables. In our case, we will add a list of IPs we want to be able to connect to our servers.

Configure ipset with a setname of ip_allow.
Add IPs you want to allow. Change the IPs below to your actual trusted/allowed IP ranges. Be sure to include your Docker server IPs here, because if you don’t they can’t communicate with eachother:

# mkdir -p /etc/sysconfig/ipset.d
# vi /etc/sysconfig/ipset.d/ip_allow.set

create -exist ip_allow hash:ip family inet hashsize 1024 maxelem 65536
add ip_allow 192.168.1.123
add ip_allow 192.168.100.0/24
add ip_allow 192.168.101.0/24
add ip_allow 192.168.102.0/24

Start, and Enable the ipset service:

# systemctl status ipset
# systemctl start ipset
# systemctl enable ipset

See what ipset has in it’s loaded configuration:

# ipset list | head

Important: Make note of the size of “Number of entries”. If that number is close to the maxelem size (65536), then you need to delete the ipset and re-create it with a larger max size. If you only use a few IP ranges like above, you don’t need to worry and will be well below the limit.

Configure iptables

Next up, iptables. iptables is our solution for a firewall. We will create a file with our rules and then add those rules into iptables. The important part is to not flush the existing rules if you are already using Docker (or Docker Swarm) on your server.

Create an iptables file to use with iptables-restore, to add the rules into iptables:

# vi iptables-rules.txt

Add below to the file. There is a lot going on here..

*filter
:DOCKER-USER - [0:0]
:FILTERS - [0:0]
#Can't flush INPUT. wipes out docker swarm encrypted overlay rules
#-F INPUT
#Use ansible or run manually once instead to add -I INPUT -j FILTERS
#-I INPUT -j FILTERS
-F DOCKER-USER
-A DOCKER-USER -m state --state RELATED,ESTABLISHED -j RETURN
-A DOCKER-USER -i docker_gwbridge -j RETURN
-A DOCKER-USER -s 172.18.0.0/16 -j RETURN
-A DOCKER-USER -i docker0 -j RETURN
-A DOCKER-USER -s 172.17.0.0/16 -j RETURN
#Below Docker ports open to everyone if uncommented
#-A DOCKER-USER -p tcp -m tcp -m multiport --dports 8000,8001 -j RETURN
#-A DOCKER-USER -p udp -m udp -m multiport --dports 9000,9001 -j RETURN
-A DOCKER-USER -m set ! --match-set ip_allow src -j DROP
-A DOCKER-USER -j RETURN
-F FILTERS
#Because Docker Swarm encrypted overlay network just appends rules to INPUT. Has to be at top unfortunately
-A FILTERS -p udp -m policy --dir in --pol ipsec -m udp -m set --match-set ip_allow src --dport 4789 -j RETURN
-A FILTERS -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FILTERS -p icmp -j ACCEPT
-A FILTERS -i lo -j ACCEPT
#Below OS ports open to everyone if uncommented
-A FILTERS -p tcp -m state --state NEW -m tcp -m multiport --dports 22 -j ACCEPT
#-A FILTERS -p udp -m udp -m multiport --dports 53,123 -j ACCEPT
-A FILTERS -m set ! --match-set ip_allow src -j DROP
-A FILTERS -j RETURN
COMMIT

Use iptables-restore to add the above rules into iptables. The very important flag is -n. That makes sure we don’t flush the iptables rules if we have rules already in Docker (or Docker Swarm).

# iptables-restore -n < iptables-rules.txt

Next, add a rule to the INPUT chain, so we start using the new rules in FILTERS. It has to be at the top, and only needs to be added once:

# iptables -I INPUT 1 -j FILTERS

Save the iptables rules:

# /usr/libexec/iptables/iptables.init save

That will save any existing and our new iptables rules to the iptables configuration file so it will be persistent after a reboot.

In addition, it was needed to run the above iptables command manually since we want to ensure it’s only inserted once. And we can’t flush the INPUT chain to ensure that since Docker Swarm could have rules there already.

Start and Enable the iptables service:

# systemctl status iptables
# systemctl start iptables
# systemctl enable iptables

If you want to customize the iptables rules to allow more ports to be open to everyone, just add the port to the appropriate rule in the iptables file (tcp or udp), then re-run the same commands from above:

# iptables-restore -n < iptables-rules.txt
# /usr/libexec/iptables/iptables.init save

Don’t miss the Warnings from above! Especially about SELinux.

If you don’t want to do all of that manually, and you use Ansible, then do this instead..

The Automatic way with Ansible

Manually run all of the above, on every Docker server is not ideal. Let’s use Ansible instead!

I’ve created an Ansible Role: iptables for Docker, on GitHub and Ansible Galaxy.

This works on CentOS 7, RHEL 7, Ubuntu 18.04, and Ubuntu 20.04.

Install the Ansible Role using Ansible Galaxy:

$ ansible-galaxy install ryandaniels.iptables_docker

Or, clone the GitHub project:

$ git clone https://github.com/ryandaniels/ansible-role-iptables-docker.git roles/ryandaniels.iptables_docker

Create the Ansible Playbook, called iptables_docker.yml:

---
- hosts: '{{ inventory }}'
  become: yes
  vars:
    # Use this role
    iptables_docker_managed: true
  roles:
  - ryandaniels.iptables_docker

Make configuration changes to add desired IP addresses and ports as needed.

Don’t miss the Warnings from above!

Then run the playbook:

$ ansible-playbook iptables_docker.yml --extra-vars "inventory=centos7" -i hosts-dev

Conclusion

In conclusion, now we have secured our Docker (and Docker Swarm) environments using Ansible to perform the installation and configuration of iptables! None of our Docker published ports are exposed to the world, unless we want them to be! We have created a custom Docker firewall with iptables. Hopefully, some day this will be the default behaviour and shipped with Docker out of the box! Dare to dream. Security is hard.

References

Background for Docker’s undocumented use of iptables INPUT chain

See my previous post about this.

References and links

References, notes, and links about the Docker firewall discussion:

• Docker Documentation – Overlay Networks
• Docker bypasses ufw firewall rules
• unrouted – Solution using iptables. Not for Swarm. It clobbers the INPUT chain, which is used by encrypted overlay with Docker Swarm
• The big thread about Docker and a firewall
• Arch Linux wiki to the rescue to show iptables flow which links to a great visual
  
  

The post Secure Docker with iptables firewall and Ansible appeared first on Ryan Daniels.

I fixed it by running one command:

$ sudo apt install cinnamon-desktop-environment

After it’s installed, reboot your computer. Then, before logging in, click the gear icon and change your session to Cinnamon.

Now everything is so much better!

Cinnamon Desktop

This will install the Cinnamon Desktop Environment for you. Which was initially developed for Linux Mint.

The main downside with this approach is you’ll probably be using this version of Cinnamon Desktop for a while. Packages don’t update very often in Ubuntu. However, in general not being on the newest of the new does bring stability.

If you still use Windows you are missing out. You should think about switching to Linux.

It’s amazing! Give it a try.

The post How to fix Ubuntu 20.04 in 1 step appeared first on Ryan Daniels.

It’s time. Windows users, Upgrade to Linux. Windows 7 is reaching the end of the line after January 14, 2020. Users must upgrade to something else. Do not replace Windows 7 with Windows 10. That is not an upgrade! How else can I say this? Do not downgrade from Windows 7 to Windows 10. Instead, upgrade Windows 7 to Linux!

In case you haven’t heard, do not use Windows 10, for many reasons. It’s a “Privacy Nightmare”!
Also, it’s actually really bad to use. They add junk into your Desktop menu at random. And it will come back even if you delete it.
Do you like ads? Microsoft is infesting Windows 10 with annoying ads.
You are not in control.

And then there’s the many problems with Windows 10 updates. So many crazy problems! It’s just plain bad. Did you know Windows 10 deleted user’s personal data! Also there are problems with Windows 10 booting after updating.

Linux, Everybody’s doing it!

There are so many reason to upgrade to Linux. If all you do on your computer is use a web browser, occasionally open pictures, sometimes open a spreadsheet or text document then you should definitely upgrade to Linux.

Even if you are a power user, there’s probably a Linux application that will replace that Windows app. But, even if there isn’t, you can use software like Wine to run Windows apps on Linux!

Do you game? Steam is an easy way to game on Linux! And it’s easy to install.

And then there’s the Linux community. It is absolutely amazing. When you do have an issue, there is so much help available by just searching.

Top 5 Reasons to switch to Linux

1. Linux just works
2. Linux is more secure
3. Surprise, Linux is easy to upgrade
4. Linux works on old hardware
5. Linux is easy to customize
6. Bonus Reason: Amazing community for help

Which Linux Desktop to Choose?

Linux on the Desktop has many distributions to choose from. There’s no single company to dictate what you can do!

With so many options to choose from, how do you pick? If it’s your first time using a Linux Desktop, try a distro that’s easy to get up and running.
“Linux Mint Cinnamon Edition” is a great choice to get started!

Why? Linux Mint is based on Ubuntu which is very popular and easy to use. If you need help, you will be able to find an answer since Ubuntu is so popular. And Linux Mint uses a nice desktop environment by default, called Cinnamon.

More screenshot can be found on the Linux Mint website.

Don’t want to use Linux Mint Cinnamon? Try Ubuntu instead. That’s what Linux Mint is based on after all! Kubuntu has a very nice desktop environment similar to Windows.

How to Upgrade from Windows to Linux Mint

Test it out before Installing

You can even try out Linux Mint before you install it to your hard drive. Actually most Linux distros can do this! Just download the ISO image and add it to a USB stick using LinuxLive USB Creator. Then reboot your computer and boot from the USB stick. Now you are test driving Linux Mint on your computer! Need a step by step guide? Check out their documentation.

Backup Windows

Before you install, be sure to backup your existing installation. A great tool for this is called Macrium Reflect. This can save an “image” of Windows to a file. Then later when running Linux Mint, you can start up your old Windows image as a virtual machine using VirtualBox!

Install Linux Mint

There are many guides online if you do a search. One thorough guide can be found here.

Conclusion

After you have upgraded to Linux, you are now free from Windows! No more worrying. You are free to enjoy Linux and all it has to offer. Next maybe you want to customize a few things. Linux (and Linux Mint) make that so easy.

Goodbye Windows, Hello Linux Mint!

The post 5 Reasons Why You Should Upgrade Windows to Linux appeared first on Ryan Daniels.