Ubuntu Budgie plans for Raspberry Pi

Raspi & ARM64
1

(David - I have co-opted this thread for development of a Pi image for Ubuntu Budgie)

Ubuntu Budgie 21.04 technical preview now available (this link) Ubuntu Budgie plans for Raspberry Pi

Discussion points so far between myself and Sam

ARM support

  1. Initial target is a Raspi v4B 4GB RAM

This makes sense, especially as it seems to be the most common/readily available model. I have been using the 4GB for months, although I also just received my 8GB model. I’d assume the SD card speed / CPU speed is more of a bottleneck than RAM.

  1. Later look to expand with other ARM boards - need to research the best target e.g. Pinebook et al

  2. Would like to investigate Touch Screen support in general i.e. will need tweaks and tucks in budgie-desktop code and applets
    a. Integration with OnBoard i.e. the screen keyboard - how is this going to be done.

  3. Need a suggestion for the target Touch Screen resolution

I have been using mine at 1024x600 (native resolution of the one I bought). “Official” screen is 800x480. I am not sure if you can set the official screen larger than its native (i.e. my 3rd party one can be set as high as 1920x1080 but looks fuzzy because it doesn’t have that many pixels, but certainly useful when a menu or app extends beyond the native resolution). I can research what the popular available sizes are, and what others are doing. It’s easy enough to try out things too and give real you feedback with this. Best I can tell so far is 800x480 is common for 5", 1024x600 for 7", and 1280x800 for 10".

  1. Investigate and detail the best method to create SD Card images

  2. Would like to publish these images - where? SourceForge? Do we have any bandwidth issues if we self publish? Talk to Dustin. Talk to Martin Wimpress (UB Mate)

  3. Need a equipment shopping list to get going. Recommendations Sam?

Basics apart from the RasPi iself:

  • power supply (3A 5V USB-C)
  • possibly an inline switch add-on, if the power supply doesn’t have one, since Raspi has no power button. After shutdown, you have to unplug and plug in the raspi to restart it, so it just is a convenience really.
  • micro sd card of course - I currently use a SanDisk Extreme Plus 64gb (U3/V30 speed class). I have also used the Samsung Evo+ 32gb, and others, including a cheap 16GB. Though the 16GB felt slower, it has worked with every card I have given it so far.
  • obviously a way to burn the microsd card - probably have this already though
  • case is nice but not mandatory - if using one I do recommend one with a tiny cooling fan. I would reach the CPU throttle temperature fairly easily without one.
  • micro hdmi to hdmi cable possibly if using a regular monitor with hdmi input.

I took the easy way out and bought the kits that had all of these included (aside from the sd cards, but I have a bunch of those already). The Cana Kit is the only one available at a local store, which is the main reason I went with that.

  • touchscreen - I have been using EVICIV 7" touchscreen I found on Amazon. I am very happy with it but there may be better or most cost-efficient options. It uses micro hdmi and usb for the touch input, so it works right out of the box. I would guess any that use the usb/hdmi setup should work fine. I want to test the official screen, see if its supported out of the box or if special drivers are needed, since it uses the ribbon cable and driver board. It is supposed to be delivered Friday so I will play with it this weekend. I also have a full size monitor that I use with it too.

  1. Best way to-do development on a Raspi?
    a. I presume should VNC/SFTP to the Raspi?

    b. Guess need some-sort of compatible keyboard for the Pi - part of the shopping list?

Tried several usb mice / keyboards, all have worked fine. I have been using the Logitech MK270 wireless combo. I like it because it only ties up one usb port for both, and I can put them in a drawer when I am done and leave the Pi looking clean without a bunch of wires. But before, I was using wired usb mouse and keyboard I had lying around, no issues. Originally I started with an iPazzPort KP-810-19S - worked well except for its size, and worse - it “sleeps” after a very short time so I was always waiting for it to power on. It was okay if only used occasionally, but using a full size keyboard and mouse makes things so much easier. Calculator, email, Volume up/down and mute buttons on the keyboard even work correctly.

c. Creating debian packages. We could use launchpad to create ARM64 images. Alternatively could cross-compile stuff. The latter needs investigation how to do this.
9. Software support:
a. Should we initially target a minimal installation? If so how? Is this going to be some-sort of bash script to deinstall packages and generally cleanup? Could use the list of packages here to cleanup with https://bazaar.launchpad.net/~ubuntubudgie-dev/ubuntu-seeds/ubuntu-budgie.groovy/view/head:/desktop.minimal-remove
b. Maybe later think about a full-fat image. May need a tweak and a tuck for the package selection. Needs investigation

  1. Would like the initial appearance of the Raspi Desktop to look very much like the intel desktop.

Without a doubt, I agree 100%. In fact, while I customize my other Budgie installs, I have left my raspi almost exactly how it is with the default appearance. It looks really nice as is. I think the picture I posted a couple months ago is ShowTime at its default size, just centered. So yeah, it needs to be scaled.

