Beiträge von jata1

  • syslog stops logging at end of startup sequence

    I am able to reproduce these 2 issues with a clean install of OMV 7 or when using omv-release-upgrade from OMV6 to OMV7 on a raspberry pi 4.


    It would be good to see if others can reproduce as if not resolved before OMV7 beta completes, I think there could be a load of people with rpi4's that have these issues...


    I am using a clean/new OMV7 install from latest 64bit lite rpi4 image and running the omv install script for testing/troubleshooting.


    Issue 1:

    The LAN interface is created with the name end0 even if I have disabled predictable network names in raspi-config - I don't think this is a problem for those setting up a new OMV7 system - but it is if you are using omv-release-upgrade (e.g. docker networks linked to eth0 will be broken)


    Issue 2:

    System logging stops at some point late in the boot sequence. There are no clues why (for me). The work-a-round is to restart journal logging that resolves the issue until the next restart.


    Code
    systemctl restart systemd-journald

  • Sorting and order of logs in WebGui

    I have the same issue on rpi3 and rpi4 and both are running latest omv6 / 64bit architecture.


    I get nothing returned if I use proftpd in the journalctl command but I do get some output if i use anacron - but it is not showing the data from 31/12/2024...


    I remember I had a similar issue at the end of 2022 (start of 2023) - but it only impacted some rsync logs.


    Code
    root@rpi4:~# journalctl --quiet --no-pager SYSLOG_IDENTIFIER='anacron' --output=short
Dec 27 14:18:37 rpi4 anacron[1037]: Job `cron.daily' started
Dec 27 14:18:37 rpi4 anacron[4800]: Updated timestamp for job `cron.daily' to 2023-12-27
Dec 27 14:54:40 rpi4 anacron[1037]: Received SIGUSR1


    Update: I forced a log rotate on my rpi3 and all the junk has cleared. I will hold off doing the same on the rpi4 in case I can help with some troubleshooting.

  • syslog stops logging at end of startup sequence

    Zitat von votdev

    That is strange because OMV does not do any changes to the systemd journal configuration.

    I thought that too.


    I also had the end0 ethernet name even though I disabled predictable names.


    Happy to have another test to see if I can reproduce either or both issues if that is helpful.


    One thing… I didn’t download the install script and use the -b flag as I read on another thread that it can be run in the usual way.

  • will omv-regen work on omv7

    Top work chente. Thank you.


    I have reverted to my omv6 setup on rpi4 as there are some weird issues i was having with omv7.


    I have followed your advice and used clonezilla with my system disk having rootfs and appdata partitions. And this made it so easy to get back to omv6 with all my omv7 data.


    Happy days and Happy New Year (in advance)

  • syslog stops logging at end of startup sequence

    I restarted journald and all seems fine now. Will check the situation after a reboot to see if this was just a little glitch.


    Code
    systemctl restart systemd-journald


    Update: After reboot - same situation with logs stopping at this point in the syslog.


    Code
    12/26/2023, 5:48:49 PM
systemd[1]: Mounted export-docs.mount - /export/docs.
12/26/2023, 5:48:49 PM
systemd[1]: Mounting export-docs.mount - /export/docs...
12/26/2023, 5:48:48 PM
systemd[1]: Mounted srv-dev\x2ddisk\x2dby\x2duuid\x2d31995d48\x2d98d2\x2d41e6\x2d91ad\x2deb9b6f6ce10f.mount - /srv/dev-disk-by-uuid-31995d48-98d2-41e6-91ad-eb9b6f6ce10f.
12/26/2023, 5:48:48 PM
(udev-worker)[712]: regulatory.0: Process '/lib/crda/crda' failed with exit code 254.
12/26/2023, 5:48:46 PM
systemd[1]: Reached target remote-fs.target - Remote File Systems.

    Status of systemd-journald after system reboot - see below. At this point there is no logging to syslog after the log entries above.


    Code
    Dec 26 17:48:40 rpi4 systemd-journald[170]: Journal started
Dec 26 17:48:40 rpi4 systemd-journald[170]: Runtime Journal (/run/log/journal/80ec49fe88324c98a44d189232c2bfe0) is 8.0M, max 75.8M, 67.8M free.
Dec 26 17:48:40 rpi4 systemd-journald[170]: Time spent on flushing to /var/log/journal/80ec49fe88324c98a44d189232c2bfe0 is 32.662ms for 435 entries.
Dec 26 17:48:40 rpi4 systemd-journald[170]: System Journal (/var/log/journal/80ec49fe88324c98a44d189232c2bfe0) is 104.0M, max 1.7G, 1.6G free.
Dec 26 17:48:40 rpi4 systemd-journald[170]: Received client request to flush runtime journal.
Dec 26 17:48:40 rpi4 systemd-journald[170]: File /var/log/journal/80ec49fe88324c98a44d189232c2bfe0/system.journal corrupted or uncleanly shut down, renaming and replacing.


    After restarting the systemd-journald, the status messages are slightly different but not sure if this is an indicator of the issue.



    Code
    Dec 26 17:56:18 rpi4 systemd-journald[3326]: File /var/log/journal/80ec49fe88324c98a44d189232c2bfe0/system.journal corrupted or uncleanly shut down, renaming and replacing.
