leaf-user — This mailing list is for all users and developers of LEAF.

Re: [leaf-user] https://bering-uclibc.zetam.org appears broken

[jeanrocco jr <bla...@gm...>]

Hello List Users, and Robert,

On Fri, Apr 3, 2026 at 8:32 AM Robert K Coffman Jr. -Info From Data Corp. <
bco...@in...> wrote:

>    Thanks for the update - and I can't wait to see your changes!
>
>    - Robert
>
> Ha ! Robert, so glad to get this answer from you, that confirms that at
least one person is looking at the doc. ... :-) !

The good news is that bering-uclibc.zetam.org/wiki/ works now. I still
don't know what happened, but yesterday, I e-mailled KP, opened a ticket (
https://sourceforge.net/p/leaf/tickets/113/ ). So, this morning, I could
also verify that the changes I made were all there, hail Mary (no I didn't
see this apparently bubble gum movie yet }.

Lately I've been having some interesting chats with ClaudeAI, so I ask IT
what would be the best way to filter ads using dnamasq with the list
provided by
https://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq-server&showintro=1
. After some sparring with IT, I finally asked ClaideAI if the default
"server=/domain/ with no IP", in the yoyo list was the best way. To my
surprise it answered NO --- "address=/domain/ with no IP" is better and
faster since dnsmasq will resolve this immediately and answer NXDOMAIN. So
a browser would not try anything else and stop the query immediately.

That is what I added in the documentation. I would like your comments if
you have any, and ever feel like giving some.

I would also like to thank ClaudeAI :-)

jeanrocco



>    On 4/2/2026 5:02:33 PM, jeanrocco jr wrote:
>
> Hello LEAF users, & Mark
>
> About 3 days ago I added some changes in the documentation in Bering-uClibc
> 7.x Advance Topics - Setting Up Ad Blocking. I proceeded as usual, but I
> might have inadvertently screwed something up since I don't have access to
> the  bering-uclibc.zetam.org/wiki/ myself. The timing corresponds to my
> changes ... Since I don't have access to the Editing Bering-uClibc 7.x -
> User Guide - Advanced Topics - Setting Up Ad blocking with dnsmasq
> (section) - bering-uClibc
> [1]<
> https://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_6.x_-_User_Gui
>
> de_-_Advanced_Topics_-_Setting_Up_Ad_blocking_with_dnsmasq&action=edit&section=2
> <https://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_6.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_Ad_blocking_with_dnsmasq&action=edit&section=2>
> >
> anymore,
> I have to ask KP, or someone else, if he can restore it.
> Jeanrocco
>
> On Thu, Apr 2, 2026 at 8:02 AM LEAF [2]<le...@pa...> wrote:
>
>
> Hi Guys,
>
> Went to [3]https://bering-uclibc.zetam.org/ earlier tonight and am getting
> this:
>
>
>   Sorry! This site is experiencing technical difficulties.
>
> Try waiting a few minutes and reloading.
>
> (Cannot access the database)
>
> ------------------------------------------------------------------------
> You can try searching via Google in the meantime.
> Note that their indexes of our content may be out of date.
>
> It's been this way for a few hours now
> Don't know if anyone knows about this,
> Mark
>
> ------------------------------------------------------------------------
> leaf-user mailing list: [4]lea...@li...
> [5]https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- [6]http://leaf-project.org/
>
>
> ------------------------------------------------------------------------
> leaf-user mailing list: [7]lea...@li...
> [8]https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- [9]http://leaf-project.org/
>
> --
> Robert K Coffman Jr.
> Info From Data Corp.
> 3307249000
> [10]su...@in...
>
> References
>
>    1.
> https://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_6.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_Ad_blocking_with_dnsmasq&action=edit&section=2
>    2. mailto:le...@pa...
>    3. https://bering-uclibc.zetam.org/
>    4. mailto:lea...@li...
>    5. https://lists.sourceforge.net/lists/listinfo/leaf-user
>    6. http://leaf-project.org/
>    7. mailto:lea...@li...
>    8. https://lists.sourceforge.net/lists/listinfo/leaf-user
>    9. http://leaf-project.org/
>   10. mailto:su...@in...
>
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/
>

Re: [leaf-user] https://bering-uclibc.zetam.org appears broken

[Robert K C. J. -I. F. D. Corp. <bco...@in...>]

   Thanks for the update - and I can't wait to see your changes!

   - Robert

   On 4/2/2026 5:02:33 PM, jeanrocco jr wrote:

Hello LEAF users, & Mark

About 3 days ago I added some changes in the documentation in Bering-uClibc
7.x Advance Topics - Setting Up Ad Blocking. I proceeded as usual, but I
might have inadvertently screwed something up since I don't have access to
the  bering-uclibc.zetam.org/wiki/ myself. The timing corresponds to my
changes ... Since I don't have access to the Editing Bering-uClibc 7.x -
User Guide - Advanced Topics - Setting Up Ad blocking with dnsmasq
(section) - bering-uClibc
[1]<https://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_6.x_-_User_Gui
de_-_Advanced_Topics_-_Setting_Up_Ad_blocking_with_dnsmasq&action=edit&section=2
>
anymore,
I have to ask KP, or someone else, if he can restore it.
Jeanrocco

On Thu, Apr 2, 2026 at 8:02 AM LEAF [2]<le...@pa...> wrote:


Hi Guys,

Went to [3]https://bering-uclibc.zetam.org/ earlier tonight and am getting
this:


  Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Cannot access the database)

------------------------------------------------------------------------
You can try searching via Google in the meantime.
Note that their indexes of our content may be out of date.

It's been this way for a few hours now
Don't know if anyone knows about this,
Mark

------------------------------------------------------------------------
leaf-user mailing list: [4]lea...@li...
[5]https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- [6]http://leaf-project.org/


------------------------------------------------------------------------
leaf-user mailing list: [7]lea...@li...
[8]https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- [9]http://leaf-project.org/

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[10]su...@in...

References

   1. https://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_6.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_Ad_blocking_with_dnsmasq&action=edit&section=2
   2. mailto:le...@pa...
   3. https://bering-uclibc.zetam.org/
   4. mailto:lea...@li...
   5. https://lists.sourceforge.net/lists/listinfo/leaf-user
   6. http://leaf-project.org/
   7. mailto:lea...@li...
   8. https://lists.sourceforge.net/lists/listinfo/leaf-user
   9. http://leaf-project.org/
  10. mailto:su...@in...

Re: [leaf-user] https://bering-uclibc.zetam.org appears broken

[jeanrocco jr <bla...@gm...>]

Hello LEAF users, & Mark

