Comment 26 for bug 1205397

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.