The following table describes the maximum file size and maximum file system size for the Btrfs, Ext4, and XFS file systems. File system limitations are affected by kernel versions and features, and by the architecture of the system on which Oracle Linux is installed. The values depicted here are estimates based on the known variables that might affect the maximum theoretical value that can be achieved. The theoretical values might be higher than those depicted here, and the actual achievable values might be lower than the values shown, depending on the hardware and the kernel version that is used.

The limits for the ext4 file system that are described here are higher than those recommended and might prove unstable. If you plan to work with systems where you are intend to work toward using higher file system sizes or file sizes, it is recommended that you use either the BTRFS or XFS file system.

The maximum supported size for a bootable logical unit number (LUN) is 50 TB. GPT and UEFI support are required for LUNs that are larger than 2 TB.

The maximum size of the address space that is available to each process is 128 TB.

Oracle Linux 7.9 (aarch64) is engineered and tested for server-related usage only. Although packages for desktop and productivity features are built and provided, testing of these packages is limited and support for graphical mode packages is not provided in this update. You can install any of these packages on your platform, but some of these applications might not work or could have issues that are not documented here.

Oracle does not provide support for these packages and any assistance is community-based. If you choose to run a desktop environment or any desktop applications, direct your questions to the Oracle Linux for Arm community forum at https://community.oracle.com/tech/apps-infra/categories/oracle-linux-for-arm.

The following issues might be encountered during an Oracle Linux 7.9 (aarch64) installation.

You can use the btrfs-convert tool to convert an ext4 file system to btrfs. However, if the tool attempts to convert a file system that has not been created with a sector block size that matches the system default page size (which is set to 64 KB for the aarch64 platform), the resulting file system cannot be mounted. Note that this issue can occur if the original ext4 file system is not created by using the -b 65536 option to specify a 64 KB block size.

(Bug ID 28200561)

Manually loading shim binaries from the UEFI shell can fail in some scenarios, including the following cases, which are known to fail:

• FS0:\EFI\redhat\shimaa64.efi

• FS0:\EFI\redhat\> shimaa64.efi

FS0:\> \EFI\redhat\shimaa64.efi is known to work correctly.

This problem is limited to the manual execution of shim in the UEFI shell. Note that a standard installation is unaffected by this bug.

(Bug ID 27962691)

On systems that have multiple CPUs, the Kdump crash dump tools fail to create a vmcore-dmesg.txt file, which is created with the vmcore file.

This issue might result in the following segmentation fault:

...
kdump: saving to /sysroot//var/crash/127.0.0.1-2018-05-22-12:34:45/
kdump: saving vmcore-dmesg.txt
/lib/kdump-lib-initramfs.sh: line 118:   459 Segmentation fault      
$_dmesg_collector /proc/vmcore > ${_path}/vmcore-dmesg-incomplete.txt
kdump: saving vmcore-dmesg.txt failed
kdump: saving vmcore
Copying data                                      : [100.0 %] \          
eta: 0s
kdump: saving vmcore complete 

The issue is occurs because the log buffer that is dynamically allocated by the kernel (vmcore-dmesg) does not know how to access memory that is allocated in this way. This issue is typically triggered on systems with 64 or more CPUs, but has also been observed on a 32-core Ampere X-Gene 3 system.

As a workaround, you can retrieve the dmesg output manually by the running crash command against vmcore and then using the dmesg command in the crash shell.

(Bug IDs 28064675, 28670960)

The bluedevil-wizard, which is available in the bluedevil package, is unable to connect or locate Bluetooth devices and fails with a segmentation fault when run.

(Bug ID 27101618)

The dsktune command, which is included with the 389 Directory Server base package (389-ds-base), fails with the following error:

ERROR: This system does not support CMPXCHG16B instruction (cpuflag cx16).
nsslapd-enable-nunc-stans must be set to "off" on this system.
In a future release of Directory Server this platform will NOT be
supported.

ERROR  : The above errors MUST be corrected before proceeding.

The message is notifying you that the system does not have support for cx16, which is a feature that is commonly available on the x86_64 platform.

The dsktune command checks that a system meets requirements and can provide helpful information pertaining to configuration; however, it is not required to run the 389 Directory Server.

(Bug ID 26861135)

The installation process for Oracle Linux 7.9 (aarch64) does not differ substantially from the installation process on the x86_64 platform. The same instructions and information that are provided in Oracle Linux 7: Installation Guide also apply to the 64-bit Arm (aarch64) platform.

The following is the recommended installation process:

1. Obtain the ISO image from the Oracle Technology Network (https://www.oracle.com/linux/).

2. Configure a network installation server to perform the installation.

3. Create a kickstart file to automate your installation.

4. Connect your target Arm hardware to the network and then configure the firmware to boot from the network or by performing a PXE boot.

   Refer to your hardware documentation for instructions.

5. Boot the target hardware and wait for the installation to complete.

For more information about configuring a network installation server and using a kickstart file to boot the installer, see Oracle Linux 7: Installation Guide.

The following exceptions and additional information might be required to complete the installation: