Ubiquity is the default for Ubuntu, Trisquel, Mint…etc
It has advantages on what calamares provide:
- Support LVM which calamares lack.
- Support TPM-fde installation which calamares lack.
1 Like
Also ~ 2000 tickets.
https://bugs.launchpad.net/ubuntu/+source/ubiquity
In comparison. calamares has ~ 140 at time of writing.
I am not saying that one or the other has more bugs, that this is a useful comparison. This is just to say, that a port form calamares to Ubiquity is justified just because Ubiquity has some nicer features.
This is a hard engineering decision and would require a developer comparing the two. calamares might cause less effort because it’s used by default by Debian live.
Has also bugs:
https://answers.launchpad.net/ubuntu/+source/ubiquity/+bugs/?field.tag=lvm
LVM is not a priority at all.
I am reasonably technical person but even for me LVM is too much.
The bug reports against both installers calamares, ubiquity also discourages me to look further into LVM.
Also related, the fixed and unfixed list of Qubes LVM related issues. Specifically the (nowadays fixed) LVM bug in Qubes that has lead to data loss when the “LVM pool” (or disk?) was filled up (which could not be recovered from, at least most users could not).
As a challenge, try to boot from an external disk and then access your Qubes encrypted LVM on your internal hard drive for data recovery process. It’s possible but very difficult for users.
TPM in context of Full Disk Encryption (FDE) is also not a priority at all.
Using full disk encryption with a strong password is more secure than using a TPM. This is elaborated here, Full Disk Encryption, chapter TPM.
related: Community Feedback
The comparison has some missing parts:
- Ubiquity released in 2006 (18 years ago), Calamares in 2015 (9 years ago)
- Ubiquity is wider in usage, is the default installer for many and very famous distros (Ubunut, Mint…etc), Calamares is less in usage and distros which use it as a default installer are counted on less than the hand fingers.
- Reliability of bug counts in Ubiquity ticketing system is unreliable e.g This ticket is fixed yet it still shown on the main page as " *1 Open CVE bug".
- Another thing to take care of is that “Open bugs” mean how many bugs are opened in the ticket system, “New Bugs” which mean that they are still unfixed bugs (called triaged/untriaged in their ticketing system).
Conclusion: Based on the age and usage, this comparison has a neglected/no effect.
Everything has bugs but when it occurs/how much its usable is the question. by checking the bugs they are just uncommon/user specific use cases (4 bugs only).
Calamares on the other hand, their developers are just not well educated on how to implement LVM, to the level one opened a ticket to remove it because its just not working.
This shows the difference on who has better high tech work.
Unrelated, as Qubes uses LVM by default (has 9 bugs only).
With server level or highly storage use cases, LVM is like a must to be available for ease and flexible for storage capacity scale (unless ditching server support).
The discussion is not about being used as a default method or how much its useful, but as a choice to the user, is it even available or not (specially in comparison to the upstream debian).
One last thing i want to mention about Ubiquity, its written in python whereas Calamares written in C++.
Ubiquity was developed by Canonical as part of Ubuntu, and is now all but abandoned upstream. It was replaced by ubuntu-desktop-provision, which is Snap-based, GTK-centric, and written in Flutter. Given that it is now abandonware, I don’t think it would be in our best interest to use it.
1 Like
Some more detail since just “it’s no longer developed” may not be a satisfactory answer (after all forks are possible):
There are actually a very sizable number of distros that use Calamares as the default installer:
- Kubuntu
- Lubuntu
- Ubuntu Unity
- KaOS
- Fedora Asahi Remix
- Debian Live
- Xebian
- KDE neon
- I think Artix Linux?
- And of course Kicksecure
- Ubuntu Studio previously used it but migrated to ubuntu-desktop-provision
So it has quite a bit of usage, and there’s almost certainly some distros I’ve missed or haven’t seen yet that use it.
Ubiquity is rather Ubuntu-centric. I have only ever seen it used as the default installer for Ubuntu derivatives (whether those be official flavors like Ubuntu MATE or unofficial spinoffs like Mint, Trisquel, KXStudio, ChaletOS, etc). From having tried to work with its code, it is not fun to work with and those I know who have worked on it professionally were… less than thrilled. Even before it was finally deprecated it was being called outdated and bitrotten. Given it’s Ubuntu-centric nature, it may not be something that even can be used on other distros, though granted I haven’t looked into its internals closely enough to know for sure.
The LVM stuff in Calamares stinks, that is very true. Why, I don’t exactly know, maybe it’s because libkpmcore (which Calamares relies on for its partitioning work) is broken? However, I have worked on Calamares’ code upstream and it is very approachable. It’s mostly written in Qt/C++ which is a relatively friendly environment to work with, and some of it is written in Python which is even more friendly. So if LVM were to become a priority, it’s something I believe would be possible to fix. TPM-based FDE also is likely doable, depending on how exactly that’s being done in Ubuntu (though as Patrick mentions use of the TPM has worrying security issues that may make it not worth it or not a priority).
2 Likes
Did you ever use LVM or are you theorizing? Did you accept my challenge:
It’s not about the number of bugs (quantity). It’s about the “quality” (severity, complexity, impact) of the bugs. For example this bug bug where the system simply stops booting looks very scary: Boot fails at "lvm event activation" · Issue #7877 · QubesOS/qubes-issues · GitHub
And it wasn’t reported from a non-technical person. It was reported by unman, a Qubes developer. So nobody else any idea how to fix it. Nobody commented since November 2022. That is to show the level of difficulty introduced by LVM. If there is a bug, then nobody has any clue how to fix it or even knows a workaround.
Default or non-default doesn’t even matter. It doesn’t change what I said:
TPM in context of Full Disk Encryption (FDE) is also not a priority at all.
Using full disk encryption with a strong password is more secure than using a TPM. This is elaborated here, Full Disk Encryption, chapter TPM.
In this context, it seems hard to add a TPM version because this would be difficult to communicate to the user.
“If you wish to use a less secure password and take your chances using a TPM, choose this option. Otherwise, it would be more secure to use a secure password instead.”
Under these conditions it doesn’t seem motivating to develop the TPM support feature.
Note: TPM support probably doesn’t necessarily need to be part of the installer such as calamares. If a user wants to set it up, they can set it up. The user could either,
- A) add an additional cryptsetup keyslot that uses the TPM; or
- B) replace the cryptsetup password based keyslot with a TPM.
So whether calamares adds support for TPM or not doesn’t prevent the user from making use of a TPM for full disk encryption. TPM setup would be unspecific to Kicksecure and could be done as per Self Support First Policy for Kicksecure.
Not true. Calamares has a lot python and unfortunately some C modules.
Ubiquity also unfortunately seems to have some C. (example: mockresolver.c)
Also seems to have telemetry (reference: telemetry.py) which would need to be investigated what that is and potentially would need to be deactivated.
1 Like
Im not sure how did you come to this conclusion, ubuntu-desktop-provision is for post installation stuff, ubiquity is the one handling partitioning and initial setup (system installer) of ubuntu (or any distro using it).
ubuntu-desktop-provision: For configuring an OEM provisioning flow for Ubuntu 24.04.1 LTS, where user creation and account setup is handled seperately to system setup (reference).
Ubiquity just has a new commit 5 days ago.
Unless there is a genuine referral for ubiquity deprecation, ubiquity still the used system installer.
- Kubuntu = True
- Lubuntu = True
- Ubuntu Unity = False, its ubiquity (check)
- KaOS = True
- Fedora Asahi Remix = Neither, just a script (check)
- Debian Live = True, but not used for debian official installation method (uses d-i)
- Xebian = True
- KDE neon = True
- Artix Linux = True, but dont forget that upstream archlinux doesnt has a GUI installer to begin with, so its like nothing or calamares then ok calamares.
- Ubuntu Studio = Ubiquity + Ubuntu-desktop-provision (which will just give you the opportunity to add your own packages config in yaml file, similar to nixos .config declarative file).
and i know couple more as well, but tbh to my knowledge the full independent not a fork distros are lower than 5 distros like NixOS and similar.
Thats very true, ubiquity doesnt even exist as a package in debian, so one need to have it in his own repository.
Looking at the mess calamares development approach for LVM, i dont know, it sound like they have zero clue how to do it correctly, not sure it will ever see the sun.
Nice to hear, i see it doable as well, i hope it can be fixed as an possibility provided for the end users.
LVM is the default installation by qubes because it uses anaconda, and debian because it uses d-i (which i use both).
The challenge which you are proposing is a specific use case which i described above for ubiquity bugs, it doesnt provide any critical bug which LVM suffer VS no LVM.
Checking at what he said:
After succesful dom0 update , but before reboot, Qubes crashed while starting a new qube.
System not under load, and temperature not excessive.On starting again, boot fails, sitting at “lvm event activation”.
We cant just point out that this is crushed and not booting because oh there is LVM mentioned on the screen, real cause need to be identified then decided if its really LVM specific or not.
If it was generic use issue, many would have fallen under the same condition, including marmarek himself. Probably its just unman specific config issue.
Its just feature less installer compared to upstream debian, regardless of what TPM provide or use case going to be for the end user.
If user is trusting TPM or lets say there is (theoretically) going to be open source TPM provider or so, calamares is on a lack road to support this.
Its not like plainly as you describe it:
Ubiquity: 98.7% is python, makefile is 0.1%
Calamares: C++ 74.2%, Python 8.0%
mockresolver.c is just an optional for testing purposes tool as described. In simple comparison if someone want to get rid of every C possible in the installer, it will be easier for sure for ubiquity but not calamares.
Yeah it is a privacy thing, but not too much of a crazy collection because it give the option to disable it and it also anonymize the “partition method”:
def set_partition_method(self, method):
"""Record anynomized partition method"""
self._metrics['PartitionMethod'] = method
But whether its useful to kicksecure to keep or not thats different thing.
For context, I am an Ubuntu Developer, Aaron Rainbolt in Launchpad
Originally Ubiquity was replaced in Ubuntu Desktop with a Flutter-based installer. That installer was later converted into a more flexible “provisioning” system, the details of which can be found at From installation to provisioning - upgrading the Ubuntu Desktop installer - Desktop - Ubuntu Community Hub, That system is ubuntu-desktop-provision.
Ubiquity was nearly removed from the Ubuntu archives entirely in the 24.04 cycle, but was kept around because it is still used in some edge cases. Request to not remove Ubiquity from 24.04 - Desktop - Ubuntu Community Hub
The Git repo you link to with a commit 5 days ago is for Subiquity, which is a distinct and separate project from Ubiquity. It is used as the backend for ubuntu-desktop-provision and the Ubuntu Server installer.
I was actually the one who ported Ubuntu Unity to use Calamares as its installer, replacing Ubiquity. Here’s the package upload done to add Ubuntu Unity support to Ubuntu’s Calamares package, along with the Feature Freeze exception granted to allow this change to be done.
Subiquity, but otherwise mostly correct. Like I mentioned, Ubuntu Studio used to use Calamares, but no more. I was part of the conversation when the primary dev of Ubuntu Studio decided to switch. Initially the switch went from Calamares back to Ubiquity, then from Ubiquity to ubuntu-desktop-provision.
Yeah, it is messed up pretty badly. Again though, that could be libkpmcore’s fault, but that’s uncertain. Would have to look deeper at the code to find out.
1 Like
Yeah now i have collected and linked everything, although i have read that article before it didnt come to my mind the differentiation between subiquity and ubiquity
Ubiquity code on launchpad not on github, mint and others forked ubiquity code from launchpad and post it on github, but the one on github from ubuntu is subiquity.
ubiquity,subiquity… how is this not confusing 
Yeah discussion about ubiquity stops here, its crazy that no where to find they said it loudly that ubiquity is deprecated…
Thats very recently, the video i have sent you is before 2 years ago.
Thats nice if it could be figured out where is at least the cause of the problem.
Pleasure to meet you 
1 Like
If you cannot pass the challenge, you’re not really using LVM except for some transparent use in Qubes but no real user interaction.
Why argue for a feature which you’re actively making use yourself? Feature completeness?
No, feature completeness based on theoretic considerations is an insufficient argument.
The Linux boot process is complicated enough. (Development of System Image Creation and Bootstrapping Tools)
Stacking another layer of complexity (LVM) without strong rationale is only making a bigger mess on top the existing usability mess. That’s why I even created Broken Boot - Kicksecure. Once the boot process is broken, analysis and recovery without re-installation is extremely complicated. The internet is full of of support requests by users which went unresolved.
I think the issue is, that we don’t have a feature request template for Kicksecure yet. This is what Qubes has:
- The problem you’re addressing (if any)
- The solution you’d like
- The value to a user, and who that user might be
And this is from systemd:
- Is your feature request related to a problem? Please describe
- A clear and concise description of what the problem is. Ex. I’m always frustrated when […]
- Describe the solution you’d like
- A clear and concise description of what you want to happen.
- Describe alternatives you’ve considered
- A clear and concise description of any alternative solutions or features you’ve considered.
Please fill this out, describe the feature you’re personally missing.
Because then maybe way to get this feature is indeed LVM but perhaps there are more suitable, simpler alternatives such as btrfs
It might make sense to request features that one doesn’t personally need but thinks this would be good for the overall health of the project since others those need it don’t even make a feature request. But in case of LVM, I don’t think that makes sense.
LVM doesn’t make analysis any simpler.
If even unman runs into this issue, doesn’t know how to fix it and nobody knows it either, then it’s simply too difficult.
Or take Unable to boot | "qubes_dom0-root does not exist" | Possible LVM problem · Issue #8707 · QubesOS/qubes-issues · GitHub. After complex analysis, it just stalled. DemiMarie (Qubes developer) didn’t answer anymore for some reason. That could be running out of ideas or time or something else. But the reasons are speculation since the end result is the same. It’s too complex, requires too much effort to debug.
Since in case of Kicksecure it’s optional and doesn’t have a strong rationale, it’s best avoided.
That’s not the kind of reliability, stability and maintainability that I set as project goals. Related:
Which further strengthens my point: Highly technical people either aren’t motivated to work with LVM or unable due to technical challenges, then it’s best avoided unless there is a strong rationale.
Solution for LVM miss and mess, is to have Btrfs at least as an option in the installation process.
TPM seems to be on the good luck road.
To have just everything above, abracadabra opensuse live:
1 Like
It’s super easy to expose BTRFS as an option in the installer. Lubuntu and Kubuntu have both been shipping with ext4, BTRFS, and XFS all available as options on the “Partitions” screen, no need for manual partitioning. It only requires tweaking one configuration file (IIRC) to make Kicksecure do the same thing.
1 Like
For (default) file system (BTRFS) related feature requests, if any, please open a separate forum thread.
related:
1 Like
Why TPM is important:
Good point:
use custom TPM SRK password (so, you did not pass -z to tpm_takeownership), then you can install Anti Evil Maid onto your regular boot partition.
Good point to why use USB to unlock your PC:
Anti Evil Maid on a separate USB stick rather than on your built-in disk boot partition. This is because you can use Anti Evil Maid as a provider of a keyfile to your LUKS disk encryption (as an additional file unsealable by the TPM). This way you could also stop adversary that is able to sniff your keystrokes (e.g. using hidden camera, or electromagnetic leak), and capture your disk decryption passphrase (see the discussion in the next section).
There are many very different ways to use a TPM. While a TPM has much less features than a CPU, a general feature request “use the TPM” is as useful as “make us of the CPU”. These topics should not be mixed.
This is mostly in a completely different context for TPM usage. Boot security / firmware security that utilizes TPM for messurements fortunately is unrelated to calamares. To accomplish measured boot, anti evil maid, fortunately no code in any Linux installer is required. This is based on boot firmware and operating system support.
Using a boot firmware and operating system that supports pressured boot, verified boot which makes use of the TPM, might increase security. Using a TPM for transparent encryption however is completely different, optional feature, decision.
There is no general “use the TPM” feature which calamares could (or should) implement. Instead, very specific proposals on how to utilize the TPM could be written by developers for the purpose of increasesd security. Such features then, don’t necessarily (and hopefully) don’t need to be implemented at the calamares level, which I would hope to stay minimal.
A useful Goals I support is:
- The differences in the code base for Live Systems vs. Installer Systems vs. Installed Systems should be reduced as much as possible.
So I want to provide a generic image for users to download. The image should be able to be flashed on an internal hard drive, a USB drive, on a server or anywhere else.
Then calamares would not even be required anymore. It’s a lot of engineering work ahead to get there and it’s not even clear if this can or will ever happen.
- Installer specific code should be as minimal as possible.
Protection from an adversary that is sniffing full disk encryption passwords using cameras, doesn’t need require a TPM. Protection from that requires only an additional keyfile on USB. Keyfiles predate TPM.
It however doesn’t protect from an adversary that can sniff the full disk encryption password and steal the USB device including the keyfile. But a TPM won’t either.
I am not aware of any Linux installer that allows setting up password + keyfile on USB + backup keyfile on another USB. I would hope that there is no need to re-invent such a feature for every Linux installer and that this could instead abstracted into a general project.
Unfortunately, that usability using cryptsetup, setting up keyfiles on USB is currently very bad. It is possible to do this manually but very difficult for users. I don’t know any Linux distribution solving that. But then again, there is no magic answer. And this problem also cannot be solved by saying “use the TPM (in calamare or anywhere)”.
Password + keyfile on USB would indeed protect against camera password sniffing + stealing of a powered off notebook.
However, that calamares TPM ticket TPM Encryption support · Issue #2355 · calamares/calamares · GitHub does not suggest that. It only suggests adding TPM Transparent Encryption support. This is a security reduction. It is vulnerable to a new class of attacks: warm cold boot attacks. (As described in the wiki.) (Not to be confused with the “classic”, “normal” cold boot attacks.)
This is also the way which the Ubuntu installer allegedly can use the TPM for.
As the developer in that ticket pointed out:
In any case an explanation of what the feature is, what it does, how it is used in Ubuntus, etc.
To make good use of a TPM for full disk encryption, it is important define adversary capabilities, the threat model. Added some of that here just now:
TPM Full Disk Encryption Threat Modeling
As for using USB to unlock full disk encryption at boot that is great. (And no TPM required.)
But then is the question, use password + USB (more secure) or use USB only (less secure, more convenient)?
If that is a feature request, please open a separate forum thread for that.
Just because it’s going to have TPM support doesn’t mean it will be bloated; that’s a wrong assumption to begin with. We can also remove FDE support in this case (which can be done post-installation), and we call that keep it minimal. So, ‘minimal’ is undefined, and TPM is default in almost all main distro installers, whether Debian, Qubes, openSUSE…etc. It’s not like we’re doing the unusual.
True, but you missed a crucial point: TPM adds an extra layer of security by binding the key file to the device’s hardware, meaning the encryption keys or key files will be tied to the specific hardware of the device. This prevents an attacker from simply copying the key file to another machine to decrypt the data. The decryption key is “unsealed” only when the system’s hardware and firmware are in a trusted state, thereby adding protection against physical attacks and tampering.
It really doesn’t matter how TPM will be used by the user, what matters is that support for it exists and is easily available.
The bottom line is that TPM has undeniable utility, whether it is fully trusted or not is beside the point. Not having it available from the installer level is a minus, not a plus to the distro features.
FDE cannot “easily” be done post-installation on Debian.
(And probably not in anyother Open Source Linux desktop distribution either. I researched that recently and haven’t found much.)
It’s called “in-place encryption”. Available for Windows. Unfortunately, for Linux Open Source desktop there isn’t and CLI available let alone GUI.
In fact, it’s so difficult, it would take me a few hours. So for users this is pretty much impossible.
Debian; Qubes installers support TPM (encryption?)? I don’t think so.
Debian I am almost certain about.
- D-I: I doubt has TPM support.
- calamares: The ticket shows that it doesn’t have any sort of TPM support.
Qubes AEM (but not an installer feature?) uses TPM but it’s at time of writing “legacy” BIOS only, no EFI support, breaks on Intel ME cleaned systems.
“Some other distribution is doing that” is also an insufficient rationale. As distribution developer I need to decide based on actual technical considerations. If some distribution adds spyware, Kicksecure won’t do the same. If some distribution add convenience features that significantly worsens user security, Kicksecure won’t do that either.
That’s why derivatives exist. Because these have different goals and make different decisions than major or other distributions.
Depending on how exactly TPM is used…
- New highly complex code interacting with one or multiple of the following: grub, dracut, systemd, installer.
- Implementation Issues: new bugs, data loss…
That doesn’t make sense. How exactly it will be used is what actually matters.
Without understanding adversary capabilities, the threat model, it cannot really be understood, compared if it is better to use or not use a specific implementation utilizing a TPM.
Utility is an insufficient rationale. It depends on the exact utility in the context of the distribution.
And what’s the issue with that?
Some distribution has, promotes, encourages feature TPM Transparent Encryption, which is less secure than password based encryption.
And then what?
Is it some some hypothetical consideration:
user sees Ubuntu supports TPM → user vaguely thinking “TPM security something” → user uses Ubuntu instead of Kicksecure → loss for Kicksecure?
No, I doubt that is how marketing works. There’s a huge list of Kicksecure security features. If that doesn’t convince the user, nothing will. I doubt adding “TPM encryption” (whatever the implementation) will make a difference.
Users instead resort to other criteria on how to decide which distribution to use. (Supposedly) expert opinions, other authorities (media), visual design of website or software as an expression of professionalism, reddit, size of distribution, whatnot.
Let’s suppose calamares did support TPM transparent encryption by default… Then Kicksecure might even disable the feature by default.
If it’s just about running checklists and showing Kicksecure is great then this could even be framed in another way.
discourages less secure encryption feature TPM transparent encryption:
If it’s just about superficial “distro wars”, “my distro is better than yours” then there’s plenty of dirt to spread on TPM.
- Defeating Microsoft’s Trusted Platform Module - Schneier on Security
- Umgehung von BitLocker mit TPM | 0xffd700 (translate to English using some tool)
Pushing TPM transparent encryption in Kicksecure could even be interpreted as an anti-feature, backdoor.
That is one advantage indeed.
To compare,
- FDE Password Only
- FDE Password + USB Keyfile
- FDE USB Keyfile Only
with
- FDE TPM Transparent Encryption and even
- FDE Password + TPM [1],
TPM Encryption Comparison Table has been created just now.
[1]
There are currently no implementations that truly combine a strong user-provided password with the unsealed key from the TPM.
This has significant disadvantages compared to FDE Password + USB Keyfile.
Relying solely on TPM with a PIN or password is not the same as deriving a cryptographic key from both the password and the TPM. If the TPM is compromised - through physical tampering - the encryption is broken, even if the password is strong. This creates a single point of failure, allowing attackers to bypass password protections entirely once the TPM is compromised. Users of FDE Password + USB Keyfile benefit from enhanced security because the complete key is genuinely derived from both the user-provided password and the USB keyfile. This means that both components are required for decryption, adding significant entropy and making it much harder for an attacker to compromise the system. Unlike setups relying solely on TPM, this approach eliminates a single point of failure, requiring an attacker to break both the password and the physical key, which provides more robust protection.
Please don’t add TPM backdoor. K. Thx!
Microsoft BitLocker encryption cracked in just 43 seconds with a $4 Raspberry Pi Pico 
According to the researcher, targeted attacks can bypass BitLocker’s encryption by directly accessing the hardware and extracting the encryption keys stored in the computer’s Trusted Platform Module (TPM) via the LPC bus.
Breaking Bitlocker - Bypassing the Windows Disk Encryption 
Hardware dependent.
Maybe would be less of an issue if the TPM was integrated inside the CPU (because nobody can disassemble a CPU, not even Intel / TSMC):
Quote https://www.reddit.com/r/intel/comments/1b3z5s4/where_is_the_tpm_physically_located/
TPM is usually on the motherboard. otherwise TPP would be listed in the specs of the cpus on intels site.
That comment makes seems helpful. If TPM was integrated inside the CPU, it would be mentioned in the specification of the CPU.
Maybe better with AMD fTPM and Intel PTT (Platform Trust Technology).
1 Like