Build failing when building kernel manually on equuleus

Hi all.

I Hope I’m in the correct section of the forum otherwise please let me know.

I’m having issues making a custom Vyos 1.3.0 iso. I’m using the docker container vyos/vyos-build:equuleus and using the latest commit of the equuleus branch of the vyos-build repository. I’m following the steps from this guide : Build VyOS — VyOS 1.4.x (sagitta) documentation

When in the container, just using the configure command and making the ISO works fine.

However when using custom kernel debs in the packages directory (/vyos/packages/) the build fails with dependencies issues for squashfs-tools.
For the moment I’ve tried building the kernel version 5.4.158 myself (with the provided script and no modification to the configuration or source code) and also just downloading the ones from the official vyos repositories to the packages directory. It failed every time with the following error.

[2021-11-10 20:50:09] lb binary_rootfs 
P: Begin building root filesystem image...
Reading package lists...
Building dependency tree...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 squashfs-tools : Depends: libzstd1 (>= 1.4.0) but 1.3.8+dfsg-3+deb10u2 is to be installed
E: Unable to correct problems, you have held broken packages.
P: Begin unmounting filesystems...
P: Saving caches...

What’s weird is that when looking at the Jenkins build squashfs-tools is supposed to require liblzo2-2 and here my build shows it requires libzstd1.

When chrooting inside the build/chroot folder and manually trying to install the package the error confirms itself with the exact same error.

I’ve managed to install squashfs-tools by modifying the file “/etc/apt/preferences” and replacing “debian” by “buster” at line 8. When doing this it also uses the same dependencies as in the Jenkins build.

Nothing productive to contribute but just wanted to thank you (sarcastically) for contributing to the voice in my head saying “Kaaaaaaaarrrrrrrrrrrllllllllllll” that will persist for days now. Guess I just need to go watch the YouTube vids. It’s been a while anyway. Hope you get a resolution to your problem. Mine will require therapy. :sweat_smile:

1 Like

I’ve still not found a fix to propose but what seems to happen is that the repos of buster and bullseye have the same priority at that stage of the live build.

(Here I’m chrooted in the build dir after it has failed)

root@8f43553b9551:/# apt-cache policy squashfs-tools
squashfs-tools:
  Installed: (none)
  Candidate: 1:4.4-2+deb11u1
  Version table:
     1:4.4-2+deb11u1 99
         99 http://deb.debian.org/debian bullseye/main amd64 Packages
     1:4.3-12+deb10u2 99
         99 http://deb.debian.org/debian-security buster/updates/main amd64 Packages
     1:4.3-12+deb10u1 99
         99 http://deb.debian.org/debian buster/main amd64 Packages

This causes the live build to try to install the bullseye version of squashfs-tools.
However looking at the jenkins builds it is definitely buster’s version that is installed :

[2021-11-11T04:52:14.303Z] Get:2 http://deb.debian.org/debian-security buster/updates/main amd64 squashfs-tools amd64 1:4.3-12+deb10u2 [126 kB]

Refering to my initial message :

I’ve managed to install squashfs-tools by modifying the file “/etc/apt/preferences” and replacing “debian” by “buster” at line 8. When doing this it also uses the same dependencies as in the Jenkins build.

This is definitely a bad idea as “buster” is not an valid origin name (I’ve documented myself a bit more since then).

But would it be possible that the preference file is not precise enough and inadvertently changes the priority of both buster’s and bullseye’s repositories instead of only buster’s?
Maybe this is being an issue since having migrated to FRR 7.5? (Before then only buster repositories were being used which would not cause this issue)

I’ve obtained the same “successful” result by appending “n,=buster” to the preferences file which successfuly changes the preferences of buster repos but not bullseye :

root@8f43553b9551:/# apt-cache policy squashfs-tools
squashfs-tools:
  Installed: (none)
  Candidate: 1:4.3-12+deb10u2
  Version table:
     1:4.4-2+deb11u1 -10
        -10 http://deb.debian.org/debian bullseye/main amd64 Packages
     1:4.3-12+deb10u2 99
         99 http://deb.debian.org/debian-security buster/updates/main amd64 Packages
     1:4.3-12+deb10u1 99
         99 http://deb.debian.org/debian buster/main amd64 Packages

Unfortunately I’ve not found any way to change this before launching the live build. I’m not experienced enough

I have the same issue when building equuleus too… Did you find a fix?

What I found is more of a botch than a real fix but I managed to get the whole build process to work by pinning the squashfs-tools package in bullseye’s repos to a lower priotity :

cat >> /vyos/data/live-build-config/archives/bullseye.pref.chroot << EOF
Package: squashfs-tools
Pin: release n=bullseye
Pin-Priority: -10
EOF

I checked all packages versions afterwards and it seems to match those of the official epa3 build.

Thanks! It works this way.

@furest @fegauthier This is the same workaround I’ve advocated, pending a full explanation of what apt is doing behind the scenes; I may well push this for now, and was about to send to @fegauthier regarding his earlier forum post.

Any fix for building 1.2.8 iso with custom patched kernel and local packages?