Posts by auanasgheps

    grubparts is only meant to restore grub and partition table info not partitions. The uefi partition is a full partition and would require a separate file (and restore) of its own. I guess I can look at backing that up too.

    Allright, thanks for the clarification.


    The UEFI partition is usually 512 MB but Debian/OMV only uses 136KB, so there is virtually no space and time required to back it up. It has a boot flag, so it should be easy for you to build a logic to detect it and back it up.


    This would be a great addition, because means we could restore an entire OMV setup to a new disk with only few commands in systemrescuecd, and not to do other this like reinstalling OMV (to be honest I haven't thought about it).

    Sure, just dd a larger portion of the beginning of the disk. I think it is normally 2MB but I need to check.

    Hey ryecoaaron, are you planning this change for fsarchiver as well?


    Yesterday I had to restore my system running UEFI and was a nightmare. I lost 3 hours before I figured out the problem was the UEFI partition not being restored from .grubparts and then the actual GRUB/UEFI restore/install process to have the system back up and running again.


    With the UEFI partition backed up would have been a breeze.

    No idea. It still doesn't make sense to me why people sleep their servers lol

    Energy prices in Europe have always been higher compared to other locations like North America, and are skyrocketing due to the Ukrainian conflict.


    Additionally I'm the only main user of my NAS, so I send it to sleep when I know nobody uses it.


    You don't need to run the deploy step. Just the prepare step to update the salt grains. And those are one time steps anyway. So, it shouldn't really matter if takes a while.

    I was following the official docs which instructed this way.
    Allright, won't do it in the future.

    Thanks! That's great, it works!

    Still, I'm not sure why hybernation is the default option now, I don't think is ideal.


    Anyway, I have applied the settings following the usual procedure :


    Code
    sudo omv-env set OMV_POWERMGMT_HIBERNATE "suspend"
    monit restart omv-engined
    omv-salt stage run prepare
    omv-salt stage run deploy

    The last step took almost 4 minutes, (Total run time: 223.039 s)

    Dduring this period the system was on I/O wait and was writing a lot of data to the system disk.


    I get it, I'm running OMV6 on a USB stick which is not super fast, but OMV5 used to take just a bunch of seconds to do run deploy, and this is a fresh install of OMV6!

    For anyone with the same/similar issue, try installing to a faster drive!


    It seems the installer doesn't like slow (but otherwise perfectly fine) USB drives. The installation media can be slow, just not the target drive.

    My USB stick speed is fairly average, but I understand your point.


    However, it's funny this issue has happened, because this entry is in OMV6 changelog:


    Code
    Enhanced ISO installer. Ensure that /media is unmounted to allow installation to USB devices. This will allow the installation from USB to USB device.

    Hi,


    When reinstalling OMV6, I have noticed that the command "Standby" in the GUI has moved from systemctl suspend to systemctl hybernate. This is not good for my system.


    I can also see the following in OMV6 changelog, but there's no documentation about these variables:


    Code
      Add environments variables OMV_POWERMGMT_REBOOT, OMV_POWERMGMT_POWEROFF, OMV_POWERMGMT_SUSPEND, OMV_POWERMGMT_HIBERNATE and OMV_POWERMGMT_HYBRIDSLEEP to customize the reboot, power-off, ... power management commands.


    My goal is restore the "suspend" function in "Power Management" section. I created a custom scheduled task, but isn't nice as having it in Power Management. Also, I'd like to use the "Standby" feature found in the GUI.


    Hybernation isn't great for everybody, especially on installs like mine with a USB thumb drive, which are terribly slow when using hybernation.


    Can this behaviour be customized with the new environment variables or am I seeing a different issue?

    do you remember the kernel version that got installed? the linked picture would let me assume a 5.14 kernel (but only indirectly).

    LTS kernels considered good are 5.10 and 5.15

    the kernel version is visible in dashboard/system information or by CLI uname -a

    Indeed, I think 5.14 was installed.

    After the install I ran the command omv-upgrade so I'm running the latest and greatest 5.16.


    By the way I have discovered the root cause of this issue: the OMV GUI has moved from systemctl suspend to systemctl hybernate. I will create a new thread to discuss this.

    I have installed OMV6 on a USB stick, as I did for OMV5. (specs in my signature)

    However the install didn't go very smoothly - issue here - but I don't know if It had a direct impact.


    The original size of the swap was very little, just under 1 GB.

    The RAM was not changed after the install. I always had 8 GB RAM installed on this setup.


    The previous OMV5 install had the correct size swap partition, but I can't remember if I did something to it since it was installed on February 2020.


    By the way, if the RAM content has to be copied to the swap partition, do you know why the sleep process is so fast?


    My system on average uses 2.5 to 3 GB RAM and the sleep process takes literally a handful of seconds, but my USB stick isn't that fast. How is this possible? I'm not complaining, I just don't understand how is accomplished.

    Hi,

    I am unable to set the system to sleep/standby.

    The action does not have any effect.


    Logs from syslog:

    My fstab:


    I am using the flashmemory plugin as I did on OMV5. On such OS (same hardware) I was able to set the system to sleep. What has changed now?

    I successfully installed OMV6 on my system following this procedure


    - Unplug the LAN cable

    - Run the OMV6 installation with a USB stick

    - Go trough the installation without a network

    - When asked to select which Debian source I preferred, I pressed ESC and selected the entry to configure the network.

    - I plugged the LAN cable

    - Network got configured and the installer resumed from the Debian source selection.

    - The installation proceeded as normal and completed successfully.

    Someone I was helping on reddit the other day was having a similar issue.


    I would probably follow the instructions to do a debian mini install, and then install OMV on top of that.

    Honestly I would like to get the issue resolved.

    OMV5 installed fine on this hardware at the time, so OMV6 should.


    The Debian installer asked much more stuff and took more time to install, so the installs are not really the same.

    Hi,

    Today I wanted to make a clean install of OMV6, but... everything went wrong.


    The installed gets stuck at 95% at the entry Installed e2fsprogs (amd64)

    I have tried both the latest and the previous OMV6 ISO (openmediavault_6.0.24 and openmediavault_6.0-34) but the behaviour is always the same.


    I got the logs by typing ALT+F4 and you can find them here (high res photo which can't be attached).


    I cannot get past this point. The computer is not stuck, in this state the cursor is flashing under the last log line, but I also can't do anything.


    So I grabbed the Debian NetInst ISO and gave it a try. The installer is slightly different and the process takes much longer. The installation completed successfully, although I am not sure if does install e2fsprogs. Because I wasted too much time today, I'm temporarily restoring OMV5 and wait for your feedback.


    The hardware I'm trying to install it is in my description. I installed OMV5 more than two years ago and I had no problems!

    Out of curiosity, how exactly do these letters change for you? Did they swap places, or picked up letters not used before? If the former, I probably wouldn't mind.

    They swap places!

    EDIT: Looks like it may be related to LUKS.

    Well, this means the guide is still good, but is a bad news for you and the others using LUKS. The developer is quite responsive so he might actually come back with a solution.