update from 7.4.17 to 7.5.0 failed

    • Official Post
    Quote from SiliconSage

    But I was talking about the technical backgrounds. For me as an end user (on amd64 actually) it is just too risky to update my server and have to be afraid every time it could break.

    On amd64, you are using pure Debian. Debian is one of the most stable distros in the world. If you are worry that much, that is being overly paranoid. You should have an identical test system to test updates on and be testing backups/restores. I have servers that are used by almost every employee at a large enterprise and I worry less than you do about your OMV box.

    Quote from SiliconSage

    Did Volker consider to use some other base like Buildroot?

    I know what it does but I fail to see how it would've helped this situation.

    omv 8.0.6-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.2 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


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


    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!

    Hello, I don't know if I'm here right, but lets see:


    My OMV version on an 2014er Intel i3 CPU system is:
    7.4.17-2 (Sandworm), Linux 6.1.0-31-amd64

    My research is telling it is from December 2024 and that there are some udates since then. Should I see (via the browser-GUI) those updates if the option:

    Community-maintained updates

    is exclusively enabled? If the answer is yes:

    What can I do to get the latest version?


    Thanks!

    _Michael_


    P.S. I will move to new HW and one advice (for a move with "omv-regen" support) is to 1st get to the latest released OMV state.

    Edited 3 times, last by _Michael_: minor text correction made ().

    Quote from _Michael_

    Should I see those updates if the option:

    Community-maintained updates

    is exclusively enabled?

    The real question is why you have it enabled?


    This is how it should be, unless you know what it does (which by your doubts, doesn't look like it)



    Quote from _Michael_

    What can I do to get the latest version?

    All you need is to click the magnifying glass and see if any updates show up:




    If not, then there's no updates.


    To confirm that everything is running proper, regarding updates, run and post the output inside a CODE box of:

    sudo omv-upgrade

    This CLI command

    sudo omv-upgrade

    did the job :-), now I have 7.7.0-2 (Sandworm).


    P.S. If someone is wondering why I have not answered on Somas input: I wrote this in parallel to Soma.

    Edited once, last by _Michael_: text with "P.S." extended ().

    Thanks for your information, Soma. I don't know why this setting is as I wrote. Until December I had never an issue with OMV updates. Could be I did a mistake, but I'm aware to not change settings I'm not familar with.

    Quote from _Michael_

    Thanks for your information, Soma. I don't know why this setting is as I wrote. Until December I had never an issue with OMV updates. Could be I did a mistake, but I'm aware to not change settings I'm not familar with.

    If you were able to see updates with the omv-upgrade command but not on the GUI then something is going in that need to be "fixed"

    How did you get to OMV7?

    Did you upgraded recent from OMV6 to 7?


    What is the story of your system?

    Quote from Soma

    1) f you were able to see updates with the omv-upgrade command but not on the GUI then something is going in that need to be "fixed"

    2) How did you get to OMV7?

    3) Did you upgraded recent from OMV6 to 7?


    4) What is the story of your system?

    1) Yes, it seems so :( because after my update I tried (after a reboot) to un-check the

    Community-maintained updates

    but get now the 3rd time this error:

    The method 'getSettings' does not exist for the RPC service 'Apt'.

    OMV\HttpErrorException: The method 'getSettings' does not exist for the RPC service 'Apt'. in /usr/share/php/openmediavault/rpc/rpc.inc:91

    Stack trace:

    #0 /usr/sbin/omv-engined(544): OMV\Rpc\Rpc::call()

    #1 {main}

    2) and 3) I triggered a CLI update from OMV6 to OMV7 last year, I cannot remember the month (but it was not December where 7.4.17-2 was released).

    4) It could be that I started with OMV4 because my current OMV-NAS hardware was 1st installed end of 2019.


    Addendum: Last year I installed a 2.5 GBit network card as replacement for the built in 1 GBit device, see my thread. There is also the info that in Jul I was still at OMV 6.9.16-1.

    Quote from _Michael_

    It could be that I started with OMV4 because my current OMV-NAS hardware was 1st installed end of 2019

    At that time, it was already OMV5 (IIRC)

    Quote from _Michael_

    2) and 3) I triggered a CLI update from OMV6 to OMV7 last year, I cannot remember the month (but it was not December where 7.4.17-2 was released)

    Run and post the complete outputs inside CODE boxes of:

    dpkg -l | grep openm


    omv-aptclean repos


    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/fix6to7upgrade | sudo bash

    Quote from _Michael_

    Your request "...post the complete outputs" will "overload" my post / answer, too much rows (> 1000) output.

    Just paste it to a txt file and attach it to the post.

    Quote from _Michael_

    I provided a text file in the link.


    P.S. Your commands have fixed the error at my un-check task of

    Community-maintained updates

    It seems that your kernel was updated to the backports v6.12 because it was activated.

    It also shows a huge amount of left-overs of previous kernels.


    The system should be asking for a reboot but before that, I advise you to install the kernel plugin and remove the unneeded one's to clear some space.


    As for the rest, all output looks OK.


    Quote from _Michael_

    P.S. Your commands have fixed the error at my un-check task of

    :thumbup:

    If you go on removing kernels, just make sure that you leave these 2:


    Code
    Found linux image: /boot/vmlinuz-6.12.9+bpo-amd64
Found initrd image: /boot/initrd.img-6.12.9+bpo-amd64
Found linux image: /boot/vmlinuz-6.1.0-31-amd64
Found initrd image: /boot/initrd.img-6.1.0-31-amd64
    Quote from Soma

    It seems that your kernel was updated to the backports v6.12 because it was activated.

    It also shows a huge amount of left-overs of previous kernels.


    The system should be asking for a reboot but before that, I advise you to install the kernel plugin and remove the unneeded one's to clear some space.

    I'm sorry but after a reboot request I do so, i.e. for the old kernels clean-up "is it too late". This should not be a problem: I will install OMV7 from scratch at my new HW and then use omv-regen to get my settings back and I expect not to see the outdated kernels again.

    Quote from _Michael_

    I'm sorry but after a reboot request I do so, i.e. for the old kernels clean-up "is it too late".

    If the system booted without any issue, you can do it now and keep using the backports kernel as default.

    I told you to do it before reboot, because some users had some issues with that version.

    Quote from _Michael_

    This should not be a problem: I will install OMV7 from scratch at my new HW and then use omv-regen to get my settings back and I expect not to see the outdated kernels again.

    If you are just going to move the system from x64 hardware to another x64 hardware, you don't need to use omv-regen.


    All you need is to move all drives to the new system, set the boot to the same old OS drive and run locally omv-firstaid to reconfigure the ethernet NIC.

Participate now!

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

Register Yourself Login