Disk decryption screen and system loading screen look weird

[blind_confused]

hi, my problems aren’t urgent or anything, but I would appreciate a fix, if anyone knows what to do.
if this is related to the issues, I installed Slowroll with gnome not too long ago. It was my first openSUSE system, so I used the ISO.

first issue:
I noticed that other openSUSE users have a different password screen for disk decryption. Mine just looks like a line of text, and only allows to try typing in the password once. If I get it wrong, I see a grub screen, out of which there is no “return” button, I have to type “restart” and press enter.

second issue:
after typing in the password, and clicking on the kernel option, my screen looks like this for a little while, with a green “…” loading symbol in the middle, and vertical lines with “?” signs on the left. Is this how it’s supposed to look like?

I reported this specific issue to the main Slowroll dev before, along with several other bugs. He helped me with a few, and said that the rest of the bugs (including this one) are generic issues with Tumbleweed, and he cannot handle all of them. That’s why I decided to message here.

thanks in advance, if anyone knows any fixes.

[nrickert]

I see a similar screen. I checked this with Tumbleweed in a VM.

I don’t see your second screen with the “?”. But that might be due to a different BIOS. The first screen is grub requesting the password. And grub uses BIOS services for this.

On my main computer (with Leap), I don’t see this. But that’s because I have a separate unencrypted “/boot”, so the password is requested by kernel services.

[blind_confused]

@nrickert

I see a similar screen. I checked this with Tumbleweed in a VM.

isn’t this what it’s supposed to look like?
I saw someone use exactly the same screen, but with a Tumbleweed logo as well. Couldn’t find where I saw it, so I got a random picture from the internet, but it looked almost identical, except the lack of logo.
another user also said it allows you to try to type in the password more than once. That would be really useful, not having to restart the computer each time hah

[nrickert]

@blind_confused

isn’t this what it’s supposed to look like?

That’s what it would look like if you have a separate unencrypted “/boot”. And perhaps it looks like that if you are using “systemd-boot” for booting. In either of those cases, the kernel has been loaded before the password is requested.

However, when you are using “grub” for booting and do not have an unencrypted “/boot”, then the password request comes from “grub” before the kernel has been loaded.

Here’s an image when booting a VM:

That parenthesized strings is the UUID of the root partition.

[blind_confused]

@nrickert

In either of those cases, the kernel has been loaded before the password is requested.

the kernel, as in, the whole system kernel?

@nrickert

And perhaps it looks like that if you are using “systemd-boot” for booting.

I thought that was still unavailable on openSUSE.
but I guess it still wouldn’t change anything, since I prefer to encrypt the partition. It’s sad if there’s no other way around it. But oh well. Not the biggest issue I guess.

[nrickert]

@blind_confused

I thought that was still unavailable on openSUSE.

“systemd-boot” does work with Tumbleweed. I haven’t tried it with slowroll. There is a warning that it is not yet fully supported, but I think it is getting close.

When using “systemd-boot”, the kernel is put in the EFI partition which is unencrypted. Thus the kernel can be loaded before needing the encryption password.

[blind_confused]

@nrickert

When using “systemd-boot”, the kernel is put in the EFI partition which is unencrypted. Thus the kernel can be loaded before needing the encryption password.

oh, that’s nice, although makes me slightly concerned about security, in case the device does ever get into the hands of someone skilled enough to do something with all this.
and then you also lose the cool grub designs haha. But eh, that’s fine.

[hcvv]

@blind_confused

although makes me slightly concerned about security, in case the device does ever get into the hands of someone skilled enough to do something with all this.

It is your data you want to protect (I assume), not the kernel that can be downloaded from a lot of places (and even the source is open source).

[blind_confused]

@hcvv

It is your data you want to protect (I assume), not the kernel that can be downloaded from a lot of places (and even the source is open source).

oh. I thought that, if you have access to the kernel, then you can change the system in different ways, run commands, etc.
tbh, I’m mostly thinking with guesses here, since I’m not tech savvy at all.

[arvidjaar]

@hcvv

It is your data you want to protect (I assume), not the kernel

With kernel/inird on ESP nothing stops attacker from replacing them with custom build that captures LUKS password

@blind_confused

in case the device does ever get into the hands of someone skilled enough to do something with all this

[hcvv]

@arvidjaar

With kernel/inird on ESP nothing stops attacker from replacing them with custom build that captures LUKS password

Yes, I did not think about that. Is that protected by secure boot?

[arvidjaar]

@hcvv

Is that protected by secure boot?

Not if physical access to the system is available.

[hcvv]

@arvidjaar

Not if physical access to the system is available.

You are right. Physical access will nullify many security precautions.

Thus can one conclude that systemd.boot worsens the security in this respect?

[arvidjaar]

@hcvv

Thus can one conclude that systemd.boot worsens the security in this respect?

Without additional measures (like measured boot - pun unintended) - yes, I guess it can be put this way. Measured boot prevents usage of modified boot chain so it mitigates this problem (to the extent you trust TPM of course).

[hcvv]

Thanks for the explanation.

Interesting for those that think about switching to systemd.boot I assume

[blind_confused]

@arvidjaar

Measured boot prevents usage of modified boot chain so it mitigates this problem (to the extent you trust TPM of course).

this is interesting. How can this be enabled? And how can TPM be enabled?
I kinda know nothing about either, but I’m interested in getting more security on my system, so I would love to hear more about it.

[malcolmlewis]

@blind_confused do you have a TPM supporting 2.0 chip in your hardware, check the system BIOS… On my Aeon setup I’m only using TPM 2.0, no secure boot with FDE and systemd-boot.

[blind_confused]

how exactly would I know that my device supports it? Is it going to say that it supports it?

[malcolmlewis]

@blind_confused there should be something in the BIOS maybe under security to show if TPM is there. but you can just use a paraphrase (password) for encryption…

[blind_confused]

well, I didn’t find one mention of TPM, all I found was passwords for BIOS and the drive, out of which I enabled the BIOS one (since my system already has encryption anyway)