Upgrade to Arrakis "killed" my data disk...

  • Hi,


    no, the data disk is not killed, the data is there and can be manually mounted. This as a foreword...


    Upgrade did fine so far, but there are strange things happening with the data drive. It is found under disks, fine:


    But looking at file systems shows...


    Disk usage is complete empty:

    Completely missing here:


    Code
    root@omv:~# blkid
    /dev/sdb1: UUID="47ab5528-bac0-4715-a145-4860c4333093" TYPE="ext4" PARTUUID="0003ab15-01"
    /dev/sdb5: UUID="d33f1c6e-d56c-4f70-9161-1fe359b59419" TYPE="swap" PARTUUID="0003ab15-05"



    Things that may be helpful:




    Anything else needed?
    Can please someone help me outta this? Thanks in advance...


    Edit: And I receive mails like:


    --
    Get a Rose Tattoo...


    HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
    OMV 5.5.23-1 Usul i386|4.19.0-9-686-pae

    • Offizieller Beitrag

    This is a known issue. It seems that there is some issue with the RAID or filesystem metadata created on Debian 8 (maybe 7, too) which is now not correctly read in Debian 9, so blkid can not detect the RAID incl. the filesystem. The problem is that this does not happen always, this means there is some relation between hardware and/or the OS/kernel OMV3 was running on when the RAID was created.


    I was not able to reproduce this behaviour on test machines and my production system.


    Other people that were affected by this copied the data to a second disk and recreated the RAID from scratch.

  • Hi Volker,


    thanks for the quick answer. Interesting, I never created a Raid. I did some investigation and found that

    Code
    root@omv:~# file -s /dev/sda1
    /dev/sda1: Linux rev 1.0 ext4 filesystem data, UUID=4a255c48-12f0-43da-8e6e-c0f650dfe8b7, volume name "Gummiplatte" (extents) (large files) (huge files)


    finds all that is needed, I think...


    But

    Code
    tune2fs /dev/sda1 -U 4a255c48-12f0-43da-8e6e-c0f650dfe8b7


    seems to do something, but blkid does not show anything afterwards...


    I will copy the disk at first and go to play around; there must be an easier way, I think

    --
    Get a Rose Tattoo...


    HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
    OMV 5.5.23-1 Usul i386|4.19.0-9-686-pae

  • ananas, looks promising (Partition is shown as ZFS-Member in wipefs).
    Can´t go further yet, still copying data from the drive...


    Question in advance: where and how to download util-linux-2.32?
    Will it not interfere with the installed wipefs?


    Tia

    --
    Get a Rose Tattoo...


    HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
    OMV 5.5.23-1 Usul i386|4.19.0-9-686-pae

  • If I remember correct ...
    You need to have "build-essential" installed.


    util-linux is available here: https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/
    Download, extract, ./configure, make but do not "make install"
    It was running from the directory where I had compiled it.


    But as other users had reported, the wipefs that ships with debian seem to have done the trick too.
    My issue with the "onboard" wipefs was, that it did just report ONE zfs signature whereas the one that I had compiled
    showed all zfs signatures.
    Maybe you can get along with version 2.29.2
    anyway, do "man wipefs" and read carefully !


    repeat
    1. "wipefs -n" to list signatures
    2. "wipefs -o <offset reported by wipefs in step 1> -t zfs" to get rid of ONE zfs signature
    until there are no more zfs signatures listed


    My filesystem got mounted after deleting the last zfs signature.


    Good luck,
    Thomas

  • ananas, you´re the man!


    After copying has finished, I unmounted the partition and tried with the onboard wipefs.
    Kinda work, it showed 30 (!) different offsets. Deleted them all and anything is back again, including disk usage.


    Thanks so much!


    Alas, this should be pinned for everyone who is in this trouble...

    --
    Get a Rose Tattoo...


    HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
    OMV 5.5.23-1 Usul i386|4.19.0-9-686-pae

    • Offizieller Beitrag

    this should be pinned for everyone who is in this trouble...

    I don't recommend this for most users. Not only do you install a newer version not intended for your system but now it won't get updates. This could be easily scripted to work with existing version of wipefs.

    Kinda work, it showed 30 (!) different offsets. Deleted them all and anything is back again, including disk usage.

    Do you have the output when it showed the 30 offsets? That would let me write a one liner to wipe everything instead of updating util-linux.

    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!

  • I don't recommend this for most users. Not only do you install a newer version not intended for your system but now it won't get updates. This could be easily scripted to work with existing version of wipefs.

    Do you have the output when it showed the 30 offsets? That would let me write a one liner to wipe everything instead of updating util-linux.

    No, I didn´t install anything...


    Zitat

    It didn´t show the 30 offsets at a time. It shows them one by one. You have to copy each Hex offset seperately reported by

    Code
    wipefs -n


    into

    Code
    wipefs -o <offset reported by wipefs in step 1> -t zfs


    until no more ZFS offsets are shown. Thats all. Nothing to install 8o

    --
    Get a Rose Tattoo...


    HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
    OMV 5.5.23-1 Usul i386|4.19.0-9-686-pae

  • What the hell is going on, #9 is under moderation? Why?



    Zitat

    Dieser Beitrag muss zunächst von einem Moderator geprüft und freigeschaltet werden, damit er für alle Benutzer sichtbar wird.

    --
    Get a Rose Tattoo...


    HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
    OMV 5.5.23-1 Usul i386|4.19.0-9-686-pae

    • Offizieller Beitrag

    What the hell is going on, #9 is under moderation? Why?

    Post is kind of long, quite a few quotes, and edited. The filter is touchy.


    Interfere, even if he did not execute
    make install ?

    Some people probably will execute make install.
    make install just moves it to a directory in your path. Doesn't mean it won't be used.
    util-linux is more than just wipefs.
    If you build it, you will probably use it more than once but never update it.
    It is untested.
    Avoids filing a bug report.
    No need since the installed wipefs will work. Just needs to be run more than once.


    One liner to do that (run as root not sudo) - will wipe the entire disk:


    disk="/dev/sdX"; while wipefs -n ${disk} | grep ^0x; do echo "wipe"; wipefs -a ${disk}; done

    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!

    Einmal editiert, zuletzt von ryecoaaron ()

  • According to the man page of wipefs:


    -a, --all
    Erase all available signatures. The set of erased signatures can be restricted with the -t option.


    That is no good idea or just a typo ?


    Cheers,
    Thomas

    • Offizieller Beitrag

    That is no good idea or just a typo ?

    As you can see in my one liner, it is using the -a flag. If you are just trying to clear some signatures and keep data, the -a flag is bad.


    There is a "bug" in wipefs in util-linux 2.29 that only "sees" one signature at a time. So, wipefs -a only wipes the one it sees. If you run it again, it will find another one and will be able to wipe that. I haven't been able to create a disk with more than one signature. So, I'm not quite sure what causes this but it is fixed in 2.32+.

    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!

Jetzt mitmachen!

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