Git Product home page Git Product logo

pi-gadget's Introduction

Raspberry Pi "Universal" Gadget Snap

This repository contains the source for an Ubuntu Core gadget snap that runs universally on all the Raspberry Pi boards currently supported by Ubuntu Core (Raspberry Pi 2B, 3B, 3A+, 3B+, 4B, Pi Zero 2 W, Compute Module 3, Compute Module 3+ and Compute Module 4).

Building with snapcraft(see below) will obtain various components from the bionic-updates archive, including:

  • the bootloader firmware from the linux-firmware-raspi2 package
  • the device-tree(s) from the linux-modules-<ver>-raspi2 package
  • u-boot binaries (for various models) from the u-boot-rpi package
  • u-boot boot script from the flash-kernel package (classic gadgets only)

On core builds, a silent boot with a splash screen is included. The splash screen binary comes from git://git.yoctoproject.org/psplash. Please see the psplash/ sub directory for patches and adjustments in use.

Gadget Snaps

Gadget snaps are a special type of snaps that contain device specific support code and data. You can read more about them in the snapcraft forum:

https://forum.snapcraft.io/t/the-gadget-snap/

Reporting Issues

Please report all issues here on the github page via: https://github.com/snapcore/pi-gadget/issues

Branding

This gadget snap comes with a boot splash. To change the logo you can add a new png file to the psplash subdirectory of this tree, adjust the "SPLASH=" option in psplash/config to point to this file and rebuild the gadget.

To turn off the splash screen completely please edit configs/core/cmdline.txt and remove the splash and the vt.handoff=2 keywords from the default kernel command line.

Branches

This repository contains the following branches for Ubuntu Core versions and the two Raspberry Pi architectures(armhf and arm64):

  • 18-arm64 - the branch for Core 18 on arm64
  • 18-armhf - the branch for Core 18 on armhf
  • 20-arm64 - the branch for Core 20 on arm64 (default)
  • 20-armhf - the branch for Core 20 on armhf
  • 22-arm64 - the branch for Core 22 on arm64
  • 22-armhf - the branch for Core 22 on armhf
  • classic - the branch for Ubuntu Server images (universal gadget)
  • desktop - the branch for Ubuntu Desktop images (universal gadget)

Building

There are two general approaches to building the pi-gadget snap: managed and manual managed.

The easiest managed approach is to simply run snapcraft within the root of this repository on a classic Ubuntu installation, such as an amd64-based Ubuntu server or desktop, or even an arm64-based Ubuntu running on a Raspberry Pi. Snapcraft will create either a Multipass or LXD build environment and produce the gadget snap automatically.

Another managed option is to run snapcraft remote-build. This command offloads the snap build process to the Launchpad build farm, pushing the potentially foreign architecture snap back to your machine when the build completes. See Remote build for further details.

Managed build environments will mirror the distro series declared in the base setting of the gadget's snapcraft.yaml, such as core20 or core18.

Manually managed builds include building the gadget snap on Ubuntu Core running on a Raspberry Pi, for example, and systems where you want to first manually isolate a build from the host system. In both cases, you first manually create an LXD instance from which you can run snapcraft --destructive-mode to use the instance as the build environment.

Examples of both a managed build and a manually managed build are outlined below.

Example managed build

This is likely the most convenient build method as the gadget is automatically built within a container on the host machine.

Prerequisites

  • An Ubuntu host (20.04 or newer is recommended)
  • Snapcraft

Method

To build the gadget snap, switch to the appropriate branch and simply run the snapcraft command:

$ git clone https://github.com/snapcore/pi-gadget
$ cd pi-gadget
$ git checkout 20-armhf
$ snapcraft
[...]
Snapped pi_20-1_armhf.snap

By default, snapcraft attempts to build the gadget snap in a Multipass container, isolating the host system from the build system. Building on LXD is another option that can be faster, especially when iterating over builds.

If Multipass or LXD is not already installed, Snapcraft will install the appropriate packages and run through their setup before building the gadget.

Both Multipass and LXD allow for the build architecture to differ from the run-on architecture, as defined by the architecture stanza in the snapcraft.yaml for the gadget snap:

architecture
  - build-on: [amd64, armhf]
    run-on: armhf

