Menu
▾
▴
leaf-user — This mailing list is for all users and developers of LEAF.
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
(2) |
Oct
|
Nov
|
Dec
|
|
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/ |
|
From: marko <le...@me...> - 2024-04-16 10:41:35
|
Hi All, I've been doing some work on easyrsa for openvpn on version 7.3 and have found that it does not work out of the box with openvpn 2.6 I have solutions, but have not worked with the leaf git system - what do I have to do to get the changes into forthcoming releases? cheers Marko |
|
From: John S. <jo...@sa...> - 2024-04-15 17:43:52
|
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. 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/ |
|
From: KP.Kirchdoerfer <ka...@be...> - 2024-03-08 23:02:15
|
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/ |
|
From: John S. <jo...@sa...> - 2024-03-08 10:28:31
|
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? 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/ -- Sent from the aether. |
|
From: KP.Kirchdoerfer <ka...@be...> - 2024-03-06 16:20:49
|
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/ |
69 messages has been excluded from this view by a project administrator.