[Bug]: armbian-install creates msdos/MBR partition table instead of GPT on empty 4TB NVMe during UEFI x86 install

[Jareika]

What happened?

Issue body

Problem description

When installing Armbian UEFI x86 to an empty 4TB NVMe drive using armbian-install, the installer automatically creates an msdos/MBR partition table instead of GPT.

This is problematic because the target disk is larger than 2 TiB, and MBR/msdos cannot properly address the full disk capacity on typical 512-byte sector devices. For an UEFI installation, I would expect the installer to create a GPT partition table with an EFI System Partition.

Image used

Armbian_26.2.6_Uefi-x86_trixie_current_6.18.26_minimal.img

Target device

Empty 4TB NVMe SSD

Example device:

/dev/nvme0n1
Installation method
Booted the Armbian UEFI x86 image and started:

sudo armbian-install
Then selected the NVMe drive as installation target and let the installer create the required partitions automatically.

Expected behavior
For UEFI installation, especially on a disk larger than 2 TiB, the installer should create a GPT partition table, for example:

Partition Table: gpt
or:

Disklabel type: gpt
Expected layout could be something like:

/dev/nvme0n1p1  EFI System Partition  FAT32
/dev/nvme0n1p2  Linux root filesystem  ext4/btrfs
Actual behavior
The installer creates an msdos/MBR partition table:

sudo parted /dev/nvme0n1 print
shows:

Partition Table: msdos
or:

sudo fdisk -l /dev/nvme0n1
shows:

Disklabel type: dos
Suspected cause
In the armbian-install script, the automatic partition creation path for UEFI appears to use fdisk without explicitly creating a GPT disklabel first.

The code path seems to do something similar to:

wipefs -aq /dev/$diskcheck

# create EFI partition
{ echo n; echo ; echo ; echo ; echo +200M; echo t; echo EF; echo w; } | fdisk /dev/$diskcheck

# create root partition
{ echo n; echo ; echo ; echo ; echo; echo w; } | fdisk /dev/$diskcheck
On an empty disk, fdisk defaults to creating a DOS/MBR disklabel unless GPT is explicitly selected with g, or unless another tool such as parted/sfdisk is used to create a GPT label first.

Suggested fix
For UEFI installs, and especially for target disks larger than 2 TiB, the installer should explicitly create a GPT partition table before creating partitions.

For example, the UEFI auto-partitioning path could use parted:

parted -s /dev/$diskcheck \
  mklabel gpt \
  mkpart EFI fat32 1MiB 201MiB \
  set 1 esp on \
  mkpart rootfs ext4 201MiB 100%
Alternatively, if continuing to use fdisk, the script should send g before creating the first partition:

{ echo g; echo n; echo ; echo ; echo ; echo +200M; echo t; echo 1; echo EF; echo w; } | fdisk /dev/$diskcheck
Workaround
Manually pre-partitioning the NVMe as GPT before running armbian-install works around the issue:

sudo wipefs -a /dev/nvme0n1
sudo sgdisk --zap-all /dev/nvme0n1

sudo parted -s /dev/nvme0n1 \
  mklabel gpt \
  mkpart EFI fat32 1MiB 512MiB \
  set 1 esp on \
  mkpart rootfs ext4 512MiB 100%

sudo mkfs.vfat -F32 -n EFI /dev/nvme0n1p1
sudo mkfs.ext4 -F -L rootfs /dev/nvme0n1p2
Then run:

sudo armbian-install
and select the existing root partition.

Additional notes
This issue is especially relevant for UEFI x86 images and large NVMe drives. Since Armbian provides an "Install system to UEFI disk" scenario, the automatic installer should probably default to GPT in this case.

### How to reproduce?

sudo armbian-install

### Branch

main (main development branch)

### On which host OS are you running the build script and observing this problem?

Debian 13 Trixie

### Are you building on Windows WSL2?

- [ ] Yes, my Ubuntu/Debian/OtherOS is running on WSL2

### Relevant log URL

_No response_

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct