Score:2

Ubuntu Encrypted instalation in external Hard Drive booting in recovery shell "GNU Grub"

mx flag

What I did:

  • 1 - Copied Ubuntu Studio 22.04.2 LTS to a Ventoy Pendrive

  • 2 - Chosed Try or install Ubuntu

  • 3 - Clicked in the icon for install in the desktop

  • 4 - During installation, Set the language to Brazilian Portuguese and default keyboard

  • 5 - Selected Full instalation erasing disk (An external HD)

  • 6- Flicked the encrypted checkbox

  • 7 - Chosed a phrase password

  • 8 - Removed the instalation media and reboot after the instalation

  • 9- During the boot, I enter the password for encryption

  • 10 - It boots into GNU grub, where I can see partitions like: (hd0), (hd0,gpt2), (hd1), (hd1,gpt4)

When I hit the command "boot" from the gnu grub, it'll say that I need to load a kernel first.

I made a fresh install repeating the exact same process, and the result was the same.

Note that if I make the exact same process but don't encrypt it, it will works.

guiverc avatar
cn flag
Being specific as to your *native* language can help, as when your install the system your *live* system was operational & may have thus used different native keyboard mapping which the OS had control over at install time (*ie. key you used for full disk encryption*), however at decryption time there is no OS running so your machine *firmware* controls keyboard & key entry (*thus maybe using English/French/Chinese or a different language to that used at install; brand/model specific as managed by firmware*). Your *unstated* release (inc. point release) matters here, and you gave no details.
Vitor Oliveira avatar
mx flag
@guiverc, sorry, I made some changes in the question to be more clear, as I've made some mistakes before
guiverc avatar
cn flag
I'll provide https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions and suggest you scroll down to "*PASSPHRASE CHARACTER SET:*" and read that section; as the 'passphrase' used at install time MUST MATCH what your machine will allow you to enter at unlock time (*keyboard being OS controlled at install time, firmware controlled at boot*). Sorry I'm a *dumb aussie* and have no experience here, but you need to use keys that are the same when OS is running & what your *firmware* allows as I understand it (*but my understanding is limited here sorry!*)
guiverc avatar
cn flag
(my last comment is my understanding of this bug - https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1827501 ... Lubuntu & Ubuntu Studio share the `calamares` installer, which is what is involved here... installer & the *full disk encryption* that Lubuntu/Ubuntu.Studio use that means little is available before providing the key & access to encrypted disk is possible!)
guiverc avatar
cn flag
FYI: What you're experiencing is what is expected WHEN you enter an *incorrect* passphrase to decrypt. Your 'entry of keys' as understood by your machine *firmware* at decryption time does not match your 'entry of keys' at install time as understood by the running OS & `calamares` at encryption time. The *gitlab.wiki* link I provided I believe is your answer UNLESS you made a typo when attempting to decrypt your system at reboot (*or install time*).
Score:3
cn flag

I'll provide https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions and suggest you scroll down to

"PASSPHRASE CHARACTER SET:"

and read that section; as the 'passphrase' used at install time MUST MATCH what your machine will allow you to enter at unlock time (keyboard being OS controlled at install time, firmware controlled at boot).

This is my understanding of this bug. Lubuntu & Ubuntu Studio share the calamares installer, which is what is involved here, or really the installer plus the full disk encryption that Lubuntu/Ubuntu.Studio use that means little is available on your disk before providing the key & access to encrypted disk is possible!

What you're experiencing is what is expected WHEN you enter an incorrect passphrase to decrypt. Your 'entry of keys' as understood by your machine firmware at decryption time does not match your 'entry of keys' at install time as understood by the running OS & calamares at encryption time.

The gitlab.wiki link I provided I believe is your answer UNLESS you made a typo when attempting to decrypt your system at reboot (or install time).

Sorry I'm a dumb aussie and have no experience here (using english which is identical to the firmware of the systems I use), but you need to use keys that are the same when OS is running & what your firmware allows as I understand it.

Vitor Oliveira avatar
mx flag
Thanks! I've made a new installation using common characters for the password, and it works now!
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.