Frequently Asked Questions
Table of contents
- What is Nitrux?
- Why Nitrux ≠ Ubuntu
- Why are the system requirements listed so high?
- Why is there no support for 32-bit processors in Nitrux?
- Will Nitrux support MBR storage devices for initialization?
- Why does Nitrux not support Legacy BIOS and only support UEFI or EFI?
- What is NX Desktop? (previously Nomad Desktop)
- Why focusing on AppImages?
- What is znx?
- What is the difference between installing and deploying in Nitrux?
- znx utilizes it, but what is the OverlayFS?
- So znx uses all the device, does that mean that I can’t use other operating systems but Nitrux?
- Does a Linux distribution, other than Nitrux, have persistence too when deployed using znx?
- Why can’t I “install” Nitrux using the ISO file when XYZ distribution “just works”?
- Deploying Nitrux from an existing Linux (Live or already installed)
- Deploying Nitrux from Windows
- How can I burn the ISO to a DVD?
- How can I flash the ISO to a USB?
- How do I try Nitrux on a virtual machine?
- I deployed Nitrux using znx, but I get an error, “No Operating System” or “unknown filesystem.”
- I deployed Nitrux using znx, but I get an error, “Selected boot image did not Authenticate. Press Enter to Continue.”
- I deployed Nitrux using znx, but I get an error, “Uncompression Error. System Halted” or “no bootable medium found.”
- I deployed Nitrux using znx, but I get an error, “Reboot and select a proper Boot device or Insert Boot Media in selected Boot device and press a key.”
- I have XYZ operating system installed on my computer, how can I dual-boot Nitrux?
- I can’t find XYZ application in the software center, how can I add new software?
- How can I add new software that isn’t available as an AppImage to Nitrux?
- I updated Nitrux using the terminal but nothing changed?
- I installed XYZ packages using the package manager, but after rebooting, they disappeared?
- I created a new user in System Settings and enabled autologin, but it’s not working?
- How long is Nitrux supported for?
- Do I have to deploy Nitrux again after a new release is available?
- I have a question, where do I ask for help?
- I’ve found an issue with Nitrux, where do I report it?
- Source code and license of Nitrux
What is Nitrux?
If you are new to Nitrux, or only casually acquainted with Linux based distributions, it can be difficult to understand how a Linux operating system compares with other computer systems that you may already be familiar. Hopefully, this page will help demystify Nitrux for new-comers.
Nitrux is an operating system based on Linux. Nitrux can be deployed without any need for a traditional installation. The operating system as a whole resides in a single file and directory on the partition /data/ of your device, making it easier to organize with your other data. We provide an operating system already preconfigured for the most common tasks, included is a web browser, an office suite, various utilities including a text editor, a file manager, a calculator, etc. Unlike a Live system, when Nitrux is deployed using znx it keeps all the data in your home folder even after the next time you boot. This feature is known as persistence. Using this feature of znx allows Nitrux to offer an immutable operating system. In other words, no changes will take place in the root directory.
Why Nitrux ≠ Ubuntu
Nitrux takes the Ubuntu distribution and brings it to a whole new level. We have built Nitrux from Ubuntu with the goal of not depending on the Debian package manager (dpkg) or its extended set of tools APT (Advanced Packaging Tool) to manage the operating system. For example, to obtain new software users don’t have to worry about missing dependencies, out of date repositories or conflicts with packages and when upgrading the operating system users won’t have to worry about conflicting dependency problems, partitioning or data loss because of the inherent stability of performing delta updates.
Contrary to what many people might think, we are not taking the vanilla Ubuntu distribution and performing a facelift.
For the moment dpkg and APT are still present on the system, however, with our constant focus on AppImages as the primary method of obtaining software now and in the future and znx as the only method of managing the operating system, the use of a package manager is not a central part of this distribution. To make it clear, we are not focusing on building a Linux distribution centered around using a package manager, no matter which one it is, our focus is on pushing forward the use of AppImages.
All of this has a massive impact on new users who expect Nitrux to be an exact replica of the Ubuntu experience with only minor differences, realizing this is not correct users may feel confused and at odds when trying out this distribution for the first time. Our changes run deep, and even though we build Nitrux from Ubuntu, Nitrux is not Ubuntu neither does it work like Ubuntu, nor it will be Ubuntu under the hood forever.
Why are the system requirements listed so high?
First, it must be understood that what is listed as the minimum requirements are not the same as what is listed as the recommended requirements. Minimum requirements indicate what we are considering to be the least powerful hardware setup to run Nitrux and still be able to use it without hurting the user experience that much. Yes, Nitrux could run in even lower-end hardware than what we list. However, the user experience would be utterly inadequate due to hardware limitations.
Therefore the recommended requirements are so that the user experience of Nitrux is optimal and the minimum requirements are so that user experience of Nitrux to be good enough. We have also included a list of the hardware that we used to create these measurements.
Why is there no support for 32-bit processors in Nitrux?
A big difference between 32-bit processors and 64-bit processors is the number of calculations per second they can perform, which affects the speed at which they can complete tasks. 64-bit processors can come in dual-core, quad-core, six-core, and eight-core versions for home computing. Multiple cores allow for an increased number of calculations per second that can be performed, which can improve the processing power and help make a computer run faster. Software programs that require many calculations to function smoothly can operate quicker and more efficiently on the multi-core 64-bit processors, for the most part.
Another big difference between 32-bit processors and 64-bit processors is the maximum amount of memory (RAM) that is supported. 32-bit computers support a maximum of 4 GB (232 bytes) of memory, whereas 64-bit CPUs can address a theoretical maximum of 18 EB (264 bytes). However, the practical limit of 64-bit CPUs (as of 2018) is 8 TB of addressable RAM.
High amounts of RAM are especially useful for software used in graphic design, engineering, and video editing as these programs have to perform many calculations to render their images.
One thing to note is that 3D graphics programs and games do not benefit much, if at all, from switching to a 64-bit computer, unless the program is a 64-bit program. A 32-bit processor is adequate for any application written for a 32-bit processor. In the case of computer games, you’ll get a lot more performance by upgrading the video card instead.
64-bit processors have been available for almost twenty years and EFI motherboards since nearly ten. We build Nitrux for the present and the future, not for the past. If you are running a 32-bit computer, we strongly recommend using other Linux or BSD distributions that focus on supporting this type of hardware.
Will Nitrux support MBR storage devices for initialization?
You can plugin MBR storage devices to Nitrux without a problem and utilize them, however, when we refer to Nitrux not supporting MBR devices we are explicitly talking about the storage device that is intended to be used with znx.
znx only supports GPT drives, when znx initializes a new device it creates a new partition table utilizing the GUID Partition Table and then creates the ESP and the data partition.
Unlike MBR partitioned disks, data critical to platform operation is located in partitions instead of unpartitioned or hidden sectors. Also, GPT partitioned disks have redundant primary and backup partition tables for improved partition data structure integrity.
Though UEFI supports the traditional master boot record (MBR) method of hard drive partitioning, it doesn’t stop there. It’s also capable of working with the GUID Partition Table (GPT), which is free of the limitations the MBR places on the number and size of partitions.
MBR-based partition table schemes insert the partitioning information for (usually) four “primary” partitions in the master boot record (MBR) (which on a BIOS system is also the container for code that begins the process of booting the system). In a GPT, the first sector of the disk is reserved for a “protective MBR” such that booting a BIOS-based computer from a GPT disk is supported, but the boot loader and O/S must both be GPT-aware. Regardless of the sector size, the GPT header begins on the second logical block of the device.
GPT uses current logical block addressing (LBA) in place of the cylinder-head-sector (CHS) addressing used with MBR. Legacy MBR information is contained in LBA 0, the GPT header is in LBA 1, and the partition table itself follows.
In summary, no, Nitrux will not support MBR storage devices for initialization.
Why does Nitrux not support Legacy BIOS and only support UEFI or EFI?
The lack of support for Legacy BIOS devices is a decision that we made based on what kind of features we wanted to add to our Linux distribution and the sort of hardware that we wanted to support for these features to work. The availability of EFI and subsequently UEFI devices has been mainstream for the past ten years, meaning that any future hardware that vendors release to the public will support UEFI exclusively and not Legacy BIOS.
As we explain further in this FAQ, it all comes down to how our distribution works; its management method and the features that we include which either make use of or depend on the hardware to support the use of EFI or UEFI firmware and the characteristics that either of these brings.
We are knowledgeable of hardware that would otherwise run this operating system without a problem but is otherwise unsupported because it did not include EFI firmware at least. Our decision is technical in that the limitations of Legacy BIOS did not allow for the support of our intended features in our Linux distribution to be feasible.
Other reasons why we decided to support only UEFI devices are the following:
- UEFI enables better use of bigger hard drives. Though UEFI supports the traditional master boot record (MBR) method of hard drive partitioning, it doesn’t stop there. It’s also capable of working with the GUID Partition Table (GPT), which is free of the limitations the MBR places on the number and size of partitions. GPT ups the maximum partition size from 2.19TB to 9.4 zettabytes.
- UEFI may be faster than the BIOS. Various tweaks and optimizations in the UEFI may help your system boot more quickly it could before. For example: With UEFI you may not have to endure messages asking you to set up hardware functions (such as a RAID controller) unless your direct input is required, and UEFI can choose to initialize only individual components. The degree to which a boot is sped up will depend on your system configuration and hardware so that you may see a significant or a minor speed increase.
- Technical changes abound in UEFI. UEFI has room for more useful and usable features than could ever be crammed into the BIOS. Among these are cryptography, network authentication, support for extensions stored on non-volatile media, an integrated boot manager, and even a shell environment for running other EFI applications such as diagnostic utilities or flash updates. Also, both the architecture and the drivers are CPU-independent, which opens the door to a wider variety of processors (including those using the ARM architecture, for example).
UEFI is the newer name and latest development of EFI.
What is NX Desktop? (previously Nomad Desktop)
Nitrux received many comments for creating yet another desktop environment instead of contributing to more extensive and established projects or worse that we have forked Plasma 5, unbeknownst to some people NX Desktop is NOT a desktop environment and we never have, once, referred to NX Desktop as such. This misunderstanding was caused by our use of the word Desktop in its name which is a tradition in many FOSS projects to apply to desktop shells.
What is NX Desktop and what it isn’t?
- What it is:NX Desktop is our set of applied customizations to the Plasma 5 Desktop and this includes new plasmoids (or widgets), a new look and feel package (wallpapers, Plasma themes, Konsole theme and profile, Aurorae themes, SDDM themes, cursors, and color schemes) an icon theme and initially two desktop applications, NX Software Center and Nomad Firewall, all of which is original work. The NX Software Center became its own thing, and Nomad Firewall is a KCM (KDE Control Module) which is not part of the plasmoids package or the look and feel package. The icon theme Lüv is also not part of the look-and-feel package.
- What it isn’t: NX Desktop is not a desktop environment. A desktop environment by concept would be a complete desktop shell and a suite of essential applications. These include a file manager, web browser, multimedia player, email client, address book, PDF reader, photo manager, and system preferences application. NX Desktop does not provide any of these which is why we have never referred to it as such.
- NX Desktop is not a fork or a derivative or a spin-off of Plasma Shell.
The Desktop suffix is because that’s where everything that comprises it is used, in the desktop. Contrary to what many people might think, we did not create a distribution around “just a bunch of themes.” Nitrux is about offering a user experience of our own that includes but it’s not limited to the artwork and the overall aesthetics, and our intention was never to provide a vanilla Plasma 5 Desktop. There are already sufficient Linux and BSD distributions that offer an unmodified Plasma 5 desktop experience.
Why focusing on AppImages?
An AppImage is a downloadable file for Linux that contains an application and everything the application needs to run (e.g., libraries, icons, fonts, translations, etc.) that cannot be reasonably expected to be part of each target system. — AppImage wiki.
Nitrux is a desktop Linux distribution meant to be used in desktop computers (that includes laptops et al.). Based on this, AppImage is the format that most adequately befits our vision. It is truly portable, doesn’t require anything else to run, and it is aimed at desktop computing. AppImage provides a very innovative and simplistic solution to software distribution. It is abundantly clear that a one-click solution to obtain software would be instantly accessible to anyone. That is not to say that package managers aren’t smart (or powerful!) when resolving conflicts but it’s not the same to manage a dozen if not hundreds of files to handle only one.
To be noted is that the AppImage format does not try to replace package managers but we want to make it our primary method of distribution for end-user software.
For this purpose, we have created a GUI software store and software to integrate AppImage files to the desktop environment. Also, we have included proper tools designed by the AppImage developers such as appimaged and AppImageUpdate. These tools are entirely independent of the Linux distribution where they are running and are also independent of each other. The mobile segment proved that this unprecedented simplicity was vital for people to obtain new software let alone actually using it, why limiting that simplicity to our phones?.
We firmly believe in the idea behind AppImages where an application is not installed but instead deployed, and this idea is from where we have created znx, our operating system manager.
What is znx?
znx is a tool that lets you use multiple operating systems and keep them updated without having to repartition the drives. It’s all about simplicity and reliability.
It’s designed to work on UEFI systems. znx will create a GPT partition table on a device and write a bootloader into the EFI System Partition. From that moment, you can deploy, update and remove operating systems as single-file ISO images. The bootloader (GRUB2) will make them available on boot. znx will help you keep them updated while making the update process safe.
znx deploys the ISO image into the storage device, then makes the device bootable and creates the data partition where the user data is kept across reboots. Once that the ISO has been deployed the user can restart and boot into the storage device to select the system.
znx follows the concept of AppImages which is that software isn’t “installed,” but it is instead deployed. That means that you don’t get lots of files and folders spread in a filesystem but just one file, same with znx, instead of unpacking the squashfs file (the compressed filesystem that holds the actual OS) and extracting the contents to the target device (thus “installing” the OS the traditional way). The OS remains as one file which can be updated using a zsync file for differential updates (so-called delta updates which is what znx does, similarly, AppImageUpdate performs updates to AppImages only updating the bits that changed).
Any file that the user creates is kept in the data partition in /data. To install new software (by the software we mean desktop applications like Firefox, LibreOffice, etc.) the go-to method is to download an AppImage. These AppImages would go in /Applications where they would be kept when the user updates the deployed ISO to a new version.
znx is a significant overhaul in Nitrux and together with the improved AppImage integration and our UI framework Mauikit forms the basis of what makes this distribution Nitrux and not Ubuntu.
znx supports both local ISO files and remote URLs.
What is the difference between installing and deploying in Nitrux?
In the context of utilizing Nitrux, we differ from conventional Linux distributions. Typically, when the user installs software, this is done with the use of a package manager. In general terms, the package manager will download and extract the contents of an archive and will place these contents inside the directory structure of the distribution in question. The archive contains files and folders that are placed in the corresponding path in the filesystem (the binaries in /bin, the configuration files to /etc, libraries to /lib and so on), and the package manager keeps track of where these files are located.
This concept is the same when an operating system is installed. Conventional Linux distributions are distributed as ISO files and make use of an installer. The installer will launch from a “Live” session and will extract the contents of the SquashFS file contained in the ISO file and place its contents on the storage device, creating the directory tree. Nitrux does not do this.
Deploying the operating system in our case means that you are “copying” the ISO file to the storage device as a single file and enabling persistence on the storage device using OverlayFS instead of extracting its contents and creating the standard directory tree on the storage device, this is why we refer to say that Nitrux does not do a traditional install.
In other words, Nitrux does a frugal installation (the operating system files are stored in just a couple of files in a directory, rather than spread out over a drive partition.).
When you install a conventional Linux distribution, your storage device will contain a directory tree like this: /boot /bin /dev /lib /usr /opt /var and so on, each of these directories with files and more folders on as many partitions as you created during installation.
With Nitrux you only have two partitions, a boot partition with the ESP and a data partition with the ISO file (containing the operating system) and the user folders, so the directory tree in your storage device is comprised of only /boot and /data.
znx utilizes it, but what is the OverlayFS?
OverlayFS provides a great way to merge directories or filesystems such that one of the filesystems (called the “lower” one) never gets written to, but all changes are made to the “upper” one. Brought into the Linux kernel mainline with version 3.18, OverlayFS allows you to overlay the contents (both files and directories) of one directory onto another.
The source directories can be on different volumes and can even be different file systems, which creates an exciting mechanism for allowing temporary modification of read-only files and folders, this also allows you to quickly add some storage to an existing filesystem that is running out of space, without having to alter any structures. It could also be a useful component of a backup or snapshot system.
Modifications to files in the “upper” directory will take place as usual. Any modification to a file from the “lower” folder will create a copy in the upper directory, and that file will be the one modified, this leaves the base files untouched and available through direct access to the “lower” folder.
Interestingly, a second task could copy modified files from the “upper” folder to the “lower” when modifications are complete.
A file removed from the OverlayFS directory would directly transfer a file from the “upper” directory, and simulate that removal from the “lower” directory by creating what is called a “whiteout” file. This file exists only within the OverlayFS directory, without physically appearing in either the “upper” or “lower” directories. When the OverlayFS is dismounted, this state information will be lost, so care should be taken to reflect any necessary changes to the “lower” directory.
A subdirectory can also be deleted from the “lower” directory, which creates what is known as an “opaque directory” in the OverlayFS directory. Behind the scenes, OverlayFS uses the “trusted” extended attribute class or namespace to record “whiteouts” and “opaque directories.”
So znx uses all the device, does that mean that I can’t use other operating systems but Nitrux?
You can entirely use other operating systems with znx, in fact, you can deploy other Linux distributions using it. znx is not exclusively a tool created as a whim from us to not use an installer. We developed znx to serve as a more straightforward approach to manage operating systems. As we have explained, znx is not an installer as it performs other tasks too.
We developed znx to use it with Nitrux, but it’s not exclusively made to work only with Nitrux. To deploy other Linux distributions using znx, the ISO file has to have a grub.cfg file and support for EFI, most distributions have this file, while others don’t, typically these distributions use ISOLINUX.
Does a Linux distribution, other than Nitrux, have persistence too when deployed using znx?
If you were to deploy an ISO file of a Linux distribution today with znx no, it wouldn’t have persistence; this is because the ISO file requires to be modified to make use of OverlayFS for the data to persist across reboots.
As we mention in this FAQ, we make use of OverlayFS to store data. We do this by modifying our ISO accordingly during its build process. This process isn’t complicated, and it’s supported directly by using Casper, the same tool that creates the SquashFS file that resides inside an ISO image.
All Linux distributions release their ISO files as installation media, so currently they are not built with this use in mind. However, it’s entirely possible to make these changes, just like we did.
Why can’t I “install” Nitrux using the ISO file when XYZ distribution “just works.”?
The most recurrent question is about our ISO and the apparent problem that new users of Nitrux have when writing it to a USB to install it. As indicated in the previous questions Nitrux isn’t Ubuntu, and this is a glaring example of this. Our ISO does not use the Master Boot Record partition table or MBR neither do we use SYSLINUX, and in turn, we do not use ISOLINUX, so our ISO is not a “hybrid-ISO.” There are no Live media, and therefore there’s no installation involved, the ISO file as we are distributing it is the actual operating system and should not be written raw to a USB device or any storage device. This characteristic of our ISO file is the primary reason why popular software to create Live USB drives of Linux distributions such as Rufus, Unetbootin, the command line utility dd, Etcher, etc. does not work.
Our ISO is a standard ISO-9660 bootable image. However, our ISO image uses the GUID partition table or GPT and directly uses GRUB2 to boot from the ESP or EFI System Partition. We only support booting from EFI and UEFI motherboards and not from the CSM or Compatibility Support Module or Legacy BIOS motherboards because of this, meaning that if you have enabled CSM in your UEFI to boot other systems, it must be disabled to boot Nitrux. Most Linux distributions already support UEFI boot.
To deploy Nitrux you need a Linux environment, and this is a must because of what znx needs to do, this can be either an existent Live USB of whatever Linux or an existent installation of whatever Linux, it doesn’t matter which one it is. The only requirement is to run an operating system where the AppImage can be executed, then proceed to download the AppImage of znx and follow the instructions at the Compendium.
Deploying Nitrux from an existing Linux (Live or already installed)
- Download the znx AppImage from https://github.com/Nitrux/znx/releases/download/continuous-stable/znx_stable
- Make it executable, open a Terminal window and run the following commands: chmod +x znx_stable and for clarity, rename the file, run: mv znx_stable znx alternatively use a file manager (right-click>properties>permissions.)
Since znx is a command line utility, all the steps below will be done on a Terminal window.
- First initialize a storage device running: sudo ./znx init /dev/sdX (where X is the device, do not enter a partition).
- Now deploy Nitrux, run: sudo ./znx deploy /dev/sdX nitrux/v1-1-2 $isopath
Depending on the speed of the storage device where the ISO is being deployed to it will take between 5-15 minutes or a couple of seconds in a virtual machine. During this time the command prompt will not be available, so it’s critical that the window where the command is running is not closed.
- After the command prompt is available once again make sure that the write cache is empty, run the command: sync
And that’s it you can begin to use Nitrux. If the ISO were deployed to a USB 2.0 device, it would take several minutes to load due to the limits of the transfer speed of these devices.
Subsequent deployments of Nitrux can be done using znx GUI from the Nitrux deployment. You can skip downloading the ISO altogether since the ISO would be already available from the device that Nitrux has booted from. The file is at /isodevice/boot_images.
Deploying Nitrux from Windows
Unfortunately for Windows users, the AppImage of znx does not run in WSL or Cygwin because neither can access the block devices in a computer and the kernel used by WSL does not have the FUSE module included which is a massive problem and one problem that znx cannot fix since it isn’t a problem of znx but a problem with Windows not being a POSIX system.
To summarize, we acknowledge that for Windows users this is not ideal as it requires adding two more steps to the process. If you are coming from Windows, please follow this workflow.
- Download a minimal conventional Linux distribution, for example, Fedora Server Net-install, Ubuntu Server or any other Linux distribution that you want; you need something where the AppImage can run and that it provides you of network access.
- Create a Live USB of that distribution and boot from it.
Please note that:
- You do not need to use a full desktop Linux system to complete the deployment at any point.
- You only need to meet two requirements: To run a Linux with FUSE included and have network access.
How can I burn the ISO to a DVD?
Please don’t write our ISO file to any optical media.
How can I flash the ISO to a USB?
Please don’t flash or write the ISO file raw to a USB or any other storage device. Deploy it using znx only.
How do I try Nitrux on a virtual machine?
The single best way to test Nitrux is to deploy it in real hardware, but maybe you don’t want to do that yet so your second best option is to use a virtual machine.
- Oracle VirtualBox. To use the ISO in VirtualBox all that you have to do is create a new virtual machine. Select Linux and Ubuntu (64-bit) after you have customized the rest of the settings for your virtual machine to boot the ISO check Enable EFI (special OSes only) under System and VBoxVGA under Graphics controller.
- VMware Workstation Pro 15 and Workstation Player 15. To use the ISO in VMware Workstation all that you have to do is create a new virtual machine. Select Linux and Other Linux 4.x or later kernel 64-bit. And just like with VirtualBox enable EFI, in this case, it would be UEFI. Select the UEFI checkbox under Firmware type in the Options tab in the virtual machine settings. For Workstation Player 15 add the following line to the vmx file of your virtual machine, firmware = “efi”.
- Parallels Desktop 13+. Following this article in the Parallels knowledge base, to enable EFI the boot flag must be set to vm.bios.efi=1 under Advanced Settings in the Boot Order category.
I deployed Nitrux using znx, but I get an error, “No Operating System” or “unknown filesystem.”
This problem is most likely because your hardware does not support EFI or UEFI boot. The UEFI specification describes the layout of an MBR partition table but does not mention the ESP.
It is theoretically possible to use the ESP on an MBR device. This method, however, is untested and it seems to produce more problems related to bootloader naming and NVRAM entries managed by efibootmgr. Furthermore, Intel plans to phase out support for the CSM by 2020. As such, we do not have any intention to spend resources on pursuing this method.
Also, EFI and subsequently UEFI motherboards have been available ca. 2010–2011 when Intel introduced its Nehalem architecture in 2008 and then when AMD launched its 800 chipset series in 2009 and later released it in 2010. These motherboards have been commonplace ever since, and this means that the kind of hardware that we are targeting is at least ten years old.
While rare there were EFI compatible motherboards for older platforms such as Socket 775 Intel processors.
I deployed Nitrux using znx, but I get an error, “Selected boot image did not Authenticate. Press Enter to Continue.”
Please make sure that Secure Boot and any other Windows-specific boot options in your UEFI settings are disabled.
I deployed Nitrux using znx, but I get an error, “Uncompression Error. System Halted” or “no bootable medium found.”
Please make sure that your motherboard supports UEFI or EFI. If you are running a VM make sure to enable EFI support.
I deployed Nitrux using znx, but I get an error, “Reboot and select a proper Boot device or Insert Boot Media in selected Boot device and press a key.”
Please make sure that your motherboard supports UEFI or EFI.
I have XYZ operating system installed on my computer, how can I dual-boot Nitrux?
While it is possible to dual-boot NItrux with other operating systems, there are some things to consider.
- Nitrux must be deployed using znx before any other operating system is installed on the computer.
- znx will create two partitions, the ESP and the Data partition.
- The included installers in most Linux and BSD distributions can do manual partitioning for their operating systems, during this phase the user can select the ESP that znx created and use it as mount point /boot/efi. The installer will add the EFI files for the operating system in question.
- During the manual partitioning phase of these installers, the user can shrink the Data partition that znx created to install the new operating system.
It is possible that the files in the ESP partition of znx are overwritten by the installer of the other operating system. We have confirmed that this is the case with the Ubiquity installer found in Ubuntu and its derivatives. By using znx, it is possible to deploy more Linux distributions the same way as Nitrux. However, like Nitrux other Linux distributions have to make use of OverlayFS in their ISO files to enable persistence.
For Windows users.
- If Windows is already installed in the computer and Nitrux is deployed to the same storage device, the storage device will be wiped.
- The Windows installer should be able to select the EFI system partition (ESP) automatically. However, it won’t be able to shrink the Data partition since Windows does not support BTRFS by default (this third-party driver adds some support for it), so to accommodate Windows in the Data partition that znx created the partition has to be resized before installing Windows.
- If Nitrux is deployed first, then the Data partition is resized, then Windows is installed on the remaining space, it’s very likely that access to Nitrux is lost. Windows is not Linux, Windows does not use GRUB so it can’t be deployed using znx and its ISO file is for installation and recovery only.
- In summary, to avoid any of these complications we recommend users to use separate storage devices.
I can’t find XYZ application in the software center, how can I add new software?
Some of the major software is already distributed as an AppImage, GIMP, Inkscape, LibreOffice, ONLYOFFICE, Blender, Krita, among others. The software center loads its listings from https://www.linux-apps.com. Alternatively, you can also download new AppImages from the web from sites like https://appimage.github.io or https://www.appimagehub.com/. Double-click the AppImage file to start the AppImage Desktop Integration utility.
Our Software Center was never designed with the intention to support anything else other than portable formats at first Snaps and then AppImages only. As mentioned before, the idea is not to use a package manager. However, we acknowledge that the software center should display a lot more results.
Providing AppImages is entirely up to the developer, so, if the software that you are looking for is not available as an AppImage ask its developer to provide one and it will be available in the SC. We do not store AppImages in a repository of our own.
How can I add new software that isn’t available as an AppImage to Nitrux?
The use of an AppImage by a developer to distribute their software allows them to target Linux as a whole instead of targeting a specific distribution. We emphasize the use of AppImages in Nitrux as it is a more straightforward way of managing end-user applications. However, not all developers make use of this packaging format, most software that is targeting Linux is distributed as packages created for package managers like APT, rpm, etc.
There are other instances where the developer releases the software as a TAR or ZIP compressed file; it is often the case that this software can directly be extracted to and doesn’t need to be installed using the distribution’s package manager. An example of this software is Android Studio and the itch.io game and assets storefront.
Other software is released as .run script files which depending on the software, allow you to select the installation path.
I updated Nitrux using the terminal but nothing changed?
As we have mentioned already, to manage the operating system, we use znx; this is normal and expected behavior.
I installed XYZ packages using the package manager, but after rebooting, they disappeared?
Nitrux is an immutable operating system; this is normal and expected behavior. To obtain new software, please use AppImages.
I created a new user in System Settings and enabled autologin, but it’s not working?
This issue occurs due to the way that Casper works out of the box and we’re working to provide a solution for this. As a workaround, press “E” after selecting the operating system in the znx boot menu, and use the arrow keys to navigate to the line marked user and hostname; here you can enter the username and the name of the computer after making the desired changes press “F10” to boot the operating system.
How long is Nitrux supported for?
Nitrux is a continuously evolving operating system, as such, we only support the latest version of the system, that is currently the 1.1.x series of releases.
Earlier versions of Nitrux such as the release candidate, Alpha 1 and 2, and the 1.0.x series of releases are not supported anymore.
Do I have to deploy Nitrux again after a new release is available?
No. Once you have deployed Nitrux to your storage device all you need to do is execute znx to update it. You only need to deploy the operating system once.
Source code and license of Nitrux
Nitrux is free software: you can redistribute it and modify it under the terms of the GNU General Public License (GPL) as published by the Free Software Foundation. Nitrux is distributed in the hope that it will be useful, but without any warranty; use at your own risk. The GNU GPL license requires that all source codes are published so others could reuse it, modify or learn from it.
© 2017-2019 Some Rights Reserved. Made with ♥ by Nitrux Latinoamericana S.C.
Any trademarks or logos used on this site are the property of their respective owners.