Repository navigation
MassOS Concepts
Concepts are interesting experimental mechanisms for installing and/or setting up MassOS. They aren't officially supported, but this article aims to document them in any case.
As the name suggests, we do NOT recommend using any concepts listed here as your primary installation. They may have instabilities or other unexpected issues. However you are encouraged to use them for testing and experimentation purposes.
This concept refers to creating a hybrid architecture installation of MassOS on a single drive - that is, one that can boot on both x86_64 and aarch64 systems, as an extension of the fully portable installation system, supporting Legacy BIOS, x86_64 UEFI, and aarch64 UEFI boot methods.
Since, for obvious reasons, you cannot have the same physical installation of MassOS be targetted at two different architectures, however the two separate installations can still be installed on the same drive by use of separate partitions. There can also be a shared /home partition for both installations, meaning personal data can be retained between both of the architecture installations.
The filesystem layout of this concept is as follows (assuming a 64GB disk with GPT partition table):
- Partition 1 - 1MiB - unformatted - BIOS boot partition - For x86_64 legacy BIOS bootloader installation.
- Partition 2 - 100MiB - vfat - EFI system partition - For x86_64 and aarch64 UEFI bootloader installation (both can be installed on the same ESP without conflicting).
- Partition 3 - 4GiB - swap - Shared swap partition - Because having a shareable partition is better than having separate swap files on both root filesystems.
- Partition 3 - 16GiB - ext4 - x86_64 root filesystem - For the x86_64 system installation.
- Partition 4 - 16GiB - ext4 - aarch64 root filesystem - For the aarch64 system installation.
- Partition 5 - 22GiB - ext4 - Shared home partition - For the shared home directory across both installations.
You can try out the concept image for yourself right now by downloading it from here - simply download the .img.xz file, and then decompress and write it to a 64GB or larger flash drive. Note that if you write it to a drive bigger than 64GB, you may wish to manually resize one or more of the partitions in order to fill the entire disk. After writing the image to a flash drive, you should be able to boot it on any system regardless of its architecture.
This concept refers to installing MassOS by using NTFS for the root filesystem, rather than using conventional GNU/Linux filesystems (such as ext4 or btrfs). This is possible as of Linux kernel version 7.1, as it contains a brand new read/write NTFS driver called NTFSPlus.
The hypothetical advantage of installing GNU/Linux on the NTFS filesystem is having native access to the root filesystem from within a (dual-booted) Windows installation, something which is not possible at all on ext4, and is somewhat difficult on btrfs. Additionally, there may be a (future) possibility of even installing GNU/Linux onto the same partition as a Windows installation - thus avoiding ever needing to repartition a drive when you wish to set up a dual-boot.
This, however, does not come without drawbacks. In particular, most GNU/Linux installations, including MassOS, contain filenames with characters that Windows doesn't support. While the NTFSPlus driver does support them, if the filesystem is later accessed from within Windows, Windows may either ignore such files on the drive, or even potentially choose to delete them (e.g. if chkdsk is run). As such, the general recommendation when using a root on NTFS installation is to avoid allowing Windows to ever have access to the drive. Whether or not you decide to allow it to have access, is down to you.
It should also be pointed out that, when accessing the drive from GNU/Linux, you should always try to mount it using the NTFSPlus driver, i.e. using the ntfs identifier, and NOT the older NTFS3 driver (which has the ntfs3 identifier). Using the latter will break symlinks because the older driver uses its own mechanism for storing symlinks, whereas the newer driver stores symlinks using the same mechanism as WSL under Windows.
Note also that, due to the GRUB bootloader's security policy, its inbuilt support for the NTFS filesystem is disabled when UEFI secure boot is enabled. As this is not something that can be (easily) worked around, the concept image contains a separate /boot partition, which is on FAT32 (a filesystem that is not locked down by GRUB under secure boot). The decision to use FAT32 for the boot partition as opposed to ext4 or btrfs, is because the point of the concept is to use only Windows native filesystems. This would obviously not be possible if part of the installation was still on ext4 or btrfs.
You can try out the concept image for yourself right now by downloading it from here - simply download the .img.xz file, and then decompress and write it to a 32GB or larger flash drive. Note that if you write it to a drive bigger than 32GB, you may wish to manually resize one or more of the partitions in order to fill the entire disk. After writing the image to a flash drive, you should be able to boot it in both Legacy BIOS or UEFI mode on any x86_64 system, and you should be able to access the drive from within Windows (though, as previously mentioned, the latter may be ill-advised).