Posts by ryecoaaron

    Well currently my perceptions on OMV installations on SBCs (specifically RPi4) is that they are treated like "seconds class citizens" in OMV forum.

    Pre-RPi4 that is true. Rpi4 is a good board. I have three. And why would a second class citizen have very specific code in the install script?

    "Years of practices and past recommendation" have, from my view, been invalidated by technical improvements delivered via the RPi4 and similar SBCs

    Bullshit. I own and test most of the popular SBC boards. So, this is just nonsense. You may be referring to old threads but I am quite sure my current advice when people ask is as current as possible.

    It's time for a change in attitude towards this group of users and revised recommendations.

    Says who? You? I almost never see RPi users asking for recommended hardware. They buy what they can afford. It is almost always higher spec amd64 systems.

    An example to illustrate the topic, is to change recommendations from "no (software) RAID" to "only use hardware RAID using verified HDD enclosures".

    Why? Once again, you don't see to understand the budgets of a large number of sbc users. Your icy box enclosures may be nice (i have a few of their multi 2.5" to 5.25" enclosures) but most do not want to spend that much. And if they are using raid and can only afford two drives, where is their backup??? If they use borgbackup, not only do they have multiple backups with bitrot detection but they still have redundancy (you can mount borgbackup archives directly in the plugin). Your raid suggestion gives no bitrot detection or protection against crypto viruses or accidental deletion. Good thing their empty or encrypted drive is still working when one fails.

    To support this technically the software RAID configuration application (mdadm) should be de-installed during OMV installation and the reasoning be explained in the "new user guide".

    You will have a lot of fun supporting the destruction you cause by telling people to do that. mdadm is a dependency of OMV and you will uninstall OMV if you uninstall mdadm. mdadm is not a plugin.

    Prediction is that "80% of use cases covered by OMV are well served by an SBC with external HDD enclosure connected via USB3"

    Thank you captain obvious. Over 80% of SBCs don't have sata ports and have to use hdd enclosures. I said don't use usb raid NOT usb hard drives.

    Does this start to make sense?

    Only in your head. Unlike you, my recommendations are formed by interacting with users to see what they need NOT what you think they need. Since you preach continuous improvement, you should know that one important factor is customer satisfaction. Can you show me someone unhappy with my recommendations? Or even someone who would have avoided a serious issue if they were using your recommendations?

    Just tried with LUKS enabled, still doesnt boot up

    As I mentioned before, I don't know if it will every work with LUKS without auto-unlock because the device doesn't exist until it is unlocked. Even if I re-wrote the entire plugin, I'm not sure it would help. Did you try the mergerfsfolders plugin?

    this is a generalization using Fear, Uncertainty and Doubt (FUD). FUD was sales approach used by IBM in the 1970 to dominate the computer market. but by now they lost it. Can we please get back to a conversation based on facts?

    I don't buy into FUD reasoning without having verifiable examples.

    FUD, huh? So, my experience personally owning at least five of these enclosures is FUD? I have few opinions on that but I will keep them to myself.

    Would love to hear results from other OMV users trying the same approach but different chipsets.

    Do you honestly think I am just making shit up? I have owned these things and had to rebuild arrays because of failures. Just because icybox happens to work doesn't mean every damn external raid enclosure works this way.

    As above, again not a technical reason.

    I honestly don't care if it is a technical reason. Since I have support users of OMV much longer than you, I have better feeling what works well for them. Once again, I see I can't say anything right and you are trying to change years and years of practices we recommend on this forum. Not sure what you goal is but I really getting tired of it....

    RAID only buys time for fixing a disc failure.

    And most users can handle the downtime while they are fixing (as I said above) avoiding the complexities and problems that most RPi users won't understand.

    Why would there be a difference for usefulness of RAID using a PC versus a RPi4?

    If you are referring to a desktop-grade "PC", I would recommend against raid for that as well. More users accidentally delete things or get hit by viruses where raid doesn't help. And if all of your drives are tied up in an array, most users won't backup anything.

    Hell, I have server grade hardware and don't run (I did for years and years) raid myself. I would rather see people buy two RPis and connect one drive to each. With a periodic sync from one to the other, they have a great setup that is much easier to understand and recover from problems.

    I work all day long with enterprise-grade, redundant hardware. Very, very few OMV users (especially RPi users) need redundant anything. I guarantee they will benefit from backups much, much more.

    One USB connection (especially using the 5Gbit/s USB3.1 or higher) to an enclosure providing hardware supported RAID is fine with an RPi4

    I disagree and will keep recommending against it (plenty of experience owning a few and providing support for them to many people). I still think it is ridiculous to run raid (no matter what method) with an RPi. These enclosures are just as bad as the faux "hardware" raid on some motherboards.

    Just wait until the cheap power supply in that enclosure fails and/or the cheap sata connectors in the enclosure stop seating on the sata connector of the drive. I have had both happen and have helped people recover from both problems. Then you go to buy a new enclosure and can't find the same chipset because it isn't made anymore. You just lost your data.

    The MAIN aspect of offering a RAID system is for redundancy. It's the FIRST letter in the name. Different RAID modes have been able to improve the performance (just because of the number of read heads available). They've also been able to provide higher data availability because of the redundancy of the system, but the initial goal was to provide redundancy. People at home DO also need this. I have a NAS on my home network that acts as a centralized file store. I've had it this way for MANY years. All of my photos, music and videos are stored there. My NAS has 2 drives in it setup in RAID 1. That saved my butt. A few years ago, one of the drives in the RAID died. If I had not had that second REDUNDANT drive, all of that data would have been lost. My brother just went through this exact same problem, but his wasn't a RAID setup. Guess what? All that data is gone now. Music and videos (non-personal ones anyways) are easy enough to replace, but all the photos and personal videos are gone.

    And you're half right when you say that RAID is not backup. But I backup to my NAS, and if it's not a RAID NAS, then if that drive goes, so to do my backups.

    Raid does stand for redundancy. But the reason a business runs raid is to prevent down time. Very few home users will explode if their system is down while the restore from backups. And backups save your butt against data loss better than raid. What if a crypto virus hits your server? Both drives instantly have encrypted files. Worthless. If you using rsnapshot or borgbackup to periodically backup (most users would be more than good with every hour), then you would have multiple backups on the second drive to recover from a crypto virus OR a drive failure. If the backup drive failed, you still have your primary drive.

    So, none of your arguments actually justify needing raid. The do justify backups. And unless you have hardware with redundancy through the system, why have it just for your drives? I have actually seen more people lose their data because their array becomes corrupt. I haven't heard anyone unless with a periodic sync of the two drives.

    I'm having this exact same issue. Yes I did install without a working internet connection. The network interface would not configure until after the install completed. Then I configured it with omv-firstaid.

    You need to add the main debian repos then. Make your /etc/apt/sources.list look like this:

    deb buster main contrib non-free

    deb buster-updates main contrib non-free

    deb buster/updates main contrib non-free


    OMV uses the entire disk that it installs on. It is possible (although unlikely) that a data disk could be used and it would be wiped. There are also some issues where grub is install on the boot record of the wrong disk and that disk is not bootable by the bios.

    Does the installer really delete all the disks or is it just a precaution?

    It only wipes the disk it is going to install on. As I mentioned above, that may be the wrong disk.

    Are there any other mitigations i could use?

    Install Debian 10 using the netinst iso first where you have complete control over the installer and the disks it uses. Then install OMV on top using the guide - Installing OMV5 on Raspberry PI's, Armbian SBC's, & i386 32-bit platforms

    If the linux password is weak, there are ways to crack them (john the ripper or hashcat) but that's not the point.

    Agreed. I played with both of those but they aren't decrypting them. It is either using a known hash list or encrypting each password and checking against the hash.

    Could be a good research topic though

    Agreed. I'm sure there is some better way. I would be very interested in that.

    Any developer/programmer giving a hint on how to do this ?

    Your password stored in Linux (in /etc/shadow) is a one way hash. There is no way to decrypt it. When you enter your password, it is encrypted and if the new encrypted hash matches what is in /etc/shadow, it is correct. We can't do this for passwords stored in OMV's database because the passwords are used without someone entering a new one. So, there really isn't a good way to improve this.