** Attachment added: "piboot-try_1.0_arm64-2026-02-14T01:04:53Z.build" https://bugs.launchpad.net/ubuntu/+source/piboot-try/+bug/2142151/+attachment/5947117/+files/piboot-try_1.0_arm64-2026-02-14T01%3A04%3A53Z.build
** Description changed: [Availability] The package piboot-try is already in Ubuntu universe. The package piboot-try build for the architectures it is designed to work on. It currently builds and works for architectures: arm64 armhf Link to package https://launchpad.net/ubuntu/+source/piboot-try [Rationale] - The package piboot-try is required in Ubuntu main for raspi-common platform - seed + seed - It manages the boot assets on all Raspberry Pi images from resolute onwards - The package has been split from flash-kernel (main), which was the original - location for this code after the Pi delta in flash-kernel grew to be more - than 50% of our delta with Debian, and had nothing in common with the rest of - flash-kernel + location for this code after the Pi delta in flash-kernel grew to be more + than 50% of our delta with Debian, and had nothing in common with the rest of + flash-kernel - Put another way, this code was already in main as part of flash-kernel but - has now been moved into its own package to reduce our flash-kernel delta with - Debian + has now been moved into its own package to reduce our flash-kernel delta with + Debian - For the time being the code is (nearly) a straight copy of the flash-kernel - code minus the bits definitely not needed (e.g. the flash-kernel-installer - package); over time it is anticipated the vast majority of the remaining - flash-kernel code will also disappear + code minus the bits definitely not needed (e.g. the flash-kernel-installer + package); over time it is anticipated the vast majority of the remaining + flash-kernel code will also disappear - Nothing else in the archive implements the required logic, but this isn't - terribly surprising given the unique nature of the Pi's bootloader + terribly surprising given the unique nature of the Pi's bootloader - This is the first time piboot-try will be in main (as it is a new package), - but the code was previously in main as part of the flash-kernel package; the - original MIR for flash-kernel is LP: #339947 + but the code was previously in main as part of the flash-kernel package; the + original MIR for flash-kernel is LP: #339947 - The binary package piboot-try needs to be in main to enable the building of - the Ubuntu for Raspberry Pi images where it is taking the place of the - flash-kernel package (see LP: #2138618 and associated merge request for the - raspi-common platform seed) + the Ubuntu for Raspberry Pi images where it is taking the place of the + flash-kernel package (see LP: #2138618 and associated merge request for the + raspi-common platform seed) - The package piboot-try is required in Ubuntu main for the resolute release [Security] - To the best of my knowledge there are no current or historical CVEs for - flash-kernel (and thus none for piboot-try either); I've been the primary - maintainer of the flash-kernel package in Ubuntu for several years now and - have yet to see a CVE for it + flash-kernel (and thus none for piboot-try either); I've been the primary + maintainer of the flash-kernel package in Ubuntu for several years now and + have yet to see a CVE for it - There have been CVEs in packages like u-boot which flash-kernel is - responsible for installing, but none that are relevant to piboot-try (we - moved away from using u-boot on the Pi several years ago) + responsible for installing, but none that are relevant to piboot-try (we + moved away from using u-boot on the Pi several years ago) - There are no `suid` or `sgid` binaries - The package DOES install executables (scripts) in `/usr/sbin` - - These scripts (`flash-kernel` and `piboot-try`) are not new but were - originally in the flash-kernel package + - These scripts (`flash-kernel` and `piboot-try`) are not new but were + originally in the flash-kernel package - The package DOES install two services: - - piboot-try-reboot: Detects when "new" (untested) boot assets are present - and initiates a reboot into the "tryboot" mode to test them - - piboot-try-validate: Validates that a boot is "successful" and moves the - "new" boot assets into the "current" slot + - piboot-try-reboot: Detects when "new" (untested) boot assets are present + and initiates a reboot into the "tryboot" mode to test them + - piboot-try-validate: Validates that a boot is "successful" and moves the + "new" boot assets into the "current" slot - Package does not open privileged ports (ports < 1024). - Package does not expose any external endpoints - Package does not contain extensions to security-sensitive software (filters, - scanners, plugins, UI skins, ...) + scanners, plugins, UI skins, ...) [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - While flash-kernel is present in Debian and primarily maintained there, the - piboot-try portion of the package has always been Ubuntu specific - - https://bugs.launchpad.net/ubuntu/+source/piboot-try + piboot-try portion of the package has always been Ubuntu specific + - https://bugs.launchpad.net/ubuntu/+source/piboot-try - The package does not deal with exotic hardware we cannot support (at least, I - hope Raspberry Pi's don't count as "exotic"; enough Canonicalers seem to own - a few :) + hope Raspberry Pi's don't count as "exotic"; enough Canonicalers seem to own + a few :) [Quality assurance - testing] - The package runs a test suite on build time, if it fails it makes the build - fail, link to build log: - - https://launchpadlibrarian.net/848101836/buildlog_ubuntu-resolute-arm64.piboot-try_1.0_BUILDING.txt.gz + fail, link to build log: + - https://launchpadlibrarian.net/848101836/buildlog_ubuntu-resolute-arm64.piboot-try_1.0_BUILDING.txt.gz - The package runs an autopkgtest, and is currently passing on - the arm64 and armhf architectures, link to test logs: - - https://autopkgtest.ubuntu.com/packages/piboot-try - - https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/arm64/p/piboot-try/20260218_024612_7c3ea@/log.gz - - https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/armhf/p/piboot-try/20260218_020250_6ea35@/log.gz + the arm64 and armhf architectures, link to test logs: + - https://autopkgtest.ubuntu.com/packages/piboot-try + - https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/arm64/p/piboot-try/20260218_024612_7c3ea@/log.gz + - https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/armhf/p/piboot-try/20260218_020250_6ea35@/log.gz - The package does have not failing autopkgtests right now - The package can not be well tested at build or autopkgtest time because - neither will actually test boot on Raspberry Pi hardware. To make up for - that: - - We have access to such hardware in the team - - Before every upload, the operation of piboot-try will be tested on actual - hardware - - The functionality will also be tested regularly as several team members use - Raspberry Pis daily, and any kernel upgrade, initramfs update, or call to - flash-kernel will exercise the functionality of the package + neither will actually test boot on Raspberry Pi hardware. To make up for + that: + - We have access to such hardware in the team + - Before every upload, the operation of piboot-try will be tested on actual + hardware + - The functionality will also be tested regularly as several team members use + Raspberry Pis daily, and any kernel upgrade, initramfs update, or call to + flash-kernel will exercise the functionality of the package [Quality assurance - packaging] - A mechanism to detect and fetch new upstream versions is not present because - it is a native package developed by us + it is a native package developed by us - debian/control defines a correct Maintainer field - This package does not yield massive lintian Warnings, Errors - - A recent build log is attached as piboot-try_1.0_arm64.build + - A recent build log is attached as piboot-try_1.0_arm64-2026-02-14T01:04:53Z.build - No output from lintian --pedantic - Lintian overrides are not present - This package does not rely on obsolete or about to be demoted packages. - The package will be installed by default, but does not ask debconf - questions higher than medium + questions higher than medium - Packaging and build is easy, link to debian/rules - - Cannot currently link to d/rules as git.launchpad.net scripts are disabled - - git clone lp:piboot-try - - vim debian/rules + - Cannot currently link to d/rules as git.launchpad.net scripts are disabled + - git clone lp:piboot-try + - vim debian/rules [UI standards] - Application is end-user facing, translation not currently present (none - inherited from flash-kernel) + inherited from flash-kernel) - End-user applications without desktop file, not needed because console only [Dependencies] - Used check-mir from ubuntu-dev-tools to validate all dependencies or - recommends are in main. + recommends are in main. [Standards compliance] - This package correctly follows FHS and Debian Policy [Maintenance/Owner] - The owning team will be foundations (architectures squad) and I have their - acknowledgment for that commitment + acknowledgment for that commitment - The future owning team is already subscribed to the package - This does not use static builds - This does not use vendored code - This package is not rust based - The package has been built within the last 3 months in the archive - Build link on launchpad: https://launchpad.net/ubuntu/+source/piboot-try/1.0 - This change will not impact other teams [Background information] The following blog post contains details of the major changes made to flash-kernel in questing which ultimately led to the decision to split out piboot-try: https://waldorf.waveform.org.uk/2025/pull-yourself-up-by-your- bootstraps.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2142151 Title: [MIR] piboot-try To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/piboot-try/+bug/2142151/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
