UbuntuMate 18.04.2 on PINN (NOOBS)

Support & Help Requests Raspberry Pi
#1

I am the author PINN, my fork of NOOBS that allows easy installation of many OSes (currently over 60 different OS variants) on the Raspberry Pi.
(See https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574 and https://github.com/procount/pinn/blob/master/README_PINN.md)
It has many more features than NOOBS such as: reinstallation/replacement of individual OSes, backup and restore of OSes, disk checking and recovery features etc. that make it more of an OS administration tool.

I previously made UbuntuMate 16.04 available for use with PINN, and I have now just completed adapting 18.04.2 beta1. This will be soon be made available in the next version of PINN under the testing category until it comes out of beta, when it will revert to the General category.

@Wimpy - The main reason ubuntuMate 18.04 requires the next version of PINN is the way this version handles its partitions, relying on the Label names of the partitions for reference. PINN is a multi-OS installer and boot manager, and its recent versions allow multiple copies of the same OS to be installed using its ProjectSpaces features. However, because of 18.04's use of partition labels, I have had to exclude 18.04 from being installed multiple times as I imagine the wrong partitions will end up being linked to, or shared between the 2 instances.

I imagine this use of labels is because of the extensive configuration that UbunutuMate does at startup and using labels makes it easy to find the other partitions, assuming they are unique. But I don't remember this being a problem with 16.04. Is there any specific reason for this change?

Due to the relocation of the OS partitions in a multi-boot environment, PINN updates a few files on installation (like cmdline.txt and etc/fstab). Typically for an SD card installation it will use the /dev/mmcblk0p6 notation and for installation to a USB device it will use the PARTUUID=123456-06 notation. For 18.04, PINN needs to maintain its use of label references.

I don't know if there is an easy adaption for this, or whether it is indeed necessary, since I imagine users who install UbuntuMate will only install one version for use as their main OS, but I'm just highlighting the issue.

I notice uboot.bin is present on the initial image, and some other uboot files get created after initial configuration. Are these actually used in the RPi environment, or are they just hangovers from the configuration process being suitable for many other targets?

Thanks,
ProCount.

1 Like
#2

@procount What. A. Coincidence! :smile:

I was reading about PINN earlier this week so that I could produce appropriate boot and root tarballs for PINN. Thanks for making a start on this :slight_smile: If you've got any tips for me the create what you need, do let me know!

I switched to using labels to follow the convention used in the new Ubuntu server images, and it also made USB booting work without any manual tinkering by users. Sorry if this has caused you a headache.

As for uboot.bin, this is installed by flash-kernel which is used to configure initrd for the custom Raspberry Pi kernel used by Ubuntu. As it happens, I don't use uboot in 18.04 but instead, use the traditional boot loader because uboot has different binaries for Pi 2 and Pi 3. That would require I make/publish multiple images and something I want to avoid.

I'm working on beta2 images today, I'll see what I can do to clean up uboot cruft from the image. That said, when a kernel update is applied flash-kernel will deposit uboot in the appropriate places but this will not be an issue for PINN I think?

Thanks for getting in touch, I am keep to make sure Ubuntu MATE 18.04works well with PINN :slight_smile:

1 Like
#3

That's great to hear! :smile:

I have a couple of articles on how to create a "Custom OS" for PINN:
One in the README_PINN.md
https://github.com/procount/pinn/blob/master/README_PINN.md#how-to-create-a-custom-os-version and another on my Wiki which is more of a tutorial.
https://github.com/procount/pinn/wiki/How-to-Create-a-Multi-Boot-SD-card-out-of-2-existing-OSes-using-PINN
You can find the result of my first conversion on sourceforge and use that for reference:
https://sourceforge.net/projects/pinn/files/os/ubuntuMate1804/

I am in the process of adding support for sha512 checksums to the tarballs, so there will be some additional work on top of the above links. See https://github.com/procount/pinn/wiki/JSON-fields for some hints prior to this being documented fully.

I kept the same slides that I used for 16.04, so feel free to update them to advertise the latest features and benefits of 18.04

Using labels is not a problem, it just causes the restriction that only one copy of UbuntuMate18.04 can be installed on the same drive. I just added a small test to make sure such OSes are not installed multiple times to avoid them referencing the wrong ones.

When the OS is installed, a custom partition_setup.sh script is used to adapt any references to the actual partitions used, so you can adapt this as you need. Raspbian uses partuuids to enable the OS to be installed on both USB and SD card.

Thank you for not using UBoot! AFAIK, it expects boot information to be found on partition 1, so I often end up taking it out to make an OS suitable for PINN. I don't think it adds anything when used on the RPi, but I appreciate it is useful for supporting other SBCs. The "cruft" is not an issue for PINN as it is not used. It was just a note.

Thanks for your support. If you need any help adapting for PINN (or want a beta of the next version for testing) just let me know. :smile:

2 Likes
#4

I've got a few jobs queued up at the moment, but I will work on creating what you need for PINN. I'll point you at the code when I start on it :slight_smile:

#5

No worries. Whenever you're ready. I'm still in testing phase for the next version of PINN.

2 Likes
#6

Looking forward to updating my pi. Is there any update on this project? Thank you.

#7

Hi Martin,
Any progress on this? Some users are asking me for updates
Thanks.

#8

Hello,
I am just checking if any progress was made with ubuntu and pinn,
I have extracted the boot and root across to empty project spaces, and now I believe cmdline.txt is replaced on ubuntu server images

#9

@Wimpy - I'm trying to create a Ubuntu 20.04 installation with PINN, but need some help/advice.

Since PINN is multi-boot, I have had to remove Uboot again, but Ubuntu server now installs fine.
After an apt update/upgrade it still works.
I have also managed to install ubuntu-mate-desktop and ubuntu-desktop ok.

  1. The first problem comes when I use software updater to update/upgrade. After a restart, Ubuntu will no longer boot - it just stops with a blank screen and no disk activity. I think this update process is messing with initrd or something similar, maybe trying to re-instate uboot or changing disk partitions, but my changes to avoid uboot still seem to be there, so I don't understand why it won't load from this point onwards. The same thing happens to both ubuntu-desktop and ubuntu-mate-desktop. Any ideas?

  2. Where is the script to expand the root partition on first boot? It is not necessary with PINN, so I'd like to remove it, although it doesn't seem to do any harm. I guess it is in systemd somewhere.

  3. Although Ubuntu now uses labels to reference the partitions, I would like to revert this so that I can install multiple copies of Ubuntu on the same SD card. It partially works, but I think many systemd scripts rely on the the labels. Would this be easy for me to revert or are there too many places for me to have to edit? If it's reasonable to do, please could you give me some pointers to which scripts I need to modify or search for.

Thanks.

#10

I've created an Ubuntu 20.04 install booting off USB with PINN.

First and foremost:

  1. Make sure you have updated they Pi4 EEPROM as described here

    https://www.tomshardware.com/how-to/boot-raspberry-pi-4-usb
    or
    https://tynick.com/blog/05-22-2020/raspberry-pi-4-boot-from-usb/

From README_PINN.md#booting-an-os-with-pinn

  1. Format the USB device as FAT 32 and copy the PINN files to it, just as you would for a normal PINN installation on an SD card.

  2. change bootloader to updated bootloaders that allow USB boot from

     https://github.com/raspberrypi/firmware/tree/master/boot

 cp start4cd.elf recover4.elf (to boot Raspberry Pi 4 from USB, only need to update this file) in PINN

  3. Alternatively if you already have an existing PINN installation, mount RECOVERY partition and update the same file start4cd.elf -> recover4.elf

From README_PINN.md#installing-oses

Local Images on USB stick

Due to the increasing size of OSes, it is becoming increasingly difficult to store their compressed installation files on the PINN SD card. PINN-lite contains no OS installation files by default, but you can copy selected OSes into the /os folder if you wish.

To counter this lack of SD card space, PINN supports storing the compressed OSes on a USB stick as well. This has the following advantages:

The OSes are available to install when a network is not available.
They do not take up any valuable space on the SD card.
The OSes should be stored on the USB stick in the same format as they would be on a PINN SD card (please see the download section):

  • Each OS should be stored in its own folder beneath the /os folder.
  • They should contain compressed images of their partitions in .tar.xz format
  • All supporting JSON files (etc.) should also be included.
  1. Be sure to update the OS boot tarballs with *.dat and *.elf so you can USB boot (you ONLY need to update the bootloaders and actually if using a Pi4 only those compatible bootloader files e.g. *4.elf, *4.dat )
  2. Boot PINN on the Pi4 from the USB device
  3. Install OS

Addressing your concerns:

  1. The update of Ubuntu does indeed change vmlinuz and initrd.img on the system-boot partition. vmlinuz is a compressed version of vmlinux which is the actual kernel image that start4.elf bootloader can boot. Decompressing vmlinuz after an Ubuntu update/upgrade in the system-boot partition will solve the inability to USB boot (SD boot for that matter)

Required for ubuntuServer 20.04 installation with PINN:

Open the config.txt on the ubuntu boot partition (labeled system-boot). Change the kernel line(s), add an initramfs line, and comment out (#) the device_tree_address line as follows:

[pi4]

arm_64bit=1
enable_gic=1
armstub=armstub8-gic.bin
#decompress vmlinuz using bzip or any compression utility that can decompress a bzimage, rename #to vmlinux ( to avoid confusion and follow linux kernel naming convention)
#JUST A NOTE: doing this changes will bypass uboot.bin which currently is not compiled to
#recognize USB hardware for the raspberry pi 4 therefore will not allow a USB boot. Uboot requires
#a bzimage of vmlinux(vmlinuz). Uboot WILL decompress vmlinuz to the raw kernel image, vmlinux
#which then loads into memory and boots, start4.elf will not decompress vmlinuz, but will load
#vmlinux
kernel=vmlinux
initramfs initrd.img followkernel

#device_tree_address=0x03000000

The decompression of vmlinuz could possibly be automated in PINN, just haven't played with that yet.

Changing the config.txt file as well as the *.elf and *.dat files in the ubuntu system-boot.tar.xz tarball can also be done prior to installing
Similarly cmdline.txt can be changed to add root=LABEL=writable in the system-boot.tar.xz tarball prior to PINN install of ubuntu OS

Addressing label issue. I have played with using PINN to install multiple ubuntu flavors and it seems each boot and root partition is sequentially numbered, e.g. system-boot, system-boot0, system-boot1, same for writable, eg. writable, writable0. As I recall though I had to manually change this after installing, I would have to see what I did again to get this all to work.

#11

I've tried to make this work as well and I keep failing, I just can't keep the modifications straight when I dig into it. I know procount is working on the project, but if you've already succeeded, can you tell us if you're using a Pi 4 to boot 20.04 off of USB?

Thanks to both of you for your contributions!