Rolled Daedalus back, now password no longer requested

[oliverjames]

Having rolled back to Daedalus 6.5.5 ver. 6.5.7 the system boots to a screen giving number 1-5 boot options, without asking for the password entry.

Is there a way to fix this please?

[BarryK]

Very strange.
Has something gone wrong with this file:

/mnt/${WKG_DEV}/${WKG_DIR}sfs/settings/initrd/CONFIG

My 'CONFIG' file has:

Code: Select all

KEYMAP='us'
ALLOW_ASK_PW='yes'
KB_HW_PROFILE='LenovoLenovoCalliopeUSBKeyboard'

Most importantly, ALLOW_ASK_PW='yes' is read by the 'init' script in the initrd.

[oliverjames]

Very strange.
Has something gone wrong with this file:

/mnt/${WKG_DEV}/${WKG_DIR}sfs/settings/initrd/CONFIG

My 'CONFIG' file has:

Code: Select all

KEYMAP='us'
ALLOW_ASK_PW='yes'
KB_HW_PROFILE='LenovoLenovoCalliopeUSBKeyboard'

Most importantly, ALLOW_ASK_PW='yes' is read by the 'init' script in the initrd.

Indeed, my equivalent 'CONFIG' has:

Code: Select all

KEYMAP='de-latin1'
ALLOW_ASK_PW='yes'
KB_HW_PROFILE='ATTranslatedSet2keyboardLogitechUSBReceiver'

[pp4mnklinux]

It happened to me in 2024. 19th November

viewtopic.php?p=136103#p136103

It happens when you restart using a full folder backup and restore.

I used it to restore system of one of my partners who forgot her password.

[oliverjames]

@pp4mnklinux

Yes, that's what I get on boot.

Can I get back to the initial password entry situation; I imagine that the password also unlocks encryption?

[BarryK]

Yes, that's what I get on boot.

Can I get back to the initial password entry situation; I imagine that the password also unlocks encryption?

Are you able to bootup and use without having entered a password?

If so, look at /mnt/wkg/, without entering a password if it asks, are folders 'files' and 'releases' all fully readable, nothing encrypted?

If the answer is yes, then you have lost encryption of the folders.

The init script in the initrd runs this test, doing it right now on my computer:

Code: Select all

# fscryptctl get_policy /mnt/wkg/releases
Encryption policy for /mnt/wkg/releases:
	Policy version: 2
	Master key identifier: 9372654c6294e90119488421bf1435e2
	Contents encryption mode: AES-256-XTS
	Filenames encryption mode: AES-256-CTS
	Flags: PAD_32
# echo $?
0

The return value "0" is used to test whether the 'releases' folder supports encryption.
If this is zero, and ALLOW_ASK_PW=yes, then the init script will ask for the password.

[oliverjames]

Are you able to bootup and use without having entered a password?

If so, look at /mnt/wkg/, without entering a password if it asks, are folders 'files' and 'releases' all fully readable, nothing encrypted?

If the answer is yes, then you have lost encryption of the folders.

The init script in the initrd runs this test, doing it right now on my computer:

Code: Select all

# fscryptctl get_policy /mnt/wkg/releases
Encryption policy for /mnt/wkg/releases:
	Policy version: 2
	Master key identifier: 9372654c6294e90119488421bf1435e2
	Contents encryption mode: AES-256-XTS
	Filenames encryption mode: AES-256-CTS
	Flags: PAD_32
# echo $?
0

The return value "0" is used to test whether the 'releases' folder supports encryption.
If this is zero, and ALLOW_ASK_PW=yes, then the init script will ask for the password.

I can bootup without the password and in /mnt/wkg/, all folders 'files' and 'releases' all fully readable, so it appears that nothing is encrypted.

Regarding the init script in initrd I'm a bit lost. If I explore /mnt/wkg and click on initrd I get to the init script, but there I get stuck.
I've attached a copy of the init script in case that is helpful.

Thank you

[BarryK]

The only way that I can think that the 'files', 'releases' and '.session' folders would lose their encryption is if you made copies of them and are now using the copies. The copy of any of those folders will not be encrypted.

What I posted earlier, will confirm that 'releases' folder no longer supports encryption:

Code: Select all

# fscryptctl get_policy /mnt/wkg/releases

[oliverjames]

The only way that I can think that the 'files', 'releases' and '.session' folders would lose their encryption is if you made copies of them and are now using the copies. The copy of any of those folders will not be encrypted.

What I posted earlier, will confirm that 'releases' folder no longer supports encryption:

Code: Select all

# fscryptctl get_policy /mnt/wkg/releases

That could well be the case. I flashed a Clonezilla image the last time something went wrong.

[BarryK]

The only way that I can think that the 'files', 'releases' and '.session' folders would lose their encryption is if you made copies of them and are now using the copies. The copy of any of those folders will not be encrypted.

What I posted earlier, will confirm that 'releases' folder no longer supports encryption:

Code: Select all

# fscryptctl get_policy /mnt/wkg/releases

That could well be the case. I flashed a Clonezilla image the last time something went wrong.

If that is the case, the easiest way to recover is to create a new frugal install.

1. Firstly, run that fscryptctl to confirm encryption no longer supported.

2. Create a new folder with vmlinuz, initrd and easy.sfs and create new entry in the boot manager.

3. Bootup the new installation, entering a password. This will create folders files, releases and .session with encryption enabled.

4. Copy everything from the old install, the one that lost its password:

Say that the new install is in /mnt/sdc2/easyos2 and your password-less install is in /mnt/sdc2/easyos1

# cp -a /mnt/sdc2/easyos1/files/* /mnt/sdc2/easyos2/files/
# cp -a /mnt/sdc2/easyos1/.session/* /mnt/sdc2/easyos2/.session/

That's not copying everything, it depends what other stuff you need to copy over, such as flatpacks and containers.

Note, Easy has a snapshot mechanism, use that to recover from a broken update.
Clonezilla is not the tool to use.