You can test or use Tails OS securely on your computer with this method, and nothing saves after you power off the virtual machine.

Step 1: Download Tails OS ISO

First, download the latest Tails OS ISO file from the official Tails website.

The ISO is found under the Burning Tails on a DVD section. Even though you aren’t burning a DVD, you need to use the ISO file for VirtualBox because VirtualBox boots operating systems from CD/DVD images.

The default Tails OS download on the homepage is a .img file for USB sticks, which supports persistence. However, VirtualBox cannot use persistence and does not support virtual USB drives via .img files, so always choose the ISO.

Step 2: Create a New Virtual Machine for Tails OS in VirtualBox

Open VirtualBox and click on New to create a new virtual machine.

Name and Operating System

Give your VM a name, such as Tails OS.

Select the Tails OS ISO file you downloaded as the ISO Image.

Ensure the following settings are automatically detected, and set them if not:

• Set the type to Linux
• Set the subtype to Debian
• Set the version to Debian (64-bit)

Be sure to check Skip Unattended Installation. This is very important for Tails OS because you want to prevent VirtualBox from creating a default user account or setting a password. Tails OS boots directly into its own secure environment by design.

Hardware

The technical minimum for Tails OS is 2048 MB RAM and 1 CPU core. However, for a smoother experience, I recommend:

• Setting the base memory (RAM) to 4096 MB
• Setting processors to 2 CPU cores or more, if your system allows

Hard Disk

Under the Hard Disk section, select Do Not Add a Virtual Hard Disk.

This setup ensures it’s physically impossible to save anything inside the Tails OS virtual machine. When you stop the VM, you erase everything, keeping your session private and secure.

When you’re happy with your virtual machine settings, click Finish.

Step 3: Boot and Use Tails OS in VirtualBox

Start your virtual machine. Tails OS will boot from the ISO.

Set your language and keyboard layout settings, and click Start Tails.

Tails OS will ask you how you want to connect to the Tor network. If you’re not sure, I suggest choosing Connect to Tor automatically and clicking Connect to Tor.

That’s it! Launch the Tor browser and start browsing the web anonymously from Tails OS.

Now you can use Tails OS in VirtualBox safely, knowing that all your activities are wiped when you shut down the VM!

Remarks

• Nothing will be saved when you shut down the virtual machine. Tails OS booted from the ISO does not support persistence. If you need persistence (the ability to save files or settings between sessions), you should use the default USB installation method instead.
• Do not install VirtualBox Guest Additions. Guest Additions can expose parts of your host system to the virtual machine, which goes against Tails OS’s privacy goals. Besides, when you power off the VM, it will wipe Guest Additions anyway.
• Keep the ISO file. Do not delete the ISO file you downloaded, because your virtual machine will need it every time it boots Tails OS.
• Use open-source virtualization software. Tails OS recommends using open-source virtualization tools like VirtualBox or KVM to run Tails OS because their transparency and auditability align with Tails OS’s privacy philosophy. Proprietary alternatives (such as VMware) are not as easily audited for privacy.
• The Tails OS documentation advises against using VirtualBox because it gets stuck at 800×600 resolution. I’ve found this advice seems outdated. You can set a variety of screen resolutions from the Tails OS display settings menu by right-clicking the desktop. VirtualBox runs Tails OS very well and is a much easier open-source alternative to KVM.

If you prefer a video guide, you can follow along with the video below:

The post How to Run Tails OS in VirtualBox appeared first on TechOpt.

In this guide, you’ll discover how to set a static IP in Ubuntu and define custom DNS settings, including nameservers and search domains. Additionally, we’ll explain how to keep DHCP while specifying DNS servers for better control.

Why Should You Set a Static IP on Ubuntu Server?

Assigning a static IP ensures your server retains the same address across reboots. This reliability is essential for servers running web services, databases, or acting as internal network resources.

Step 1: Identify Your Ubuntu Server Network Interface

To begin, list your network interfaces:

ip link

You’ll usually see names like eth0, ens33, or enp0s3.

Step 2: Edit the Netplan Configuration

Netplan configurations are stored in /etc/netplan/. View the files with:

ls /etc/netplan/

Next, edit the YAML file (replace with your actual file name):

sudo nano /etc/netplan/50-cloud-init.yaml

Here’s an example static IP configuration for Ubuntu Server:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        search: [yourdomain.local]
        addresses:
          - 1.1.1.1
          - 1.0.0.1