See Architectures for more details on defining architectures and Image building for instructions on how to build a bootable image that includes the gadget snap.

Example manually managed build

This method allows for the gadget snap to be built on the same hardware the gadget is intended for.

Prerequisites

Method

To build the gadget snap:

  1. Install and set up LXD
  2. Launch a fresh instance of Ubuntu 20.04
  3. Within the instance:
    • Install snapcraft
    • Clone the repo, switch to the appropriate build and arch branch
    • Build the gadget with snapcraft
  4. Exit the instance and obtain the snap from within the container

Running the following commands on the Raspberry Pi will perform the above process:

$ sudo snap install lxd
$ sudo lxd init --auto
$ sudo lxc launch ubuntu:20.04 focal
$ sudo lxc shell focal
# snap install snapcraft --classic
# git clone https://github.com/snapcore/pi-gadget/
# cd pi-gadget
# snapcraft --destructive-mode
[...]
Snapped pi_20-1_arm64.snap
# exit
$ lxc file pull focal/root/pi-gadget/pi_20-1_arm64.snap .

See Image building for instructions on how to build a bootable image that includes the gadget snap.

pi-gadget's People

Contributors

anonymouse64 avatar degville avatar jawn-smith avatar jfether avatar mvo5 avatar ogra1 avatar sil2100 avatar vorlonofportland avatar waveform80 avatar xnox avatar zyga avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pi-gadget's Issues

Boot of uc20 on serial port strange

When I boot uc20 with the pi gadget revision 224 on arm64 on my pi3 I get strange output, see attached screenshot.

Also the hdmi monitor is showing nothing but a blank screen for most of the time (and a little "flash" symbol on the top right). Eventually I do get console-conf on the HDMI and everything seems to be working.

Might be weirdness with my system of course, I use "screen /dev/ttyUSB0 115200" - but the fact that some chars are correct and some are garbled indicates something else is going on.

Screenshot from 2020-11-27 20-01-50

Device tree in gadget.yaml

We are having difficulties getting this image to run on Raspberry Pi 3 B. We haven't narrowed down the issue completely but something has caught our attention. Why does the gadget.yaml is referencing an old device tree (bcm2709-rpi-3-b-plus)?
We expected to see a valid device tree in gadget.yaml, as defined here.

Use GPT partition table

need sample gadget + test on all the pies using e.g. testflinger.

also, aren't our classic images gpt already?

not enough i2c interfaces in snapcraft.yaml

when using dtoverlay lines to enable additional i2c buses via the i2c-gpio overlay, adding the following to config.txt works fine, the devices are created and functional after a reboot:

# adding /dev/i2c-4
dtoverlay=i2c-gpio,bus=4,i2c_gpio_delay_us=1,i2c_gpio_sda=23,i2c_gpio_scl=24
# adding /dev/i2c-3
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=17,i2c_gpio_scl=27

yet application snap packages can not access these devices, snapcraft.yaml only has:

i2c-0:
  interface: i2c
  path: /dev/i2c-0
i2c-1:
  interface: i2c
  path: /dev/i2c-1
i2c-2:
  interface: i2c
  path: /dev/i2c-2

additional interface declarations for /dev/i2c-3 and /dev/i2c-4 should be added here ...

Build instructions broken

Trying to build a gadget following the instructions in README.md results in:

$ sudo snapcraft snap --target-arch=arm64 --destructive-mode
Running with 'sudo' may cause permission errors and is discouraged. Use 'sudo' when cleaning.
Setting target machine to 'arm64'
--target-arch has been deprecated and is no longer supported on core20.
$

The gadget should be reverted to a proper snapcraft.yaml again (with proper parts to do all porocessing as it used to be) instead of moving back a decade in time to shell out to a Makefile. Then using the required architectures: fields for cross building will work again as well, there is nothing in the Makefile that can not be done cleaner from snapcraft parts.

U-boot script does not cope with missing kernel, should trigger recovery

I've discovered that my Ubuntu Core 20 system, running on a Raspberry Pi 3B, has failed to boot for several weeks. After a long debugging session I've noticed that:

  1. The system expected some version of the kernel snap to be installed
  2. That version was not on disk (ext4) and not extracted to boot partition (fat)
  3. The boot script hanged after failing to load the kernel.

