ipfire-2.x]# ./make.sh build
Packaged toolchain compilation
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
unshare: unrecognized option '--time'
Try 'unshare --help' for more information.
ERROR: Failed extracting the toolchain
any devs have an idea? i can see unshare in the make.sh file but reading the man page for it which says --time is acceptable
A new Toolchain has been issued so maybe try running
./make.sh gettoolchain
to get the latest toolchain downloaded before running
./make.sh build
next is building for me but my git repo does not include the changes from 6 and 5 hours ago and some of those involve make.sh so something might have changed and affected it.
I canāt check it at the moment as I am running a long build emulating riscv64
What OS are you on? We have recently made some changes and require some newer kernel features, but any kernel from 6.0 should be fine if not even earlier.
Im building on AlmaLinux 8.10 Linux 4.18.0-553.16.1.el8_10.x86_64 on x86_64
which has been fine up until today after a git pull, make clean, download srcās and toolchain.
i deleted everything and will try again from scratch
You can remove the āātimeā switch and see what happens afterā¦ Kernel 4.18 is quite old and out of support for a very long time.
Using leapp to upgrade from 8 to 9 and will test after that
ok so got that all sorted and even updated the kernel
[root@sio9 ipfire-2.x]# ./make.sh build
Packaged toolchain compilation
Building IPFire
stage2
Aug 23 23:10:01: Building stage2 unshare: cannot change /home/ipfire/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
ERROR: Downloading stage2 [ FAIL ]
Check /home/ipfire/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ]
[root@sio9 ipfire-2.x]# uname -a
Linux sio9.loop.net 6.10.6-1.el9.elrepo.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Aug 19 13:18:57 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux
[root@sio9 ipfire-2.x]#
am i now a few kernels too far?
UPDATE:
the quick fix for my issue was to mount the directory first before unsure ran
local unshare=()
sudo mount -o bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
# Configure a new namespace
if [ -n "${IN_NAMESPACE}" ]; then
unshare+=(
# Create a new cgroup namespace
"--cgroup"
# Create a new mount namespace
"--mount"
"--propagation=slave"
# Create a new PID namespace and fork
"--pid"
"--fork"
# Create a new time namespace
"--time"
# Create a new UTS namespace
"--uts"
# Mount /proc so that the build environment does not see
# any foreign processes.
"--mount-proc=${BUILD_DIR}/proc"
# If unshare is asked to terminate, terminate all child processes
"--kill-child"
)
fi
[root@sio9 ipfire-2.x]# ./make.sh build
Building IPFire
stage2 [ 1 ][ DONE ]
linux (6.6.47) HEADERS=1 [ 29 ][ DONE ]
man-pages (6.9.1) [ 7 ][ DONE ]
glibc (2.39) [ 1:31 ]
Hi,
YMMD!
I had the same problems - and error message - as you.
My solution was to add two āmountā-lines further back. Donāt know why - but it was the only way to get things running:
...
# If unshare is asked to terminate, terminate all child processes
"--kill-child"
)
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
mount --make-rslave ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
case "${1}" in
...
Discussion:
=> Re: The unshared changes give a problem with build after doing git pull on next - Development - lists.ipfire.org
Best
Matthias
I only had to do the one line and the build completed with out any more issues. I have some plugins to compile now so Iāll report back if I get any errors doing that.
Iām testing with your oneliner and its workingā¦
I must confess: my two lines were pure ātry and errorā and I was astonished when it suddenly worked.
Either of your changes are breaking the integrity of the container and PID namespace by loading the hosts /proc filesystem into the build system. They would have totally different contents in both cases.
We will have to fix this properly for older kernels, and we cannot use those workarounds as they are not working around anything.
i was just trying some of the things i found on the web that was discussing the error and figured id post what i found after i tried it.
https://github.com/util-linux/util-linux/issues/718
https://github.com/util-linux/util-linux/issues/648#issuecomment-404066455
Iāll stop posting āfixesā from now on and let the dev team handle it.
This is not what I meant of course.
Iāve tried a lot of Variations to the unshare code in make.sh using the unshare man page and the only thing Iāve found that works is mounting the proc folder and letting unshare remount it like the second link I posted above talks about. So if that breaks the namespace then I donāt have any other ideas to work with since everything on google pertaining to the error leads in that direction unless Iām just not reading their conversations correctly.
Hi,
some news from me - the solution from above doesnāt work (anymore).
After starting ./make.sh downloadsrc Iām getting the following errors:
root@Devel64-1: /git/ipfire-2.x # ./make.sh downloadsrc
Pre-loading all source files
7zip (17.05) mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist.
[ DONE ]
abseil-cpp (20230802.1) mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist.
[ DONE ]
acl (2.3.2) mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist.
...
At this point I pressed CTRL-Cā¦
For me the only way to get ānextā running is adding mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc as in post #9.
It just needs this single line, the second one does not seem to be absolutely necessary - build is running.
But I donāt still know why, sorry.
i can agree on that, the placement of where i put my line was definitely the issue with the downloads.
No this would not break it, it would be a possible workaround, although you are doing it at the wrong place, but that should not be the problem here.
We are having half of this conversation on the list and half on here which does not help with keeping things clear with all parties. I prefer to have development talk on the list only so that there is only one place.
A mkdir would fix that 