Replace eth0 with your interface name. Adjust the IP, gateway, and DNS to match your network.

Important: Some older guides might mention using the gateway4 parameter. However, gateway4 has been deprecated. It’s better to use the routes section, as demonstrated above, for better compatibility with future Ubuntu versions.

Step 3: Apply the Static IP Ubuntu Configuration

Once you have finished editing, apply the changes with:

sudo netplan apply

To confirm your new settings, run:

ip a

This command will display your active IP address. To confirm your DNS configuration is working, you can run:

apt update

This will refresh the built-in software repositories, and as long as it’s successful you know that your DNS configuration is working.

Alternative: Keep DHCP but Configure DNS in Ubuntu Server

If you prefer to use DHCP for IP assignment but still want to control DNS servers, use this configuration:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: yes
      dhcp4-overrides:
        use-dns: no
      nameservers:
        search: [yourdomain.local]
        addresses:
          - 1.1.1.1
          - 1.0.0.1

This method allows the server to receive its IP address from the DHCP server, while your specified DNS servers handle name resolution.

Conclusion

To sum up, netplan is the modern, recommended tool for configuring a static IP Ubuntu setup. You should avoid older methods like resolvconf or editing /etc/network/interfaces, as they are deprecated in the latest Ubuntu versions. Whether you need a full static IP or simply want to control your DNS while keeping DHCP, netplan makes the process clear and manageable.

If you would like to learn about all the configuration options for netplan, you can read the official Netplan documentation.

If you would prefer to view this guide in video form, I’ve created a video explaining these instructions on the TechOpt.io YouTube channel, which you can watch below:

The post Setting a Static IP Address and DNS in Ubuntu Server appeared first on TechOpt.

Step 1: Identify the USB Drive

Before writing the ISO to USB in Linux, you need to determine the correct device name for your USB drive. Plug in the USB drive and run:

sudo fdisk -l

This command lists all storage devices connected to your system. Look for your USB drive by checking the model, size and type. It will usually be listed as /dev/sdX (e.g., /dev/sdb) or /dev/diskX (on some distributions).\

In my case, this happens to be /dev/sdc, as you can see in the screenshot below:

Warning: Be very careful when selecting the device name, as writing to the wrong disk will result in data loss!

Step 2: Write the ISO to the USB Drive

Once you’ve identified the correct device, use the dd command to write the ISO to the USB drive:

sudo dd if=/path/to/iso.iso of=/dev/sdX bs=1M

Replace /path/to/iso.iso with the actual path to your ISO file and /dev/sdX with your USB drive’s identifier.

Explanation of Parameters:

• if=/path/to/iso.iso – Input file (the ISO image).
• of=/dev/sdX – Output file (your USB drive). Do not include a partition number (e.g., /dev/sdX1), as you need to write to the whole disk.
• bs=1M – Block size (1 Megabyte). Without this, dd defaults to a 512-byte block size, which can significantly down the process.

Step 3: Monitor Progress

When the dd command completes, it will output a summary similar to this:

123456789+0 records in
123456789+0 records out
123456789 bytes (X GB) copied, XX.XXXX s, XX.X MB/s

This confirms that all data has been written successfully to the USB drive:

The dd command does not provide real-time progress updates by default. On some distributions, you can add status=progress to see the write progress:

sudo dd if=/path/to/iso.iso of=/dev/sdX bs=1M status=progress

Step 4: Safely Eject the USB Drive

Once the process is complete, ensure all data is written by running:

sudo sync

Then, safely remove the USB drive:

sudo eject /dev/sdX

Remarks

• For bigger ISO images, the process will take longer.
• You should use the root device name (e.g., /dev/sdX) and not a partition (e.g., /dev/sdX1).
• For all options you can use with dd, you can consult the dd man page.

Now, your USB drive is ready to boot into the written ISO image!

If you would like a video guide, I also have one available:

The post How to Write an ISO to USB Drive in Linux appeared first on TechOpt.

Why Use Custom Warnings in Zabbix?

Zabbix provides various alerts by default, but I needed a custom warning to:

• Ensure Btrfs snapshots are being created regularly
• Get notified if the snapshot process fails
• Integrate this check into my existing monitoring system

There are numerous various use-cases for custom warnings in Zabbix. Custom warnings provide greater flexibility, allowing you to adapt them to your specific monitoring needs.

