Arch Linux User Repository

NOTICE: Regarding Secure Boot.

Since 1.1.13+, upstream Ventoy has started signing EFI binaries in their releases. You can confirm this with for example sbverify --list fbx64.efi. We don't have access to their private signing key, so obviously cannot do the same. AFAICT, this puts some doubt into the Ventoy Secure Boot situation for our "build from source" scenario.

To be honest, I've never been a fan of the Ventoy Secure Boot "Bypass" thing anyway.. You can read about the new upstream Ventoy Secure Boot Policy here.

NOTICE: Regarding Secure Boot.

Since 1.1.13+, upstream Ventoy has started signing EFI binaries in their releases. You can confirm this with for example sbverify --list fbx64.efi. We don't have access to their private signing key, so obviously cannot do the same. AFAICT, this puts some doubt into the Ventoy Secure Boot situation for our "build from source" scenario.

To be honest, I've never been a fan of the Ventoy Secure Boot "Bypass" thing anyway.. You can read about the new upstream Ventoy Secure Boot Policy here.

@TheGreatAndyChow, all working fine here in a clean chroot. You'll need to figure out what's wrong with your environment.

==> Extracting sources... -> Extracting ventoy-1.1.12.tar.gz with bsdtar -> Creating working copy of ipxe git repo... Reset branch 'makepkg' -> Extracting dietlibc-0.34.tar.xz with bsdtar -> Extracting musl-1.2.6.tar.gz with bsdtar -> Extracting kernel-headers-musl-6.12.77.tar.gz with bsdtar ==> Starting prepare()... mv: cannot overwrite 'INSTALL.upstream/INSTALL': Directory not empty ==> ERROR: A failure occurred in prepare(). Aborting... :: Unable to build ventoy - makepkg exited with code: 4 =>> Try again? [y/N]:

Thanks to both of you.. @rubin55 for the heads-up and @intelfx for the pointer! It was caused by Arch recent upgrade of kernel-headers-musl. Build fix incoming...

Busybox bugzilla returns a 404 when trying to access the relevant bug report, so here is one of the surviving references to it: https://lists.busybox.net/pipermail/busybox-cvs/2024-January/041751.html

Presumably, a viable fix would be to deselect the tc applet in whatever copy of busybox this package is trying to build — I'd bet ventoy does not use it.

During build I'm getting this (set of) error(s):

networking/tc.c: In function ‘cbq_print_opt’:
networking/tc.c:238:27: error: ‘TCA_CBQ_MAX’ undeclared (first use in this function); did you mean ‘TCA_CBS_MAX’?
  238 |         struct rtattr *tb[TCA_CBQ_MAX+1];
      |                           ^~~~~~~~~~~
      |                           TCA_CBS_MAX
