Posts by m4tt0

  • [SOLVED] Boot kernel parameters and EdgeTPU / Coral AI issues

    Context:

    I've been fiddling with frigate recently to control my security cams and introduce AI-based autodetection. I'm very happy with it but it puts a lot of workload on the server using CPUs to run the algorithms. Frigate itself recommends "outsourcing" the number crunching to Google Coral AI devices. This caught my interest, I ordered an M.2 EdgeTPU and I put it into my system. While the drivers install as advertised, test algorithms break down throwing "Failed to load delegate from libedgetpu.so.1" errors. Others have experienced this before and there are several guides to trouble-shoot this. This is certainly off-topic here.


    My issue:

    One of the requirements of utilizing the EdgeTPU is, that the system supports MSI-X as defined in the PCI 3.0 specification. My motherboard should support that. One of the workarounds I found recommended to introduce some kernel boot parameters to the system. When I looked at `/etc/default/grub`, I found that my installation contains the boot parameter `pci=nomsi,noaer`, which may(!) deactivate msi support and be the culprit of the problem.


    Questions:

    Is this true? If yes, can I simply remove the `nomsi`parameter or am I going to run into trouble (I assume it's there for a reason)? If not, can I simply add additional boot parameters in this file and reboot or do I need to configure the boot parameters in another place (still not familiar with salt, sorry).


    Any insight appreciated.

  • Festplatten kopieren

    Ich hatte OMV4 gar nicht gesehen. Du hattest Glück, dass in OMV 4 die Festplatten noch per Label gemountet werden. Klappt mit OMV5+ definitiv nicht mehr, weil die Festplatten dann per UUID gemountet werden. Und die UUID ist für jede Platte anders. Aber egal. Wenn es läuft, ist es gut...

  • Festplatten kopieren

    Im Prinzip schon. Du musst die in OMV nur sauber "abmelden" und hinterher wieder "anmelden".

    Abmelden beinhaltet:

    - Alle Referenzen auf die defekten Platten deaktivieren bzw. löschen (z.B. rsync jobs, SMB Freigaben, etc)

    - Dann aushängen (unmounten). Wenn Du beim Schritt vorher was vergessen hast, geht das nicht.

    - Dann runterfahren und Platte ausbauen

    - Woanders klonen, und alles wieder rückwärts.


    Du kannst das aber auch unter OMV machen, wenn Du noch einen Festplattenslot hast, z.B.:

    - Neue Platte rein und temporär einhängen

    - rsync job einrichten, um alles rüberzuschaufeln

    - Alte Platte aushängen und ausbauen (s.o.)

    - Neue Platte wie die alte konfigurieren.

  • Replacing old RAID5 hdd's

    Yes, I would...

    1. Remove all references to the RAID first, i.e. SMB shares, shared folders, rsync jobs, whatever points at it...
    2. Dissolve the RAID (if you haven't done step 1 or you forgot to remove pointers, you may struggle here)
    3. Properly wipe all individual discs to avoid data theft (if you are concerned about that)
    4. Shutdown the computer
    5. Remove the old drives, install the new ones

    ...and take it from there.

  • New openmediavault-kvm plugin

    Can confirm. Using SPICE and virt-viewer, everything works as expected. Many thanks chente and ryecoaaron. Gee, what a journey!


    P.S.: And for those trying and wondering how to run the virt-viewer SPICE client on Windows: Nooooo, there is no virt-viewer app (that would obviously be too simple). "Remote Viewer" is the name of the app you are looking for. Not sure if you want to chente, but may be worthwhile adding to your very nice guide, too...

  • New openmediavault-kvm plugin

    OK. Thanks. I've manually changed the "/etc/default/keyboard" file to switch to a US keyboard layout. After reboot, the hyphen is working. Not ideal, but at least manageable.


    If anybody has a better solution, please let me know. Thanks again.

  • New openmediavault-kvm plugin

    ryecoaaron Thanks for looking into this, but is the keyboard mapping actually working for you? If so, what is your layout and configuration, please? I'd have no issue using a US or French layout or what not on my German keyboard, but I do have an issue with not being able to produce hyphens at all, because key presses don't produce anything or every other one produces "Ö"s...

  • New openmediavault-kvm plugin

    I just tried to install a Debian VM using the KVM plugin. Setup itself went fine and I was able to get it up and running and connect to it with a VNC client. My only problem is that it is almost unuseable, as the keyboard layout is completely messed up.


    I installed Debian inside of the VM using German keyboard layout. The VNC client runs on a Win 10 laptop with a German keyboard layout, too. I tried tightVNC, turboVNC and VNC Viewer. Same problem everywhere. I tried to run "dpkg-reconfigure" commands to change the keyboard layout within the Debian VM, but no matter what I press, there is no hyphen anywhere, so I cannot execute the command. It's crazy.


    Have you ever encountered similar problems? And if so, how have you solved them? Any advice appreciated...

  • Monitoring restart -- Connection failed nginx

    OK, I kept receiving those notifications, but I've finally managed to get rid of them.


    The short version: votdev was right. It was a configuration problem.


    The longer version;

    - I've started tracking when the connection failures started to occur and realized they in fact did occur regularly, every second Friday at pretty much the same time in the middle of the night.

    - I then started checking the logs and realized that immediately prior to the issue occuring, I had rsync jobs failing.

    - Looking into them, I quickly realized what was wrong: I exchanged my server some months ago and demoted the former server to a backup medium. At the same time I changed the old server IP and assigned the old server IP to the new server. I did not change the rsync job though.

    - In effect, my new OMV server tried to rsync to itself, with login information for a user that did not exist and while no rsync server was running (that just runs on the old server).

    - I've corrected the configuration and restored the standard monit configuration more than three weeks ago.

    - No problems since and given the above, I'd be surprised they'd return.

  • OMV + TV headend

    OK, I assume that is how you labeled the USB drive you wanted to record to, i.e. "Datensicherung" is the label of the drive, no?

    If that's the case, your recording folder should be in there.


    If you go into your OMV web-interface, to Access Mgmt -> shared folders, which entries do you see?

  • OMV + TV headend

    Depends on your setup:

    - Do you use a TVH docker container or is it installed natively on your OMV?

    - Have you created a shared folder for your recordings?

    - If you use docker, how are folders mapped?

    - What are the Filesystem settings in the TVH Web-interface (c.f. Configuration -> Recording -> Digital Video Recorder Profiles: right hand side)?

  • Monitoring restart -- Connection failed nginx

    cubemin : Unfortunately this did not work either. Ran into an email wall again yesterday. Undoing the changes. :(


    EDIT: Too quick, too early: Trying to "undo" the changes, I saw that they had been overwritten by the original values. I ran updates earlier this week. That's probably why. Changed it again and will continue testing...


    Sorry for the noise!