[LL-user]

@Şerban

I tried to send you a private message via the link in your profile. It's not working (user unknown). Also searching for you in a new compose window doesn't succeed?


EDIT: Issue has been solved thanks to Jerry!

[valtam]

I've investigated. Here's what's happening — and it's not a bug in our config, it's the classic UEFI-firmware-meets-MBR-disk dead-end in upstream Calamares.

What you're actually hitting:

1. "It only shows /dev/sda, not /dev/sda1" — that's by design, not the bug you think. On the Manual partitioning page, the top combobox lists whole disks (/dev/sda), never partitions. The partitions (sda1, sda2…) are supposed to appear in the table/bar view below the combobox, where you click a row to assign a mount point and flags. So "only /dev/sda in the dropdown" is normal. The combobox is not failing to update — it was never meant to hold sda1.

2. The real blocker: the live ISO booted in UEFI mode, but the target disk has an MBR (msdos) table.

Our partition.conf has:

Code:

efiSystemPartition: "/boot/efi"

When Calamares detects /sys/firmware/efi (i.e. the machine booted UEFI), it hard-requires an EFI System Partition: a partition flagged esp, formatted FAT32, with mount point /boot/efi assigned inside Calamares. This requirement lives in upstream libcalamares (PartUtils::isEfiSystem() → "requires an EFI partition") — it is not configurable, and our fork (calamares-linuxlite) doesn't patch it.

Your /dev/sda1 is FAT32 with a GParted "boot" flag, on an msdos table. That is not an ESP:

  - The MBR "boot" flag ≠ the GPT esp flag Calamares looks for.
  - You also have to assign the /boot/efi mount point to that partition inside Calamares — setting the flag in GParted alone does nothing; Calamares "ignores it" exactly as they describe, then bounces them back to the previous step. Dead end.
 
Why no "boot from FAT32 / MBR mode" combobox exists: while booted under UEFI, Calamares has no BIOS-install code path at all. It will only ever install a GPT ESP. So the combobox they expected to switch to MBR/BIOS boot doesn't "fail to update" — it doesn't exist in UEFI mode by design.

The two ways forward:

- Easiest: reboot the LL installer in Legacy / CSM / BIOS mode (disable UEFI for the USB in firmware). Then /sys/firmware/efi is absent, Calamares does a BIOS install, honours the MBR "boot" flag on sda1, and the EFI requirement disappears entirely — their other data partitions stay intact.

- Or stay UEFI: the disk needs a GPT table with a real ESP (FAT32, esp flag) that they then assign /boot/efi to inside Calamares. On their existing MBR disk that means converting to GPT — riskier with data present.

Our side
 
There's nothing to fix in partition.conf or the settings package — the requirement is upstream and correct. The only thing we could improve is user-facing guidance, since this trips people repeatedly:

- The error message ("requires an EFI partition" → previous step) is a genuine upstream UX dead-end with no hint about Legacy-boot.

- We could add a line to the LL install docs / a slideshow note: "Manual install failing with 'requires an EFI partition'? Boot the installer in Legacy/BIOS mode to install to an MBR disk."

[Şerban S.]

I've investigated. Here's what's happening — and it's not a bug in our config, it's the classic UEFI-firmware-meets-MBR-disk dead-end in upstream Calamares.

What you're actually hitting:

1. "It only shows /dev/sda, not /dev/sda1" — that's by design, not the bug you think. On the Manual partitioning page, the top combobox lists whole disks (/dev/sda), never partitions. The partitions (sda1, sda2…) are supposed to appear in the table/bar view below the combobox, where you click a row to assign a mount point and flags. So "only /dev/sda in the dropdown" is normal. The combobox is not failing to update — it was never meant to hold sda1.

2. The real blocker: the live ISO booted in UEFI mode, but the target disk has an MBR (msdos) table.

Our partition.conf has:

Code:

efiSystemPartition: "/boot/efi"

When Calamares detects /sys/firmware/efi (i.e. the machine booted UEFI), it hard-requires an EFI System Partition: a partition flagged esp, formatted FAT32, with mount point /boot/efi assigned inside Calamares. This requirement lives in upstream libcalamares (PartUtils::isEfiSystem() → "requires an EFI partition") — it is not configurable, and our fork (calamares-linuxlite) doesn't patch it.

Your /dev/sda1 is FAT32 with a GParted "boot" flag, on an msdos table. That is not an ESP:

  - The MBR "boot" flag ≠ the GPT esp flag Calamares looks for.
  - You also have to assign the /boot/efi mount point to that partition inside Calamares — setting the flag in GParted alone does nothing; Calamares "ignores it" exactly as they describe, then bounces them back to the previous step. Dead end.
 
