Beiträge von jata1

    The end0 vs. eth0 issue on RPI is covered in the omv7 installation guide.


    omv7:raspberry_pi_install [omv-extras.org]


    There is an additional step required to make sure you end up with a system that has eth0 as the name of the lan interface. This step is needed to be taken before you run the install script...


    Hope this helps you - I had a load of issues with this during the beta testing stage and the solution was the introduction of the pre configure script.


    I am a Mac user. Only use PC for work. I had issues before omv 7 with using .local domain so I did the following and all has been good since.


    1 if router lan settings set domain then name the domain .lan (never .local)

    2. Use dhcp for client up assignment. Assign addresses that you need to

    Be fixed.

    3. In omv network setting change domain to .lan (as above).


    Then change and scripts/plugins etc to use client.lan and not client.local

    Really appreciate any help with this from the very smart people in this community :)


    Project objective - is to have a opensource system to track my teenage son's driving behaviour. Particularly to see if he is speeding or in a car with friends who are driving dangerously. Life360 is the easy way but it is not open source and they have terrible data privacy policies. So...


    I have successfully built an overpass-api docker image and after much pain have it running on a rpi5 with 8GB ram! I think some of the issues (not all) I have encountered are related to RAM memory.


    I have successfully integrated the overpass-api to work with my traccar container also running on the same rpi. Today I was speeding (a little) and it is working.


    link to overpass-api docker that I have built for arm64. https://github.com/wiktorn/Overpass-API/tree/master





    I have 3 little tweaks/improvements that I need a bit of help with.


    1. More RAM memory via a swap file moved from the SD card to the ext4 system disk (new and fast SSD)

    2. I have had to download the entire planet of openstreetmap data - there is a way to do this differently but I can't quite work it out

    3. similar to 2 - there is a way to healthcheck the operpass container but I have something slightly wrong with my syntax


    So can anyone help with the swap file question and see anything wrong with the following 2 code snippets (both from a compose file in docker)?


    This one is supposed to decompress the pbf file to bz2 format so I can just pull Oz data. At the moment I am cloning the entire planet 360GB just to run api calls to return speed limit. haha

    Code
          - OVERPASS_PLANET_URL=https://download.geofabrik.de/australia-oceania/australia-latest.osm.pbf
          - OVERPASS_DIFF_URL=https://planet.openstreetmap.org/replication/minute/
          - OVERPASS_COMPRESSION=gz
          - OVERPASS_PLANET_PREPROCESS='mv /db/planet.osm.bz2 /db/australia-latest.osm.pbf && osmium cat -o /db/planet.osm.bz2 /db/australia-latest.osm.pbf && rm /db/australia-latest.osm.pbf'


    And this is one is supposed to check that the container is healthy but something is wrong running on arm64 (I think it only works on amd64). I get an invalid escape character error - see below.


    Code
    test: ["CMD-SHELL", "curl --noproxy '*' -qf 'http://192.168.100.105:8084/api/interpreter?data=\[out:json\];node(1);out;' | jq '.generator' |grep -q Overpass || exit 1"]


    well after a load of research and a load of attempts - I have build an overpass image and the container starts and is pulling data.


    It failed to complete the initiation as it downloads a load of data and has to decompress it - filled up my system drive. Now trying again with the database on a large spinning drive...


    I had to remove the healthcheck from the compose file as I was getting an error when checking the compose file. Anything obvoius wrong with the following test line/statement in the compose.?


    Code
    test: ["CMD-SHELL", "curl --noproxy '*' -qf 'http://localhost/api/interpreter?data=\[out:json\];node(1);out;' | jq '.generator' |grep -q Overpass || exit 1"]
    start_period: 48h


    The error I am getting from omv is


    I think I am very far away from being able to achieve this but I thought I'd ask here...


    Situation is that I have a traccar container running great on my rpi5. The issue is that I want to use this to monitor my kids driving to see if/when they are driving over the speed limit. Traccar can do this only if you have a way to use location to get the speedlimit from another source - overpass API is the default that is part of openstreetmaps.


    So I found a docker container for overpass https://github.com/wiktorn/Overpass-API.


    But when I tried to run the container i realised the container is built for amd64 :)


    I can't find another container that is arm64 so I'm stuck. I am so stuck that I don't even know how to 'build' a container.


    I guess this is a good project for me to learn but I have no idea how/where to start. I think the first step is to see if I can get overpass-api to build anything. Then I will need to modify the dockerfile.template to build for my architecture.


    Mission impossible or worth progressing?

    The easiest work-a-round is to add a scheduled task on reboot that restarts journald - see below.


    The link you posted is for transmission running inside a VPN. I am not sure about jackett - don't know what this is. Sorry.


    I use the haugene docker with PIA as the VPN provider. Works great. Below is my compose file (with a few bits redacted of course) :)


    First you need to install and configure the compose plugin for OMV 6/7. There is loads of info on this in the forums so I am not covering it here.



    I think that’s fine. Are you concerned with the cpu temp?


    I have rpi5 with active cooler. My setip is quite light with a few dockers. Fan not running at all.


    CPU stable at 55 °c


    My pi is in a drawer with a few spinning disks so not a cool or well ventilated and I live in a hot country and it’s summer.

    I have three docker containers that use the same macvlan network - all with different IPs from the macvlan range. They all work fine.


    Today I was doing some testing and I found that I can't reach (ping, dig etc) these docker IPs from the cli on the server that runs docker and hosts these containers.


    If I use another server and try to ping, dig etc to the docker container IP then it works as expected.


    All other clients on my network are all reachable fine - this only impacts the 3 dockers that use a macvlan network.


    The error I get when trying to ping is destination host unreachable - see below.


    Is this normal?

    If not, what can I do to investigate?


    I'm running latest OMV 7 on rpi5.


    The issue I had a while ago was caused by the ssd I was using for omv system and docker. I had my docker install and appdata on a separate partition on the system disk. I now have omv system and docker/appdata on separate disks on a clean install of omv7 on a new rpi5. Issue resolved.


    The second image I posted in the thread was not correct. I wanted to show that the docker widget in the dashboard was switching from status 'running' to blank every 10 seconds - but as I said this issue is resolved on my new setup.


    hccz95 - what exactly is the issue? Not clear from your post

    has anyone seen or reproduced the syslog issue on rpi / omv7 where logging just stops sometime during the reboot process? I can reproduce this at will on rpi4 and rpi5 after a clean install of omv7 or upgrade from omv6.


    work-a-round is to restart systemd-journald at reboot using a scheduled job but it would be good to find a better solution


    systemctl restart systemd-journald

    RPI5 requires the preinstall as well.

    Yes but I accidentally found a work-a-round on rpi5 (without the preinstall).


    Not 100% sure but I think the process was...


    1. new install pi os lite

    2. use raspi-config to disable predictable network names

    3. install omv - normal install script

    4. reboot and use raspi-config to disable predictable network names again (something in the script seems to enable it)

    5. reboot and network name is eth0 in gui and system