Posts by bobafetthotmail

    the thread where we discussed things before making the plugin is here [Tutorial][Experimental][Third-party Plugin available]Reducing OMV's disk writes, also to install it on USB flash
    someone says also how to log the amount of writes in the first 2-3 pages.


    So this string got me wondering, what if, instead of planning to replace
    the drive or engage in workarounds to reduce writes, you used a larger
    capacity drive?

    Yes, that would work fine for most mid-to-high-end rigs. As I said, the main reason for the plugin was allowing OMV to run without wasting a Sata port and/or inside low-end devices where you have 1-2 Sata and a few USB/SD cards total. (I'm not buying a SSD for my NSA325v2, nor is ryecoaaron buying one for his raspi/bananapi/whatever other board)

    On most decent x86 rigs, you can probably use one of the USB 3.0 ports with a usb 3.0 -to-whatever (Sata or mSata or NGFF) to not waste a Sata port with the SSD you keep the OS into, and do without that plugin alltogether.


    I doubt doubling capacity will double lifespan, but it should extend it quite a bit.

    Well, unless something is seriously wrong in the controller, lifespan depends directly from capacity.

    A twice as big drive should theoretically last twice as long (if we are talking only of failures related to flash writes, of course).

    Still, look up benchmarks, they aren't hard to find, and last time I looked the SSDs were already lasting 50 TBs or so.

    Umm, tmpfs isn't the average windows ramdisk.
    Tmpfs can grow until it reaches 50% of total ram but it occupies only the space needed by the files you put in it, it does not waste space like most ramdisks.

    Anyways, I'll see if I can get more useful things in the plugin UI like a table with space occupied and and the auto-synch option.

    Please note, the plugin was written for installing OMV inside a USB flash drive or SD card, they have a single or at most a double flash chip.
    So even if they try hard (most controllers nowadays do wear leveling), they will still fail pretty soon under heavy write activity.

    SSDs (even normal cheapo ones) have plenty of flash chips and their wear-leveling has enough of them.
    First-second-third gen ones had less endurance so it was a factor, nowadays... it's high enough to be not relevant unless you are using them as fast cache for ZFS or someting.

    Industrial-grade ones even more so. SLC cells are supposed to last 10 times as much as consumer-grade MLC chips, if not more, and the average consumer SSD is not going to die of writes in less than 10 years or so (much sooner if used as cache, of course).

    If you are worried by the writes, just go and disable the option in System --> Monitoring as said by Ryecoaaron,

    It will disable the pretty usage graphs of cpu and stuff you can see (but most don't know-need-use), that is basically the only source of writes that can worry you. It was doing something like a few GB per day or something like that just to update fixed-size databases (basically rewriting the same files with new data). Nothing else combined in OMV (or Debian) gets anywhere near this GB-per-day of writes.

    Then don't install Flashmemory plugin. A few logs, the package cache and the other nuisances left are not going to kill a SSD in a million years.


    What about moving default log location of your important logs.
    Is this possible for most logs? Move it off the SSD to a rotational

    It's on the list, yes. as long as it is a folder it is doable, for each log file... not that much, many logfiles are gzipped every now and then, I think symlinks will break that.
    For now the little free time I have was spent to get systemd to like my script, since I know little of it, and OMV 3.0 is (finally) using systemd.

    I'd like to promote a bit another guy that basically rewrote folder2ram (the thing doing the leg work in this plugin) in Perl and his version has already all features I wanted to add, if you want to try that out and give him some cookies...

    Is there a downside of using the plugin? If no, why not always enable it, even with a normal boot HDD?

    The only downside is that in case of sudden power otuage you lose some logs, and the databases that OMV uses to make the pretty CPU/Network/ram usage graphs.

    Other stuff is just disabled by the plugin to avoid unnecessary writes (like say downloading packages whenever there are new ones in repos, to make a faster install when updating, which is not really needed).

    If you want to save that stuff regularly to disk, you need to set a chron job manually calling a "folder2ram -syncall", which syncs the contents of the ram folders to the disk folders.


    It will never be more than "experimental" or "in testing" as long as Volker itself does not implement it into the CORE of OMV.

    That's kinda unfair, it's not based off fs2ram anymore now, the only failures we had are not possible with folder2ram because of safety checks.

    USB: scanning bus for devices... 2 USB Device(s) found
    scanning bus for storage devices... 0 Storage Device(s) found

    It is not seeing USB storage.
    It can happen with stock u-boot. USB drive too slow to initialize in time for u-boot.

    Bodhi's u-boot does wait more time, so you can use his own if you want. (in the logs posted you showed it did see the usb storage drive)

    if with another usb drive you cannot boot, can you try changing an u-boot setting?

    originally it was

    pre_bootcmd_linux_usb='setenv mainlineLinux yes; setenv bootargs $(bootargs_linux); mw.l f1010100 0020c000; usb reset'

    to change it write:

    setenv pre_bootcmd_linux_usb 'setenv mainlineLinux yes; setenv bootargs $(bootargs_linux); usb reset'

    the mw.l f1010100 0020c000; is a workaround to manually power up the USB system, that is needed on NSA325 to boot from USB because uboot command "usb reset" is bugged, maybe on NSA320 it is breaking things.

    Sorry for the annoyance, but I don't have a NSA320 so I cannot test on it, only on NSA325 and NSA310.

    Ok, so the issue is that your u-boot is trying to boot wrong files in first partition (boot partition).

    in first partition (the one seen by the uboot) there is no /boot folder, so /boot/uImage and /boot/uInitrd don't exist.

    My script teaches stock u-boot to look for /uImage and /uInitrd instead, but it seems the uboot setting modification works for stock uboot only, as bodhi's uboot keeps its settings in a different place and the standard firmware cannot work on it (also bodhi's uboot does not need an ext2 boot partition and can boot directly ext4, that's why it is probably looking for /boot/something boot files).

    Will have to add some lines to readme stating this and the manual workaround.

    you need to change the uboot lines manually, please write the following from uboot serial connection:

    setenv usb_load_uimage 'ext2load usb $device 0x800000 /uImage'
    setenv usb_load_uinitrd 'ext2load usb $device 0x1100000 /uInitrd'


    I have tried to nuke the 32GB key, but for some reason the install
    script isn't finding it during the install (bad USB stick or bad USB
    port on the back of the NSA320?).

    It probably needs to be formatted as something (with mbr or msdos partition table and all) for zyxel firmare to see it. I never tested an install without partitions.

    are you using my install script or what else?

    how is the flash drive partitioned? what partition type? ext2 or ext3 or ext4?

    are boot files in /boot folder or is there a boot partition?

    what you did to flash it to arch? You tried updating its own firmware to latest before attempting?


    - made 'resetenv;reset';
    more then once!

    You started with older scripts. Now it should
    boot its firmware if it does not find something in sata and USB drives.

    From there you can do a fw_resetenv and then reboot

    That still doesn't seem to be the truth ;-)

    Feel free to help me debug OMV. Because this is OMV issue, not recognizing partition table made by the older fdisk in the firmware.
    Or maybe you can show you have some kind of IT background and suggest to statically-compile a modern fdisk binary that works with Zyxel firmware (as long as it is statically compiled it probably will), and use that during installation.


    Up to now i thought the goal is to find a straight way to a working solution.

    Yes, my goal was to do without UART, and I made the grievous mistake of assuming that others (ALARM devs) did their job properly, because U-boot is the same y'know.


    That's an example for the above said: You linked to a script for Arch-Linux, that doesn't work with Debian. I found and used a different script.

    feel free to provide links.

    Yeah, tested with sata drive and it does the same. With OMV 1.19 it wasn't having these issues.
    Will have to look into this, I think it is OMV not liking the partition table done by the NAS's firmware.

    Try to use parted instead of fdisk.
    parted is newer and might make something that OMV likes.

    If it does not work, install OMV in a USB flash drive (instructions in README, same as above, you just plug a USB flash drive instead of a Sata drive, and the usb flash drive with installer scripts and archives).
    The OMV system in this installer contains flashmemory plugin so the usb flash drive will not be killed by OMV write activity.

    And erase the partition table of the current hard drive with parted or gparted (the graphical user interface of parted if you have a Ubuntu system).

    Whew. It is finally up.


    tried to enter ssh, root passwd openmediavault -> nope

    SSH login is "root" password is "root" This is stated in the README. :D


    Addendum: OK ... Frontend works, HDs displayed, but i cannot partition, format and share the diskspace ...

    You installed it in a Sata drive? what size? Need to do some tests on mine.

    EDIT: did tests. You need to go to "Physical Disks" section, select the data disk and press "wipe" button a few times. First time errors out, second time works and then you can go and make partitions from "File Systems" section.

    also manual re-partition of data drive or data partition fixes this, afterwards you can use OMV own panels.

    Seems OMV issue with partition tables though. ?(

    as we can see, scripted installation is "more user-friendly" and "much faster" than doing it manually ;-).

    Yep. Now it is just download, unzip and plug it in. No serial nor box disassembly needed. :D

    Development times are always longer than doing it manually, the machine is fast, but stupid. Also the tutorials you followed required months of work for someone, don't think you are cooler because you know how to follow a manual.


    but it had the problem, that it didn't start eth0, when powered on
    without connected serial interface as reported by cascate.

    You need to send down a command to a specific GPIO as I linked in the posts above each boot (paste the code in a script executed each boot). That GPIO enables the WoL feature AND keeps the dumb eth0 operational after a reboot.

    Ok, you reset the bootloader.

    Now can you try installing again using the install scripts version 1.4 as I said?

    The hard drive must be in the LEFT port when booting (it will install fine if it was in right or left port).
    USB drives must be in back ports.

    Try again with the HDD in the LEFT port.

    The serial log you posted seems to be cut in quite a few places.…cpl14vRQeurbPPnJ5Vza?dl=0 the same as above. It is a folder where you find all files.

    Before you try again installing, stop the boot by pressing a key then write
    resetenv; reset
    and press enter
    Then you can power off the NAS and begin installation.


    Do I have to untar the tarballs in boot... and debian ...

    No, because the installer is modifying bootloader settings to boot from usb/Sata


    PS ... actually trying to persuade the UART-Screen to be scrollable

    If you are using Putty you can set it to log your sessions automatically, read here