Jump to content

MortenSchmidt

Members
  • Posts

    309
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by MortenSchmidt

  1. On 3/29/2022 at 11:11 PM, MortenSchmidt said:

    Now.. to figure out how much space is needed to do the db upgrade, I believe I had around 84GB free before starting the process and yet it just failed on me again.

    In case anyone is wondering.. I got a longwinded errormessage concluding with "sqlite3.OperationalError: database or disk is full " and it turned out to be the docker image running out of space. 2GB free was apparently not enough. After increasing the max docker image size to 50GB it was able to complete the db upgrade.

    Edit: Oh, and after upgrading you have to stop, delete (or keep as backup) the V1 database and start, and don't put this off as it does not automatically switch over to the v2 database and will need to sync up the v2 database from the time the upgrade process started (mine took more than 24 hours and I was more than 8000 blocks behind when I switched over to the V2 database)

  2. 49 minutes ago, guy.davis said:


    Hello!  Sorry for the delayed response. 

    No worries. My problem was a corruption in the wallet files. The problem first occurred when the SSD had run out of space (while doing a db upgrade attempt). Deleting the following and starting up helped:

    blockchain_wallet_v2_mainnet_xxxxxxxxxx.sqlite-shm

    blockchain_wallet_v2_mainnet_xxxxxxxxxx.sqlite-wal

    I left the main wallet file (.sqlite) and after that the wallet quickly synced up and "chia wallet show" returns the expected output.

    Now.. to figure out how much space is needed to do the db upgrade, I believe I had around 84GB free before starting the process and yet it just failed on me again.

  3. 45 minutes ago, guy.davis said:

    Hi, yes.  The Machinaris development images included the latest HDDCoin just a few hours after HDDCoin team released on January 6th.  Some Machinaris users, in the #hddcoin channel of our Discord ,used that early Machinaris version for the hodl command-line that very day.   

     

    The Machinaris test images received this HDDCoin update about 3 days later.  The next Machinaris official release with the updated HDDCoin version is due sometime next month.

     

    Details on Machinaris release streams on the wiki.  You're welcome to run whichever stream you would like.  Hope this helps.

     

    (I think??) I'm running the test stream (ghcr.io/guydavis/machinaris-hddcoin:test) and running "docker exec -it machinaris-hddcoin hddcoin version" returns "1.2.10.dev121".

    What I did was simply add the :test to the repo in unraid "update Continer" dialog and hit apply, it looked to me like it pulled the new image and while I see you have more elaborate instructions in the wiki, please help me understand if and why all that is needed and whether running those commands will cause all of my running dockers to stop, wipe and re-pull? I've used docker commands a bit but never encountered the docker-compose command nor a need for it.

     

    PS. Also. running "docker exec -it machinaris-hddcoin hodl -h" (or without the -h) returns:

    OCI runtime exec failed: exec failed: container_linux.go:367: starting container process caused: exec: "hodl": executable file not found in $PATH: unknown

    I do see your note in the changelog for :test stream about v6.9 updating to v1.2.11 but according to hddcoin github, v2.0 is needed for hodl.

  4.   

    17 hours ago, DoeBoye said:

    Any ideas?

    Check if database drive ran out of space? You might have a different issue but I had that happen, I don't recall what errors I got but the only way out was a database resync. I saw some say you could export it in sqlite as text, remove first and last lines and reimprt, it's just surprisingly difficult to do with a 30+GB file when you're not an expert on sed, and I guess there's no guarantee it would work even if you could do that.

      

    16 hours ago, guy.davis said:

    I'm actually looking into automated DB backups within Machinaris as a way to try to mitigate this unfortunate instability.

    That would be welcomed, but also checking whether the drive that holds the database is running out pf space would be beneficial. Yes, unraid does have low space warnings but it's not very granular, and it'd be nice to have within machinaris.

     

    On another note, have you tested HDDcoin v2.0 at all? I'm sort of interested in their HODL program which requires the new version.

  5. Quick note to anyone having the problem the farmer and wallet not starting up after updating the docker which currently runs "1.2.1-dev0" : Try forwarding port 8555 in your router, after I did this everything starts normally again. Chia v1.2.0 release notes says something about an RPC system being added, that uses this port.

     

    EDIT: Another quick note : To pool, you need to generate new plots with the -c switch, read tjb_altf4's guide thoroughly or check out the official documentation, it is not enough to upgrade to 1.2 and create new plots. Unless plots are created with -c switch they will be legacy solo-farming plots.

     

    But that said, I am currently stuck trying to join a pool, have followed tjb_altf4's guide above to successfully create the nft (well, it shows up with plotnft show, and I now have two wallets so think that has worked), but when I try to join a pool with "chia plotnft join -i 2 -u https://europe.ecochia.io" I get the somewhat puzzeling error message "Incorrect version: 1, should be 1". Anyone know what's up with that?

    EDIT: Must have been a problem specific to ecochia, No problem with pool.xchpool.org

     

  6. On 1/17/2020 at 8:55 PM, Alexander said:

    Edit: consider this alternative Lenovo card too (2020-08-07).

    https://www.youtube.com/embed/wudbsI_XB24?start=460&end=480

     

    For the sake of people searching the forum, the card featured in that video is the Lenovo FRU 03X3834. TheArtofServer guy says it is a newer card than the IBM FRU 46M0997 and that the cards he received did not have any of the firmware bugs the other cards used to come with. I had a lot of trouble digging up any mentions of this card, so thank you for linking this video.

  7. Thank you all who have contributed to this mamooth information dump. I have tried to follow the instructions in the Wiki to convert my recently acquired IBM M1015 card to LSI SAS9211-8i but the established process failed with a "No LSI SAS adapters found!" already in step 1. Maybe the information on how to overcome this is already in one of the prior 67 pages of the thread but I did not sit down to read through it all.. I did find the a workable solution here: https://www.truenas.com/community/threads/ibm-serveraid-m1015-and-no-lsi-sas-adapters-found.27445/

    I have used this successfully and have taken the liberty of updating the unraid Wiki with this information hoping it might help someone, this is what I have added:

     

    Note on converting newer IBM 1015 cards to plain SAS2008 (LSI SAS9211-8i) :

    If you encounter the "No LSI SAS adapters found!" in step 1 and when launching the LSI SAS2FLSH tool (either DOS or EFI versions) manually, it may be because newer versions of the IBM M1015 firmware prevent the card being recognized by the LSI tool. In this case you will need to:

    - Obtain a copy of "sbrempty.bin" for example from https://www.mediafire.com/folder/5ix2j4jd9n3fi77,x491f4v3ns5i40p,1vcq9f93os76u3o,yc0fsify6eajly0,xkchwsha0yopqmz/shared

    - Manually read out the SAS address from the sticker on the back side of the card, as you aren't able to read it out with the sas2flsh.exe tool. It has the format "500605B x-xxxx-xxxx", ignore spaces and dashes and note down the sas address in format "500605Bxxxxxxxxx"

    - Still read all the instructions and precautions in the guide (have only one controller card in the machine, preferably have the machine on UPS power, etc.)

    - Execute "MEGAREC -writesbr 0 sbrempty.bin" (This wipes out the vendor ID, after this command SAS2FLSH can see the card but refuses to read out the sas address or erase the card)

    - Execute "MEGAREC -cleanflash 0" (This erases the card incl sas address)

    - Reboot the machine.

    - From here you can folow the guide in the P20 package after step 3 - Run the "5ITP20.BAT" batch file in 5_LSI_P20\ folder, then 6.bat in the root folder that you modified with your sas address beforehand.

    - For ease of reference and because not much is left of the guide at this point, the actual commands remaining are "SAS2FLSH -o -f 2118it.bin" to flash the P20 IT mode firmware, and "SAS2FLSH -o -sasadd 500605Bxxxxxxxxx" to set the sas address.

     

    • Like 2
    • Thanks 1
  8. http://www.bestbuy.ca/en-CA/product/wd-wd-my-book-5tb-3-5-external-hard-drive-wdbfjk0050hbk-nesn-wdbfjk0050hbk-nesn/10384896.aspx

     

    I've shelled a 5TB Elements last summer, works fine so far and had warranty coverage on the internal drive's serial when I looked it up. This is the my book, but assume it is the same drive inside.

     

    Cheap harddrives have been hard to come by lately up here. If you have any better deals, please share.

  9. I too get this, probably happened 3 or 4 times in total. Today happened on 6.1.9 while building a docker image I'm (trying to) develop.

     

    In my case, syslogd is the sender and I noticed my tmpfs (/var/log) is full. Next time you guys get this, check

    df -h

     

    Look for:

    Filesystem      Size  Used Avail Use% Mounted on
    tmpfs           128M  128M     0 100% /var/log

     

    In my case /var/log/docker.log.1 was about 127MB in size (of mostly jibberish). Last time this happened docker didn't like it a lot either - already running dockers worked fine but I was unable to start/stop new ones (docker deamon seems to crash - impossible to check syslog since that stops working too).

     

    Any good ideas how to prevent docker logs from balooning like they seem to do for me?

  10. I kept looking at this a bit longer - the other way to get rid of the false warnings is to change from monitoring raw to normalized values. This way one could still monitor field 187's normalized value.

     

    I also looked closer at the smartctl-x report which breaks out which fields are relevant to pre-failiure prediction and which are not.

     

    SMART Attributes Data Structure revision number: 10
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
      5 Reallocated_Sector_Ct   -O--CK   100   100   000    -    0
      9 Power_On_Hours          -O--CK   000   000   000    -    909937 (110 2 0)
    12 Power_Cycle_Count       -O--CK   100   100   000    -    116
    170 Unknown_Attribute       PO--CK   100   100   010    -    0
    171 Unknown_Attribute       -O--CK   100   100   000    -    0
    172 Unknown_Attribute       -O--CK   100   100   000    -    0
    174 Unknown_Attribute       -O--CK   100   100   000    -    27
    184 End-to-End_Error        PO--CK   100   100   090    -    0
    187 Reported_Uncorrect      POSR--   118   118   050    -    199827011
    192 Power-Off_Retract_Count -O--CK   100   100   000    -    27
    225 Unknown_SSD_Attribute   -O--CK   100   100   000    -    327259
    226 Unknown_SSD_Attribute   -O--CK   100   100   000    -    65535
    227 Unknown_SSD_Attribute   -O--CK   100   100   000    -    30
    228 Power-off_Retract_Count -O--CK   100   100   000    -    65535
    232 Available_Reservd_Space PO--CK   100   100   010    -    0
    233 Media_Wearout_Indicator -O--CK   100   100   000    -    0
    241 Total_LBAs_Written      -O--CK   100   100   000    -    327259
    242 Total_LBAs_Read         -O--CK   100   100   000    -    146395
    249 Unknown_Attribute       PO--C-   100   100   000    -    11051
                                ||||||_ K auto-keep
                                |||||__ C event count
                                ||||___ R error rate
                                |||____ S speed/performance
                                ||_____ O updated online
                                |______ P prefailure warning

     

    I decided to add fields 170, 184 and 232 since these are classified as "prefailure warning" fields, and also field 232 because of its title. (But not 249 since that already has a high raw value which like 187 is not 'auto-kept', so presumably resets with power-on like 187 does).

     

    Interestingly, the only field that UnRaid monitors per default, that is a classified as a prefailure warning field for this SSD is 187 (which it monitors incorrectly in raw mode).

     

    Not sure if monitoring all those fields including 187 in normalized mode or all of them excl 187 in raw mode is better. I'm leaning toward the latter, thinking that will give the earliest warning possible, but on the other hand since it is just a cache device maybe we don't need to be concerned with the raw values.

     

    In case anyone at limetech sees this, the obvious improvement suggestion here is to offer the possibility to monitor some fields in raw mode and others in normalized mode. Or implement the extended attributes so field 187 can be monitored in raw mode correctly.

  11. Back again. Took all of 10 minutes for the uncorrectable error count notifications to start popping up.

     

    With smartctl-a and Unraid WebGui:

    ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
    187 Uncorrectable_Error_Cnt 0x000f   114   114   050    Pre-fail  Always       -       76820312

    (BTW, please note that worst and value are way above the threshold)

     

    With smartctl -x the same raw value is reported, but this is added below:

    Device Statistics (GP Log 0x04)
    Page Offset Size         Value  Description
      4  =====  =                =  == General Errors Statistics (rev 1) ==
      4  0x008  4                0  Number of Reported Uncorrectable Errors
    

     

  12. I too have this. Same drive Intel 520 120GB. I'm flooded with "uncorrectable error count" emails and notifications in webgui.

     

    I have had the drive hooked up to a windows PC running the Intel SSD Toolbox today to check for new firmware, but drive already has the latest firmware version "400i".

     

    Did you find a solution?

     

    What did you find that suggested this is causes by a bug in the SSD? I'm thinking since the power on hours reporting is also messed up in linux but reports correctly in windows with SSD toolbox, maybe the problem is with linux or its unraid implementation. This topic seems to suggest the drive works with "extended logs" and requires running "smartctl -x" instead of "smartctl -a"

     

    https://communities.intel.com/thread/53491?start=0&tstart=0

     

    For what it's worth, with smartctl -a (and in unraid WebGui) the power hours are reported like this:

    ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
       9 Power_On_Hours_and_Msec 0x0032   000   000   000    Old_age   Always       -       909799h+57m+24.280s

     

    But with smartctl -x it adds this interpretation:

    Device Statistics (GP Log 0x04)
    Page Offset Size         Value  Description
      1  =====  =                =  == General Statistics (rev 2) ==
      1  0x010  4            15004  Power-on Hours

     

    So the -x makes a lot more sense, and is the same value I see in windows with the SSD toolbox.

     

    Have just rebooted the server so don't have the uncorrectable notifications popping up yet. Can update this later when it returns (from what I have read, the uncorrectable error count raw value resets at power-on with these SSD's).

  13. Interestingly, I have never had this issue -- and I have 14 VERY full Reiser disks on my media server [2-4TB disks, less than 1GB of free space on each]    I don't copy files as large as 35GB, however ... none of my media files exceed about 8.5GB in size.

     

    If you wanted to make sure you encountered this problem, what you would do is free up 10-20% on a drive, fill it up again, repeat several times. I never had a problem simply filling a reiserfs drive, it was once a disk had been partially emptied and refilled. Could be a month or a year until I would see the problems, and on many disks I never did. I have even seen the problems on disks that were never filled beyond 98% (40GB free), just a matter of time and use.

     

    I too migrated to XFS and haven't had problems since.

  14. This is an issue with the version of NZBGet in this container.  Try going to settings - logging - TimeCorrection

     

    Thanks for responding. I still think it would be worthwhile to list as a known defect in the first post.

     

    EDIT : Or call it a known issue. Whatever. Just please, lets not fill up this thread with pointless chatter. No matter if this is an issue with the NZBget code or a docker issue, listing that sucker right up front would keep the thread more reader-friendly IMHO - just a friendly suggestion.

  15. Please post any questions/issues relating to this docker you have in this thread.

     

    I am having an issue with scheduled tasks not happening at local time. I need to enter scheduled times at GMT. I bet I'll have to go and edit them once we switch to daylight savings time too. Not a big deal, but I didn't have that problem with needo's docker back when I used that.

     

    If this is an acknowledged/known issue, please consider listing it in the top post as a known defect. And if you fix this, please make an announcement or update the top post. Thanks!

×
×
  • Create New...