mount problem LUKS after upgrade

  • I get this error message after an upgrade, reboot and trying to unlock one of my LUKS drives:

    Code
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; mount -v --source '/dev/disk/by-uuid/b6c87626-ea4b-4661-abbd-d3b5a2137ea9' 2>&1' with exit code '1': mount: /dev/disk/by-uuid/b6c87626-ea4b-4661-abbd-d3b5a2137ea9: can't find mount source /dev/disk/by-uuid/b6c87626-ea4b-4661-abbd-d3b5a2137ea9 in /etc/fstab.

    This is my folder /dev/disk/by-uuid

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • I did some more digging and found that the disk UUIDs for 2 HDs are somehow mixed up.


    In "/dev/disk/by-uuid" is defined

    sdg --> ....523

    sdf --> .....8ds


    In "LUKS GUI screen" is defined

    sdg --> ....8ds

    sdf --> .....523


    and I can unlock all disk, just mounting of sdg doesn't work and throws the error message above.

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • Is this still related with this thread???

    On the Pi???

    upgrade errors - General - openmediavault

  • Yes its on the Pi. I dont know if it is related but after reboot the mounting doesnt work anymore. Kernel seems stable though.

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • Yes its on the Pi. I dont know if it is related but after reboot the mounting doesnt work anymore. Kernel seems stable though.

    So you DO have a special situation running on the Pi even after I asked you there if you did anything different!!!!

    Sorry but it's difficult to provide proper solutions if the problem is not fully known.


    And I did asked you on the other thread.


    If you have crypto drives, that is why you have to redo the initramfs every time the kernel is updated.

    Otherwise the modules aren't loaded before the mounting of the drives.


    If it's done correctly (which I trust it is due to the initramfs errors on the other thread), it will all happen automatically.

    But if you don't have space on the /boot drive (it's only 256MiB ) it will fail.


    Did you make any of what I described here:

    RE: upgrade errors

  • I wasn't aware that by "special situation" you meant LUKS drives.

    Anyhow, I did not delete any of the old kernels but rebotted and then noticed the LUKS drive issue.


    So in which order shall I proceed?

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • Do you have any updates pending via OMV Gui to see it's output?


    To see if you still having the same errors with the initramfs on the update?


    Otherwise, just follow the #10 on the other thread (link above)

  • Yes. I suddenly have around 30 updates in the GUI list.

    I am now on Kernel 5.10.63 v7l+ or ...v8 (depending on booting the Pi as 64 Bit or 32-bit) and OMV 5.6.21-1

    Shall I run all those updates first?

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • First, you really need to have a good working backup clone of your SD Card, before attempting anything.

    I don't want you to blame me if your system goes kaput, ;)

    depending on booting the Pi as 64 Bit or 32-bit

    I need you to explain me this???

    Are you jumping from architecture on boot? (adding the arm64=1 to the config.txt)?

  • Yes. I usually run on 32-Bit but 12 months ago installed 64-Bit Kernel so it runs in both modes.

    THe LUKS disks worked fine with either. Just after the recent Kernel update and reboot the LUKS/disk order is mixed up.

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • Yes. I usually run on 32-Bit but 12 months ago installed 64-Bit Kernel so it runs in both modes

    You either run it on arm64 or armhf, stick to one or the other.

    uname -a will show what architecture is the kernel. That is the one to follow.


    Just make a clone of the OS and then try the update.

    Post the output here.

  • running on 32-Bit at the moment

    Why?

    From the other thread you posted:

    Quote

    I now rebooted and the current kernel shows as

    Linux pi3 5.10.63-v8+ #1488 SMP PREEMPT Thu Nov 18 16:16:16 GMT 2021 aarch64 GNU/Linux

    How do you jump from 32 to 64bit ?????


    And you keep having the same errors (your /boot is FULL and the update can't regenerate the initramfs)

  • I switch 32-Bit to 64-Bit by changing 1 line in the config.txt.

    I normally run on 32-Bit but because of all these errors I tried 64-Bit to see if it helps.

    So I should remove old Kernels from the Boot folder?

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • right now I am on

    Linux pi3 5.10.63-v7l+ #1488 SMP Thu Nov 18 16:15:28 GMT 2021 armv7l GNU/Linux

    which is 32-Bit as I understand

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • I deleted the files.

    Now there is 154M available on /boot

    OMV GUI doesnt how any updates though.

    Shall I run manually?

    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • When I run apt update, it says all packages up to date

    When I run omv-update, I get this error message


    OMV4 on ProLiant N54L + 5 x 3.5'' WD/Seagate HDs

    OMV5 on Raspberry Pi4

  • I switch 32-Bit to 64-Bit by changing 1 line in the config.txt.

    I know how to change it, what I don't understand is WHY you keep on doing it.

    Reverting back and forth.

    This is forcing your OS to have the repositories for both architectures, not only that and also doubling the space for the debs for both.


    With all the conflicts that come with it, this isn't worth it, sorry to tell you.


    Now, everytime you boot on a different kernel, you need a specific initramfs for it taking double the size needed on /boot (armhf and arm64)


    All I can tell you is to free some of the old files (like I told you before) to at least, the update regenerate a new initramfs without problems.


    The crypto errors will (might) be solved. If not, I can't help you since I don't use crypto (LUKS) drives.

    But the errors for the lack of space on /boot will be solved.

  • When I run apt update, it says all packages up to date

    When I run omv-update, I get this error message


    Because now, you're running arm64.

    And the updates were on armhf.


    Or vice-versa

    i'm completely LOST


    Understand know the paradox?!?

Participate now!

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