Setting Up a Custom Warning in Zabbix

1. Create a Custom Script

First, I created a dedicated directory for custom scripts in Zabbix on my Linux host:

mkdir -p /etc/zabbix/scripts

Then, I created the script file and opened it for editing:

nano /etc/zabbix/scripts/check_btrfs_snapshot.sh

I added the following script to check if a Btrfs snapshot exists within the last 24 hours:

#!/bin/bash

SNAPSHOT_DIR="/mnt/btrfs/.snapshots"  # Adjust to your snapshot location
THRESHOLD=$(date -d '24 hours ago' +%s)

latest_snapshot=$(find "$SNAPSHOT_DIR" -maxdepth 1 -type d -printf '%T@ %p\n' | sort -nr | head -n1 | awk '{print $1}')

if [[ -z "$latest_snapshot" ]]; then
    echo 0  # No snapshots found
elif (( $(echo "$latest_snapshot >= $THRESHOLD" | bc -l) )); then
    echo 1  # Recent snapshot exists
else
    echo 0  # No recent snapshot
fi

After saving the script, I made it executable:

chmod +x /etc/zabbix/scripts/check_btrfs_snapshot.sh

2. Add the Script to Zabbix Agent 2

I’m using Zabbix Agent 2 for advanced features. Since Zabbix Agent 2 supports system.run, I modified zabbix_agent2.conf to add the script:

1. Open the configuration file: nano /etc/zabbix/zabbix_agent2.conf
2. Add this line to allow the script: AllowKey=system.run[/etc/zabbix/scripts/check_btrfs_snapshot.sh]
3. Restart the agent: systemctl restart zabbix-agent2

3. Create a Custom Item in Zabbix

1. Go to Zabbix Web Interface → Monitoring → Hosts
2. Select the host where Btrfs is monitored (or where you’re adding your custom script) and click Items.
3. Click Create Item and set your parameters:
   • Name: Btrfs Snapshot in the last 24 hours
   • Type: Zabbix Agent
   • Key: system.run[/etc/zabbix/scripts/check_btrfs_snapshot.sh]
   • Type of information: Text
   • Update interval: 30m

I also recommend testing your script to make sure it runs properly with the Test option at the bottom of the Item UI from above.

4. Set Up a Custom Trigger

1. Navigate to the Triggers tab.
2. Click Create Trigger.
3. Use this expression to trigger a warning if no snapshot exists in the last 24 hours:last(/example-hostname/system.run[/etc/zabbix/scripts/check_btrfs_snapshot.sh])=0.
   You can also use the “Add Condition UI” in the side panel by clicking Add to help generate the correct expression.
4. Set severity (e.g., Warning).
5. Click Add.

Final Thoughts

Setting up this custom warning in Zabbix ensures my Btrfs snapshots are created on schedule. If a snapshot fails, I get a warning immediately, allowing me to troubleshoot the issue before it becomes a bigger problem.

If you’re using Zabbix for monitoring, creating custom warnings like this can significantly improve your ability to track and respond to important system events. Try it out and enhance your monitoring experience!

The post How to Create a Custom Warning in Zabbix appeared first on TechOpt.

When setting up a new environment, you might wonder whether you should deploy your workload inside an LXC container or a full VM. The choice depends on what you are trying to achieve.

LXC Containers: Lightweight and Efficient

LXC (Linux Containers) provides an efficient way to run isolated environments on a Proxmox system. Unlike traditional VMs, containers share the host system’s kernel while maintaining their own isolated user space. This means they use fewer resources, start up quickly, and offer near-native performance.

When to Use LXC Containers:

• Single Applications – If you need to run a single application in an isolated environment, an LXC container is an excellent choice.
• Docker Workloads – If an application is only available as a Docker image, you can run Docker inside an LXC container, avoiding the overhead of a full VM.
• Resource Efficiency – LXC containers consume fewer resources, making them ideal for lightweight applications that don’t require their own kernel.
• Speed – Since LXC containers don’t require full emulation, they start almost instantly compared to VMs.

Considerations for LXC Containers:

• Less Isolation – Since they share the host kernel, they are not as isolated as a full VM, which can pose security risks if an attacker exploits vulnerabilities in the kernel or improperly configured permissions.
• Compatibility Issues – Some applications that expect a full OS environment may not work well inside an LXC container.
• Limited System Control – You don’t have complete control over kernel settings like you would in a VM.