Why no "boot from FAT32 / MBR mode" combobox exists: while booted under UEFI, Calamares has no BIOS-install code path at all. It will only ever install a GPT ESP. So the combobox they expected to switch to MBR/BIOS boot doesn't "fail to update" — it doesn't exist in UEFI mode by design.

The two ways forward:

- Easiest: reboot the LL installer in Legacy / CSM / BIOS mode (disable UEFI for the USB in firmware). Then /sys/firmware/efi is absent, Calamares does a BIOS install, honours the MBR "boot" flag on sda1, and the EFI requirement disappears entirely — their other data partitions stay intact.

- Or stay UEFI: the disk needs a GPT table with a real ESP (FAT32, esp flag) that they then assign /boot/efi to inside Calamares. On their existing MBR disk that means converting to GPT — riskier with data present.

Our side
 
There's nothing to fix in partition.conf or the settings package — the requirement is upstream and correct. The only thing we could improve is user-facing guidance, since this trips people repeatedly:

- The error message ("requires an EFI partition" → previous step) is a genuine upstream UX dead-end with no hint about Legacy-boot.

- We could add a line to the LL install docs / a slideshow note: "Manual install failing with 'requires an EFI partition'? Boot the installer in Legacy/BIOS mode to install to an MBR disk."

Thanks for the details!

Trouble is that the disk is GPT. The FAT32 partition was made with GPartEd indeed, buit it is GPT since I needed more than one partition and MBR allows only four primaries and I wanted actually six, without "extended".
Besides that, I don't have the slightest idea on how to create an MSDOS and GPT partition table on the same disk. I even see it pointless, useless, given the differences.
As for the UEFI boot, I always booted the UEFI LL and never had trouble until today's release.
As an example, LL 7.x, worked fine (all versions).
Besides that, I guess your solution might work, because I have the option "Legacy" in the firmware, but I disabled it years ago.
As for the Calamares Partition Manager, it has bugs that were present long years before LL 8.0, since Red Hat 4.2 (over 14 years I guess) so I dont rely much on the upstream "insurances". That is in fact why I always used GPartEd. It is reliable!
I have serious doubts though regarding a working solution. I already tested the mountpoint thing. It adds the mount point on the screen, but writes nothing on the disk.
And there is another problem: Since the partition is GPT, the /dev/sda1 is also a GPT. How will it be recognized by the legacy path which will look for an MBR partition? I don't get it.

I guess the only way to pinpoint the glitch, is to install another Linux and see if it also fails. For the moment, I'm too busy studying the LL 8.0 to waste time testing this bug with another flavor. Maybe after I polish the current installation. I don't know, just saying...
The current release, has enough new things to keep me busy for weeks (if not months...).

How did I do it?

Well, I'm kinda taugh nut to crack so, I went on the hard path:
Install LL. 7.8 --> Update --> install 

Code:

sudo apt-get install lite-series-upgrade

Next, perform the series upgrade.

Here, I owe you a special mention:
The series upgrade code, works flawless (did this twice already, although it takes an endless time...) and what is even more astonishing, is that the "Upgrade Major" step was merged with "Update" so at the end of the process, I found myself in front of the message "Your system is up to date!". Nothing more to add or do. If I remember right, the 8.0 Installer says that there were (are) 144 updates available after running the Live OS.

As you can figure out, I installed on the same disk/machine that pushed me into failure with the 8.0 installer. Nothing changed. Same disk, same partitioning scheme, same flags.
So as far as I can see and understand, it is highly unlikely to be in any way your "missing something". It is simply the Calamares Partition Manager that inherits the bugs from version to version for many years.


The only workaround you can add eventually, would be a way to skip the Calamares' Partition Manager but as I see it, it's a heavy load task.
Maybe, in some future, you can add a substitute screen that will only identify the partitions and write only the mountpoints, since we are practically in the "expert mode". But again, it's just a funny idea.

Bottom line:
LL 8.0 is working, so far. Aside what I said above, I have no more feedback. I need time to tune the Os and then study the new modules.
Anyway, for now it works without any visible glitch so I asume it will go on working.

Best regards!

[valtam]

Thanks for the details!

