Tutorial on Douglas Domingos :: CompSci@UFCG

Creating a Multiboot USB Drive with Ventoy

Wed, 20 Nov 2024 18:49:01 -0300

Introduction

During a deploy of our custom Linux Mint images in one of the labs at UFCG, I’ve learned about Ventoy – an interesting tool for creating bootable USB drives. Of all the tools I’ve used for this task (like Rufus and Etcher), Ventoy catched my interest for three reasons:

It does not require flashing the ISO into the USB drive
It allows you to add multiple ISO files to the USB drive, without tweaking with disk partitions
It allows you to choose which image to boot from at startup

Ventoy is also very easy to install and use, as it provides packages with graphical interface for Linux, so you don’t have to worry with cryptic shell commands. But that’s boring, so we’re going to get our hands dirty anyways 🥱

How Ventoy works?

While installing Ventoy on an USB drive, it will create two main partitions:

The EFI partition (formatted as FAT), where Ventoy’s bootloader and configurations are stored, and only 32MB in size
The main partition (usually formatted as exFAT or FAT32), where you can place your ISO files

When booting from the USB drive, Ventoy’s bootloader will look for ISO files inside the main partition and list them at the boot menu. Please note that the disk layout may vary, depending on whether you choose the MBR or GPT partitioning scheme.

Using Ventoy on Linux

As mentioned before, we’ll be installing Ventoy through CLI – like real Linux users would. So, you’ll need to download the binary packages (e.g. ventoy-1.0.XX-linux.tar.gz file), which are avaliable at SourceForge. I recommend unpacking the tarball at /opt for convenience.

Inside the package, you’ll see a bunch of executable files. Since we won’t use a graphical interface, our focus is in the Ventoy2Disk.sh script.

If you wish to install Ventoy using a graphical interface, execute one of the files labeled with the VentoyGUI prefix. Please note that you have to choose the executable with the same architecture as your machine (e.g. VentoyGUI.x86_64 for 64-bit machines).

You may also use an Web UI by executing the VentoyWeb.sh and opening your browser at http://localhost:24680

If you plan to use Ventoy frequently, it might be interesting to add the executables to your $PATH. For that, I have an article on how to install packages manually on Linux, which you can find here.

Installing Ventoy on a USB drive

Now that we have the package set up on our machine, let’s take a look on how to use Ventoy2Disk.sh. After running the script without any arguments, we get the following output:

[...]
Usage: Ventoy2Disk.sh CMD [ OPTION ] /dev/sdX
 CMD:
 -i install Ventoy to sdX (fails if disk already installed with Ventoy)
 -I force install Ventoy to sdX (no matter if installed or not)
 -u update Ventoy in sdX
 -l list Ventoy information in sdX

 OPTION: (optional)
 -r SIZE_MB preserve some space at the bottom of the disk (only for install)
 -s/-S enable/disable secure boot support (default is enabled)
 -g use GPT partition style, default is MBR (only for install)
 -L Label of the 1st exfat partition (default is Ventoy)
 -n try non-destructive installation (only for install)

Although the text is pretty straightforward, we need to find which device is our USB drive – specified by /dev/sdX. For that, you can use the lsblk command to list all the block devices in the system. Here’s a sample output for this command:

user@host:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
[...]
sda 8:0 0 238,5G 0 disk
├─sda3 8:3 0 237,5G 0 part /
└─sda4 8:4 0 1G 0 part /boot/efi
sdb 8:16 1 7,5G 0 disk
├─sdb1 8:17 1 7,5G 0 part /media/dougsilva/Ventoy
└─sdb2 8:18 1 32M 0 part
[...]

USB devices are usually mounted at the /media directory. In my case, the USB drive is represented by sdb device, so I must pass /dev/sdb as the installation device to the Ventoy2Disk.sh script. Below are some examples on how to configure your installation:

# Install Ventoy on /dev/sdX. This will fail if Ventoy is already installed.
sudo ./Ventoy2Disk.sh -i /dev/sdX

# Force install on /dev/sdX, ignoring any existent Ventoy installation
sudo ./Ventoy2Disk.sh -I /dev/sdX

# Install on /dev/sdX while keeping a 500MB free space at the end of the device
sudo ./Ventoy2Disk.sh -i -r 500 /dev/sdX

