Menu
▾
▴
#17 UUID
As somebody mentioned about that before, I found the same problem on Debian testing installation. I have two Sparky installation of my machine; I reinstalled first one and I couldn't log in to the second one. To make sure it is not Sparky issue only, I reinstalled the first system using Debian testing installation media. The issue is the same so it came from Debian. For the installation I used the same (for system 1 and 2) SWAP partition. The installer used existing SWAP and formatted it so it gave a new UUID for SWAP. After that it's not possible to boot the second Sparky/Debian testing installation, because th SWAP UUID has been changed. To make sure it's exactly what I said, I chrooted to the second system, edited fstab and I changed the SWAP entry from UUID to dev number. After that I logged on to the second system with no problem.
We could either modify the installer to not format the already existing SWAP partition or make the installer use a disk file instead of a partition for the swap space.
Don't our current installers already have an option of choosing not to format the swap partition? We could close this if they do.
The Advanced Installer has such option; if detects existing swap partition, it uses it without formatting. Not sure about Calamares.
I'll check it out. If Calamares can re-use the SWAP partition, then we can close this as well.