How to create w/ KDE Part. Mgr. the initial, 1 mb unformatted partition that precedes the GRUB partition on a new SSD?

[Qqmike]

Any suggestion?

Well, I'm not sure! Let's see ...
I usually use GParted, but the KDE Partition Manager is supposed to be OK, also, according to people here.
So you used KPM to create a partition table (where, at some point in creating it, you selected a GPT type).
So now you have a GPT partition table set up (presumably).
But you haven't created any partitions yet. So, you will not see any partitions in the graphic or in the listing. Usually, the first partition most people create is the ESP, for example.
You won't see the Protective MBR because it is not a partition. It is 512 B at the start of that new disk, and it is setup by the GPT creator (KPM) according to GPT specs.
That Protective MBR has the correct code in it. I attached a graphic I found on the Internet.
Edit: I copied my first 512 B (in my UEFI/GPT system) here:

sudo dd if=/dev/sda count=1 | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001c0 02 00 ee ff ff ff 01 00 00 00 2f 60 38 3a 00 00 |........../`8:..|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
1+0 records in
1+0 records out
512 bytes copied, 1.5237e-05 s, 33.6 MB/s
00000200

[RLynwood]

First, thank you for staying with me on this! Second, I'm sorry to have to say that I don't understand any of your code printout. And, yes to all your assumptions.
Looking back over Fitzcarraldo's article, I see a distinction that I failed to note before. The 1 MiB distinct partition is called the MBR protective partition, and the other one is GPT's protective partition, only about 512 B. This one is built into a GUID partition, and I don't understand it. I even read--but I don't remember where and can't find it now--that ideally a GPT partitioned disk should have that 1 MiB protective MBR partition at the end of the disk, behind all other partitions, also.

However, using KPM to establish the partitions on the laptop I'm using and having had the same problem with it, I ignored the protective partition and established all the regular gpt partitions, and it works fine, of course. But when I call up KPM & look at this SSD, i see NO initial, 1 MiB protective partition, either at the beginning or the end. And I've always seen that partition displayed in the graphic (that's how I've known that it even exists).

"Usually, the first partition most people create is the ESP, for example." That's not been my experience. I've *always* seen the protective partition first (it's been displayed graphically as a partition, and it's been listed as being 1 MiB and unknown), then the ESP partition, etc. Again, that's how I've known about it.
"You won't see the Protective MBR because it is not a partition." See above. "It is 512 B at the start of that new disk, and it is setup by the GPT creator (KPM) according to GPT specs. That Protective MBR has the correct code in it."
Those specs apply to the GPT partitions, and I've read that. Still, I believe I've read that the preceding, 1 MiB unknown protective MBR partition should be there. And I don't know how to create it with the KDE Part. Mgr. (or GParted). I don't know how to use the command line to do this stuff.

I'm still trying to find the explanation I saw but don't remember where that explains the wisdom of using those 1 MiB protective MBR partitions.

[Qqmike]

The "1 MiB" thing:
Boy, I don't know what you read and now have in mind. There is the thing about 'optimal partition alignment' on a disk; and for that, the sources recommend starting the first partition at the 1 MiB position on the disk.
But, that consideration never mentions anything about a 1 MiB "protective partition," at least I have never seen it. If anyone knows about such a thing, it would be Rod Smith.

The hexdump of my protective MBR:
It is the output of this command, as you can see:
sudo dd if=/dev/sda count=1 | hexdump -C
I only provided it to show you what it looks like physically: a bunch of hexadecimal digits (base 16 numbers), placed within that 512 B Protective MBR of a GPT.
You can learn to read it, maybe Starman explains it, or a Google would probably give a tutorial source, but it is not necessary to do so. Unless you are a firmware coder, you would never need to read it or write it. Just accept that it is there to protect your GPT.

I can tell you quickly everything I know about this reference to "1 MiB" as a starting place for the 1st partition. Easy! I will copy some text from my how-to.
The how-to is here:
https://www.kubuntuforums.net/forum/...l=1#post498911

Some text that contains everything I know about GPT layout with respect to any 1 MiB considerations is this (copied from that how-to link I just gave you):

The picture to have in your mind ... [when comparing the old MBR system to the new GPT system] ...

-- MBR. This is easy:

Picture the first 512 bytes of your disk (HDD or USB). That's where the MBR goes. Then there's a gap. Then the first partition starts.

There may be a gap of 62 sectors (62 * 512 = 31,744 bytes, so the first partition starts after 32,256 bytes = 31,744+512 = 63 sectors). Or, the first partition may start at LBA 2048 = 1 MiB = 1,048,576 bytes, leaving a gap of 1,048,576 - 512 = 1,048,064 bytes. Or, the gap may be some other number of bytes. Stage 2 of the GRUB 2 bootloader (or other bootloaders) usually fits into this gap.

-- GPT. This is also easy, but flexible!

At the start of this article:
http://en.wikipedia.org/wiki/GUID_Partition_Table
on the right, is an excellent graphic of the GPT layout and scheme.

In the GPT scheme, space is still set aside for a traditional 512-byte MBR, at location LBA 0 (the first 512-byte sector of the disk); and it is called the "protective MBR." (If the GPT sector size is greater than 512 bytes, then there will be a gap after the MBR and before the Partition Table Header.)

Then, at the start of the GPT is the header, the Partition Table Header, starting at the second sector of the disk, or LBA 1.
And then comes the partition table, or "partition entry array," at LBA 2, containing the partition entries, one entry for each partition.
Then come the actual partitions on the disk.
The last sector of the disk (LBA -1) contains the secondary or backup Partition Table Header; and the sector preceding the last sector (LBA -2) contains the secondary or backup partition table.

The thing to note is that the sector size need not be 512 bytes; it can be anything.
And this: "The EFI stipulates a minimum of 16,384 bytes be reserved for the partition table array, so there are 128 partition entries reserved, each 128 bytes long."

--> Thus, you can have 128 partitions with a GPT setup.

If you know the sector size, you can always picture where you're at on the GPT disk. (By the way, of course, both the bootloader and the OS must be aware of the sector size used.)

The LBA 34 thing ...
For example, if the sector size is 512 bytes ...
... and if the partition table has a full 128 entires, each 128 bytes long, that's 16,384 bytes, or 32 sectors (each 512 bytes). Add 1 sector for the protective MBR and 1 sector for the Partition Table Header, you get 34 sectors (each 512 bytes). So LBA 34 (the 35th sector) would be the first available address for the start of the first partition (but for optimal partition alignment, you may choose a larger sector number for starting the first partition, such as the 1 MiB mark = 2048 sectors (each 512 bytes)).

BIOS Boot Partition

When using GPT with BIOS [traditional, Legacy BIOS], Stage 1 of GRUB 2, called boot.img will fit into the first 446 bytes of the protective MBR, but you need room for the second stage of GRUB 2, the core.img. With the GPT layout, there is no gap, no room, for core.img (in GPT, the Partition Table Header starts immediately after the 512-byte MBR). Thus, you need a BIOS Boot Partition for the core.img of GRUB 2.

Flag: Using the graphical GParted, create the BIOS Boot Partition, and set the flag on it as: bios_grub; using gdisk, it is of type EF02.

Size: Minimum size is 32 KiB, but most people are using 1 MiB (which also serves certain optimum partition-alignment goals--which, btw, these goals are also served by modern partitioning tools since about 2010).

Note that the BIOS Boot Partition does not have a filesystem on it; it only holds raw binary code (the core.img stage of GRUB 2).

[Qqmike]

Note to my post 34:

The only thing I have noticed -- and I didn't look into this in any detail -- is that the issue of "optimal partition alignment" seems to be important for Windows OSs. Thus, the reference to "start your first actual partition at the 1 MiB location" for optimal partition alignment [for Windows systems]. If this is true, and if it prevents problems with a Windows install, then in that sense, it is a 'protective' measure.

[Schwarzer Kater]

Qqmike: I think I remember that I have had this 1MB for partition allignment with Windows 7 systems and before (can't remember if "legacy" BIOS/MBR or/and UEFI/GPT, though) - but I have not seen it with Windows 10 or 11 anymore (at least not on the UEFI systems I have worked with)…

[Qqmike]

S-K: Yes, and apparently, since about 2010, partitioning tools are aware of such optimum partition-alignment goals, anyway. It doesn't seem to be an issue; and nothing I can find supports any kind of 'protective' 1 MiB full-blown special partition.

[claydoh]

and nothing I can find supports any kind of 'protective' 1 MiB full-blown special partition.

Same. This stuff is all **outside** the part of the drive that is visible and used for filesystems, partitions, and data.


I think the main place for confusion is that sometimes there simply is leftover space on some drives after partitioning on today's ginormous drives, as well as those instances with people using Legacy boot systems (a small, empty unpartitioned space is needed there)

[RLynwood]

Perhaps you're all right, but why then does 24.04 include it, beginning the drive with that 1 MiB protective MBR partition (see post #20 in this conversation)? Surely, being responsible for tens of millions of safe, secure, reliable installations, they know what they're doing. Or are you all suggesting that they put that in for those few who're installing in MBR-BIOS systems?

[Schwarzer Kater]

OT:

[…] Surely, being responsible for tens of millions of safe, secure, reliable installations, they know what they're doing. […]

Sorry, but I had to laugh out load. I think you are far too trusting.
Minimum of 300MB EFI partition? vm.swappiness of 60 for desktop installations? discard in Kubuntu 24.04's /etc/fstab for ext4? Not installing FileLight by default despite Dolphin uses it? Shipping an LTS version where Flatpak does not work properly in Discover (K 22.04 LTS without Backports Extra)? Not following a lot of KDE's Distributions/Packaging Recommendations? And I could go on…
No - "they" definitely don't know what "they" are doing.

And have you compared what Kubuntu's installer does to the ones from Red Hat Enterprise Linux or SUSE Linux Enterprise or Debian or even Ubuntu server? I am simply curious…
Those are responsible for a lot of reliable installations.

No offense!

[RLynwood]

No offense taken. After all, I'm merely a non-techie "desktop" user. I nearly totally depend on you experts to help with all my modifications (that I don't know how to do) and problems. I don't know what almost all of those examples are (I do recognize the Filelight reference and greatly your or whoever it was that told me to downlfoad it). Still, you didn't answer that post's essential question, except, I guess, by implying that their having included that partition was no evidence of their knowing what they were doing.

[Schwarzer Kater]

More or less OT:

Exactly what your last sentence says.
I honestly don't know the answer to your question - I just "stumbled in here" by chance.
(And I consider it too irrelevant for the perhaps 150 desktop Linux installations and the few servers I have done in the last couple of years, sorry…
If I had to deploy thousands or tens of thousands of workstations and servers I would certainly be a bit more interested and would invest some "academic" time to find out.)

Don't misunderstand my last post - I like Kubuntu, otherwise I would not use it or install it for other people from time to time.
I just don't think it is the "holy grail"…

[claydoh]

Perhaps you're all right, but why then does 24.04 include it, beginning the drive with that 1 MiB protective MBR partition (see post #20 in this conversation)?

The image in question - /dev/vdaindicates a virtual machine, and that the software (Virtualbox, Vmware, or whatever) is using a Legacy bios as the defualt emulation, not EFI, like 95% of real-world installs would.
As I mentioned in post 21.
This empty space is needed by grub in this situation. Installers (and probably partitioning tools maybe) will leave that space, if/when it is actually needed.

The "protective MBR" is something completely different, and isn't a partition, just like an actual MBR isn't. As in you don't see it.

YOU DO NOT NEED TO MAKE that 1Mb of empty space ON AN EFI SYSTEM
if you really want it, just leave 1Mb of free space at the beginning. Shrink you main partition by 1Mb, slide the EFI partition over by that 1Mb and yer done.
If the installer needed it , it will complain, just like if you forgot an EFI partition, or if that were too small.

BUT YOU DON'T NEED IT on your EFI setup!

[Schwarzer Kater]

Without having paid attention in detail to this any further (like I said above): claydoh's explanation is the most logical and reasonable one.

[Qqmike]

Claydoh's posts are very good here, posts 21 and 43, and they hold the key:
If you have any need for a BIOS boot partition (e.g., running EFI in Legacy emulation or wrt a virtual machine), then you DO need that 1 MiB BIOS boot partition to hold Stage 2 of GRUB. But it is not in any way acting as a "protective partition."
(In this case, my post 34 explains in detail how that BIOS boot partition fits into your GPT disk arrangement and why you need it if you wish to boot by Legacy GRUB (as opposed to booting by EFI).)

The only "protection" offered by a GPT/UEFI setup, comes from, as we have said above, that Protective MBR of 512 bytes -- it ensures that some software that tries to overwrite your GPT with Legacy GRUB code will surely fail (because it will be fooled by that Protective MBR which indicates, in its code, that the disk is full, or some such thing).

[jglen490]

I always use the "manual" install procedures in the Kubuntu installer. The first partition is always (at least since using UEFI) the EFI partition. It always wants empty space at the beginning of the disk. This is how my disk looks in lsblk and in fdisk:

ohn@John-HP-ENVY:~$ sudo fdisk -l
[sudo] password for john:
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO Plus 1TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CCF88799-68FE-44FF-BF32-D3A771D7E807

Device Start End Sectors SizeType
/dev/nvme0n1p1 2048 206847 204800 100M EFI System
/dev/nvme0n1p2 206848 102606847 102400000 48.8G Linux filesystem
/dev/nvme0n1p3 102606848 1919182847 1816576000 866.2G Linux filesystem
/dev/nvme0n1p4 1919182848 1953523711 34340864 16.4G Linux swap
john@John-HP-ENVY:~$ lsblk -T --output NAME,FSTYPE,LABEL,UUID,SIZE,FSAVAIL,MOUNTPOINTS
NAME FSTYPE LABEL UUID SIZE FSAVAIL MOUNTPOINTS
nvme0n1 931.5G
├─nvme0n1p1 vfat C309-DC20 100M 92.4M /boot/efi
├─nvme0n1p2 ext4 43f7aabd-aa47-4eef-b4f4-d49cbef8b875 48.8G 31.8G /
├─nvme0n1p3 ext4 870436af-1189-421f-8240-e35613dba718 866.2G 489.7G /home
└─nvme0n1p4 swap 4bfd3cbc-efd5-48cd-ba39-6c4186543565 16.4G [SWAP]
john@John-HP-ENVY:~$

Never had an issue with empty space and 2048 is too insignificant to bother with. Another fine example of don't worry, be happy. And looking forward to 24.04 LTS sometime today!