Trouble is that the disk is GPT. The FAT32 partition was made with GPartEd indeed, buit it is GPT since I needed more than one partition and MBR allows only four primaries and I wanted actually six, without "extended".
Besides that, I don't have the slightest idea on how to create an MSDOS and GPT partition table on the same disk. I even see it pointless, useless, given the differences.
As for the UEFI boot, I always booted the UEFI LL and never had trouble until today's release.
As an example, LL 7.x, worked fine (all versions).
Besides that, I guess your solution might work, because I have the option "Legacy" in the firmware, but I disabled it years ago.
As for the Calamares Partition Manager, it has bugs that were present long years before LL 8.0, since Red Hat 4.2 (over 14 years I guess) so I dont rely much on the upstream "insurances". That is in fact why I always used GPartEd. It is reliable!
I have serious doubts though regarding a working solution. I already tested the mountpoint thing. It adds the mount point on the screen, but writes nothing on the disk.
And there is another problem: Since the partition is GPT, the /dev/sda1 is also a GPT. How will it be recognized by the legacy path which will look for an MBR partition? I don't get it.

I guess the only way to pinpoint the glitch, is to install another Linux and see if it also fails. For the moment, I'm too busy studying the LL 8.0 to waste time testing this bug with another flavor. Maybe after I polish the current installation. I don't know, just saying...
The current release, has enough new things to keep me busy for weeks (if not months...).

How did I do it?

Well, I'm kinda taugh nut to crack so, I went on the hard path:
Install LL. 7.8 --> Update --> install 

Code:

sudo apt-get install lite-series-upgrade

Next, perform the series upgrade.

Here, I owe you a special mention:
The series upgrade code, works flawless (did this twice already, although it takes an endless time...) and what is even more astonishing, is that the "Upgrade Major" step was merged with "Update" so at the end of the process, I found myself in front of the message "Your system is up to date!". Nothing more to add or do. If I remember right, the 8.0 Installer says that there were (are) 144 updates available after running the Live OS.

As you can figure out, I installed on the same disk/machine that pushed me into failure with the 8.0 installer. Nothing changed. Same disk, same partitioning scheme, same flags.
So as far as I can see and understand, it is highly unlikely to be in any way your "missing something". It is simply the Calamares Partition Manager that inherits the bugs from version to version for many years.


The only workaround you can add eventually, would be a way to skip the Calamares' Partition Manager but as I see it, it's a heavy load task.
Maybe, in some future, you can add a substitute screen that will only identify the partitions and write only the mountpoints, since we are practically in the "expert mode". But again, it's just a funny idea.

Bottom line:
LL 8.0 is working, so far. Aside what I said above, I have no more feedback. I need time to tune the Os and then study the new modules.
Anyway, for now it works without any visible glitch so I asume it will go on working.

Best regards!

Thanks for the detailed follow-up — and you've corrected me on an important point. Since your disk is GPT, ignore the Legacy/BIOS suggestion entirely; that only makes sense on an MBR disk and would need a bios_grub partition on GPT anyway. You're right to stay UEFI. So scratch that whole branch.

One thing worth clarifying: this is actually the first Linux Lite release built on Calamares — every 7.x version used a different installer (Ubiquity). So the fact that 7.x worked doesn't carry over, and this is new ground for us rather than an old inherited bug we're ignoring.

On a GPT/UEFI disk, the installer should accept your existing FAT32 partition as the EFI System Partition. The combination it's looking for is: the partition carries the esp flag (on GPT, parted treats boot and esp as the same flag, but the check is for the EFI-System type), it's FAT32, and inside the manual editor you assign its mount point to /boot/efi with "Format" left UNCHECKED — that keeps your other five partitions and their data completely untouched. If you set esp explicitly in GParted and then assign /boot/efi without formatting and it still bounces you with the EFI error, that's a genuine recognition bug and I'd very much like to capture it.
By the way, "it shows the mount point on screen but writes nothing to disk" is actually normal — Calamares stages every change and only writes them when you confirm at the final Install step, so the on-screen mount point is the plan, not a live write.

We've reviewed our code and here is the result in the interests of transparency:

/etc/calamares/modules/partition.conf (full, with comments) — the only place ESP behaviour is configured.
OEM variant — /etc/calamares-oem/modules/partition.conf is a symlink to the same file (-> /etc/calamares/modules/partition.conf), so OEM and normal installs share identical partition logic. No divergence to worry about.
Grepped every .conf for efi* keys — only the two below exist, plus the bootloader efiBootLoader: grub and a post-install grub.cfg copy. No hidden ESP knobs anywhere.

The two ESP-related keys we set:

Code:

