The ubuntu-core-desktop README file says:

This directory contains an image of Ubuntu Core 22 with the GDM display manager loaded into the boot file system. It can be launched in a Qemu virtual machine by following these instructions:

Download and decompress the two image files and place them in the same directory.   

and the README then says:

• Add an image as a VM launchable from GNOME Boxes or virt-manager:_

Is Canonical going to add/include LXD's VM capability in this README as well?
Including any specific install/config instructions to start/utilize ubuntu-core-desktop in an LXD VM.

I can’t wait to try out Ubuntu Core Desktop. After reading about it on one of the computer news sites, I think it is an awesome idea. I even installed the openSUSE version of this and tried it out, using KDE and Flatpak instead of GNOME and Snap. I would love to try out your version.

I have found this repo, and its README gives me very helpful instructions on how to run it. However, the README references that there are two images to download. I cannot find a link to download these images anywhere! DuckDuckGo does not give me anything useful, and I understand the regular Core images do not come with a desktop.

Furthermore, are there any plans on building a general-use ARM64 build of this project? I run an M1 Mac, and therefore am unable run many Linux distributions (including regular Ubuntu) because they only provide binaries for Intel. (I understand that the Raspberry Pi images only include support for the Raspberri Pi’s specific bootloader, and will not work under standard UEFI. I am happy to be proved wrong, though.)

Our company is interested in evaluating the Ubuntu Core Desktop, but one major concern we have is image size. Devices we run are constrained to 16GB. Ubuntu Core was designed to have a small image size ("...image size of 260MB..." from https://www.zdnet.com/article/ubuntu-core-doubles-down-on-internet-of-things/). Is this the same case with Ubuntu Core Desktop? I wasn't sure if size was much of a consideration with Ubuntu Core Desktop since GNOME desktop is used. Or maybe this is configurable?

An img file conveerted to iso isn't bootable in a virtual machine!

Its not like you didn't have the consideration to provide an iso instead of wasting people's time on a half baked project.

We'll have to wait til later in the year for the iso release you're either unwilling or too lazy to post here.

I have been looking at this project to examine whether an immutable version of the budgie desktop is possible.

I have been looking at adding and removing snaps, generating images etc.

I can see that I will need a slight tweaks and a tuck with the ubuntu-session snap for us.

But I am missing the obvious ... what is the snap/snaps project(s) that is/are actually installing gnome-shell plus GDM? Initially I would need to look at substituting gnome-shell with budgie. Eventually replacing GDM with lightdm or similar.

TIA

UPower clients usually connects to the standard DBus signal org.freedesktop.DBus.Properties.PropertiesChanged to detect changes in the properties of a device, like the battery percentage or the charging/on-battery flag. But, for some reason, in the current images of ubuntu-core-desktop, this signal isn't received by the clients if they are snapped. In a normal Ubuntu desktop, the same snap does receive the notifications. Also, running the binary outside the snap, as root, it does receive the signals.

The current SNAPD code has specific apparmor configuration to allow to pass the PropertiesChanged signals:

To test this, you can download this snap: https://drive.google.com/file/d/1nsPB2amxZaqy5uy5bLAKg2mpvXqmq_L8/view?usp=share_link

Installing it in the system and running it with "snap run upower-test" will show all the properties for the path "/org/freedesktop/UPower/devices/battery_BAT0". Any change on their properties will also be notified (like when the power cord is connected/disconnected).

Running it in a classic Ubuntu desktop, it will work fine (as long as the "upower-observer" plug is connected, of course).

Running it in an ubuntu-core-desktop laptop will read all the properties, but won't detect the signals.

In the same ubuntu-core-desktop system, going to the root terminal and running it directly ("/snap/upower-test/current/usr/bin/upower") will work fine, showing all the properties and detecting the signals.

I have the simple-scan snap in candidate (44.0, Rev 792) on a core desktop system. When I scan a document and click the download button, the default location it tries to open, as a suggested download location, gives a permissions error. This is because the default location opened is /run/user/1001/doc, which nobody will have access to. This happens on the firefox snap as well, so I suspect this is a shared issue.

You can still click OK and then go select another location like ~/Downloads and download the document just fine though.

Most modern printers are driverless IPP printers, and their driverless IPP does not only work via network connections but also via USB, using the IPP-over-USB standard. To support this in Ubuntu Core Desktop, the "ipp-usb" Snap needs to get seeded. Once done this, driverless printers connected via USB are immediately available. The printer's internal web admin interface can then be accessed via http://localhost:60000/.

One of the things I see Snap packages can do is mount or unmount SMB/CIFS shares. That led me to thinking: how would the user mount a filesystem in Ubuntu Core Desktop? From what I can tell the mount binaries are not in the base image. Even if there were there, there would be no terminal in the final image to use them from.

If I were to provide them in a snap with a GUI, I would run into severe problems with where I can mount a share due to strict confinement, because it would have to be under either $SNAP_USER_COMMON or $SNAP_USER_DATA. This to me is not a very user-friendly location to store what is effectively document data. If I were to use the portals to mount it elsewhere, then I would need to use the portal a second time to unmount it (causing a paper cut that users might complain about). And there seems to be no way to have the system open a folder to the user in their file manager (allowing them to access the location that way), which is an API Windows and macOS both provide.

Furthermore, wouldn’t I still need to be root to successfully call mount(2)? Fixing this through use of sudo requires the terminal, and probably wouldn’t be allowed on the Snap Store in the first place.

How am I supposed to take advantage of the cifs-mount interface given all that I have explained above?

I have set up a regular Ubuntu VM, and used it to build an image I can boot in my VM software. I built this image using make pc.img in the root directory of this repo, with no modifications. However, the output image is a regular (non-Core) live image, with only one snap installed, which is not what I want. This happens despite the build process spending a good chunk of time downloading and unpacking snaps. What’s going wrong?

Hi,

I have downloaded a image from actions and I am going to use it on my secondary device in order to transition my current workflow into all Snap and Workshops LXC containers. I am wondering if I'll be able to update the installed OS from Settings or Terminal (apt upgrade)? Please let me know.

Best regards,

Following on from #61, I have downloaded, unpacked, and ran the image file downloaded from this actions run. I am using QEMU, with a similar command line to yours. I changed a few things to work on my copy of macOS QEMU, and I also converted the image from raw to qcow2 to save disk space. Here it is:

exec qemu-system-x86_64 \
	-smp 2 \
	-m 2048 \
	-net nic,model=virtio -net user,hostfwd=tcp::8022-:22 \
	-drive file=/opt/homebrew/share/qemu/edk2-x86_64-code.fd,if=pflash,format=raw,unit=0,readonly=on \
	-drive file=ubuntu-core-desktop.qcow2,cache=none,format=qcow2,id=main,if=none \
	-device virtio-blk-pci,drive=main,bootindex=1

However, when I do this, EFI gives me the error: error: no such device: ubuntu-boot, then goes to a black screen with an underscore and locks up. I have also tried using this image in the UTM app, with a similar command line. It does the same thing there. All things being equal, I’d rather use UTM, but I wanted to try raw QEMU since that’s what the README said. Are you able to give me any guidance here?