a. ShowTime would need a tweak to determine the initial resolution on launch and reduce the font size - the default font size would be too big for the lower resolution Raspi
b. The menu would need a more development to size for the desktop
c. Alternatively we could ship an "raspi.layout" with different - more resolution appropriate applets for the raspi.

  1. We should do development as open as possible. Suggest use the discourse forum here and/or ubuntubudgie.org/blog - Sam ping Nikola for access if we go down the blog route.

  2. Target for the initial release should be 21.04 via our own release mechanism
    a. Maybe 21.10 we could target a Canonical produced raspi image. Ubuntu is doing this now for 20.10 - so can discuss this with the Ubuntu team.
    b. for 21.10 need a strategy - need to meet beta testing, release candidate and release testing requirements. On going support for ARM specific issues. All not to be underestimated for an “official release”

  3. Later we could consider re-rolling for 20.04 - so if we target multiple releases then we should automate/script everything so that releases should be as painless and reproducible as possible.

  4. Does Ubuntu Mate have a release production method? Discuss with Martin Wimpress.

  5. Involvement with the raspi community? Maybe raise on an raspi forum - could get more people to help hopefully.

  6. Raspi supports SNAPS - so our welcome screen will work here - we already publish an ARM based snap for ubuntu-budgie-welcome.
    a. Need to review welcome and see which bits need reworking to be ARM specific.

Desktopify does install this snap as well by default when installing Budgie. Easy enough to dig into this one.

17 … and I imagine more stuff to be added after considering the above!

Some “gotchas” I have found:

  • Using the Ubuntu server image doesn’t take into account the region. Without a real “install”, I keep forgetting to set my location / timezone.
  • Server image has a user “ubuntu” set up, forces you to set a new password on first login. Mate image looks like it sets up the user/password on first run.
  • Not an Ubuntu issue but Raspi doesn’t have a real-time clock module. It sets the time on startup using NTP. (does this by default) Drawback is no network, no time.

The good thing is that a lot of stuff works by default. My network printer, external HD, and a few other things work no different than on my other machines. Tilix is fixed on 20.10. Some apps don’t have ARM versions yet (like Slack). However, other than it being a bit slower, when using on a full monitor with mouse and keyboard, its easy to forget its a RasPi.

2

Hi and welcome,

our plans revolve around 21.04 - myself and @samlane are currently considering what is the best strategy to produce a RPi image optimised for budgie. This would include (if possible) good support for raspi touch-screens.

Its early days yet in the planning - but certainly we would like to work with enthusiastic community members like yourself.

In general we are looking to automate the whole production process so that a smooth and seamless production of builds such as 20.10/20.04 could be done.

3

Hello,

I have been quite happy booting Ubuntu Budgie 20.10 from USB SSD so far.

In addition to @fossfreedom’s comments, some general feedback for anyone interested.

I have been running Ubuntu Budgie on a Rpi4 4gb for a while now, originally just manually installing and tweaking it on the 20.04 server image, but then using desktopify. I recently got a Rpi4 8gb to play with as well. I have since upgraded to 20.10 and have Budgie running on both of them. The 4gb currently has a 7" touchscreen, and boots from a 120gb USB SSD drive. The 8gb is running on a full monitor and runs off a 64gb SD card. (It will be SSD one of these days…) Both have been running well without issue.

(I did not ever try Budgie 20.04 from USB boot, only sd card)

When I switched to 20.10 during the testing/beta period, I also used desktopify (through a small modification to the script) to install Budgie 20.10 on it. However, now that Canonical has given us an official desktop image, that is my current starting point to install Budgie. Its great that the official Raspberry Pi imager has built-in support for the Ubuntu 20.10 desktop image now. I much prefer the desktop image route because it has the initial setup for creating a user / selecting locale, etc… No more being user “ubuntu”.

I simply installed Ubuntu Budgie onto the Ubuntu desktop image:

sudo apt install ubuntu-budgie-desktop

snap install ubuntu-budgie-welcome --classic

(I am a big fan of Budgie Welcome)

I also remove Gnome shell because I don’t use it:

sudo apt purge gnome-shell gdm3

I also remove some of the Ubuntu software that is not part of Budgie - nautilus, deja-dup, eog, shotwell, gnome-terminal, totem, snap-store, and probably some more I’m forgetting.

I haven’t seen any negatives since switching to 20.10 vs. 20.04. In fact, my biggest annoyance with 20.04 was Tilix not working correctly without a workaround, but that has now been resolved. Again, so far, no issue with SSD boot from USB.

Here is what I am running now. The little guy on the left is the 4gb model booting from that PNY SSD drive. The one on the right in the clear case (sorry, image is kinda dark) is the 8gb booting the SD card. And yes, the big one is running a VNC connection to the little 4gb model :slightly_smiling_face:

IMG_1587
IMG_15872016×1512 468 KB

1 Like
4

Nice. What make/model of tiny monitor is that you’re using?

5

It is an EVICIV 7" touchscreen. Honestly, I see so many similar ones available, so I think a lot of them might actually be the same one, just branded differently by different companies. It has its pros and cons. The biggest pro is although it only has a 1024x600 native resolution, you can actually set it as high as 1920x1080, though it becomes blurry. This is important because there are some dialog boxes and programs that will go off the screen at 600 pixels, so it is a good fail-safe when that happens.

The cons are that it does suffer from image retention when something bright is shown for a little while, and that can take several minutes to fade completely. Not horrible, but it happens. Also, when used in a multi-monitor setup, this touchscreen’s geometry area gets messed up (though it can be fixed with xinput / map-to-output, its a pain to have to do that all the time.)

I also have tried the official 7" touch screen. Instead of HDMI, this uses a DSI ribbon cable. The biggest drawback to this one is that it is 800x480 resolution. This is too small to be practical, and unlike the other one, it cannot be set to a higher resolution. During the Ubuntu install, a lot of guessing was involved since the back / next buttons were off the screen. There is a trick using xrandr --panning if you absolutely need a bigger area to display large windows though, but this DOES mess up the touch screen geometry. It does function really well for the multi-monitor setup though. No issues with the touchscreen calibration there.

If anyone else has been using any other types of touchscreens with the Raspberry Pi, I am very interested to hear about any pros and cons.

6

Thanks! I’m interested in these smaller monitors–ideally, something in the 10-13" range–in case I decide at some point to build a DIY “laptop”.

1 Like
7

Thanks for the replies from David and Sam. I followed Sams recommendation, and installed ubuntu-budgie-desktop and ubuntu-budgie-welcome --classic onto the 20.10 desktop image. Then removed gnome-shell gdm3 and nautilus

I’ve spent a couple of days and trying to familiarise myself again with the Budgie desktop and the workflows. Performance is good, slightly better than the official desktop image, boot from SSD all works. A couple of the applets have some lag.

I’m happy to assist with testing etc for future builds.

I see Ubuntu Mate now have RPi 20.04.1 and 2.10 RPi images available

1 Like
8

What applets have lag issues?

The next step probably is to come up with a bash script that can be run on-top of the official ubuntu raspi image.

This script should deinstall all the ubuntu apps and then install the ubuntu-budgie-desktop and snap package.

9

I was trying various applets combinations in the top panel.

Lightpad was often slow, especially first time opened in a new session. Combinations of Lightpad, Budgie Menu, App Menu, would also occasionally cause the panel to freeze, though I could sometimes still launch apps from the plank dock and interact with other desktop elements.

The new application grid in Gnome 20.10 could probably replace much of the need for these three applets, especially if used alongside something like ulauncher

10

Thanks! I’m interested in these smaller monitors–ideally, something in the 10-13" range–in case I decide at some point to build a DIY “laptop”.

Pine64 has stuff like that

1 Like
11

Not sure what help I can offer here besides feedback and testing, but I am certainly willing to help in any way possible. One of my favorite things about the Raspberry Pi is the ease of swapping out the sd card as needed - practically zero worries an installation getting messed up.

12

I’m looking for someone who is interested in tailoring our solution for the Pi 4 - so

  1. reviewing the existing software - nominating good quality alternatives if necessary
  2. interest in developing producing an image to be distributed - take inspiration/work with our friends in the Ubuntu Mate community
  3. has interest on learning how to produce debian packages - i.e. tailoring what we have for the Pi. Initially just on their own computers. Later learning about uploading to a launchpad PPA
  4. Looking at Budgie Welcome and making changes to orientate it to a Pi (basic HTML knowledge and maybe a bit of python)

Sam if you are interested then there is a spot on the team! Let me know.

1 Like
13

Been using Budgie on both pi 3 & 4 for a while, happy to help with this project too on the development side of things

Super keen on a more official budgie for raspberry pi

14

What are your interests jess?

A bit of code tweaking? Showtime needs to be more dynamic in terms of its font size to take into account the connected monitor size.

@samlane is looking at bash scripting installing and removing packages based on the Canonical raspi 20.10 image.

What we need here is to script a method to unpack that image, run Sam’s script and then repack.

Generally we need to take a very careful look at the desktop installed on a raspi and see what needs to be tweaked to make it run on the lower resolution raspi screen devices.

I am sure there is a lot more todo … just depends on where your interests are.

1 Like
15

Cool! Will go have a go with showtime
have been budgifying ubuntu server images w/ this script here
keen to reorganize a script to work from chroot instead of from the pi

16

ok - initial look around at the raspi image from Canonical - it is a .img file and can be edited via a chroot.