efiSystemPartition: "/boot/efi"

Code:

efiSystemPartitionSize: 512M

efiSystemPartition: "/boot/efi" — just the mount point Calamares expects an ESP at. Standard, correct, matches bootloader.conf. Not a tightening.

efiSystemPartitionSize: 512M — this only governs the size when Calamares creates an ESP in erase/automatic mode. It is not applied as a minimum-size gate against an existing ESP in manual mode. (The key that would warn on a too-small existing ESP is the separate efiSystemPartitionRecommendedSize, which we don't set — so we don't even emit a size warning, let alone a block.)

The rest of the file (partitionLayout rootfs 100%, requiredStorageGiB, swap choices) only applies to erase/automatic mode and is never consulted during manual partitioning, so it can't be involved in your case at all.

Where the "requires an EFI partition" block actually lives:
The hard stop is upstream libcalamares, not our config. When booted UEFI (/sys/firmware/efi present), the partition page requires a partition that simultaneously:

-  carries the esp flag (EFI-System type), and
- is assigned the /boot/efi mount point inside Calamares.

There is no config key to relax or disable this requirement. Our partition.conf cannot turn it off — only a source patch to the fork could, and that's exactly the "messing up our Calamares" risk we want to avoid. So no change is the correct outcome.

Our config is exonerated. Your configuration failure is one of:

The existing FAT32 isn't presenting the esp flag to Calamares the way it expects (even though parted aliases boot↔esp on GPT, Calamares reads the partition type), or
He set the /boot/efi mount point but Calamares still didn't register it as satisfying the requirement → a genuine upstream recognition bug.

Either way it's not tunable in partition.conf. The only thing that pins it down is his /var/log/calamares/session.log from a failed run — that log states exactly which condition failed.

Bottom line

No code changed — correctly so. Our partitioning config is minimal, standard, and not the cause. The block is an upstream UEFI/ESP requirement we can't relax via config without patching (and risking) the installer.

And thank you for the kind words on the series upgrade — hearing that it ran flawlessly twice and dropped you straight onto "Your system is up to date" with the major upgrade folded into the update is exactly the experience we were aiming for. Glad 8.0 is keeping you busy in a good way.

[Şerban S.]

Thanks for the detailed follow-up — and you've corrected me on an important point. [...]

Glad I could help in any way.

[...]One thing worth clarifying: this is actually the first Linux Lite release built on Calamares — every 7.x version used a different installer (Ubiquity). So the fact that 7.x worked doesn't carry over, and this is new ground for us rather than an old inherited bug we're ignoring. [...]

Good to know!

[...]On a GPT/UEFI disk, the installer should accept your existing FAT32 partition as the EFI System Partition. The combination it's looking for is: the partition carries the esp flag (on GPT, parted treats boot and esp as the same flag, but the check is for the EFI-System type), it's FAT32, and inside the manual editor you assign its mount point to /boot/efi with "Format" left UNCHECKED — that keeps your other five partitions and their data completely untouched. If you set esp explicitly in GParted and then assign /boot/efi without formatting and it still bounces you with the EFI error, that's a genuine recognition bug and I'd very much like to capture it.[...]

This is exactly what blew my mind.
Yet, I still have to test the partitioning step where I set the mount point to /boot/efi inside GPartEd.
Question is:
Will the module read the layout correctly?

We've reviewed our code and here is the result in the interests of transparency:

/etc/calamares/modules/partition.conf (full, with comments) — the only place ESP behaviour is configured.
OEM variant — /etc/calamares-oem/modules/partition.conf is a symlink to the same file (-> /etc/calamares/modules/partition.conf), so OEM and normal installs share identical partition logic. No divergence to worry about.
Grepped every .conf for efi* keys — only the two below exist, plus the bootloader efiBootLoader: grub and a post-install grub.cfg copy. No hidden ESP knobs anywhere.

The two ESP-related keys we set:

Code:

efiSystemPartition: "/boot/efi"

Code:

efiSystemPartitionSize: 512M

efiSystemPartition: "/boot/efi" — just the mount point Calamares expects an ESP at. Standard, correct, matches bootloader.conf. Not a tightening.

efiSystemPartitionSize: 512M — this only governs the size when Calamares creates an ESP in erase/automatic mode. It is not applied as a minimum-size gate against an existing ESP in manual mode. (The key that would warn on a too-small existing ESP is the separate efiSystemPartitionRecommendedSize, which we don't set — so we don't even emit a size warning, let alone a block.)

