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.
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)
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 :
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 :
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 :
@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.