I had no traces of information as to what has happened (no persistent journal, all changes and tasks recycled). A complete thread of debugging/analysis is shared on twitter: https://twitter.com/zygoon/status/1548640642967928833

uc20 kernel cmdline duplicates "quiet splash"

Current uc20 image has this as /proc/cmdline:

$ for i in $(cat /proc/cmdline); do echo $i; done
coherent_pool=1M
8250.nr_uarts=1
video=Composite-1:720x480@60,margin_left=32,margin_right=32,margin_top=32,margin_bottom=32
smsc95xx.macaddr=B8:27:EB:42:E5:ED
vc_mem.mem_base=0x3ec00000
vc_mem.mem_size=0x40000000
dwc_otg.lpm_enable=0
console=ttyS0,115200
elevator=deadline
rng_core.default_quality=700
vt.handoff=2
quiet
splash
quiet <--- duplicate
splash <--- duplicate
snapd_recovery_mode=run
snapd_recovery_system=20200811
panic=-1
systemd.gpt_auto=0
rd.systemd.unit=basic.target
ubuntu@ubuntu:~$ snap list
Name                     Version                     Rev   Tracking       Publisher             Notes
core20                   20                          771   latest/beta    canonical✓            base
pi                       20-1                        72    20/beta        canonical✓            gadget
pi-kernel                5.4.0-1015.15               179   20/beta        canonical✓            kernel
snapd                    2.46~pre2+git2496.g6696cd6  8950  latest/beta    canonical✓            snapd

I assume the bug is actually somewhere in the bootscript from flash-kernel

Remove 'desktop' branch

Now that livecd is always using the 'classic' branch (and knows to specify different targets for server or desktop images), there's no point keeping the 'desktop' branch around (which is also a trivial diff away from 'classic'). Assuming there's no commenters raise any objections, I'll kill the branch at the end of the week.

Ubuntu Core 20 support on CM4

Hello.