Dec 26 17:56:18 rpi4 systemd-journald[3326]: Journal started
Dec 26 17:56:18 rpi4 systemd-journald[3326]: System Journal (/var/log/journal/80ec49fe88324c98a44d189232c2bfe0) is 112.0M, max 189.6M, 77.6M free.

  • syslog stops logging at end of startup sequence

    I know that logging uses journald rather than rsyslog in omv7 but I have an issue where there are no further logs in the GUI or using journalctl from the console. Logging seems to stop at the end of a startup sequence but I do not know how to trouble shoot this.


    My rpi4 system is upgraded from omv6 to omv7 using omv-release-upgrade and this worked fine. Everything is working well (except logs i think).


    If I check the syslog in /var/log/syslog I can see recent logs so it is just journald / journalctl that is not working.


    Any ideas?

  • clean install of omv7 on rpi4 - openvswitch: ovsdb-server.service is not running

    I am looking to create a clean install of omv7 on a rpi4 and the install script completed fine but there was one message that I wasn't sure about - see below.


    After the install competed, I logged into omv edited eth0 in the GUI to disable IPv6 (as I don't use it). Something went wrong with the config change and I could no longer access the system (headless).


    Is it possible the message below is related as the issue occured when I tried to change network setup?


    Thanks!


  • will omv-regen work on omv7

    I have recently upgraded my rpi4 from omv6 to omv7 and while it is all working, I have a few little issues so I am thinking of starting with a clean omv7 setup and using omv-reg to setup my new system.


    I have a simple setup. just a few plugins (compose, symlinks, resetperms, flash) and 4 docker containers. My system disk is ext4 and has 3 partitions (boot, system and appdata)


    Has anyone attempted this with omv7 or is it too early as omv7 is still early beta?


    chente what are your thoughts?

  • config files for rsyslog service is behaving differently in omv7

    Thanks votdev. I will have to accept the spam in the syslog and get over it :)


    I have changed the names (file extension to .bak) of the 3x conf files in /etc/rsyslog.d and rebooted my rpi but now I think there is a different issue with logging...


    The issue is that logging seems to stop altogether towards the end of my system startup. How can I investigate this further? Below is the last page of syslog entries before it stops. Any clues"


  • config files for rsyslog service is behaving differently in omv7

    I have upgraded to omv7 from omv6 on a rpi4 and everything is working well but something is differnent with a custom conf file that I use to filter out syslog message spam.


    The config file is etc/rsyslog.d/omv-custom.conf and I have been trying to resolve the problem - it's just a syntax issue I think...


    I have been working the issue by making changes to the file and then restarting the service using the following commands. The service starts fine but is not filter out any messages.


    Code
    service rsyslog restart
service rsyslog status


    my custom conf file includes the following filters but I am still getting the messages. Maybe it is the order that the config is applied?


    Any help appreciated.


    Code
    :programname, isequal, "nmbd" stop
:programname, isequal, "CRON" stop
:programname, isequal, "rngd" stop
:programname, isequal, "smbd" stop

:msg, contains, "action " stop
:msg, contains, "netsnmp_assert" stop
:msg, contains, "Failed to initiate sched scan" stop
:msg, contains, "run-docker-runtime" stop

  • omv-release-upgrade worked but issue with eth0 in the GUI

    I'm in the office today but will try tomorrow with predictable names disabled.


    I have noticed that when I run raspi-config it asked to define/set the user and defaults to the pi account but I have deleted this account from my omv6 setup a long time ago (as I don't use the pi account/user). Strange that the system still thinks the account exists. The change seems to have 'stuck' after a reboot so I think it will work. I'll post an update tomorrow.

  • After upgrade from OMV6 to OMV7 DNS not working on Odroid HC2

    Zitat von macom

    Seems similar to this


    Thema
    omv-release-upgrade worked but issue with eth0 in the GUI
    hello all - I just upgraded my rpi4 from latest omv6 to omv7 using omv-release-upgrade and everything went well. System is up and logs look good i think.

    I noticed an issue when I tried to start a docker that uses a macvlan network. Here is the error.

    (Quelltext, 13 Zeilen)

    So i did a bit of digging and I noticed that there is something not quite right in the network > interfaces in the OMV GUI - although the network is working fine as the system is up and using eth0

    see screen shots below - This…
    jata1

    I had another go at using omv-release-upgrade on my rpi4 and still have the same issue as reported last week.


    Tested on a backup/testing system (cloned from my omv6 setup today). I know votdev has added a fix but issue is not resolved or the fix has not yet been pushed into omv7 beta and/or omv-release-upgrade.


    I will try again next week :)