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

[RLynwood]

Swarzer Kater, yes, I recognize the Calamares name; I just couldn't remember it. I'll get to those modifications asap. I'm working on my general settings and trying to sync the tower computer with the laptop and transfer its files. Oh, and in attempting to install Mint in its partition (didn't), its installer showed the 1 MiB empty, unknown partition that 24.04's partitioning scheme builds into it. It's still there, just built into the ESP-creation code. I think someone said that earlier. In addition to those modifications, very early I want to run Swatzer Kater's de-snapping script.

[Qqmike]

I edited my last post: My ASUS laptop is 2014.

[Qqmike]

I have an ASUS laptop here, 2023, it is 2014, and it took 20.04 and 22.04 easily. ASUS does a good job implementing EFI/UEFI standards, IMO. I always use ASUS motherboards in my Desktop PC builds. And, yes, ASUS "BIOS" may use different wordings and menus re things like CSM. So, glad you got it ... Making progress!

[Schwarzer Kater]

Yes, it is the Calamares installer now, like it has already been for some time in Lubuntu.

Fine, so Kubuntu 24.04 LTS is sucessfully installed on your machine!

Then perhaps it is time to do some bug fixing and some optimizations for a desktop installation:
Essential and strongly recommended things to do directly after a Kubuntu 24.04 LTS installation

[RLynwood]

Well, so far, so good. At this point, it even looks like great news. My 2013 Asus mainboard definitely does have UEFI; no problem there. In its firmware, I set CSM to something a bit different than your two choices; it prioritized UEFI but allows BIOS. That allowed me to install 24.04 manually, first creating the partitions I wanted, which went with only a couple minor mistakes which I was alerted to & corrected, and then proceeded with the installation. It went easily, smoothly, and quickly, much quicker than all earlier installations. I was quite surprised at how quickly it finished. Everything appears to have worked perfectly. I must say, the devs greatly improved the installer--actually, I think it's a completely new one, and it made the installation MUCH easier (once I understood how to work it). Now I'm getting it all set up.

[Qqmike]

I have been under the impression that a PC built around 2011 or after should have UEFI.
As for configuring "BIOS," before installing Kubuntu:

BIOS/UEFI firmware menu:
CSM (compatibility support module): set to Auto (default). Or turn it OFF.
Disable Secure Boot; or on some ASUS, you can select: Change to “Other O/S”, which disables Secure Boot for the ASUS UEFI. Disable Fast Boot.

When working like this, it may be necessary to reboot more than once to 'get thing to take' just right.

[RLynwood]

Yes, that's what I want to do, but it didn't work when I tried it before. I'll try again.

[Schwarzer Kater]

Ok. My 11-yr-old mainboard wouldn't let me set to UEFI only, so I set it to UEFI first. That allowed me to boot. It or something else also got rid of the squirrelly lines. But KPM still shows only that one partition labeled /dev/sda1 ext4 spanning the entire SSD, 931 GiB. I guess this means that the system considers this installation to be a legacy device, right? […]

I suppose so…
Easier than starting the KDE Partition Manager each time could be to enter lsblk -e7 -f in Konsole.

You could try to force it by a simple manual partitioning with GPT as listed above = creating and pointing to /boot/efi and / - and see if this can change the outcome.

[RLynwood]

Ok. My 11-yr-old mainboard wouldn't let me set to UEFI only, so I set it to UEFI first. That allowed me to boot. It or something else also got rid of the squirrelly lines. But KPM still shows only that one partition labeled /dev/sda1 ext4 spanning the entire SSD, 931 GiB. I guess this means that the system considers this installation to be a legacy device, right? Also, I haven't seen how to set the time to 12-hour display. KPM's partitions dis\play is what's important now, though.

[Schwarzer Kater]

[…] First, the desktop is only barely readable. It looks like visual stuttering, no sharp, clear, line anywhere, only infinitesimally small, jagged lines. Who's brilliant idea is that?! Is that how the devs intend it to be?
[…]

Certainly not and you are the first one, at least I know of, to report something like this in Kubuntu 24.04 LTS.

Could be e.g.:
defective graphics drivers,
wrong graphics drivers,
missing graphics drivers,
wrong settings/refresh rate for your GPU or monitor,
wrong/defective monitor cable,
wrong/defective monitor adapter or
defective monitor itself.

Best to be checked from bottom to top.

[RLynwood]

I mistakenly wrote "barely unreadable" but meant barely readable. Right: the file is listed as /dev/sda1. I think you are right again that I'll have to disable CSM, then reinstall. I'll do that, then post again. Finally, what about the unclear, fuzzy lines?

[Schwarzer Kater]

/dev/sda normally cannot be "the one" partition after a default installation with erasing the disk - it is the device itself.
For SATA devices afterwards it is either just /dev/sda1 for "legacy" BIOS or /dev/sda1 and /dev/sda2 for UEFI.
You will probably have to alter an UEFI setting (e.g. disable CSM or something similar) if you want to install with an EFI system partition…

A swap file is not shown in KDE Partition Manager, because it is a file and no partition.
You can check this with e.g. cat /etc/fstab or sudo swapon --show .


Manual partitioning for Kubuntu 24.04 LTS - the most basic version for an UEFI system with an SATA device and its controller set to AHCI in UEFI (doesn't matter if HDD or SSD or mSATA-NVMe):

Partition table: GPT

• /dev/sda1
  size: 304MB or more (but why more?)
  file system type: FAT32
  mount point: /boot/efi
  partition type: EFI system partition
  flag: boot (or boot/esp depending on the tool)
• /dev/sda2
  size: rest
  file system type: ext4, Btrfs or whatever you like and is able to boot a Linux system
  mount point: /
  partition type: Linux file system partition
  flag: none

[RLynwood]

jglen490's display looks good, appropriate to me. But--shriek! I just installed 24.04 on a 1 T SSD, whole disk, standard. First, the desktop is only barely unreadable. It looks like visual stuttering, no sharp, clear, line anywhere, only infinitesimally small, jagged lines. Who's brilliant idea is that?! Is that how the devs intend it to be?
Second, wanting to see how the default installation set its partitions, I used KPM to look at the SSD. Again, apart from hardly being able to read it, there was only one--1!--partition, no EFI partition, no swap file, just the one, whole-disk partition labeled /debl/sda, gpt, ext4.
I can see that the devs have striven to make installation as dead simple as possible, with the fewest choices, but it looks like they've gone a step or two too far.
I also tried a manual installation. That didn't work either. Now, after I digest all responses to this, I expect to attempt again to install it manually.
What do you all say?

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

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