Support for Raspberry Pi 4

looks like it landed shortly after you mentioned it 4 days ago :slight_smile:

Got my 4GB model from in about 3 days flat.

I noticed that there was some new EEPROM setting which requires a ‘start.elf’ file/pkg on the boot drive in order to install? So the existing Ubuntu Core files did not work :frowning:

Running the Raspbian Buster atm (and having a blast)…

i have one on the way to me now and expect it to arrive before the weekend … if our kernel works without extra hackery i expect to have an unofficial core image for testing ready by monday (or perhaps even earlier) …


So i had my 4GB pi4 arrive this morning … but i fear we have to wait a little longer until an actual u-boot port exists.

i was falsely assuming there had been work done already, without bootloader there is indeed no way to roll a gadget snap … else it would have been a quick job :frowning:

1 Like

Even though we do not have a working u-boot tree yet, i played a bit on the weekend to get a kernel with full strict snap confinement together (that can serve later for an initial, unofficial kernel snap until the Ubuntu kernel team has something ready) … the (very hackish) build script and a link to the tarball are at:


So here we go … i have an experimental Ubuntu Core18 image for the Pi4 up at:

Please see the README file in that dir for details …

The u-boot tree used in the gadget is still in very early stages (mainly a pi3 u-boot with the most minimal patches to make the board boot at all and a binary pi4 dtb stuffed on top) and does only initialize 1GB of RAM even on pi’s with more physical RAM available.

Links to the sources for the snaps as well as a subdir with the model assertion used to build the image can be found under the above URL as well.


So here we go …

The image at

… now properly initializes the actual amount of physical RAM.

I have been using it since a week now to build snaps in an lxd container (using a USB3.1 SSD for the writable partition) as well as for various other tasks and it seems to be pretty solid (no crashes or anything)


I’ve installed your image on a Rpi4 4GB and I’ve also installed mir-kiosk, chromium-mir-kiosk, mir-kiosk-apps and got the black screen with a blinking (underscore) cursor.
I’ve tested all the stables, betas and edges; the same thing happens. I’ve messed around with snap interfaces a bit too but didn’t get anywhere.

Idk if that’s something that’s even supposed to work at this stage?

you might need to play with the dtoverlay= kms or fkms values in config.txt. i know the vc4 driver isnt fully ready to drive the vc5 hardware in the pi4 but i know that for example my omxplayer-pi snap works fine (only 1080p though, omxplayer does not support h265 yet) when either using no dtoverlay or with the fkms one (not with the kms one though).

1 Like

Could you pastebin the mir-kiosk log? That will likely point at the issue.

my suspicion is that the mesa version is not new enough … (though thats just a wild guess)

  1. I’ve done a clean installation of the Ogra’s Rpi4 image.

  2. Did $ snap refresh and stuff refreshed from the edge channel.

  3. Device automatically rebooted.

  4. Installed mir-kiosk from edge $ snap install --edge mir-kiosk

  5. Screen changed from ssh instructions to a black screen with blinking underscore cursor (afaik, that’s normal edit: Not normal!).

  6. I did $ snap install --edge chromium-mir-kiosk but from the installation feedback it said it first installed a stable and then an edge version. Is that normal?

  7. Nothing changed on the screen.

  8. I tried $ snap set chromium-mir-kiosk url='["",""]'

  9. Nothing changed on the screen

  10. I executed $ snap set chromium-mir-kiosk url='["",""]'

  11. Nothing changed on the screen.

  12. I $ sudo reboot the machine but still nothing changed after boot, just a black screen with blinking underscore cursor.

  13. I ssh again and try $ snap start chromium-mir-kiosk, the terminal responds with Started. but no changes on the screen.

I tried getting the logs as described here:

  1. I execute $ snap log mir-kiosk and it throws me an error error: unknown command "log", see 'snap help'.

But I failed ofc. You might wanna update that to say logs since that’s the first thing that popped up on Google.

$ snap logs mir-kiosk

