unattended-upgrades decided to uninstall openmediavault packages - why?

  • Hi, first a big thank you for this sexy software - like it very much!


    But - unattended-upgrades decided to uninstall all openmediavault-packages - why?


    Removing openmediavault-sharerootfs (5.0.2-1) ...

    Removing openmediavault-lvm2 (5.0.3-1) ...

    Removing openmediavault-symlinks (5.0) ...

    Removing omvextras-common (5.0) ...

    Removing openmediavault-backup (5.2.4) ...

    Removing openmediavault-borgbackup (5.1.9) ...

    Removing openmediavault-luksencryption (5.0.2) ...

    Removing openmediavault-omvextrasorg (5.6.4) ...

    Removing openmediavault-remotemount (5.0.3) ...

    Removing openmediavault-resetperms (5.0) ...

    Removing openmediavault (5.6.20-1) ...

    Removing ethtool (1:4.19-1) ...

    Processing triggers for man-db (2.8.5-2) ...

    Log ended: 2021-12-02 06:29:31



    While probably it is easy to re-install I am really interested in why such a thing could happen - I usually view apt as a very reliable system, in fact it is the main reason for choosing Debian based systems for everything that should just work. And of course the unattended-upgrade package seems essential to everything that should just work, too.


    so I would like to better understand what went wrong here and how such a thing can be avoided.


    Thanks for your attention!


    Foxy Lady

  • Some more logs from unattended-upgrades.log:


    Code
    2021-12-02 06:29:12,186 INFO Initial whitelist:
    2021-12-02 06:29:12,186 INFO Starting unattended upgrades script
    2021-12-02 06:29:12,187 INFO Allowed origins are: origin=Debian,codename=buster,label=Debian, origin=Debian,codename=buster,label=Debian-Security
    2021-12-02 06:29:17,824 INFO Packages that will be upgraded: libsmbclient libwbclient0 python-samba samba samba-common samba-common-bin samba-libs samba-vfs-modules smbclient
    2021-12-02 06:29:17,825 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
    2021-12-02 06:29:19,297 WARNING Keeping auto-removable python3-yaml package(s) because it would also remove the following packages which should be kept in this step: samba-common
    2021-12-02 06:29:19,954 WARNING Keeping auto-removable libnginx-mod-mail package(s) because it would also remove the following packages which should be kept in this step: nginx-light
    2021-12-02 06:31:06,666 WARNING Keeping auto-removable samba-common-bin package(s) because it would also remove the following packages which should be kept in this step: libsmbclient libwbclient0 samba-common samba-libs
    2021-12-02 06:36:37,055 INFO Packages that were successfully auto-removed: acl beep borgbackup btrfs-progs chrony cifs-utils collectd collectd-core cron-apt davfs2 dctrl-tools ethtool f2fs-tools fsarchiver gdisk jfsutils jq libarchive13 libb2-1 libdbi1 libf2fs-format4 libf2fs5 libfile-slurp-perl libgd3 libhiredis0.14 libjavascript-minifier-xs-perl libjq1 libjs-extjs6 libjson-perl liblocale-po-perl liblzo2-2 libmemcached11 libmemcachedutil2 libneon27 libnginx-mod-http-auth-pam libnginx-mod-http-dav-ext libnginx-mod-http-echo libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-subs-filter libnginx-mod-http-upstream-fair libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream libnorm1 libnss-myhostname libntfs-3g883 libonig5 libossp-uuid16 libpgm-5.2-0 librrd8 libsensors-config libsensors5 libsodium23 libxpm4 libxxhash0 libyaml-0-2 libzmq5 mdadm monit netplan.io nfs-kernel-server nginx nginx-common nginx-full ntfs-3g omvextras-common openmediavault openmediavault-backup openmediavault-borgbackup openmediavault-luksencryption openmediavault-lvm2 openmediavault-omvextrasorg openmediavault-remotemount openmediavault-resetperms openmediavault-sharerootfs openmediavault-symlinks php-bcmath php-cgi php-common php-fpm php-mbstring php-pam php-symfony-class-loader php-xml php-yaml php7.3-bcmath php7.3-cgi php7.3-cli php7.3-common php7.3-fpm php7.3-json php7.3-mbstring php7.3-opcache php7.3-readline php7.3-xml proftpd-basic proftpd-mod-vroot python-crypto python-dnspython python-ldb python-samba python-tdb python3-cached-property python3-click python3-colorama python3-dateutil python3-dialog python3-distro python3-jinja2 python3-llfuse python3-lxml python3-markupsafe python3-msgpack python3-natsort python3-netifaces python3-psutil python3-pycryptodome python3-pyudev python3-systemd python3-yaml python3-zmq quota quotatool rrdcached rrdtool rsync salt-common salt-minion samba samba-common-bin samba-vfs-modules sdparm smartmontools smbclient socat sshpass sudo tdb-tools uuid wsdd xfsprogs xmlstarlet
    2021-12-02 06:36:37,056 INFO Packages that are kept back: libnginx-mod-mail python3-yaml samba-common-bin

    sorry for posting inline code in the first msg - too many hours in front of the screen already...


    Thanks again!

  • But - unattended-upgrades decided to uninstall all openmediavault-packages - why?

    First:

    What is unattended-upgrades?


    Second:

    Did you ever saw what the script really does?


    Third:

    You should be asking that question to whoever created unattended-upgrades script.

  • hd-idle is very likely not the root cause.

    On what platform (x86, arm) are you running OMV?
    For better troubleshooting most forum users add this info to their signature (see mine below)

    omv 6.0.8 (Shaitan) on RPi CM4/4GB with 64bit Kernel 5.10.63

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


    omv 5.6.21-1 (usul) on RPi4/4GB with Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs 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

  • First:

    What is unattended-upgrades?

    I think it is what is used for the security updates. Installed by OMV unless you prevent it

    https://packages.debian.org/bullseye/unattended-upgrades


    EDIT:

    omv does not use unattended-upgrades


    If you want to disable the automatic security update feature of OMV:

    END EDIT

    Code
    omv-env set OMV_APT_USE_OS_SECURITY false
    omv-salt stage run prepare
    omv-salt deploy run apt
    omv-aptclean
  • I think it is what is used for the security updates. Installed by OMV unless you prevent it

    https://packages.debian.org/bullseye/unattended-upgrades


    Code
    omv-env set OMV_APT_USE_OS_SECURITY false
    omv-salt stage run prepare
    omv-salt deploy run apt
    omv-aptclean

    You pointed to Bullseye but OP is on Buster.


    Does that install without user intervention?

    Didn't ryecoaaron removed (or set it to off) a while back?

  • Didn't ryecoaaron removed (or set it to off) a while back?

    Nope. That is an OMV feature.

    omv 6.0.8-1 Shaitan | 64 bit | 5.15 proxmox kernel | omvextrasorg 6.0.5 | kvm plugin 6.0.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I think it is what is used for the security updates. Installed by OMV unless you prevent it

    Seems the security updates on OMV are implemented differently

    https://github.com/openmediavault/openmediavault/issues/980

    https://github.com/openmediava…2520d98dc2f8dfcff471b684b

  • Nope. That is an OMV feature.

    Ok. But is it always false and user is the one to set it to true or something else?


    And now, the OP situation happened do to the setting beeing true?


    Makes no sense otherwise more people would experience the same, I guess.

  • Ok. But is it always false and user is the one to set it to true or something else?

    It defaults to true.


    And now, the OP situation happened do to the setting beeing true?


    Makes no sense otherwise more people would experience the same, I guess.

    All I can guess is the system had the openmediavault package or one its dependencies in a partially installed state and unattended-upgrades uninstalled taking the plugins with it.

    omv 6.0.8-1 Shaitan | 64 bit | 5.15 proxmox kernel | omvextrasorg 6.0.5 | kvm plugin 6.0.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • It defaults to true

    Don't want to beat around the bush, but this got me worried, since I'm always long periods away:


    On my OMV5 (5.6.21-2) arm64,:

    Code
    Linux XXXXXXX 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64
    .........
    pi@XXXXXX:~ $ sudo omv-env get OMV_APT_USE_OS_SECURITY
    pi@XXXXXX:~ $

    But on my OMV5 (5.6.21-2) armhf:

    Code
    Linux XXXX 5.10.63-v7l+ #1496 SMP Wed Dec 1 15:58:56 GMT 2021 armv7l
    .........
    pi@XXXX:~ $ sudo omv-env get OMV_APT_USE_OS_SECURITY
    OMV_APT_USE_OS_SECURITY=false


    Checked a just now install of OMV6 (6.0.5) and it shows:

    Code
    Linux tacho 5.10.63-v8+ #1488 SMP PREEMPT Thu Nov 18 16:16:16 GMT 2021 aarch64
    .......
    pi@tacho:~ $ sudo omv-env get OMV_APT_USE_OS_SECURITY
    OMV_APT_USE_OS_SECURITY=false


    All of this status are without my intervention.

    Can I rest assure that it will never turn to the default =true???


    unattended-updates is so Windowz and the first thing to set to OFF as soon as possible (personal choice).

  • Can I rest assure that it will never turn to the default =true?

    I guess it is possible on the system where it is not explicitly set.

    unattended-updates is so Windowz and the first thing to set to OFF as soon as possible (personal choice).

    Actually Ubuntu has been using it longer than Windows. I even use it at work on Ubuntu on hundreds of VMs. Never had a problem with it. I haven't seen any issues with it on the 15 or so VMs and other machines I have running OMV at home either.

    omv 6.0.8-1 Shaitan | 64 bit | 5.15 proxmox kernel | omvextrasorg 6.0.5 | kvm plugin 6.0.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • unattended-updates .... set to OFF (personal choice).

    Might be a good choice for experienced IT admins but a bad choice for the first time Linux user coming from a Windows background.

    omv 6.0.8 (Shaitan) on RPi CM4/4GB with 64bit Kernel 5.10.63

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


    omv 5.6.21-1 (usul) on RPi4/4GB with Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs 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

    Edited once, last by mi-hol ().

  • omv-env get will only show values in /etc/default/openmediavault

    If you did not change it, it will not be shown

    That is the point on my questions:


    I never change any of the settings, but they are there and with =false


    Except on the arm64 OMV5 that throws a blank.

    Running omv-env list doesn't even show it available.

    [EDIT]

    It's there, sorry

    [/EDIT]


    Might be a good choice for experienced IT admins but a bad choice for the first time Linux user coming from a Windows background.


    Since (IIRC) you were the most enthusiastic enforcer of the unattended-upgrades, I understand and accept your opinion.

    And I would agree with you if I was an experienced IT admin but I'm not.


    I'm just a Windows background user that had too many failed/problematic unattended-updates that I choose to keep the updates in control.

    I choose to first see what is the update, what it does and the changelog of what it does.


    And, honestly, it only takes an instant to scroll through the available updates and check them.

    Don't need to be an IT admin, only to read.

  • I can assure you that unattended-upgrades is not comparable to Windows, same as the whole packaging system, especially on Debian, is absolutely not comparable to anything that you might know from the Windows world. You should not apply Windoz xperiences to Linux world, this makes no sense at all. The name "Debian" stands for "updates never hurt" and I can assure you that this is true for very mucho admins everywhere on the planet / galaxy...


    The unattended-upgrades package runs on hundreds of debian machines without any problems [for us] since many years, except maybe for desktop installs with custom repos - we are talking minimal servers here of course. Minimal problems occur of course everywhere, but not this kind of brutal deinstallation of vital packages - this is a very uncommon event.


    Also I did not notice these kind of problem on any non-omv machine, so my first attempt to investigate is here, not the original package - I might turn to them, of course, when I decide to dig deeper. For now this is just one more yellow note on the board of "things to investigate" - and maybe omv devs should watch if that happens in other places, too.


    Thank you very much for your attention - i will put all logs and shell history to some safe place and go on to investigate on that one day when suddenly nothing else needs to be done...


    However, watch your unattended-upgrades!


    Thanks again for your cooperation!


    Cu l8ter!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!