OMV is labelling one hard disk twice. How To repair?

  • I had initial issues with my openmediavault system because for some reason, one of my hard disks went missing. This disk was in a JBOD linked to the server via a USB3 connector.
    To avoid the issue I ran the following procedure:…ting-usb-sticks-on-debian
    After this I noticed that the system was double labelling disks as in the attached example:

    As you can see Gen1610T0004 is occuring twice when it should occur only once. According to my previous records, there should only be one of this. How can I correct it?
    if I run this I get:

    root@omv:~# blkid -U 8bfc6a26-2a16-416a-92ca-ae9a579ddff6

    And this gives me:

    root@omv:~# blkid -U 95af425e-7c51-4539-ad8f-c67966f3b5fb

    Either this one hard disk is being mounted twice or there is a problem.

    root@omv:~# blkid -L Gen1610T0004

    I know from previous interrogations that /dev/sda1 is

    I have deleted the scripts I initiated in http automount and ran omv-mkconf fstab but I still get no repair.
    Can anyone help repair the damage I did my system?
    My fstab is as follows:

    The config xml and the automount process are attached

    One other variable I should mention is that during booting I get a pause and a request to run a maintenance shell which is kind of difficult since all I can run is fsck which always exits with an e2fsck 8 error.
    I have googled to find out what else to do but the advice to run fsck is e2fsck is tempered by the responses from the system that running fsck on a GPT system is not recommended.
    I'm kind of stuck. Can anyone help?

  • Why don't you undo all the configurations you did?
    autofs shouldbe used in only certain cases. I suspect you haven't deleted your udev rules and that's why youre getting double entries.

    I have deleted all the rules. I followed the process exactly and removed each script but what I have not done is rebooted the server itself.
    I will do that now and report back.

    I rebooted the server and then ssh into it and ran blkid -o list and got this: Now Gen1016T0003 is being counted twice. Should I delete the relevant sections of configuration.xml in the hope that fstab will rebuild?

    Although omv reports the hdd situation accurately except that it is now reporting a communication failure. sigh!

    I have donated. have you?
    OMV 2.2 running on HP Gen 8 G1610T server, 16GB RAM + Xeon E3-1220

    Edited once, last by seanbw ().

  • After rebooting both my client machine and the server itself, the problem has been resolved.
    Thanks for your assistance.

    I have donated. have you?
    OMV 2.2 running on HP Gen 8 G1610T server, 16GB RAM + Xeon E3-1220

Participate now!

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