Gave these:
2019-07-24T17:03:11Z mir-kiosk.mir-kiosk[1945]: std::exception::what: Failed to open DRM device node: Permission denied 2019-07-24T17:03:11Z mir-kiosk.mir-kiosk[1945]: [boost::errinfo_file_name_*] = /dev/dri/card1 2019-07-24T17:03:11Z systemd[1]: snap.mir-kiosk.mir-kiosk.service: Main process exited, code=exited, status=1/FAILURE 2019-07-24T17:03:11Z systemd[1]: snap.mir-kiosk.mir-kiosk.service: Failed with result 'exit-code'. 2019-07-24T17:03:11Z systemd[1]: snap.mir-kiosk.mir-kiosk.service: Service hold-off time over, scheduling restart. 2019-07-24T17:03:11Z systemd[1]: snap.mir-kiosk.mir-kiosk.service: Scheduled restart job, restart counter is at 7. 2019-07-24T17:03:11Z systemd[1]: Stopped Service for snap application mir-kiosk.mir-kiosk. 2019-07-24T17:03:11Z systemd[1]: snap.mir-kiosk.mir-kiosk.service: Start request repeated too quickly. 2019-07-24T17:03:11Z systemd[1]: snap.mir-kiosk.mir-kiosk.service: Failed with result 'exit-code'. 2019-07-24T17:03:11Z systemd[1]: Failed to start Service for snap application mir-kiosk.mir-kiosk.

nope, that is not normal … it should quickly flash orange, then turn black and show a mouse pointer. if you see a blinking cursor mir did not start.

1 Like

There may be other, earlier, errors but here Mir is failing to get access to the graphics DRM device. That explains why Mir doesn’t start.

You can get a longer listing with snap logs -n 100 mir-kiosk, but there is an incompatibility with kernel graphics module(s) in the image.

Have you tried ogra’s suggestion:

So I’ve done another clean Ubuntu Core install, did snap refresh and snap install --edge mir-kiosk and got the black screen with a blinking underscore cursor.
This time tho, here are the logs you’ve asked:

Changing the dtoverlay from dtoverlay=vc4-fkms-v3d to dtoverlay=vc4-kms-v3d makes Rpi4 unable to output any signal to the monitor. It’s black with my monitors no hdmi signal message.

Also snap command is not working for some reason after trying to install nano snap and rebooting.
$ snap logs -n 100 mir-kiosk
error: cannot communicate with server: Get http://localhost/v2/logs?n=100&names=mir-kiosk: dial unix /run/snapd.socket: connect: connection refused

The rest of the snap commands just hang and show empty line.

Got my 4GB pi4 last week, and it’s happily running raspbian.
I’m interested in accelerated opengl support in ubuntu core,
but haven’t gotten up the courage to try ogra’s build yet.

accelerated opengl isnt there yet on the Pi4 … but accelerated video playback works fine using the omxplayer-pi package as well as on the other pi’s (or on classic ubuntu) … only 1080p though, omxplayer upstream does not support h265 yet.

Looks like is a nice thread re gpu and rpi4 status…

Well, the thread you point to is about 64bit support (and indeed also mentions V3D on 64bit) … I dont plan to work on any 64bit images. The ones I built are for initial developer use until an official Ubuntu image exists.

Wether or not @ppisati plans to work on a 64bit kernel for upcoming official Ubuntu Pi4 images and when the Ubuntu kernels will be ready at all, I dont even know though.

Im a strong opponent of supporting arm64 on unsuited hardware.

64bit ARM means you allocate nearly twice the ram for each running application without gaining any beneift, unless the app actually makes use of 64bit registers… so effectively you only waste memory. It is a hard requirement on systems with more than 4GB of ram and it surely makes sense for software that has been specifically written for 64bit register usage though.

What i plan to work on in the nearer future is a classic image to provide along with the Ubuntu Core image though (but under the same restrictions, only until an actual Ubuntu image exists).

Any progress on core 18 for raspberry pi 4 beyond ogra’s july test image?

1 Like