You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(3) |
Feb
(19) |
Mar
(9) |
Apr
(16) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(392) |
Nov
(810) |
Dec
(808) |
2002 |
Jan
(1087) |
Feb
(823) |
Mar
(771) |
Apr
(781) |
May
(725) |
Jun
(696) |
Jul
(949) |
Aug
(1085) |
Sep
(686) |
Oct
(662) |
Nov
(765) |
Dec
(440) |
2003 |
Jan
(863) |
Feb
(749) |
Mar
(420) |
Apr
(508) |
May
(691) |
Jun
(514) |
Jul
(444) |
Aug
(296) |
Sep
(276) |
Oct
(281) |
Nov
(209) |
Dec
(438) |
2004 |
Jan
(215) |
Feb
(240) |
Mar
(249) |
Apr
(258) |
May
(265) |
Jun
(152) |
Jul
(330) |
Aug
(153) |
Sep
(182) |
Oct
(250) |
Nov
(178) |
Dec
(246) |
2005 |
Jan
(126) |
Feb
(104) |
Mar
(138) |
Apr
(119) |
May
(93) |
Jun
(131) |
Jul
(188) |
Aug
(118) |
Sep
(113) |
Oct
(85) |
Nov
(123) |
Dec
(100) |
2006 |
Jan
(136) |
Feb
(136) |
Mar
(126) |
Apr
(85) |
May
(106) |
Jun
(107) |
Jul
(67) |
Aug
(157) |
Sep
(84) |
Oct
(121) |
Nov
(185) |
Dec
(150) |
2007 |
Jan
(113) |
Feb
(112) |
Mar
(102) |
Apr
(120) |
May
(40) |
Jun
(71) |
Jul
(92) |
Aug
(61) |
Sep
(26) |
Oct
(38) |
Nov
(38) |
Dec
(69) |
2008 |
Jan
(82) |
Feb
(37) |
Mar
(76) |
Apr
(58) |
May
(38) |
Jun
(35) |
Jul
(60) |
Aug
(17) |
Sep
(20) |
Oct
(19) |
Nov
(15) |
Dec
(27) |
2009 |
Jan
(19) |
Feb
(34) |
Mar
(18) |
Apr
(26) |
May
(25) |
Jun
(8) |
Jul
(11) |
Aug
(63) |
Sep
(3) |
Oct
(10) |
Nov
(5) |
Dec
|
2010 |
Jan
(5) |
Feb
(24) |
Mar
|
Apr
(6) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(26) |
Sep
(6) |
Oct
(18) |
Nov
(29) |
Dec
(20) |
2011 |
Jan
(48) |
Feb
(68) |
Mar
(43) |
Apr
(29) |
May
(35) |
Jun
(24) |
Jul
(26) |
Aug
(23) |
Sep
(31) |
Oct
(16) |
Nov
(8) |
Dec
(12) |
2012 |
Jan
(29) |
Feb
(29) |
Mar
(13) |
Apr
(23) |
May
(23) |
Jun
(10) |
Jul
(10) |
Aug
(10) |
Sep
(9) |
Oct
(33) |
Nov
(46) |
Dec
(10) |
2013 |
Jan
(27) |
Feb
(7) |
Mar
(19) |
Apr
(25) |
May
|
Jun
(9) |
Jul
(9) |
Aug
(23) |
Sep
(15) |
Oct
(35) |
Nov
(8) |
Dec
(7) |
2014 |
Jan
(5) |
Feb
(7) |
Mar
(18) |
Apr
(16) |
May
(4) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(32) |
Oct
(68) |
Nov
(19) |
Dec
(5) |
2015 |
Jan
(14) |
Feb
(20) |
Mar
(37) |
Apr
|
May
(1) |
Jun
(9) |
Jul
(5) |
Aug
(3) |
Sep
(12) |
Oct
(6) |
Nov
(17) |
Dec
(2) |
2016 |
Jan
(59) |
Feb
(38) |
Mar
(65) |
Apr
(5) |
May
(13) |
Jun
(13) |
Jul
(3) |
Aug
(8) |
Sep
(40) |
Oct
(9) |
Nov
(26) |
Dec
(38) |
2017 |
Jan
(47) |
Feb
(7) |
Mar
(3) |
Apr
(23) |
May
(31) |
Jun
(6) |
Jul
(1) |
Aug
(5) |
Sep
(8) |
Oct
(26) |
Nov
(31) |
Dec
(8) |
2018 |
Jan
(2) |
Feb
(8) |
Mar
(9) |
Apr
(10) |
May
(29) |
Jun
(7) |
Jul
(5) |
Aug
(17) |
Sep
(9) |
Oct
(10) |
Nov
|
Dec
(6) |
2019 |
Jan
(23) |
Feb
(20) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(44) |
Jul
(2) |
Aug
(3) |
Sep
(12) |
Oct
|
Nov
(12) |
Dec
(9) |
2020 |
Jan
(30) |
Feb
(18) |
Mar
|
Apr
|
May
(7) |
Jun
(6) |
Jul
(35) |
Aug
(55) |
Sep
(15) |
Oct
(25) |
Nov
(5) |
Dec
(58) |
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(62) |
Jun
(11) |
Jul
(11) |
Aug
(12) |
Sep
|
Oct
(5) |
Nov
(4) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
(4) |
Apr
(5) |
May
(17) |
Jun
(1) |
Jul
(8) |
Aug
(3) |
Sep
(2) |
Oct
(13) |
Nov
(20) |
Dec
(2) |
2023 |
Jan
(1) |
Feb
(3) |
Mar
(9) |
Apr
(7) |
May
(11) |
Jun
(5) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
|
Nov
(3) |
Dec
(4) |
2024 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
(6) |
May
|
Jun
(5) |
Jul
(9) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
From: KP.Kirchdoerfer <ka...@be...> - 2024-09-30 14:50:35
|
Am Sonntag, 29. September 2024, 16:35:00 CEST schrieb gp...@fr...: > Actually my build environnement was not clean (I had a libxt_ACCOUNT.so > coming from an earlier version in > staging/x86_64-unknown-linux-uclibc/lib/xtables/). > > For reason I don't understand build of >=3.25 does not generate > libxt_ACCOUNT.so, while <=3.24 generate this libxt_ACCOUNT.so. Only > diffference between ACCOUNT dir of both releases are makefiles. > > As a summary > xtables-addons-3.24 build just fine a produce the libxt_ACCOUNT.so > xtables-addons-3.25 (and 3.26) must be patched to have libxt_ACCOUNT.so > > Basically you need to use versions of 3.24 of the following files : > /extensions/ACCOUNT/Makefile.am > /extensions/ACCOUNT/Makefile.in > to have the libxt_ACCOUNT.so generated. > > Nota : same issue on libxt_pknock.so which requires former makefiles to > be built. > > Attached is the patch file sucessfully applied + buildtool files > adapted accordingly. > Unforunately there was no patch attached, maybe the mailing list doesn't allow attachments...? Anyway this explains why I still couldn't buil libxt_ACCOUNT.so (and the same for pknock). I found a solution to revert this upstream change: https://codeberg.org/jengelh/xtables-addons/commit/ 08a16d90ceaee66206b038b844873438d1fe3cf4#diff-9621ccb817d06b69d9733bbce52cc08b912237ea Committed the changes to git master branch yesterday. If your's is better pls send me off-list and I'll have a look at it. In either case gibt maint-7.3.1 will be get a commit as well. And a lot of thanks for your help! kp > Regards > > =========================================================== > > > Date: Thu, 26 Sep 2024 13:21:09 +0200 > From: <gp...@fr...> > To: lea...@li... > Subject: Re: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT > > > I built the 3.25 version, without any patch or anything unless adding > the 5 lines in buildtool.cfg > > Please note that then remove/clean macro is NOT working (i don't now > how to fix it) > > Nota : Toolchain=x86_64-unknown-linux-uclibc > > > Date: Tue, 24 Sep 2024 17:31:53 +0200 > From: "KP.Kirchdoerfer" <ka...@be...> > To: lea...@li... > Subject: Re: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT > > > Hi; > > Am Sonntag, 22. September 2024, 15:48:19 CEST schrieb gp...@fr...: > > Hello, > > > > I suceeded to fix the problem by adding the following lines in > > buildtool.cfg of xtables-addons (in contents section of ipacct) & > > rebuilding the package. > > > > <File> > > > > Filename = lib/xtables/libxt_ACCOUNT.so > > Source = lib/xtables/libxt_ACCOUNT.so > > Type = binary > > > > </File> > > Great you found a solution for yourself. > > Anyway, the module libxt_ACCOUNT.so doesn't even build in my > environment and therfor I removed libxt_ACCOUNT.so from the package in > the false assumption it won't be neded any longer. > This is obviously wrong. > > So the error here is somewhere else. > > May I ask you what version of xtables_addons you are compiling? > > kp > > > =========================================================== > > > > > > Date: Fri, 20 Sep 2024 16:12:21 +0200 > > From: <gp...@fr...> > > To: lea...@li... > > Subject: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT > > > > > > Hello, > > > > I have an issue on 7.3.1.1 (on APU2) : Shorewall fails to launch if > > accounting is used. > > > > Error message in shorewall-init.log > > Sep 20 15:22:59 Compiling /etc/shorewall/accounting... > > Sep 20 15:23:00 ERROR: ACCOUNT Rules require ACCOUNT Target in your > > kernel and iptables /etc/shorewall/accounting (line 11) > > > > but actually xt_ACCOUNT module is loaded : > > firewall# lsmod | grep xt_ACCOUNT > > xt_ACCOUNT 20480 0 - Live 0xffffffffc04d1000 (O) > > x_tables 32768 42 > > xt_statistic,xt_connlimit,xt_helper,xt_realm,xt_NFQUEUE,xt_hashlimit,xt_tc > > pm > > ss,xt_CHECKSUM,ipt_rpfilter,xt_DSCP,xt_dscp,xt_TPROXY,xt_CLASSIFY,xt_TCPM > > SS, > > xt_length,xt_connmark,xt_owner,xt_iprange,xt_physdev,xt_policy,xt_NETMAP, > > xt_ > > ACCOUNT,xt_nat,xt_REDIRECT,xt_MASQUERADE,xt_recent,xt_time,xt_comment,ipt > > _RE > > JECT,xt_addrtype,iptable_nat,xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptab > > le_ > > raw,xt_multiport,xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables, > > Live 0xffffffffc04c3000 > > > > and iptaccount is also available : > > > > firewall# iptaccount -a > > > > libxt_ACCOUNT_cl userspace accounting tool v1.3 > > > > Finished. > > > > > > Nota : strictly same config was working well on 7.2.3 (kernel 5). > > > > > > Thanks a lot for your help or idea to fix the point. > > > > > > ------------------------------------------------------------------------ > > leaf-user mailing list: lea...@li... > > https://lists.sourceforge.net/lists/listinfo/leaf-user > > Support Request -- http://leaf-project.org/ > > > > |
From: <gp...@fr...> - 2024-09-29 14:35:25
|
Actually my build environnement was not clean (I had a libxt_ACCOUNT.so coming from an earlier version in staging/x86_64-unknown-linux-uclibc/lib/xtables/). For reason I don't understand build of >=3.25 does not generate libxt_ACCOUNT.so, while <=3.24 generate this libxt_ACCOUNT.so. Only diffference between ACCOUNT dir of both releases are makefiles. As a summary xtables-addons-3.24 build just fine a produce the libxt_ACCOUNT.so xtables-addons-3.25 (and 3.26) must be patched to have libxt_ACCOUNT.so Basically you need to use versions of 3.24 of the following files : /extensions/ACCOUNT/Makefile.am /extensions/ACCOUNT/Makefile.in to have the libxt_ACCOUNT.so generated. Nota : same issue on libxt_pknock.so which requires former makefiles to be built. Attached is the patch file sucessfully applied + buildtool files adapted accordingly. Regards =========================================================== Date: Thu, 26 Sep 2024 13:21:09 +0200 From: <gp...@fr...> To: lea...@li... Subject: Re: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT I built the 3.25 version, without any patch or anything unless adding the 5 lines in buildtool.cfg Please note that then remove/clean macro is NOT working (i don't now how to fix it) Nota : Toolchain=x86_64-unknown-linux-uclibc Date: Tue, 24 Sep 2024 17:31:53 +0200 From: "KP.Kirchdoerfer" <ka...@be...> To: lea...@li... Subject: Re: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT Hi; Am Sonntag, 22. September 2024, 15:48:19 CEST schrieb gp...@fr...: > Hello, > > I suceeded to fix the problem by adding the following lines in > buildtool.cfg of xtables-addons (in contents section of ipacct) & > rebuilding the package. > > <File> > Filename = lib/xtables/libxt_ACCOUNT.so > Source = lib/xtables/libxt_ACCOUNT.so > Type = binary > </File> Great you found a solution for yourself. Anyway, the module libxt_ACCOUNT.so doesn't even build in my environment and therfor I removed libxt_ACCOUNT.so from the package in the false assumption it won't be neded any longer. This is obviously wrong. So the error here is somewhere else. May I ask you what version of xtables_addons you are compiling? kp > > =========================================================== > > > Date: Fri, 20 Sep 2024 16:12:21 +0200 > From: <gp...@fr...> > To: lea...@li... > Subject: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT > > > Hello, > > I have an issue on 7.3.1.1 (on APU2) : Shorewall fails to launch if > accounting is used. > > Error message in shorewall-init.log > Sep 20 15:22:59 Compiling /etc/shorewall/accounting... > Sep 20 15:23:00 ERROR: ACCOUNT Rules require ACCOUNT Target in your > kernel and iptables /etc/shorewall/accounting (line 11) > > but actually xt_ACCOUNT module is loaded : > firewall# lsmod | grep xt_ACCOUNT > xt_ACCOUNT 20480 0 - Live 0xffffffffc04d1000 (O) > x_tables 32768 42 > xt_statistic,xt_connlimit,xt_helper,xt_realm,xt_NFQUEUE,xt_hashlimit,xt_tcpm > ss,xt_CHECKSUM,ipt_rpfilter,xt_DSCP,xt_dscp,xt_TPROXY,xt_CLASSIFY,xt_TCPMSS, > xt_length,xt_connmark,xt_owner,xt_iprange,xt_physdev,xt_policy,xt_NETMAP,xt_ > ACCOUNT,xt_nat,xt_REDIRECT,xt_MASQUERADE,xt_recent,xt_time,xt_comment,ipt_RE > JECT,xt_addrtype,iptable_nat,xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_ > raw,xt_multiport,xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables, > Live 0xffffffffc04c3000 > > and iptaccount is also available : > > firewall# iptaccount -a > > libxt_ACCOUNT_cl userspace accounting tool v1.3 > > Finished. > > > Nota : strictly same config was working well on 7.2.3 (kernel 5). > > > Thanks a lot for your help or idea to fix the point. > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ ------------------------------------------------------------------------ leaf-user mailing list: lea...@li... https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/ ------------------------------------------------------------------------ leaf-user mailing list: lea...@li... https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/ |
From: <gp...@fr...> - 2024-09-26 11:21:31
|
I built the 3.25 version, without any patch or anything unless adding the 5 lines in buildtool.cfg Please note that then remove/clean macro is NOT working (i don't now how to fix it) Nota : Toolchain=x86_64-unknown-linux-uclibc Date: Tue, 24 Sep 2024 17:31:53 +0200 From: "KP.Kirchdoerfer" <ka...@be...> To: lea...@li... Subject: Re: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT Hi; Am Sonntag, 22. September 2024, 15:48:19 CEST schrieb gp...@fr...: > Hello, > > I suceeded to fix the problem by adding the following lines in > buildtool.cfg of xtables-addons (in contents section of ipacct) & > rebuilding the package. > > <File> > Filename = lib/xtables/libxt_ACCOUNT.so > Source = lib/xtables/libxt_ACCOUNT.so > Type = binary > </File> Great you found a solution for yourself. Anyway, the module libxt_ACCOUNT.so doesn't even build in my environment and therfor I removed libxt_ACCOUNT.so from the package in the false assumption it won't be neded any longer. This is obviously wrong. So the error here is somewhere else. May I ask you what version of xtables_addons you are compiling? kp > > =========================================================== > > > Date: Fri, 20 Sep 2024 16:12:21 +0200 > From: <gp...@fr...> > To: lea...@li... > Subject: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT > > > Hello, > > I have an issue on 7.3.1.1 (on APU2) : Shorewall fails to launch if > accounting is used. > > Error message in shorewall-init.log > Sep 20 15:22:59 Compiling /etc/shorewall/accounting... > Sep 20 15:23:00 ERROR: ACCOUNT Rules require ACCOUNT Target in your > kernel and iptables /etc/shorewall/accounting (line 11) > > but actually xt_ACCOUNT module is loaded : > firewall# lsmod | grep xt_ACCOUNT > xt_ACCOUNT 20480 0 - Live 0xffffffffc04d1000 (O) > x_tables 32768 42 > xt_statistic,xt_connlimit,xt_helper,xt_realm,xt_NFQUEUE,xt_hashlimit,xt_tcpm > ss,xt_CHECKSUM,ipt_rpfilter,xt_DSCP,xt_dscp,xt_TPROXY,xt_CLASSIFY,xt_TCPMSS, > xt_length,xt_connmark,xt_owner,xt_iprange,xt_physdev,xt_policy,xt_NETMAP,xt_ > ACCOUNT,xt_nat,xt_REDIRECT,xt_MASQUERADE,xt_recent,xt_time,xt_comment,ipt_RE > JECT,xt_addrtype,iptable_nat,xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_ > raw,xt_multiport,xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables, > Live 0xffffffffc04c3000 > > and iptaccount is also available : > > firewall# iptaccount -a > > libxt_ACCOUNT_cl userspace accounting tool v1.3 > > Finished. > > > Nota : strictly same config was working well on 7.2.3 (kernel 5). > > > Thanks a lot for your help or idea to fix the point. > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ ------------------------------------------------------------------------ leaf-user mailing list: lea...@li... https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/ |
From: KP.Kirchdoerfer <ka...@be...> - 2024-09-24 15:49:27
|
Hi; Am Sonntag, 22. September 2024, 15:48:19 CEST schrieb gp...@fr...: > Hello, > > I suceeded to fix the problem by adding the following lines in > buildtool.cfg of xtables-addons (in contents section of ipacct) & > rebuilding the package. > > <File> > Filename = lib/xtables/libxt_ACCOUNT.so > Source = lib/xtables/libxt_ACCOUNT.so > Type = binary > </File> Great you found a solution for yourself. Anyway, the module libxt_ACCOUNT.so doesn't even build in my environment and therfor I removed libxt_ACCOUNT.so from the package in the false assumption it won't be neded any longer. This is obviously wrong. So the error here is somewhere else. May I ask you what version of xtables_addons you are compiling? kp > > =========================================================== > > > Date: Fri, 20 Sep 2024 16:12:21 +0200 > From: <gp...@fr...> > To: lea...@li... > Subject: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT > > > Hello, > > I have an issue on 7.3.1.1 (on APU2) : Shorewall fails to launch if > accounting is used. > > Error message in shorewall-init.log > Sep 20 15:22:59 Compiling /etc/shorewall/accounting... > Sep 20 15:23:00 ERROR: ACCOUNT Rules require ACCOUNT Target in your > kernel and iptables /etc/shorewall/accounting (line 11) > > but actually xt_ACCOUNT module is loaded : > firewall# lsmod | grep xt_ACCOUNT > xt_ACCOUNT 20480 0 - Live 0xffffffffc04d1000 (O) > x_tables 32768 42 > xt_statistic,xt_connlimit,xt_helper,xt_realm,xt_NFQUEUE,xt_hashlimit,xt_tcpm > ss,xt_CHECKSUM,ipt_rpfilter,xt_DSCP,xt_dscp,xt_TPROXY,xt_CLASSIFY,xt_TCPMSS, > xt_length,xt_connmark,xt_owner,xt_iprange,xt_physdev,xt_policy,xt_NETMAP,xt_ > ACCOUNT,xt_nat,xt_REDIRECT,xt_MASQUERADE,xt_recent,xt_time,xt_comment,ipt_RE > JECT,xt_addrtype,iptable_nat,xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_ > raw,xt_multiport,xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables, Live > 0xffffffffc04c3000 > > and iptaccount is also available : > > firewall# iptaccount -a > > libxt_ACCOUNT_cl userspace accounting tool v1.3 > > Finished. > > > Nota : strictly same config was working well on 7.2.3 (kernel 5). > > > Thanks a lot for your help or idea to fix the point. > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ |
From: <gp...@fr...> - 2024-09-22 13:48:46
|
Hello, I suceeded to fix the problem by adding the following lines in buildtool.cfg of xtables-addons (in contents section of ipacct) & rebuilding the package. <File> Filename = lib/xtables/libxt_ACCOUNT.so Source = lib/xtables/libxt_ACCOUNT.so Type = binary </File> =========================================================== Date: Fri, 20 Sep 2024 16:12:21 +0200 From: <gp...@fr...> To: lea...@li... Subject: [leaf-user] Issue on 7.3.1.1 on APU2 shorewall and ACCOUNT Hello, I have an issue on 7.3.1.1 (on APU2) : Shorewall fails to launch if accounting is used. Error message in shorewall-init.log Sep 20 15:22:59 Compiling /etc/shorewall/accounting... Sep 20 15:23:00 ERROR: ACCOUNT Rules require ACCOUNT Target in your kernel and iptables /etc/shorewall/accounting (line 11) but actually xt_ACCOUNT module is loaded : firewall# lsmod | grep xt_ACCOUNT xt_ACCOUNT 20480 0 - Live 0xffffffffc04d1000 (O) x_tables 32768 42 xt_statistic,xt_connlimit,xt_helper,xt_realm,xt_NFQUEUE,xt_hashlimit,xt_tcpmss,xt_CHECKSUM,ipt_rpfilter,xt_DSCP,xt_dscp,xt_TPROXY,xt_CLASSIFY,xt_TCPMSS,xt_length,xt_connmark,xt_owner,xt_iprange,xt_physdev,xt_policy,xt_NETMAP,xt_ACCOUNT,xt_nat,xt_REDIRECT,xt_MASQUERADE,xt_recent,xt_time,xt_comment,ipt_REJECT,xt_addrtype,iptable_nat,xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_raw,xt_multiport,xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables, Live 0xffffffffc04c3000 and iptaccount is also available : firewall# iptaccount -a libxt_ACCOUNT_cl userspace accounting tool v1.3 Finished. Nota : strictly same config was working well on 7.2.3 (kernel 5). Thanks a lot for your help or idea to fix the point. ------------------------------------------------------------------------ leaf-user mailing list: lea...@li... https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/ |
From: <gp...@fr...> - 2024-09-20 14:12:46
|
Hello, I have an issue on 7.3.1.1 (on APU2) : Shorewall fails to launch if accounting is used. Error message in shorewall-init.log Sep 20 15:22:59 Compiling /etc/shorewall/accounting... Sep 20 15:23:00 ERROR: ACCOUNT Rules require ACCOUNT Target in your kernel and iptables /etc/shorewall/accounting (line 11) but actually xt_ACCOUNT module is loaded : firewall# lsmod | grep xt_ACCOUNT xt_ACCOUNT 20480 0 - Live 0xffffffffc04d1000 (O) x_tables 32768 42 xt_statistic,xt_connlimit,xt_helper,xt_realm,xt_NFQUEUE,xt_hashlimit,xt_tcpmss,xt_CHECKSUM,ipt_rpfilter,xt_DSCP,xt_dscp,xt_TPROXY,xt_CLASSIFY,xt_TCPMSS,xt_length,xt_connmark,xt_owner,xt_iprange,xt_physdev,xt_policy,xt_NETMAP,xt_ACCOUNT,xt_nat,xt_REDIRECT,xt_MASQUERADE,xt_recent,xt_time,xt_comment,ipt_REJECT,xt_addrtype,iptable_nat,xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_raw,xt_multiport,xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables, Live 0xffffffffc04c3000 and iptaccount is also available : firewall# iptaccount -a libxt_ACCOUNT_cl userspace accounting tool v1.3 Finished. Nota : strictly same config was working well on 7.2.3 (kernel 5). Thanks a lot for your help or idea to fix the point. |
From: Otto H. - T. <ott...@te...> - 2024-09-12 18:31:32
|
Dears, I downloaded Bering-uClibc_7.3.1.1_wrap_syslinux_serial57600 and tried to run it on wrap board. It started to boot but after a while the boot process was interrupted. Then I tried to use 7.2.3 with the same result: SYSLINUX 3.86 2010-04-01 Copyright (C) 1994-2010 H. Peter Anvin et al [ 0.000000] CPU: vendor_id 'Geode by NSC' unknown, using generic init. [ 0.000000] CPU: Your system may be unstable. LINUXRC: Bering - Initrd - 7.2.3 Rev 1 uClibc 1.0.42 LINUXRC: Parsing kernel command line... I left the wrap on and suddenly after 25 minutes it continued booting until fully booted. So the whole time to boot takes circa 30 minutes. Any idea what could be wrong? Or the newer version are so demanding that they need newer hardware? Mean time I tried many versions and it looks like the 7.0.3 is the last where the boot process takes minute or two. Otto |
From: KP.Kirchdoerfer <ka...@be...> - 2024-07-27 12:35:30
|
Hi David thx for providing a solution. I'm running it without problems, have tested within a qemu virtual machine successfully and built a 3.1.1.1-rc1 for testing with this change only. I'm waiting for feedback before building a final version. kp Am Donnerstag, 11. Juli 2024, 15:29:00 CEST schrieb David Brooke: > Thanks for confirming Otto - seems this happens more widely than we thought. > > This morning I had it fail about 4 times in a row and only boot on the 5th > try. > > I'm confident I know what's going wrong: the modules squashfs gets unmounted > 'too early' because the attempt to unmount it succeeds - but the script > assumes the unmount will fail if module processing is ongoing. > > I've just pushed a change to Git with a tweak to where the loop 'sleeps' and > made it reference usb_wait (so the 'sleep' can be configured at runtime). > That's working reliably for me on my APU2 and should be 'safe' for > everyone. > > @kp: I just pushed the change direct to the 'master' branch; hope that's OK. > Not sure if this warrants a 7.3.1.1, or an early 7.3.2...? > > dMb > > > On 11/07/2024 11:54 BST Otto Halák - TeleLarm <ott...@te...> > > wrote: > > > > > > Hi list, > > the same thing happen to me. I am using version 7.3.1 released > > 2024-06-29 on ALIX.6F2 / LX800 256MB. After reboot both the eth > > interfaces are missing. It only happen sometimes, not every second > > reboot like in case of APU2 boards. > > Here is part of the boot proces shown on the terminal: > > > > ... > > LOADPKG: configdb.lrp installed > > LOADPKG: Unmounting /mnt1 > > LOADPKG: Removing /mnt1 > > LOADPKG: Loaded Packages > > LOADMODULES: identified device /dev/sda1 > > LOADMODULES: Mounting squashfs with modules... > > LOADMODULES: found modules.sqfs on /mnt1 > > [ 33.768860] /dev/loop0: Can't open blockdev > > LOADMODULES: loading modules from /etc/modules > > LOADMODULES: Unmounting /mnt1 > > LOADMODULES: Removing /mnt1 > > > > Type in help if you are really lost > > Setting kernel variables ... > > net.ipv4.conf.default.rp_filter = 1 > > net.ipv4.conf.all.rp_filter = 0 > > kernel.printk = 3 4 1 7 > > kernel.panic = 5 > > kernel.core_pattern = /tmp/core.%e.%p.%s > > net.core.rmem_max = 6291456 > > net.core.wmem_max = 6291456 > > net.core.optmem_max = 524288 > > net.core.netdev_max_backlog = 10000 > > net.core.netdev_tstamp_prequeue = 0 > > done. > > Mounting local file systems... > > Initializing random number generator... done. > > Starting rsyslog daemon: OK > > Configuring network interfaces: Cannot find device "eth0" > > Cannot find device "eth1" > > Cannot find device "eth1" > > done. > > Starting software watchdog... done. > > Starting IPv4 shorewall rules... > > Compiling using Shorewall 5.2.8... > > Shorewall configuration compiled to /var/lib/shorewall/.start > > Starting Shorewall.... > > done. > > Starting internet superserver: inetd. > > ... > > > > BR, Otto > > > > Dne 08.07.2024 v 18:53 David Brooke napsal(a): > > >> On 08/07/2024 14:34 BST David Brooke <le...@da...> wrote: > > >>> On 06/07/2024 12:30 BST KP.Kirchdoerfer <ka...@be...> > > >>> wrote: > > >>> > > >>> Am Mittwoch, 3. Juli 2024, 18:30:29 CEST schrieb David Brooke: > > >>>> Hi, > > >>>> > > >>>>> On 04/06/2024 14:20 BST KP.Kirchdoerfer <ka...@be...> > > >>>>> wrote: > > >>>>> > > >>>>> > > >>>>> Hi; > > >>>>> > > >>>>> Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: > > >>>>>> Hello, > > >>>>>> > > >>>>>> tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using > > >>>>>> the > > >>>>>> Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. > > >>>>>> > > >>>>>> This failed since the network interfaces were no longer recognized. > > >>>>>> Reverting back to rc1 made the network interfaces appear again. > > >>>>>> Have not > > >>>>>> yet understood on what goes wrong, but maybe someone else is also > > >>>>>> having > > >>>>>> this issue. > > >>>>> > > >>>>> It does work here with APU2 and igb network driver (automatically > > >>>>> detected). > > >>>>> > > >>>>> If you're issue persists I'll look again next week. > > >>>>> > > >>>>> kp > > >>>> > > >>>> I am seeing the same issue today with 7.3.1_x86_64 on an APU2. > > >>>> > > >>>> Seems to be intermittent / inconsistent though: > > >>>> * Reboot and it says can't find eth0/1/2 > > >>>> * Reboot again and it *can* find those but *not* e.g. ppp0 > > >>>> * Reboot again and it's back to not finding eth0/1/2 > > >>>> > > >>>> I wonder if it's right on the limit of a timeout for module > > >>>> loading??? > > >>>> (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for > > >>>> this?) > > >>> > > >>> Odd; I'm running it successfully on an APU4 and also tested the image > > >>> with > > >>> qemu. > > >> > > >> Odd indeed! :-) When it works, everything is fine - and I've been > > >> running > > >> 7.3.1 successfully for a few days now (without rebooting). But then I > > >> do a > > >> reboot and it fails to find the network interfaces. When I reboot a > > >> second > > >> time - *with the **exact** same configuration* - it works fine again. > > >> > > >> (Changing usb_wait didn't help; I've had that set to 4 when it failed, > > >> and > > >> 2 when it works.) > > >> > > >>> What does dmesg show when you are booting? (see below how it looks > > >>> here) > > >> > > >> I've now got the dmesg output captured for a 'good' and a 'bad' boot. > > >> These are identical until after the 'u32 classifier' lines - which I > > >> believe are the result of loading cls_u32, specified near the end of > > >> /etc/modules. Is that a clue? Looking at repo/init.d/root.loadmodules > > >> there's an attempt to unmount the squashfs as soon as /etc/modules > > >> has been processed. > > >> > > >> dmesg output from a 'good' boot: > > >> > > >> ... > > >> [ 17.801213] 8021q: 802.1Q VLAN Support v1.8 > > >> [ 17.866368] u32 classifier > > >> [ 17.866384] Performance counters on > > >> [ 17.866387] input device check on > > >> [ 17.866390] Actions configured > > >> [ 17.941866] igb: loading out-of-tree module taints kernel. > > >> [ 17.956580] igb: Intel(R) Gigabit Ethernet Linux Driver - version > > >> 5.15.6 > > >> [ 17.956588] igb: Copyright(c) 2007 - 2023 Intel Corporation. > > >> ... (Many more igb lines, omitted) > > >> [ 18.100447] igb 0000:03:00.0: Using MSI-X interrupts. 1 rx queue(s), > > >> 1 tx queue(s) [ 19.117966] sp5100_tco: SP5100/SB800 TCO WatchDog > > >> Timer Driver > > >> [ 19.118339] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog > > >> MMIO address [ 19.118510] sp5100-tco sp5100-tco: initialized. > > >> heartbeat=60 sec (nowayout=0) [ 19.139035] piix4_smbus 0000:00:14.0: > > >> SMBus Host Controller at 0xb00, revision 0 [ 19.139055] piix4_smbus > > >> 0000:00:14.0: Using register 0x02 for SMBus port selection [ > > >> 19.139329] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller > > >> at 0xb20 [ 19.263714] EDAC amd64: MCT channel count: 1 > > >> [ 19.264013] EDAC MC0: Giving out device to module amd64_edac > > >> controller F16h_M30h: DEV 0000:00:18.3 (INTERRUPT) [ 19.264054] EDAC > > >> amd64: F16h_M30h detected (node 0). > > >> [ 19.264059] EDAC MC: DCT0 chip selects: > > >> [ 19.264063] EDAC amd64: MC: 0: 4096MB 1: 0MB > > >> [ 19.264070] EDAC amd64: MC: 2: 0MB 3: 0MB > > >> [ 19.264076] EDAC amd64: MC: 4: 0MB 5: 0MB > > >> [ 19.264081] EDAC amd64: MC: 6: 0MB 7: 0MB > > >> [ 19.264086] EDAC MC: DCT1 chip selects: > > >> [ 19.264089] EDAC amd64: MC: 0: 0MB 1: 0MB > > >> [ 19.264094] EDAC amd64: MC: 2: 0MB 3: 0MB > > >> [ 19.264098] EDAC amd64: MC: 4: 0MB 5: 0MB > > >> [ 19.264103] EDAC amd64: MC: 6: 0MB 7: 0MB > > >> [ 19.264107] EDAC amd64: using x4 syndromes. > > >> [ 19.264144] EDAC PCI0: Giving out device to module amd64_edac > > >> controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) [ > > >> 19.264183] AMD64 EDAC driver v3.5.0 > > >> [ 19.630869] acpi_cpufreq: overriding BIOS provided _PSD data > > >> [ 23.910792] EXT4-fs (sda3): unmounting filesystem. > > >> [ 23.919071] Adding 104444k swap on /dev/zram0. Priority:100 > > >> extents:1 across:104444k SS > > >> > > >> > > >> dmesg output from a 'bad' boot: > > >> > > >> ... > > >> [ 17.803206] 8021q: 802.1Q VLAN Support v1.8 > > >> [ 17.868978] u32 classifier > > >> [ 17.869023] Performance counters on > > >> [ 17.869026] input device check on > > >> [ 17.869028] Actions configured > > >> [ 17.899170] EXT4-fs (sda3): unmounting filesystem. > > >> [ 17.908144] Adding 104444k swap on /dev/zram0. Priority:100 > > >> extents:1 across:104444k SS > > >> > > >> So it's not only the igb modules that are missing; some others fail to > > >> load too. It's as if the module auto-loading just stops too soon. > > >> > > >> The text on the serial console is the same in both cases: > > >> > > >> LOADMODULES: identified device /dev/sda3 > > >> LOADMODULES: Mounting squashes with modules... > > >> LOADMODULES: found modules.sqfs on /mnt1 > > >> [ 16.399684] /dev/loop0: Can't open blockdev > > >> LOADMODULES: loading modules from /etc/modules > > >> LOADMODULES: Unmounting /mnt1 > > >> LOADMODULES: Removing /mnt1 > > >> > > >> (I always get that /dev/loop0 'blockdev' message, which seems to just > > >> be a > > >> warning.) > > >> > > >>> Maybe it's worth testing the kernel module for igb, we are suing the > > >>> out-of- tree from Intel and/or a kernel version without UEFI support > > >>> (which has been added in 7.3.1-rc2. > > >> > > >> I don't think that will help, since the issue isn't specific to the igb > > >> module. > > >> > > >> Having reviewed the root.loadmodules script, my hunch is that the > > >> unmount > > >> of the squashfs is happening before the auto-loading has finished. > > >> Maybe the loop with a 'sleep 3' gets (un)lucky sometimes? I note > > >> there's a VERBOSE2 variable which will create more output; I'll give > > >> that a try when I get chance.> > > > > The extra debug output to the serial console with VERBOSE2 set would > > > appear to confirm my hunch. > > > > > > When the module auto-loading stops too early: > > > > > > LOADMODULES: Waiting for module loading... > > > LOADMODULES: PKGPATH: /dev/sda3:ext4 > > > LOADMODULES: identified device /dev/sda3 > > > LOADMODULES: Mounting /dev/sda3 on /mnt1 > > > LOADMODULES: Mounted /dev/sda3 on /mnt1 > > > LOADMODULES: The following mountpoints were created: /mnt1 > > > LOADMODULES: Mounting squashfs with modules... > > > LOADMODULES: found modules.sqfs on /mnt1 > > > [ 16.342129] /dev/loop0: Can't open blockdev > > > LOADMODULES: loading modules from /etc/modules > > > LOADMODULES: /sbin/modprobe pppoe > > > LOADMODULES: /sbin/modprobe softdog > > > LOADMODULES: /sbin/modprobe ipv6 > > > LOADMODULES: /sbin/modprobe 8021q > > > LOADMODULES: /sbin/modprobe ifb > > > LOADMODULES: /sbin/modprobe act_police > > > LOADMODULES: /sbin/modprobe cls_fw > > > LOADMODULES: /sbin/modprobe cls_flow > > > LOADMODULES: /sbin/modprobe sch_tbf > > > LOADMODULES: /sbin/modprobe sch_prio > > > LOADMODULES: /sbin/modprobe sch_ingress > > > LOADMODULES: /sbin/modprobe cls_u32 > > > LOADMODULES: /sbin/modprobe sch_htb > > > LOADMODULES: /sbin/modprobe sch_sfq > > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 > > > LOADMODULES: Unmounting /mnt1 > > > LOADMODULES: Removing /mnt1 > > > > > > When the module auto-loading happens normally: > > > > > > LOADMODULES: Waiting for module loading... > > > LOADMODULES: PKGPATH: /dev/sda3:ext4 > > > LOADMODULES: identified device /dev/sda3 > > > LOADMODULES: Mounting /dev/sda3 on /mnt1 > > > LOADMODULES: Mounted /dev/sda3 on /mnt1 > > > LOADMODULES: The following mountpoints were created: /mnt1 > > > LOADMODULES: Mounting squashfs with modules... > > > LOADMODULES: found modules.sqfs on /mnt1 > > > [ 16.361295] /dev/loop0: Can't open blockdev > > > LOADMODULES: loading modules from /etc/modules > > > LOADMODULES: /sbin/modprobe pppoe > > > LOADMODULES: /sbin/modprobe softdog > > > LOADMODULES: /sbin/modprobe ipv6 > > > LOADMODULES: /sbin/modprobe 8021q > > > LOADMODULES: /sbin/modprobe ifb > > > LOADMODULES: /sbin/modprobe act_police > > > LOADMODULES: /sbin/modprobe cls_fw > > > LOADMODULES: /sbin/modprobe cls_flow > > > LOADMODULES: /sbin/modprobe sch_tbf > > > LOADMODULES: /sbin/modprobe sch_prio > > > LOADMODULES: /sbin/modprobe sch_ingress > > > LOADMODULES: /sbin/modprobe cls_u32 > > > LOADMODULES: /sbin/modprobe sch_htb > > > LOADMODULES: /sbin/modprobe sch_sfq > > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 > > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- > > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- > > > LOADMODULES: Unmounting /mnt1 > > > LOADMODULES: Removing /mnt1 > > > > > > The difference (marked <--) is that, when all the modules are loaded, it > > > takes 3 attempts (with a sleep of 3 seconds between) to satisfy the > > > criteria for 'looping to unmount' whereas when only some of the modules > > > are loaded, the unmount of /lib/modules/6.1.64-x86_64 succeeds at the > > > first attempt. > > > > > > This is the relevant section of repo/initrd/root.loadmodules (installed > > > > > > as /var/lib/lrpkg/root.loadmodules): > > > # umount the squashfs > > > loop_counter=0 > > > while [ $loop_counter -lt 15 ] > > > do > > > > > > [ "$VERBOSE2" ] && Lecho "looping to unmount > > > /lib/modules/$KVER" > > > umount /lib/modules/$KVER > /dev/null 2>&1 > > > [ -z "$(grep /lib/modules/$KVER /proc/mounts)" ] && break > > > sleep 3 > > > > > > done > > > > > > For some reason, the 'umount' is succeeding before module auto-loading > > > has > > > completed - but only sometimes, and only for some installations (and > > > only > > > on APU boards, it seems). > > > > > > dMb > > > > > >> dMb > > >> > > >>> kp > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ |
From: David B. <le...@da...> - 2024-07-11 13:29:09
|
Thanks for confirming Otto - seems this happens more widely than we thought. This morning I had it fail about 4 times in a row and only boot on the 5th try. I'm confident I know what's going wrong: the modules squashfs gets unmounted 'too early' because the attempt to unmount it succeeds - but the script assumes the unmount will fail if module processing is ongoing. I've just pushed a change to Git with a tweak to where the loop 'sleeps' and made it reference usb_wait (so the 'sleep' can be configured at runtime). That's working reliably for me on my APU2 and should be 'safe' for everyone. @kp: I just pushed the change direct to the 'master' branch; hope that's OK. Not sure if this warrants a 7.3.1.1, or an early 7.3.2...? dMb > On 11/07/2024 11:54 BST Otto Halák - TeleLarm <ott...@te...> wrote: > > > Hi list, > the same thing happen to me. I am using version 7.3.1 released > 2024-06-29 on ALIX.6F2 / LX800 256MB. After reboot both the eth > interfaces are missing. It only happen sometimes, not every second > reboot like in case of APU2 boards. > Here is part of the boot proces shown on the terminal: > > ... > LOADPKG: configdb.lrp installed > LOADPKG: Unmounting /mnt1 > LOADPKG: Removing /mnt1 > LOADPKG: Loaded Packages > LOADMODULES: identified device /dev/sda1 > LOADMODULES: Mounting squashfs with modules... > LOADMODULES: found modules.sqfs on /mnt1 > [ 33.768860] /dev/loop0: Can't open blockdev > LOADMODULES: loading modules from /etc/modules > LOADMODULES: Unmounting /mnt1 > LOADMODULES: Removing /mnt1 > > Type in help if you are really lost > Setting kernel variables ... > net.ipv4.conf.default.rp_filter = 1 > net.ipv4.conf.all.rp_filter = 0 > kernel.printk = 3 4 1 7 > kernel.panic = 5 > kernel.core_pattern = /tmp/core.%e.%p.%s > net.core.rmem_max = 6291456 > net.core.wmem_max = 6291456 > net.core.optmem_max = 524288 > net.core.netdev_max_backlog = 10000 > net.core.netdev_tstamp_prequeue = 0 > done. > Mounting local file systems... > Initializing random number generator... done. > Starting rsyslog daemon: OK > Configuring network interfaces: Cannot find device "eth0" > Cannot find device "eth1" > Cannot find device "eth1" > done. > Starting software watchdog... done. > Starting IPv4 shorewall rules... > Compiling using Shorewall 5.2.8... > Shorewall configuration compiled to /var/lib/shorewall/.start > Starting Shorewall.... > done. > Starting internet superserver: inetd. > ... > > BR, Otto > > > Dne 08.07.2024 v 18:53 David Brooke napsal(a): > >> On 08/07/2024 14:34 BST David Brooke <le...@da...> wrote: > >> > >> > >>> On 06/07/2024 12:30 BST KP.Kirchdoerfer <ka...@be...> wrote: > >>> > >>> > >>> Am Mittwoch, 3. Juli 2024, 18:30:29 CEST schrieb David Brooke: > >>>> Hi, > >>>> > >>>>> On 04/06/2024 14:20 BST KP.Kirchdoerfer <ka...@be...> wrote: > >>>>> > >>>>> > >>>>> Hi; > >>>>> > >>>>> Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: > >>>>>> Hello, > >>>>>> > >>>>>> tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the > >>>>>> Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. > >>>>>> > >>>>>> This failed since the network interfaces were no longer recognized. > >>>>>> Reverting back to rc1 made the network interfaces appear again. Have not > >>>>>> yet understood on what goes wrong, but maybe someone else is also having > >>>>>> this issue. > >>>>> > >>>>> It does work here with APU2 and igb network driver (automatically > >>>>> detected). > >>>>> > >>>>> If you're issue persists I'll look again next week. > >>>>> > >>>>> kp > >>>> > >>>> I am seeing the same issue today with 7.3.1_x86_64 on an APU2. > >>>> > >>>> Seems to be intermittent / inconsistent though: > >>>> * Reboot and it says can't find eth0/1/2 > >>>> * Reboot again and it *can* find those but *not* e.g. ppp0 > >>>> * Reboot again and it's back to not finding eth0/1/2 > >>>> > >>>> I wonder if it's right on the limit of a timeout for module loading??? > >>>> (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for this?) > >>>> > >>> > >>> Odd; I'm running it successfully on an APU4 and also tested the image with > >>> qemu. > >> > >> Odd indeed! :-) When it works, everything is fine - and I've been running > >> 7.3.1 successfully for a few days now (without rebooting). But then I do a > >> reboot and it fails to find the network interfaces. When I reboot a second > >> time - *with the **exact** same configuration* - it works fine again. > >> > >> (Changing usb_wait didn't help; I've had that set to 4 when it failed, and > >> 2 when it works.) > >> > >>> What does dmesg show when you are booting? (see below how it looks here) > >> > >> I've now got the dmesg output captured for a 'good' and a 'bad' boot. > >> These are identical until after the 'u32 classifier' lines - which I > >> believe are the result of loading cls_u32, specified near the end of > >> /etc/modules. Is that a clue? Looking at repo/init.d/root.loadmodules > >> there's an attempt to unmount the squashfs as soon as /etc/modules > >> has been processed. > >> > >> dmesg output from a 'good' boot: > >> > >> ... > >> [ 17.801213] 8021q: 802.1Q VLAN Support v1.8 > >> [ 17.866368] u32 classifier > >> [ 17.866384] Performance counters on > >> [ 17.866387] input device check on > >> [ 17.866390] Actions configured > >> [ 17.941866] igb: loading out-of-tree module taints kernel. > >> [ 17.956580] igb: Intel(R) Gigabit Ethernet Linux Driver - version 5.15.6 > >> [ 17.956588] igb: Copyright(c) 2007 - 2023 Intel Corporation. > >> ... (Many more igb lines, omitted) > >> [ 18.100447] igb 0000:03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) > >> [ 19.117966] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver > >> [ 19.118339] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address > >> [ 19.118510] sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0) > >> [ 19.139035] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 > >> [ 19.139055] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus port selection > >> [ 19.139329] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20 > >> [ 19.263714] EDAC amd64: MCT channel count: 1 > >> [ 19.264013] EDAC MC0: Giving out device to module amd64_edac controller F16h_M30h: DEV 0000:00:18.3 (INTERRUPT) > >> [ 19.264054] EDAC amd64: F16h_M30h detected (node 0). > >> [ 19.264059] EDAC MC: DCT0 chip selects: > >> [ 19.264063] EDAC amd64: MC: 0: 4096MB 1: 0MB > >> [ 19.264070] EDAC amd64: MC: 2: 0MB 3: 0MB > >> [ 19.264076] EDAC amd64: MC: 4: 0MB 5: 0MB > >> [ 19.264081] EDAC amd64: MC: 6: 0MB 7: 0MB > >> [ 19.264086] EDAC MC: DCT1 chip selects: > >> [ 19.264089] EDAC amd64: MC: 0: 0MB 1: 0MB > >> [ 19.264094] EDAC amd64: MC: 2: 0MB 3: 0MB > >> [ 19.264098] EDAC amd64: MC: 4: 0MB 5: 0MB > >> [ 19.264103] EDAC amd64: MC: 6: 0MB 7: 0MB > >> [ 19.264107] EDAC amd64: using x4 syndromes. > >> [ 19.264144] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) > >> [ 19.264183] AMD64 EDAC driver v3.5.0 > >> [ 19.630869] acpi_cpufreq: overriding BIOS provided _PSD data > >> [ 23.910792] EXT4-fs (sda3): unmounting filesystem. > >> [ 23.919071] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS > >> > >> > >> dmesg output from a 'bad' boot: > >> > >> ... > >> [ 17.803206] 8021q: 802.1Q VLAN Support v1.8 > >> [ 17.868978] u32 classifier > >> [ 17.869023] Performance counters on > >> [ 17.869026] input device check on > >> [ 17.869028] Actions configured > >> [ 17.899170] EXT4-fs (sda3): unmounting filesystem. > >> [ 17.908144] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS > >> > >> So it's not only the igb modules that are missing; some others fail to load too. > >> It's as if the module auto-loading just stops too soon. > >> > >> The text on the serial console is the same in both cases: > >> > >> LOADMODULES: identified device /dev/sda3 > >> LOADMODULES: Mounting squashes with modules... > >> LOADMODULES: found modules.sqfs on /mnt1 > >> [ 16.399684] /dev/loop0: Can't open blockdev > >> LOADMODULES: loading modules from /etc/modules > >> LOADMODULES: Unmounting /mnt1 > >> LOADMODULES: Removing /mnt1 > >> > >> (I always get that /dev/loop0 'blockdev' message, which seems to just be a > >> warning.) > >> > >>> Maybe it's worth testing the kernel module for igb, we are suing the out-of- > >>> tree from Intel and/or a kernel version without UEFI support (which has been > >>> added in 7.3.1-rc2. > >> > >> I don't think that will help, since the issue isn't specific to the igb module. > >> > >> Having reviewed the root.loadmodules script, my hunch is that the unmount > >> of the squashfs is happening before the auto-loading has finished. Maybe the > >> loop with a 'sleep 3' gets (un)lucky sometimes? I note there's a VERBOSE2 > >> variable which will create more output; I'll give that a try when I get chance. > >> > > > > The extra debug output to the serial console with VERBOSE2 set would appear to > > confirm my hunch. > > > > When the module auto-loading stops too early: > > > > LOADMODULES: Waiting for module loading... > > LOADMODULES: PKGPATH: /dev/sda3:ext4 > > LOADMODULES: identified device /dev/sda3 > > LOADMODULES: Mounting /dev/sda3 on /mnt1 > > LOADMODULES: Mounted /dev/sda3 on /mnt1 > > LOADMODULES: The following mountpoints were created: /mnt1 > > LOADMODULES: Mounting squashfs with modules... > > LOADMODULES: found modules.sqfs on /mnt1 > > [ 16.342129] /dev/loop0: Can't open blockdev > > LOADMODULES: loading modules from /etc/modules > > LOADMODULES: /sbin/modprobe pppoe > > LOADMODULES: /sbin/modprobe softdog > > LOADMODULES: /sbin/modprobe ipv6 > > LOADMODULES: /sbin/modprobe 8021q > > LOADMODULES: /sbin/modprobe ifb > > LOADMODULES: /sbin/modprobe act_police > > LOADMODULES: /sbin/modprobe cls_fw > > LOADMODULES: /sbin/modprobe cls_flow > > LOADMODULES: /sbin/modprobe sch_tbf > > LOADMODULES: /sbin/modprobe sch_prio > > LOADMODULES: /sbin/modprobe sch_ingress > > LOADMODULES: /sbin/modprobe cls_u32 > > LOADMODULES: /sbin/modprobe sch_htb > > LOADMODULES: /sbin/modprobe sch_sfq > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 > > LOADMODULES: Unmounting /mnt1 > > LOADMODULES: Removing /mnt1 > > > > When the module auto-loading happens normally: > > > > LOADMODULES: Waiting for module loading... > > LOADMODULES: PKGPATH: /dev/sda3:ext4 > > LOADMODULES: identified device /dev/sda3 > > LOADMODULES: Mounting /dev/sda3 on /mnt1 > > LOADMODULES: Mounted /dev/sda3 on /mnt1 > > LOADMODULES: The following mountpoints were created: /mnt1 > > LOADMODULES: Mounting squashfs with modules... > > LOADMODULES: found modules.sqfs on /mnt1 > > [ 16.361295] /dev/loop0: Can't open blockdev > > LOADMODULES: loading modules from /etc/modules > > LOADMODULES: /sbin/modprobe pppoe > > LOADMODULES: /sbin/modprobe softdog > > LOADMODULES: /sbin/modprobe ipv6 > > LOADMODULES: /sbin/modprobe 8021q > > LOADMODULES: /sbin/modprobe ifb > > LOADMODULES: /sbin/modprobe act_police > > LOADMODULES: /sbin/modprobe cls_fw > > LOADMODULES: /sbin/modprobe cls_flow > > LOADMODULES: /sbin/modprobe sch_tbf > > LOADMODULES: /sbin/modprobe sch_prio > > LOADMODULES: /sbin/modprobe sch_ingress > > LOADMODULES: /sbin/modprobe cls_u32 > > LOADMODULES: /sbin/modprobe sch_htb > > LOADMODULES: /sbin/modprobe sch_sfq > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- > > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- > > LOADMODULES: Unmounting /mnt1 > > LOADMODULES: Removing /mnt1 > > > > The difference (marked <--) is that, when all the modules are loaded, it > > takes 3 attempts (with a sleep of 3 seconds between) to satisfy the > > criteria for 'looping to unmount' whereas when only some of the modules > > are loaded, the unmount of /lib/modules/6.1.64-x86_64 succeeds at the > > first attempt. > > > > This is the relevant section of repo/initrd/root.loadmodules (installed > > as /var/lib/lrpkg/root.loadmodules): > > > > # umount the squashfs > > loop_counter=0 > > while [ $loop_counter -lt 15 ] > > do > > [ "$VERBOSE2" ] && Lecho "looping to unmount /lib/modules/$KVER" > > umount /lib/modules/$KVER > /dev/null 2>&1 > > [ -z "$(grep /lib/modules/$KVER /proc/mounts)" ] && break > > sleep 3 > > done > > > > For some reason, the 'umount' is succeeding before module auto-loading has > > completed - but only sometimes, and only for some installations (and only > > on APU boards, it seems). > > > > dMb > > > >> dMb > >> > >>> kp > >>> > > > > |
From: Otto H. - T. <ott...@te...> - 2024-07-11 11:55:02
|
Hi list, the same thing happen to me. I am using version 7.3.1 released 2024-06-29 on ALIX.6F2 / LX800 256MB. After reboot both the eth interfaces are missing. It only happen sometimes, not every second reboot like in case of APU2 boards. Here is part of the boot proces shown on the terminal: ... LOADPKG: configdb.lrp installed LOADPKG: Unmounting /mnt1 LOADPKG: Removing /mnt1 LOADPKG: Loaded Packages LOADMODULES: identified device /dev/sda1 LOADMODULES: Mounting squashfs with modules... LOADMODULES: found modules.sqfs on /mnt1 [ 33.768860] /dev/loop0: Can't open blockdev LOADMODULES: loading modules from /etc/modules LOADMODULES: Unmounting /mnt1 LOADMODULES: Removing /mnt1 Type in help if you are really lost Setting kernel variables ... net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 0 kernel.printk = 3 4 1 7 kernel.panic = 5 kernel.core_pattern = /tmp/core.%e.%p.%s net.core.rmem_max = 6291456 net.core.wmem_max = 6291456 net.core.optmem_max = 524288 net.core.netdev_max_backlog = 10000 net.core.netdev_tstamp_prequeue = 0 done. Mounting local file systems... Initializing random number generator... done. Starting rsyslog daemon: OK Configuring network interfaces: Cannot find device "eth0" Cannot find device "eth1" Cannot find device "eth1" done. Starting software watchdog... done. Starting IPv4 shorewall rules... Compiling using Shorewall 5.2.8... Shorewall configuration compiled to /var/lib/shorewall/.start Starting Shorewall.... done. Starting internet superserver: inetd. ... BR, Otto Dne 08.07.2024 v 18:53 David Brooke napsal(a): >> On 08/07/2024 14:34 BST David Brooke <le...@da...> wrote: >> >> >>> On 06/07/2024 12:30 BST KP.Kirchdoerfer <ka...@be...> wrote: >>> >>> >>> Am Mittwoch, 3. Juli 2024, 18:30:29 CEST schrieb David Brooke: >>>> Hi, >>>> >>>>> On 04/06/2024 14:20 BST KP.Kirchdoerfer <ka...@be...> wrote: >>>>> >>>>> >>>>> Hi; >>>>> >>>>> Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: >>>>>> Hello, >>>>>> >>>>>> tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the >>>>>> Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. >>>>>> >>>>>> This failed since the network interfaces were no longer recognized. >>>>>> Reverting back to rc1 made the network interfaces appear again. Have not >>>>>> yet understood on what goes wrong, but maybe someone else is also having >>>>>> this issue. >>>>> >>>>> It does work here with APU2 and igb network driver (automatically >>>>> detected). >>>>> >>>>> If you're issue persists I'll look again next week. >>>>> >>>>> kp >>>> >>>> I am seeing the same issue today with 7.3.1_x86_64 on an APU2. >>>> >>>> Seems to be intermittent / inconsistent though: >>>> * Reboot and it says can't find eth0/1/2 >>>> * Reboot again and it *can* find those but *not* e.g. ppp0 >>>> * Reboot again and it's back to not finding eth0/1/2 >>>> >>>> I wonder if it's right on the limit of a timeout for module loading??? >>>> (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for this?) >>>> >>> >>> Odd; I'm running it successfully on an APU4 and also tested the image with >>> qemu. >> >> Odd indeed! :-) When it works, everything is fine - and I've been running >> 7.3.1 successfully for a few days now (without rebooting). But then I do a >> reboot and it fails to find the network interfaces. When I reboot a second >> time - *with the **exact** same configuration* - it works fine again. >> >> (Changing usb_wait didn't help; I've had that set to 4 when it failed, and >> 2 when it works.) >> >>> What does dmesg show when you are booting? (see below how it looks here) >> >> I've now got the dmesg output captured for a 'good' and a 'bad' boot. >> These are identical until after the 'u32 classifier' lines - which I >> believe are the result of loading cls_u32, specified near the end of >> /etc/modules. Is that a clue? Looking at repo/init.d/root.loadmodules >> there's an attempt to unmount the squashfs as soon as /etc/modules >> has been processed. >> >> dmesg output from a 'good' boot: >> >> ... >> [ 17.801213] 8021q: 802.1Q VLAN Support v1.8 >> [ 17.866368] u32 classifier >> [ 17.866384] Performance counters on >> [ 17.866387] input device check on >> [ 17.866390] Actions configured >> [ 17.941866] igb: loading out-of-tree module taints kernel. >> [ 17.956580] igb: Intel(R) Gigabit Ethernet Linux Driver - version 5.15.6 >> [ 17.956588] igb: Copyright(c) 2007 - 2023 Intel Corporation. >> ... (Many more igb lines, omitted) >> [ 18.100447] igb 0000:03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) >> [ 19.117966] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver >> [ 19.118339] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address >> [ 19.118510] sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0) >> [ 19.139035] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 >> [ 19.139055] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus port selection >> [ 19.139329] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20 >> [ 19.263714] EDAC amd64: MCT channel count: 1 >> [ 19.264013] EDAC MC0: Giving out device to module amd64_edac controller F16h_M30h: DEV 0000:00:18.3 (INTERRUPT) >> [ 19.264054] EDAC amd64: F16h_M30h detected (node 0). >> [ 19.264059] EDAC MC: DCT0 chip selects: >> [ 19.264063] EDAC amd64: MC: 0: 4096MB 1: 0MB >> [ 19.264070] EDAC amd64: MC: 2: 0MB 3: 0MB >> [ 19.264076] EDAC amd64: MC: 4: 0MB 5: 0MB >> [ 19.264081] EDAC amd64: MC: 6: 0MB 7: 0MB >> [ 19.264086] EDAC MC: DCT1 chip selects: >> [ 19.264089] EDAC amd64: MC: 0: 0MB 1: 0MB >> [ 19.264094] EDAC amd64: MC: 2: 0MB 3: 0MB >> [ 19.264098] EDAC amd64: MC: 4: 0MB 5: 0MB >> [ 19.264103] EDAC amd64: MC: 6: 0MB 7: 0MB >> [ 19.264107] EDAC amd64: using x4 syndromes. >> [ 19.264144] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) >> [ 19.264183] AMD64 EDAC driver v3.5.0 >> [ 19.630869] acpi_cpufreq: overriding BIOS provided _PSD data >> [ 23.910792] EXT4-fs (sda3): unmounting filesystem. >> [ 23.919071] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS >> >> >> dmesg output from a 'bad' boot: >> >> ... >> [ 17.803206] 8021q: 802.1Q VLAN Support v1.8 >> [ 17.868978] u32 classifier >> [ 17.869023] Performance counters on >> [ 17.869026] input device check on >> [ 17.869028] Actions configured >> [ 17.899170] EXT4-fs (sda3): unmounting filesystem. >> [ 17.908144] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS >> >> So it's not only the igb modules that are missing; some others fail to load too. >> It's as if the module auto-loading just stops too soon. >> >> The text on the serial console is the same in both cases: >> >> LOADMODULES: identified device /dev/sda3 >> LOADMODULES: Mounting squashes with modules... >> LOADMODULES: found modules.sqfs on /mnt1 >> [ 16.399684] /dev/loop0: Can't open blockdev >> LOADMODULES: loading modules from /etc/modules >> LOADMODULES: Unmounting /mnt1 >> LOADMODULES: Removing /mnt1 >> >> (I always get that /dev/loop0 'blockdev' message, which seems to just be a >> warning.) >> >>> Maybe it's worth testing the kernel module for igb, we are suing the out-of- >>> tree from Intel and/or a kernel version without UEFI support (which has been >>> added in 7.3.1-rc2. >> >> I don't think that will help, since the issue isn't specific to the igb module. >> >> Having reviewed the root.loadmodules script, my hunch is that the unmount >> of the squashfs is happening before the auto-loading has finished. Maybe the >> loop with a 'sleep 3' gets (un)lucky sometimes? I note there's a VERBOSE2 >> variable which will create more output; I'll give that a try when I get chance. >> > > The extra debug output to the serial console with VERBOSE2 set would appear to > confirm my hunch. > > When the module auto-loading stops too early: > > LOADMODULES: Waiting for module loading... > LOADMODULES: PKGPATH: /dev/sda3:ext4 > LOADMODULES: identified device /dev/sda3 > LOADMODULES: Mounting /dev/sda3 on /mnt1 > LOADMODULES: Mounted /dev/sda3 on /mnt1 > LOADMODULES: The following mountpoints were created: /mnt1 > LOADMODULES: Mounting squashfs with modules... > LOADMODULES: found modules.sqfs on /mnt1 > [ 16.342129] /dev/loop0: Can't open blockdev > LOADMODULES: loading modules from /etc/modules > LOADMODULES: /sbin/modprobe pppoe > LOADMODULES: /sbin/modprobe softdog > LOADMODULES: /sbin/modprobe ipv6 > LOADMODULES: /sbin/modprobe 8021q > LOADMODULES: /sbin/modprobe ifb > LOADMODULES: /sbin/modprobe act_police > LOADMODULES: /sbin/modprobe cls_fw > LOADMODULES: /sbin/modprobe cls_flow > LOADMODULES: /sbin/modprobe sch_tbf > LOADMODULES: /sbin/modprobe sch_prio > LOADMODULES: /sbin/modprobe sch_ingress > LOADMODULES: /sbin/modprobe cls_u32 > LOADMODULES: /sbin/modprobe sch_htb > LOADMODULES: /sbin/modprobe sch_sfq > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 > LOADMODULES: Unmounting /mnt1 > LOADMODULES: Removing /mnt1 > > When the module auto-loading happens normally: > > LOADMODULES: Waiting for module loading... > LOADMODULES: PKGPATH: /dev/sda3:ext4 > LOADMODULES: identified device /dev/sda3 > LOADMODULES: Mounting /dev/sda3 on /mnt1 > LOADMODULES: Mounted /dev/sda3 on /mnt1 > LOADMODULES: The following mountpoints were created: /mnt1 > LOADMODULES: Mounting squashfs with modules... > LOADMODULES: found modules.sqfs on /mnt1 > [ 16.361295] /dev/loop0: Can't open blockdev > LOADMODULES: loading modules from /etc/modules > LOADMODULES: /sbin/modprobe pppoe > LOADMODULES: /sbin/modprobe softdog > LOADMODULES: /sbin/modprobe ipv6 > LOADMODULES: /sbin/modprobe 8021q > LOADMODULES: /sbin/modprobe ifb > LOADMODULES: /sbin/modprobe act_police > LOADMODULES: /sbin/modprobe cls_fw > LOADMODULES: /sbin/modprobe cls_flow > LOADMODULES: /sbin/modprobe sch_tbf > LOADMODULES: /sbin/modprobe sch_prio > LOADMODULES: /sbin/modprobe sch_ingress > LOADMODULES: /sbin/modprobe cls_u32 > LOADMODULES: /sbin/modprobe sch_htb > LOADMODULES: /sbin/modprobe sch_sfq > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- > LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- > LOADMODULES: Unmounting /mnt1 > LOADMODULES: Removing /mnt1 > > The difference (marked <--) is that, when all the modules are loaded, it > takes 3 attempts (with a sleep of 3 seconds between) to satisfy the > criteria for 'looping to unmount' whereas when only some of the modules > are loaded, the unmount of /lib/modules/6.1.64-x86_64 succeeds at the > first attempt. > > This is the relevant section of repo/initrd/root.loadmodules (installed > as /var/lib/lrpkg/root.loadmodules): > > # umount the squashfs > loop_counter=0 > while [ $loop_counter -lt 15 ] > do > [ "$VERBOSE2" ] && Lecho "looping to unmount /lib/modules/$KVER" > umount /lib/modules/$KVER > /dev/null 2>&1 > [ -z "$(grep /lib/modules/$KVER /proc/mounts)" ] && break > sleep 3 > done > > For some reason, the 'umount' is succeeding before module auto-loading has > completed - but only sometimes, and only for some installations (and only > on APU boards, it seems). > > dMb > >> dMb >> >>> kp >>> > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ |
From: Otto H. - T. <ott...@te...> - 2024-07-11 11:09:28
|
Hi Marko, kernel params are in syslinux.cfg file in line after the APPEND on your storage device. There should be also parameter reboot=bios. BR, Otto Dne 11.07.2024 v 10:43 marko via leaf-user napsal(a): > Hi All, > > I have a qotom 4 port mini pc router which does not reboot on command. > It stops at "Requesting system reboot" > > Normally I would try some different kernel reboot= parameters but I can't find > the location in leaf. > > Can anyone shed some light on this or how to ensure reboot? > > thanks > marko > > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ -- Ing. Otto Halák technický ředitel --------------------------------- TeleLarm - security servis s.r.o. Na Zámecké 1518/9 140 00 Praha 4 Provozovna (návštěvní a korespondenční adresa): TeleLarm - Security servis s.r.o. U Nadjezdu 185 284 03 Kutná Hora tel. +420 327 312 749 gsm +420 608 362 487 e-mail: ott...@te... web: www.telelarm.cz --------------------------------- |
From: marko <le...@me...> - 2024-07-11 08:43:32
|
Hi All, I have a qotom 4 port mini pc router which does not reboot on command. It stops at "Requesting system reboot" Normally I would try some different kernel reboot= parameters but I can't find the location in leaf. Can anyone shed some light on this or how to ensure reboot? thanks marko |
From: David B. <le...@da...> - 2024-07-08 16:54:12
|
> On 08/07/2024 14:34 BST David Brooke <le...@da...> wrote: > > > > On 06/07/2024 12:30 BST KP.Kirchdoerfer <ka...@be...> wrote: > > > > > > Am Mittwoch, 3. Juli 2024, 18:30:29 CEST schrieb David Brooke: > > > Hi, > > > > > > > On 04/06/2024 14:20 BST KP.Kirchdoerfer <ka...@be...> wrote: > > > > > > > > > > > > Hi; > > > > > > > > Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: > > > > > Hello, > > > > > > > > > > tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the > > > > > Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. > > > > > > > > > > This failed since the network interfaces were no longer recognized. > > > > > Reverting back to rc1 made the network interfaces appear again. Have not > > > > > yet understood on what goes wrong, but maybe someone else is also having > > > > > this issue. > > > > > > > > It does work here with APU2 and igb network driver (automatically > > > > detected). > > > > > > > > If you're issue persists I'll look again next week. > > > > > > > > kp > > > > > > I am seeing the same issue today with 7.3.1_x86_64 on an APU2. > > > > > > Seems to be intermittent / inconsistent though: > > > * Reboot and it says can't find eth0/1/2 > > > * Reboot again and it *can* find those but *not* e.g. ppp0 > > > * Reboot again and it's back to not finding eth0/1/2 > > > > > > I wonder if it's right on the limit of a timeout for module loading??? > > > (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for this?) > > > > > > > Odd; I'm running it successfully on an APU4 and also tested the image with > > qemu. > > Odd indeed! :-) When it works, everything is fine - and I've been running > 7.3.1 successfully for a few days now (without rebooting). But then I do a > reboot and it fails to find the network interfaces. When I reboot a second > time - *with the **exact** same configuration* - it works fine again. > > (Changing usb_wait didn't help; I've had that set to 4 when it failed, and > 2 when it works.) > > > What does dmesg show when you are booting? (see below how it looks here) > > I've now got the dmesg output captured for a 'good' and a 'bad' boot. > These are identical until after the 'u32 classifier' lines - which I > believe are the result of loading cls_u32, specified near the end of > /etc/modules. Is that a clue? Looking at repo/init.d/root.loadmodules > there's an attempt to unmount the squashfs as soon as /etc/modules > has been processed. > > dmesg output from a 'good' boot: > > ... > [ 17.801213] 8021q: 802.1Q VLAN Support v1.8 > [ 17.866368] u32 classifier > [ 17.866384] Performance counters on > [ 17.866387] input device check on > [ 17.866390] Actions configured > [ 17.941866] igb: loading out-of-tree module taints kernel. > [ 17.956580] igb: Intel(R) Gigabit Ethernet Linux Driver - version 5.15.6 > [ 17.956588] igb: Copyright(c) 2007 - 2023 Intel Corporation. > ... (Many more igb lines, omitted) > [ 18.100447] igb 0000:03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) > [ 19.117966] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver > [ 19.118339] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address > [ 19.118510] sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0) > [ 19.139035] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 > [ 19.139055] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus port selection > [ 19.139329] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20 > [ 19.263714] EDAC amd64: MCT channel count: 1 > [ 19.264013] EDAC MC0: Giving out device to module amd64_edac controller F16h_M30h: DEV 0000:00:18.3 (INTERRUPT) > [ 19.264054] EDAC amd64: F16h_M30h detected (node 0). > [ 19.264059] EDAC MC: DCT0 chip selects: > [ 19.264063] EDAC amd64: MC: 0: 4096MB 1: 0MB > [ 19.264070] EDAC amd64: MC: 2: 0MB 3: 0MB > [ 19.264076] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 19.264081] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 19.264086] EDAC MC: DCT1 chip selects: > [ 19.264089] EDAC amd64: MC: 0: 0MB 1: 0MB > [ 19.264094] EDAC amd64: MC: 2: 0MB 3: 0MB > [ 19.264098] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 19.264103] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 19.264107] EDAC amd64: using x4 syndromes. > [ 19.264144] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) > [ 19.264183] AMD64 EDAC driver v3.5.0 > [ 19.630869] acpi_cpufreq: overriding BIOS provided _PSD data > [ 23.910792] EXT4-fs (sda3): unmounting filesystem. > [ 23.919071] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS > > > dmesg output from a 'bad' boot: > > ... > [ 17.803206] 8021q: 802.1Q VLAN Support v1.8 > [ 17.868978] u32 classifier > [ 17.869023] Performance counters on > [ 17.869026] input device check on > [ 17.869028] Actions configured > [ 17.899170] EXT4-fs (sda3): unmounting filesystem. > [ 17.908144] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS > > So it's not only the igb modules that are missing; some others fail to load too. > It's as if the module auto-loading just stops too soon. > > The text on the serial console is the same in both cases: > > LOADMODULES: identified device /dev/sda3 > LOADMODULES: Mounting squashes with modules... > LOADMODULES: found modules.sqfs on /mnt1 > [ 16.399684] /dev/loop0: Can't open blockdev > LOADMODULES: loading modules from /etc/modules > LOADMODULES: Unmounting /mnt1 > LOADMODULES: Removing /mnt1 > > (I always get that /dev/loop0 'blockdev' message, which seems to just be a > warning.) > > > Maybe it's worth testing the kernel module for igb, we are suing the out-of- > > tree from Intel and/or a kernel version without UEFI support (which has been > > added in 7.3.1-rc2. > > I don't think that will help, since the issue isn't specific to the igb module. > > Having reviewed the root.loadmodules script, my hunch is that the unmount > of the squashfs is happening before the auto-loading has finished. Maybe the > loop with a 'sleep 3' gets (un)lucky sometimes? I note there's a VERBOSE2 > variable which will create more output; I'll give that a try when I get chance. > The extra debug output to the serial console with VERBOSE2 set would appear to confirm my hunch. When the module auto-loading stops too early: LOADMODULES: Waiting for module loading... LOADMODULES: PKGPATH: /dev/sda3:ext4 LOADMODULES: identified device /dev/sda3 LOADMODULES: Mounting /dev/sda3 on /mnt1 LOADMODULES: Mounted /dev/sda3 on /mnt1 LOADMODULES: The following mountpoints were created: /mnt1 LOADMODULES: Mounting squashfs with modules... LOADMODULES: found modules.sqfs on /mnt1 [ 16.342129] /dev/loop0: Can't open blockdev LOADMODULES: loading modules from /etc/modules LOADMODULES: /sbin/modprobe pppoe LOADMODULES: /sbin/modprobe softdog LOADMODULES: /sbin/modprobe ipv6 LOADMODULES: /sbin/modprobe 8021q LOADMODULES: /sbin/modprobe ifb LOADMODULES: /sbin/modprobe act_police LOADMODULES: /sbin/modprobe cls_fw LOADMODULES: /sbin/modprobe cls_flow LOADMODULES: /sbin/modprobe sch_tbf LOADMODULES: /sbin/modprobe sch_prio LOADMODULES: /sbin/modprobe sch_ingress LOADMODULES: /sbin/modprobe cls_u32 LOADMODULES: /sbin/modprobe sch_htb LOADMODULES: /sbin/modprobe sch_sfq LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 LOADMODULES: Unmounting /mnt1 LOADMODULES: Removing /mnt1 When the module auto-loading happens normally: LOADMODULES: Waiting for module loading... LOADMODULES: PKGPATH: /dev/sda3:ext4 LOADMODULES: identified device /dev/sda3 LOADMODULES: Mounting /dev/sda3 on /mnt1 LOADMODULES: Mounted /dev/sda3 on /mnt1 LOADMODULES: The following mountpoints were created: /mnt1 LOADMODULES: Mounting squashfs with modules... LOADMODULES: found modules.sqfs on /mnt1 [ 16.361295] /dev/loop0: Can't open blockdev LOADMODULES: loading modules from /etc/modules LOADMODULES: /sbin/modprobe pppoe LOADMODULES: /sbin/modprobe softdog LOADMODULES: /sbin/modprobe ipv6 LOADMODULES: /sbin/modprobe 8021q LOADMODULES: /sbin/modprobe ifb LOADMODULES: /sbin/modprobe act_police LOADMODULES: /sbin/modprobe cls_fw LOADMODULES: /sbin/modprobe cls_flow LOADMODULES: /sbin/modprobe sch_tbf LOADMODULES: /sbin/modprobe sch_prio LOADMODULES: /sbin/modprobe sch_ingress LOADMODULES: /sbin/modprobe cls_u32 LOADMODULES: /sbin/modprobe sch_htb LOADMODULES: /sbin/modprobe sch_sfq LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- LOADMODULES: looping to unmount /lib/modules/6.1.64-x86_64 <-- LOADMODULES: Unmounting /mnt1 LOADMODULES: Removing /mnt1 The difference (marked <--) is that, when all the modules are loaded, it takes 3 attempts (with a sleep of 3 seconds between) to satisfy the criteria for 'looping to unmount' whereas when only some of the modules are loaded, the unmount of /lib/modules/6.1.64-x86_64 succeeds at the first attempt. This is the relevant section of repo/initrd/root.loadmodules (installed as /var/lib/lrpkg/root.loadmodules): # umount the squashfs loop_counter=0 while [ $loop_counter -lt 15 ] do [ "$VERBOSE2" ] && Lecho "looping to unmount /lib/modules/$KVER" umount /lib/modules/$KVER > /dev/null 2>&1 [ -z "$(grep /lib/modules/$KVER /proc/mounts)" ] && break sleep 3 done For some reason, the 'umount' is succeeding before module auto-loading has completed - but only sometimes, and only for some installations (and only on APU boards, it seems). dMb > dMb > > > kp > > |
From: David B. <le...@da...> - 2024-07-08 13:35:05
|
> On 06/07/2024 12:30 BST KP.Kirchdoerfer <ka...@be...> wrote: > > > Am Mittwoch, 3. Juli 2024, 18:30:29 CEST schrieb David Brooke: > > Hi, > > > > > On 04/06/2024 14:20 BST KP.Kirchdoerfer <ka...@be...> wrote: > > > > > > > > > Hi; > > > > > > Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: > > > > Hello, > > > > > > > > tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the > > > > Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. > > > > > > > > This failed since the network interfaces were no longer recognized. > > > > Reverting back to rc1 made the network interfaces appear again. Have not > > > > yet understood on what goes wrong, but maybe someone else is also having > > > > this issue. > > > > > > It does work here with APU2 and igb network driver (automatically > > > detected). > > > > > > If you're issue persists I'll look again next week. > > > > > > kp > > > > I am seeing the same issue today with 7.3.1_x86_64 on an APU2. > > > > Seems to be intermittent / inconsistent though: > > * Reboot and it says can't find eth0/1/2 > > * Reboot again and it *can* find those but *not* e.g. ppp0 > > * Reboot again and it's back to not finding eth0/1/2 > > > > I wonder if it's right on the limit of a timeout for module loading??? > > (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for this?) > > > > Odd; I'm running it successfully on an APU4 and also tested the image with > qemu. Odd indeed! :-) When it works, everything is fine - and I've been running 7.3.1 successfully for a few days now (without rebooting). But then I do a reboot and it fails to find the network interfaces. When I reboot a second time - *with the **exact** same configuration* - it works fine again. (Changing usb_wait didn't help; I've had that set to 4 when it failed, and 2 when it works.) > What does dmesg show when you are booting? (see below how it looks here) I've now got the dmesg output captured for a 'good' and a 'bad' boot. These are identical until after the 'u32 classifier' lines - which I believe are the result of loading cls_u32, specified near the end of /etc/modules. Is that a clue? Looking at repo/init.d/root.loadmodules there's an attempt to unmount the squashfs as soon as /etc/modules has been processed. dmesg output from a 'good' boot: ... [ 17.801213] 8021q: 802.1Q VLAN Support v1.8 [ 17.866368] u32 classifier [ 17.866384] Performance counters on [ 17.866387] input device check on [ 17.866390] Actions configured [ 17.941866] igb: loading out-of-tree module taints kernel. [ 17.956580] igb: Intel(R) Gigabit Ethernet Linux Driver - version 5.15.6 [ 17.956588] igb: Copyright(c) 2007 - 2023 Intel Corporation. ... (Many more igb lines, omitted) [ 18.100447] igb 0000:03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [ 19.117966] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver [ 19.118339] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address [ 19.118510] sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0) [ 19.139035] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 [ 19.139055] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus port selection [ 19.139329] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20 [ 19.263714] EDAC amd64: MCT channel count: 1 [ 19.264013] EDAC MC0: Giving out device to module amd64_edac controller F16h_M30h: DEV 0000:00:18.3 (INTERRUPT) [ 19.264054] EDAC amd64: F16h_M30h detected (node 0). [ 19.264059] EDAC MC: DCT0 chip selects: [ 19.264063] EDAC amd64: MC: 0: 4096MB 1: 0MB [ 19.264070] EDAC amd64: MC: 2: 0MB 3: 0MB [ 19.264076] EDAC amd64: MC: 4: 0MB 5: 0MB [ 19.264081] EDAC amd64: MC: 6: 0MB 7: 0MB [ 19.264086] EDAC MC: DCT1 chip selects: [ 19.264089] EDAC amd64: MC: 0: 0MB 1: 0MB [ 19.264094] EDAC amd64: MC: 2: 0MB 3: 0MB [ 19.264098] EDAC amd64: MC: 4: 0MB 5: 0MB [ 19.264103] EDAC amd64: MC: 6: 0MB 7: 0MB [ 19.264107] EDAC amd64: using x4 syndromes. [ 19.264144] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) [ 19.264183] AMD64 EDAC driver v3.5.0 [ 19.630869] acpi_cpufreq: overriding BIOS provided _PSD data [ 23.910792] EXT4-fs (sda3): unmounting filesystem. [ 23.919071] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS dmesg output from a 'bad' boot: ... [ 17.803206] 8021q: 802.1Q VLAN Support v1.8 [ 17.868978] u32 classifier [ 17.869023] Performance counters on [ 17.869026] input device check on [ 17.869028] Actions configured [ 17.899170] EXT4-fs (sda3): unmounting filesystem. [ 17.908144] Adding 104444k swap on /dev/zram0. Priority:100 extents:1 across:104444k SS So it's not only the igb modules that are missing; some others fail to load too. It's as if the module auto-loading just stops too soon. The text on the serial console is the same in both cases: LOADMODULES: identified device /dev/sda3 LOADMODULES: Mounting squashes with modules... LOADMODULES: found modules.sqfs on /mnt1 [ 16.399684] /dev/loop0: Can't open blockdev LOADMODULES: loading modules from /etc/modules LOADMODULES: Unmounting /mnt1 LOADMODULES: Removing /mnt1 (I always get that /dev/loop0 'blockdev' message, which seems to just be a warning.) > Maybe it's worth testing the kernel module for igb, we are suing the out-of- > tree from Intel and/or a kernel version without UEFI support (which has been > added in 7.3.1-rc2. I don't think that will help, since the issue isn't specific to the igb module. Having reviewed the root.loadmodules script, my hunch is that the unmount of the squashfs is happening before the auto-loading has finished. Maybe the loop with a 'sleep 3' gets (un)lucky sometimes? I note there's a VERBOSE2 variable which will create more output; I'll give that a try when I get chance. > If you can't build a kernel and modules sqfs any more because of a missing > build environment, I'll provide both. I do have a build environment for 7.3.1 - I was unable to get FreeRadius working for my 802.1X WiFi Authentication use-case so I've been doing some updates to that, which I will share once I'm happy they are working OK. dMb > kp > |
From: KP.Kirchdoerfer <ka...@be...> - 2024-07-06 11:30:25
|
Am Mittwoch, 3. Juli 2024, 18:30:29 CEST schrieb David Brooke: > Hi, > > > On 04/06/2024 14:20 BST KP.Kirchdoerfer <ka...@be...> wrote: > > > > > > Hi; > > > > Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: > > > Hello, > > > > > > tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the > > > Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. > > > > > > This failed since the network interfaces were no longer recognized. > > > Reverting back to rc1 made the network interfaces appear again. Have not > > > yet understood on what goes wrong, but maybe someone else is also having > > > this issue. > > > > It does work here with APU2 and igb network driver (automatically > > detected). > > > > If you're issue persists I'll look again next week. > > > > kp > > I am seeing the same issue today with 7.3.1_x86_64 on an APU2. > > Seems to be intermittent / inconsistent though: > * Reboot and it says can't find eth0/1/2 > * Reboot again and it *can* find those but *not* e.g. ppp0 > * Reboot again and it's back to not finding eth0/1/2 > > I wonder if it's right on the limit of a timeout for module loading??? > (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for this?) > Odd; I'm running it successfully on an APU4 and also tested the image with qemu. What does dmesg show when you are booting? (see below how it looks here) Maybe it's worth testing the kernel module for igb, we are suing the out-of- tree from Intel and/or a kernel version without UEFI support (which has been added in 7.3.1-rc2. If you can't build a kernel and modules sqfs any more because of a missing build environment, I'll provide both. kp [ 20.619194] igb: loading out-of-tree module taints kernel. [ 20.630841] igb: Intel(R) Gigabit Ethernet Linux Driver - version 5.15.6 [ 20.630849] igb: Copyright(c) 2007 - 2023 Intel Corporation. [ 20.679286] igb 0000:02:00.0: added PHC on eth0 [ 20.679306] igb 0000:02:00.0: Intel(R) Gigabit Ethernet Linux Driver [ 20.679313] igb 0000:02:00.0: eth0: (PCIe:2.5GT/s:Width x1) [ 20.679322] igb 0000:02:00.0 eth0: MAC: 00:0d:b9:3f:9d:60 [ 20.679334] igb 0000:02:00.0: eth0: PBA No: Unknown [ 20.679352] igb 0000:02:00.0: LRO is disabled [ 20.679357] igb 0000:02:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [ 20.727310] igb 0000:03:00.0: added PHC on eth1 [ 20.727329] igb 0000:03:00.0: Intel(R) Gigabit Ethernet Linux Driver [ 20.727337] igb 0000:03:00.0: eth1: (PCIe:2.5GT/s:Width x1) [ 20.727346] igb 0000:03:00.0 eth1: MAC: 00:0d:b9:3f:9d:61 [ 20.727358] igb 0000:03:00.0: eth1: PBA No: Unknown [ 20.727376] igb 0000:03:00.0: LRO is disabled [ 20.727381] igb 0000:03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [ 20.775263] igb 0000:04:00.0: added PHC on eth2 [ 20.775282] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Linux Driver [ 20.775289] igb 0000:04:00.0: eth2: (PCIe:2.5GT/s:Width x1) [ 20.775299] igb 0000:04:00.0 eth2: MAC: 00:0d:b9:3f:9d:62 [ 20.775311] igb 0000:04:00.0: eth2: PBA No: Unknown [ 20.775329] igb 0000:04:00.0: LRO is disabled [ 20.775334] igb 0000:04:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) |
From: David B. <le...@da...> - 2024-07-03 16:43:58
|
Hi, > On 04/06/2024 14:20 BST KP.Kirchdoerfer <ka...@be...> wrote: > > > Hi; > > Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: > > Hello, > > > > tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the > > Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. > > > > This failed since the network interfaces were no longer recognized. > > Reverting back to rc1 made the network interfaces appear again. Have not > > yet understood on what goes wrong, but maybe someone else is also having > > this issue. > > It does work here with APU2 and igb network driver (automatically detected). > > If you're issue persists I'll look again next week. > > kp > I am seeing the same issue today with 7.3.1_x86_64 on an APU2. Seems to be intermittent / inconsistent though: * Reboot and it says can't find eth0/1/2 * Reboot again and it *can* find those but *not* e.g. ppp0 * Reboot again and it's back to not finding eth0/1/2 I wonder if it's right on the limit of a timeout for module loading??? (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for this?) Regards, davidMbrooke > > > > Kind Regards, > > Dirk > > > > > > ------------------------------------------------------------------------ > > leaf-user mailing list: lea...@li... > > https://lists.sourceforge.net/lists/listinfo/leaf-user > > Support Request -- http://leaf-project.org/ > > > > > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ |
From: marko <le...@me...> - 2024-06-16 11:41:43
|
On Friday, 14 June 2024 11:59:11 PM AEST Graziano Brioschi wrote: > Hi list, > > is there a way to enable boot in UEFI mode on 7.3.1-rc2? I have found a > specific "pseudo-industrial" machine that does not support "legacy BIOS > mode", so I cannot enable it on UEFI hardware firmware > > thanks > > Ciao > > G. syslinux does support UEFI here is a link if you want to try it out. https://unix.stackexchange.com/questions/703920/create-bootable-syslinux-usb-on-uefi[1] best of luck marko -------- [1] https://unix.stackexchange.com/questions/703920/create-bootable-syslinux-usb-on-uefi |
From: Graziano B. <gra...@ou...> - 2024-06-14 14:19:50
|
Hi list, is there a way to enable boot in UEFI mode on 7.3.1-rc2? I have found a specific "pseudo-industrial" machine that does not support "legacy BIOS mode", so I cannot enable it on UEFI hardware firmware thanks Ciao G. -- Graziano Brioschi Outland s.a.s. sede operativa: Via A. Don Rocca, 13 20030, Senago (MI) tel: 02 9948 6014 mobile: 328 8382622 email: gra...@ou... --> U4E <-- |
From: KP.Kirchdoerfer <ka...@be...> - 2024-06-04 13:20:47
|
Hi; Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer: > Hello, > > tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the > Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. > > This failed since the network interfaces were no longer recognized. > Reverting back to rc1 made the network interfaces appear again. Have not > yet understood on what goes wrong, but maybe someone else is also having > this issue. It does work here with APU2 and igb network driver (automatically detected). If you're issue persists I'll look again next week. kp > > Kind Regards, > Dirk > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ |
From: Dirk G. <Dir...@gu...> - 2024-06-04 07:24:54
|
Hello, tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image. This failed since the network interfaces were no longer recognized. Reverting back to rc1 made the network interfaces appear again. Have not yet understood on what goes wrong, but maybe someone else is also having this issue. Kind Regards, Dirk |
From: Dirk G. <Dir...@gu...> - 2024-06-04 07:19:55
|
Hello, looks like 7.3.1-rc2 ships with 6.1.64 which is rather old. Are there plans to update to 6.1.91? Kind Regards, Dirk |
From: KP.Kirchdoerfer <ka...@be...> - 2024-04-28 11:47:13
|
Hi Marko Am Sonntag, 28. April 2024, 12:31:02 CEST schrieb marko via leaf-user: > Hi all, > I've been cleaning up my leaf packages and lost access to > i) Install to disk (experimental) > in the lrcfg menu. > > I don't see any package loading errors on boot. > which packages are required to enable this function? hdsupp.lrp is needed. kp > thanks > marko |
From: marko <le...@me...> - 2024-04-28 10:31:19
|
Hi all, I've been cleaning up my leaf packages and lost access to i) Install to disk (experimental) in the lrcfg menu. I don't see any package loading errors on boot. which packages are required to enable this function? thanks marko |
From: John S. <jo...@sa...> - 2024-04-18 19:08:13
|
kp, I am glad it builds for other architectures. I have rebuilt it with your mods successfully. I haven't yet tested it on my firewall but the nft and libnftables binaries are the same size as I would expect. The nftables documentation is deficient for the libnftables API though Debian has a man page for it so, yes, the separation of the library makes sense. regards, John On 18/04/2024 16:31, KP.Kirchdoerfer wrote: > Hi John; > > Am Montag, 15. April 2024, 16:57:59 CEST schrieb John Sager: >> kp, >> >> I have just pushed a new branch 'nftables-test' to the repository. This has >> the commit for the nftables stuff - conf/sources.d/nftables.cfg and >> repo/nftables/. >> >> Sorry it has taken so long to do but I have been busy with other things. I >> have only tested it on x86-64 as that is my only test environment. > > Thx a lot for the contribution! > > It builds fine for all architectures. > > I've committed a change in your branch seperating the libs in their own > package. > It was an early design decison for LEAF Bering-uClibc to seperate tools from > libs wherever possible - that way a user can use the libs with other tools if > wanted/needed without installing unwanted binaries. > nftables.lrp will install libnftables.lrp - so it works as you expect. > > Pls have a look and (hopefully) confirm it works. > > kp > > > > >> regards, >> >> John >> >> On 08/03/2024 23:02, KP.Kirchdoerfer wrote: >>> Hi; >>> >>> Am Freitag, 8. März 2024, 11:21:12 CET schrieb John Sager: >>>> KP, >>>> >>>> Ok I'll commit nftables to the git repository but it will be a week or >>>> two >>>> before I can do so. Which branch should I use for the commit? >>> >>> I think best would be to branch from master and create a new repository >>> which can be merged after a bit of testing builds. >>> >>> kp >>> >>>> regards, >>>> >>>> John >>>> >>>> On 6 March 2024 16:20:36 GMT, "KP.Kirchdoerfer" <ka...@be...> >>> >>> wrote: >>>>> H John; >>>>> >>>>> sorry for late reply. >>>>> >>>>> Am Dienstag, 6. Februar 2024, 11:45:27 CET schrieb John Sager: >>>>>> I've been using version 7.0.2 on a PC Engines APU2C2 as my border >>>>>> router/firewall for a couple of years and I decided to upgrade to >>>>>> version >>>>>> 7.3.0, it being the latest release. I don't use the 'upgrade' tool but >>>>>> instead I have three partitions on the SD card - a vfat boot partition >>>>>> and >>>>>> two ext4 partitions for old and new versions. This makes it easy to >>>>>> just >>>>>> reboot the old version if the new one misbehaves. >>>>> >>>>> Honestly, ido the same - having three versions on my router - old and >>>>> ultrastable, if everything goes wrong, stable with a current version >>>>> having >>>>> usual updates and testing for cutting edge. >>>>> >>>>>> Additionally I had moved to using nftables on 7.0.2 to create the >>>>>> firewall >>>>>> rules and packet marking rules for traffic control. I wanted to try it >>>>>> out >>>>>> in a real environment. Previously I used hand-crafted iptables rules >>>>>> rather >>>>>> than shorewall anyway for more flexibility. >>>>>> >>>>>> I like nftables so I am sticking with it. For this release I cloned the >>>>>> bering development git repository on sourceforge to build nftables. I >>>>>> had >>>>>> to use version 1.0.6 of nftables rather than the latest version (1.0.9) >>>>>> as it has to work with the release version (1.2.5) of libnftnl. Besides >>>>>> libnftnl it also needs libmnl (already in initrd, as I eventually >>>>>> realised), libedit, libgmp and libjansson. Those libraries and all the >>>>>> other packages are from >>>>>> Bering-uClibc_7.3.0_x86_64_syslinux_serial115200.tar.gz. >>>>>> >>>>>> On first booting into the new version I got errors. nftables didn't >>>>>> work >>>>>> as >>>>>> I had made a small build error but that was easily fixed. However a >>>>>> couple >>>>>> of other applications also failed: >>>>>> >>>>>> ntpd requires libcap though it isn't listed in ntpd.deplrp, so libcap >>>>>> needs >>>>>> to go in the list of packages to load in leaf.cfg. This was also raised >>>>>> by >>>>>> Robert K Coffman jr on leaf-user in August 2023. >>>>> >>>>> Yeap, for got to commit the fix previously, done. >>>>> >>>>>> tc requires libxtables. When using iptables, that library would >>>>>> normally >>>>>> get loaded automatically but I don't use iptables, so libiptbl (where >>>>>> libxtables lives) goes in the package list in leaf.cfg. >>>>> >>>>> It most probably won't do any harm if libiptbl would be added to tc.lrp >>>>> as >>>>> requirement. >>>>> >>>>>> So far the new version has been working for over 24 hours with no >>>>>> obvious >>>>>> issues. >>>>>> >>>>>> If there is a demand for nftables perhaps it could be added to the >>>>>> distro? I can supply the config and the repo that I have used >>>>>> successfully now in two versions of Bering-uClibc as a template. >>>>> >>>>> Please do - it will be welcome. >>>>> As nothing has changed in the git permissions since you've committed the >>>>> first wireguard packages years ago, you should be able to do so for >>>>> nftables as well. >>>>> >>>>> regards kp >>>>> >>>>>> regards, >>>>>> >>>>>> John Sager >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------------- >>>>>> - >>>>>> leaf-user mailing list: lea...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/leaf-user >>>>>> Support Request -- http://leaf-project.org/ >>>>> >>>>> ------------------------------------------------------------------------ >>>>> leaf-user mailing list: lea...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/leaf-user >>>>> Support Request -- http://leaf-project.org/ >>> >>> ------------------------------------------------------------------------ >>> leaf-user mailing list: lea...@li... >>> https://lists.sourceforge.net/lists/listinfo/leaf-user >>> Support Request -- http://leaf-project.org/ >> >> ------------------------------------------------------------------------ >> leaf-user mailing list: lea...@li... >> https://lists.sourceforge.net/lists/listinfo/leaf-user >> Support Request -- http://leaf-project.org/ > > > > > > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ |
From: KP.Kirchdoerfer <ka...@be...> - 2024-04-18 15:32:04
|
Hi John; Am Montag, 15. April 2024, 16:57:59 CEST schrieb John Sager: > kp, > > I have just pushed a new branch 'nftables-test' to the repository. This has > the commit for the nftables stuff - conf/sources.d/nftables.cfg and > repo/nftables/. > > Sorry it has taken so long to do but I have been busy with other things. I > have only tested it on x86-64 as that is my only test environment. Thx a lot for the contribution! It builds fine for all architectures. I've committed a change in your branch seperating the libs in their own package. It was an early design decison for LEAF Bering-uClibc to seperate tools from libs wherever possible - that way a user can use the libs with other tools if wanted/needed without installing unwanted binaries. nftables.lrp will install libnftables.lrp - so it works as you expect. Pls have a look and (hopefully) confirm it works. kp > regards, > > John > > On 08/03/2024 23:02, KP.Kirchdoerfer wrote: > > Hi; > > > > Am Freitag, 8. März 2024, 11:21:12 CET schrieb John Sager: > >> KP, > >> > >> Ok I'll commit nftables to the git repository but it will be a week or > >> two > >> before I can do so. Which branch should I use for the commit? > > > > I think best would be to branch from master and create a new repository > > which can be merged after a bit of testing builds. > > > > kp > > > >> regards, > >> > >> John > >> > >> On 6 March 2024 16:20:36 GMT, "KP.Kirchdoerfer" <ka...@be...> > > > > wrote: > >>> H John; > >>> > >>> sorry for late reply. > >>> > >>> Am Dienstag, 6. Februar 2024, 11:45:27 CET schrieb John Sager: > >>>> I've been using version 7.0.2 on a PC Engines APU2C2 as my border > >>>> router/firewall for a couple of years and I decided to upgrade to > >>>> version > >>>> 7.3.0, it being the latest release. I don't use the 'upgrade' tool but > >>>> instead I have three partitions on the SD card - a vfat boot partition > >>>> and > >>>> two ext4 partitions for old and new versions. This makes it easy to > >>>> just > >>>> reboot the old version if the new one misbehaves. > >>> > >>> Honestly, ido the same - having three versions on my router - old and > >>> ultrastable, if everything goes wrong, stable with a current version > >>> having > >>> usual updates and testing for cutting edge. > >>> > >>>> Additionally I had moved to using nftables on 7.0.2 to create the > >>>> firewall > >>>> rules and packet marking rules for traffic control. I wanted to try it > >>>> out > >>>> in a real environment. Previously I used hand-crafted iptables rules > >>>> rather > >>>> than shorewall anyway for more flexibility. > >>>> > >>>> I like nftables so I am sticking with it. For this release I cloned the > >>>> bering development git repository on sourceforge to build nftables. I > >>>> had > >>>> to use version 1.0.6 of nftables rather than the latest version (1.0.9) > >>>> as it has to work with the release version (1.2.5) of libnftnl. Besides > >>>> libnftnl it also needs libmnl (already in initrd, as I eventually > >>>> realised), libedit, libgmp and libjansson. Those libraries and all the > >>>> other packages are from > >>>> Bering-uClibc_7.3.0_x86_64_syslinux_serial115200.tar.gz. > >>>> > >>>> On first booting into the new version I got errors. nftables didn't > >>>> work > >>>> as > >>>> I had made a small build error but that was easily fixed. However a > >>>> couple > >>>> of other applications also failed: > >>>> > >>>> ntpd requires libcap though it isn't listed in ntpd.deplrp, so libcap > >>>> needs > >>>> to go in the list of packages to load in leaf.cfg. This was also raised > >>>> by > >>>> Robert K Coffman jr on leaf-user in August 2023. > >>> > >>> Yeap, for got to commit the fix previously, done. > >>> > >>>> tc requires libxtables. When using iptables, that library would > >>>> normally > >>>> get loaded automatically but I don't use iptables, so libiptbl (where > >>>> libxtables lives) goes in the package list in leaf.cfg. > >>> > >>> It most probably won't do any harm if libiptbl would be added to tc.lrp > >>> as > >>> requirement. > >>> > >>>> So far the new version has been working for over 24 hours with no > >>>> obvious > >>>> issues. > >>>> > >>>> If there is a demand for nftables perhaps it could be added to the > >>>> distro? I can supply the config and the repo that I have used > >>>> successfully now in two versions of Bering-uClibc as a template. > >>> > >>> Please do - it will be welcome. > >>> As nothing has changed in the git permissions since you've committed the > >>> first wireguard packages years ago, you should be able to do so for > >>> nftables as well. > >>> > >>> regards kp > >>> > >>>> regards, > >>>> > >>>> John Sager > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ----------------------------------------------------------------------- > >>>> - > >>>> leaf-user mailing list: lea...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/leaf-user > >>>> Support Request -- http://leaf-project.org/ > >>> > >>> ------------------------------------------------------------------------ > >>> leaf-user mailing list: lea...@li... > >>> https://lists.sourceforge.net/lists/listinfo/leaf-user > >>> Support Request -- http://leaf-project.org/ > > > > ------------------------------------------------------------------------ > > leaf-user mailing list: lea...@li... > > https://lists.sourceforge.net/lists/listinfo/leaf-user > > Support Request -- http://leaf-project.org/ > > ------------------------------------------------------------------------ > leaf-user mailing list: lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ |