sdm and Bullseye 2021-10-30 versions with Desktop issue

[gitbls]

The versions of Bullsye 2021-10-30 with desktop also have vlc installed. There is some sort of apt issue in these images, which causes an apt-get upgrade to fail due to a dependency issue with some of the vlc components. This can be easily observed on "virgin", unmodified IMGs from RPT.

Curiously, apt upgrade works.

sdm uses apt-get (which is recommended for scripts), so the upgrade fails.

I'm waiting to learn more from the RPT team on the issue, but am preparing an update to sdm that will add a --apt-dist-upgrade switch. This switch will cause apt to do a dist-upgrade rather than just an upgrade.

However, dist-upgrade may have other effects (the docs are not completely clear) so I'm not going to make it the default for all apt-get upgrade scenarios.

In the meantime, if you find that sdm is not updating, you can do the following:

• sudo /usr/local/sdm/sdm --explore /path/to/2021-10-30-bullseye-armhf.img
• Once "in" the nspawn simply do an apt upgrade or apt-get dist-upgrade
• exit the image and you're done

[mcguirepr89]

Have you noticed any issues with the --poptions samba switch for Bullseye? I have had trouble with samba actually working (failing silently on the server side) on Bullseye

[gitbls]

Can you clarify what you mean by "had trouble with samba actually working"? Are you saying that it doesn't start, or that it doesn't function correctly once started?

[mcguirepr89]

Clients cannot connect.
From the server side of things everything works well. Configuring shares is the same and avahi (or zeroconf?) that announces the services works fine, and no errors appear in samba server logs (though I've not tinkered with verbosity for that yet). Ports are opened and ready for connections, but something happens when trying to connect.
(I had this particular breakage on a system that has since been wiped away, so I will rebuild the problem and have a much better description of the failures from the client side. I will also try increasing some of sambas logging (I'm sure that's just in smb.conf somewhere that I've not yet needed).)

I thought you may have run into it (seems to be becoming more commonly noticed since the change to bullseye).

I'll get back to you with better info

Update with some info:

This is the standard greeting when trying to connect to samba through Gnome Files on x86_64 Debian Buster. No login prompts or group prompts at all.
If you explicitly connect to the server using its smb://serveraddress you will get closer in that you get to see the available shares:

BUT, when you click the share, you are entered into an endless login loop.

The loop isn't a credential thing, either, as you can set the share to allow guests and Anonymous will also fail :/

From a command line,smbclient always fails with tree connect failed: NT_STATUS_ACCESS_DENIED

And finally, from the server side, the logs only mention: smbd[164625]: pam_unix(samba:session): session closed for user nobody

I certainly don't expect you to have answers for this, merely thought you may have run into this since sdm sets up a samba server.

Update: I re-added the 'pi' user as a samba user and everything works again.

Sorry for the distraction!

[gitbls]

TBH I don't run Samba much on my Pi systems. I see that you sorted out (at least) one problem, which is great!

[mcguirepr89]

Me neither, but my BirdNET-Pi users are Windows folks, and I figured a Samba share would be a kind gesture to put into the next image (though I found a new issue with how it is handling file names that contain special characters! 😄 )

[mcguirepr89]

If I end up using sdm to add a Samba share to my image, I will let you know (and will put together a pull) if that little samba user recreation is necessary.

[gitbls]

Don't forget that you can do the smbpasswd for the pi user in your customphase in the post-install phase!