NAS

Moderators
  • Posts

    5040
  • Joined

  • Last visited

Posts posted by NAS

  1. Right but it should be on users with problems to work around or disable modules and not for everyone else to hunt out and install addons for mainstream hardware.

     

    To be clear I am not critiquing you work, it is excellent, but this is not a rare component and has been on countless boards now for >10 years.

     

    It is a slippery slope.

  2. Could we trigger an update on a semi regular basis? I do not know what your build pipeline is but I would like to avoid getting into a situation where we are essentially nagging you as a trigger.

     

    Even once a month or perhaps on each minor release could be automated.?

     

    Ultimately the end goal should be to make your life easier helping where we can; forking, splitting effort or taking away from your work should never be our goal.

    • Like 1
  3. On 4/12/2023 at 3:15 PM, primeval_god said:

    Yes an update to this plugin is planned, but no eta.

     

    Can I ask about release cadence. Compose is now 13 versions out of date, is there any way we can assist in increasing this cadence?

     

    Does the addon need work every time the compose dependency changes? If so can we split this into two addons, one for compose itself and one for manager? Could we request compose be shipped with unRAID itself, would that help?

     

    Trying to understand where the bottleneck is as we just passed the 200 days mark since the shipped version of compose was released and that is too long.

     

    This post is not a criticism at all, just a realistic shout out to see if we can find a way to make this burden easier for you.

    • Upvote 1
  4. On 11/6/2022 at 4:49 PM, voidpointer said:

    The "Fix Common Problems" plugin warns about updating every individual docker container:

     

    > Docker Application prowlarr has an update available for it

     

    How can I disable this permanently for *all* docker containers?

     

    On 10/26/2022 at 12:50 AM, bdr9 said:

    This plugin is reporting many warnings on my Unraid server, but they are all Docker container updates. I can ignore them individually, but that only ignores the one specific Docker container, and warnings are still generated for other Docker containers. I would prefer not to receive any warnings for Docker container updates. Is there a way to disable this entire category of warning?

     

    This is a very long thread but I can only find issue reports and not a fix.

     

    How do I disable the image update warning entirely? I find myself starting to ignore Fix Common Problems because 99/100 it is docker noise and that cant be a good thing when that one time is important.

  5. On 11/18/2022 at 8:23 AM, sjtuross said:

    ...

    Is it possible to also update the local sha256 hash in this file /var/lib/docker/unraid-update-status.json? Since local sha256 is different from remote sha256 there, dockerman keeps showing update ready until I manually update the local sha256 hash.

     

    "library/traefik:latest": {
        "local": "sha256:2e53e47b59bc9a799b6c7b0d6d65f529de478094781751f1e061516ce9ca7c68",
        "remote": "sha256:ac1480ce3203541705b01d6dce40ef4bf563cdb29d5b00db88cc396fa9fa9cd5",
        "status": "true"
    }

    Very much this. Is this an accepted feature request?

    • Like 2
  6. 20 hours ago, dlandon said:

    @NAS This discussion all began with you saying that USB disks would make a noise when spun down.  I asked you to do some testing for me:

     

    Can you please respond to this post and let me know if it makes a difference?

    I can confirm that spinning down a drive before you unpower it reduces or even removes completely the unpleasant noise.

     

    This is expected behavior since these noises are caused by the very action of un-powering an actively moving drive. This is not USB specific it is also true of hotplug albeit harder to hear because they are typically within a chassis.

     

    I apologize if this was not clear. I started this discussion from a position of already knowing that reducing the power state has this impact. What was not clear is how far "down" we could take them and the best methodology to do this within unRAID.

  7. On 9/6/2022 at 12:45 PM, dlandon said:

    This command is not a...

    Sorry for slow reply, I gave up trying to make my comments and quotes look pretty.

     

    I agree on `udisksctl`. We should not consider adding this as it is unnecessary. I only mentioned it as it had a documented caveat that seemed relevant to any similar approach.

     

    `If I implement a 'safely_remove' feature it will not be generic in the sense that it will not be done on every unmount.  The user will have to add a 'safely_remove' command, and only USB devices will be operated on.  You can appreciate doing a safe removal on a built in hard disk by accident.  A reboot would be required to restore it.`

     

    Can we consider making this a button (or buttons) operation. I had imagined this never being event driven but rather would require a human button action in an identical manner to umount each and every time.

    This feels safer to me, allowing users not to press it of they choose (or even need) to do so if there are any edge cases out there. It would also let us add some safety where the button is only available within the correct context i.e. drive is not mounted.

     

    The term `safe removal` might be too harsh if we go this route since it implies not pressing would be `unsafe` which we have no proof is actually true. We can discuss terminology if this is agreed.

     

    `You can appreciate doing a safe removal on a built in hard disk by accident.  A reboot would be required to restore it.`

    I agree that this would be a terrible situation but I expect that since we know `echo 1 > /sys/class/scsi_device/<scsi bus>/device/rescan` can reactivate a device we could create an action to undo this mistake. e.g. https://www.systutorials.com/docs/linux/man/8-rescan-scsi-bus.sh.

     

    I say this for two reasons. Whilst I agree with your conclusion about maintaining flash /boot writes is bad I suspect `I'm not sure a re-attach is practical for UD.` could also be covered by this generic scan/undo action without having to maintain a state or action memory.

     

    More importantly I would like to made sure hotplug disks are not excluded from this as there is no real need to limit it to USB as long as we can exclude arrays disks and have a scan/undo option.

     

    Should we create a new thread on this whole concept and discussions to attract more attention and make it easier to refer back to and google later?

    • Like 1
  8. 14 hours ago, aim60 said:

    I've experimented with 

      echo '1' > /sys/block/sdX/device/delete

    and it gave me a warm and fuzzy before powering off a device.  But sometimes I wanted to remount the device without unplugging it first.  However, it had disappeared completely.  Even doing an UD Refresh Disks wouldn't bring it back.

     

    Research lead me to

      echo 1 > /sys/class/scsi_device/<scsi bus>/device/rescan

    which was successful.  But there was no way to tell which bus the disk was on unless you noted it before the device delete.  If you implement the above, please include a way to bring back the disk.

     

    This is good feedback and even better practical advice.

     

    Obviously it is expected behavior needing to physically re-plug a device that has been fully removed although I admit is it not intuitive behavior. It does in my opinion reinforce the concept that a `warm and fuzzy` state exists below umount where the OS has released even more control of the device for safer removal.

     

    We are in a strong position to cater for this unintuitiveness since we will know that the disk is still there and which bus it was on so in theory at least we can have a reattach button.

     

    One unconfirmed edge case from udisksctl manpage

     

    Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives.

     

    I am unsure if this impacts the more specific block action, testing will tell.

     

    I found linked via a previous suggestion this discussion discussing this approach on the Debian forums which is quite insightful.

     

     

  9. 21 hours ago, dlandon said:

    Unmounting the drive cleanly should be a safe way of removing it.

     

    The spindown is not a power off command.  I've not seen any head clunking tbis with any of my drives.

     

    Have you tried the commands in the link you supplied to see if there is a difference in the head clunking?  I suspect that the drive has an issue with parking the head cleanly.

     

    As I understand it the spindown command above requires every device be given an alias. I have no doubt this works since spin state is easy to change I just question how practical it is to require that the user define an alias first and for every device.

     

    For info this is not one specific drive, this is any spinning drive. It is easy to replicate, simply listen to the difference in sounds the drive makes between a spun down drive becoming unpowered and one that was just umounted and is still spinning.

     

    I also understand that spinning down a drive is not the same as a power off command we are just mixing the terms because we are ultimately just taking about the same end goal, safe removal.

     

    So to focus this a bit.

     

    Currently the procedure for removing a drive is

    • umount
    • power off

    I suggest there are more steps available to us:

     

    • umount
    • spin down
      • Other options to explore such as
        • eject/unbind the usb-storage driver/suspend the USB device
        • Offlining the device e.g. echo 'offline' > /sys/block/XXX/device/state ,

        • Detaching the device e.g. echo '1' > /sys/block/XXX/device/delete

    • power off

     

    If we feel that these are too complex or risky we should at the very least offer a generic "safely remove option" that just spins down the drive without any requiring aliases etc. It is not really a "safe removal" when compared to similar features in Ubuntu etc but its far better than just removing power from a potentially spinning drive

     

    TBH I think we can do much more here if we put our minds to it.

  10. On 1/18/2022 at 12:05 PM, dlandon said:

    I'm finishing up a new feature that allows you to add an alias name to a disk device and then use that name to mount, unmount, and spin down a disk.  Using this feature, you can spin down a disk when it is unmounted by changing the device script like this:

      'REMOVE' )
        # do your stuff here
        /usr/local/sbin/rc.unassigned spindown name=Scratch

    After the disk is unmounted the 'REMOVE' event is sent to the device script and at that time the spindown can occur.  The caveat is that this only works in 6.9 and later.

     

    Here is a screen shot to show how the alias naming works.

    2031750679_UDDisplay.thumb.png.800207c822bb94bbb5f195d7e9ac5e8f.png

     

    Don't use the hdparm command on 6.9 and later because it confuses the spin down logic in Unraid.

     

    Can we come back to this. It is not obvious to me what the correct method to remove a drive as safely as possible.

     

    Can the current method be improved because you can clearly hear the drive head horribly clunking if you go directly from umount to power off?

     

    There are many threads discussing this one is the most simple.

     

    https://unix.stackexchange.com/questions/35508/eject-usb-drives-eject-command

     

    (It is labelled USB the content quickly becomes more generic than that)

     

     

     

     

  11.  

    Addon works great.

     

    What are your plans for patching compose. I can see that the opening posts says version 2.1.1

     

    On 10/3/2021 at 8:22 PM, primeval_god said:

    ...

    This plugin installs docker compose 2.1.1 and compose switch 1.0.3.

    ...

     

    however the plugin change logs says:

    2022.05.14
    
    Change default output style to terminal.
    
    Added theme support.
    
    Docker Compose v2.5.0

     

    which matches what is included:

    # docker-compose -v
    Docker Compose version v2.5.0

     

    but according to https://docs.docker.com/compose/release-notes/#250

     

    this is three months and three releases out of date.

  12. Has any discussion happened on mechanic disk head parking on umount?

     

    When I press the interface button to umount and then physically power off the drive I can clearly hear the disk doing something that sounds a little awful.

     

    As an experiment, immediately after pressing the interface button, I issued the following command to the external USB disk:

     

    hdparm -y /dev/sdt

     

    and whilst I get an error:
     

     issuing standby command
    SG_IO: bad/missing sense data, sb[]:  f0 00 01 00 50 40 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

     

    it seems to work and powering off the disk sounds less harsh.

     

    This is proof of concept only, just enough to check the theory to open a post here for discussion.

     

  13. Thank you. Even after mounting countless hundreds of disk using UD I was not aware of those settings in the GUI at all. Perhaps that hints at either PEBCAK or an area where interface changes would help.

     

    As for image work, I cited that specific example as it was easy to do using the wiki itself but other examples include the more mundane tasks of backing up disks, thumb drives, RPI SD cards etc but I accept that these examples whilst not disk recovery are still intended more for the sysop than the average user.

     

    Thank you for the education and consideration.

  14. 51 minutes ago, dlandon said:

    What is it you are trying to accomplish?  I don't understand the use case you are asking for.

     

    Nothing especially complicated I am just suggesting that disks should only be mounted RW if you actually need RW. Failing that an option that allows you chose RO.

     

    For example if you are loading data from a backup then RO would be a safer option especially in the scenario where you are needing to restore from backup in the first place.

     

    As for working with images this gives a practical example of a use case https://wiki.unraid.net/Manual/Troubleshooting#Using_ddrescue_to_recover_data_from_a_failing_disk

  15. On 10/2/2021 at 2:29 PM, NAS said:

    Apologies if this is covered in the previous 252 pages but has consideration been given to adding the ability to mount and/or create disk/partition images (typically using dd in the background)

     

    Perhaps niche but genuinely useful especially if RO mode is an option.

    Any thoughts on this?

     

    If image options are out of scope please consider the read only mount option.

     

    There is a lot to be said to mounting disks RO by default with an option to seamlessly remount RW if needed.

  16. This clearly falls within the bounds of the release methodology. I appreciate the conflicting pressures and associated costs but its time, 332 days between security releases is pushing it a bit.

     

      

    On 9/2/2015 at 6:11 PM, limetech said:

    At present we are maintaining two code branches:  latest stable and development.

     

    The latest stable is always the first entry listed under Stable Releases on the website Download page.  The development releases are only publicized in the forum Announcement board.

     

    If a relevant Slackware Security Advisory package update becomes available (or other kind of security update), we update both the latest stable and development branches.  For the latest stable branch, we then increment the patch level of the release version (the third digit) and publish the new release as soon as practical.  Other critical bug fixes may also trigger publishing another latest stable patch release.

     

    Of the stable releases listed on the Download page, only the latest stable will be updated.  That is, we do not maintain multiple old stable releases at this time.  Updates are free and users are encouraged to keep up-to-date.

     

    For the development branch, an updated release may or may not be published at the same time as the new stable release, but any package updates or bug fixes which go into latest stable are first integrated into development and tested.

     

    Anyone who discovers a security-related issue is encouraged to post here so that we can integrate necessary patches in a timely manner.

     

    • Like 3