How can I reset the `/etc/crypttab’ file so that it is the same as it would be if I installed the system with an encrypted boot floppy?
Huh? How do you image you can “reset” files? Either use a backup or read documentation what goes in. Or install Manjaro in a VM the same way and check that.
1 Like
AFAIK, /etc/crypttab contains the path to file(s) with valid keys (or hashes of them) to unlock the encrypted container.
If there is only that key (and no corresponding password)
and you lose the key (the key file)
then you are literally screwed.
You can only “reset” it by supplying the matching valid key file.
Or, when there is also a passphrase.
Then you can open the volume and either extract the original key or set a new one and use that in your key file.
Thanks, Nachlese.
Due to some mistake of mine, the password for the root partition is now requested twice instead of once when booting.
Once the system is booted, the password of the 2nd partition with the data is requested, which has always been the case. But now the password manager also asks for confirmation twice, where I have to enter my root password.
I don’t know how to get rid of this.
P.S. Some people in the forum just like to write something without really saying anything 
Hm. And you cannot find out or remember what that was?
… there is the shell history - if you used the command line
Thankfully nothing is lost.
this is probably not helpful:
I never had to supply a password for individual volumes.
And /etc/crypttab was always empty (not needed).
I only need the password to open the container in order to boot.
But my setup is “custom”. It’s Arch - not Manjaro.
With an unencrypted /boot partition.
(it is actually created by using the EOS installer )
I don’t think I can help you. 
This line was already in this line /etc/crypttab
# <name> <device> <password> <options>
luks-"of-root-partition" UUID="of-root-partition" /crypto_keyfile.bin luks
What I have done. I added this line in /etc/crypttab
luks-"of-data-partition" UUID="of-data-partition" /crypto_keyfile.bin luks
Later I deleted the line again but the problem stayed. I suppose something has been written into
/crypto_keyfile.bin
But may be even more probable now, something “wrong” has been written into the password manager or in the files in /dev/mapper/.
Probably sticking my nose in where it’s not needed, but I wonder if the request for the root password could be due to the recent removal of the Manjaro hotfixes package preventing drives from auto-mounting, and if this suggested solution from another thread might resolve it:
1 Like
Why are you censoring UUIDs? Do you think anyone can do anything with that info? =)
Also why is root patition even in crypttab?
1 Like
Thanks Scotty. I will have a look at it and check it. That may be also the reason the log in process has changed.
Don’t you think your tone is a bit harsh? 
No matter which UUID code is there, it certainly does not help to solve the problem, as it is individual for each partition. Therefore I have simply inserted a filler text.
You may ask calamaris installer when you install encryption with swap file. 
This is very off-topic and will probably offend some people. They must deal with it.
It has always amused me how people can complain about tone when it’s written text and no audio involved. 
If you want to analyse and take offense at someone’s “tone” over the internet, well, then you just want to pick a fight.
Note: “Tone” is completely different from attitude, or even insults.
3 Likes
I have reinstalled my complete system. And looked into KDE partition manager. The settings were disabled: “no automatic mount”
Still after confirming your password the data drive root password confirmation is still required. It very looks like it is due to an update you mentioned because this was never before like this.
We can hope that Manjaro team will fix it soon.