networking/tc.c:238:27: note: each undeclared identifier is reported only once for each function it appears in
networking/tc.c:251:16: error: ‘TCA_CBQ_RATE’ undeclared (first use in this function); did you mean ‘TCA_TBF_RATE64’?
  251 |         if (tb[TCA_CBQ_RATE]) {
      |                ^~~~~~~~~~~~
      |                TCA_TBF_RATE64
networking/tc.c:257:16: error: ‘TCA_CBQ_LSSOPT’ undeclared (first use in this function)
  257 |         if (tb[TCA_CBQ_LSSOPT]) {
      |                ^~~~~~~~~~~~~~
networking/tc.c:258:61: error: invalid application of ‘sizeof’ to incomplete type ‘struct tc_cbq_lssopt’
  258 |                 if (RTA_PAYLOAD(tb[TCA_CBQ_LSSOPT]) < sizeof(*lss))
      |                                                             ^
networking/tc.c:263:16: error: ‘TCA_CBQ_WRROPT’ undeclared (first use in this function)
  263 |         if (tb[TCA_CBQ_WRROPT]) {
      |                ^~~~~~~~~~~~~~
networking/tc.c:264:61: error: invalid application of ‘sizeof’ to incomplete type ‘struct tc_cbq_wrropt’
  264 |                 if (RTA_PAYLOAD(tb[TCA_CBQ_WRROPT]) < sizeof(*wrr))
      |                                                             ^
networking/tc.c:269:16: error: ‘TCA_CBQ_FOPT’ undeclared (first use in this function)
  269 |         if (tb[TCA_CBQ_FOPT]) {
      |                ^~~~~~~~~~~~
networking/tc.c:270:59: error: invalid application of ‘sizeof’ to incomplete type ‘struct tc_cbq_fopt’
  270 |                 if (RTA_PAYLOAD(tb[TCA_CBQ_FOPT]) < sizeof(*fopt))
      |                                                           ^
networking/tc.c:275:16: error: ‘TCA_CBQ_OVL_STRATEGY’ undeclared (first use in this function)
  275 |         if (tb[TCA_CBQ_OVL_STRATEGY]) {
      |                ^~~~~~~~~~~~~~~~~~~~
networking/tc.c:276:67: error: invalid application of ‘sizeof’ to incomplete type ‘struct tc_cbq_ovl’
  276 |                 if (RTA_PAYLOAD(tb[TCA_CBQ_OVL_STRATEGY]) < sizeof(*ovl))
      |                                                                   ^
networking/tc.c:279:50: error: invalid application of ‘sizeof’ to incomplete type ‘struct tc_cbq_ovl’
  279 |                                 (unsigned) sizeof(*ovl));
      |                                                  ^
networking/tc.c:295:23: error: invalid use of undefined type ‘struct tc_cbq_lssopt’
  295 |         if (lss && lss->flags) {
      |                       ^~
networking/tc.c:298:24: error: invalid use of undefined type ‘struct tc_cbq_lssopt’
  298 |                 if (lss->flags&TCF_CBQ_LSS_BOUNDED) {
      |                        ^~
networking/tc.c:298:32: error: ‘TCF_CBQ_LSS_BOUNDED’ undeclared (first use in this function)
  298 |                 if (lss->flags&TCF_CBQ_LSS_BOUNDED) {
      |                                ^~~~~~~~~~~~~~~~~~~
networking/tc.c:302:24: error: invalid use of undefined type ‘struct tc_cbq_lssopt’
  302 |                 if (lss->flags&TCF_CBQ_LSS_ISOLATED) {
      |                        ^~
networking/tc.c:302:32: error: ‘TCF_CBQ_LSS_ISOLATED’ undeclared (first use in this function)
  302 |                 if (lss->flags&TCF_CBQ_LSS_ISOLATED) {
      |                                ^~~~~~~~~~~~~~~~~~~~
networking/tc.c:310:24: error: invalid use of undefined type ‘struct tc_cbq_wrropt’
  310 |                 if (wrr->priority != TC_CBQ_MAXPRIO)
      |                        ^~
networking/tc.c:310:38: error: ‘TC_CBQ_MAXPRIO’ undeclared (first use in this function)
  310 |                 if (wrr->priority != TC_CBQ_MAXPRIO)
      |                                      ^~~~~~~~~~~~~~
networking/tc.c:311:46: error: invalid use of undefined type ‘struct tc_cbq_wrropt’
  311 |                         printf("prio %u", wrr->priority);
      |                                              ^~
networking/tc.c:315:43: error: invalid use of undefined type ‘struct tc_cbq_wrropt’
  315 |                         printf("/%u ", wrr->cpriority);
      |                                           ^~
networking/tc.c:316:32: error: invalid use of undefined type ‘struct tc_cbq_wrropt’
  316 |                         if (wrr->weight != 1) {
      |                                ^~                              ^~
<snip>

A workaround to fix the build failures has been applied. Turns out the root cause is slightly buggy Arch GCC packaging. More info here: https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/work_items/39

usr/bin/ld: cannot find -latomic_asneeded: No such file or directory

Thanks for the report. Seems to be a generic problem when static linking with musl-gcc and gcc-16. The AUR pkg dash-static-musl has the same issue.. I'll need to find a solution somehow...

clean chroot build

usr/bin/ld: cannot find -latomic_asneeded: No such file or directory
/usr/bin/ld: have you installed the static version of the atomic_asneeded library ?
collect2: error: ld returned 1 exit status

build log at https://app.box.com/s/k3k2af36jny2rfd9v5xsiwzy6nm0qhvl prepare log at https://app.box.com/s/g4k11js8mhc0eud3oj43nq69d4lwpsfa

The build is now fixed with 1.1.10-4.