The rest of the file (partitionLayout rootfs 100%, requiredStorageGiB, swap choices) only applies to erase/automatic mode and is never consulted during manual partitioning, so it can't be involved in your case at all.

Thanks for the detailed breakdown. Sadly, this is exactly what I suspected it happens. I admit though, I hoped for something easier to fix...

Where the "requires an EFI partition" block actually lives:
The hard stop is upstream libcalamares, not our config. When booted UEFI (/sys/firmware/efi present), the partition page requires a partition that simultaneously:

-  carries the esp flag (EFI-System type), and
- is assigned the /boot/efi mount point inside Calamares.

This is exactly what I suspected. The "read" procedure though, should pass some data to the installer. This is where the code cracks.

There is no config key to relax or disable this requirement. Our partition.conf cannot turn it off — only a source patch to the fork could, and that's exactly the "messing up our Calamares" risk we want to avoid. So no change is the correct outcome.

Our config is exonerated. Your configuration failure is one of:

This makes sense, so the choice left is the below mechanism:

The existing FAT32 isn't presenting the esp flag to Calamares the way it expects (even though parted aliases boot↔esp on GPT, Calamares reads the partition type),

This might be, but my senses tell me it's the next:

He set the /boot/efi mount point but Calamares still didn't register it as satisfying the requirement → a genuine upstream recognition bug.

I belive this is exactly what happens.
Now the only way to catch the glitch, is to do the same partitioning scheme with GPartEd AND set the flag for /dev/sda1 inside GPartEd.
Logic says this should fix the problem. If it doesn't, then the problem is the READ procedure inside the Partition Manager.

Either way it's not tunable in partition.conf. The only thing that pins it down is his /var/log/calamares/session.log from a failed run — that log states exactly which condition failed.

Thanks for the valuable conversation!
If the above solution works, then we have the solution for everybody that uses custom partitioning.
If it fails, at least we know that Calamares PM needs some patching.


Best regards!

[Şerban S.]

Problem solved.

Here is what I've done:
- Started GPartEd and FORMATTED the /dev/sda1 partition;
- Flagged it as boot/esp; 
- Booted into LL 8.0 ISO;
- Chose the "Manual partitioning";
- On the next screen, I set up the mount point to /boot/efi for /dev/sda1;
- Set up the other mount points for the rest of the partitions.

This time the installer showed the screen with the list of tasks to be performed. I accepted and the process started.
I used a different SSD so the OS was cleanly installed and that was clearly visible, because my /home partition on this disk has a different content than my current machine (namely: default OS setup for /home).
The only difference is that instead of a directory /home/ I have a partition, with the same content. No custom configurations, so it was easy to recognize.

What is sure is that the Calamares PM reads the contents of the /dev/sda1 and if there is any trace of a previous installation on it, it will prevent the writing of the mount point /boot/esp, even if on the interface looks like it was set. Hence, the error screen I encountered.

What I could not get is why it refused to recognize the partition even after formatting it and setting the mount point to /boot/efi.
This was supposed to work.
It is also possible that the installer wil work if all the partitioning is done entirely with the Calamares PM. I don't know, because I always had the drive prepartitioned and formatted with GPartEd.
Further more, I usually have lots of data on the other partitions and the only one I format, is the main (/). For all the rest, the only thing I need is set the mount points.
There are several possible scenarios though, but since I managed to install, I gave up testing all of them.

In the end, maybe it worths mentioning that I use a Ventoy disk as boot medium and it works great (tested already with 6.x, 7.x and now the 8.0 release). The only cave eat here is the long time required to write the large ISOs.

Thanks everyone for the support!

Thanks Jerry for the great "Series Upgrade" module that works wonderful, in spite of the difficult tasks it has to perform!
So far, I think 8.0 is the best release of all!

[valtam]

@Şerban S. you are very welcome. It's been an interesting journey for this PM scenario.
There's always something new to learn out there

Cause confirmed: Calamares silently rejects the ESP if /dev/sda1 carries any trace of a prior installation — the mount point looks set in the UI but never gets written. Fix was to format sda1 fresh in GParted + flag it boot/esp, then assign /boot/efi in Manual partitioning.

Fix: GParted → format /dev/sda1 fresh + flag boot/esp → boot ISO → Manual partitioning → assign /boot/efi to it → set the other mountpoints. Clean install, no issues.

Conclusion: Calamares silently swallowing the mountpoint instead of telling the user "this ESP looks used, format it" is the real UX trap here — but that's upstream libcalamares, not the fork.

Happy computing