So regarding the current workaround that lets FDE work, can someone who has applied it show what apt autoremove shows? Don't actually hit "yes" to remove it given the issue that was reported that it removes packages that are needed.
Hopefully it's obvious which package is marked incorrectly and then it's as simple as running
apt install $package
and it is no longer marked as auto-removable.
Hi @dell-mario l,
When I am posting the full log, the following error is now returned:
"This reply was marked as spam and has been removed. If you believe this is an error, submit an abuse report."
So, I am posting part 1 (in French):
$ sudo apt-get autoremove
[sudo] Mot de passe de xxx :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
apt-clone archdetect-deb btrfs-tools cryptsetup cryptsetup-bin dmeventd
dmraid gir1.2-timezonemap-1.0 gir1.2-xkl-1.0 kpartx kpartx-boot
libdebian-installer4 libdevmapper-event1.02.1 libdmraid1.0.0.rc16
libido3-0.1-0 liblvm2app2.2 liblvm2cmd2.02 libreadline5 libtimezonemap-data
libtimezonemap1 linux-oem-headers-4.15.0-1006 lvm2 python3-icu python3-pamrdate
0 mis à jour, 0 nouvellement installés, 25 à enlever et 4 non mis à jour.
Après cette opération, 93,7 Mo d'espace disque seront libérés.
Thanks for sharing. Looking at that list I would expect it's caused by three of those packages.
If you can please run the following command, I would expect that you would have no more problems with autoremove after:
# apt install cryptsetup cryptsetup-bin lvm2
I will back up the whole system with CloneZilla before testing and I will do this during this weekend.
In a previous message you mentioned apt install $package.
So is it apt install cryptsetup cryptsetup-bin lvm2 or or apt install $cryptsetup $cryptsetup-bin $lvm2 ?
It took me a bit longer than I planned to do this on my XPS (busy time at work, plus I realized that before I reinstalled from scratch I might want to try out XFCE on this machine for a while). But yesterday I made the new USB installation image and today I went ahead and reinstalled Ubuntu with FDE. The process was straightforward and quick, so I definitely encourage others to do it also.
I have only one bit of advice for people planning to do this: If possible, do this as soon as you receive your new laptop (before you install or configure anything, copy files, etc.). By far the majority of the time that I spent finishing this off today was setting up my system the way that I wanted it again and copying all of my files back over. This is partly because I did not make an image of my system and restore it (instead I just used grsync to copy my home directory to an external drive, since I thought that would allow my to avoid any cruft in the new system). But nevertheless it's a seamless experience if you encrypt and reinstall first and then set everything up. It works either way, but you save some time and effort if you start with FDE. Plus you won't be tempted to wipe all of the blank space when encrypting your drive (which takes much longer), since you will never have had any of your own data on it.
These are the steps as I followed them (based on steps that others posted here):
For reference, I completed steps 8-15 in less than an hour this morning, but the last step took me about three hours. YMMV.
Hopefully future systems can be shipped with these packages in the standard recovery partition and include instructions for how to do this (which would be a whole lot easier than modifying the encryption method so that users can choose what they want when they receive their systems, although of course that would be ideal).
Thanks very much to the Dell devs who made this possible and to the community members who tested and debugged this!
So perhaps all that needs to be done for now is to have a KB article on Dell.com about how to reinstall Ubuntu with FDE (and ideally to ship these packages with future systems, but that may not be as quick to implement). Oh and I guess I don't know the status of how non-QWERTY keyboards might behave when setting the password. So that may require a warning and/or more testing.
If you do a KB article, one thing that I always try to remember to mention to anyone who is doing this type of encryption is that no one can help them if they forget their FDE password, so they should make sure that won't happen.
I agree that a KB article would be useful soon. Before checking how to make that happen, I would like someone to be able to comment if this QWERTY issue is "real". I suspect it's related to setting up the passphrase in the installer before the keyboard locale was selected. (OEM installs don't do that until the OEM config out of box pages).
This means that the installer might still need modification to unset preseeds and show the keyboard locale selection page to correct it.