Odroid dev-disk-by-id

  • I've had an Odroid HC2 running the OpenMediaVault image since February. Iv'e had my fair share of issues and worked through them. I'm posting because I would really like to understand why my mount points were renamed twice since I've owned it. I've searched all over and mostly resolved my issues. However, I haven't come across anyone with this specific issue.


    It seems that my initial install mounted my SATA drive as /srv/dev-sda1 or similar. Later, I believe an update changed this to /srv/dev-disk-by-id-ata etc etc. I went through the process of recreating the sharedfolders in webui and recovered. Recently I performed an apt upgrade and my drive is now mounted at /srv/dev-sda1. The remaining space on my SD card, mmcblk1p3, is now mounted as dev-disk-by-id-mmc- but this name is slightly different from what it was prior to the most recent apt upgrade. I think I have everything corrected to point to the new paths; most services seem to be working as expected. However, my /sharedfolders is not being mounted at all. Additionally, my drive is not being mounted automatically at reboot. I have to navigate to Storage > File Systems in the webui and click mount. Afterwards, some of the services need to be restarted to work correctly. My /sharedfolders is not being bound, either. In the webui, all sharedfolders exist and have been re-linked to "new" drive.


    Any ideas what happened? I'm assuming the underlying distro is more at fault than openmediavault, but it would be great to get some help resolving my openmediavault issues created by this change.


    thanks for your help.

    • Offizieller Beitrag

    I am also using an HC-2, but I did not have the issues you are mentioning.


    What I also notice is this:

    Additionally, my drive is not being mounted automatically at reboot.

    I solved this by adding a mount -a job at reboot. No problem since I added it.

    • Offizieller Beitrag

    Sound very strange. I think you have a corrupt install. Sorry! Perhaps even a corrupt SD card. Not good.


    When I first tried OMV on a HC2, for a few days I did a lot of experimenting and testing and had some very strange experiences I had problems to recover from. And I had to start over several times.


    But then, after a while, the testing was over!


    I started from scratch and did a new clean install without any testing or experimenting at all. No fixes. Nothing but exactly what I wanted and already KNEW worked fine! And I backed up the SD card a few times along the way, so I wouldn't have to start from scratch in case of mistakes and errors. And so that I now CAN test and experiment and easily revert back to a known good pristine configuration, without having to start over from scratch. This is how I think you are supposed to run a server...


    I run only OMV on my OMV HC2s. No extra software at all, except MC and RPi-Monitor.


    And my two current OMV HC2s now boots and runs perfectly without any issues or extra fixes at all. Latest everything. I have never had any problems when upgrading either. But I still make sure I have at least one fresh backup of the SD card before I upgrade anything. My OMV installs are still pristine! And they function like it... They are not very complex, so they would be easy to reinstall from scratch.


    I run a lot of server stuff (Plex/LMS/Node-JS/Node-Red/MariaDB/SQLite/Apache/PHP) on an Armbian HC2 but then NOT from a SD card but from a root filesystem on an SSD. And it is still pristine as well. But not so quick to reinstall from scratch. If I boot from a "rescue" SD card (root filesystem remain on the SD card) I can safely backup or restore the offline root filesystem on sda1 to another partition or even to a share on an OMV HC2. Again, this is how I think you are supposed to run a server...


    Anything that can go wrong will go wrong!

  • those of you that are using the OMV image for HC2 (and similar) can you tell me how the system names your drives? is it sda1 or disk-by-id? what controls this? is it kernel?


    i am considering starting over from a clean slate, but ... well you know...

    • Offizieller Beitrag

    You are probably confused by the different naming of block devices (like HDD).
    Hopefully this article helps:


    https://wiki.archlinux.org/ind…stent_block_device_naming


    In /dev/disk/  you will find the different persistent block device names on your system.


    However, most important is where the drive is mounted. OMV mounts the devices as


    /srv/dev-diks-by-label-<LABEL>

  • yup, i broke it somehow. it was mounting in /srv/dev-sda1. i got another sd card and booted fresh image. drive is being mounted as /srv/dev-disk-by-id on clean image. i guess i'll be migrating to the new card since there doesn't seem to be another way to clean up my mess.

  • Just had the same issue.


    I have an Odoird-HC2 as well, my disk used to be mounted as /srv/dev-disk-by-id-ata-WDC_........-part1 and all of a sudden it decided to mount as /srv/dev-sda1


    The only think I think I have changed was the acoustic mode of the hard drive from performance to quiet. It then failed after a reboot.


    I have mounted the drive as dev-sda1 and changed all the sahredfolders to match, then updated all of my dockers fingers crossed it doesn't decide to change its mind back again!


    Just checked and the drive is not automounting either.


    Guess I'll be building a new SD card then...

  • Mounting by device ID such as /srv/dev-sda1 is not a good idea if you have more than one disk. How disks are enumerated that way is a matter of timing and if the ID changes all hardcoded specifications will be wrong and lots of things will be broken.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

Jetzt mitmachen!

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