↓ Skip to Main Content
Shannon Wetnight

Starting the Linux Journey with Ubuntu

·· loading · loading · ·
Table of Contents

As I wanted to dabble a little bit with running Proxmox, I decided to deprecate a laptop and overwrite Windows 10 with a bare metal Proxmox installation. Laptops are great first-starters for home labs because they contain all the necessary ingredients to dip your toes in the water to what operating a home lab might be like before investing into the journey. A laptop has a built-in KVM, networking, power supply and a battery that can act as a UPS for itself. After using this as my virtual environment to play around with Proxmox, I later realized that a large portion of the setup for my home lab would require a mobile interface, such as that very laptop, to use during installs. For this reason, I sought to install Ubuntu and begin my learn Linux journey.

The laptop I am using is an Asus Zephyrus S Ultra Slim notebook. I ordered this device on Amazon in May of 2019 for $1800, and it served me well until I needed a desktop computer. The hardware is configured as followed:

Display: 1080p 144Hz IPS
CPU: Intel i7-8750H
GPU: GeForce GTX 1070 8GB
RAM: 24GB DDR4
Storage: 1TB PCIe NVMe SSD

My initial experience with Proxmox was great, and I intend on using it throughout my home lab journey installed on a Dell PowerEdge 730xd as the primary hypervisor (topic for later). Unfortunately, I ran into a bunch of errors and installation issues while trying to overwrite my NVMe storage device to get Ubuntu up and running. It seems that Proxmox may use Logical Volume Manager (LVM) for partitioning, and it is for this reason that the installation kept failing. After reviewing the log files to figure out where the installation kept failing, I discovered that it was referencing /dev/pve/data as not being an existing file or block device. I needed to remove that before proceeding.

Removing Existing (Protected) Partitions
#

There was probably an easier way to do this, but as I am new to the Linux environment, I decided to restart my laptop and boot into Hiron’s Boot CD via Ventoy. After loading into HBCD (Windows 10), I needed to open Disk Management and remove the solo partition responsible for the installation headaches. Unfortunately, Disk Management was unable to format the lonely partition due to it being an EFI System Partition (ESP). These types of partitions generally contain boot loaders and system files that are required for the system to boot, and they are usually protected from deletion for this reason.

To remove this partition, I had to use Diskpart in Command Prompt. The following steps saw the successful format of this pesky partition:

  1. Launch diskpart.
diskpart
  1. From here I needed to see which disks are recognized.
list disk
  1. In my case, I had a couple of disks listed, including the Ventoy USB bootloader. To remove the applicable drive (in my case, it was disk 1), I needed to select the disk to target before making any changes.
select disk
  1. At this point, the target disk is selected and I could now view the available partitions.
list partition
  1. I had two partitions assigned to this disk, and needed neither so that I could install Ubuntu and set my own partitions during the installation.
select partition 1
  1. Now that the first partition for this disk is selected, we can go ahead and delete it entirely.
delete partition override
  • Using Diskpart was crucial here because we have access to override. This allows deletion of protected partitions, which in this case was that first partition created by Proxmox.
  1. Reboot via Ventoy USB and install Ubuntu.

Ubuntu Partition Layout
#

After forcing a format with Hiron’s Boot CD, the installation was smooth and painless. I opted to split my single 1TB drive into a few partitions during the Ubuntu installation as followed:

Partition 1 (Default)  
  Name: nvme0n1p1  
  Format: FAT32  
  Location: /boot/efi  
  Size: 1.13GB  

Partition 2
  Name: nvme0n1p2  
  Format: Ext4  
  Location: /  
  Size: 512GB  

Partition 3  
  Name: nvme0n1p3  
  Format: Ext4  
  Location: /home  
  Size: 256GB  

Partition 4  
  Name: nvme0n1p4  
  Format: Ext4  
  Location: /swap  
  Size: 32GB  

Partition 5 (Remaining Space)  
  Name: nvme0n1p5  
  Format: Ext4  
  Location: /virtualmachines  
  Size: 220GB

