encrypted install fails because unsafe swap (zram) is detected

My humble guess is that the zram swap is mistakenly recognised as a swap on harddisk

Workaround:
1) boot via "Try Lubuntu" not "Install Lubuntu"
2) open terminal
3) enter "swapoff --all" press enter
4) start installation

This workaround works only if the unsafe swap error has not been raised since the last reboot.
If that has been the case even with swapoff --all the installer will fail, to circumvent reboot.

Status changed to 'Confirmed' because the bug affects multiple users.

I'm getting the same with Lubuntu 14.04 installing onto a fresh unformatted virtual disk in virtualbox.

Same error. It only occurs when I attempt to encrypt my home directory. Unencrypted, the installation goes without an error.

I notice that I have a one MB reserved space at either end of my disk memory. Nothing I do will get rid of these partitions. I assume they are the problem. Gpart doesn't remove them but gives me an error instead. If I insist on trying again, it locks the computer up and I have to do a hard reboot.

My disk was originally an uninstalled new purchase Windows 7. I refuse to use that product for security reasons and am attempting to replace it with Lubuntu 14.04. Looks like Microsoft is reaching out from the grave to make sure their security problems stay with me evey when I don't use their software.

The computer is a refurbished (by Acer) Acer Notebook NX.V7EAA.009;TMP653-M-9889. It does have hardware TMP.

I also tried to execute swapoff --all but that didn't work either.

Hi everyone,

I ran into this problem as well, but my fix was:

Boot into Live session

Terminal, enter: "sudo swapoff --all"

Proceed with installation

Remember, it must be run as sudo(super user) to disable swapoff.

Hope this works!

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1205397

I noticed this in syslog:

Jul 26 13:45:39 lubuntu kernel: [ 15.163548] Adding 513168k swap on /dev/zram0. Priority:5 extents:1 across:513168k SSFS

