Unable to build ISO 1.4

Hi Team,

I am trying to build 1.4.2 ISO on Debian 12 however its failing consistently. Can anyone help me please?


Installing new version of config file /etc/skel/.bashrc ...
Installing new version of config file /etc/skel/.profile ...
Created symlink /etc/systemd/system/cloud-init-local.service.wants/vyos-config-cloud-init.service → /lib/systemd/system/vyos-config-cloud-init.service.
Unit /lib/systemd/system/vyos-config-cloud-init.service is added as a dependency to a non-existent unit cloud-init-local.service.
Setting up vyos-1x-vmware (1.4.0-epa2-205-gd8bca084a) ...
Setting up vyos-world (1.4.0+vyos1+current) ...
Setting up vyos-1x-smoketest (1.4.0-epa2-205-gd8bca084a) ...
Getting image source signatures
Copying blob 7b2699543f22 done
Copying config ba5dc23f65 [--------------------------------------] 0.0b / 372.0b
FATA[0049] copying system image from manifest list: reading config blob sha256:ba5dc23f65d4cc4a4535bce55cf9e63b068eb02946e3422d3587e8ce803b6aab: Get "https://productionm/registry-v2/docker/registry/v2/blobs/sha256/ba/ba5dc23f65d4cc4a4535bce55cf9e63b068eb02946e3422d3587e8ce803b6aab/data?verify=1713263145-56bWjscDEfPyZGFmVAWR2f47WcI%3D".215:443: i/o timeout
dpkg: error processing package vyos-1x-smoketest (--configure):
 installed vyos-1x-smoketest package post-installation script subprocess returned error exit status 1
Processing triggers for initramfs-tools (0.142) ...
Processing triggers for dbus (1.14.10-1~deb12u1) ...
Processing triggers for rsyslog (8.2302.0-1) ...
invoke-rc.d: unknown initscript, /etc/init.d/rsyslog not found.
Running in chroot, ignoring request.
Processing triggers for nginx (1.22.1-9) ...
Running in chroot, ignoring request.
All runlevel operations denied by policy
Errors were encountered while processing:
 vyos-1x-smoketest
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done

The log you provided contains where it fails.
Also, “FATA”, stands for Fatal.

I am sorry since I was not in town didnt look at the alerts. What could be the issue then?

I would try again and if it fails again, please provide ALL steps you followed/executed.
Much easier to suggest what might be the issue then :slight_smile:

Ok Tried again and here are the steps
Here are the commands I ran on host system

   53  cd /opt/
   54  git clone -b sagitta --single-branch https://github.com/vyos/vyos-build
   55  cd vyos-build/
   56  ls
   57  docker run --rm -it --privileged -v $(pwd):/vyos -w /vyos vyos/vyos-build:sagitta bash

Below commands are from docker

root@63ea0382b403:/vyos# history
    1  os=buster64 branch=sagitta make build
    2  sudo make clean
    3  sudo ./build-vyos-image iso --architecture amd64 --build-by "blason@example.com"
    4  history

And here is the error


Get:37 http://deb.debian.org/debian trixie/non-free amd64 Packages [97.5 kB]
Get:38 http://deb.debian.org/debian trixie/non-free Translation-en [67.1 kB]
Reading package lists... Done
E: The repository 'http://dev.packages.vyos.net/repositories/sagitta sagitta Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
N: Repository 'Debian bookworm' changed its 'non-free component' value from 'non-free' to 'non-free non-free-firmware'
N: More information about this can be found online in the Release notes at: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.html#non-free-split
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done
Building dependency tree... Done

Can this be error then?

image

Why does it say Debian Trixie?

This is my base host system

root@vyos-build-db12:/opt/vyos-build# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm

And then I am pulling docker

I guess the image that I pull has those trixie names mentioned?

Ahh right sorry - it must be how the current build scripts are. Sorry I’m not sure what’s going on, hopefully someone from the Vyos team can answer.

Not sure why but I followed the steps on hosts machine with instructions from Dockerfile and it successfully done but it failed on Docker consistently.

I have tried to build from source without using Docker (following the instructions for native build of 1.4 in a fresh Debian 12 VM) but it fails when trying to access the repo:

Err:8 https://sagitta-packages.vyos.net sagitta InRelease
403 Forbidden [IP: 104.18.31.79 443]

Trying to access the URL from a web browser also reports an error.

Sorry, you have been blocked

You are unable to access vyos.net

Why have I been blocked?

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

What can I do to resolve this?

You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.

Even if I try from a totally different IP (mobile Internet), it still says the same thing (which doesn’t make sense, simply opening an URL in Safari on iPhone shouldn’t trigger any security solution). So it looks like it’s not just me. Does it work for anyone else?

I guess many people are trying to build from source - could that repo be mirrored somewhere to cope with the load? Or could the binary packages (non-)available from that repo (can’t even download a list of them) be built from source?

Same for me at the moment.

I have the same issue. 1.3 won’t build as well. I can build 1.5 without issues

Reported in ⚓ T6249 ISO builder fails because of changed buster-backport repository (which was originally about 1.3 build failing because of moved old Debian repo, but also tagged for 1.4 so I thought it seemed appropriate to mention a similar failure just a different repo not accessible).

1 Like

Seems like they blocked access to the repo based on this blog post. :frowning:

That blog post appeared only after my report ⚓ T6264 ISO builder fails to build 1.4 because of sagitta-packages repo 403 error - not very nice to the community. The 403 error from Cloudlflare looked very confusing, more like access was blocked because of a DDoS or something.

I;d be glad to rebuild all these packages from sources using my own CPU cycles, disk space and bandwidth, but access to patches and build scipts is denied too. “all code is in github” - really? So, how do I rebuild, say, https://dev.packages.vyos.net/repositories/sagitta/pool/main/a/accel-ppp/accel-ppp_1.12.0-260-g19c36e5_amd64.deb (which I can’t download) from the upstream accel-ppp sources, where are the necessary patches? It’s a real question, there is a real bug in accel-ppp ⚓ T4600 Closing IPV6CP by client closes PPPoE link completely, even if IPv6 is optional which I’m trying to fix and would like to test the fix as part of VyOS but it seems it will now be easier to roll my own router on plain Debian or Alpine instead of reverse-engineering these packages.

1 Like

Access to the code is open
The accel-ppp build script you can find here

The same with patches, they are open.

Thank you. Good catch though - honestly I didn’t expect to find accel-ppp under linux-kernel. I never used the ipoe/pptp/vlan_mon modules, and kernel mode pppoe has been in the standard kernel for a long time.
That’s just the first part - now, what is the process to create a repo with all these packages like your 403 Forbidden one, stored on my local filesystem so I can then point that failing apt source to it? It doesn’t have to be bit-for-bit the same, “almost LTS 1.4+” is fine, but nightly rolling is not, as I just want to test one change at a time to fix the bug, without risk that other changes break something else.

Thanks for the hint.
Some of that complexity could be avoided though, as it all would happen on the same trusted local system.
So no need to sign and then check signatures, simply dpkg -i *.deb in the directory with built packages?