It is actually disabled through another override applied to the Marco (window manager), but I will disable that too for completeness.
Noticed another issue. I'm frequently asked to enter a login keyring after logging in. I have automatic sign in enabled, if that matters.
What a nice user experience. Keep it up folks 
1 Like
How to change monitor resolution?
(my monitor max 1600x1200 input DVI)
Add 'video=1600x1200' to the end of cmdline.txt.
I swear that login keyring issue occurs 100% of the time when automatic login is enabled. Also, I noticed what looked like a kernel panic the other day when shutting down. A saw a stacktrace and the device dumped text to a virtual terminal and I had to pull the cord. Any way to grab logs from that?
Thanks a lot! I've been testing BOTH the armhf and arm64 versions. There are some issues/observations I found:
- armhf
1.1 Cannot use HotSpot in NetworkManager. Keep getting:
kernel: netlink: 'wpa_supplicant': attribute type 213 has an invalid length.
See this bug report https://bugzilla.redhat.com/show_bug.cgi?id=1570903
1.2 Using x11vnc, I get graphical artifacts that make the remote desktop unusable, especially when opening a Qt app (https://github.com/LibVNC/x11vnc/issues/88)
- arm64
1.1 Hotspot can be started, but it is extremely slow and log is full of:
kernel: : nf_conntrack: table full, dropping packet
1.2 x11vnc actually works just fine here without any graphical artifacts.
So... I went in under Users & Groups and checked off automatic login. Now, thus far, no more login keyring prompt. Checking off the box during setup to do automatic login results in this behavior of the keyring popup. Another bug found.
The resolution has not changed.
Is the login box supposed to be like that on the side? Shouldn’t it be centered?
Setup:
Raspberry pi model 3 b+
Ubuntu MATE 18.04.2 beta 1
Hmm. I'd be glad to file bug reports on the issues I've found, but I have no clue what packages are affected by several of them. And it errors out when I run ubuntu-bug without a specified package.
No that's the way it is on normal UM, besides it would be over the logo then
Regarding the 64 bit image...
I have been playing with the 32 bit image since the beta was released. Not really formal testing but trying things which I do on my 3B and 3B+ Pi's which are running UN 16.04 do-release-upgraded to 18.04. So far everything I have tried seems to work fine. THANK YOU SO MUCH!!!
Today I decided to try the 64 bit image on a 3B+. I burned the image and booted the Pi with no problems. After installing all available updates and doing a reboot I logged on and launched Firefox. I called up the web site for a local TV station as a test. While this was loading (and the green drive access LED was glowing constantly) I was eventually able to launch the system monitor application. Most memory and all of swap was utilized. I opened a second tab in Firefox and observed the rest of the memory being consumed and the system quit responding. The graphs in performance monitor quit updating. Eventually the graphs started to move again and I clicked on the close button in Firefox. After some minutes the "You are about to close multiple tabs" dialog from Firefox appeared. I clicked OK and after several more minutes I pulled the power cord from the Pi. Which brings me to my question...
What exactly is the 64 bit image intended for? I read some discussion a while back about the wisdom (or not) of running a 64 bit OS on a Pi with only 1 GB of RAM. A 64 bit OS can obviously handle larger amounts of RAM and work more efficently. However, if there is no more RAM and no way to add any... Is all the hard work being put into UM 64 bit being devoted to a lost cause?
Ken
I believe there are performance benefits over using ARMv8 NEON instead of ARMv7 NEON on ARMv8 hardware.
1 Like
Thanks code_exec,
If you are trying to say that 64 bit code runs better than 32 bit code on ARMv8 (I guess this is what the 3B+ processor is?) - OK I understand that. However, as the Pi is RAM limited, is there other hardware, with more RAM, which will run the UM 18.04 Pi image? If so, what is it - perhaps I need to buy one.
Ken
Please allow me to contribute a bit of feedback on the beta image (32 bit)...
I just did a clean install, booted the Pi, applied updates, rebooted and enabled ssh (sudo systemctl enable ssh). I then started ssh (sudo systemctl start ssh). I was unable to connect from another computer. I traced the issue to the fact that the necessary host encryption keys were not present in /etc/ssh/.
This was easily fixed with sudo dpkg-reconfigure openssh-server
I do not recall ever having to do this on a new install of any distro. I have seen the ssh server disabled or not installed. In the former case some part of the initial installation/configuration process (I think) causes the keys to be generated and in the latter case the keys are generated as part of the ssh server package installation.
Perhaps this could be looked into?
TIA,
Ken
p.s. As I was writing this it occurred to me that this might be handled by raspi-config. However, when I looked I did not see anything about ssh. Perhaps that is on Raspbian.
No, since the kernel used by the image is designed for the Raspberry Pi hardware.
Thanks again code_exec
That is what I thought - thus my concern. I have tried the 64 bit versions of Suse (SLES, Tumbleweed and whatever the other flavor is called) on a 3B+. Rather a disaster. One would not boot, one would not access the update repos even though they were properly configured and the third would not connect to the network or something similar.) In ALL cases the response was so slow as to be unusable. The load times for programs were more in terms of minutes rather than seconds.
I guess we need some bright individual to figure out how to hot wire a couple more GB of RAM to the Pi 
Ken
I will post a new beta2 image in the coming days which resolves some of the issues discussed here. From the WIP changelog on https://ubuntu-mate.org/raspberry-pi/
- Added Raspberry Pi specific applications to the Software Boutique.
- Minecraft: Pi Edition
- Steam Link
- Disabled WiFi Power Management.
-
openssh-serverno longer pre-installed.
Well, it took me a bit to get sshd to start on boot. I am not sure, but I believe that putting it to a static IP address did make it start on boot, as I am pretty sure that it wasn't getting a DHCP address before sshd.service tried starting and stayed in a failed unstarted state. I did add networking.service to the After= in /lib/systemd/system/ssh.service
It was:
After=network.target auditd.service
now is
After=network.target auditd.service networking.service
so I have x2goclient installed and working over ssh
ssh is now working on boot
I also have HDMI plugged into the Mate PI using Picture in Picture on my 34" wide screen in the bottom right corner and I switch it from whatever pi I am working on, should I need a connected monitor. I am going to setup my 5" display instead, with a bluetooth keyboard. Pi's are so much fun.
Now to use them for Ansible learning along with VM's.
Thanks for all the hard work Whimpy and team.