After I built a gadget from this source (20-armhf), it seems like the boot process hangs on booting UC20 on the CM4.
Is the CM4 supported?
Here is the output:
`U-Boot 2020.10+dfsg-1ubuntu0~20.04.2 (Jan 08 2021 - 13:03:11 +0000)

DRAM: 1.9 GiB
RPI: Board rev 0x14 outside known range
RPI Unknown model (0xb03140)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
starting USB...
No working controllers found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
4638 bytes read in 30 ms (150.4 KiB/s)

Executing script at 02400000

4096 bytes read in 27 ms (147.5 KiB/s)
7586304 bytes read in 603 ms (12 MiB/s)
halfword at 0x00080000 (0x8b1f) != halfword at 0x02700000 (0x5a4d)
Total of 0 halfword(s) were the same
Copying kernel...
16937018 bytes read in 1287 ms (12.6 MiB/s)
Booting Ubuntu (with bootz) from mmc 0:...
Kernel image @ 0x080000 [ 0x000000 - 0x73c200 ]

Flattened Device Tree blob at 02600000

Booting using the fdt blob at 0x2600000
Using Device Tree in place at 02600000, end 0260f08c

Starting kernel ...

[ 0.675281] kvm [1]: Error, CPU 0 not supported!
[ 1.510313] spi-bcm2835 fe204000.spi: could not get clk: -517
[ 2.118705] systemd-modules-load[169]: Inserted module 'i2c_bcm2708'
[ 2.136826] systemd-modules-load[169]: Inserted module 'nvme'
[ 2.154427] systemd-modules-load[169]: Inserted module 'usbhid'
[ 2.173146] systemd-modules-load[169]: Inserted module 'hid_generic'
[ 2.185480] systemd-modules-load[169]: Module 'squashfs' is built in
[ 2.193556] systemd-modules-load[169]: Failed to find module 'ahci'
[ 2.208841] systemd-modules-load[169]: Inserted module 'libahci'
[ 2.224835] systemd-modules-load[169]: Inserted module 'usb_storage'
[ 2.236308] systemd-modules-load[169]: Inserted module 'nls_iso8859_1'
[ 2.252797] systemd-modules-load[169]: Inserted module 'virtio_scsi'
[ 2.268876] systemd-modules-load[169]: Module 'sdhci' is built in
[ 2.284641] systemd-modules-load[169]: Failed to find module 'sdhci-pci'
[ 2.300719] systemd-modules-load[169]: Failed to find module 'sdhci-acpi'
[ 2.316780] systemd-modules-load[169]: Module 'mmc_block' is built in
[ 2.332771] systemd-modules-load[169]: Failed to find module 'hv_storvsc'
[ 2.348599] systemd-modules-load[169]: Failed to find module 'hv_vmbus'
[ 2.364703] systemd-modules-load[169]: Inserted module 'virtio_blk'
[ 2.380838] journalctl[198]: No items in catalog.
[ 2.396349] systemd-modules-load[169]: Inserted module 'algif_skcipher'
[ 2.412688] systemd-modules-load[169]: Inserted module 'dm_crypt'
[ 2.428514] systemd-modules-load[169]: Module 'dm_mod' is built in
[ 2.444293] systemd-modules-load[169]: Inserted module 'aes_arm'
[ 2.464356] systemd-modules-load[169]: Module 'cbc' is built in
[ 2.480316] systemd-modules-load[169]: Inserted module 'echainiv'
[ 2.496271] systemd-modules-load[169]: Module 'cryptomgr' is built in
[ 2.516279] systemd[1]: Starting Flush Journal to Persistent Storage...
[ 2.536364] systemd-modules-load[169]: Inserted module 'sha256_arm'
[ 2.556299] systemd-modules-load[169]: Module 'xts' is built in
[ 2.576331] systemd-modules-load[169]: Failed to find module 'aesni-intel'
[ 2.592304] systemd[1]: Started udev Kernel Device Manager.
[ 2.608394] systemd-modules-load[169]: Inserted module 'phy_generic'
[ 2.628347] systemd-modules-load[169]: Module 'sdhci_iproc' is built in
[ 2.644340] systemd-modules-load[169]: Module 'fixed' is built in
[ 2.660354] systemd-modules-load[169]: Module 'gpio_regulator' is built in
[ 2.676663] systemd-modules-load[169]: Module 'genet' is built in
[ 2.692550] systemd[1]: Finished Load Kernel Modules.
[ 2.708609] systemd[1]: Mounting FUSE Control File System...
[ 2.724359] systemd[1]: Mounting Kernel Configuration File System...
[ 2.740387] systemd[1]: Starting Apply Kernel Variables...
[ 2.756402] systemd[1]: Finished Flush Journal to Persistent Storage.
[ 2.772387] systemd[1]: Mounted FUSE Control File System.
[ 2.788374] systemd[1]: Starting Create Volatile Files and Directories...
[ 2.804545] systemd-sysctl[193]: Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists).
[ 2.824349] systemd-sysctl[193]: Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists).
[ 2.844406] systemd[1]: Mounted Kernel Configuration File System.
[ 2.860429] systemd-sysctl[193]: Couldn't write 'fq_codel' to 'net/core/default_qdisc', ignoring: No such file or directory
[ 2.880332] systemd[1]: Finished Apply Kernel Variables.
[ 2.896548] systemd-tmpfiles[195]: Failed to copy files to /etc/nsswitch.conf: No such file or directory
[ 2.916367] systemd-tmpfiles[195]: Failed to copy files to /etc/pam.d: No such file or directory
[ 2.936361] systemd-tmpfiles[195]: Failed to copy files to /etc/issue: No such file or directory
[ 2.956299] systemd[1]: Finished Create Volatile Files and Directories.
[ 2.972349] systemd[1]: Starting Rebuild Journal Catalog...
[ 2.988373] systemd[1]: Finished Rebuild Journal Catalog.
[ 3.004364] systemd[1]: Starting Update is Completed...
[ 3.020374] systemd[1]: Finished Update is Completed.
[ 3.037022] systemd-udevd[201]: Using default interface naming scheme 'v245'.
[ 3.056379] systemd[1]: Finished udev Coldplug all Devices.
[ 3.072926] systemd[1]: Starting udev Wait for Complete Device Initialization...
[ 3.096376] systemd[1]: Finished udev Wait for Complete Device Initialization.
[ 3.116564] udevadm[216]: systemd-udev-settle.service is deprecated.
[ 3.495496] systemd[1]: Reached target System Initialization.
[ 3.512402] systemd[1]: Started Daily Cleanup of Temporary Directories.
[ 3.528492] systemd[1]: Reached target Basic System.
[ 3.544566] systemd[1]: Reached target Timers.
[ 3.560406] systemd[1]: Condition check resulted in Wait for the Ubuntu Core chooser trigger being skipped.
[ 3.584391] systemd[1]: Starting the-tool.service...
[ 3.585247] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[ 3.585502] systemd[1]: Listening on fsck to fsckd communication Socket.
[ 3.585758] systemd[1]: Starting File System Check on /dev/mmcblk0p1...
[ 3.590672] systemd[1]: Started File System Check Daemon to report status.
[ 3.617690] systemd-fsck[230]: CP437: Invalid argument
[ 4.226388] systemd-fsck[230]: fsck.fat 4.1 (2017-01-24)
[ 4.226687] systemd-fsck[230]: /dev/mmcblk0p1: 312 files, 1171346/2419758 clusters
[ 4.253715] systemd[1]: Finished File System Check on /dev/mmcblk0p1.
[ 4.272380] systemd[1]: Mounting /run/mnt/ubuntu-seed...
[ 4.291119] systemd[1]: Mounted /run/mnt/ubuntu-seed.
[ 4.384767] the-tool[220]: 2019/11/19 12:24:27.555751 secboot_tpm.go:196: cannot open TPM connection: no TPM2 device is available
[ 4.408301] the-tool[[220]: FAILEDerror: cannot load metadata and verify essential bootstrap snaps [base kernel snapd gadget]: cannot accept some assertions:]
Failed to start the-tool.service.
[ 4.408977] the-tool[220]: - assertion is signed with expired public key "SY4gB2ohu-" from "jjNCJ
[ 4.468368] systemd[1]: the-tool.service: Main process exited, code=exited, status=1/FAILURE
[ 4.488341] systemd[1]: the-tool.service: Failed with result 'exit-code'.
[ 4.504258] systemd[1]: Failed to start the-tool.service.
[ 4.520225] systemd[1]: Startup finished in 1.826s (kernel) + 0 (initrd) + 2.613s (userspace) = 4.440s.
[ 4.540218] systemd[1]: the-tool.service: Triggering OnFailure= dependencies.
[ 4.556215] systemd[1]: systemd-ask-password-console.path: Succeeded.
[ 4.572208] systemd[1]: Stopped Dispatch Password Requests to Console Directory Watch.
[ 4.592199] systemd[1]: systemd-tmpfiles-clean.timer: Succeeded.
[ 4.608227] systemd[1]: Stopped Daily Cleanup of Temporary Directories.
[ 4.624213] systemd[1]: Stopped target Basic System.
[ 4.640198] systemd[1]: Stopped target System Initialization.
[ 4.656192] systemd[1]: emergency.service: Starting requested but asserts failed.
[ 4.672190] systemd[1]: Assertion failed for Emergency Shell.
[ 4.688215] systemd[1]: Dependency failed for Emergency Mode.
[ 4.704198] systemd[1]: emergency.target: Job emergency.target/start failed with result 'dependency'.
[ 34.263284] systemd[1]: systemd-fsckd.service: Succeeded.`
The boot process just hangs there...