# Install on /dev/sdX with GPT partition style and labelling the main partition as "Multiboot USB"
sudo ./Ventoy2Disk.sh -i -g -L "Multiboot USB" /dev/sdX

Please note that installing Ventoy WILL ERASE ALL DATA FROM THE DEVICE, so you should backup any important files from the USB drive before installation. Also, while installing through command-line, be careful to not mistake your USB drive for another device.

You can also use the fdisk -l command to list the devices of your machine with a more verbose output. This allows you to search for a device with grep (i.e. fdisk -l | grep "YOUR_DEVICE").

Booting up the USB drive

After the installation is complete, you can simply drag-and-drop your ISO files into the main partition, reboot your machine and boot from the USB drive. If you had no unpleasant surprises during installation, you should see the following screen:

From here, simply choose which ISO you wish to boot, and select the Boot in normal mode option. For more information about boot modes, read the documentation.

Some machines have a hot key for entering the Boot Menu at startup, so you don’t need to manually change the boot order in your BIOS. Please check out this list for reference.

Considerations about Secure Boot

Since Ventoy 1.0.76, Secure Boot support is enabled by default. This means that Ventoy should work whether Secure Boot is enabled in your machine or not.

If Secure Boot is indeed enabled in your machine, you should see the screen below when booting Ventoy for the first time. Please follow these instructions in Ventoy’s documentation on how to allow Ventoy on Secure Boot.

However, if you see another error screen while booting Ventoy, your system may not support Ventoy on Secure Boot. As such, you’ll need to disable the option in your Ventoy installation and your BIOS.

Conclusion

Until now, Ventoy has proved to be a handy tool for testing Linux distributions and keeping backup ISOs for system recovery. It’s easy to install and use, it’s lightweight and also quite fast when compared to similar tools.

While I have not tried installing a system through Ventoy, I plan to try it out soon with Fedora, and if everything goes as expected, I may use it to setup a dual-boot installation with Windows in the (not so) far future.

Installing software in Linux, the "hard" way

Sun, 15 Sep 2024 13:34:18 -0300

Introduction

Picture this: you’re setting up the packages and tools to develop your brand new application. Everything is going smooth, until you found out that one of the softwares you need is only avaliable as package of executable binaries, without any installers and nowhere to be found in your package managers. Seems like quite the overhead, right?

Well, not to worry! Because today we’re out to get our hands dirty and learn how to install ANY PACKAGE in a Linux system ‒ and you might just learn a few new tricks about Linux along the way.

I. Housing the package

The first step to solve our problem is to define where the package will be stored in our system. In practice, you may use any directory you’d like, but to keep things organized, let’s use the /opt directory.

The /opt directory is reserved for installing software and packages that are not part of the system’s core components, i.e, not necessary for your system to function properly.

When installing your package, you should create a new directory (preferably with the package name, like /opt/<package_name>) to avoid mixing up files of different packages.

You may have noticed that inside your package, there’s a /bin directory that contains some executable files. At this point, we can run these files, but we’ll have to specify the full path of the file every time.

II. Make your package avaliable with `$PATH`

To avoid having to pass the full path of the executables each time we run the software, we’ll make use of the $PATH environmental variable to specify the path of our installation.

The $PATH variable is a special shell variable that defines a list of directories where executable files are located. Each directory is delimited by a colon (:)

You may specify new directories in $PATH by exporting the variable with the new value (export PATH=/new/dir/path:$PATH).

Now, there are two ways of adding a executable to $PATH:

Adding a Symlink to the executables

Symlinks are (roughly) files that “point” to other file paths or directories. This allows us to access files accross the file system (and even other file systems), without specifying the full path.

You can create new symlinks using the command ln -s TARGET LINK_NAME, where:

TARGET is the path of the file which the symlink will point to
LINK_NAME is the path where the symlink will be created

To make it avaliable in $PATH, we may create a symlink inside a directory that is already in $PATH. In this case, let’s use the /usr/local/bin directory to store our symlink.

To create our symlink, simply run the following comman:

# Replace the placeholders with the proper names of your directories/files
ln -s /opt/<package_name>/bin/<filename> /usr/local/bin/<filename>

Once created, the executable will be avaliable in your shell. Try it out by typing the name of the symlink in your terminal.

Trade-offs of using symlinks

This approach is pretty straightforward and easy to setup. We don’t need to edit the value of $PATH, thus avoiding possible configuration errors. Also, by placing the symlink inside /usr/local/bin, we make it avaliable for all users of the system.

