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

[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.

[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]

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"…

[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]

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]

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?

[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)

[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.

[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]

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.

[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).

[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]

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]

"So you already have a GPT, but it doesn't have any Protective MBR set up with it?" Using KDE Part. Mgr. in a Live USB of 23.10 (trying it), I clicked the "New Partition Table" button & applied it. The KPM shows the entire disk as Unallocated. Right-cicking on either image of the disk, then clicking on Properties, yields no mention of the partition table. Yet clicking on the Device button (tool bar), then on Properties, yields a different display that does say it is a GPT partition (& that the SMART status is Good). But there is no indication of a partition, just the entire band/bar that says Unallocated and gives its size. Oh, the upper band/bar, which is brown/gray, just says unallocated, but the blue colored line/bar in the table below says Partition: unallocated, Type: unknown. And it spans the entire disk.

Your next line makes it sound like that is my answer, but there is no protective partition, just the entire disk bar in display and size. So it looks like I'm not doing something or doing something wrong. Any suggestion?

[Qqmike]

The Protective MBR is an original feature of a GPT, and its purpose is as stated in the Wikipedia article.
Trying to reason this out now ...
So you already have a GPT, but it doesn't have any Protective MBR set up with it?
You can see why I'm asking: The Protective MBR should be created and coded (filled in) by the software that created the GPT in the first place.
I mean, otherwise, how would you create a 512B partition -- at the start of the disk -- to be the Protective MBR AND fill it in with the proper code to show that disk is full (to prevent MBR-aware software from trying to write to that disk)?
Unless you know how to write that code into an empty MBR ...
(I admit I didn't read this entire thread.)

Only other off-the-cuff thought I have is this: Has Rod Smith addressed anything about the Protective MBR on his website (which is, I believe, the original and most complete website on UEFI/GPT).