While I am not sure if that outcome is intended (loss of a feature compared to pre-web-ui-era, rendering disk encryption unrealistic on some devices), it is more a feature request than a bug report: AES disk encryption is not suggested if hardware has no AES-NI (performance and power consumption can end up in a denial of service), which can happen on low-end hardware and some ARM hardware (e.g., Raspberry PIs). There are some other reasons why users sometimes would want to avoid AES but that are only minor niche cases. The kernel has added support for adiantum for this (adiantum is just a setting in cryptsetup/dm-crypt). Anaconda does not allow to adjust encryption but only uses the default, which is AES-XTS (=AES), so users needed to do this themselves in advance in the past, and then use the pre-created encrypted device (with the cipher setting of cryptsetup/dm-crypt being set for adiantum encryption) within anaconda. There is an open ticket in storaged-project/blivet [1] to automate this, but it is unclear if and when this is implemented. However, I have just tested for the first time the Web-UI installation through F43 KDE Spin and found out that it is no longer possible to add pre-existing encrypted devices: I can unlock the existing device in the web-ui and then see the partition table, but I cannot add a partition within the encrypted device but only delete the encrypted device to setup something new (leading to the original problem: web-ui/anaconda sets up only default encryptions with AES): see the screenshots attached. I could imagine (pure speculation!) if I setup manually a file system within the encrypted device in advance, the web-ui might be able to use that one (showing it at the place currently showing the removed luks UUID), but I lack time to do much testing atm and we should not rely on affected users coming themselves to this idea, so I just file this for your consideration: the support for pre-existing encrypted devices should be available as in earlier anaconda versions from the time before web-ui. If you have questions or if something is unclear, feel free to let me know. [1] https://github.com/storaged-project/blivet/issues/1108 Reproducible: Always Steps to Reproduce: Pre-create an encrypted device on some command line (e.g., in a live system: `cryptsetup --type luks2 --sector-size 4096 --cipher=xchacha12,aes-adiantum-plain64 --offset=0 --pbkdf argon2id luksFormat /dev/sdx"`) 2. Start F43 KDE Spin web-ui installer 3. Unlock the device at "How would you like to install?" 4. Go ahead and try to create a file system for the installation in the existing encrypted device Actual Results: Not possible Expected Results: It should be possible Additional Information: tested on x86_64
Created attachment 2129364 [details] screenshot 1 of the situation in which the issue manifests
Created attachment 2129365 [details] screenshot 2 of the situation in which the issue manifests
Due to a lack of time, please forgive me to not open a new ticket, but to have it reported: Several Fedora Kinoite installations are degraded through settings set by anaconda: anaconda adds a / entry to /etc/fstab, which is not intended for Kinoite. Therefore, systemd is degraded through `systemd-remount-fs.service` on installation. Originally, I thought the issue is that I intuitively added a / myself (which I did), and the issue of anaconda is merely that it does not warn me about the outcome. However, I then setup on a native laptop a default Fedora Kinoite installation (43), and set the partitioning to "automatic", and it still created a line with / in /etc/fstab, and the system was again degraded. The degrading can be resolved by adding a # to the beginning of the line of / in /etc/fstab, and the degrading is harmless, it does not cause issues other than the error. It might be still worth to be resolved over time :) According to a user report, there is also the possibility for cases in which the line / is added but the system is still not degraded, although siosm confirms that the line for / is not intended (see the discussion link below). We didn't go into details about this though. I have not explicitly tested if that issue also applies to web-ui, as Kinoite does not yet use it, but I assume the partitioner and its defaults might be the same, so I add it for your consideration. ------ There was a short discussion about this here: https://discussion.fedoraproject.org/t/fedora-kinoite-systemd-degraded-upon-installation/181225 (a link to another discussion where this happened as well is contained in the discussion) There is also a workaround from siosm for those experiencing this issue (this is only indirectly about this case but shows that the / is not intended): https://discussion.fedoraproject.org/t/root-mount-options-are-ignored-in-fedora-atomic-desktops-42/148562 Hope that helps to improve anaconda a little for the immutable experiences :) Thanks for your hard work!
Hello Christopher, Anaconda supports unlocking of an existing LUKS container and reusing them for installation (see attached screenshot), so I'm wondering why it didn't work for you. Could you please share the exact steps you followed (including preparation of the LUKS container) that were unsuccessful for you? Is it possible that you created the container outside of the installation environment using a cipher that is not present in/supported by the installation environment? Also attaching installation logs (found in /tmp) might be helpful. As for the second bug, I'll copy & paste it into a separate bug. We really appreciate the bug reports, as they help us making Anaconda better. Nevertheless we need to keep all of the reported issues separate, so that they are easy to track, fix and the comments don't mix up. Thank you for understanding.
Created attachment 2131898 [details] Option to unlock a present LUKS device provided by Anaconda
I have to review the case I had back then, as it's some time ago, but having done some testing in other settings since, I can confirm my earlier assumption ... > I could imagine (pure speculation!) if I setup manually a file system within the encrypted device in advance, the web-ui might be able to use that one (showing it at the place currently showing the removed luks UUID), ... The problem is that anaconda when using the "set mount points" option (rather than using the "use all remaining space" option or so) only recognizes existing file systems. So if I create an encrypted LUKS device but do not format it, then anaconda does not show it in the mount points: I need to format it in advance. So the formatting possibility in the "set mount points" window has a limited use, as it can only reformat an existing formatting/file-system (as it is not shown as possibility otherwise), but not create an initial formatting / file system on a LUKS device that is not yet formatted with a file system. I now know this also applies to LVM: anaconda "set mount points" did not show LVM devices that existed with "lvdisplay" (I ensured they are available): I had to format them in advance with any file system. I had this issue in all cases / all settings of BZ#2442353 and BZ#2443812. I can reproduce it in all settings: encrypted LUKS devices (even once unlocked) and logical volumes of LVM (even if I ensure they are available/active) are not visible until I format them in advance with xfs or ext4 or so (I didn't do testing with btrfs as OS without btrfs support were involved). So, create an encrypted LUKS partition or a LVM logical volume of any volume group (without creating any file system or so!), and it will be NOT shown in anaconda's "set mount points" option (so the page after LUKS has been unlocked). But if you additionally do mkfs.ext4 or mkfs.xfs on the logical volume / on the encrypted LUKS device (so mkfs.ext4/xfs on the decrypted mapped device of course!), then it will be shown afterwards and you can set it in anaconda as mount point or even reformat it. Hope that suffices? :) > using a cipher that is not present in/supported by the installation environment? While it would be great if anaconda would allow to change the choice of ciphers (which would modify the cryptsetup luksFormat cmd), the outcome does not make a difference: all dm-crypt devices will behave the same. Anaconda will not be exposed to any difference unless it calls metadata through a luksDump, in which the metadata obviously would differ in the very places (I assume anaconda does not care to collect this information anyway:). But the behavior and support is equal as long as dm-crypt is used in ways standardized in the kernel (adiantum is in the kernel since some time in 5.x). With the formatting such as mkfs.ext4, it works out fine to use Adiantum with anaconda. Keep in mind that I also tested this with the default dm-crypt (the defaults as created by "cryptsetup luksFormat" without customization). So all tests after this report were with default encrypted devices anyway.
Thank you for sharing the details, it absolutely makes sense as you've described it. Indeed, if the existing LUKS container is not formatted, there won't be anything available to get reused by Anaconda. However, this is limitation is only valid unless you resort to using the advanced partitioning feature (storage editor). You can reach it by clicking on the three dots button in the top right corner on the 'Installation method' screen and selecting 'Launch storage editor'. Then you can unlock the LUKS container and create whatever partitioning you like inside of it and set how it will be used by Anaconda for installation. To bring in some more background: Anaconda's limited ability to reuse existing encrypted partitioning is basically targeted to scenarios where you're dealing with a regular, complete existing partitioning from some previous installation. In a similar way, at this point it is deliberately limited to cover the most common partitioning scenarios in general. While I understand your use case and why you took the aforementioned steps (which are an actual workaround for those limited abilities), it's something a bit out of scope of more or less standard use cases covered by the non-advanced UI options. At the same time there's the Storage editor exactly for the reason of allowing advanced users to create more complex partitioning, including handling LUKS. On the other hand it would never hurt to have this documented in a better way, so that it's easier to find out how to solve this advanced partitioning requirement.
> more or less standard use cases covered by the non-advanced UI options I generally agree to your points. My desire would have gone more towards having such advanced UI options rather than only non-advanced UI :) That said ... > You can reach it by clicking on the three dots button in the top right corner on the 'Installation method' screen and selecting 'Launch storage editor'. I was not aware of this, and having felt (until reading your point) that I clicked myself through most of that UI, I would have never linked these buttons to something like that (or generally to something that is part of the actual installation). For me, that "felt clearly" like the buttons for minimize/maximize/quit/about/help or "options of anaconda's interface/appearance" itself, which in the end is still a window within KDE (and so I have interpreted the window I "experienced"). I have not rationalized these dots before, but when reviewing it now, the first what I have in mind is the three-line-button (rather than three dots) in my Firefox top right: that's for me clearly linked to options of/for Firefox itself, and if I search for options within a website, I would never click/search there. Maybe my perception is also triggered that way because these dots are there since I opened the web-ui and remain there throughout, and so I tend to not link them to anything in particular of any of the very windows. I try to rationalize and elaborate my perception / intuition in order to give you some feedback of the user experience, I hope any of that makes somehow sense and can be useful ;) Maybe a button that is more explicit would be useful? "Advanced" or so? It needs to be comprehensible to wide audiences with different ways of reasoning and different ways of interpretation. Just some thoughts :) So these advanced options indeed bring me one step ahead and indeed neutralizes some of the critique I had in mind :) I admit, at first glance it still feels a little more confusing than the old Anaconda, but that can be also because I am used to something other. I have no time at the moment to evaluate them in depth. But thanks for letting me know :) One last point about the crypto: when I can choose between luks1 and luks2, it might be on the long term (for your road map:) also useful to add choices of cryptsetup's supported ways: I assume what happens at the moment is just `cryptsetup luksFormat /dev/xxx`, this can be easily customized with options like "--cipher=xchacha20,aes-adiantum-plain64" (that is Adiantum rather than AES-XTS for devices without aes hardware encryption -> can be easily automated as even "lscpu" contains "aes" in "flags" when aes-ni is available) or using xchacha12 rather than xchacha20 for low end devices like raspberry or so (aes is already a denial of service for them), or custom key sizes "--key-size" (note key size in AES-XTS = <keysize>/2) or hashes "--hash". Any of them can be customized individually, and whatever you do not customize, will be done in the default setting. If you use an API it might be different, but I expect comparable. Just some thoughts for long term planning, just in case :)