[SOLVED] Running new OMV (0.5.18) - can not mount drive?

  • Hi there,


    I am pretty new to Linux in general and even more so if it comes to OMV and NAS server. I am facing an odd problem - I think.
    Checking the forum did not help me (the search does not produce any viable output...).


    I own a little N40L and I am testing OMV. Most of the installation went along the lines you can find http://www.och-group.de/2013/0…-und-debian-installieren/.
    Before I get the bashing yes it runs off a USB key - I have tried Microdrive (via USB) etc. before but it stopped working. It is meant for testing and that sort of for now.


    ====================================================================================
    Update: Issue got fxed in 0.5.19
    Thanks Volker
    ====================================================================================


    0.5.17 vs 0.5.18
    The server comes with 250GB harddrive which should pose as the data drive for now. I did use it with a previous installation (0.5.17) and it was recognized and mounted ok - but with
    0.5.18 I see the device but I can not mount it via the GUI. The drive already holds data I do not want to lose.


    /dev/sda VS /dev/sda1?
    As I can see the harddrive in the 'Physical Disks' (/dev/sda) next to the USB stick (/dev/sdb) I can still not mount it in the filesystem section.
    There it shows only a dev/sda1 device - nothing more. When I attempt to mount it - it says ' device not found' which is quite logical as the device I would be expecting here is /dev/sda only.


    Any idea how to fix this?


    NAST


    Here is the support info - if anyone might ask:


    Some more - error details when attempting to mount:

    Code
    Error #6002: exception 'OMVException' with message 'Device '/dev/sda1' not found' in /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc:665 Stack trace: #0 [internal function]: OMVRpcServiceFileSystemMgmt->mount(Array, Array) #1 /usr/share/php/openmediavault/rpcservice.inc(125): call_user_func_array(Array, Array) #2 /usr/share/php/openmediavault/rpc.inc(62): OMVRpcServiceAbstract->callMethod('mount', Array, Array) #3 /usr/sbin/omv-engined(495): OMVRpc::exec('FileSystemMgmt', 'mount', Array, Array, 1) #4 {main}


    PS. admin: I can not post the support info as it is consideres spam...!??
    search is not working really...



    ====================================================================================
    A workaround - Solution for anyone facing the same problem:
    1. Step : Downgrade to 0.5.17 0 maybe log in your server via SSH (if you can):

    Zitat von "ryecoaaron"

    Go here. All the versions are there.


    Code
    wget http://packages.openmediavault.org/public/pool/main/o/openmediavault/openmediavault_0.5.17_all.deb
    dpkg -i openmediavault_0.5.17_all.deb


    2. Step : You should now be able to mount the drives
    If you have just USB drives (not connected permanently - you might want to stay with 0.5.17 though) [?]
    3. Step : Update the system to 0.5.18 - the drives will be still there and mounted!



    At least it worked for me ;) !

  • Zitat von "Solo0815"

    you can try downgrading

    Code
    apt-get install openmediavault=0.5.17


    ^^^ can't test, if the command works atm, sorry


    Thanks for the reply... I would if I could...


    apt-get install openmediavault=0.5.17 gives me:


    Code
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    E: Version '0.5.17' for 'openmediavault' was not found


    Yes the machine is connectd to the http://WWW...


    Thanks,


    NAST

  • Hi Volker,


    as requested:


    Code
    /dev/sda1: LABEL="Storage" UUID="e8298cfa-9ccf-4efd-836f-47931485c57e" TYPE="ext4" 
    /dev/sdb1: UUID="6c37eaf1-1653-47bb-b978-3ff3b00e9483" TYPE="ext4" 
    /dev/sdb5: UUID="2541a7b4-97dd-49ea-afa3-d9b7cf4d67e3" TYPE="swap"


    and


    Code
    major minor  #blocks  name
    
    
       8        0  244198584 sda
       8        1  244197376 sda1
       8       16    3948544 sdb
       8       17    3732480 sdb1
       8       18          1 sdb2
       8       21     212992 sdb5


    SDA and SDA1 - are they the same but then not?


    Thanks,


    NAST

  • Zitat von "votdev"

    Will be fixed in openmediavault 0.5.19.


    So it is a bug!?
    Since I seem not being able to go back to 0.5.18 I need to wait.
    I wonder if I am the only one affected? Can that be!?


    Cheers,
    NAST


    BTW would a disk - empty so it can be formated by OMV - make a difference at all?

  • Is the version 0.5.17 still existant?
    If no:
    Feature Request:
    After the release of a new version, the old one should be in the repos, so that users like NAST can downgrade.

  • Zitat von "Solo0815"

    Is the version 0.5.17 still existant?
    If no:
    Feature Request:
    After the release of a new version, the old one should be in the repos, so that users like NAST can downgrade.


    I double that... at least the previous version should remain...


    It seems so that the old version vanished from the repo .. at least that is what I get:


    Code
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    E: Version '0.5.17' for 'openmediavault' was not found


    Thanks,
    NAST

    • Offizieller Beitrag

    Go here. All the versions are there.


    Code
    wget http://packages.openmediavault.org/public/pool/main/o/openmediavault/openmediavault_0.5.17_all.deb
    dpkg -i openmediavault_0.5.17_all.deb

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    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!

  • You are not seeing device /dev/sda in filesystems sections of OMV because there is a filesystem on it already. Thus you are seeing /dev/sda1. A storage device before it has partitions or filesystems on it will appear like these examples /dev/sda, /dev/sdb. /dev/sdc. Once you partition it, or put a filesystem on it, then you have names like /sda1, /sda2, sdb1. So if you see anything with a number after the letters you know it has a partition or filesystem on it.

  • Zitat von "KM0201"

    Having the same problem on a vbox install.


    I almost thought I be the only one affect - looks like a serous bug for anyone hooking up a disk w/ data to fresh install of OMV.


    Workaround kind'a
    I did - as suggested - downgrade to 0.5.17 with having the drive in place... I could mount it with no problem.
    Then I did the upgrade via the GUI and the drive is still there running 0.5.18.


    So that can serve as a workaround for anyone on a fresh install facing these problems until the problem is fixed.


    NAST

  • Zitat von "tekkbebe"

    You are not seeing device /dev/sda in filesystems sections of OMV because there is a filesystem on it already. Thus you are seeing /dev/sda1. A storage deivce before it has partitions or filesystems on it will appear like these examples /dev/sda, /dev/sdb. /dev/sdc. One you partition it or put a filesystem on it the have you have names like /sda1, /sda2, sdb1. So if you see anything with a number after the letters you know it has a partition or filesystem on it.


    Even with a file system on there - it should be 'mountable' or am I mistaken?


    Thanks,


    NAST

  • The filesystem should be, yes. I don't know if a partition with no filesystem can be. You want things to be functional in OMV. Some things have to be structured in certain ways so not to break things.

  • My experience:
    After installing two additional harddrives to my omv box I did see them in the list of harddrives and I also could create a filesystem on them but this filesystem could not be mounted. Reason: no entries in /etc/fstab were created after initialising the filesystem. The fs itself is good and it can also be seen in the list of filesystems. Manual mounting works fine and afterwards the fs is marked as mounted and shows the correct size.


    Maybe this is related to manual additions to /etc/fstab ? I added some entries for mounting a nfs share from another server. But as I can see, the omv-related entries are surrounded by special lines inidcating begin and end of omv generated entries. Therefore I don't think that manual additions might break something.


    Currently running OMV 0.5.18

    System: OMV 1 on HP Microserver G7 N54L w/ 16GB RAM and 60GB SSD (backports enabled)
    Storage: 3TB + 2x 1.5TB + 3x1TB HDD

  • Zitat von "x-lette"

    My experience:
    After installing two additional harddrives to my omv box I did see them in the list of harddrives and I also could create a filesystem on them but this filesystem could not be mounted. Reason: no entries in /etc/fstab were created after initialising the filesystem. ...


    Currently running OMV 0.5.18



    I do not think it is related to having edited the fstab - but I am not sure.
    if this does not matter it seems that all are affected by this bug who want to add drives even to an existing setup running 0.5.18.


    NAST

    • Offizieller Beitrag
    Zitat von "tekkbebe"

    You are not seeing device /dev/sda in filesystems sections of OMV because there is a filesystem on it already. Thus you are seeing /dev/sda1. A storage device before it has partitions or filesystems on it will appear like these examples /dev/sda, /dev/sdb. /dev/sdc. Once you partition it, or put a filesystem on it, then you have names like /sda1, /sda2, sdb1. So if you see anything with a number after the letters you know it has a partition or filesystem on it.


    /dev/sda was not the problem.


    I had an additional virtual drive, and I could *see* /dev/sdb1, it would format to a filesystem no problem (ext3, 4, etc.) on sdb w/o issue. When I tried to mount it (ie, sdb1), it would say "/dev/sdb1 does not exist" despite the fact it was showing the partition available and having a filesystem.


    Anyway, Volker obviously knew there was a problem and it's resolved.

Jetzt mitmachen!

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