Unfortunately, there are also drawbacks. If you need to add multiple executables, you’ll need do create one symlink per executable. You may create a symlink to the /bin directory of the package, but you’ll still need to specify the name of the executable.

Links in Linux
Links are a powerful tool in Linux, allowing you to create shortcuts between files and directories, organizing your files easily, and much more. I recommend reading this RedHat post about linking in Linux.

Adding the package directory to `$PATH`

If you want a more robust solution, you may effectivelly edit the $PATH variable to include your package directory. For that, we’ll need to create a configuration file to export our updated $PATH.

The /etc/ directory contains configuration files of system applications, e.g. service management, network, SSH, and many more. Be careful when making changes to files here.

Similar to /opt, Linux also has a directory for storing system-wide configuration files: the /etc directory. Actually, there’s the /etc/opt directory, which is intended to store configuration files for applications installed in /opt.

To create the configuration file, head to /etc/opt and create a new file, named as <package_name>rc. Inside it, paste the following code and replace the placeholders with the correspondent paths:

# Replace "PACKAGE_HOME" with the name of your package
export PACKAGE_HOME=/opt/<package_dir>
export PATH=$PACKAGE_HOME/bin:$PATH

To load the settings into your shell session, run source /etc/opt/<config_file> and check your $PATH variable with echo $PATH. If the directory of your package is there, your configuration file is working.

Now, you might have noticed that the configurations aren’t loaded automatically when you open a new terminal. To address this, simply add this configuration to one of the following files:

# This loads "PACKAGE" into $PATH
[ -f /etc/opt/<config_file> ] && source /etc/opt/<config_file>

For only one user, append the load configuration at the end of ~/.bashrc
For all users, create a shell script (with the .sh suffix) in /etc/profile.d/ with the load configuration

Trade-offs of using `$PATH`

One advantage of this approach is that every executable inside the /bin directory will be avaliable in your shell. Also, you may choose to make it avaliable for only one user or for all users, by simply placing the load configuration in a different file.

However, tweaking with the $PATH variable may break your shell configuration if you’re not careful enough. The same goes for editing files inside /etc/profile.d; it’s best to create a new file rather than edit an existing one.

If you’re installing an application with a graphical interface (not CLI-based), you’ll likely want to add it to your desktop menu for easier access. In this case, we’ll need to take an extra step.

The entries in your desktop menu are located in the /usr/share/applications directory. Each application has a .desktop entry file, containing settings for how it is displayed in the menu.

To add a desktop entry file for your application:

Create a new .desktop entry file with the name of your application

Open the file and add the following configuration, replacing the placeholders with the correct settings:

[Desktop Entry]
Version=1.0
Type=Application
Name=<APP_NAME>
Icon=/opt/<PACKAGE_NAME>/<ICON_FILE>
Exec="/opt/<PACKAGE_NAME>/<EXEC_FILE>" %f
Comment=<APP_DESCRIPTION>
Categories=<KEYWORD1;KEYWORD2;>

Save the file and run sudo update-desktop-database

Now, the application is avaliable in your app menu, without the need to start it through the terminal.

Summary

Install your package in the /opt directory
Use symlinks or edit your $PATH variable to include the package executables for an user or all the system
If the package is not CLI-based, add a .desktop entry file at /usr/share/applications to add the package to your desktop menu

Conclusion

Although application support for Linux platforms is pretty decent today, you’ll eventually come across a situation like the one we’ve discussed here. Also, you can automate this process by creating shell scripts to setup the files for you.

Well, that’s it. Until next time! 👋

Tutorial on Douglas Domingos :: CompSci@UFCG

Creating a Multiboot USB Drive with Ventoy

Introduction

How Ventoy works?

Using Ventoy on Linux

Installing Ventoy on a USB drive

Booting up the USB drive

Considerations about Secure Boot

Conclusion

Installing software in Linux, the "hard" way

Introduction

I. Housing the package

II. Make your package avaliable with $PATH

Adding a Symlink to the executables

Trade-offs of using symlinks

Adding the package directory to $PATH

Trade-offs of using $PATH

III. Updating the desktop menu (BONUS)

Summary

Conclusion

II. Make your package avaliable with `$PATH`

Adding the package directory to `$PATH`

Trade-offs of using `$PATH`