Upgrade path from 5 to 6

  • macom

    Hat das Label OMV 6.x (alpha) hinzugefügt.
  • Will omv6 go back (early omv5) to mounting drives based on Name vs current uuid?

    Linux Mint, EndeavourOS Arch Linux

    OMV6 NAS, bond0 LACP, Fractal Design Define R5 Case, Kodi "Omega", FreeBSD pfSense Plus firewall/router

    • Offizieller Beitrag

    Will omv6 go back (early omv5) to mounting drives based on Name vs current uuid?

    No, because filesystem labels make more trouble than they help.


    Example:

    A Windows user has multiple USB devices from the same product. All of them are named Traveller out-of-the-box by the manufacturer.

    Now the inexperienced user configures one USB device in OMV. The device is named /dev/disk/by-label/Traveller. The user now plugs another device of the same product and reboots. On next boot the kernel does not know which of the device is the correct one, because both are named Traveller.


    This has happend very often here in the forum. Because of that filesystem identifiers are much better than labels. At the end, the devicefile is somewhat uninteresting for the end-user of OMV, it should simply work, and that's what OMV is delivering.

    • Offizieller Beitrag

    Will omv6 go back (early omv5) to mounting drives based on Name vs current uuid?

    So with that cleared up... using UUIDs really isn't that difficult with OMV 6. There is a simple "copy" button when you show the absolute paths in the file system. This copy's the absolute path to the clipboard, and then you can just paste it into your docker-compose/stack file. Really is just that simple.


    The other option would be to learn to use symlinks, to make some simple paths to use (my personal solution)

  • So, you suggest that because of "unexperienced" user does not know that they need to unmount devices (drives) in UNIX and the "little siblings" known as Linux, we should be forced to use symbolic links to accommodate their lack of knowledge. So, having said that, your example is just wrong. It shows exactly what you should NOT do in UNIX, you DO NOT just "unplug" USB or any other drives, you unmount them.

    Linux Mint, EndeavourOS Arch Linux

    OMV6 NAS, bond0 LACP, Fractal Design Define R5 Case, Kodi "Omega", FreeBSD pfSense Plus firewall/router

  • So with that cleared up... using UUIDs really isn't that difficult with OMV 6. There is a simple "copy" button when you show the absolute paths in the file system. This copy's the absolute path to the clipboard, and then you can just paste it into your docker-compose/stack file. Really is just that simple.


    The other option would be to learn to use symlinks, to make some simple paths to use (my personal solution)

    FYI. Been sysadm on UNIX (SGI Irix) networks for over 20 years. Early releases of OMV5 (5.0.5) used mount by name method, later on changed to uuid. Why, I do not know. Just asking.

    Linux Mint, EndeavourOS Arch Linux

    OMV6 NAS, bond0 LACP, Fractal Design Define R5 Case, Kodi "Omega", FreeBSD pfSense Plus firewall/router

    • Offizieller Beitrag

    FYI. Been sysadm on UNIX networks for over 20 years. Early releases of OMV5 (5.0.5) used mount by name method, later on changed to uuid. Why, I do not know. Just asking.

    It was already explained to you why it had to change in votdev's post. Your experience with other systems, and even previous OMV releases, is not relevant. This was a significant issue for new users and caused them a lot of headache, thus why it had to change.

    • Offizieller Beitrag

    There is a simple "copy" button when you show the absolute paths in the file system.

    The copy button is a new feature in OMV 6. KM0201 ’s comment about Symlinks is the way to go.

    • Offizieller Beitrag

    So, having said that, your example is just wrong. It shows exactly what you should NOT do in UNIX, you DO NOT just "unplug" USB or any other drives, you unmount them.

    You do realize that you're trying to lecture a seasoned and accomplished developer, who has probably forgotten more about Linux (or UNIX) than you and I will ever know?

    BTW: UNIX proper is -> pretty much dead, along with IRIX which hasn't been developed in several years. Linux, it's ancestor, is alive, well and growing far faster than any of the offspring of the UNIX family .

    • Offizieller Beitrag

    You do realize that you're trying to lecture a seasoned and accomplished developer, who has probably forgotten more about Linux (or UNIX) than you and I will ever know?

    BTW: UNIX proper is -> pretty much dead, along with IRIX which hasn't been developed in several years. Linux, it's ancestor, is alive, well and growing far faster than any of the offspring of the UNIX family .

    While his delivery could use some work, we all know he is right.. you just don't "unplug" a USB drive (and I'd hope he is aware votdev knows this).... The issue he doesn't seem to grasp is OMV is not meant to require sysadmin level skills to set up and manage. It is meant for novice users who with little effort on their part can turn a spare PC into an excellent NAS. He's been a member here for 6mo, and hasn't posted much, so maybe he hasn't seen the questions that were the equivalent of "PLEASE HELP, THIS SQUARE PLUG WILL NOT FIT IN THE ROUND HOLE, WHAT SHOULD I DO!!!!" Lord knows with the transition from plugins to docker on many things, some folks seem to think it's the end of the OMV.


    Those of us who are here regularly and support some of these new users... know the problems the labels were causing.... UUID's are fine... as has been said, use symlinks if you want to use something easier (there's even a plugin for it if you don't want to do it manually)

    .

    • Offizieller Beitrag

    The issue he doesn't seem to grasp is OMV is not meant to require sysadmin level skills to set up and manage.

    This is, truly, the crux of the matter. Developers must deal with the actions of users, the bulk of which range from enthusiasts to complete novices. It is coping with that reality that makes an OS or a package like OMV viable. Along those lines, users will "unplug" USB drives without unmounting them. That's a fact.

    Further, users will simply plug in a thumbdrive, multiples of the exact same version from the same OEM, without formatting them. Hence the disk/by-label issue. UUID is an effective way to deal with it.

  • This is, truly, the crux of the matter.

    I know this will sound rude, but for this EXACT matter, then unless people plan on sitting around their NAS as if it's a campfire, hot plugging USB devices like an ape probing for ants, most of this discussion is irrelevant :-/.


    As for the upgrade path, I'm taking that the answer is no. However, I'm more curious of the planned differences between OMV 5 and 6. For example, is 6 a fundamental-might-break things update, or more of a new-flashy-ornaments with a GUI update.

    • Offizieller Beitrag

    then unless people plan on sitting around their NAS as if it's a campfire, hot plugging USB devices like an ape probing for ants, most of this discussion is irrelevant :-/

    The developer told andrzejls in this thread (posts above) that this exact problem is one of the reasons why he changed the behavior. It happened often enough to where he felt that the issue needed a solution. So,, I suppose we may have a few, I'll use the word "primates", in the user base. It is what it is.


    However, I'm more curious of the planned differences between OMV 5 and 6. For example, is 6 a fundamental-might-break things update, or more of a new-flashy-ornaments with a GUI update.

    Some of what you suggest might be the case, flashy-ornaments, GUI changes, etc. I believe a more pressing reason to update, when 6 comes out of the Alpha and Beta, stages, is to get in front for Debian security updates. 5 will be supported in the immediate future, but it will be EOL'ed eventually. I've found that those intervals seem to be happen faster, as I get older.

    • Offizieller Beitrag

    Some of what you suggest might be the case, flashy-ornaments, GUI changes, etc. I believe a more pressing reason to update, when 6 comes out of the Alpha and Beta, stages, is to get in front for Debian security updates. 5 will be supported in the immediate future, but it will be EOL'ed eventually. I've found that those intervals seem to be happen faster, as I get older.

    This is the crux of the issue. Many most users of OMV forget fail to appreciate that Debian lies underneath and supports OMV, and votdev has no control over the development of Debian.


    "GUI changes, etc." are a more subjective issue, but what better time to rework the layout and build in improvements than at a major OS distribution upgrade. With my small dabbling with OMV 6, I find nothing offensive to my tastes. Your tastes may be different. Look and feel may be a bit different in places but functionality will not be very different from what most of us are use to.


    A third aspect of a major software upgrade involves what is (mostly) under the hood: faster, more stable, more efficient performance. Added features are also welcome; items such as copy buttons for absolute paths. This third aspect doesn't get much discussion on the forum because some are too busy bitching about what they don't like, and the rest of us are busy running around trying to put out the fires.


    Edit: Oh, and no, I did not work as the IT Director for Bell Labs for 65 years, and I didn't invent the Internet. I drove a truck for thirty-five years, and I try to not let it go to my head.

    • Offizieller Beitrag

    chudak My guess is that an upgrade path will be one of the last things implemented. There are a number of users “testing” now, either with virtual machines or on an unused sbc or pc.

Jetzt mitmachen!

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