(No idea if posting to the right place, hopefully someone, somewhere out there gets some use out of this. It's far too rare for me to go back and actually post solutions to problems I had and fixed..)

I had the same problem, there's definitely something wrong with the installer (I was trying to set up 14.04 with encrypted partitions on different drives, with / on my small SSD and /home /usr /tmp /var and swap on my HDD). But I played around with it, restarted the installer/rebooted a number of times, and here's how you work around it:

It's the ordering. It can't cope with setting swap as an encrypted partition and then creating another partition after that. So, set up all your actual partitions, including your encrypted containers first. I believe it necessary to include an encrypted partition for swap, so make sure to make one of suitable size for it. Don't know if relevant, but I happened to pick all logical partitions and that worked.

Once you have them all set up, THEN, and only then pin them to actual mount points (setting this straight away will result in a crash). I started with swap and then moved on to /home and so on.

Now you have your encrypted partitions, and you don't have to forgo swap with swapoff!

Same bug still exists in 14.10, the workaround from #8 is what I used to complete install.

Yes, I ran into this problem again when attempting a install of 14.10 using my (encrypted) 14.04 partitions. Very frustrating since it takes 5+ minutes per iteration after you quit and try something different. The problem seems worse -- I tried at least 5 or 6 different variations before finally being able to complete the install. Even though I would run "sudo swapoff --all" (from the terminal, from a virtual console), I'd still get the error. I tried deleting my existing partitions and creating new partitions.

The problem seems worse (or perhaps it's an additional problem) -- there were several times that I was trying the approach from comment #11 and not setting mount points until the end, but then the problem was that after I created one physical volume for encryption, the installer would hang when I created the second. (One partition for swap, one for /, in addition to the unencrypted /boot partition).

In the end, the solution I came up with was to create a partition for swap but not to use it at all. (I.e., an install with no swap). Now that the install completed, I'll go back and set up that partition to be swap after the fact. This will probably be better anyway -- I'll be able to set it up so that it uses a random key for swap encryption so I only need to type one passphrase to boot. (Which is fine since I never do a hibernate anyway.)

Still there in Lubuntu 15.04.

surprised this is still here in lubuntu 14.04.3

still present in 15.10

Running into this in 16.04

I'm running into this on Lubuntu 16.04.1 too - i386 and amd64 desktop ISOs (downloaded yesterday). Tried on multiple machines with the same results, but the workaround fixed the problem.

The error message is: "An unsafe swap space has been detected" (I couldn't find this bug by copying + pasting the message).

This seems like a major bug to me - users can't install using one of the options presented to them unless they run a terminal command manually. I consider myself to be an advanced user and I managed to find the workaround via a blog post, but I suspect people with less experience will give up.

Is there a way of getting the bug importance increased (I don't think Medium fully conveys the seriousness of "I can't install Lubuntu using the wizard") and is there anything users can do to help get this fixed?

Is this bug already present on Lubuntu 16.04.1 and if yes what is the best way to solve it?

This bug is still present in Lubuntu 16.04.1, and it has been here for years. Lubuntu is great, but I don't know why such really critical bug cannot be removed. Unfortunately, I don't know how to program...

PLEASE, dear Lubuntu Team, would PLEASE fix it? I would appreciate this very much. If necessary and you tell me someone who can do this, I would be willing to pay for the bugfix.

Hard disks should not be used unencrypted, but this bug FORCES every normal user to do so! Installing without encryption is the ONLY thing a normal user can do!

For everybody who has found this page, a workaround:

1. Restart your computer and choose test Lubuntu (without installation).
2. In the program menu, find the program LXterminal (in German: you can find it in "Systemwerkzeuge").
3. Type "sudo swapoff -all".
4. Only then click the icon to install Lubuntu. Encrypted installation should work now.

Please note: The restart is necessary, the system must be "clean".

I'm getting the same with Lubuntu 16.10 installing onto a fresh virtual disk in virtualbox.

I'm installing Lubuntu on may 2017, latest, the error still there. Plus the "continue" grayed on the last step (that you need to go back and forward in order to work)

Same issue with 16.04 AND 17.04 and it does not work even with "sudo swapoff -all".

Tried lubuntu-17.04-desktop-amd64.iso on a lenovo yoga 300 several times using "sudo swapoff --all" before running into error. Thus the error message changed to auto-partition failed.

At my system the auto-partitioning creates a 1MB partition as first an one as last partition on disk, which is quite odd.
I found a forum hint pointing out that the result of auto-partitioning would be the cause for the resulting error. My expertise is not sufficient to manually create the needed partitions using gparted and getting the installer using these partitions.

Thus I am not able to use the 64-bit Version of Lubuntu. This is a pitty as the installation of 16.04 on 32bit ASUS eeePC 901 runs like a dream. Which was the trigger for trying to switch from ubuntu to lubuntu with the yoga .

Thanks for your effort to provide this distribution. For my old eeePC this is the distro,
Thanks, Peter

Amendment to #24
The following solution worked for me for installation:
(see: https://askubuntu.com/questions/845401/installing-lubuntu-16-10-with-encrytion)
I booted using 17.04 64 bit and did choose the "Try Lubuntu" option from the boot menu.
From the desktop I have chosen "start menu" -> "system tools" -> "LXTerminal"
In the terminal I issued:
  sudo swapoff --all
  sudo apt-get install lvm2
  answer Y to continue install of lvm2
After completion I started the installer icon from the desktop and the installation ran smoothly.

BUT AFTER REBOOT I RAN INTO CONSOLE-ONLY MODE. BusyBox v1.22.1 (Ubuntu 1:1.22.0-19ubuntu2) build-in shell (ash)

Perhaps this part of the solution does help someone else. Good Luck!

I am pretty fed up by now. Perhaps I might come back at a later point in time. Bye for now.

Indeed, for now the solution will have to be to disable zram before installing for LVM2 with crypto.

So; for zram, I think the solution will be "involved". Not overly complex, but I think it needs a small rework of seeds. zram is compressed, not encrypted. It would be downright wrong to ignore zram devices when checking that swap is safe when dealing with encrypted disks. One option is to allow users to decide whether it's fine, but that seems like pointing them in a direction that might not be in their best interest -- it's not obvious enough this way that we look whether swap is safe for a good reason: if you keep unencrypted swap enabled, you still have unencrypted data in memory that may contain the data you're trying to secure with disk encryption.

The other option would be to install zram later, once we know the system is not going to be installed with crypto. To get that, we'd need to move zram-config from live-share to ship-live-share so it still exists on the CD, but in the pool/ directory rather than as a part of the live image; and add some code in ubiquity to that if you install without crypto, for lubuntu it would install zram-config.

You wouldn't have the error if the live image didn't have zram-config in the first place. In fact, I think having zram-config in live potentially slows things down -- if you're in the live session, you're already running in memory and not swapping to disk (the point of the live image is not to change the local disk), so having zram only seems to me to be adding compression overhead.

Late install of zram-config probably ought to be done somewhat like for language packs, so in scripts/plugininstall.py for instance, possibly install_extras() with the appropriate guards to install on Lubuntu, and only if LVM2-crypto was not the partitioning mode.

Setting the ubiquity task to Triaged. I don't think I have the time to do this right now, but I think I've captured by idea here and given sufficient background that someone else could easily attempt to implement this in ubiquity -- that would be a pretty interesting way to get to know ubiquity, too.

FWIW, the unsafe_swap check is done in partman-crypto -- that's a debian-installer component, so another reason to avoid making flavour-specific / security-sensitive changes there.

Here is another workaround https://askubuntu.com/questions/393418/unsafe-swap-space-detected

Please provide a possibility that when this warning is prompted, the user can disable all swap with a single click and, if needed, is navigated back to the install screen most suitable to restart with.

On 12/1/2017 10:39 AM, Mathieu Trudel-Lapierre wrote:
> So; for zram, I think the solution will be "involved". Not overly
> complex, but I think it needs a small rework of seeds. zram is
> compressed, not encrypted. It would be downright wrong to ignore zram
> devices when checking that swap is safe when dealing with encrypted

No, it wouldn't. This is exactly the solution that is needed.

> disks. One option is to allow users to decide whether it's fine, but
> that seems like pointing them in a direction that might not be in their
> best interest -- it's not obvious enough this way that we look whether
> swap is safe for a good reason: if you keep unencrypted swap enabled,
> you still have unencrypted data in memory that may contain the data
> you're trying to secure with disk encryption.

Data in ram is *always* unencrypted. You encrypt the disk to make sure
it is encrypted while it is on the disk. If someone has access to your
ram then they can grab the decrypted data out of the page cache ( or
better yet, grab the decryption key and then read whatever they want off
the disk ). The only thing that zswap does is compress what is already
in ram anyway, and is thus already vulnerable to such attacks without zswap.