Pi-hole in doker network problem

  • this thread will get butchered up


    You are the author of [How To] Install Pi-Hole in Docker: Update - 08/10/18 right?


    Care to elaborate

    • why do you suggest configuring a DNS server manually (why do you think this is needed at all?)
    • why do you suggest using Google's server when it's about using Pi-Hole (do you catch the irony handing out your whole surf history to Google? Some people recommend using Cloudflare's 1.1.1.1 in the meantime but this doesn't improve things a lot)

    Are you aware that if there is no real reason to configure manually a DNS server @Nefertiti would've been up and running within minutes and not days? At least I think it's better to finish a task within minutes and without hassles than spending hours on something that requires a thread in a forum full of problematic advises (e.g. recommending to not use a well known DHCP feature called 'static allocation' the OP already successfully used)

    • Offizieller Beitrag

    Care to elaborate

    No, that would be pointless and there's no point in continuing this thread.


    @ryecoaaron approved the Docker/Pi-Hole How-To and there's no reason to change it. If you feel it's technically insufficient or hurting users, by some odd stretch of imagination, take it up with him.


    I think we're done here...

  • @Nefertiti: can you provide output from 'armbianmonitor -u' when you're logged into OMV on your RPi via SSH? In case you use an OMV image older than 1 year this will produce only 'command now found' but if you started with OMV 3 after July 2017 we might get some insights.

    Far from me to reopen the thread but above all the polemic witch I feel in a way l a little bit responsible Anyway here what I got from root
    root@raspberrypi:/# armbianmonitor -u
    /var/log/armhwinfo.log has been uploaded to http://sprunge.us/80Suyn output at https://drive.google.com/file/…L6XZ_FVa/view?usp=sharing
    Please post the URL in the forum where you've been asked for.
    I was thinking it is possible not only I upgraded from 3.99 to 4.. but also I changed the device to a new 3b+ so maybe eth1 may come from this process Since I was never be able to install 4... from fresh On any devices even with a brand new SD

  • root@raspberrypi:/# armbianmonitor -u
    /var/log/armhwinfo.log has been uploaded to sprunge.us/80Suyn

    Thank you for helping to improve OMV unlike others here.


    Ok, so debug output is telling clearly that your only interface all the time was eth1 while you were able to create an eth0 entry in the GUI (which of course led to the expected result not being able to activate the non existing interface). So there's definitely some room for improvements wrt interface handling at least on the ARM images where there's no entry present after installation (due to different initial setup attempt).


    Currently no idea how to deal with this since your log shows some rename events occurring after each and every reboot:


    Code
    lan78xx 1-1.1.1:1.0 eth1: renamed from eth0

    And I also do not understand how it was possible that you were able to create an eth0 entry in the OMV UI (but I can confirm with my own testings in OMV4 on EspressoBin).


    The 'funny' part is that the interface name wouldn't be a problem at all if the tutorial you tried to follow would not recommend an extra step to create an eth0 entry to hand over all your private web activity to Google (the questions @flmaxey is either not able or willing to answer. And obviously not even willing to think about whether it's a great idea recommding Google DNS for Pi-Hole users and their privacy concerns).


    Without the 'needed' step to configure Google's DNS server (we still don't know why since the tutorial author is not able to answer simple questions) you would've been up and running in no time if you would've been aware that your interface name is eth1 and not eth0 which I consider a problem since there's a mismatch between OMV UI and reality according to ip addr.

  • /var/log/armhwinfo.log has been uploaded to sprunge.us/80Suyn


    BTW: If you look at the end of dmesg output at the bottom of the link it can be seen that there's something seriously wrong now that you've Docker running:


    (and so on -- this most probably also floods /var/log/system.log so you might run into a 'filesystem full' situation sometimes in the future)


    Update: Maybe already within the next few hours:


    Code
    ### df:
    
    
    Filesystem      Size  Used Avail Use% Mounted on
    ...
    folder2ram      489M  331M  159M  68% /var/log
  • @Nefertiti: can you please provide the output from these two commands:


    Code
    nmcli dev show
    ip addr

    on your device? I'm preparing a thread to discuss necessary changes in the way OMV interacts with the basic Armbian system your currently using and am about to collect information. Since your OMV box suffers from the same problem as my test machine (OMV allowing to create an eth0 interface when the interface in question is eth1 in your case) it would be great to have as much data as possible.


    BTW: I hope you're aware that something's wrong on your board as already mentioned? You might check df -h /var/log.

  • I have no idea how to fix my board here the output any advice would be appreciated!


    root@raspberrypi:/# df -h /var/log
    Filesystem Size Used Avail Use% Mounted on
    folder2ram 489M 203M 287M 42% /var/log

  • folder2ram 489M 203M 287M 42% /var/log

    I guess you rebooted in the meantime since last time /var/log/ was filled with 331M which is way too much (folder2ram uses uncompressed RAM -- something @ryecoaaron might look into soon -- so this huge amount of logs will not only fill the partition quickly but also take away RAM from the rest of the system).


    At the end of the armbianmonitor -u output it could be seen that network devices got disabled/enabled/renamed multiple times per second. You might check with dmesg | tail -n 100 whether that's still the problem.


    I've no idea why this happens but I suspect it's due to following @'flmaxey''s tutorial and using eth0 everywhere? I would check how you created the macvlan device since if this uses eth0 instead of eth1 as parent device then clearly something's wrong. Whether this is the culprit I don't know.


    Thank you for the other output. Things start to make sense (needing unrelated fixes in OMV somewhere)

    • Offizieller Beitrag

    folder2ram uses uncompressed RAM -- something @ryecoaaron might look into soon

    I still want to do that. Just haven't had a chance to look into it.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

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