Should allow a way to boot a u-boot binary with serial completely disabled

Many addon boards for the Pi talk to the host system by being attached to the serial port header. Often these boards get powered by the mains power so that they are up and listening on the serial connection before u-boot comes up ...

If u-boot writes anything to the serial console in this combination the addon board typically go into a bad state. To use such boards on Ubuntu Core a way to boot with a completely quiet u-boot on serial should be provided. Preferably via an easy to set (and well documented) option or environment variable when building the gadget.

Pi 3 USB not enumerating

Hello.

I am trying to make a armhf gadget snap, but I realised after building the armhf gadget snap and adding it to my own image build, it does not enumerate USB devices. (the Pi3 boots the image)

I git cloned this repo, changed the branch over to 18-armhf, built the image, etc.
as all per instructions.
Can someone tell me where and what went wrong?
My model file:
{
"type": "model",
"series": "16",
"model": "core18-armhf-pi3",
"display-name":"Ubuntu Core 18 (armhf)",
"architecture": "armhf",
"kernel": "pi-kernel=18-pi3",
"gadget": "my-gadget",
"base": "core18",
"required-snaps": ["core"],
"authority-id": "-removed-",
"brand-id": "-removed-",
"timestamp": "2020-11-25T16:50:51+00:00"
}
gadget snap yaml:
Bone stock, except for the name change
{
name: my-gadget
version: 18-1
summary: Raspberry Pi3 gadget
description: |
Support files for booting Raspberry Pi.
This gadget snap supports the Raspberry Pi 2B, 3B, 3A+, 3B+, 4B, Compute
Module 3, and the Compute Module 3+ universally.
type: gadget
base: core18
architectures:

  • build-on: [amd64, armhf]
    run-on: armhf
    confinement: strict
    etc...
    }