Basically a bunch of command line stuff https://raspberrypi.stackexchange.com/a/856

Might be easier to-do this on the raspi itself - but would be interesting to see if the instructions in that link still work for the latest 20.04/20.10 x86 based system

17

I have had very good luck so far modifying the preinstalled Ubuntu Raspberry Pi desktop image to be a Ubuntu Budgie install. I haven’t tried the qemu method yet, but it is fairly straightforward to do it directly from the Raspberry Pi using chroot. Some of these steps could be polished and enhanced I am sure, but it works fairly well.

First, I download the image file, and unzip it:

wget https://cdimage.ubuntu.com/releases/20.10/release/ubuntu-20.10-preinstalled-desktop-arm64+raspi.img.xz

xz -d ubuntu-20.10-preinstalled-desktop-arm64+raspi.img.xz

In order to mount the image correctly, we need to get the offset for the second partition:

parted ubuntu-20.10-preinstalled-desktop-arm64+raspi.img unit B print

After running this, you get a list which shows the offset needed (we want the Start for #2):

Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start       End          Size         Type     File system  Flags
 1      1048576B    269484031B   268435456B   primary  fat32        boot, lba
 2      269484032B  8750718975B  8481234944B  primary  ext4
        ^^^^^^^^^

I then made the mount point, and mounted the image file to it using the offset:

sudo mkdir /mnt/pi        
sudo mount -o loop,offset=269484032 ubuntu-20.10-preinstalled-desktop-arm64+raspi.img /mnt/pi

apt will throw a lot of errors because it can’t find /proc, /dev, and /sys, so this is needed:

cd /mnt/pi
sudo mount -t proc /proc proc/
sudo mount --rbind /sys sys/
sudo mount --rbind /dev dev/

chroot into the image:

sudo chroot /mnt/pi

Though I had internet access in chroot, DNS lookups were failing, so I had to add a nameserver. (I used 1.1.1.1 because, well, couldn’t be easier to remember and type in)

echo 'nameserver 1.1.1.1' >> /etc/resolv.conf

To remove gnome-shell and gdm3: (I remove gdm3 before installing Budgie, that way it doesn’t pause to ask to select lightdm or gdm3)

sudo apt purge gnome-shell gdm3

I also remove these to match the Ubuntu Budgie default install more closely:

network-manager-config-connectivity-ubuntu gnome-initial-setup ubuntu-report eog gnome-terminal nautilus xdg-desktop-portal-gtk apt-config-icons-hidpi gamemode seahorse yaru-theme-gnome-shell yaru-theme-gtk yaru-theme-icon yaru-theme-sound ubuntu-wallpapers gnome-session-canberra ubuntu-settings gsettings-ubuntu-schemas xcursor-themes realmd adcli gnome-getting-started-docs shotwell remmina totem thunderbird deja-dup

A little cleanup:

sudo apt autoremove

Now the fun part… make it Budgie!

sudo apt install ubuntu-budgie-desktop

Ok, these lines I borrowed from desktopify. Essentially, it changes the initial setup to use the Ubuntu Budgie slideshow instead of the default Ubuntu:

sudo apt-get -y install --no-install-recommends oem-config-slideshow-ubuntu-budgie
sed -i 's/oem-config-slideshow-ubuntu/oem-config-slideshow-ubuntu-budgie/' /usr/lib/ubiquity/plugins/ubi-usersetup.py
sed -i 's/oem-config-slideshow-ubuntu/oem-config-slideshow-ubuntu-budgie/' /usr/sbin/oem-config-remove-gtk
sed -i 's/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu-budgie/' /usr/sbin/oem-config-remove-gtk

For good measure, I reset resolv.conf when I was done with it:

echo -n "" > /etc/resolv.conf

The downside of this method is that snaps cannot be installed this way, so ubuntu-budgie-welcome isn’t on it (not yet at least), but it can certainly be added after setup. But with this method, anyone can customize the image.

2 Likes
18

Nice!

fwiw qemu is a real pain with Pi + 64 bits anyway-
the wonky pi boot procedure means one must manually extract and rearrange the paths of vmlinuz / ramdisk / tree / etc etc to get qemu sorted-

(Really ancient 32 bit pi images could get away with generic versatilepb in qemu, pretty useless at this point)

Have collected random bits and notes on this here:


(…though most of this particular project is either broken or missing…)
1 Like
19

Folks - I’m using disks to write the .img file

when writing the .img to the microsd card do you write the img and partition the extras space left on the SD card separately i.e. then its seen as a separate ‘drive’ in the file-manager

Or do you resize the written .img via (I’m guessing) gparted?

20

If you are asking what I think you are, I have just been burning the entire image to the microsd. The “writable” partition (I think it’s called) will resize itself on first boot. You should end up with 2 partitions on the SD card, but the writable one expands.