Re: MX-23 Rpi Respin -- Beta testing

Message

#191 Post by **chrispop99** » Sun Dec 24, 2023 3:54 pm

Only able to do a brief sanity check - next couple of days here in the UK get taken over a bit - but it looks great. The issues I was seeing are all fully resolved. Great work @Jerry3904 and @dolphin_oracle !

Chris

#192 Post by **Jerry3904** » Sun Dec 24, 2023 5:02 pm

I totally agree! The workaround is nearly invisible and removes the problem. I appreciate the change in desktop icons.

Final thoughts
1) would like to see us consider one last time removing shortened desktop icon captions to give this very clear setup.

fullicontitles.png

2) think we might want to speak directly to localization, since the choices are embedded and small on the Installer. Maybe right in the Announcement would be good, and I can add a section to the Tips document adding the methods (RPi and Tools) of changing once installed. Along that line of thinking, I would like to point to rc-config, wondering if it would be better eventually to use that for the menu entry we have for R P Configuration:

rc-config.png

Otherwise, IMO, as Bugs Bunny always said: That's it, folks!

#193 Post by **fehlix** » Mon Dec 25, 2023 12:06 pm

dolphin_oracle wrote: ↑Sat Dec 23, 2023 10:25 pm
* perhaps disable gnome-keyring in auto-start,
but do enable gnome-keyring-daemon.service as user-service instead.
This might help pam to unlock the newly created login-keyring.
at least in theory...
I did try that, but there was no help.

OK, this works here:

To unlock gnome-keyring automatically at user login with password (not with auto-login):

* masks both user-services :
gnome-keyring-daemon.service
and
gnome-keyring-daemon.socket

* remove from autostart the temp-workaround zz-restart-gnome-keyring-1-time.desktop

Tested this way
First mounted mounted mx23.1_rc2_rpi.img writable
with
gnome-disk-image-mounter -w mx23.1_rc2_rpi.img
and
mounted rootfs from mx23.1_rc2_rpi.img at /media/fehlix/rootfs

Next:
Created two systemd user masks:
sudo mkdir -p /media/fehlix/rootfs/etc/skel/.config/systemd/user
sudo ln -s /dev/null /media/fehlix/rootfs/etc/skel/.config/systemd/user/gnome-keyring-daemon.service
sudo ln -s /dev/null /media/fehlix/rootfs/etc/skel/.config/systemd/user/gnome-keyring-daemon.socket

and removed zz-restart-gnome-keyring-1-time.desktop
sudo rm /media/fehlix/rootfs/etc/skel/.config/autostart/zz-restart-gnome-keyring-1-time.desktop

Now unmounted,
and wrote the image to an USB-stick, with help of BitJam's image writer:

Code: Select all

sudo dd-live-usb -f  mx23.1_rc2_rpi.img

Booted now with this USB-stick from a Raspberry PI 400.
Success Login keyring unlocked after login at the Lightdm login screen.
Also any newly created user, will immediately get the keyring unlocked
after user creation and logout login to the new user.
Suggest to get this onto the release image.
Thanks

#194 Post by **Jerry3904** » Mon Dec 25, 2023 12:42 pm

Thanks for working through this, @fehlix!

#195 Post by **Jerry3904** » Mon Dec 25, 2023 12:51 pm

BTW: I noticed when running a search for "Raspberry" in synaptic that the package rpi-chromium-mods is not installed, has in the comment "Pi-specific modifications." Did we ever look at that?

I'm going to install it this week and try to see what those patches are doing.

#196 Post by **dolphin_oracle** » Mon Dec 25, 2023 2:01 pm

fehlix wrote: ↑Mon Dec 25, 2023 12:06 pm
dolphin_oracle wrote: ↑Sat Dec 23, 2023 10:25 pm
* perhaps disable gnome-keyring in auto-start,
but do enable gnome-keyring-daemon.service as user-service instead.
This might help pam to unlock the newly created login-keyring.
at least in theory...
I did try that, but there was no help.
OK, this works here:

To unlock gnome-keyring automatically at user login with password (not with auto-login):

* masks both user-services :
gnome-keyring-daemon.service
and
gnome-keyring-daemon.socket

* remove from autostart the temp-workaround zz-restart-gnome-keyring-1-time.desktop

Tested this way
First mounted mounted mx23.1_rc2_rpi.img writable
with
gnome-disk-image-mounter -w mx23.1_rc2_rpi.img
and
mounted rootfs from mx23.1_rc2_rpi.img at /media/fehlix/rootfs

Next:
Created two systemd user masks:
sudo mkdir -p /media/fehlix/rootfs/etc/skel/.config/systemd/user
sudo ln -s /dev/null /media/fehlix/rootfs/etc/skel/.config/systemd/user/gnome-keyring-daemon.service
sudo ln -s /dev/null /media/fehlix/rootfs/etc/skel/.config/systemd/user/gnome-keyring-daemon.socket

and removed zz-restart-gnome-keyring-1-time.desktop
sudo rm /media/fehlix/rootfs/etc/skel/.config/autostart/zz-restart-gnome-keyring-1-time.desktop

Now unmounted,
and wrote the image to an USB-stick, with help of BitJam's image writer:
Code: Select all
sudo dd-live-usb -f  mx23.1_rc2_rpi.img
Booted now with this USB-stick from a Raspberry PI 400.
Success Login keyring unlocked after login at the Lightdm login screen.
Also any newly created user, will immediately get the keyring unlocked
after user creation and logout login to the new user.
Suggest to get this onto the release image.
Thanks

I thought about doing it that way. It’s essentially the way it works on sysvinit. Will make the adjustment.

#197 Post by **dolphin_oracle** » Mon Dec 25, 2023 2:43 pm

@fehlix keeping in mind that the pi uses systemd do we have any issues with missing sockets this way.

#198 Post by **fehlix** » Mon Dec 25, 2023 3:47 pm

dolphin_oracle wrote: ↑Mon Dec 25, 2023 2:43 pm @fehlix keeping in mind that the pi uses systemd do we have any issues with missing sockets this way.

The socket /run/user/$UID/keyring/control used by gnome-keyring's secrets
seems to get created by gnome-keyring-daemon itself, if not exists.
Not sure why systemd thinks to need all and every socket created by it's own.

#199 Post by **dolphin_oracle** » Mon Dec 25, 2023 3:51 pm

fehlix wrote: ↑Mon Dec 25, 2023 3:47 pm
dolphin_oracle wrote: ↑Mon Dec 25, 2023 2:43 pm @fehlix keeping in mind that the pi uses systemd do we have any issues with missing sockets this way.
The socket /run/user/$UID/keyring/control used by gnome-keyring's secrets
seems to get created by gnome-keyring-daemon itself, if not exists.
Not sure why systemd thinks to need all and every socket created by it's own.

Ok good

#200 Post by **fehlix** » Mon Dec 25, 2023 6:01 pm

Hmm, seems machine-id get's not re-generated during oobe-install as it always is the same as on the image.
Suggest to have dbus-uuidgen call also somwehre added to oobe.cpp, and not only on the normal mx-installer part.
Otherwise I guess systemd related local network activities might get confused with two identical machine-id's.
Probably an easy one.

Another point is about the FS-UUID for the ext4 partition, which is not change and taken from the image,
which creates confusion, eg. if some plugs-in a 2nd USB with the image, b/c two identical UUID cannot be handled by the kernel properly, and would make one partition invisible
Probably a bit more involved, as we cannot run uuid-generation during the oobe-installer b/c it's already mounted.
So somewhere to inject in the early expansion phase of the image during first boot.