Why fdisk & gparted disk types do not match?
 

/dev/sda1 (partition) output from fdisk:
gparted gui indicates a gpt disk.

Are not all partitions on a physical volume the same partition table format?

/dev/sda1 is a partition but you then mention disk label as in partition table or MBR. So in this you have two different things.

See what /dev/sda says.

Without seeing the output from fdisk it is not possible to understand the problem.

It is possible to create a table on a partition itself i.e. fdisk /dev/sdx1 that is separate from the entire drive i.e. fdisk /dev/sdx. You can find more then one thread on the site where the OP made the mistake.

Not sure how a hybrid would show up.

FDISK and GPARTED show different things because you have them POINTED to different things.

From what I can tell (with possibly inadequate information) your /dev/sda disk has a GPT/EFI table. IF it is a normal EFI format that means partition /dev/sda1 will be DOS/FAT format file system and /dev/sda2 will be some format of Linux partition. (most common is Linux(83) type which can contain almost any of the Linux filesystems. On my laptops usually EXT4 or BTRFS. )

You pointed GPARTED at the disk.
You pointed FDISK at the DOS partition.

I hope that makes the situation clear.

The output is clear, it is a GPT disk, but how MBR resides on GPT demands cognitive digestion.

It is as if a partition is just another disk. But if, say, an OS demands a GPT/UEFI setup, will it be the disk or partition complying with the standard?

I believe we basically are all saying the same thing. You specified the wrong device when running fdisk. Again it is possible to create a partition table within a partition itself like below. The drive itself is GPT and the partition table created within the first partition is MBR. While it is possible I don't know if can actually be used. Best to create a new filesystem.

Oh, it can be used, and really isn't all that uncommon. Consider a host partition that is used as a virtual disk by a VM. Viewed from the host, it's a partition that then begins with a partition table. While it's uncommon to dig into that partition structure from the host, you can do it if you play the right games with kpartx. While you can do that from a booted system, there's no way to make the BIOS dig into that partition, treat it like a drive, and boot from it, at least none that I know of. It can of course be used as the boot drive for a VM, but that doesn't help if the objective is to install an OS on the bare hardware.

That's what BSD does. I fooled about a bit with openbsd a couple of years ago and was amazed to find that it subdivided its partition and placed some kind of mbr or label at the beginning of it to handle the sub-partitions. This label also had entries for the other main partitions on the drive so that they could be mounted within the BSD system.

It must have booted in two stages. There was some kind of BSD bootloader on the partition, which could be accessed with GRUB or reFind but not with elilo.

Why fdisk & gparted disk types do not match?
 

The discrepancy between disk types in fdisk and gparted often occurs because they interpret disk types differently. fdisk typically categorizes disks based on their partition table type (e.g., MBR or GPT), while gparted categorizes disks based on their partitioning scheme (e.g., MBR, GPT, or unallocated space). This variation can lead to differences in the reported disk types between the two tools.

Yeah, but that was not the issue here.
He pointed one at the disk /dev/sda
and the other at the PARTITION /dev/sda1

The first disk on any modern SATA-based system is always referred to by the operating system a /dev/sda therefore the partition scheme of a primary HDD SDD under UNIX-Like operating systems counts up from the bared disk by orders of 1 for example the first partition on the first disk would be addressed as /dev/sda1 and the partitions would count up from that.