Virtual Machines: Full System Isolation

Virtual machines in Proxmox use KVM (Kernel-based Virtual Machine) technology to provide a fully virtualized system. Each VM runs its own operating system with its own kernel, making it functionally identical to a physical machine.

When to Use Virtual Machines:

• Multiple Applications Working Together – If you need to run a system with multiple interacting services, a VM provides a fully isolated environment.
• Custom Kernel or OS Requirements – If your application requires a specific kernel version or a non-Linux operating system (e.g., Windows or BSD), a VM is the way to go.
• Strict Security Requirements – Since VMs have strong isolation from the host system, they provide better security for untrusted workloads.
• Compatibility – Any software that runs on a physical machine will run in a VM without modification.

Considerations for Virtual Machines:

• Higher Resource Usage – VMs require more CPU, RAM, and disk space compared to containers.
• Slower Start Times – Because they emulate an entire system, VMs take longer to boot up.
• More Maintenance – You’ll need to manage full OS installations, updates, and security patches for each VM separately.

Final Thoughts: When to Choose LXC Containers vs. Virtual Machines in Proxmox

In general, if you need to run a single application in isolation, or if your application is only available as a Docker image, an LXC container is the better choice. Containers are lightweight, fast, and efficient. However, if you’re running a more complex system with multiple interacting applications, need complete OS independence, or require strong isolation, a VM is the better solution.

Proxmox makes it easy to work with both LXC and VMs, so understanding your workload’s needs will help you choose the right tool for the job. By leveraging the strengths of each, you can optimize performance, security, and resource usage in your environment.

The post LXC Containers (CTs) vs. Virtual Machines (VMs) in Proxmox appeared first on TechOpt.

Why Upgrade Now?

Ubuntu LTS (Long-Term Support) versions receive five years of updates, meaning 20.04 will stop receiving standard support in April 2025. While Ubuntu does offer Extended Security Maintenance (ESM) for an additional five years, that requires an Ubuntu Pro subscription, which costs money and may not be ideal for all users.

Checking Software Compatibility Before Upgrading

One of the main reasons I stayed on Ubuntu 20.04 was because I run the TP-Link Omada Controller, which historically ran best on older LTS versions. However, as of now, Omada supports Ubuntu 22.04 LTS, making this a good time to upgrade.

If you’re running custom software, self-hosted services, or enterprise applications, check their documentation or forums to confirm compatibility before proceeding.

Steps to Upgrade from Ubuntu 20.04 LTS to 22.04 LTS

To ensure a smooth upgrade, follow these steps:

1. Back Up Your System

Before making major changes, always back up important data. If you’re running a production server, consider creating a full system snapshot using tools like:

• Timeshift (for desktop users)
• rsync or tar for manual backups
• Btrfs snapshots (if you’re using a Btrfs filesystem)

I also backed up my Omada configuration through the web administration page, as well as made a snapshot of the virtual machine in Proxmox.

2. Update Ubuntu 20.04 Fully

Before upgrading, ensure your system is fully up to date. Run the following commands:

sudo apt update && sudo apt upgrade -y
sudo apt full-upgrade -y
sudo apt autoremove --purge -y

After the updates complete, reboot your system:

sudo reboot

3. Start the Upgrade Process

Once back online, use the following command to begin the upgrade:

sudo do-release-upgrade

This will check for a new release and guide you through the upgrade process.

4. Follow the On-Screen Prompts

• The upgrade tool will download necessary packages and warn you about changes.
• If prompted to replace configuration files, choose the default option unless you’ve manually customized them.
• When prompted to remove obsolete packages, confirm with Y.
• The process may take some time depending on your internet speed and system resources.

5. Reboot Into Ubuntu 22.04

After the upgrade is complete, reboot your system:

sudo reboot

Once your system boots up, confirm the upgrade with:

lsb_release -a

This should display Ubuntu 22.04 LTS.

Post-Upgrade Checks

1. Verify Software Functionality – Ensure your applications and services, like the TP-Link Omada Controller, are running properly.
2. Check for Remaining Updates – Run: sudo apt update && sudo apt upgrade -y
3. Remove Old Packages – Clean up unnecessary files: sudo apt autoremove --purge -y

Conclusion

Upgrading from Ubuntu 20.04 LTS to 22.04 LTS is straightforward but requires some preparation. Since Ubuntu 20.04 reaches EOL in April 2025, it’s best to upgrade sooner rather than later to stay secure and supported. If you run software that relies on very specific versions on Ubuntu (such as the TP-Link Omada Controller), ensure it’s compatible before proceeding.

The post Upgrade Ubuntu 20.04 LTS to 22.04 LTS appeared first on TechOpt.

Debian vs. Ubuntu: Their Origins

Debian

First released in 1993, Debian stands as one of the oldest and most respected Linux distributions. Built around the principles of free and open-source software, it thrives under community-driven development. Many other distributions, including Ubuntu, rely on Debian as their foundation.

Ubuntu

Launched in 2004 by Canonical, Ubuntu aimed to make Linux more accessible. It builds on Debian’s foundation but offers a polished and beginner-friendly experience. Regular updates and strong enterprise support make it a widely adopted choice. Over the years, Ubuntu has played a huge role in spreading Linux and has gained popularity on desktops, servers, and IoT devices.

The Shift in Ubuntu’s Philosophy

Once the go-to distribution for Linux newcomers and professionals, Ubuntu has undergone significant changes. Canonical, its parent company, has made several controversial decisions in recent years. One of the most debated changes is the introduction and enforcement of Snap packages. Unlike traditional package management systems like apt, Snap is a Canonical-controlled format that bundles dependencies with applications. It simplifies software deployment but adds unnecessary overhead, increases startup times, and creates system inconsistencies.

For many users, Snap complicates rather than simplifies Linux usage. Its abstraction layers make troubleshooting harder, and in some cases, it even reduces performance. Additionally, some software once available via apt is now only offered as Snap, limiting user choice. Frustrated by these changes, many long-time Ubuntu users are reconsidering their options.

Debian: Still Raw, Lean, and True to FOSS Principles

Debian, in contrast, remains committed to free and open-source principles. Unlike Ubuntu, which includes extra layers of customization and proprietary elements like Snap, Debian offers a raw and lean experience. Users control what gets installed and how the system is configured, ensuring a cleaner and more efficient setup.

This distribution also provides greater flexibility. Although configuring it initially requires more effort, it rewards users with stability and minimal bloat. By adhering to the Unix philosophy of keeping things simple and modular, Debian ensures a streamlined system. Its extensive repositories provide access to a vast range of free and open-source software, eliminating the need for third-party packaging formats that can hurt performance.

Debian vs. Ubuntu: Which One Should You Choose in 2025?

For those seeking a fast, efficient Linux distribution free of corporate influence, Debian stands out as the better choice in 2025. It serves as a rock-solid foundation for servers, desktops, and embedded systems while giving users full control over software choices without Canonical’s restrictions.

That said, Ubuntu still holds some advantages. Users who need enterprise-level support, long-term support (LTS) releases, or better third-party application compatibility may find Ubuntu more suitable. Companies and organizations that require professional support and streamlined administration tools will continue benefiting from Ubuntu’s ecosystem.

For individuals prioritizing performance, freedom, and a clean Linux experience, Debian remains the superior option. It stays true to Linux principles and provides a reliable system that does exactly what users need, without unnecessary extras.

Final Thoughts

Ubuntu has played a crucial role in making Linux more widespread. However, Canonical’s recent decisions have made it less appealing to users who prioritize performance and freedom. Debian, on the other hand, continues to champion the free and open-source philosophy. With its efficiency and customizable nature, it remains a strong alternative. If you want a Linux distribution that respects user choice and avoids corporate bloat, Debian is the best option in 2025.

The post Debian vs. Ubuntu in 2025: Which One Should You Choose? appeared first on TechOpt.

A key advantage of using Btrfs on openSUSE is its integration with Snapper, a tool that automatically creates snapshots before critical system changes, such as package installations through YaST or zypper. This allows users to quickly rollback openSUSE if something goes wrong.

While openSUSE is known for its strong Btrfs integration, the filesystem is not exclusive to it. Other Linux distributions, such as Fedora, Ubuntu, and Arch Linux, also support Btrfs, though the level of integration varies.

In this guide, we’ll explore how Btrfs works in openSUSE, how automatic snapshots function, and how to manually create and restore snapshots when needed.

Automatic Snapshots in openSUSE

