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.