The writable partition (the actual rootfs) only expands on first boot, you could try to create a /home partition at the end of the disk (leaving enough wiggle room for “writable” to expand to a usable size still) right after you flashed to the device but before the first boot …
That said, i dont know if it works, you really have to try, 20.10 switched to systemd-growfs from the existing scripts which i dont have experience with (the former scripts would have worked this way) …
Its easy now you can update boot rom from raspbian OS latest with sudo raspi-config under boot options see this video takes a few seconds and a reboot. https://www.youtube.com/watch?v=suU09BMMFts
Not sure if it has been asked before but will we see a official Desktop Pi image of Ubuntu 20.04 LTS or do we have to wait until the 22.04 LTS release?
Thanks for the tip!
I think other people already asked but is there any possibility to have the Ubuntu flavours available? I expect Ubuntu Mate to also be available but I would like to see others like Kubuntu. I would also like to know if there is a way to make our own images for the Pi (with the desktop we want) or if there are any plans to have documentation on that.
Thanks for this release to get us closer to a real 64-bit OS on RPi! But…
Not sure what the support policy is for installing other desktop environments on top of a stock Ubuntu gnome desktop but the 20.04.1 server image handles this fine whereas both 20.10 images fail. So I hope 20.10 will be tested and fixed to carry this capability forward.
My experience is that 20.10 does not boot after attempting apt install of Mate desktop and one other I tried (forget which). Many desktop install methods documented online were tried (booting to commandline for apt install, using tasksel, using all possible display managers, etc) as was using the server image. All result in boot to the rainbow screen then nothing. No text, just a black screen.
Just installing lightdm worked to boot to gnome, but then apt install of Mate hangs at boot.
This is on an 8GB Pi 4 with 1440x900 display.
I know the other desktop flavors may eventually put out images with refinements but… if apt install runs- it should work! If an apt install is not supported on a platform it should print a message and exit. Or at least not leave the image in an unbootable, unfixable state.
One more request: Please consider creating an “ISO” version of the RPi build that has Grub/disk options/standard installer and works with the community UEFI boot SD image.
(P.S. I will try to get used to the default desktop but it seems scaled for small, touch displays.)
I have got the MATE desktop working with 20.10 in two different ways:
Upgrading a MATE 20.04 system to 20.10. I found a couple of problems, which I reported in this forum on October 26.
Installing MATE on a clean install of the 20.10 server. After installation of the server, then
sudo apt update
sudo apt upgrade
I did:
sudo apt install ubuntu-mate-desktop
I chose the lightdm option, when asked, and on completion (over an hour), I did:
startx
After installation of chromium, the only problem is that chromium takes a long time to start the first time after startup. This has been reported by several people, both here and on the RPi forum, and is being tracked and investigated in bug #1900783.
Great to have Ubuntu, but missing drivers for the various can boards we use (https://copperhilltech.com/pican-can-bus-fd-board-with-real-time-clock-for-raspberry-pi/) and the j1939 modules weren’t compiled in. With a new kernel like Ubuntu 20.10, we were hoping to take advantage to the linux J1939 stack in Linux directly.
Compiling drivers from source has been a bit troublesome but I guess that’s the nature of a first release.
Looking forward to follow up releases!
If you are writing the image on a Windows PC then use Rufus 3.12 to write it and select a persistent partition and choose how much space for the boot and persistent partition you want. This will set up separate partitions on your SSD. For more info see the various videos on the subject in YouTube or go to the Rufus website https://rufus.ie/
will that leave enough unparitioned room for the auto-resize of / ? else you will end up with something like only 50MB free on your rootfs …
Thank you john-chaam and ogra.
I’m not sure that my previous post was clear enough. I don’t want to setup an SSD with a separate partition for /home. It already exists. I am currently running 20.04, booting from an SD to the system root which is on the first partition of the SSD. The second, much larger, partition on the SSD is mounted to /home.
What I want to do is set up 20.10, booting to the SSD, but without deleting the /home partition. I understand that I can’t do this directly with RPI-Imager or Etcher, as these will only install to a disk, not a partition on a disk. I will read up about rufus to see if it will do this. In any case, when the system is booted, will it resize to the partition it’s in, or will it ignore the existing partitions and resize to the whole SSD?
My plan is to install 20.10 to an SD, boot to it, so that the system is setup and the resize takes place. I will then ‘dd’ the SD to the first partition of the SSD, and ‘dd’ the first 446 bytes ((the MBR) from the SD to the SSD. Of course, I’ll have everything backed up, as I know that dd means disk destroyer. Do you think this would work?
I do not think that Rufus will work for you in this case as one of the first things that Rufus does is to format the drive irrespective of the partitioning that you have previously selected.
It seems possible for you to use DD as you have described. However, I don’t know how you are going to ensure that the MBR block of data (your first 446 bytes) are going to be written to the first block of the SSD. As you would have already backed everything up then it seems worth trying.
I echo what @skellat said: it would be nice to have different flavors available. If the installer provided the option, or if the normal infrastructure built Pi images of the different flavors, that would be really nice.
Small note: When using a Raspberry Pi 4 with the Pi Foundation display (resolution: 800 x 480), the first boot workflow is partially off screen and there is no option resize the window or move to see the bottom. I hope I didn’t accept anything too crazy !!
using “Alt-Click” (i.e. holding the alt key while clicking) should allow you to move the window.
Tried it again, but the issue still remains.
Moving the windows isn’t the concern, it’s the height of the window. I also tried to use Alt + F8 per this official documentation but was not able to resize the window (I was able to move it with the Alt + F7, but still the window was too tall)
As an update to the above. UI installed Ubuntu 20.10 on a WD Green 240 GB SSD again not overclocked and it booted OK and went through the setup process without issue.
However, when trying to setup my monitor I could not set the desktop up to match my display size, I’m using an LG 32-Inch TV, with many different combinations of overscan on or off and different left/right/top/bottom fractions both positive and negative. Eventually the system responded to overscan_left and overscan_right settings and filled the width of the display. But, no matter what setting I made for overscan_top or overscan_bottom I could not get the desktop to fill the display.
Same issues with the audio defaulting to headphones. With Bluetooth I again was able to detect devices and pair. However, I could not setup or connect even after installing Blueman.
did you consider just using the setup menu of the TV to turn off overscan there ?
Thanks for the suggestion but that was not an issue as when I booted the RPI from the previous SD card with Ub 20.10 installed the overscan top and bottom settings worked OK and the desktop filled the screen. It could just be something unusual with the specific SSD installation. I shall try it again and see what materialises.
Hi, is there any plan to support H264 hardware decoding on ubuntu 20.10 for the rpi4 like there is on raspberry pi OS?
I’d like to reiterate again the notion of having choices for different flavors. What do flavors need to do to make this happen?