Ubuntu-image command:
sudo ubuntu-image -c stable --image-size 4G --snap ./gadget/pi-gadget/my-gadget_18-1_armhf.snap models/core18-armhf-pi3.model

Switch Core 24 to kms

This should've been done before release, but evidently I forgot. The fkms overlay isn't supported on the Pi 5, and hasn't been supported on prior models since buster (upstream), so we can't be relying upon it for Core 24.

Enabling camera in custom image

Hi,

I'm trying to get to grips with Ubuntu Core a bit, and one thing I'm looking to do is create a custom image with a couple of application snaps, but importantly the camera interface needs to be enabled without any user intervention. A lot of online tutorials talk about just editing the boot config.txt, but obviously this doesn't really work for what we want.

Am I right in thinking that the workflow should be:

  • Fork this gadget snap
  • Rename, and enable the camera module usingconfig.txt.armhf and config.txt.arm64
  • Publish the forked gadget snap
  • Build a custom image with the gadget set to the forked snap

I've read a bunch of the documentation but I'm either missing something about how to actually use custom gadgets in custom images, or it's really not obvious.

Any pointers would be great,

Thanks!

end.psplash.service results in failed state on UC18 devices

Current UC18 images include a service unit to ensure the psplash process is terminated. On the following devices this unit results in a failed state:

  • rpi CM3
  • rpi CM3+
  • rpi 2b
  • rpi 3b
  • rpi 3b+
  • rpi 4b
ubuntu@localhost:~$ systemctl status end.psplash.service
● end.psplash.service - Stop Splash Screen
   Loaded: loaded (/etc/systemd/system/end.psplash.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-07-02 09:38:23 UTC; 57min ago
  Process: 811 ExecStart=/usr/bin/pkill psplash (code=exited, status=1/FAILURE)
 Main PID: 811 (code=exited, status=1/FAILURE)

classic pi-gadget should be published as a snap

classic pi-gadget should be published as a snap in the store (maybe on a separate classic track, which might be the same as regular gadget, or not. May need to be build on the right target series however.

that way livecd-rootfs/ubuntu-image can stop cloning this git repository, and instead just download the gadget and use it.

Please remove 'elevator=deadline' from cmdline.txt

Starting with kernel v5.5 [1], the elevator= commandline option is no longer supported and leads to boot warnings:

[    0.000000] Kernel parameter elevator= does not have any effect anymore.
               Please use sysfs to set IO scheduler for individual devices.

Please remove it from all relevant branches.

[1] torvalds/linux@f8db383

Default branch doesn't work with snapcraft remote-build

The default branch (20-arm64) of this repository cannot be built with the snapcraft remote-build command.

To reproduce:

git clone https://github.com/snapcore/pi-gadget.git
cd pi-gadget

(make sure to be on the 20-arm64 branch)

snapcraft remote-build
Build status as of 2024-06-11 11:18:14.297731:
        arch=amd64      state=Needs building
Build status as of 2024-06-11 11:18:44.811219:
        arch=amd64      state=Currently building
[...]
Build status as of 2024-06-11 11:23:48.415609:
        arch=amd64      state=Failed to build
Snap file not available for arch 'amd64'.
Build log available at 'pi_amd64.txt'
Build failed for arch 'amd64'.
Build task(s) complete.
Build failed for arch amd64.
+ snapcraftctl stage
Priming gadget
+ snapcraftctl prime
Priming psplash-local
+ snapcraftctl prime
Priming psplash
+ snapcraftctl prime
Failed to generate snap metadata: Missing gadget.yaml file.
When creating gadget snaps you are required to provide a gadget.yaml file
in the root of your snapcraft project

The gadget.yaml file is actually present. So it looks like a bug.
I could reproduce it on my host (20.04) and in a VM (24.04).

snapcraft 8.2.10

Cross Building is not working for psplash

amd64 [mulipass - lxd]

👍 build success
👍 work plug and other config

👎 not working PSplash

arm64 [build on rpi4 - lxc focal]

👍 build success
👍 work plug and other config
👍 working PSplash

Not able to build pi-gadget classic

Hi,
I tried build pi-gadget classic on amd64 Ubuntu 20.04 , it never builds and always hangs.
sudo SERIES=focal ARCH=arm64 make

So, i tried it on arm64 and it worked. It created a stage folder. how am i supposed to used this to create classic gadget?

I also tried running snapcraft --use-lxd on both architectures. But it always fails giving:

Building gadget
++ arch
++ arch

  • '[' x86_64 '!=' aarch64 -a x86_64 '!=' armv7l ']'
  • echo 'Cross compilation detected; using pre-defined sources list'
    Cross compilation detected; using pre-defined sources list
  • OPTIONAL_ARGS='SOURCES_HOST="./helpers/sources.list.cross"'
    ++ dpkg-architecture -t x86_64-linux-gnu -q DEB_HOST_ARCH
  • make -C /home/ok/classic-gadget/pi-gadget default DESTDIR=/home/ok/classic-gadget/pi-gadget/parts/gadget/install ARCH=arm64 'SOURCES_HOST="./helpers/sources.list.cross"'
    make: Entering directory '/home/ok/classic-gadget/pi-gadget'
    Makefile:18: *** Build architecture is not supported. Stop.
    make: Leaving directory '/home/ok/classic-gadget/pi-gadget'

README should clarify "managed" and "manual managed" build modes

The README is confusing, referring early to "managed" and "manual managed" build modes, but that terminology seems less than useful. The explanation should stick to more typical descriptions like "native" build, or Multipass build or LXD build or whatever. Don't make the reader have to guess what the examples are doing.

add ubuntu-save to gadget.yaml

ubuntu-save will be useful for non-encrypted cases like the pi anyways, so we should add that partition before the release

Missing documentation about how to customize

With the switch to using a Makefile and binary debs from the archive for u-boot it is not easily possible anymore to patch the bootloader i.e. for addon boards that need to be initialized before a kernel loads etc ...

the old setup that was building u-boot from upstream source had well dcumented ways of adding patches and modifying u-boot build configuration for addon hardware (even by following the generic snapcraft documentation about patching and building snaps) so people could follow manufacturer instructions easily. It would be nice to have ways of cusomization documented for the new setup of the snap.

Comment on 20-arm64 branch still refers to armhf

Around line 27:

# unconditionally set the arch-triplet since this snapcraft.yaml will
# always be used to produce an armhf snap
BUILD_ARCH_TRIPLET=aarch64-linux-gnu

I'm guessing that was just copied and pasted from 20-armhf branch; should that not say

"always be used to produce an arm64 snap"?

Partition always grows (growpart off ignored) on Ubuntu 21.10 + Jammy daily

Hi,

On Raspberry Pi since Impish, the partition always grows even if I set the following in user-data of cloud-init.

growpart:
mode: off
devices: ['/']

I have tested this on 21.04, and it works, but is broken on 21.10. (partition always grows)

I've also tested this in KVM on amd64, and it works (partition does NOT grow).

I've tested this on the latest jammy raspberry pi daily as at 20210216 and it is also an issue.

This is a problem for me because I am using runcmd in cloud-init to migrate my drive to LVM/LUKS, and the partitioning step fails because the drive is already full.

I've submitted a ticket to the ubuntu bug tracker, but so far nobody can tell me where the Raspberry Pi modification occur... Is this the correct repo? If not, does anyone have any idea how I can find when the behavior changed and why? Or a lead on which repo I should post this to?

https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1947311

Thanks!
Noah

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.