Lubuntu 18.04.2 arm64 image with OEM setup

[ed10vi]

Hello.

I'd like to share an image I've built for Raspberry Pi 3 B / B+:

Lubuntu 18.04.2

Just flash and resize the partition with Gparted
An OEM config tool will promt to setup your session

How I did it:

Build the Gadget tree:

Code: Select all

git clone -b classic https://github.com/CanonicalLtd/pi3-gadget.git
cd pi3-gadget
sed -i '/1 multiverse/d' Makefile
echo "      - boot.scr" >> snapcraft.yaml
sudo snapcraft prime --target-arch=arm64
cd ../

Copy the build scripts from livecd-rootfs:

Code: Select all

cp /usr/share/livecd-rootfs/live-build/auto ./

At the beginning of the config file in the folder auto, set IMAGEFORMAT to ext4

Code: Select all

IMAGEFORMAT='ext4'

Near line 932, modify the hook 999-raspi2-fixes.chroot to be something like this:

Code: Select all

#!/bin/sh -ex
echo "/dev/mmcblk0p2       /               ext4    defaults,noatime   0       1" > /etc/fstab
echo "/dev/mmcblk0p1       /boot/firmware  vfat    defaults           0       2" >> /etc/fstab
echo -n "#" >> /etc/fstab

oem-config-prepare
rm -rf /boot/firmware/*

Build the image with ubuntu-image:

Code: Select all

export UBUNTU_IMAGE_LIVECD_ROOTFS_AUTO_PATH=auto
sudo ubuntu-image classic -p lubuntu -s bionic -a arm64 --subarch raspi3 -d pi3-gadget/prime

[code_exec]

Great! I'll try out the instructions when I have time to make images for other Ubuntu flavours such as Xubuntu. Good work!

[flanylla]

Anyone got a 3B+ to test? I don't have a spare SD card or decent sized USB, and don't want to take chances just yet

[paolo-pi]

Yes , I have 3B+
It seems run well
I had problem with bluetooth but used
/etc/rc.local

#!/bin/sh -e
/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
exit 0

and works

Paolo

[gilius]

I tested on my 3B+ and went to install an application, but the system then hung on updating and installing some rasp3 DTB files - presumably needed for the software to work!?

[code_exec]

Hello.

I'd like to share an image I've built for Raspberry Pi 3 B / B+:

Lubuntu 18.04.2

Just flash and resize the partition with Gparted
An OEM config tool will promt to setup your session

How I did it:

Build the Gadget tree:

Code: Select all

git clone -b classic https://github.com/CanonicalLtd/pi3-gadget.git
cd pi3-gadget
sed -i '/1 multiverse/d' Makefile
echo "      - boot.scr" >> snapcraft.yaml
sudo snapcraft prime --target-arch=arm64
cd ../

Copy the build scripts from livecd-rootfs:

Code: Select all

cp /usr/share/livecd-rootfs/live-build/auto ./

At the beginning of the config file in the folder auto, set IMAGEFORMAT to ext4

Code: Select all

IMAGEFORMAT='ext4'

Near line 932, modify the hook 999-raspi2-fixes.chroot to be something like this:

Code: Select all

#!/bin/sh -ex
echo "/dev/mmcblk0p2       /               ext4    defaults,noatime   0       1" > /etc/fstab
echo "/dev/mmcblk0p1       /boot/firmware  vfat    defaults           0       2" >> /etc/fstab
echo -n "#" >> /etc/fstab

oem-config-prepare
rm -rf /boot/firmware/*

Build the image with ubuntu-image:

Code: Select all

export UBUNTU_IMAGE_LIVECD_ROOTFS_AUTO_PATH=auto
sudo ubuntu-image classic -p lubuntu -s bionic -a arm64 --subarch raspi3 -d pi3-gadget/prime

I believe that you need an ARM64 chroot for this if you are building on an x64 host because the snapcraft command gave me several errors when I tried building directly on x64. In an ARM64 chroot, it didn't.

[code_exec]

Ubuntu Budgie image is currently being built using these instructions, I will try it out tomorrow.

I wonder if these instructions can be adapted to create a live ISO that uses the generic kernel (the CMA bug will be fixed when 19.04 is released) that can be booted using u-boot. The Ubiquity installer would still have to be adapted to be compatible with the Pi. This requires the following:

[*]The partitioner creates a MBR partition table instead of a GPT partition table to make the resulting installation bootable on the Pi.
[*]The partitioner doesn't format partition #1 as an EFI System Partition because this partition type is unbootable on the Pi.
[*]At the installing bootloader stage, the '--no-nvram' flag is passed to the GRUB installer so that the installer doesn't fail to install GRUB.
[*]At the end of the installation, Ubiquity copies the bootloader files and a prebuilt u-boot binary to the FAT partition to make the resulting installation bootable on the Pi.

[code_exec]

I've finished building the image, but where is it stored?

[feelslikeautumn]

Ubuntu Budgie image is currently being built using these instructions, I will try it out tomorrow.

I wonder if these instructions can be adapted to create a live ISO that uses the generic kernel (the CMA bug will be fixed when 19.04 is released) that can be booted using u-boot. The Ubiquity installer would still have to be adapted to be compatible with the Pi. This requires the following:

[*]The partitioner creates a MBR partition table instead of a GPT partition table to make the resulting installation bootable on the Pi.
[*]The partitioner doesn't format partition #1 as an EFI System Partition because this partition type is unbootable on the Pi.
[*]At the installing bootloader stage, the '--no-nvram' flag is passed to the GRUB installer so that the installer doesn't fail to install GRUB.
[*]At the end of the installation, Ubiquity copies the bootloader files and a prebuilt u-boot binary to the FAT partition to make the resulting installation bootable on the Pi.

There is a discussion of how official ISOs are created here https://community.kde.org/Neon/Installa ... ble_images . Basically live-build/livecd-rootfs is used to build the majority of it, then the grub efi bits are added by a little understood (outside of canonical) process. That's not a problem though, you can just reuse the files from an official iso.

Ubiquity has never been used for arm64 so there is code missing around the bootloader to use. Not a problem it is just python and the necessary additions are trivial.

I'm not sure the --no-nvram thing is necessary if you give the correct mount point and give the fat partition the bootable flag. There is already code for detecting removable drives. Certainly works on usb.

[feelslikeautumn]

[*]The partitioner creates a MBR partition table instead of a GPT partition table to make the resulting installation bootable on the Pi.
[*]The partitioner doesn't format partition #1 as an EFI System Partition because this partition type is unbootable on the Pi.

It depends how far you want to go with this, but if you wanted patches accepted you would have to probably define a new sub arch for the pi. I tried to get raspbian interested in this https://bugs.launchpad.net/raspbian/+bug/1723203 . It is much easier just to preseed it which is the approach I took with my Ubuntu installers https://ubuntu-mate.community/t/status- ... /18054/132 . Machine in use can then be selected by the bootloader.

[*]At the end of the installation, Ubiquity copies the bootloader files and a prebuilt u-boot binary to the FAT partition to make the resulting installation bootable on the Pi.

Again this can be solved several ways. If you are just targeting the pi, then you could copy the files to /boot/efi in the squashfs and these should be copied by ubiquity automagically to the correct partition. However, if you are making a true generic iso then users will already have these files to boot the iso, so it is nothing to worry about.

[code_exec]

Ubuntu Budgie failed presumably because I mistyped something in the config file, so I'll see if I can build an Xubuntu image instead.

[feelslikeautumn]

Ubiquity has never been used for arm64 so there is code missing around the bootloader to use. Not a problem it is just python and the necessary additions are trivial.

I had a go at writing a patch https://bugs.launchpad.net/ubuntu/+sour ... ug/1819765