Hello,
On 8 Aug 2024, at 13:06, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
ok - please don't laugh.
I did something completely different...
I added the following to 'make.sh':
***SNIP*** diff --git a/make.sh b/make.sh index 922fc4b4c..212256ab1 100755 --- a/make.sh +++ b/make.sh @@ -662,6 +662,11 @@ execute() { # 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
I don’t know why this would fix anything.
Could you once again try to swap the slave/private parameters of the —-propagation option for both calls of unshare?
Also: Why is this working on my freshly installed system?
while [ $# -gt 0 ]; do ***SNAP***
No 'invalid argument' error anymore.
I don't know why - but with this patch the build is running...
Any comments?
Best Matthias
On 06.08.2024 17:40, Michael Tremer wrote:
Hello,
We should not touch the mount propagation of the host’s namespace.
Instead, we should create our own mount namespace and that should be private.
You can however try to see what happens when you add —-propagation=slave to the first unshare command.
I just installed the plain Ubuntu Server, installed git, checkout out the repository, downloaded the toolchain and ran the build.
-Michael
On 3 Aug 2024, at 12:22, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 03.08.2024 10:54, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
just looked through https://man7.org/linux/man-pages/man1/unshare.1.html and ran 'findmnt -o+PROPAGATION' (see attachment).
I don't know if this could help but does this differ from your test installation?
Best Matthias
On 3 Aug 2024, at 08:47, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi Michael,
[shortened some stuff]
...
>>> >>> Being curious I tried to build 'next', but I always get the same error: >>> >>> ***SNIP*** >>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>> Packaged toolchain compilation >>> Building IPFire >>> stage2 >>> Jul 26 13:32:59: Building stage2 unshare: cannot change >>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
>> ...
It looks like you can simply update the kernel staying on the same release:
https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels
For 22.04 LTS, there is a Linux 6.8 image available.
Could you check that and confirm that it fixes the mount propagation problem?
Done.
Current state is as follows:
***SNIP*** ... root@Devel64-1: /git/ipfire-2.x # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy ... root@Devel64-1: /git/ipfire-2.x # uname -mrs Linux 6.8.0-39-generic x86_64 ... ***SNAP***
But when I try to build 'next' I get exactly the same error as before:
***SNIP*** root@Devel64-1: /git/ipfire-2.x # ./make.sh build Packaged toolchain compilation Building IPFire stage2 Aug 2 21:21:15: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
Ah, this is good information. So it is not the kernel, it rather is Ubuntu handling something differently.
I will have a look at this and get back to you.
ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
Being curious, I commented line line 633 in 'make.sh' ("--mount-proc=${BUILD_DIR}/proc") => Building starts but fails during 'glib 2.77.0':
***SNIP*** ... glib (2.77.0) [ 1:14 ][0/1011]
[951/1374] Compiling C object gio/gio.p/gio-tool-tree.c.o [952/1374] Linking target gio/gio [953/1374] Compiling C object gio/gio-querymodules.p/gio-querymodules.c.o [954/1374] Linking target gio/gio-querymodules [955/1374] Compiling C object gio/gresource.p/gresource-tool.c.o [956/1374] Compiling C object gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o [957/1374] Linking target gio/gresource [958/1374] Compiling C object gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o [959/1374] Compiling C object gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o [960/1374] Compiling C object gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o [961/1374] Compiling C object gio/glib-compile-resources.p/glib-compile-resources.c.o [962/1374] Linking target gio/glib-compile-resources [963/1374] Compiling C object gio/tests/modules/libtestmodulea.so.p/test-module-a.c.o [964/1374] Compiling C object gio/gapplication.p/gapplication-tool.c.o [965/1374] Compiling C object gio/gsettings.p/gsettings-tool.c.o [966/1374] Linking target gio/tests/modules/libtestmodulea.so [967/1374] Generating gio/tests/plugin-resources.c with a custom command FAILED: gio/tests/plugin-resources.c /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources --compiler=gcc --target=gio/tests/plugin-resources.c --sour cedir=/usr/src/glib-2.77.0/gio/tests --internal --generate-source --c-name _g_plugin ../gio/tests/test4.gresource.xml /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources: error while loading shared libraries: libgio-2.0.so.0: can not open shared object file: No such file or directory [968/1374] Linking target gio/gapplication [969/1374] Compiling C object gio/glib-compile-schemas.p/glib-compile-schemas.c.o [970/1374] Linking target gio/gsettings [971/1374] Compiling C object gio/tests/modules/libtestmoduleb.so.p/test-module-b.c.o [972/1374] Compiling C object gio/tests/gdbus-overflow.p/gdbus-overflow.c.o [973/1374] Compiling C object gio/gdbus.p/gdbus-tool.c.o [974/1374] Compiling C object gio/tests/gdbus-object-manager-example/libgdbus-example-objectmanager.so.p/meson-gener ated_.._objectmanager-gen.c.o ninja: build stopped: subcommand failed. make: *** [glib:75: /usr/src/log/glib-2.77.0] Error 1 make: Leaving directory '/usr/src/lfs'
ERROR: Building glib [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
Best Matthias
On 16.08.2024 17:35, Michael Tremer wrote:
Hello,
Hi,
On 8 Aug 2024, at 13:06, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
ok - please don't laugh.
I did something completely different...
I added the following to 'make.sh':
***SNIP*** diff --git a/make.sh b/make.sh index 922fc4b4c..212256ab1 100755 --- a/make.sh +++ b/make.sh @@ -662,6 +662,11 @@ execute() { # 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
I don’t know why this would fix anything.
I don't know either. If I remove these lines, I get the 'invalid argument' errors again. Immediately.
Could you once again try to swap the slave/private parameters of the —-propagation option for both calls of unshare?
Ok. I'll try and keep you informed, lets see. By the way: "Devel 1" just built 'next' in 3:09:49, updating 'rust 1.80.1' and 'clamav 1.4.0'.
1. I commented my two lines above and I get:
... Aug 16 16:34:12: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument ...
2. I swap slave/private parameters => change line 646 to "--propagation=private" and line 2146 to "--propagation=slave" and get the same error: "...Invalid argument"
3. I swap parameters back and uncomment my two lines: => Build is running again.
Also: Why is this working on my freshly installed system?
Good question...this is something really strange...
while [ $# -gt 0 ]; do ***SNAP***
No 'invalid argument' error anymore.
I don't know why - but with this patch the build is running...
Any comments?
Best Matthias
On 06.08.2024 17:40, Michael Tremer wrote:
Hello,
We should not touch the mount propagation of the host’s namespace.
Instead, we should create our own mount namespace and that should be private.
You can however try to see what happens when you add —-propagation=slave to the first unshare command.
I just installed the plain Ubuntu Server, installed git, checkout out the repository, downloaded the toolchain and ran the build.
-Michael
On 3 Aug 2024, at 12:22, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 03.08.2024 10:54, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
just looked through https://man7.org/linux/man-pages/man1/unshare.1.html and ran 'findmnt -o+PROPAGATION' (see attachment).
I don't know if this could help but does this differ from your test installation?
Best Matthias
On 3 Aug 2024, at 08:47, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi Michael,
[shortened some stuff]
...
>>>> >>>> Being curious I tried to build 'next', but I always get the same error: >>>> >>>> ***SNIP*** >>>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>>> Packaged toolchain compilation >>>> Building IPFire >>>> stage2 >>>> Jul 26 13:32:59: Building stage2 unshare: cannot change >>>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
>>> ...
> It looks like you can simply update the kernel staying on the same release: > > https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels > > For 22.04 LTS, there is a Linux 6.8 image available. > > Could you check that and confirm that it fixes the mount propagation problem?
Done.
Current state is as follows:
***SNIP*** ... root@Devel64-1: /git/ipfire-2.x # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy ... root@Devel64-1: /git/ipfire-2.x # uname -mrs Linux 6.8.0-39-generic x86_64 ... ***SNAP***
But when I try to build 'next' I get exactly the same error as before:
***SNIP*** root@Devel64-1: /git/ipfire-2.x # ./make.sh build Packaged toolchain compilation Building IPFire stage2 Aug 2 21:21:15: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
Ah, this is good information. So it is not the kernel, it rather is Ubuntu handling something differently.
I will have a look at this and get back to you.
ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
Being curious, I commented line line 633 in 'make.sh' ("--mount-proc=${BUILD_DIR}/proc") => Building starts but fails during 'glib 2.77.0':
***SNIP*** ... glib (2.77.0) [ 1:14 ][0/1011]
[951/1374] Compiling C object gio/gio.p/gio-tool-tree.c.o [952/1374] Linking target gio/gio [953/1374] Compiling C object gio/gio-querymodules.p/gio-querymodules.c.o [954/1374] Linking target gio/gio-querymodules [955/1374] Compiling C object gio/gresource.p/gresource-tool.c.o [956/1374] Compiling C object gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o [957/1374] Linking target gio/gresource [958/1374] Compiling C object gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o [959/1374] Compiling C object gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o [960/1374] Compiling C object gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o [961/1374] Compiling C object gio/glib-compile-resources.p/glib-compile-resources.c.o [962/1374] Linking target gio/glib-compile-resources [963/1374] Compiling C object gio/tests/modules/libtestmodulea.so.p/test-module-a.c.o [964/1374] Compiling C object gio/gapplication.p/gapplication-tool.c.o [965/1374] Compiling C object gio/gsettings.p/gsettings-tool.c.o [966/1374] Linking target gio/tests/modules/libtestmodulea.so [967/1374] Generating gio/tests/plugin-resources.c with a custom command FAILED: gio/tests/plugin-resources.c /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources --compiler=gcc --target=gio/tests/plugin-resources.c --sour cedir=/usr/src/glib-2.77.0/gio/tests --internal --generate-source --c-name _g_plugin ../gio/tests/test4.gresource.xml /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources: error while loading shared libraries: libgio-2.0.so.0: can not open shared object file: No such file or directory [968/1374] Linking target gio/gapplication [969/1374] Compiling C object gio/glib-compile-schemas.p/glib-compile-schemas.c.o [970/1374] Linking target gio/gsettings [971/1374] Compiling C object gio/tests/modules/libtestmoduleb.so.p/test-module-b.c.o [972/1374] Compiling C object gio/tests/gdbus-overflow.p/gdbus-overflow.c.o [973/1374] Compiling C object gio/gdbus.p/gdbus-tool.c.o [974/1374] Compiling C object gio/tests/gdbus-object-manager-example/libgdbus-example-objectmanager.so.p/meson-gener ated_.._objectmanager-gen.c.o ninja: build stopped: subcommand failed. make: *** [glib:75: /usr/src/log/glib-2.77.0] Error 1 make: Leaving directory '/usr/src/lfs'
ERROR: Building glib [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
Best Matthias
Hello Matthias,
As you might have seen I played around with this all more… There is either a kernel bug, or a bug in unshare which causes these problems…
So if we mount /proc manually later this works for me on Ubuntu 22.04 LTS:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8ea702f3f853c4c28a28...
However, there are now some packages which don’t want to build any more.
So I would simply suggest to upgrade the kernel on your Ubuntu release like this:
apt install linux-generic-hwe-22.04
That should allow you to build with the stock make.sh again.
Best, -Michael
On 16 Aug 2024, at 17:43, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 16.08.2024 17:35, Michael Tremer wrote:
Hello,
Hi,
On 8 Aug 2024, at 13:06, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
ok - please don't laugh.
I did something completely different...
I added the following to 'make.sh':
***SNIP*** diff --git a/make.sh b/make.sh index 922fc4b4c..212256ab1 100755 --- a/make.sh +++ b/make.sh @@ -662,6 +662,11 @@ execute() { # 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
I don’t know why this would fix anything.
I don't know either. If I remove these lines, I get the 'invalid argument' errors again. Immediately.
Could you once again try to swap the slave/private parameters of the —-propagation option for both calls of unshare?
Ok. I'll try and keep you informed, lets see. By the way: "Devel 1" just built 'next' in 3:09:49, updating 'rust 1.80.1' and 'clamav 1.4.0'.
- I commented my two lines above and I get:
... Aug 16 16:34:12: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument ...
- I swap slave/private parameters
=> change line 646 to "--propagation=private" and line 2146 to "--propagation=slave" and get the same error: "...Invalid argument"
- I swap parameters back and uncomment my two lines:
=> Build is running again.
Also: Why is this working on my freshly installed system?
Good question...this is something really strange...
while [ $# -gt 0 ]; do ***SNAP***
No 'invalid argument' error anymore.
I don't know why - but with this patch the build is running...
Any comments?
Best Matthias
On 06.08.2024 17:40, Michael Tremer wrote:
Hello,
We should not touch the mount propagation of the host’s namespace.
Instead, we should create our own mount namespace and that should be private.
You can however try to see what happens when you add —-propagation=slave to the first unshare command.
I just installed the plain Ubuntu Server, installed git, checkout out the repository, downloaded the toolchain and ran the build.
-Michael
On 3 Aug 2024, at 12:22, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 03.08.2024 10:54, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
just looked through https://man7.org/linux/man-pages/man1/unshare.1.html and ran 'findmnt -o+PROPAGATION' (see attachment).
I don't know if this could help but does this differ from your test installation?
Best Matthias
> On 3 Aug 2024, at 08:47, Matthias Fischer matthias.fischer@ipfire.org wrote: > > Hi Michael, > > [shortened some stuff] > > ... > >>>>> >>>>> Being curious I tried to build 'next', but I always get the same error: >>>>> >>>>> ***SNIP*** >>>>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>>>> Packaged toolchain compilation >>>>> Building IPFire >>>>> stage2 >>>>> Jul 26 13:32:59: Building stage2 unshare: cannot change >>>>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument > >>>> ... > >> It looks like you can simply update the kernel staying on the same release: >> >> https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels >> >> For 22.04 LTS, there is a Linux 6.8 image available. >> >> Could you check that and confirm that it fixes the mount propagation problem? > > Done. > > Current state is as follows: > > ***SNIP*** > ... > root@Devel64-1: /git/ipfire-2.x # lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 22.04.4 LTS > Release: 22.04 > Codename: jammy > ... > root@Devel64-1: /git/ipfire-2.x # uname -mrs > Linux 6.8.0-39-generic x86_64 > ... > ***SNAP*** > > But when I try to build 'next' I get exactly the same error as > before: > > ***SNIP*** > root@Devel64-1: /git/ipfire-2.x # ./make.sh build > Packaged toolchain compilation > Building IPFire > stage2 > Aug 2 21:21:15: Building stage2 unshare: cannot change > /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
Ah, this is good information. So it is not the kernel, it rather is Ubuntu handling something differently.
I will have a look at this and get back to you.
> ERROR: Downloading stage2 > [ FAIL ] > Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if > applicable [ FAIL ] > ***SNAP*** > > Being curious, I commented line line 633 in 'make.sh' > ("--mount-proc=${BUILD_DIR}/proc") => Building starts but fails during > 'glib 2.77.0': > > ***SNIP*** > ... > glib (2.77.0) > [ 1:14 ][0/1011] > > [951/1374] Compiling C object gio/gio.p/gio-tool-tree.c.o > [952/1374] Linking target gio/gio > [953/1374] Compiling C object > gio/gio-querymodules.p/gio-querymodules.c.o > [954/1374] Linking target gio/gio-querymodules > [955/1374] Compiling C object gio/gresource.p/gresource-tool.c.o > [956/1374] Compiling C object > gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o > [957/1374] Linking target gio/gresource > [958/1374] Compiling C object > gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o > [959/1374] Compiling C object > gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o > [960/1374] Compiling C object > gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o > [961/1374] Compiling C object > gio/glib-compile-resources.p/glib-compile-resources.c.o > [962/1374] Linking target gio/glib-compile-resources > [963/1374] Compiling C object > gio/tests/modules/libtestmodulea.so.p/test-module-a.c.o > [964/1374] Compiling C object gio/gapplication.p/gapplication-tool.c.o > [965/1374] Compiling C object gio/gsettings.p/gsettings-tool.c.o > [966/1374] Linking target gio/tests/modules/libtestmodulea.so > [967/1374] Generating gio/tests/plugin-resources.c with a custom command > FAILED: gio/tests/plugin-resources.c > /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources > --compiler=gcc --target=gio/tests/plugin-resources.c --sour > cedir=/usr/src/glib-2.77.0/gio/tests --internal --generate-source > --c-name _g_plugin ../gio/tests/test4.gresource.xml > /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources: error > while loading shared libraries: libgio-2.0.so.0: can > not open shared object file: No such file or directory > [968/1374] Linking target gio/gapplication > [969/1374] Compiling C object > gio/glib-compile-schemas.p/glib-compile-schemas.c.o > [970/1374] Linking target gio/gsettings > [971/1374] Compiling C object > gio/tests/modules/libtestmoduleb.so.p/test-module-b.c.o > [972/1374] Compiling C object > gio/tests/gdbus-overflow.p/gdbus-overflow.c.o > [973/1374] Compiling C object gio/gdbus.p/gdbus-tool.c.o > [974/1374] Compiling C object > gio/tests/gdbus-object-manager-example/libgdbus-example-objectmanager.so.p/meson-gener > ated_.._objectmanager-gen.c.o > ninja: build stopped: subcommand failed. > make: *** [glib:75: /usr/src/log/glib-2.77.0] Error 1 > make: Leaving directory '/usr/src/lfs' > > ERROR: Building glib > [ FAIL ] > Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if > applicable [ FAIL ] > ***SNAP*** > > Best > Matthias
On 21.08.2024 16:28, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
As you might have seen I played around with this all more… There is either a kernel bug, or a bug in unshare which causes these problems…
So if we mount /proc manually later this works for me on Ubuntu 22.04 LTS:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8ea702f3f853c4c28a28...
However, there are now some packages which don’t want to build any more.
So I would simply suggest to upgrade the kernel on your Ubuntu release like this:
apt install linux-generic-hwe-22.04
Done. Ran without problems.
I'm now on "Linux Devel64-1 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC..."
That should allow you to build with the stock make.sh again.
Sorry, but no chance...
Today I tested the hint from "siosios" found in https://community.ipfire.org/t/trying-to-build-188/11999/8
Works. Build is running. I'm building 'clamav 1.4.0' right now.
One glitch I found: the new build still has problems identifying the need for customizing new rootfiles(?).
Best Matthias
Best, -Michael
On 16 Aug 2024, at 17:43, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 16.08.2024 17:35, Michael Tremer wrote:
Hello,
Hi,
On 8 Aug 2024, at 13:06, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
ok - please don't laugh.
I did something completely different...
I added the following to 'make.sh':
***SNIP*** diff --git a/make.sh b/make.sh index 922fc4b4c..212256ab1 100755 --- a/make.sh +++ b/make.sh @@ -662,6 +662,11 @@ execute() { # 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
I don’t know why this would fix anything.
I don't know either. If I remove these lines, I get the 'invalid argument' errors again. Immediately.
Could you once again try to swap the slave/private parameters of the —-propagation option for both calls of unshare?
Ok. I'll try and keep you informed, lets see. By the way: "Devel 1" just built 'next' in 3:09:49, updating 'rust 1.80.1' and 'clamav 1.4.0'.
- I commented my two lines above and I get:
... Aug 16 16:34:12: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument ...
- I swap slave/private parameters
=> change line 646 to "--propagation=private" and line 2146 to "--propagation=slave" and get the same error: "...Invalid argument"
- I swap parameters back and uncomment my two lines:
=> Build is running again.
Also: Why is this working on my freshly installed system?
Good question...this is something really strange...
while [ $# -gt 0 ]; do ***SNAP***
No 'invalid argument' error anymore.
I don't know why - but with this patch the build is running...
Any comments?
Best Matthias
On 06.08.2024 17:40, Michael Tremer wrote:
Hello,
We should not touch the mount propagation of the host’s namespace.
Instead, we should create our own mount namespace and that should be private.
You can however try to see what happens when you add —-propagation=slave to the first unshare command.
I just installed the plain Ubuntu Server, installed git, checkout out the repository, downloaded the toolchain and ran the build.
-Michael
On 3 Aug 2024, at 12:22, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 03.08.2024 10:54, Michael Tremer wrote: > Hello Matthias,
Hi Michael,
just looked through https://man7.org/linux/man-pages/man1/unshare.1.html and ran 'findmnt -o+PROPAGATION' (see attachment).
I don't know if this could help but does this differ from your test installation?
Best Matthias
>> On 3 Aug 2024, at 08:47, Matthias Fischer matthias.fischer@ipfire.org wrote: >> >> Hi Michael, >> >> [shortened some stuff] >> >> ... >> >>>>>> >>>>>> Being curious I tried to build 'next', but I always get the same error: >>>>>> >>>>>> ***SNIP*** >>>>>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>>>>> Packaged toolchain compilation >>>>>> Building IPFire >>>>>> stage2 >>>>>> Jul 26 13:32:59: Building stage2 unshare: cannot change >>>>>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument >> >>>>> ... >> >>> It looks like you can simply update the kernel staying on the same release: >>> >>> https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels >>> >>> For 22.04 LTS, there is a Linux 6.8 image available. >>> >>> Could you check that and confirm that it fixes the mount propagation problem? >> >> Done. >> >> Current state is as follows: >> >> ***SNIP*** >> ... >> root@Devel64-1: /git/ipfire-2.x # lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description: Ubuntu 22.04.4 LTS >> Release: 22.04 >> Codename: jammy >> ... >> root@Devel64-1: /git/ipfire-2.x # uname -mrs >> Linux 6.8.0-39-generic x86_64 >> ... >> ***SNAP*** >> >> But when I try to build 'next' I get exactly the same error as >> before: >> >> ***SNIP*** >> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >> Packaged toolchain compilation >> Building IPFire >> stage2 >> Aug 2 21:21:15: Building stage2 unshare: cannot change >> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument > > Ah, this is good information. So it is not the kernel, it rather is Ubuntu handling something differently. > > I will have a look at this and get back to you. > >> ERROR: Downloading stage2 >> [ FAIL ] >> Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if >> applicable [ FAIL ] >> ***SNAP*** >> >> Being curious, I commented line line 633 in 'make.sh' >> ("--mount-proc=${BUILD_DIR}/proc") => Building starts but fails during >> 'glib 2.77.0': >> >> ***SNIP*** >> ... >> glib (2.77.0) >> [ 1:14 ][0/1011] >> >> [951/1374] Compiling C object gio/gio.p/gio-tool-tree.c.o >> [952/1374] Linking target gio/gio >> [953/1374] Compiling C object >> gio/gio-querymodules.p/gio-querymodules.c.o >> [954/1374] Linking target gio/gio-querymodules >> [955/1374] Compiling C object gio/gresource.p/gresource-tool.c.o >> [956/1374] Compiling C object >> gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o >> [957/1374] Linking target gio/gresource >> [958/1374] Compiling C object >> gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o >> [959/1374] Compiling C object >> gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o >> [960/1374] Compiling C object >> gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o >> [961/1374] Compiling C object >> gio/glib-compile-resources.p/glib-compile-resources.c.o >> [962/1374] Linking target gio/glib-compile-resources >> [963/1374] Compiling C object >> gio/tests/modules/libtestmodulea.so.p/test-module-a.c.o >> [964/1374] Compiling C object gio/gapplication.p/gapplication-tool.c.o >> [965/1374] Compiling C object gio/gsettings.p/gsettings-tool.c.o >> [966/1374] Linking target gio/tests/modules/libtestmodulea.so >> [967/1374] Generating gio/tests/plugin-resources.c with a custom command >> FAILED: gio/tests/plugin-resources.c >> /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources >> --compiler=gcc --target=gio/tests/plugin-resources.c --sour >> cedir=/usr/src/glib-2.77.0/gio/tests --internal --generate-source >> --c-name _g_plugin ../gio/tests/test4.gresource.xml >> /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources: error >> while loading shared libraries: libgio-2.0.so.0: can >> not open shared object file: No such file or directory >> [968/1374] Linking target gio/gapplication >> [969/1374] Compiling C object >> gio/glib-compile-schemas.p/glib-compile-schemas.c.o >> [970/1374] Linking target gio/gsettings >> [971/1374] Compiling C object >> gio/tests/modules/libtestmoduleb.so.p/test-module-b.c.o >> [972/1374] Compiling C object >> gio/tests/gdbus-overflow.p/gdbus-overflow.c.o >> [973/1374] Compiling C object gio/gdbus.p/gdbus-tool.c.o >> [974/1374] Compiling C object >> gio/tests/gdbus-object-manager-example/libgdbus-example-objectmanager.so.p/meson-gener >> ated_.._objectmanager-gen.c.o >> ninja: build stopped: subcommand failed. >> make: *** [glib:75: /usr/src/log/glib-2.77.0] Error 1 >> make: Leaving directory '/usr/src/lfs' >> >> ERROR: Building glib >> [ FAIL ] >> Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if >> applicable [ FAIL ] >> ***SNAP*** >> >> Best >> Matthias
Hello,
On 24 Aug 2024, at 09:33, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 21.08.2024 16:28, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
As you might have seen I played around with this all more… There is either a kernel bug, or a bug in unshare which causes these problems…
So if we mount /proc manually later this works for me on Ubuntu 22.04 LTS:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8ea702f3f853c4c28a28...
However, there are now some packages which don’t want to build any more.
So I would simply suggest to upgrade the kernel on your Ubuntu release like this:
apt install linux-generic-hwe-22.04
Done. Ran without problems.
I'm now on "Linux Devel64-1 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC..."
That should allow you to build with the stock make.sh again.
Sorry, but no chance...
Today I tested the hint from "siosios" found in https://community.ipfire.org/t/trying-to-build-188/11999/8
Are you referring to this?
mount -o bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
He put this into an unfortunate place and will mount this over and over and over again... but making the empty directory a mount point is something that would acceptable as a workaround.
If you can confirm, I can add this to the code.
Works. Build is running. I'm building 'clamav 1.4.0' right now.
One glitch I found: the new build still has problems identifying the need for customizing new rootfiles(?).
This might be fixed here:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=d7ee801712705c97fda6...
Best Matthias
Best, -Michael
On 16 Aug 2024, at 17:43, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 16.08.2024 17:35, Michael Tremer wrote:
Hello,
Hi,
On 8 Aug 2024, at 13:06, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
ok - please don't laugh.
I did something completely different...
I added the following to 'make.sh':
***SNIP*** diff --git a/make.sh b/make.sh index 922fc4b4c..212256ab1 100755 --- a/make.sh +++ b/make.sh @@ -662,6 +662,11 @@ execute() { # 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
I don’t know why this would fix anything.
I don't know either. If I remove these lines, I get the 'invalid argument' errors again. Immediately.
Could you once again try to swap the slave/private parameters of the —-propagation option for both calls of unshare?
Ok. I'll try and keep you informed, lets see. By the way: "Devel 1" just built 'next' in 3:09:49, updating 'rust 1.80.1' and 'clamav 1.4.0'.
- I commented my two lines above and I get:
... Aug 16 16:34:12: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument ...
- I swap slave/private parameters
=> change line 646 to "--propagation=private" and line 2146 to "--propagation=slave" and get the same error: "...Invalid argument"
- I swap parameters back and uncomment my two lines:
=> Build is running again.
Also: Why is this working on my freshly installed system?
Good question...this is something really strange...
while [ $# -gt 0 ]; do ***SNAP***
No 'invalid argument' error anymore.
I don't know why - but with this patch the build is running...
Any comments?
Best Matthias
On 06.08.2024 17:40, Michael Tremer wrote:
Hello,
We should not touch the mount propagation of the host’s namespace.
Instead, we should create our own mount namespace and that should be private.
You can however try to see what happens when you add —-propagation=slave to the first unshare command.
I just installed the plain Ubuntu Server, installed git, checkout out the repository, downloaded the toolchain and ran the build.
-Michael
> On 3 Aug 2024, at 12:22, Matthias Fischer matthias.fischer@ipfire.org wrote: > > On 03.08.2024 10:54, Michael Tremer wrote: >> Hello Matthias, > > Hi Michael, > > just looked through https://man7.org/linux/man-pages/man1/unshare.1.html > and ran 'findmnt -o+PROPAGATION' (see attachment). > > I don't know if this could help but does this differ from your test > installation? > > Best > Matthias > >>> On 3 Aug 2024, at 08:47, Matthias Fischer matthias.fischer@ipfire.org wrote: >>> >>> Hi Michael, >>> >>> [shortened some stuff] >>> >>> ... >>> >>>>>>> >>>>>>> Being curious I tried to build 'next', but I always get the same error: >>>>>>> >>>>>>> ***SNIP*** >>>>>>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>>>>>> Packaged toolchain compilation >>>>>>> Building IPFire >>>>>>> stage2 >>>>>>> Jul 26 13:32:59: Building stage2 unshare: cannot change >>>>>>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument >>> >>>>>> ... >>> >>>> It looks like you can simply update the kernel staying on the same release: >>>> >>>> https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels >>>> >>>> For 22.04 LTS, there is a Linux 6.8 image available. >>>> >>>> Could you check that and confirm that it fixes the mount propagation problem? >>> >>> Done. >>> >>> Current state is as follows: >>> >>> ***SNIP*** >>> ... >>> root@Devel64-1: /git/ipfire-2.x # lsb_release -a >>> No LSB modules are available. >>> Distributor ID: Ubuntu >>> Description: Ubuntu 22.04.4 LTS >>> Release: 22.04 >>> Codename: jammy >>> ... >>> root@Devel64-1: /git/ipfire-2.x # uname -mrs >>> Linux 6.8.0-39-generic x86_64 >>> ... >>> ***SNAP*** >>> >>> But when I try to build 'next' I get exactly the same error as >>> before: >>> >>> ***SNIP*** >>> root@Devel64-1: /git/ipfire-2.x # ./make.sh build >>> Packaged toolchain compilation >>> Building IPFire >>> stage2 >>> Aug 2 21:21:15: Building stage2 unshare: cannot change >>> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument >> >> Ah, this is good information. So it is not the kernel, it rather is Ubuntu handling something differently. >> >> I will have a look at this and get back to you. >> >>> ERROR: Downloading stage2 >>> [ FAIL ] >>> Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if >>> applicable [ FAIL ] >>> ***SNAP*** >>> >>> Being curious, I commented line line 633 in 'make.sh' >>> ("--mount-proc=${BUILD_DIR}/proc") => Building starts but fails during >>> 'glib 2.77.0': >>> >>> ***SNIP*** >>> ... >>> glib (2.77.0) >>> [ 1:14 ][0/1011] >>> >>> [951/1374] Compiling C object gio/gio.p/gio-tool-tree.c.o >>> [952/1374] Linking target gio/gio >>> [953/1374] Compiling C object >>> gio/gio-querymodules.p/gio-querymodules.c.o >>> [954/1374] Linking target gio/gio-querymodules >>> [955/1374] Compiling C object gio/gresource.p/gresource-tool.c.o >>> [956/1374] Compiling C object >>> gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o >>> [957/1374] Linking target gio/gresource >>> [958/1374] Compiling C object >>> gio/glib-compile-schemas.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o >>> [959/1374] Compiling C object >>> gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-reader.c.o >>> [960/1374] Compiling C object >>> gio/glib-compile-resources.p/.._subprojects_gvdb_gvdb_gvdb-builder.c.o >>> [961/1374] Compiling C object >>> gio/glib-compile-resources.p/glib-compile-resources.c.o >>> [962/1374] Linking target gio/glib-compile-resources >>> [963/1374] Compiling C object >>> gio/tests/modules/libtestmodulea.so.p/test-module-a.c.o >>> [964/1374] Compiling C object gio/gapplication.p/gapplication-tool.c.o >>> [965/1374] Compiling C object gio/gsettings.p/gsettings-tool.c.o >>> [966/1374] Linking target gio/tests/modules/libtestmodulea.so >>> [967/1374] Generating gio/tests/plugin-resources.c with a custom command >>> FAILED: gio/tests/plugin-resources.c >>> /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources >>> --compiler=gcc --target=gio/tests/plugin-resources.c --sour >>> cedir=/usr/src/glib-2.77.0/gio/tests --internal --generate-source >>> --c-name _g_plugin ../gio/tests/test4.gresource.xml >>> /usr/src/glib-2.77.0/builddir/gio/glib-compile-resources: error >>> while loading shared libraries: libgio-2.0.so.0: can >>> not open shared object file: No such file or directory >>> [968/1374] Linking target gio/gapplication >>> [969/1374] Compiling C object >>> gio/glib-compile-schemas.p/glib-compile-schemas.c.o >>> [970/1374] Linking target gio/gsettings >>> [971/1374] Compiling C object >>> gio/tests/modules/libtestmoduleb.so.p/test-module-b.c.o >>> [972/1374] Compiling C object >>> gio/tests/gdbus-overflow.p/gdbus-overflow.c.o >>> [973/1374] Compiling C object gio/gdbus.p/gdbus-tool.c.o >>> [974/1374] Compiling C object >>> gio/tests/gdbus-object-manager-example/libgdbus-example-objectmanager.so.p/meson-gener >>> ated_.._objectmanager-gen.c.o >>> ninja: build stopped: subcommand failed. >>> make: *** [glib:75: /usr/src/log/glib-2.77.0] Error 1 >>> make: Leaving directory '/usr/src/lfs' >>> >>> ERROR: Building glib >>> [ FAIL ] >>> Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if >>> applicable [ FAIL ] >>> ***SNAP*** >>> >>> Best >>> Matthias
On 27.08.2024 12:01, Michael Tremer wrote:
Hello,
Hi,
On 24 Aug 2024, at 09:33, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 21.08.2024 16:28, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
As you might have seen I played around with this all more… There is either a kernel bug, or a bug in unshare which causes these problems…
So if we mount /proc manually later this works for me on Ubuntu 22.04 LTS:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8ea702f3f853c4c28a28...
However, there are now some packages which don’t want to build any more.
So I would simply suggest to upgrade the kernel on your Ubuntu release like this:
apt install linux-generic-hwe-22.04
Done. Ran without problems.
I'm now on "Linux Devel64-1 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC..."
That should allow you to build with the stock make.sh again.
Sorry, but no chance...
Today I tested the hint from "siosios" found in https://community.ipfire.org/t/trying-to-build-188/11999/8
Are you referring to this?
mount -o bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
He put this into an unfortunate place and will mount this over and over and over again... but making the empty directory a mount point is something that would acceptable as a workaround.
I tested this again today, but running "./make.sh downloadsrc" ended in a bunch of error messages: "...mount point does not exist".
So I'm back to my previous solution from https://community.ipfire.org/t/trying-to-build-188/11999/9
And I found that I only need ONE line:
... # If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do case "${1}" in ...
If you can confirm, I can add this to the code.
Right now I wouldn't add anything. This is too mysterious (to me). Its working - but I don't know why.
In a few days the LTS-update for Ubuntu 24.04 LTS will be available - its scheduled for August 29. I'll test this update and then we'll see.
Works. Build is running. I'm building 'clamav 1.4.0' right now.
One glitch I found: the new build still has problems identifying the need for customizing new rootfiles(?).
This might be fixed here:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=d7ee801712705c97fda6...
Thanks! I'm testing...
Best Matthias
[Shortened some stuff - again]
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
Hello everyone,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
testing this now https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a... and will let you know.
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
Hi All,
On 28/08/2024 18:30, Matthias Fischer wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
I don't know if the problem is because of the above commit but coreutils fails to build. It appears to be not finding aclocal-1.16
It built fine yesterday so the problem must be one of the updates that was in the git pull I did today.
Regards,
Adolf.
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
On 28.08.2024 19:52, Adolf Belka wrote:
Hi All,
On 28/08/2024 18:30, Matthias Fischer wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
I don't know if the problem is because of the above commit but coreutils fails to build. It appears to be not finding aclocal-1.16
IMHO 'automake 1.16.5 => 1.17' must be the culprit...
It built fine yesterday so the problem must be one of the updates that was in the git pull I did today.
Just a quick test: went back to 'automake 1.16.5'. Build runs.
Best Matthias
Regards,
Adolf.
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
Hi Matthias,
On 28/08/2024 20:28, Matthias Fischer wrote:
On 28.08.2024 19:52, Adolf Belka wrote:
Hi All,
On 28/08/2024 18:30, Matthias Fischer wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3ae7719925ede8470069a6I don't know if the problem is because of the above commit but coreutils fails to build. It appears to be not finding aclocal-1.16
IMHO 'automake 1.16.5 => 1.17' must be the culprit...
but that is then also a peculiarity as I did the update build of automake to 1.17 and the build system had the same coreutils as today and the whole build went successfully. Coreutils was updated to the current version by myself back on 12th June and it was merged on 22nd July.
A difference today is the make.sh file but also the toolchain has been bumped up due to the binutils update.
If coreutils is not being built due to automake-1.17 I can't understand why my build of automake-1.17 with the same version of coreutils did build successfully. There must be some other factor interacting.
Regards, Adolf.
It built fine yesterday so the problem must be one of the updates that was in the git pull I did today.
Just a quick test: went back to 'automake 1.16.5'. Build runs.
Best Matthias
Regards,
Adolf.
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c9147ace4d509f7d2317c-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
On 28/08/2024 21:10, Adolf Belka wrote:
Hi Matthias,
On 28/08/2024 20:28, Matthias Fischer wrote:
On 28.08.2024 19:52, Adolf Belka wrote:
Hi All,
On 28/08/2024 18:30, Matthias Fischer wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
I don't know if the problem is because of the above commit but coreutils fails to build. It appears to be not finding aclocal-1.16
IMHO 'automake 1.16.5 => 1.17' must be the culprit...
but that is then also a peculiarity as I did the update build of automake to 1.17 and the build system had the same coreutils as today and the whole build went successfully. Coreutils was updated to the current version by myself back on 12th June and it was merged on 22nd July.
A difference today is the make.sh file but also the toolchain has been bumped up due to the binutils update.
If coreutils is not being built due to automake-1.17 I can't understand why my build of automake-1.17 with the same version of coreutils did build successfully. There must be some other factor interacting.
and I have done at least 4 or 5 builds successfully since automake-1.17 was pulled into my build system.
Regards, Adolf.
It built fine yesterday so the problem must be one of the updates that was in the git pull I did today.
Just a quick test: went back to 'automake 1.16.5'. Build runs.
Best Matthias
Regards,
Adolf.
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
Hello,
On 28 Aug 2024, at 21:10, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Matthias,
On 28/08/2024 20:28, Matthias Fischer wrote:
On 28.08.2024 19:52, Adolf Belka wrote:
Hi All,
On 28/08/2024 18:30, Matthias Fischer wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
I don't know if the problem is because of the above commit but coreutils fails to build. It appears to be not finding aclocal-1.16
IMHO 'automake 1.16.5 => 1.17' must be the culprit...
but that is then also a peculiarity as I did the update build of automake to 1.17 and the build system had the same coreutils as today and the whole build went successfully. Coreutils was updated to the current version by myself back on 12th June and it was merged on 22nd July.
A difference today is the make.sh file but also the toolchain has been bumped up due to the binutils update.
If coreutils is not being built due to automake-1.17 I can't understand why my build of automake-1.17 with the same version of coreutils did build successfully. There must be some other factor interacting.
This is because of the older toolchain. We used to ship automake 1.16 in the old toolchain and automake 1.17 in the actual system last week.
I then rebuilt the toolchain so that we have the same versions throughout which removed automake 1.16. When Coreutils was calling autoreconf, it found the older version of automake in the toolchain and used that. Now that has gone, it can only find 1.17 and is unhappy with that.
So, these are just normal birthing issues with a new toolchain :)
-Michael
Regards, Adolf.
It built fine yesterday so the problem must be one of the updates that was in the git pull I did today.
Just a quick test: went back to 'automake 1.16.5'. Build runs. Best Matthias
Regards,
Adolf.
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
I ran two separate builds on two different machines from scratch and they ran through the build process no problems that i could tell. I also added the netdata package to the mix on a second run on one of the machines and failed the build with the below error. mind you i have a 3rd machine with CU187 on it and it built the netdata package flawlessly, same files as I used on the CU188 machine so I am not sure if this is from the change or not. I have also gone into the shell with make.sh on the machine that had the error and could build netdata just fine with the same commands as in the lfs file.
netdata build from shell: --- We are done! ---
^ |.-. .-. .-. .-. .-. . netdata .-. .-. .-. .-. .-. .- | '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' +----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--->
--- is installed now! --- enjoy real-time performance and health monitoring...
ipfire build chroot (x86_64) root:~/netdata-v1.47.0$ Ping from shell: [root@cloud ipfire-2.x]# ./make.sh shell Entering to a shell inside the build environment, go out with exit ipfire build chroot (x86_64) root:~$ ping github.com PING github.com (140.82.116.3) 56(84) bytes of data. 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=1 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=2 ttl=52 time=89.0 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=3 ttl=52 time=112 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=4 ttl=52 time=109 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=5 ttl=52 time=102 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=6 ttl=52 time=101 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=7 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=8 ttl=52 time=106 ms
Error:
netdata (1.47.0) [ 1:36 ][ FAIL ]
Could not resolve host: github.com
shutting down connection #0
--- LOG END --- error: downloading 'https://github.com/netdata/kernel-collector/releases/download/v1.4.5.1/netda...' failed status_code: 6 status_string: "Could not resolve hostname" log: --- LOG BEGIN --- Could not resolve host: github.com
shutting down connection #0
--- LOG END ---
ninja: build stopped: subcommand failed. FAILED ''
ABORTED Failed to build Netdata.
make: *** [netdata:86: /usr/src/log/netdata-v1.47.0] Error 1 make: Leaving directory '/usr/src/lfs'
ERROR: Building netdata
Hello sio,
The build system does not have any network access. We block this so that any compromised package cannot download anything more malicious that we don’t have a paper trail for. It is also that not all build systems have internet access all the time.
So you will have to download everything you need through the lfs/netdata file, extract, and then run the build.
In the “./make.sh shell” environment we make network access possible so that you can download files and patches and what not.
-Michael
On 29 Aug 2024, at 02:07, sio / siosios1@hotmail.com wrote:
I ran two separate builds on two different machines from scratch and they ran through the build process no problems that i could tell. I also added the netdata package to the mix on a second run on one of the machines and failed the build with the below error. mind you i have a 3rd machine with CU187 on it and it built the netdata package flawlessly, same files as I used on the CU188 machine so I am not sure if this is from the change or not. I have also gone into the shell with make.sh on the machine that had the error and could build netdata just fine with the same commands as in the lfs file.
netdata build from shell: --- We are done! ---
^ |.-. .-. .-. .-. .-. . netdata .-. .-. .-. .-. .-. .- | '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' +----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--->
--- is installed now! --- enjoy real-time performance and health monitoring...
ipfire build chroot (x86_64) root:~/netdata-v1.47.0$ Ping from shell: [root@cloud ipfire-2.x]# ./make.sh shell Entering to a shell inside the build environment, go out with exit ipfire build chroot (x86_64) root:~$ ping github.com PING github.com (140.82.116.3) 56(84) bytes of data. 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=1 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=2 ttl=52 time=89.0 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=3 ttl=52 time=112 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=4 ttl=52 time=109 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=5 ttl=52 time=102 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=6 ttl=52 time=101 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=7 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=8 ttl=52 time=106 ms
Error:
netdata (1.47.0) [ 1:36 ][ FAIL ]
Could not resolve host: github.com
shutting down connection #0
--- LOG END --- error: downloading 'https://github.com/netdata/kernel-collector/releases/download/v1.4.5.1/netda...' failed status_code: 6 status_string: "Could not resolve hostname" log: --- LOG BEGIN --- Could not resolve host: github.com
shutting down connection #0
--- LOG END ---
ninja: build stopped: subcommand failed. FAILED ''
ABORTED Failed to build Netdata.
make: *** [netdata:86: /usr/src/log/netdata-v1.47.0] Error 1 make: Leaving directory '/usr/src/lfs'
ERROR: Building netdata
Michael Tremer wrote:
Hello sio, The build system does not have any network access. We block this so that any compromised package cannot download anything more malicious that we don’t have a paper trail for. It is also that not all build systems have internet access all the time. So you will have to download everything you need through the lfs/netdata file, extract, and then run the build. In the “./make.sh shell” environment we make network access possible so that you can download files and patches and what not. -Michael
On 29 Aug 2024, at 02:07, sio / siosios1@hotmail.com wrote: I ran two separate builds on two different machines from scratch and they ran through the build process no problems that i could tell. I also added the netdata package to the mix on a second run on one of the machines and failed the build with the below error. mind you i have a 3rd machine with CU187 on it and it built the netdata package flawlessly, same files as I used on the CU188 machine so I am not sure if this is from the change or not. I have also gone into the shell with make.sh on the machine that had the error and could build netdata just fine with the same commands as in the lfs file. netdata build from shell: --- We are done! --- ^ |.-. .-. .-. .-. .-. . netdata .-. .-. .-. .-. .-. .- | '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' +----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---> --- is installed now! --- enjoy real-time performance and health monitoring... ipfire build chroot (x86_64) root:~/netdata-v1.47.0$ Ping from shell: [root@cloud ipfire-2.x]# ./make.sh shell Entering to a shell inside the build environment, go out with exit ipfire build chroot (x86_64) root:~$ ping github.com PING github.com (140.82.116.3) 56(84) bytes of data. 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=1 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=2 ttl=52 time=89.0 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=3 ttl=52 time=112 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=4 ttl=52 time=109 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=5 ttl=52 time=102 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=6 ttl=52 time=101 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=7 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=8 ttl=52 time=106 ms Error: netdata (1.47.0) [ 1:36 ][ FAIL ] Could not resolve host: github.com shutting down connection #0 --- LOG END --- error: downloading 'https://github.com/netdata/kernel-collector/releases/download/v1.4.5.1/netda...' failed status_code: 6 status_string: "Could not resolve hostname" log: --- LOG BEGIN --- Could not resolve host: github.com shutting down connection #0 --- LOG END --- ninja: build stopped: subcommand failed. FAILED '' ABORTED Failed to build Netdata. make: *** [netdata:86: /usr/src/log/netdata-v1.47.0] Error 1 make: Leaving directory '/usr/src/lfs' ERROR: Building netdata
hello Michael,
ok, that would make sense but was there a changed in 188 vs 187? just asking due to being able to build the same identical package on 187, if there wasn't a change then i need to do some more investigating. thank you for the info you can provide on this.
Hello,
On 29 Aug 2024, at 14:00, sio / siosios1@hotmail.com wrote:
Michael Tremer wrote:
Hello sio, The build system does not have any network access. We block this so that any compromised package cannot download anything more malicious that we don’t have a paper trail for. It is also that not all build systems have internet access all the time. So you will have to download everything you need through the lfs/netdata file, extract, and then run the build. In the “./make.sh shell” environment we make network access possible so that you can download files and patches and what not. -Michael
On 29 Aug 2024, at 02:07, sio / siosios1@hotmail.com wrote: I ran two separate builds on two different machines from scratch and they ran through the build process no problems that i could tell. I also added the netdata package to the mix on a second run on one of the machines and failed the build with the below error. mind you i have a 3rd machine with CU187 on it and it built the netdata package flawlessly, same files as I used on the CU188 machine so I am not sure if this is from the change or not. I have also gone into the shell with make.sh on the machine that had the error and could build netdata just fine with the same commands as in the lfs file. netdata build from shell: --- We are done! --- ^ |.-. .-. .-. .-. .-. . netdata .-. .-. .-. .-. .-. .- | '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' +----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---> --- is installed now! --- enjoy real-time performance and health monitoring... ipfire build chroot (x86_64) root:~/netdata-v1.47.0$ Ping from shell: [root@cloud ipfire-2.x]# ./make.sh shell Entering to a shell inside the build environment, go out with exit ipfire build chroot (x86_64) root:~$ ping github.com PING github.com (140.82.116.3) 56(84) bytes of data. 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=1 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=2 ttl=52 time=89.0 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=3 ttl=52 time=112 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=4 ttl=52 time=109 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=5 ttl=52 time=102 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=6 ttl=52 time=101 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=7 ttl=52 time=110 ms 64 bytes from lb-140-82-116-3-sea.github.com (140.82.116.3): icmp_seq=8 ttl=52 time=106 ms Error: netdata (1.47.0) [ 1:36 ][ FAIL ] Could not resolve host: github.com shutting down connection #0 --- LOG END --- error: downloading 'https://github.com/netdata/kernel-collector/releases/download/v1.4.5.1/netda...' failed status_code: 6 status_string: "Could not resolve hostname" log: --- LOG BEGIN --- Could not resolve host: github.com shutting down connection #0 --- LOG END --- ninja: build stopped: subcommand failed. FAILED '' ABORTED Failed to build Netdata. make: *** [netdata:86: /usr/src/log/netdata-v1.47.0] Error 1 make: Leaving directory '/usr/src/lfs' ERROR: Building netdata
hello Michael,
ok, that would make sense but was there a changed in 188 vs 187? just asking due to being able to build the same identical package on 187, if there wasn't a change then i need to do some more investigating. thank you for the info you can provide on this.
Yes, this has changed in the current development cycle. There is more information about that here:
https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/messag...
-Michael
Correct.
On 28 Aug 2024, at 20:28, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 28.08.2024 19:52, Adolf Belka wrote:
Hi All,
On 28/08/2024 18:30, Matthias Fischer wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
I don't know if the problem is because of the above commit but coreutils fails to build. It appears to be not finding aclocal-1.16
IMHO 'automake 1.16.5 => 1.17' must be the culprit...
It built fine yesterday so the problem must be one of the updates that was in the git pull I did today.
Just a quick test: went back to 'automake 1.16.5'. Build runs.
Best Matthias
Regards,
Adolf.
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
Hello,
On 28 Aug 2024, at 19:52, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
On 28/08/2024 18:30, Matthias Fischer wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
I don't know if the problem is because of the above commit but coreutils fails to build. It appears to be not finding aclocal-1.16
It built fine yesterday so the problem must be one of the updates that was in the git pull I did today.
This is correct, but not a problem of the build system, but the package:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=3e9871d20728c5b25ffb...
I dropped the patch that caused it to re-run autoconf. I don’t think we need this one.
-Michael
Regards,
Adolf.
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
Hello,
On 28 Aug 2024, at 18:30, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 28.08.2024 17:46, Michael Tremer wrote:
Hello everyone,
Hi,
Could you please confirm that this works:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5e8730eb9aec83a76b3a...
For me it does.
It works for me on Ubuntu 22.04 LTS with kernel 5.15.
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
This is kind of the wrong kernel, but at least it didn’t break anything either :)
I tested 'make.sh' with all important parameters (clean, downloadsrc, gettoolchain) - right now a 'next'-build is running and looking good - I'll report when its ready. ;-)
Best Matthias
There is also another fix to support kernels without time namespaces (< 5.6). However, I am not sure if the built itself runs through on this and does not require anything more recent:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=faccfa70754fabaed56c...
-Michael
On 27 Aug 2024, at 20:03, / / siosios1@hotmail.com wrote:
I can concur that moving the line to where Matthias put it does fix the issues on my machines with downloading and building, it also takes care of the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not exist from what I am seeing.
# If unshare is asked to terminate, terminate all child processes "--kill-child" )
mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc
fi
while [ $# -gt 0 ]; do
one thing I don't see is the mount when i check the output of mount or the output of findmnt -o+PROPAGATION
Hi,
On 29.08.2024 09:39, Michael Tremer wrote:
...
Here: Ubuntu 22.04 LTS / 6.8.0-40-generic
This is kind of the wrong kernel, but at least it didn’t break anything either :)
Just for the records:
Since yesterday the 'Devels' are on "Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-41-generic x86_64)".
Update went smooth - test build is running.
Best Matthias
-
/ / -
Adolf Belka -
Matthias Fischer -
Michael Tremer -
sio /