Beiträge von gderf

    Somehow and I don't know how the filesystem UUIDs on both disks are the same and also all thru both grub.cfg files.


    I know when I changed this on my OMV6 disk after cloning it to update the clone to OMV7, but I may have restored the OMV6 disk from a backup that had the unchanged UUID.


    Simple enough to fix.


    Thanks for your help.

    Recently there was a large set of updates which I installed in the shell. During that process a screen was presented saying I needed to select which drives I wanted to install Grub on and the list showed every drive in my system, 13 of them. I thought I selected the correct two drives to place Grub on, but it didn't work. My OMV 7 was bootable but when I attempt to boot my OMV6 install via the system BBS popup it boots OMV7.


    I tried installing Grub to the two OMV disks like this:


    Code
    grub-install /dev/sdn
    grub-install /dev/sdm

    But when I rebooted and selected the OMV6 disk, it booted OMV7.


    Does anyone know what the shell command is that presents the table of all disks and allows selecting which disks to put grub on?

    What I didn't quite understood, is how do you manage to switch the booting to that older stick? It sounds, like you can do this remotely.


    So far need to have physical access to the machine to be able to enter the BIOS and switch boot device. Which also includes attaching a screen and a keyboard. Which is one more reason, why I want it as simple as possible, since I can't attach additional devices at the NAS, where I have it running... (I need to relocate is to some desk or so)

    But being able to do this remotely sounds interesting to me,

    I would be happy if you could point me in the direction how to do this.

    The machine has IPMI access which is accessible over the network on a serial over LAN connection (SOL). This is accomplished by the motherboard which has a system on a chip (SOC) running software, probably some cut down Linux variant on it that is connected to a dedicated ethernet port. Client access is via a terminal shell to the IP bound to that port.


    In the terminal it looks just like a ssh connection or like the console usually available via a monitor and keyboard.


    The SOC is running all the time so long as power is applied to the motherboard, even if the machine is shut down. Another way the SOC can be accessed is via a browser which allows certain commands to be run, status information is displayed, etc.


    This functionality is not available on ordinary home use type motherboards.


    So, yes, I can power on/off the machine, reboot the machine, select the boot device, enter the BIOS, all remotely over the network, which if I forwarded a port on the router, from anywhere via the internet There is no monitor or keyboard attached in my use case but those ports are available, and the machine is locked in a safe. The only times I have physically accessed it is to add more hard drives and add some more RAM.

    Here's my log. It shows a few more process lines. I didn't compare it line for line though.

    Would you be willing to try the one that dockerhub forum suggested to me should prove whether or not things are working?


    Code
    ---
    services:
      test_default_bridge:
        image: nginx:latest
        network_mode: bridge
        ports:
          - 8080:80

    Works for me. As do the other dozen containers I run here.


    What does the container log say about this one?

    I run a script that uses dd to make a nightly backup of my system drive. The image is stored on a data drive and I keep the most recent seven images.


    There are backup plugins within OMV, but since I don't use them I don't know anything about them. Look them over for yourself, maybe one will do what you need.

    Ok, thanks, but what is the path of the file? I know it exists because I already found it, but I forgot where it is

    /var/log/journal but there are many files there, none of which are human readable.


    Use the journalctl program to read the journal. You'll probably want to read the man page.


    There is also the /var/log/syslog file and its rotations.

    You wouldn't have unpredictable behavior until the machine is rebooted.


    You could do like I do by writing the dd image of the boot drive to an image file on another disk. But recovery using this image file isn't exactly trivial.


    I have my old OMV 6 USB stick still in the machine and I can boot to that instance when desired or needed, interactively on startup in a remote ipmi terminal. From there I can use the image file file to write to a new unused spare USB stick that is always in the machine by running dd in the console shell. The machine is headless so these things happen via a remote machine which could be anywhere that has network access. Once that is done I can reboot and select the newly written USB stick to boot to and set that one to be the default boot disk. I would also have to modify the backup script to select the new USB stick as the source for future backups if I didn't want to swap the old stick for the new one.


    I have been making automated daily dd image file backups like this since starting with OMV2 nine years ago (that's over 3200 backups). I keep the seven most recent images.

    Read the container's log file.


    What machine are you trying to browse to plex.tv/claim on? If you are getting a black screen something is wrong with that machine or its browser. Try another browser or clear its cache.


    It's difficult to help when you have provided very little beyond that it does not work.