Specifically, I chose to allocate a larger amount of storage to the root directory, as my experience with application installs is that it generally takes up twice as much as the user data I actually choose to store. Most of my data is cloud-based now, and in the near future I plan to have some kind of home NAS setup for anything that I would deem “large” and storage costly. Most of my files have been stored on my phone or tablet, both of which have 512GB, and of which neither has ever seen above 40% utilization.

For this reason, especially since this device will be primarily used as a mobile setup unit, it didn’t make sense to me to over-allocate storage for user data, since the expected amount would be fairly insignificant. Partition 5 will be used for light virtual machine use, with a minimal amount of storage being allocated. This is not intended to be used for anything heavy, so 220GB seems perfectly fine.

2026 Reflection: I intended to document this process further but never ended up getting around to it. Documentation focus did not start until mid-2025. Since this post, I have had a lot of experience with Ubuntu as a primary operating system. I’m also using Debian-based containers and virtual machines as I use that as the primary operating system for the virtualized servers in my home lab.

No light at the end of the keyboard.
#

Moving on to some quirks with the Ubuntu installation and things that I noticed right off the bat, my dual-purpose track/numpad no longer has the ability to cycle between modes, and I no longer have a backlit keyboard. As these were controlled by proprietary software (Armoury Crate and Aura Sync), this functionality has been completely lost without some modifications. The dual purpose num/trackpad situation isn’t of the highest priority, but I’d really love to have a backlit keyboard at the moment. After some research, I was able to find the brightnessctl utility.

Let’s take a look at how we can rectify a dead backlit keyboard after switching from Windows.

Utility Install
#

Installing brightnessctl and using it to locate the backlight.

We’ll need to install the brightnessctl utility that will enable us to script the function that we’ll use to control the brightness of the keyboard. Reading the documentation for this utility can be helpful to get a feel for some of the controls we can adapt from the commands list.

  1. Open a terminal, type “sudo apt install brightnessctl” and press Enter.
sudo apt install brightnessctl
  1. After it’s installed, we can go ahead and track down which devices are available to change brightness controls for. This is a critical step as without this information we won’t know which device to tell the brightnessctl utility to control.
brightnessctl \-l
  • I have several devices here that are listed, presumably for all kinds of specific functions for the LED controllers, as the laptop I’m working on this for happens to have several rows of addressable RGB LEDs. All that I am concerned with at the moment is getting the backlit keyboard to be either on or off, so let’s assign the Device globally responsible for that function. In this case, that device is listed as asus::kbd\_backlight. We need to addres this device using a script that we can then run to turn on at a certain brightness level.
    ![][image]

Creating a Script
#

Creating the script that will toggle the backlight on and off.

After locating which device I want to assign to control with brightnessctl, I can go ahead and think about how it needs to be commanded. The thought process isn’t rocket science – ideally, this should happen the way it usually does on a laptop – I’ll press the function key fn in combination with a function (F5 in my case) to toggle either 100% brightness, or turn the backlight off entirely.

We can accomplish this by using an if-else statement in a shell script that checks the current value for brightness, and if it is 0 (off), sets it 3 (max brightness) to turn the backlight on. Conversely, when we press the key again, it will perform the same check, but recognize that it’s now 3 and set it back to 0 to turn the backlight off again.

To write this script, we’ll need to do the following steps:

  1. Open a terminal and create a script:
nano \~/kbd\_backlight\_toggle.sh
  • This opens the nano text editor with a new file so we can write the script content. The name here can be anything you want, but I felt that it was appropriate to call it by the function it’s intended to perform.
  1. Tapping into my inner script kiddie and using Google to aid with the scripting here, especially as I am unfamiliar with the syntax, the following code is responsible for the backlight state.
#!/bin/bash

# Get the current brightness level of the device
current_brightness=$(brightnessctl --device='asus::kbd_backlight' g)