About 3 days ago I added some changes in the documentation in Bering-uClibc
7.x Advance Topics - Setting Up Ad Blocking. I proceeded as usual, but I
might have inadvertently screwed something up since I don't have access to
the  bering-uclibc.zetam.org/wiki/ myself. The timing corresponds to my
changes ... Since I don't have access to the Editing Bering-uClibc 7.x -
User Guide - Advanced Topics - Setting Up Ad blocking with dnsmasq
(section) - bering-uClibc
<https://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_6.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_Ad_blocking_with_dnsmasq&action=edit&section=2>
anymore,
I have to ask KP, or someone else, if he can restore it.
Jeanrocco

On Thu, Apr 2, 2026 at 8:02 AM LEAF <le...@pa...> wrote:

> Hi Guys,
>
> Went to https://bering-uclibc.zetam.org/ earlier tonight and am getting
> this:
>
>
>   Sorry! This site is experiencing technical difficulties.
>
> Try waiting a few minutes and reloading.
>
> (Cannot access the database)
>
> ------------------------------------------------------------------------
> You can try searching via Google in the meantime.
> Note that their indexes of our content may be out of date.
>
> It's been this way for a few hours now
> Don't know if anyone knows about this,
> Mark
>
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/
>

[leaf-user] https://bering-uclibc.zetam.org appears broken

[LEAF <le...@pa...>]

Hi Guys,

Went to https://bering-uclibc.zetam.org/ earlier tonight and am getting 
this:


  Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Cannot access the database)

------------------------------------------------------------------------
You can try searching via Google in the meantime.
Note that their indexes of our content may be out of date.

It's been this way for a few hours now
Don't know if anyone knows about this,
Mark

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[LEAF <le...@pa...>]

Hi Erich,

On 1/04/2026 11:44 am, LEAF wrote:
>>
>> Right, so wireguard loads the modules dynamically. I am pretty sure 
>> it uses the same kernel modules as shorewall to handle iptables.
>
> Wireguard does try to load the modules it needs. I don't know if 
> shorewall loads everything wireguard needs, but I can test this at a 
> later time.

