MACVLAN Issues

    Zitat von ozboss

    But now that I have the same issue on a completely different architecture with different kernel version it seems to indicate that this is not necessarily the case...

    I think it all comes down to Linux kernel version eventually.
    If you refer to this link, people are complaining the same macvlan issue on the 5.4.x kernel.


    The reason it worked on 4.19.102-v7l+ with rpi-update is that they back-ported the patch on kernel 4.19.x.


    So if you can find a way to update your arm64 kernel to 5.4.14, that should fix the issue.

    Zitat von limac

    I think it all comes down to Linux kernel version eventually.If you refer to this link, people are complaining the same macvlan issue on the 5.4.x kernel.


    The reason it worked on 4.19.102-v7l+ with rpi-update is that they back-ported the patch on kernel 4.19.x.


    So if you can find a way to update your arm64 kernel to 5.4.14, that should fix the issue.

    I had this problem after updating OMV5-amd64 kernel to Debian GNU/Linux, with Linux 5.4.0-0.bpo.3-amd64.


    Rolling back to Debian GNU/Linux, with Linux 5.4.0-0.bpo.2-amd64 using the omv-extras plugin fixed it for me.

    just for "info"


    my macvlan was running for 2 or 3 weeks now without problems, yesterday i have to reboot omv and it switched to 5.4.0.0.bpo.3-amd64, today i try to start my tv (kodi connectet to tvheadend using macvlan) and it didn't work - try to ping tvheadends ip - not reachable, docker exec to the tvheadend- ping router - ok - ping pc - ok - try to ping again from pc to tvh - OK ... try to connect from mobilephone - no connect - ping from mobile to tvh - noway ... see the post above in forum, changed back to 5.4.0.0.bpo.2 - reboot the machine ... all works like it should, tvh is reachable from all devices and work like a charm.


    so there must be an error with bpo.3 and macvlan.

    ___________________________
    OMV5@AsRock j3455 8GB RAM

    2 Mal editiert, zuletzt von draddy ()

    I'm so glad you guys are there!!


    I have spent the last 24 hours digging on my own setup trying to understand why pihole was not responding after 4-5 minutes.


    I have noticed the exact same behavior with 4.19.97-v7+ on Buster and a Pi3 .. I thought the weirdest thing and that I was starting to see things..


    One question: as it seems that running rpi-update fixes this, what are the implication on OMV?
    is it safe to upgrade the kernel? what difference does it make compared to waiting for the new kernel to pop up in the updates section of OMV/apt-get?


    Thanks,

    Zitat von nick2k3

    One question: as it seems that running rpi-update fixes this, what are the implication on OMV?

    From my understand, if you install OMV 5 from the script, it is based on Raspian.
    However, if you installed OMV4 using ISO, it is using a different OS like Armbian, thus rpi-update won't work in this case.


    Zitat von nick2k3

    is it safe to upgrade the kernel? what difference does it make compared to waiting for the new kernel to pop up in the updates section of OMV/apt-get?

    rpi-update will give you the bleeding edge version for the Raspian kernel which Raspian team is still testing it.
    The stable version for raspian is still in 4.18.97 at this point.
    Normally it shouldn't break anything existing stuff, if macvlan annoys you too much and you don't want to set a static ARP entry. Then go ahead.


    If you want to be absolutely safe, then just wait for sometime till the new kernel version is released.


    You can refer to this.

    Zitat von geaves

    There is an interesting video here this installs pi-hole without macvlan.

    Directed a folk from the video to here since he had the same issue with macvlan. :)


    This video showed another neat way to make pihole work by changing the omv port. However, to me that is a compromise since macvlan should be the best of both worlds till we hit this bug. :(


    Docker swarm it used is a good stuff to spin up services.


    @prplhaz4 Macvlan has the same issue. If you want to see the individual client IPs, you need to either set your pihole as the DHCP or there is something called conditional forwarding which I didn't have success with.

    • Offizieller Beitrag
    Zitat von limac

    there is something called conditional forwarding which I didn't have success with.

    That is an option I used when I first used Pi-Hole on OMV in Docker and I was using OMV4's DNS plugin which is no longer available in OMV5. Pi-Hole's DHCP would not work for me as I have three pieces of hardware that would not communicate (for whatever reason) with Pi-Holes DHCP service, but they would work using the OMV4 plugin.


    Zitat von limac

    However, to me that is a compromise since macvlan should be the best of both worlds till we hit this bug.

    I agree it is a compromise but it's a working compromise with it's only caveat being the creation of a what appears to be a virtual IP, which in turn would probably be of no help in setting conditional forwarding in Pi-Holes' interface. I have yet to test that video on my OMV5 test machine, hopefully next week I'll give it a try.


    Some time ago I abandoned using Pi-Hole in Docker as I wanted to used unbound, again whilst it was doable it was somewhat of a PIA setting it up. Now I run a dedicated RPi with DietPi, Pi-Hole and Unbound and have since purchased a router that allows me to set a DNS for DHCP distribution.

    • Offizieller Beitrag
    Zitat von prplhaz4

    Rolling back to Debian GNU/Linux, with Linux 5.4.0-0.bpo.2-amd64 using the omv-extras plugin fixed it for me.

    :thumbup: that does work, having started my test machine this morning I couldn't get to Pi-Hole's interface, so the latest kernel release is the problem, will have to wait for next one to see if it's been resolved.

    Great, found this topic today. Downgraded to bpo.2 kernel and i hope it will solve my issue.
    I noticed also a much lower cpu usage after downgrading the kernel.

    OMV 5 on i3-2120 CPU with 8GB

    Portainer with several Dockers

    So if I'm reading this thread correctly I need to downgrade to bpo.2 from bpo.3. Is there an easy way to do that? I feel like I'm in a bit over my head downgrading my linux kernel.

    Zitat von prplhaz4

    haha...I was waiting to hear back too. Guess I should do my part to help humanity during this pandemic and just test it...

    Alright - good news - this issue looks to be fixed in bpo.4!


    For some reason, after installing and rebooting, the bpo.3 kernel was selected by default and everything was broken again.


    BE SURE to change the kernel to bpo.4 in OMV Extras before rebooting after installing this new kernel.

    Zitat von prplhaz4

    Alright - good news - this issue looks to be fixed in bpo.4!


    For some reason, after installing and rebooting, the bpo.3 kernel was selected by default and everything was broken again.


    BE SURE to change the kernel to bpo.4 in OMV Extras before rebooting after installing this new kernel.

    that sounds good, thx for your test


    will maybe try it later the day after homeoffice and will also report here.

    ___________________________
    OMV5@AsRock j3455 8GB RAM

    Zitat von geaves

    OMV-Extras -> Kernel you should be able to change from the drop down

    and for that first "Enable backports" should be enabled first? but I get an error "Gateway Timeout" on that option. So I can't enable backports , I can't change the Kernel.

    I'm on the latest OMV4 (raspberry pi 3b+) . Any ideas what the problem may be?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden