When choose the option encrypt disk and after the installation process and reboot. Before entering to grub I was asked to input the disk key, then grub initialized, and after that I got kick to busybox
reason : the GRUB config was to look for /dev/mapper/luks-UUID, when manually decrypt using cryptsetup /dev/sda1 UUID the decrypted system was /dev/mapper/UUID
solution : use live usb to boot into it, decrypt the partition, mount in mnt and modify both in /mnt/etc/default/grub and /mnt/boot/grub/grub.cfg and delete all the "luks-" precedding all UUID
restart
got kicked into busybox again this time I need to manually decrypt the partitions and then exit for it to boot normally finally
each time I hit restart or turn off the pc and then turn it on again I'll have to repeat the process indefinitely
hypothesis : when you made Peppermint to ask for password it was before grub was loaded, and then decrypt the partition, load grub and load the OS, but when the OS is loading, there is actually no password from before that get pass down, so the system has no idea of how to process the disk and kick the user into busybox, so that the user has to painstakingly decrypt the partition himself at each boot (yes I have to type the UUID manually each time I boot, for both the root and the swap, it is painful)
Lastly everything works, except that the swap wasn't mount, I have 4GB of swap which on htop shows 0 (I need to enable swap manually again)
Full article here : https://superuser.com/questions/1714597/peppermint-os-boot-failure-because-of-disk-encryption (yes I did take hours to write this painstakingly, the only thing I didn't include is how to mount the swap manually, but for those stuck with the same problem this is but a temporary solution and not a permanent, if no one really answer, I will have to research GRUB and LUKS into more detail because I have no experience in this and it will take a lot of time)
Please at the very least, fix this issue for the next version of Peppermint, the only reason no one speak up until now is because they don't use encryption, I just happen to be the odd one out
Lastly thank you for the OS, I am spending some time to explore it, but to find myself in such a problem the moment after installation is not quite appealing, although I did learn something, so no real loss here. Last comment the installer was hella fast, I thought I'd need at least half an hour for an old pc (intel codename merom core 2 DUO 1,66Ghz 2GB RAM) it did finish installing in 5 mins, KUDOS for that (the update later took so much more time, lol)
Last edit: New1997 2022-04-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2022-04-05
Thank you for trying PeppermintOS, you did not mention which partitions you attempted to encrypt. As the Calmares installer, only allows for the /home partition to be encrypted.
If you choose to do a manual encryption of the /, swap and the /home a method that is possible with the Ubiquity installer, it will replicate the result you have experienced to date.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't choose, the installer encrypt every partition, when choosing which partition to install Peppermint, I choose the entire disk and left to auto, and then check the encryption button, the rest was done by the installer, even the swap partition got encrypted
Last edit: New1997 2022-04-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just think carefully and trying to search as much as possible, but hen this occur to me : the reason that I got kicked into busybox might be because that the password from grub loader did not get passed down while booting, so ok, but what about the fact that I need to get dirty and use a live boot usb to edit the grub configuration file to remove the "luks-" before each UUID out in order for it to work, can you guys at the very least see to this "minor" configuration issue? because that would be of very much help and avoid any additional headache (on top of having to decrypt the partition manually at every boot)
Thank you (my tone seems a little bit aggressive sometimes so I must apologize in advance)
N.B an after thought, same goes for fstab, which made my swap not mounting in the first place
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As things sit for now , to get encryption you will need a partition for /home separate from /.
You can then encrypt the /home partition and it will decrypt it during the boot process.
The notes on the debian pages for this are somewhat vague about this point.
Essentially , they are interpreted (locally) just as I mentioned.
Yes, I would much prefer a fully encrypted session.
For now, encrypting /home will suffice.
Thanks
KsWoodsMan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply, so essentially bad documentation and being lead to this, I presume? May I ask that you include some warning to the installer to prevent further case (maybe I got too hasty and did not read it, if that is the case, I apologize, otherwise, might appreciate the heads up). also aside from getting kick into busybox, can you do something about "luks-" before the UUID (In GRUBS when booting and in fstab when mounting, for those who want to encrypt \ or more, just in every case even though it is only recommended for home partition)? Because things did not get properly mount because of it (in my individual case, I can just modify some config files, but for everyone else, it would be much easier if the dev just modify the template once and for all)
Thank you for you reply
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2022-04-07
FYI. Try a Manjaro install, an encrypted install through the auto-install method or manually encrypting the /root, /swap and /home will cause a failure. Only a manual install of the /home partition will work. I have had positive test on Manjaro and PMOS. Manjaro have been using Calamares since 2015 and is heavily influenced by them, due to the level of custom work they have carried out to improve it, over the years.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But my concern is, can you include the warning on your installation process to warn any future installer? and what about "luks-" that precede the UUID which make the mounting process go haywire, which I need to modify grubs and /etc/fstab to solve the problem? I do understand calamares and ubiquity is what is out of your power or are you trying to tell me that the "luks-" naming before UUID is part of ubiquity and that is where I should address my concerns? (and that means it is them who should do the warning to the people who will install your distribution to not use automatic partitioning while using disk encryption?) Please clarify so that I know who should be address about what, because even though you use both of that I thought that you can still customize your install so that there will be a warning for the users to not use disk encryption with automatic partitioning/whole disk installer or the "luks-" name in disk identifier, but if you do confirme me that you have 0 power over this and no chance at all to modify this particular setting, I will address ubiquity myself. But I still need your confirmation of these two issues, so that I can address them with all the correct information and not saying nonsense and having tell me to come back to you guys and wasting my time with back and forth.
Thank you for the time you take for reading my long reply
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2022-04-08
FYI.
In 2014 when Manjaro used the Ubiquity installer prior to their move Calamares circa 2015, was also a disaster for encrypted installs. I have made a note in our wiki, for encrypted installs. I have experienced this and other issue with different distros over the years, while distro hopping.
Your points have been noted, but the author of the Calamares installer which is considered to a an excellent installer, their frustrations were highlighted in their notes. Our team spent many hours, ironing out its various quirks to ensure a smooth install. The encryption process, has eluded Manjaro and us, but their dev team is larger and better financed than us.
I see from your profile you are fluent with many code languages, Calarmare is an open source project: https://calamares.io/ and you can either inform them or rewrite the entire installer to your satisfaction.
Regards the Peppermint dev team.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for your reply, I'll try my best to see what I can do at my end (either informing them about the issue or trying to see how I can solve the problem) thank you for your time
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2022-04-14
@New1997
Proof of concept achieved, though it is not production ready. It is one of many back-burner projects we are working on to improve the overall quality of Peppermint.
nice!!! 👍👍👍, BTW I might have found a solution on my side too regarding getting kicked to busybox (initramfs), I'll be tweaking a bit and if it works, I'll post the solution to super user stack exchange as an answer to myself, so those with the same problem can refer to it. If I understand it correctly it only present on LUKS1 and not LUKS2. So in the future, this solution might not be necessary at all.
Thank you for your hard work and dedication and your time that you invested in this matter
Last edit: New1997 2022-04-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nope, what I said is wrong, lol. I misunderstood the text, I just reread, in LUKS1 the volume key can be found by user space, so having a key file doesn't change a thing, where LUKS2 the volume key is offloaded to the kernel keyring, so having a key file is less secure (and the first time I read it I thought that it can pass the password to the kernel, but upon rereading again, it seems to not be the case)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is indeed within "luks-" prefix, but not in the way I originally thought and I'll give summary here:
First of all, everything is configured "correctly" but somehow the /etc/crypttab is not working and did not decrypt the partitions, upon removing all "luks-" in /etc/crypttab, grub config files (and fstab for automatic mounting) and update initramfs (using update-initramfs -u) everything works as it should : you enter the password at grubs boot sequence first stage, and the later stage are decrypt automatically using a keyfile. I don't know what actually cause this issue, but I think I need to have a word with the team that deals with encryption (or crypttab file) about this bug, which is weird because in theory, this should have never happened.
Thank you anyway, maybe I should have a word with the team that do installer too, so that they should remove "luks-" prefix for now, since it was the cause of the problem. Cavy which one should I have a word with, ubiquity or calamares or both?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is less a bug in the installer and more of a conflict.
The keyfile wasn't going into the initrd to unlock the / filesystem on bootup.
The command you used to update the initrd put the correct keyfile in the initrd.
The "fix" has been in for several days, already having been thoroughly tested before it goes in the next release.
Thanks
KsWoodsMan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where did I get it ?
It came to me one sleepless night, in a dream of dancing UTF-8 characters as I chanted bar-foo incantations, in the dark, to a blinking cursor.
KsW
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
haha, lol, that was funny 🤣🤣🤣🤣. That's not what I meant, I was meaning to ask if there are people to help you or other people who experience the same problem on other distro or if someone mentioned it on the chat of Peppermeint OS, or that you spent all this time reproducing the error and tried to figured it out on your own. By the way you answer, I'd say that you spend a lot of time to figure it out and there was little to no help from others. It was because you said that "the fix has been in for several days" but since no one mentioned it until you did a few days ago, I thought that it was a bug that was found by others on another platform/os and that it was fixed there first, and then it came to be known by you a bit later. (I do understand that you need some time to thoroughly test the "fix" before being sure before delivering the solution, but sometimes the people who are waiting for the fix need some update from time to time, just to know if it can be fix, or if their hypothesis was wrong, or if there is any other factors they weren't aware of, like, any information from time to time no matter how insignificant they are is still better then nothing, like to not leave them in the dark)
I hope that you don't take too much offense in what I have to say, but I was just curious of the exchange, the communication and the thought process of people to go from a problem to a solution (how they perceive the problem, thought process to formulate a hypothesis, the exchange between people with different hypothesis, the result of all the hypothesis and which hypothesis were proven true and contribute to actual solution, )
Thank you for your time for this particular problem (and thank you for reading this long text)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Funny in what way ?
Am I the only one that still writes code this way ?
This isn't a "me" effort.
We have a team of volunteers.
We each have our strong points in our skill sets.
Each of us use our skills where needed and follow due diligence to keep others, in the team, informed of what we are working on in the project.
Beyond that, follow the forum here for what's coming in the next release.
If you have a feature request, ask.
It's possibly already on "our list", to be worked on - as time allows.
If it is seen as a positive addition, without making the ISO grow, at some point it might be there.
If you need it faster, paid programmers don't come cheap.
KsW
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't forget we hang out on matrix as well.. That can provide some up to date info for more of a real-time conversation....then you can always watch the git repos on codeberg we are pretty good about detailed messaging in our commits. At least I try to be..lol
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When choose the option encrypt disk and after the installation process and reboot. Before entering to grub I was asked to input the disk key, then grub initialized, and after that I got kick to busybox
reason : the GRUB config was to look for /dev/mapper/luks-UUID, when manually decrypt using
cryptsetup /dev/sda1 UUIDthe decrypted system was /dev/mapper/UUIDsolution : use live usb to boot into it, decrypt the partition, mount in mnt and modify both in /mnt/etc/default/grub and /mnt/boot/grub/grub.cfg and delete all the "luks-" precedding all UUID
restart
got kicked into busybox again this time I need to manually decrypt the partitions and then exit for it to boot normally finally
each time I hit restart or turn off the pc and then turn it on again I'll have to repeat the process indefinitely
hypothesis : when you made Peppermint to ask for password it was before grub was loaded, and then decrypt the partition, load grub and load the OS, but when the OS is loading, there is actually no password from before that get pass down, so the system has no idea of how to process the disk and kick the user into busybox, so that the user has to painstakingly decrypt the partition himself at each boot (yes I have to type the UUID manually each time I boot, for both the root and the swap, it is painful)
Lastly everything works, except that the swap wasn't mount, I have 4GB of swap which on htop shows 0 (I need to enable swap manually again)
Full article here : https://superuser.com/questions/1714597/peppermint-os-boot-failure-because-of-disk-encryption (yes I did take hours to write this painstakingly, the only thing I didn't include is how to mount the swap manually, but for those stuck with the same problem this is but a temporary solution and not a permanent, if no one really answer, I will have to research GRUB and LUKS into more detail because I have no experience in this and it will take a lot of time)
Please at the very least, fix this issue for the next version of Peppermint, the only reason no one speak up until now is because they don't use encryption, I just happen to be the odd one out
Lastly thank you for the OS, I am spending some time to explore it, but to find myself in such a problem the moment after installation is not quite appealing, although I did learn something, so no real loss here. Last comment the installer was hella fast, I thought I'd need at least half an hour for an old pc (intel codename merom core 2 DUO 1,66Ghz 2GB RAM) it did finish installing in 5 mins, KUDOS for that (the update later took so much more time, lol)
Last edit: New1997 2022-04-18
Thank you for trying PeppermintOS, you did not mention which partitions you attempted to encrypt. As the Calmares installer, only allows for the
/home partitionto be encrypted.If you choose to do a manual encryption of the
/,swapand the/homea method that is possible with the Ubiquity installer, it will replicate the result you have experienced to date.I didn't choose, the installer encrypt every partition, when choosing which partition to install Peppermint, I choose the entire disk and left to auto, and then check the encryption button, the rest was done by the installer, even the swap partition got encrypted
Last edit: New1997 2022-04-06
I just think carefully and trying to search as much as possible, but hen this occur to me : the reason that I got kicked into busybox might be because that the password from grub loader did not get passed down while booting, so ok, but what about the fact that I need to get dirty and use a live boot usb to edit the grub configuration file to remove the "luks-" before each UUID out in order for it to work, can you guys at the very least see to this "minor" configuration issue? because that would be of very much help and avoid any additional headache (on top of having to decrypt the partition manually at every boot)
Thank you (my tone seems a little bit aggressive sometimes so I must apologize in advance)
N.B an after thought, same goes for fstab, which made my swap not mounting in the first place
As things sit for now , to get encryption you will need a partition for /home separate from /.
You can then encrypt the /home partition and it will decrypt it during the boot process.
The notes on the debian pages for this are somewhat vague about this point.
Essentially , they are interpreted (locally) just as I mentioned.
Yes, I would much prefer a fully encrypted session.
For now, encrypting /home will suffice.
Thanks
KsWoodsMan
Thanks for your reply, so essentially bad documentation and being lead to this, I presume? May I ask that you include some warning to the installer to prevent further case (maybe I got too hasty and did not read it, if that is the case, I apologize, otherwise, might appreciate the heads up). also aside from getting kick into busybox, can you do something about "luks-" before the UUID (In GRUBS when booting and in fstab when mounting, for those who want to encrypt \ or more, just in every case even though it is only recommended for home partition)? Because things did not get properly mount because of it (in my individual case, I can just modify some config files, but for everyone else, it would be much easier if the dev just modify the template once and for all)
Thank you for you reply
FYI. Try a Manjaro install, an encrypted install through the auto-install method or manually encrypting the /root, /swap and /home will cause a failure. Only a manual install of the /home partition will work. I have had positive test on Manjaro and PMOS. Manjaro have been using Calamares since 2015 and is heavily influenced by them, due to the level of custom work they have carried out to improve it, over the years.
OK,
But my concern is, can you include the warning on your installation process to warn any future installer? and what about "luks-" that precede the UUID which make the mounting process go haywire, which I need to modify grubs and /etc/fstab to solve the problem? I do understand calamares and ubiquity is what is out of your power or are you trying to tell me that the "luks-" naming before UUID is part of ubiquity and that is where I should address my concerns? (and that means it is them who should do the warning to the people who will install your distribution to not use automatic partitioning while using disk encryption?) Please clarify so that I know who should be address about what, because even though you use both of that I thought that you can still customize your install so that there will be a warning for the users to not use disk encryption with automatic partitioning/whole disk installer or the "luks-" name in disk identifier, but if you do confirme me that you have 0 power over this and no chance at all to modify this particular setting, I will address ubiquity myself. But I still need your confirmation of these two issues, so that I can address them with all the correct information and not saying nonsense and having tell me to come back to you guys and wasting my time with back and forth.
Thank you for the time you take for reading my long reply
FYI.
In 2014 when Manjaro used the Ubiquity installer prior to their move Calamares circa 2015, was also a disaster for encrypted installs. I have made a note in our wiki, for encrypted installs. I have experienced this and other issue with different distros over the years, while distro hopping.
Your points have been noted, but the author of the Calamares installer which is considered to a an excellent installer, their frustrations were highlighted in their notes. Our team spent many hours, ironing out its various quirks to ensure a smooth install. The encryption process, has eluded Manjaro and us, but their dev team is larger and better financed than us.
I see from your profile you are fluent with many code languages, Calarmare is an open source project: https://calamares.io/ and you can either inform them or rewrite the entire installer to your satisfaction.
Regards the Peppermint dev team.
thank you for your reply, I'll try my best to see what I can do at my end (either informing them about the issue or trying to see how I can solve the problem) thank you for your time
@New1997
Proof of concept achieved, though it is not production ready. It is one of many back-burner projects we are working on to improve the overall quality of Peppermint.
nice!!! 👍👍👍, BTW I might have found a solution on my side too regarding getting kicked to busybox (initramfs), I'll be tweaking a bit and if it works, I'll post the solution to super user stack exchange as an answer to myself, so those with the same problem can refer to it. If I understand it correctly it only present on LUKS1 and not LUKS2. So in the future, this solution might not be necessary at all.
Thank you for your hard work and dedication and your time that you invested in this matter
Last edit: New1997 2022-04-18
Nope, what I said is wrong, lol. I misunderstood the text, I just reread, in LUKS1 the volume key can be found by user space, so having a key file doesn't change a thing, where LUKS2 the volume key is offloaded to the kernel keyring, so having a key file is less secure (and the first time I read it I thought that it can pass the password to the kernel, but upon rereading again, it seems to not be the case)
@cavy
Good news, I actually found the solution, full detail in https://superuser.com/questions/1714597/peppermint-os-boot-failure-because-of-disk-encryption/1716808#1716808 so you can reproduce the error and follow the solution steps.
The problem is indeed within "luks-" prefix, but not in the way I originally thought and I'll give summary here:
First of all, everything is configured "correctly" but somehow the /etc/crypttab is not working and did not decrypt the partitions, upon removing all "luks-" in /etc/crypttab, grub config files (and fstab for automatic mounting) and update initramfs (using update-initramfs -u) everything works as it should : you enter the password at grubs boot sequence first stage, and the later stage are decrypt automatically using a keyfile. I don't know what actually cause this issue, but I think I need to have a word with the team that deals with encryption (or crypttab file) about this bug, which is weird because in theory, this should have never happened.
Thank you anyway, maybe I should have a word with the team that do installer too, so that they should remove "luks-" prefix for now, since it was the cause of the problem. Cavy which one should I have a word with, ubiquity or calamares or both?
Thanks
It is less a bug in the installer and more of a conflict.
The keyfile wasn't going into the initrd to unlock the / filesystem on bootup.
The command you used to update the initrd put the correct keyfile in the initrd.
The "fix" has been in for several days, already having been thoroughly tested before it goes in the next release.
Thanks
KsWoodsMan
Oh!!! where did you get the info? I didn't know, I'd love to have that too, thank you very much!!!
I did see your answer in superuser, thank you very much
Where did I get it ?
It came to me one sleepless night, in a dream of dancing UTF-8 characters as I chanted bar-foo incantations, in the dark, to a blinking cursor.
KsW
haha, lol, that was funny 🤣🤣🤣🤣. That's not what I meant, I was meaning to ask if there are people to help you or other people who experience the same problem on other distro or if someone mentioned it on the chat of Peppermeint OS, or that you spent all this time reproducing the error and tried to figured it out on your own. By the way you answer, I'd say that you spend a lot of time to figure it out and there was little to no help from others. It was because you said that "the fix has been in for several days" but since no one mentioned it until you did a few days ago, I thought that it was a bug that was found by others on another platform/os and that it was fixed there first, and then it came to be known by you a bit later. (I do understand that you need some time to thoroughly test the "fix" before being sure before delivering the solution, but sometimes the people who are waiting for the fix need some update from time to time, just to know if it can be fix, or if their hypothesis was wrong, or if there is any other factors they weren't aware of, like, any information from time to time no matter how insignificant they are is still better then nothing, like to not leave them in the dark)
I hope that you don't take too much offense in what I have to say, but I was just curious of the exchange, the communication and the thought process of people to go from a problem to a solution (how they perceive the problem, thought process to formulate a hypothesis, the exchange between people with different hypothesis, the result of all the hypothesis and which hypothesis were proven true and contribute to actual solution, )
Thank you for your time for this particular problem (and thank you for reading this long text)
Funny in what way ?
Am I the only one that still writes code this way ?
This isn't a "me" effort.
We have a team of volunteers.
We each have our strong points in our skill sets.
Each of us use our skills where needed and follow due diligence to keep others, in the team, informed of what we are working on in the project.
Beyond that, follow the forum here for what's coming in the next release.
If you have a feature request, ask.
It's possibly already on "our list", to be worked on - as time allows.
If it is seen as a positive addition, without making the ISO grow, at some point it might be there.
If you need it faster, paid programmers don't come cheap.
KsW
Don't forget we hang out on matrix as well.. That can provide some up to date info for more of a real-time conversation....then you can always watch the git repos on codeberg we are pretty good about detailed messaging in our commits. At least I try to be..lol
Thank you for the info, will do, 😁😁😁