MX Linux Forum

Jerry3904 wrote: ↑Thu Dec 28, 2023 5:15 pm I can't confirm what Chris is seeing. A clean install with autologin enabled and I saw the two-entry box that fehlix mentions. Every other login/reboot requires a password when I launch the browser.

BTW: somehow RPi gets around all this, and I wonder again about that package we do not have installed: rpi-chromium-mods (need to check name again in a minute when I'm back on the Pi 5)

the package sets up a couple of default items, but doesn't do anything to the keyring.

Man, I'm not getting all of this.

I think the long and the short is that I'm going to let this sit one more day, maybe fix a typo in the installer that is about 8" high on my screen, and if nothing comes up release on dec 30.

there will need to be a mx-system update to accommodate some version strings that I need to test but other than that should be good to go.

things for future:

1. locale selection before installer oobe starts up, so that oobe is localized (briefly discussed with AK-47)
2. changing UUID (trickier than it looks)
3. um, that's it from my list of things, so anything else that comes up.

in the meantime, will write up the build instructions so this can be redone later.

That sounds good to me. I'll take a last look at the Wiki Tips tomorrow especially with regard to Chr and login (will try to waffle a bit...).
Release tomorrow would be good so that just maybe DW might mention it Sunday night.

future things on my list
1. incorporate rc-gui into main menu alongside (?) raspi-config
2. (need to check notes)

dolphin_oracle wrote: ↑Thu Dec 28, 2023 8:31 pm I think the long and the short is that I'm going to let this sit one more day, maybe fix a typo in the installer that is about 8" high on my screen, and if nothing comes up release on dec 30.

there will need to be a mx-system update to accommodate some version strings that I need to test but other than that should be good to go.

things for future:

1. locale selection before installer oobe starts up, so that oobe is localized (briefly discussed with AK-47)
2. changing UUID (trickier than it looks)
3. um, that's it from my list of things, so anything else that comes up.

in the meantime, will write up the build instructions so this can be redone later.

PARTUUID may be easier to get adjusted, b/c the used /etc/resize-root-fs
shows a good way to adjust the partuuid by using sfdisk.
Currently it boots with the identical PARTUUID like the one on the image,
But it not so important/crititcal/conflicting like the FS-UUID,
b/c fstab holds only the PARTUUID, which would not create much conflicts
with an additionally mounted sd/usb.

FS-UUID is indeed trickier b/c as soon we boot we are mounted with the existing FS-UUID
of the mounted filesystem. And b/c the file system is mounted we cannot change the filesystem-UUID.

Anyway Wiki/FAQ may be consided to be adjusted asap to reflect
autologin vs password-prompt consideration/ explanations.
Good work.

I've realised what I do that produces a different result with the Chromium keyring issue.
I elect to 'Continue' without entering a password, then confirm that action. On subsequent boots I no longer get the keyring prompt.
I realise that this could be considered a security risk, but I guess most users would accept that tiny risk in return for not entering the password every boot, bearing in mind typical Raspberry Pi usage.

Perhaps the Wiki entry could reflect the different actions?

Chris

Thanks. I'm in the middle of a complete test now and have finally seen what you describe. Will create a new paragraph in main text on "Security" to explain.

I've revised the Tips document: https://mxlinux.org/wiki/rpi-tips/

Jerry3904 wrote: ↑Fri Dec 29, 2023 7:27 am I've revised the Tips document: https://mxlinux.org/wiki/rpi-tips/

May be I'm not seeing this in th link above. So commenting here anyway: User can always change the protecting password, by installing "Password & Keys" with the package seahorse, where they can empty the password, which does has security and privacy implications,
or changing the password of the login-keyring e.g. in case user has changed the normal login-user password, where the login-keyring password would also need to be manually changed to be the same as the user-password, otherwise
auto-unlock at login would not work.

I didn't add that there b/c I considered it outside the document's scope. But I can add a link to (your) Wiki discussion of Gnome Keyring (which may need some revision as you indicate).