openSUSE, through Snapper, automatically creates Btrfs snapshots before major system changes. These snapshots act as a safety net, allowing you to rollback openSUSE to a working system state if something breaks.

For example, when installing or updating software via YaST or zypper, a snapshot is taken before the changes are applied. This means that if an update causes issues, you can easily revert to the state before the update.

To list all available snapshots, run:

snapper list

You’ll see a list of snapshots with IDs, timestamps, and descriptions of what triggered them.

Creating a Manual Snapshot

While automatic snapshots provide great protection, there may be times when you want to create a manual snapshot before making significant changes.

To create a new snapshot manually, run:

sudo snapper create --description "Before major change"

This will create a snapshot that you can revert to if necessary. You can confirm its creation by running snapper list.

Rollback openSUSE to a Snapshot

If something goes wrong after an update or system change, rolling back to a previous snapshot is straightforward. You can do this in two ways: using Snapper or from the GRUB boot menu.

Method 1: Rollback via Snapper (Live System)

To rollback openSUSE to a previous snapshot while still inside your running system, first identify the snapshot ID from snapper list, then run:

sudo snapper rollback <snapshot-ID>

For example, if you want to rollback to snapshot 20, you would run:

sudo snapper rollback 20

After rolling back, reboot your system to apply the changes:

sudo reboot

Method 2: Rollback via GRUB

If your system becomes unbootable after an update or change, you can rollback openSUSE from the GRUB menu:

1. Reboot your computer.
2. In the GRUB menu, select Advanced options for openSUSE.
3. Choose Start bootloader from a snapshot.
4. Select a snapshot from the list and boot into it.
5. If the system works fine in this snapshot, you can make it permanent by running:sudo snapper rollback sudo reboot

This will set the selected snapshot as the new baseline.

Btrfs and Snapper Make a Rollback in openSUSE so Easy!

Btrfs, combined with Snapper, provides openSUSE users with a robust and reliable way to manage system changes, and rollback if necessary. Automatic snapshots ensure that package updates and system modifications can be easily undone if needed, and manual snapshots give users additional control over their system state.

Although Btrfs is especially well-integrated in openSUSE, it is also available on other Linux distributions like Fedora and Ubuntu. However, openSUSE’s implementation with Snapper makes it one of the most user-friendly and reliable choices for those looking to take full advantage of Btrfs.

The post Rollback openSUSE with Btrfs: A Filesystem with Snapshots appeared first on TechOpt.

The exact error I was getting after installing openSUSE Leap via Ventoy was:

Unable to mount root fs on unknown-block(0 0)

Interestingly, the recovery mode entries in GRUB worked fine. Upon further investigation, I discovered the culprit: the boot parameter rdinit=/vtoy/vtoy was included in the default boot entry but not in the recovery mode entry. Here’s how I identified and resolved the issue.

This guide will show you how to fix the “unable to mount root fs” kernel panic by identifying and removing problematic boot parameters from GRUB.

Steps to Fix Linux Unable to Mount Root FS Kernel Panic After Ventoy Install

1. Boot into Recovery Mode

Since the default GRUB entry triggered a kernel panic, I selected the recovery mode entry to boot into the system. This allowed me to access a functional shell for diagnosis.

2. Inspect Boot Parameters

To pinpoint the issue, I compared the boot parameters of the default and recovery mode entries. Using the following command, I listed the relevant boot parameters for the default entries:

grep -A2 "linux.*default.*root=" /boot/grub2/grub.cfg | grep -v "recovery"

This command filtered and displayed the GRUB boot parameters associated with the default entry. In the output, I noticed the parameter rdinit=/vtoy/vtoy, which was absent from the recovery mode entries. This discrepancy indicated the cause of the kernel panic.

3. Edit GRUB Configuration

To resolve the issue, I edited the GRUB configuration to remove the faulty parameter:

1. Open the GRUB configuration:
   
   sudo nano /etc/default/grub
   
   
2. Locate the line containing GRUB_CMDLINE_LINUX_DEFAULT. It looked similar to this:
   
   GRUB_CMDLINE_LINUX_DEFAULT="quiet splash rdinit=/vtoy/vtoy"
   
   
3. Remove the rdinit=/vtoy/vtoy parameter, leaving the rest of the line unchanged:
   
   GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
   
   
4. Save the file and exit the editor.

Step 4: Regenerate GRUB Configuration