This is that test - wireguard restart with wireguard not loading any 
modules and shorewall enabled and loading the its default modules. (I've 
added a few empty lines in the output for clarity)

    router# /etc/init.d/wireguard restart
    Stopping wireguard VPN server on interface wg0
    wg-quick: `wg0' is not a WireGuard interface
    Starting wireguard VPN server on interface wg0
    [#] ip link add wg0 type wireguard
    [#] wg setconf wg0 /dev/fd/63
    [#] ip -4 address add 10.2.0.2/32 dev wg0
    RTNETLINK answers: Network is unreachable
    [#] ip link set mtu 1420 up dev wg0
    [#] resolvconf -a wg0 -m 0 -x
    [#] wg set wg0 fwmark 51820
    [#] ip -6 route add ::/0 dev wg0 table 51820
    [#] ip -6 rule add not fwmark 51820 table 51820
    [#] ip -6 rule add table main suppress_prefixlength 0

    [#] ip6tables-restore -n
    modprobe: can't open 'modules.dep': No such file or directory
    ip6tables-restore v1.8.8 (legacy): ip6tables-restore: unable to
    initialize table 'raw'

    Error occurred at line: 1
    Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more
    information.

    [#] resolvconf -d wg0 -f
    [#] ip -6 rule delete table 51820
    [#] ip -6 rule delete table main suppress_prefixlength 0
    [#] ip link delete dev wg0
    router#

So wireguard is looking for the following modules that are not provided 
by shorewall. There could be a few others (I didn't work through them to 
check), but that doesn't matter, because shorewall module loading 
doesn't provide everything on its own.

    iptable_raw
    ip6table_raw

Note: for this test wireguard has no internet access in this run as I've 
swapped the VM interfaces around, so I can connect from my PC to the VM 
to copy off infomation for this email.
So errors about network unreachable are only due to this setup.

Thanks,
Mark

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[LEAF <le...@pa...>]

Hi Erich,

On 1/04/2026 2:35 am, Erich Titl wrote:
>
> Right, so wireguard loads the modules dynamically. I am pretty sure it 
> uses the same kernel modules as shorewall to handle iptables.

Wireguard does try to load the modules it needs. I don't know if 
shorewall loads everything wireguard needs, but I can test this at a 
later time.

>>
>> Of course I needed to add /etc/init.d/wireguard in the local files 
>> list so the changes get saved to configdb.lrp so they survive a reboot.
>> Maybe this change can be made to wireguard.lrp going forward by the 
>> LEAF developers so this isn't necessary for others to do in the future.
>
> I would believe this is an easy modification which will not hurt.
>
This will allow the user to use the init script to start / stop 
wireguard with or without shorewall. (Even though wireguard still won't 
start - see below)

> My experience is/was that it is the safest way to start shorewall in 
> any case.
>
This only became a problem because I set shorewall to not start in 
/etc/shorewall/shorewall.conf and then used shorewall start / stop 
afterwords.
I haven't play with LEAF since 2017 ish, so some lessons have been 
forgotten.

> I still don't understand the openresolv issue. The way I understand it 
> manages resolv.conf and apparently it allows applications to manage 
> /etc/resolv.conf at will.
>
The openresolv issue is actually a "resolvconf" program missing issue.

With the current version of wireguard.lrp you cannot start wireguard 
with the init script, even if all the modules are loaded. This is 
because /etc/init.d/wireguard start() calls "wg-quick", and the 
"wg-quick" script has been updated from around 2020 to now call 
"resolvconf".
The script "resolvconf" is missing, so the process fails and the link is 
deleted.

 From my earlier post (some bits deleted for this post)

    router# /etc/init.d/wireguard restart
    Starting wireguard VPN server on interface wg0
    [#] ip link add wg0 type wireguard
    [#] wg setconf wg0 /dev/fd/63
    [#] ip -4 address add 10.2.0.2/32 dev wg0
    [#] ip link set mtu 1420 up dev wg0

    [#] resolvconf -a wg0 -m 0 -x
    /usr/bin/wg-quick: line 32: resolvconf: command not found

    [#] ip link delete dev wg0

So I see there are 3 solutions,

1. Make and openresolv.lrp available
     - this contains the "resolvconf" script and based on what I see in 
the Debian packages, appears to be just scripts, so no compiling to 
worry about. (I'm not a developer, so it could be harder than it looks)

2. Add the script "resolvconf" to the wireguard package
    - though I don't believe "resolvconf" is part of the upstream 
wireguard code base (but I could be wrong) which would then make a bit 
of a mixed package (maybe this isn't a problem, again not a developer)

3. Update the LEAF user manual to show how to set this up without using 
the /etc/init.d/wireguard.
     - while the user manual talks about wireguard itself, there is no 
guidance on how to actually implement it. So it's fair to assume as a 
user, you just run the init script and everything will be sweet.

So as it stands, /etc/init.d/wireguard run() will call wg-quick which 
will fail, because wg-quick wants resolvconf, which doesn't exist.

Hope this explains the problem and why the openresolv package or 
resolvconf program is necessary.

Thanks,
Mark

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[Erich T. <eri...@th...>]

Hi Mark

Am 31.03.2026 um 14:44 schrieb LEAF:
> Hi Erich,
> 
> Quick update on today's play
> 
> On 31/03/2026 9:53 pm, Erich Titl wrote:
>>
>> modprobe will not do this. I _believe_ most of the modules are loaded 
>> when you start shorewall, which itself calls mount_modules/ 
>> umount_modules to make the modules available.
>>
> I found if I modify the /etc/init.d/wireguard start function from:
> 
>     $WG_QUICK up $INTERFACE
> 
> to:
> 
>     /usr/sbin/mount_modules
>     $WG_QUICK up $INTERFACE
>     /usr/sbin/umount_modules
> 
> All the module names I had to add to /etc/modules for wireguard can go 
> away. As long as you don't run wg-quick directly on the first start and 
> always use the init.d script for this. If /etc/default/wireguard has 
> start set to Yes, this will just happen and load all the needed 
> wireguard modules.

Right, so wireguard loads the modules dynamically. I am pretty sure it 
uses the same kernel modules as shorewall to handle iptables.

> 
> Of course I needed to add /etc/init.d/wireguard in the local files list 
> so the changes get saved to configdb.lrp so they survive a reboot.
> Maybe this change can be made to wireguard.lrp going forward by the LEAF 
> developers so this isn't necessary for others to do in the future.

I would believe this is an easy modification which will not hurt.

> 
>> I _guess_ in the "standard" set up LEAF is using shorewall as its 
>> iptables set_up utility. If your installation does not use this you 
>> may have to install the kernel modules yourself. Your method to add it 
>> to etc/modules might be inconvenient but most intuitive.
>>
> I'm using shorewall as well to handle the masquerading / SNAT of the 
> traffic from Mint VM through the router VM to the VPN link. Though I 
> haven't got that working yet. All traffic from the router VM to the VPN 
> link dies when shorewall is started, so I don't have something setup 
> right. But I did discover I have to use init.d scripts to start 
> shorewall in the first instance so the modules that shorewall needs get 
> loaded after a reboot instead of using "shorewall start" directly.

My experience is/was that it is the safest way to start shorewall in any 
case.

> 
>>
>> Look above, I somehow guessed it. I believe once you have shorewall up 
>> and running your troubles will just disappear.
>>
> Except you need the wireguard link created before shorewall can use it 
> as far as I know. I'm not creating it via the interfaces file, so it 
> doesn't exist until wg-quick creates it.

> 
> After all this, it would still be nice to have an openresolv.lrp so 
> future users don't have to make all the same discoveries and back them 
> up to configdb.lrp

I still don't understand the openresolv issue. The way I understand it 
manages resolv.conf and apparently it allows applications to manage 
/etc/resolv.conf at will.

If you are using dynamic addresses this ist done most of the time by 
your dhcp client process and you don't want to mess too much with it. 
For static addresses I see little advantage to just edit 
/etc/resolv.conf manually as basically it just uses a different notation 
and another configuration file to maintain. YMMV

cheers

ET
-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[Robert K C. J. -I. F. D. Corp. <bco...@in...>]

   I'm fairly sure you can mark that interface as "optional" in shorewall
   interfaces to work around that.  Shorewall should start regardless of
   whether it is there or not.

   On 3/31/2026 8:44:51 AM, LEAF wrote:

     Except you need the wireguard link created before shorewall can use
     it as far as I know.

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[1]su...@in...

References

   1. mailto:su...@in...

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[LEAF <le...@pa...>]

Hi Erich,

Quick update on today's play

On 31/03/2026 9:53 pm, Erich Titl wrote:
>
> modprobe will not do this. I _believe_ most of the modules are loaded 
> when you start shorewall, which itself calls 
> mount_modules/umount_modules to make the modules available.
>
I found if I modify the /etc/init.d/wireguard start function from:

    $WG_QUICK up $INTERFACE

to:

    /usr/sbin/mount_modules
    $WG_QUICK up $INTERFACE
    /usr/sbin/umount_modules

All the module names I had to add to /etc/modules for wireguard can go 
away. As long as you don't run wg-quick directly on the first start and 
always use the init.d script for this. If /etc/default/wireguard has 
start set to Yes, this will just happen and load all the needed 
wireguard modules.

Of course I needed to add /etc/init.d/wireguard in the local files list 
so the changes get saved to configdb.lrp so they survive a reboot.
Maybe this change can be made to wireguard.lrp going forward by the LEAF 
developers so this isn't necessary for others to do in the future.

> I _guess_ in the "standard" set up LEAF is using shorewall as its 
> iptables set_up utility. If your installation does not use this you 
> may have to install the kernel modules yourself. Your method to add it 
> to etc/modules might be inconvenient but most intuitive.
>
I'm using shorewall as well to handle the masquerading / SNAT of the 
traffic from Mint VM through the router VM to the VPN link. Though I 
haven't got that working yet. All traffic from the router VM to the VPN 
link dies when shorewall is started, so I don't have something setup 
right. But I did discover I have to use init.d scripts to start 
shorewall in the first instance so the modules that shorewall needs get 
loaded after a reboot instead of using "shorewall start" directly.

>
> Look above, I somehow guessed it. I believe once you have shorewall up 
> and running your troubles will just disappear.
>
Except you need the wireguard link created before shorewall can use it 
as far as I know. I'm not creating it via the interfaces file, so it 
doesn't exist until wg-quick creates it.

After all this, it would still be nice to have an openresolv.lrp so 
future users don't have to make all the same discoveries and back them 
up to configdb.lrp

Thanks,
Mark

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[Erich T. <eri...@th...>]

Hi Mark

Am 31.03.2026 um 02:10 schrieb LEAF:
> Hi ET,
> 
> This is going to be a bit more than a "Why do I want this" and more a 
> how did I get to wanting this.
> 
> I found this tread on the leaf-user mail list:
> 
> Re: [leaf-user] wireguard and shorewall From: John S. <jo...@sa...> - 
> 2020-12-05 13:02:01 with some back and forth with KP

Mhhh... I have not seen this.
Basically my own setup works without any additional quirks.

....

> So resolvconf is happy, but we have a bunch of missing modules that 
> appear to not be able to be loaded by modprobe.
> Probably because the modules is a squash-fs now and needs to be added 
> with /usr/sbin/mount_modules before modprobe or installed via /usr/sbin/ 
> install_modules. I don't know how to make modprobe do automatically this.

modprobe will not do this. I _believe_ most of the modules are loaded 
when you start shorewall, which itself calls 
mount_modules/umount_modules to make the modules available.

> 
> So by a process of elimination I put all the needed module names in 
> the /etc/modules:
> 
>     # IP tables for wireguard
>     #
> 
>     # Common IPV4 and IPV6
>     x_tables
>     xt_connmark
>     xt_comment
>     xt_mark
>     xt_addrtype
>     nf_conntrack
>     nf_defrag_ipv4
>     nf_defrag_ipv6
>     libcrc32c
> 
>     # IPV4
>     #
>     ip_tables
>     iptable_raw
>     iptable_filter
>     iptable_mangle
> 
>     # IPV6
>     #
>     ip6_tables
>     ip6table_raw
>     ip6table_filter
>     ip6table_mangle
> 
> But I'm thinking there must be an easier way, that I just don't know yet.

I _guess_ in the "standard" set up LEAF is using shorewall as its 
iptables set_up utility. If your installation does not use this you may 
have to install the kernel modules yourself. Your method to add it to 
etc/modules might be inconvenient but most intuitive.

> 
> Which finally gives me:
> 
>     router# /etc/init.d/wireguard restart
>     Stopping wireguard VPN server on interface wg0
>     [#] ip -4 rule delete table 51820
>     [#] ip -4 rule delete table main suppress_prefixlength 0
>     [#] ip -6 rule delete table 51820
>     [#] ip -6 rule delete table main suppress_prefixlength 0
>     [#] ip link delete dev wg0
>     [#] resolvconf -d wg0 -f
>     [#] iptables-restore -n
>     [#] ip6tables-restore -n
>     Starting wireguard VPN server on interface wg0
>     [#] ip link add wg0 type wireguard
>     [#] wg setconf wg0 /dev/fd/63
>     [#] ip -4 address add 10.2.0.2/32 dev wg0
>     RTNETLINK answers: Network is unreachable
>     [#] ip link set mtu 1420 up dev wg0
>     [#] resolvconf -a wg0 -m 0 -x
>     [#] wg set wg0 fwmark 51820
>     [#] ip -6 route add ::/0 dev wg0 table 51820
>     [#] ip -6 rule add not fwmark 51820 table 51820
>     [#] ip -6 rule add table main suppress_prefixlength 0
>     [#] ip6tables-restore -n
>     [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
>     [#] ip -4 rule add not fwmark 51820 table 51820
>     [#] ip -4 rule add table main suppress_prefixlength 0
>     [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
>     [#] iptables-restore -n
> 
>   and resolv.conf is automatically updated:
> 
>     # Generated by resolvconf
>     # Included file /etc/resolv.conf.head starts here
>     # Included file /etc/resolv.conf.head ends here
>     nameserver 10.2.0.1
>     # Included file /etc/resolv.conf.tail starts here
>     # Included file /etc/resolv.conf.tail ends here
> 
> I just need to connect the VM back to the internet via the CPE and make 
> sure the VPN link works, then tackle the shorewall part of the equation. 
> I currently have shorewall disabled from starting.
 >

Look above, I somehow guessed it. I believe once you have shorewall up 
and running your troubles will just disappear.

> Hope this wasn't too draw out,
> Mark
> 
...

cheers

ET


-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[LEAF <le...@pa...>]

Hi ET,

This is going to be a bit more than a "Why do I want this" and more a 
how did I get to wanting this.

I found this tread on the leaf-user mail list:

Re: [leaf-user] wireguard and shorewall From: John S. <jo...@sa...> - 
2020-12-05 13:02:01 with some back and forth with KP

> gatekeeper# /etc/init.d/wireguard restart > Stopping wireguard VPN server on interface wg0 > [#] ip 
link delete dev wg0 > Starting wireguard VPN server on interface wg0
> [#] ip link add wg0 type wireguard
> [#] wg setconf wg0 /dev/fd/63
> [#] ip -4 address add 192.168.17.1/24 dev wg0
> [#] ip link set mtu 1420 up dev wg0
> 

When I do the same thing, I get:

    router# /etc/init.d/wireguard restart
    Stopping wireguard VPN server on interface wg0
    wg-quick: `wg0' is not a WireGuard interface
    Starting wireguard VPN server on interface wg0
    [#] ip link add wg0 type wireguard
    [#] wg setconf wg0 /dev/fd/63
    [#] ip -4 address add 10.2.0.2/32 dev wg0
    RTNETLINK answers: Network is unreachable
    [#] ip link set mtu 1420 up dev wg0
    [#] resolvconf -a wg0 -m 0 -x
    /usr/bin/wg-quick: line 32: resolvconf: command not found
    [#] ip link delete dev wg0

Ignoring the following as ip link hasn't happened yet and eth0 has no 
net access at the moment on the VM:

    wg-quick: `wg0' is not a WireGuard interface
    RTNETLINK answers: Network is unreachable

But wg-quick has changed and now tries to set resolv.conf using the 
script resolvconf

    [#] resolvconf -a wg0 -m 0 -x
    /usr/bin/wg-quick: line 32: resolvconf: command not found

So hunting down where resolvconf comes from using the Debian package 
archive I found:

File 
<https://packages.debian.org/search?suite=trixie&arch=any&mode=exactfilename&searchon=contents&keywords=resolvconf&sort_by=file> 
	Packages 
<https://packages.debian.org/search?suite=trixie&arch=any&mode=exactfilename&searchon=contents&keywords=resolvconf&sort_by=pkg> 

/etc/dhcp/dhclient-enter-hooks.d/resolvconf 	openresolv 
<https://packages.debian.org/trixie/openresolv>,resolvconf 
<https://packages.debian.org/trixie/resolvconf>
/etc/init.d/resolvconf 	resolvconf 
<https://packages.debian.org/trixie/resolvconf>
/etc/network/if-down.d/resolvconf 	openresolv 
<https://packages.debian.org/trixie/openresolv>,resolvconf 
<https://packages.debian.org/trixie/resolvconf>
/sbin/resolvconf 	openresolv 
<https://packages.debian.org/trixie/openresolv>[mipsel],resolvconf 
<https://packages.debian.org/trixie/resolvconf>[mipsel]
/usr/sbin/resolvconf 	openresolv 
<https://packages.debian.org/trixie/openresolv>[not mipsel],resolvconf 
<https://packages.debian.org/trixie/resolvconf>[not 
mipsel],systemd-resolved 
<https://packages.debian.org/trixie/systemd-resolved>[not mips64el, mipsel]
/usr/share/bash-completion/completions/resolvconf 	bash-completion 
<https://packages.debian.org/trixie/bash-completion>
/usr/share/lintian/overrides/resolvconf 	resolvconf 
<https://packages.debian.org/trixie/resolvconf>

So as proof of concept, I downloaded the openresolv.deb, extracted it, 
copied the files to the router with sftp then chmod the scripts to 755.
Finally placed the list of files from the openresolv deb into the local 
packages list of files to be saved (ignoring all the /usr/share/* stuff) 
, so it survives a reboot.

    /etc/dhcp/dhclient-enter-hooks.d/resolvconf
    /etc/network/if-down.d/resolvconf
    /etc/network/if-up.d/000resolvconf
    /etc/ppp/ip-down.d/000resolvconf
    /etc/ppp/ip-up.d/000resolvconf
    /etc/resolvconf.conf
    /usr/lib/resolvconf/dnsmasq
    /usr/lib/resolvconf/libc
    /usr/lib/resolvconf/libc.d/avahi-daemon
    /usr/lib/resolvconf/libc.d/mdnsd
    /usr/lib/resolvconf/named
    /usr/lib/resolvconf/pdns_recursor
    /usr/lib/resolvconf/pdnsd
    /usr/lib/resolvconf/unbound
    /usr/sbin/resolvconf

Which results in:

    router# /etc/init.d/wireguard restart
    Stopping wireguard VPN server on interface wg0
    wg-quick: `wg0' is not a WireGuard interface
    Starting wireguard VPN server on interface wg0
    [#] ip link add wg0 type wireguard
    [#] wg setconf wg0 /dev/fd/63
    [#] ip -4 address add 10.2.0.2/32 dev wg0
    RTNETLINK answers: Network is unreachable
    [#] ip link set mtu 1420 up dev wg0
    [#] resolvconf -a wg0 -m 0 -x
    [#] wg set wg0 fwmark 51820
    [#] ip -6 route add ::/0 dev wg0 table 51820
    [#] ip -6 rule add not fwmark 51820 table 51820
    [#] ip -6 rule add table main suppress_prefixlength 0
    [#] ip6tables-restore -n
    modprobe: can't open 'modules.dep': No such file or directory
    ip6tables-restore v1.8.8 (legacy): ip6tables-restore: unable to
    initialize table 'raw'

    Error occurred at line: 1
    Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more
    information.
    [#] resolvconf -d wg0 -f
    [#] ip -6 rule delete table 51820
    [#] ip -6 rule delete table main suppress_prefixlength 0
    [#] ip link delete dev wg0

So resolvconf is happy, but we have a bunch of missing modules that 
appear to not be able to be loaded by modprobe.
Probably because the modules is a squash-fs now and needs to be added 
with /usr/sbin/mount_modules before modprobe or installed via 
/usr/sbin/install_modules. I don't know how to make modprobe do 
automatically this.

So by a process of elimination I put all the needed module names in the 
/etc/modules:

    # IP tables for wireguard
    #

    # Common IPV4 and IPV6
    x_tables
    xt_connmark
    xt_comment
    xt_mark
    xt_addrtype
    nf_conntrack
    nf_defrag_ipv4
    nf_defrag_ipv6
    libcrc32c

    # IPV4
    #
    ip_tables
    iptable_raw
    iptable_filter
    iptable_mangle

    # IPV6
    #
    ip6_tables
    ip6table_raw
    ip6table_filter
    ip6table_mangle

But I'm thinking there must be an easier way, that I just don't know yet.

Which finally gives me:

    router# /etc/init.d/wireguard restart
    Stopping wireguard VPN server on interface wg0
    [#] ip -4 rule delete table 51820
    [#] ip -4 rule delete table main suppress_prefixlength 0
    [#] ip -6 rule delete table 51820
    [#] ip -6 rule delete table main suppress_prefixlength 0
    [#] ip link delete dev wg0
    [#] resolvconf -d wg0 -f
    [#] iptables-restore -n
    [#] ip6tables-restore -n
    Starting wireguard VPN server on interface wg0
    [#] ip link add wg0 type wireguard
    [#] wg setconf wg0 /dev/fd/63
    [#] ip -4 address add 10.2.0.2/32 dev wg0
    RTNETLINK answers: Network is unreachable
    [#] ip link set mtu 1420 up dev wg0
    [#] resolvconf -a wg0 -m 0 -x
    [#] wg set wg0 fwmark 51820
    [#] ip -6 route add ::/0 dev wg0 table 51820
    [#] ip -6 rule add not fwmark 51820 table 51820
    [#] ip -6 rule add table main suppress_prefixlength 0
    [#] ip6tables-restore -n
    [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
    [#] ip -4 rule add not fwmark 51820 table 51820
    [#] ip -4 rule add table main suppress_prefixlength 0
    [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
    [#] iptables-restore -n

  and resolv.conf is automatically updated:

    # Generated by resolvconf
    # Included file /etc/resolv.conf.head starts here
    # Included file /etc/resolv.conf.head ends here
    nameserver 10.2.0.1
    # Included file /etc/resolv.conf.tail starts here
    # Included file /etc/resolv.conf.tail ends here

I just need to connect the VM back to the internet via the CPE and make 
sure the VPN link works, then tackle the shorewall part of the equation. 
I currently have shorewall disabled from starting.

Hope this wasn't too draw out,
Mark

On 30/03/2026 10:47 pm, Erich Titl wrote:
> Hi
>
> Am 30.03.2026 um 03:26 schrieb LEAF:
>> Hello all,
>>
>> It's been quite a while since I've used Bering-uClibc and been on the 
>> list. Hope everyone is well.
>>
>> As background, I'm setting Linux Mint booting off a CD image on a 
>> VMWare 17 VM to allow to access the internet using wireguard running 
>> on another VMWare 17 VM using Bering-uClibc_7.2.2_x86_64 
>> _isolinux_vga.iso installed on a hard drive and booting via syslinux.
>>
>> Currently I have Linux Mint VM -> Bering-uClibc VM -> CPE Router -> 
>> Internet = works fine without wireguard.
>>
>> I tried setting this up with Bering- 
>> uClibc_7.5.2_x86_64_isolinux_vga.iso, but ran into a problems with 
>> trying to install syslinux on the hard drive where it kept reporting 
>> the hard drive was busy. So I went back to 7.2.2 as I already had 
>> this image. I'll get some proper 7.5.2 error messages for this at a 
>> later date when I try again.
>>
>> Anyway, when running /etc/init.d/wireguard start I get a message from 
>> wireguard saying resolvconf wasn't found and the VPN link isn't 
>> setup. I looked at the Debian packages to see where resolvconf comes 
>> from and found it is located in openresolv_3.13.2-3_all.deb. Looking 
>> at the files in openresolv they all appear to be just scripts.
>>
>> So I'm wondering if the good people at Bering-uClibc could make an 
>> openresolv.lrp and add this to the LEAF system going forward.
>
> I am running wireguard on various LEAF boxes without problems. Just to 
> let me understand, why would openresolv be needed by wireguard? If I 
> understand you correctly then wireguard is probably looking for 
> resolv.conf which is built by one of the DNS packages available.
>
> Then if your setup is not dynamic you could always build your own 
> resolv.conf manually.
>
> cheers
> ET
>

Re: [leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[Erich T. <eri...@th...>]

Hi

Am 30.03.2026 um 03:26 schrieb LEAF:
> Hello all,
> 
> It's been quite a while since I've used Bering-uClibc and been on the 
> list. Hope everyone is well.
> 
> As background, I'm setting Linux Mint booting off a CD image on a VMWare 
> 17 VM to allow to access the internet using wireguard running on another 
> VMWare 17 VM using Bering-uClibc_7.2.2_x86_64 
> _isolinux_vga.iso installed on a hard drive and booting via syslinux.
> 
> Currently I have Linux Mint VM -> Bering-uClibc VM -> CPE Router -> 
> Internet = works fine without wireguard.
> 
> I tried setting this up with Bering- 
> uClibc_7.5.2_x86_64_isolinux_vga.iso, but ran into a problems with 
> trying to install syslinux on the hard drive where it kept reporting the 
> hard drive was busy. So I went back to 7.2.2 as I already had this 
> image. I'll get some proper 7.5.2 error messages for this at a later 
> date when I try again.
> 
> Anyway, when running /etc/init.d/wireguard start I get a message from 
> wireguard saying resolvconf wasn't found and the VPN link isn't setup. I 
> looked at the Debian packages to see where resolvconf comes from and 
> found it is located in openresolv_3.13.2-3_all.deb. Looking at the files 
> in openresolv they all appear to be just scripts.
> 
> So I'm wondering if the good people at Bering-uClibc could make an 
> openresolv.lrp and add this to the LEAF system going forward.

I am running wireguard on various LEAF boxes without problems. Just to 
let me understand, why would openresolv be needed by wireguard? If I 
understand you correctly then wireguard is probably looking for 
resolv.conf which is built by one of the DNS packages available.

Then if your setup is not dynamic you could always build your own 
resolv.conf manually.

cheers
ET

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

[leaf-user] Can openresolv.lrp be added to Bering-uClibc to provide resolvconf for wireguard

[LEAF <le...@pa...>]

Hello all,

It's been quite a while since I've used Bering-uClibc and been on the 
list. Hope everyone is well.

As background, I'm setting Linux Mint booting off a CD image on a VMWare 
17 VM to allow to access the internet using wireguard running on another 
VMWare 17 VM using Bering-uClibc_7.2.2_x86_64 
_isolinux_vga.iso installed on a hard drive and booting via syslinux.

Currently I have Linux Mint VM -> Bering-uClibc VM -> CPE Router -> 
Internet = works fine without wireguard.

I tried setting this up with 
Bering-uClibc_7.5.2_x86_64_isolinux_vga.iso, but ran into a problems 
with trying to install syslinux on the hard drive where it kept 
reporting the hard drive was busy. So I went back to 7.2.2 as I already 
had this image. I'll get some proper 7.5.2 error messages for this at a 
later date when I try again.

Anyway, when running /etc/init.d/wireguard start I get a message from 
wireguard saying resolvconf wasn't found and the VPN link isn't setup. I 
looked at the Debian packages to see where resolvconf comes from and 
found it is located in openresolv_3.13.2-3_all.deb. Looking at the files 
in openresolv they all appear to be just scripts.

So I'm wondering if the good people at Bering-uClibc could make an 
openresolv.lrp and add this to the LEAF system going forward.

Thanks in advance,

Mark

Re: [leaf-user] 7.5.1 iso won't fully load

[Jim M. <jv...@ho...>]

Hi Rob,

You might try "usb_wait=6" in syslinux.cfg to get it to finish loading.  
I had to make a couple tweaks to

get it to load on a faster machine.  (see my post Sept 2025 [leaf-user] 
7.5.1-rc1 and m720q tiny pc)

cheers

Jim

Re: [leaf-user] 7.5.1 iso won't fully load

[Erich T. <eri...@th...>]

Hi Rob

Am 13.02.2026 um 22:27 schrieb Rob Ogle via leaf-user:
> I have pulled down the latest 7.5.1 iso, loaded to a usb, and it won't
> load fully into LEAF.
> 
> It gives an error saying that the LRP variable is empty or not set.
> 
>   
> 
> It lets me to the console.
> 
> I mounted the drive and looked at the leaf.cfg file.
> 
> I noticed that it was changed back to using a single line variable for LRP
> rather than concatenating the variable like in some previous versions.
> 
>   
> 
> I have tried multiple usb drives and have tried booting it on multiple
> machines.
> 
>   
> 
> I also pulled down the syslinx tar and went through the process of running
> syslinux and copying the files over- which is how I have always done it in
> the past for previous versions.
> 
> I get the same results.
> 
>   
> 
> I was hoping to try out the new gee-whizzy option of booting to the usb
> and loading it to the hard drive is the reason I went the ISO route to
> start.
> 
>   
> 
> I'm not sure where to go next.
> 
>   
> 
> Any ideas?
> 

I looked into leaf.cfg on the iso file and at the first glimpse it looks 
OK which normally means that it is not parsed at all.
Then I looked into isolinux.cfg and again the LEAFCFG parameter looks good.

That you get booted into a restricted console means that the kernel gets 
loaded and initrd appears to not have read the LRP parameters from leaf.cfg.

The initrd.lrp checksum matches the the one in the package directory for 
the x486 architecture, so this appears correct too.

In the root directory of the system there should be a number of files 
with the suffix .err which you can inspect and see if there is something 
fishy.

ls /*.err
/linuxrc.err      /loadmodules.err  /loadpkg.err

isolinux.cfg does not use UUID to specify the location of the leaf.cfg file.

cheers

ET

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] 7.5.1 iso won't fully load

[marko <le...@me...>]

I have not seen this error myself.  

one thing to check is the syslinux configuration
in /syslinux/syslinux.cfg  there is a reference to the UUID of the volume 
containing Leaf lrp string.   make sure that is correct.

good luck
Marko


On Saturday, 14 February 2026 8:27:01 AM AEDT Rob Ogle via leaf-user wrote:
> I have pulled down the latest 7.5.1 iso, loaded to a usb, and it won't
> load fully into LEAF.
> 
> It gives an error saying that the LRP variable is empty or not set.
> 
> 
> 
> It lets me to the console.
> 
> I mounted the drive and looked at the leaf.cfg file.
> 
> I noticed that it was changed back to using a single line variable for LRP
> rather than concatenating the variable like in some previous versions.
> 
> 
> 
> I have tried multiple usb drives and have tried booting it on multiple
> machines.
> 
> 
> 
> I also pulled down the syslinx tar and went through the process of running
> syslinux and copying the files over- which is how I have always done it in
> the past for previous versions.
> 
> I get the same results.
> 
> 
> 
> I was hoping to try out the new gee-whizzy option of booting to the usb
> and loading it to the hard drive is the reason I went the ISO route to
> start.
> 
> 
> 
> I'm not sure where to go next.
> 
> 
> 
> Any ideas?
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/

[leaf-user] 7.5.1 iso won't fully load

[Rob O. <ro...@ci...>]

I have pulled down the latest 7.5.1 iso, loaded to a usb, and it won't
load fully into LEAF. 

It gives an error saying that the LRP variable is empty or not set. 

 

It lets me to the console. 

I mounted the drive and looked at the leaf.cfg file. 

I noticed that it was changed back to using a single line variable for LRP
rather than concatenating the variable like in some previous versions. 

 

I have tried multiple usb drives and have tried booting it on multiple
machines. 

 

I also pulled down the syslinx tar and went through the process of running
syslinux and copying the files over- which is how I have always done it in
the past for previous versions. 

I get the same results. 

 

I was hoping to try out the new gee-whizzy option of booting to the usb
and loading it to the hard drive is the reason I went the ISO route to
start. 

 

I'm not sure where to go next. 

 

Any ideas? 

 

 

Re: [leaf-user] 7.5.1 and logs (solved)

[Erich T. <eri...@th...>]

Hi Boris

Am 18.01.2026 um 20:44 schrieb Boris via leaf-user:
> Hej Erich,
...

>>
>> So maybe it is enough to just comment it out and the message is just a 
>> warning.
> 
> I can add the information, that the mentioned line is not present on 
> both boxes here. Might be some forensic work to find out where the line 
> is from and what the file belongs to....
> 

OK.. that is rather easy.
I checked the releases from 7.0.0 to 7.5.0. On every release the plugin 
is present in ulogd.conf, at least in repo/ulogd. The I checked 
buildtool.mk

commit f1a24e44c786f1f8b9d16e2b7299756c2bc07ad9
             <File>
                 Source          = usr/lib/ulogd/ulogd_inppkt_ULOG.so
                 Filename        = usr/lib/ulogd/ulogd_inppkt_ULOG.so
                 Type            = binary
                 Permissions = 755
             </File>

commit 5068d91c042768709ae647d4a1b4efca485a0fc5
Author: kapeka <ka...@us...>
Date:   Sat Jun 14 15:03:44 2025 +0200

     ulogd: update to upstream version 2.0.9

     fix linking ulogd_inppkt_NFLOG.so with libmnl - without ulogd fails 
to start

Here the incriminating plugin goes amiss, but is also removed from 
ulogd.conf. This makes me believe that it is not needed for ulogd to run.

ulogd.conf is a configuration file which may have been taken over from 
an earlier release which still had the plugin. So I commented it out and 
restarted ulogd without the plugin. It appears that shorewall is still 
logging even without this plugin being present in ulogd.conf. I guess 
this proves that the plugin is not necessary for the operation of ulogd 
in our environment but it also shows that such a missing plugin can 
hamper ulogd.

So I guess we can forget this issue and just call it a heads-up should 
anyone face a problem starting ulogd.

cheers

ET

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] 7.5.1 and logs

[Boris <bo...@ca...>]

Hej Erich,

Am 18.01.26 um 19:08 schrieb Erich Titl:
> Hi Boris
> 
> Am 18.01.2026 um 16:15 schrieb Boris via leaf-user:
>> Hej Erich again,
>>
>> Am 18.01.26 um 14:51 schrieb Boris via leaf-user:
>>> Hej Erich,
>>>
>>> happy new year, even though it is almost not longer new....
>>>
>>> Am 08.01.26 um 18:42 schrieb Erich Titl:
>>>> Hi Folks
>>>>
>>>> I am running a 7.5.1 on an Alix and cannot get ulogd up and running.
>>>> The logfile tells me
>>>>
>>>> Thu Jan  8 16:42:01 2026 <7> ulogd.c:779 load_plugin: '/usr/lib/ 
>>>> ulogd/ ulogd_inppkt_ULOG.so': File not found
>>>>
>>>> and indeed this file is mising in ulogd.lrp
>>>
>>> I did that upgrade to 7.5.1 (x86_64 on a APU3) just a few minutes ago 
>>> an I can confirm that file is missing.
>>
>> Exactly same situation as I updated my second box (Alix with of course 
>> geode architecture).
> 
> Maybe it is not really necessary, I found hardly any documentation on 
> the ulogd plugins. But it is in ulogd.conf
> 
> ######################################################################
> # PLUGIN OPTIONS
> ######################################################################
> 
> # We have to configure and load all the plugins we want to use
> 
> # general rules:
> # 1. load the plugins _first_ from the global section
> # 2. options for each plugin in seperate section below
> 
> 
> plugin="/usr/lib/ulogd/ulogd_inppkt_NFLOG.so"
> plugin="/usr/lib/ulogd/ulogd_inppkt_ULOG.so"
> #plugin="/usr/lib/ulogd/ulogd_inppkt_UNIXSOCK.so"
> plugin="/usr/lib/ulogd/ulogd_inpflow_NFCT.so"
> plugin="/usr/lib/ulogd/ulogd_filter_IFINDEX.so"
> plugin="/usr/lib/ulogd/ulogd_filter_IP2STR.so"
> 
> So maybe it is enough to just comment it out and the message is just a 
> warning.

I can add the information, that the mentioned line is not present on 
both boxes here. Might be some forensic work to find out where the line 
is from and what the file belongs to....

> In my case I added it to the respective directory, the error went away 
> and ulogd started logging.

Regards,


Boris

Re: [leaf-user] 7.5.1 and logs

[Erich T. <eri...@th...>]

Hi Boris

Am 18.01.2026 um 16:15 schrieb Boris via leaf-user:
> Hej Erich again,
> 
> Am 18.01.26 um 14:51 schrieb Boris via leaf-user:
>> Hej Erich,
>>
>> happy new year, even though it is almost not longer new....
>>
>> Am 08.01.26 um 18:42 schrieb Erich Titl:
>>> Hi Folks
>>>
>>> I am running a 7.5.1 on an Alix and cannot get ulogd up and running.
>>> The logfile tells me
>>>
>>> Thu Jan  8 16:42:01 2026 <7> ulogd.c:779 load_plugin: '/usr/lib/ 
>>> ulogd/ ulogd_inppkt_ULOG.so': File not found
>>>
>>> and indeed this file is mising in ulogd.lrp
>>
>> I did that upgrade to 7.5.1 (x86_64 on a APU3) just a few minutes ago 
>> an I can confirm that file is missing.
> 
> Exactly same situation as I updated my second box (Alix with of course 
> geode architecture).

Maybe it is not really necessary, I found hardly any documentation on 
the ulogd plugins. But it is in ulogd.conf

######################################################################
# PLUGIN OPTIONS
######################################################################

# We have to configure and load all the plugins we want to use

# general rules:
# 1. load the plugins _first_ from the global section
# 2. options for each plugin in seperate section below


plugin="/usr/lib/ulogd/ulogd_inppkt_NFLOG.so"
plugin="/usr/lib/ulogd/ulogd_inppkt_ULOG.so"
#plugin="/usr/lib/ulogd/ulogd_inppkt_UNIXSOCK.so"
plugin="/usr/lib/ulogd/ulogd_inpflow_NFCT.so"
plugin="/usr/lib/ulogd/ulogd_filter_IFINDEX.so"
plugin="/usr/lib/ulogd/ulogd_filter_IP2STR.so"

So maybe it is enough to just comment it out and the message is just a 
warning.

In my case I added it to the respective directory, the error went away 
and ulogd started logging.

cheers

ET

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] 7.5.1 and logs

[Boris <bo...@ca...>]

Hej Erich again,

Am 18.01.26 um 14:51 schrieb Boris via leaf-user:
> Hej Erich,
> 
> happy new year, even though it is almost not longer new....
> 
> Am 08.01.26 um 18:42 schrieb Erich Titl:
>> Hi Folks
>>
>> I am running a 7.5.1 on an Alix and cannot get ulogd up and running.
>> The logfile tells me
>>
>> Thu Jan  8 16:42:01 2026 <7> ulogd.c:779 load_plugin: '/usr/lib/ulogd/ 
>> ulogd_inppkt_ULOG.so': File not found
>>
>> and indeed this file is mising in ulogd.lrp
> 
> I did that upgrade to 7.5.1 (x86_64 on a APU3) just a few minutes ago an 
> I can confirm that file is missing.

Exactly same situation as I updated my second box (Alix with of course 
geode architecture).

Ahoi,


Boris

Re: [leaf-user] 7.5.1 and logs

[Boris <bo...@ca...>]

Hej Erich,

happy new year, even though it is almost not longer new....

Am 08.01.26 um 18:42 schrieb Erich Titl:
> Hi Folks
> 
> I am running a 7.5.1 on an Alix and cannot get ulogd up and running.
> The logfile tells me
> 
> Thu Jan  8 16:42:01 2026 <7> ulogd.c:779 load_plugin: '/usr/lib/ulogd/ 
> ulogd_inppkt_ULOG.so': File not found
> 
> and indeed this file is mising in ulogd.lrp

I did that upgrade to 7.5.1 (x86_64 on a APU3) just a few minutes ago an 
I can confirm that file is missing.

But ulogd seems running

# ps | grep ulog
  3191 root      1792 S<   /usr/sbin/ulogd -d

and /var/lod/ulogd.log is zero bytes.

So everything seems to be all right even without this file?

> 
> I did som digging in the repo and could not find the file in 
> buildtool.cfg so I assume it got lost sometime.
> 
> I have a development environment and copied the missing object file to
> /usr/lib/ulogd. Then restarted ulogd and the incriminating message did 
> not show up in ulogd.log again.
> 
> Anyone knows why this file appears to be missing?
> 
> cheers
> ET

Cheerio,


Boris

[leaf-user] 7.5.1 and logs

[Erich T. <eri...@th...>]

Hi Folks

I am running a 7.5.1 on an Alix and cannot get ulogd up and running.
The logfile tells me

Thu Jan  8 16:42:01 2026 <7> ulogd.c:779 load_plugin: 
'/usr/lib/ulogd/ulogd_inppkt_ULOG.so': File not found

and indeed this file is mising in ulogd.lrp

I did som digging in the repo and could not find the file in 
buildtool.cfg so I assume it got lost sometime.

I have a development environment and copied the missing object file to
/usr/lib/ulogd. Then restarted ulogd and the incriminating message did 
not show up in ulogd.log again.

Anyone knows why this file appears to be missing?

cheers
ET

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] setup LEAF from Windows

[Erich T. <eri...@th...>]

Hi Bob

Am 02.01.2026 um 08:55 schrieb Robert K Coffman Jr. -Info From Data Corp.:
>     I agree with this - I maintain two Clonezilla images for this, with one
>     of them being for UEFI systems.  To up/downgrade, I have a script to
>     SCP the contents of two folders I call mnt and syslinux, replacing the
>     contents with the older/newer version I desire, while retaining the
>     configdb and leaf.cfg files.

While most of this will work, be careful with the contents of the 
configdb file. The upgrade script included in the LEAF distro tries to 
mitigate small changes in the ontent of the config files but cannot 
unfortunately deal with major changes in the format of these. It will 
warn you if it fails and leave the various files in /tmp.

cheers

ET
-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] setup LEAF from Windows

[Robert K C. J. -I. F. D. Corp. <bco...@in...>]

   I agree with this - I maintain two Clonezilla images for this, with one
   of them being for UEFI systems.  To up/downgrade, I have a script to
   SCP the contents of two folders I call mnt and syslinux, replacing the
   contents with the older/newer version I desire, while retaining the
   configdb and leaf.cfg files.

   - Bob

   On 12/31/2025 7:05:55 PM, Erich Titl wrote:

     Hi Jeanrocco
     Am 31.12.2025 um 20:00 schrieb jeanrocco jr:

     Hello Victor and All,

     I believe the easiest way is to burn one of the prebuilt images
     using a suitable imager like the one for a Pi to a CF or something
     that can be plugged in the CF slot of the Alix box.