Error on auto update

  • i have my omv install set to notify me of errors. not an expert user so please bear with me. i keep getting the below error when an auto update is run.



    The following packages are already downloaded and ready to install. Security packages are installed automatically. Please go to the 'System | Update Management' page in the web interface or run 'omv-update' from the CLI to install non-security packages finally.



    You have received this notification because you have enabled software update notifications on this host. To change your notification preferences, please go to the 'System | Notification' page in the web interface.



    CRON-APT RUN [/etc/cron-apt/config]: Tue May 4 07:38:42 EDT 2021 CRON-APT SLEEP: 2490, Tue May 4 08:20:12 EDT 2021 CRON-APT ACTION: 3-download CRON-APT LINE: /usr/bin/apt-get dist-upgrade -d -y -o APT::Get::Show-Upgraded=true Reading package lists...


    Building dependency tree...


    Reading state information...


    Calculating upgrade...


    The following packages will be upgraded:


    bind9-host libbind9-161 libdns-export1104 libdns1104 libisc-export1100


    libisc1100 libisccc161 libisccfg163 liblwres161


    9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


    1 not fully installed or removed.


    Need to get 0 B/4299 kB of archives.


    After this operation, 41.0 kB disk space will be freed.


    Download complete and in download only mode



    The following security packages have been installed automatically.



    CRON-APT ACTION: 5-openmediavault-security CRON-APT LINE: /usr/bin/apt-get --option quiet=1 --option APT::Get::List-Cleanup=false --option Dir::Etc::SourceList=/etc/apt/sources.list --option Dir::Etc::SourceParts="/dev/null" --option DPkg::Options::=--force-confold dist-upgrade --yes --option APT::Get::Show-Upgraded=true Reading package lists...


    Building dependency tree...


    Reading state information...


    Calculating upgrade...


    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


    1 not fully installed or removed.


    After this operation, 0 B of additional disk space will be used.


    Setting up grub-pc (2.02+dfsg1-20+deb10u4) ...


    /dev/disk/by-id/usb-JMicron_Tech_DD56419883893-0:0 does not exist, so cannot grub-install to it!


    You must correct your GRUB install devices before proceeding:



    DEBIAN_FRONTEND=dialog dpkg --configure grub-pc


    dpkg --configure -a


    dpkg: error processing package grub-pc (--configure):


    installed grub-pc package post-installation script subprocess returned error exit status 1 Errors were encountered while processing:


    grub-pc


    E: Sub-process /usr/bin/dpkg returned an error code (1)

  • grub-pc

    Unfortunately no idea

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Offizieller Beitrag

    The following packages are already downloaded and ready to install. Security packages are installed automatically. Please go to the 'System | Update Management' page in the web interface or run 'omv-update' from the CLI to install non-security packages finally.

    vince954


    Have you tried the above yet? (Updating under System, Update Management?) If you have OMV-Extras installed, the same can be done in the GUI under System, OMV-Extras, clicking the Updates Button and selecting omv-update. Under Diagnostics, System Information, you want to be updated to OMV 5.6.5-2

    • Offizieller Beitrag

    Unfortunately no idea

    For at least a few reasons, I'm not a fan of auto updates.

    "Auto" anything should be something a user agrees to and turns on themselves. It should be a "opt-in" not an "opt-out".

  • could there be a misconception regarding "auto updates"?


    Security is from my view a non-negotiable essential for any solution.


    from blog post:

    6. April 2021 by volker

    openmediavault 5.6.3

    • Install security updates automatically. This can be disabled via the OMV_CRONAPT_SECURITY_UPGRADES_ENABLED environment variable.

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Offizieller Beitrag

    Security is from my view a non-negotiable essential for any solution.

    This is at the crux of the problem as I see it; you're only interested in your point of view and can not (for some reason) see the view point of others.

  • vince954


    Have you tried the above yet? (Updating under System, Update Management?) If you have OMV-Extras installed, the same can be done in the GUI under System, OMV-Extras, clicking the Updates Button and selecting omv-update. Under Diagnostics, System Information, you want to be updated to OMV 5.6.5-2

    tried that but got an error result, tried to copy the log but could not for some reason. the log window seems to reload every few seconds.

    • Offizieller Beitrag

    Security is from my view a non-negotiable essential for any solution.

    The kernel is arguably the most important package to update for security yet auto updates without rebooting means the update has no effect. On sbc boards, there is no backup kernel in case of a bad update. And people using compiled modules can really have problems.


    openssl is probably the next important one. And once again, typically unless you restart the service using it, your update is meaningless.


    Your security views are very Windows-based which are very different from a non-desktop, no browser, headless NAS not serving content on the internet. If you are doing the latter, then you should be patching regular and not just relying on automatic security updates.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • The kernel is arguably the most important package to update for security yet auto updates without rebooting means the update has no effect. On sbc boards, there is no backup kernel in case of a bad update. And people using compiled modules can really have problems.


    openssl is probably the next important one. And once again, typically unless you restart the service using it, your update is meaningless.


    Your security views are very Windows-based which are very different from a non-desktop, no browser, headless NAS not serving content on the internet. If you are doing the latter, then you should be patching regular and not just relying on automatic security updates.

    as you suggested i rebooted and ran updates again, nothing new and i am now at 5.6.6-1 will report if i have more errors, i guess its purdent to do a reboot from time to time, should this be scheduled?

    • Offizieller Beitrag

    i guess its purdent to do a reboot from time to time, should this be scheduled?

    You only need to reboot when a package requiring a reboot is installed. From the command line, Debian tells you if a reboot is required by the presence of a reboot-required file in /run/. OMV will tell you the same thing when there is a spinning, circular arrow in the upper right part of the web interface. I see no reason to schedule a reboot as long as you log into your system occasionally (monthly is fine).

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • you're only interested in your point of view and can not (for some reason) see the view point of others.

    well if if this your view and no facts are shared on why this view isn't correct, how should I consider changing my view?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • yet auto updates without rebooting means the update has no effect

    well if that is the truth, the goal for "automate security updates" has NOT been achieved.


    A common requirement for any appliance is that no additional maintenance effort is caused for the owner to operate it in a secure way.

    As stated previously without telemetry data no facts about owners behavior in regards to login & manual updates are available.

    Discussing about opinions is fruitless (at least for the solution)

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Offizieller Beitrag

    well if if this your view and no facts are shared on why this view isn't correct, how should I consider changing my view?


    I already know I can't change your point of view. I've attempted to do so, in times past (with, quite literally, "pages").

    • Offizieller Beitrag

    A common requirement for any appliance is that no additional maintenance effort is caused for the owner to operate it in a secure way.

    I have no idea what kind of appliance you are referring but I know of no appliances that operate that way. Reboots are very disruptive and should only happen when the owner says it is ok to do so. If you want to schedule a reboot, then do so but that does not belong as the standard for OMV.

    Discussing about opinions is fruitless (at least for the solution)

    Being on the Linux security team for a large enterprise company that has thousands of Linux VMs that need security updates in a very similar fashion tells me my opinion has a lot of experience and knowledge behind it.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • crashtest I'm sorry but don't see a concern in the GH issue that was created to jump start the feature.

    Volker's position is manifested as :

    "

    votdev commented on Mar 9 edited


    Security related issues will be applied silently without admin interaction to ensure that they are applied and taken into account immediately.

    "

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • I have no idea what kind of appliance you are referring but I know of no appliances that operate that way

    OMV is an example of such an appliance and should operate that way

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Offizieller Beitrag

    Security related issues will be applied silently without admin interaction to ensure that they are applied and taken into account immediately.

    That is true from the package level. Anything beyond that is disruptive and should be done at the owner's consent. That is standard for Linux admins.

    I'm sorry but don't see a concern in the GH issue that was created to jump start the feature.

    I had many but you ignored as usual because they differed from your "goal".

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    OMV is an example of such an appliance and should operate that way

    Bullshit. OMV is a NAS and no other NAS works this way. No commercial appliance works this way either. I have no idea where you come up with this stuff but if every OMV box automatically patched and rebooted, you are going to have broken systems and/or angry users. Implement this on your own system.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • if every OMV box automatically patched and rebooted, you are going to have broken systems

    why did Linus Torvald bother to integrate atomic Live Patching in the 5.1 kernel?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!