Score:0

Preventing Ubuntu from asking for password for encrypted data partition at startup (Ubuntu 20.04)

cn flag

I'm using Ubuntu 20.04.

I have a (LUKS) encrypted partition that I do not want to be prompted to mount on startup (at minimum, not providing a password for it on startup should not block the system from booting), but I can't work out how to disable this. Note that the partition in question is not a root partition - rather it contains optional data not needed by the OS and is not needed to boot the system

I strongly suspect I need to do something with Systemd but I can't work out what. I see there is a cryptsetup.target set to enabled, but running "systemctl disable cryptsetup.target" does not disable it.

There is nothing in crypttab and nothing related to the partition in question in fstab.

Right now, if I try and boot the system it says "Starting Cryptography Setup for srv..." Please enter passphrase for disk LOGICAL_VOLUME (srv): ...

The system does not timeout or boot unless I try and enter in the password 3 times - and this is happening before networking is even enabled.

David avatar
cn flag
The simple answer is you do not disable this. Why did you encrypt if you do not want security?
cn flag
@David I want to remotely access the system and enter in the password and bring up a fairly complex system on top of it. Why would you downvote the question because you don't know my use case?
David avatar
cn flag
Where is any of this info in the question? Also do not accuse someone of something that you do not know if they actually did.
cn flag
here is how https://dradisframework.com/support/guides/customization/auto-unlock-luks-encrypted-drive.html I agree with David though: it makes encryption useless. You would be better off removing it. and why do you assume it was David that downvoted? Most downvoterd don't bother commenting. edit: David :-)
cn flag
and do note the "Warning: following this guide will render disk encryption useless. You will be storing your encryption key, plain-text, in the unencrypted part of the disk!" in the beginning. You are better off removing LUKS. ssh private/public keys is what you want for what you posted in comment, not encryption.
cn flag
@David If you did not downvote my I apologize and I got the wrong idea because of the very small window between when you commented and the downvote occurred (and also that is typical on Superuser.com, which I am more familiar with). I will make my question clearer as it seems I implied but did not explicitly state that the partition in question was not the root partition.
cn flag
@Rinzwind Thank you for your comment - From your link I think I may have worded the question badly - I am not trying to strip the password off the root partition - this is a separate partition which should not need to be accessed to bring up the system - indeed, entering a wrong password (ie just enter) does not unlock the partition but allows the system to boot.
rfm avatar
mk flag
rfm
Was there an entry in /etc/fstab to mount this partition at boot?
cn flag
@rfm No. There was never an entry for this partition in fstab or crypttab (so it would not have been present on the versions in initrd or similar).
Score:0
cn flag

I think this should be as easy as adding the noauto option to the crypttab entry.

From the crypttab man page "noauto Entirely ignore the device at the boot process"

For example, an entry like this in /etc/crypttab would cause the my-crypt luks volume to be skipped over during boot:

my-crypt UUID=87938ea5-d6c2-4191-a56f-6d86e9ee none luks,noauto
Score:0
cn flag

I have more-or-less solved this - and without messing with Systemd.

The partition type I had set was "21 - Linux server data". When I change the type 41 - Apple RAID offline" and rebooted I was not prompted. While the type is not accurately reflected at least I now know that the partition type is being scanned and mounted if its type 21.

David avatar
cn flag
And you know this will have no effect to using permissions on files on this miss labeled disk?
cn flag
@David Thank you for your concern. I am not sure what you are saying here. I have a very solid understanding of the fundamentals of what I am doing and the weaknesses of my approach - I am just not paricularly good with (and dislike but need to live with) systemd. I am certain my solution is not elegant but other then slightly confusing disk management and it effect on the boot process has zero impact on what is on the disk. LUKS is still in tact on the partition.
cn flag
If anyone stumblrs across this - When I set up a similar server but adding a software (mdadm) RAID layer with LUKS on top of that I did not need to mess arround witj partition type identifiers - systemd ignored tje LUKS partition on startup.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.