# Check if the brightness is off (0)
if [ "$current_brightness" -eq 0 ]; then
    # Turn the brightness to max (or your desired value for "on")
    sudo brightnessctl --device='asus::kbd_backlight' s 3
    echo "Keyboard backlight turned on (max brightness)."
else
    # Turn off the backlight if the backlight was aready on
    sudo brightnessctl --device='asus::kbd_backlight' s 0
    echo "Keyboard backlight turned off."
fi
  • Where we create this script doesn’t entirely matter, but for good hygiene I have chosen to create a folder in /home/Scripts to host any ongoing custom scripts that I will inevitably make as a result of decisions made by ASUS to leave Linux support out of the picture for Armoury Crate. This just keeps things clean and structured for future use.
  1. With the script created, we need to make the file executable before continuing.
chmod \+x \~/kbd\_backlight\_toggle.sh
  1. Now that it’s executable, go ahead and make sure it works by manually calling for this script to run.
kbd\_backlight\_toggle.sh
  • The system prompts for a password. This is normal and is addressed in the next section to make sure that the entire brightnessctl utility does not require a password to function.
  • The backlight to the keyboard either will turn on or off. Repeat the command to toggle states.

Adding a Sudoer
#

Removing the password requirement and keybinding the script.

Just a few more steps remaining before we have a functioning backlit keyboard toggle. Ideally, I would be able to change the brightness, alter the color (mine is currently yellow for some reason at the moment), or change effects. However, I don’t even have a way to turn the backlight on without running the script manually, so let’s address that.

We can start with the keybind, but brightnessctl will not function without sudo and a password entered, so you’d be sorely disappointed and confused like I was, pressing your keybind over and over and assuming you did something wrong or broke some component to the device in the process. Without being added to the list of sudoers, the brightnessctl script will function in the background but not actually do anything without a way to enter the password. Let’s go ahead and add the brightnessctl utility to the list of sudoers to get rid of this headache.

Open a terminal and complete the following steps to add the brightnessctl utility to the list of sudoers to bypass the authentication requirement. For this, we want to avoid altering the sudoers file and instead only add a configuration file containing what we need. This keeps the original sudoers file clean.

  1. Create the configuration file we need and open it so we can add the bypass information.
sudo visudo \-f /etc/sudoers.d/brightnessctl
username ALL=(ALL) NOPSSWD: /usr/bin/brightnessctl

Setting the Keybind
#

With the permissions out of the way, we can now set a keybind to toggle the brightness.

  1. Open Ubuntu Settings0

  2. Navigate to Keyboard

  3. Scroll to the bottom and select View and Customize Shortcuts under the Keyboard and Shortcuts submenu

  4. Scroll to the bottom and select Custom Shortcuts

  5. Add a new custom keybind

  6. In the Name field, enter whatever makes the most sense to you for this function.

  7. In the Command field, point the shortcut to the script we created to toggle the backlight, /home/yourusername/kbd\_backlight\_toggle.sh. This the location you chose to create the script.

    • If you choose to move it, make sure that it’s pointing to that location. The command must point to the absolute path where the file is stored.

  8. Set the shortcut by clicking on the shortcut assignment button. Press the function key combination that works best for you, but be careful not to conflict with other pre-assigned keybinds. I chose to use my laptop’s fn key in combination with one of the (now broken) Asus function keys on F5. Your combination may vary and can be whatever makes the most sense to you.

  9. Click Add

  10. Test the script by pressing the chosen function keys.

2026 Reflection: This approach is generally fine for something personal, but the best approach would have been to add brightnessctl write access to the affected files without giving it full sudo. The major security drawback to adding the utility as a sudoer is that it quite simply violates the principle of least privilege, and there is no reasonable need for the utility to have full root permission. Someone could leverage an unfound security vulnerability with the utility and do serious damage. Using something like udev tags would better suit the control scheme here and is actually outlined in brightnessctl’s official documentation. In hindsight, this approach was fine for what it did but is not a path I would take now due to the security implications of adding a potential external root user.

Reply by Email