After editing the configuration, I regenerated the GRUB configuration file to apply the changes:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Step 5: Reboot the System

Finally, I rebooted the system:

sudo reboot

This time, the default GRUB entry worked perfectly, and the kernel panic was resolved. My laptop then booted into openSUSE successfully.

Remarks

• Ventoy adds the parameter rdinit=/vtoy/vtoy during installation, which can interfere with booting certain Linux distributions.
• While this guide focuses on openSUSE, similar issues may arise with other Linux distributions installed via Ventoy.

By carefully inspecting and editing the boot configuration, I was able to resolve the kernel panic and successfully boot openSUSE installed from Ventoy. This method should help others facing similar challenges.

The post Fix Unable to Mount Root FS Kernel Panic After Ventoy Install appeared first on TechOpt.

This guide includes examples for various Linux and BSD distributions to make your system management easier and more efficient. I often use these commands myself when managing my various systems.

Keep in mind that these commands will generally auto-accept/default on any user prompts that would normally appear since they’re meant to be unattended.

Why Use a One-Line Command to Update and Reboot Linux/BSD Systems?

Combining commands into a single line streamlines routine maintenance, saving time and effort. Moreover, it’s especially helpful for:

• Servers where uptime is critical and automation is desired.
• Workstations where you want updates done quickly without constant supervision.
• Any user who values convenience and simplicity in managing their system.

Another key advantage of these commands is that they generally don’t require human interaction once executed. This makes them ideal for unattended updates, ensuring your system is updated and rebooted with minimal effort.

General Structure of the Update and Reboot Linux/BSD Command

Most package managers can refresh repositories, perform upgrades, and handle reboots. Therefore, the typical structure looks like this:

<refresh repositories command> && <upgrade software command> && reboot

Let’s look at specific examples for popular distributions.

openSUSE Leap

openSUSE Leap uses the zypper package manager. Consequently, the following command refreshes the repositories, upgrades the installed packages, and reboots the system:

zypper refresh && zypper up -y && reboot

openSUSE Tumbleweed

For the rolling-release version of openSUSE, Tumbleweed, you’ll typically use a distribution upgrade command. Here’s the one-liner:

zypper refresh && zypper dup -y && reboot

Debian and Ubuntu

Debian-based distributions use apt. Thus, this command refreshes repositories, upgrades software, removes unnecessary packages, and reboots the system:

apt update && apt upgrade -y && apt autoremove -y && reboot

Fedora

Fedora users can utilize the dnf package manager. Accordingly, the command for refreshing repositories, upgrading, and rebooting looks like this:

dnf update -y && reboot

Arch Linux and Manjaro

Arch Linux and Manjaro both use pacman for package management. Consequently, the one-liner for refreshing repositories, upgrading software, and rebooting is:

pacman -Syu --noconfirm && reboot

FreeBSD

FreeBSD employs the pkg tool. Therefore, the equivalent command for refreshing repositories, upgrading software, and rebooting is:

pkg update && pkg upgrade -y && shutdown -r now

(Note: FreeBSD uses shutdown -r now instead of reboot.)

Additional Tips to Update and Reboot Linux/BSD with One Command

• Use Sudo if Not Root: Ensure you run these commands with sudo if you’re not logged in as the root user. This grants the necessary permissions to update and reboot the system. For example, on openSUSE this would be:
  sudo zypper refresh && sudo zypper up -y && sudo reboot
• Automate with Cron or Systemd: To fully automate updates, schedule these commands with cron or a systemd timer. Additionally, ensure you have proper backups and are aware of the risks of unattended upgrades.
• Check Logs: After an unattended upgrade, check your logs to ensure everything updated successfully.
• Be Cautious with Rolling Releases: Systems like Arch or Tumbleweed may introduce breaking changes. Therefore, always review updates before running them unattended.
• For Servers: Test updates on a staging system before deploying them to production environments.

Conclusion

Updating and rebooting Linux or BSD systems doesn’t have to be a multi-step process. With a single-line command, you can simplify maintenance tasks and keep your systems running smoothly. Therefore, adapt the commands for your preferred distribution and enjoy the convenience of streamlined system updates.

Overall, this approach saves time and ensures that your systems are always up-to-date without much hassle. Additionally, the lack of required human interaction makes these commands an excellent choice for automation. Happy updating!

The post Update and Reboot Linux/BSD with a One-Line Command appeared first on TechOpt.