unRAID Server Release 6.0-beta14b-x86_64 Available


limetech

Recommended Posts

Tryed several times to upgrade from beta14 to beta14b via WebGUI and getting:

 

/usr/local/sbin/plugin update unRAIDServer.plg 2>&1

plugin: running: 'anonymous'

plugin: creating: /tmp/unRAIDServer.zip - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/beta/unRAIDServer-6.0-beta14b-x86_64.zip

plugin: skipping: /tmp/unRAIDServer.md5 already exists

plugin: running: 'anonymous'

Archive: ../unRAIDServer.zip

inflating: bzimage

inflating: bzroot

bzroot: write error (disk full?). Continue? (y/n/^C)

warning: bzroot is probably truncated

unzip error

plugin: run failed: /bin/bash retval: 1

 

There is plenty of room on the flash drive.  Thanks

Link to comment
  • Replies 476
  • Created
  • Last Reply

Top Posters In This Topic

Tryed several times to upgrade from beta14 to beta14b via WebGUI and getting:

 

/usr/local/sbin/plugin update unRAIDServer.plg 2>&1

plugin: running: 'anonymous'

plugin: creating: /tmp/unRAIDServer.zip - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/beta/unRAIDServer-6.0-beta14b-x86_64.zip

plugin: skipping: /tmp/unRAIDServer.md5 already exists

plugin: running: 'anonymous'

Archive: ../unRAIDServer.zip

inflating: bzimage

inflating: bzroot

bzroot: write error (disk full?). Continue? (y/n/^C)

warning: bzroot is probably truncated

unzip error

plugin: run failed: /bin/bash retval: 1

 

There is plenty of room on the flash drive.  Thanks

This could  be due to some sort of corruption on the flash drive causing it to be read-only.  The normal way to fix such an issue is to pop the flash drive into a Windows PC (or Mac) and let Windows fix any corruption found.
Link to comment

Just updated to 14b and I have noticed that every time I restart unRAID I get a notification that one of my hard-drives has 1 relocated sector... IMO I don't need to be notified every time I reboot about the relocated sector. I personally only would like to know if that 1 relocated sector turns to 2... Is there a way for unRAID to keep track of the smart values and only let me know if the count increases?

The value of the currently reallocated sectors (and the other attributes monitored) is not saved during a reboot.  After the initial boot and notification, the system will only notify you when those monitored attributes change.  I've suggested a couple of times for the settings to be saved on reboot as it is a fair bit annoying (particularily when I just switch to a new beta and am resetting very often to evaluate the software)

 

Link to comment

Just updated to 14b and I have noticed that every time I restart unRAID I get a notification that one of my hard-drives has 1 relocated sector... IMO I don't need to be notified every time I reboot about the relocated sector. I personally only would like to know if that 1 relocated sector turns to 2... Is there a way for unRAID to keep track of the smart values and only let me know if the count increases?

The value of the currently reallocated sectors (and the other attributes monitored) is not saved during a reboot.  After the initial boot and notification, the system will only notify you when those monitored attributes change.  I've suggested a couple of times for the settings to be saved on reboot as it is a fair bit annoying (particularily when I just switch to a new beta and am resetting very often to evaluate the software)

I agree, the values should be saved.

Link to comment

Just updated to 14b and I have noticed that every time I restart unRAID I get a notification that one of my hard-drives has 1 relocated sector... IMO I don't need to be notified every time I reboot about the relocated sector. I personally only would like to know if that 1 relocated sector turns to 2... Is there a way for unRAID to keep track of the smart values and only let me know if the count increases?

The value of the currently reallocated sectors (and the other attributes monitored) is not saved during a reboot.  After the initial boot and notification, the system will only notify you when those monitored attributes change.  I've suggested a couple of times for the settings to be saved on reboot as it is a fair bit annoying (particularily when I just switch to a new beta and am resetting very often to evaluate the software)

 

Another vote for storing those parameters on the flash drive when the the server is rebooted or shutdown.  Not quite for the same reason as you mention for one quite different.  When I install it on my working server, it may be months between shutdowns (or reboots).  Nothing like a panic attack when the server is rebooted and a BIG red flag pops and the E-mail arrives announcing that there is a problem on the server.  At that point, I have to try to remember what the old values were so I can figure out whether this is an old issue or the start of a new problem!!!  Storing the values (and reloading) should be a simple matter that will be much appreciated by both the user and those of us on the Forum who will be dealing with the questions forever after if this feature request is not addressed.

 

EDIT:  I have installed 14b and no problems or issues.  Looks like we should be getting close to an rc!  Keep up the good work, guys.

Link to comment

Tryed several times to upgrade from beta14 to beta14b via WebGUI and getting:

 

/usr/local/sbin/plugin update unRAIDServer.plg 2>&1

plugin: running: 'anonymous'

plugin: creating: /tmp/unRAIDServer.zip - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/beta/unRAIDServer-6.0-beta14b-x86_64.zip

plugin: skipping: /tmp/unRAIDServer.md5 already exists

plugin: running: 'anonymous'

Archive: ../unRAIDServer.zip

inflating: bzimage

inflating: bzroot

bzroot: write error (disk full?). Continue? (y/n/^C)

warning: bzroot is probably truncated

unzip error

plugin: run failed: /bin/bash retval: 1

 

There is plenty of room on the flash drive.  Thanks

This could  be due to some sort of corruption on the flash drive causing it to be read-only.  The normal way to fix such an issue is to pop the flash drive into a Windows PC (or Mac) and let Windows fix any corruption found.

 

Looks like you were correct.  Thanks

Link to comment

Minor "bug" in the Web Interface.

 

When using an iPhone (in this case iOS8 on iPhone 5, but I assume the same on all iOS devices) and performing an activity that results in the "pop-up" screen (for example the upgrade pop-up which shows the activities being performed), the user is not able to scroll down within the pop-up. 

 

In this situation, swiping on the popup results in the GUI "below" the pop-up to move/scroll.

Link to comment

Just tried a parity check on this beta and it was going very slow. The system log is filled with these

 

Feb 26 21:25:07 Tower kernel: mdcmd (61): check CORRECT
Feb 26 21:25:07 Tower kernel: md: recovery thread woken up ...
Feb 26 21:25:07 Tower kernel: md: recovery thread checking parity...
Feb 26 21:25:07 Tower kernel: md: using 1536k window, over a total of 2930266532 blocks.
Feb 26 21:26:01 Tower sSMTP[11098]: Creating SSL connection to host
Feb 26 21:26:02 Tower sSMTP[11098]: SSL connection using RC4-SHA
Feb 26 21:26:03 Tower sSMTP[11098]: Sent mail for ####### (221 know-smtprelay-4-imp bizsmtp closing connection) uid=0 username=root outbytes=746
Feb 26 21:26:09 Tower kernel: INFO: rcu_sched self-detected stall on CPU { 2}  (t=6001 jiffies g=10526 c=10525 q=90297)
Feb 26 21:26:09 Tower kernel: Task dump for CPU 2:
Feb 26 21:26:09 Tower kernel: unraidd         R  running task        0  3155      2 0x00000008
Feb 26 21:26:09 Tower kernel: 0000000000000000 ffff88030fc83da8 ffffffff8105e0b5 0000000000000002
Feb 26 21:26:09 Tower kernel: 0000000000000002 ffff88030fc83dc8 ffffffff81060780 0000000000000004
Feb 26 21:26:09 Tower kernel: ffffffff81834400 ffff88030fc83df8 ffffffff8107845f ffffffff81834400
Feb 26 21:26:09 Tower kernel: Call Trace:
Feb 26 21:26:09 Tower kernel:   [] sched_show_task+0xbe/0xc3
Feb 26 21:26:09 Tower kernel: [] dump_cpu_task+0x35/0x39
Feb 26 21:26:09 Tower kernel: [] rcu_dump_cpu_stacks+0x6a/0x8c
Feb 26 21:26:09 Tower kernel: [] rcu_check_callbacks+0x1db/0x4f9
Feb 26 21:26:09 Tower kernel: [] ? tick_sched_handle+0x34/0x34
Feb 26 21:26:09 Tower kernel: [] update_process_times+0x3a/0x64
Feb 26 21:26:09 Tower kernel: [] tick_sched_handle+0x32/0x34
Feb 26 21:26:09 Tower kernel: [] tick_sched_timer+0x37/0x61
Feb 26 21:26:09 Tower kernel: [] __run_hrtimer.isra.29+0x57/0xb0
Feb 26 21:26:09 Tower kernel: [] hrtimer_interrupt+0xd9/0x1c0
Feb 26 21:26:09 Tower kernel: [] local_apic_timer_interrupt+0x50/0x54
Feb 26 21:26:09 Tower kernel: [] smp_apic_timer_interrupt+0x3c/0x4e
Feb 26 21:26:09 Tower kernel: [] apic_timer_interrupt+0x6d/0x80
Feb 26 21:26:09 Tower kernel:   [] ? xor_sse_5_pf64+0xc3/0x3c0
Feb 26 21:26:09 Tower kernel: [] ? xor_sse_5_pf64+0x57/0x3c0
Feb 26 21:26:09 Tower kernel: [] xor_blocks+0x49/0x4b
Feb 26 21:26:09 Tower kernel: [] handle_stripe+0xd84/0x120f [md_mod]
Feb 26 21:26:09 Tower kernel: [] unraidd+0xda/0x194 [md_mod]
Feb 26 21:26:09 Tower kernel: [] md_thread+0xd2/0xe8 [md_mod]
Feb 26 21:26:09 Tower kernel: [] ? __wake_up_sync+0xd/0xd
Feb 26 21:26:09 Tower kernel: [] ? 0xffffffffa00c9000
Feb 26 21:26:09 Tower kernel: [] kthread+0xd6/0xde
Feb 26 21:26:09 Tower kernel: [] ? kthread_create_on_node+0x172/0x172
Feb 26 21:26:09 Tower kernel: [] ret_from_fork+0x7c/0xb0
Feb 26 21:26:09 Tower kernel: [] ? kthread_create_on_node+0x172/0x172

 

I have added a system log and wanted to add it does not happen on B14a. All my drives are XFS.

syslog.zip

Link to comment

I stopped the array through the webui and tried to initiate a reboot and the webui displayed the yellow banner about rebooting.

 

However no reboot has occured, this is showing over ipmi

 

 

 

If i refresh the webui i can only get the yellow rebooting banner, i can log in via ssh and uptime via top is showing 19+ hours.

error.jpg.19a86244d6986add972eea163daadfca.jpg

Link to comment

Just tried a parity check on this beta and it was going very slow. The system log is filled with these

 

Feb 26 21:25:07 Tower kernel: mdcmd (61): check CORRECT
Feb 26 21:25:07 Tower kernel: md: recovery thread woken up ...
Feb 26 21:25:07 Tower kernel: md: recovery thread checking parity...
Feb 26 21:25:07 Tower kernel: md: using 1536k window, over a total of 2930266532 blocks.
Feb 26 21:26:01 Tower sSMTP[11098]: Creating SSL connection to host
Feb 26 21:26:02 Tower sSMTP[11098]: SSL connection using RC4-SHA
Feb 26 21:26:03 Tower sSMTP[11098]: Sent mail for ####### (221 know-smtprelay-4-imp bizsmtp closing connection) uid=0 username=root outbytes=746
Feb 26 21:26:09 Tower kernel: INFO: rcu_sched self-detected stall on CPU { 2}  (t=6001 jiffies g=10526 c=10525 q=90297)
Feb 26 21:26:09 Tower kernel: Task dump for CPU 2:
Feb 26 21:26:09 Tower kernel: unraidd         R  running task        0  3155      2 0x00000008
Feb 26 21:26:09 Tower kernel: 0000000000000000 ffff88030fc83da8 ffffffff8105e0b5 0000000000000002
Feb 26 21:26:09 Tower kernel: 0000000000000002 ffff88030fc83dc8 ffffffff81060780 0000000000000004
Feb 26 21:26:09 Tower kernel: ffffffff81834400 ffff88030fc83df8 ffffffff8107845f ffffffff81834400
Feb 26 21:26:09 Tower kernel: Call Trace:
Feb 26 21:26:09 Tower kernel:   [] sched_show_task+0xbe/0xc3
Feb 26 21:26:09 Tower kernel: [] dump_cpu_task+0x35/0x39
Feb 26 21:26:09 Tower kernel: [] rcu_dump_cpu_stacks+0x6a/0x8c
Feb 26 21:26:09 Tower kernel: [] rcu_check_callbacks+0x1db/0x4f9
Feb 26 21:26:09 Tower kernel: [] ? tick_sched_handle+0x34/0x34
Feb 26 21:26:09 Tower kernel: [] update_process_times+0x3a/0x64
Feb 26 21:26:09 Tower kernel: [] tick_sched_handle+0x32/0x34
Feb 26 21:26:09 Tower kernel: [] tick_sched_timer+0x37/0x61
Feb 26 21:26:09 Tower kernel: [] __run_hrtimer.isra.29+0x57/0xb0
Feb 26 21:26:09 Tower kernel: [] hrtimer_interrupt+0xd9/0x1c0
Feb 26 21:26:09 Tower kernel: [] local_apic_timer_interrupt+0x50/0x54
Feb 26 21:26:09 Tower kernel: [] smp_apic_timer_interrupt+0x3c/0x4e
Feb 26 21:26:09 Tower kernel: [] apic_timer_interrupt+0x6d/0x80
Feb 26 21:26:09 Tower kernel:   [] ? xor_sse_5_pf64+0xc3/0x3c0
Feb 26 21:26:09 Tower kernel: [] ? xor_sse_5_pf64+0x57/0x3c0
Feb 26 21:26:09 Tower kernel: [] xor_blocks+0x49/0x4b
Feb 26 21:26:09 Tower kernel: [] handle_stripe+0xd84/0x120f [md_mod]
Feb 26 21:26:09 Tower kernel: [] unraidd+0xda/0x194 [md_mod]
Feb 26 21:26:09 Tower kernel: [] md_thread+0xd2/0xe8 [md_mod]
Feb 26 21:26:09 Tower kernel: [] ? __wake_up_sync+0xd/0xd
Feb 26 21:26:09 Tower kernel: [] ? 0xffffffffa00c9000
Feb 26 21:26:09 Tower kernel: [] kthread+0xd6/0xde
Feb 26 21:26:09 Tower kernel: [] ? kthread_create_on_node+0x172/0x172
Feb 26 21:26:09 Tower kernel: [] ret_from_fork+0x7c/0xb0
Feb 26 21:26:09 Tower kernel: [] ? kthread_create_on_node+0x172/0x172

 

@jonp @limetech yet another RFS cpu stall issue to add to the growing list.

 

Link to comment

I'm not sure what to make of these notifications after rebooting:

 

unRAID Disk 2 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 90195689498

ST31500341AS_6VS03J6M (sdo)

×

unRAID Disk 1 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 8590065670

ST31000528AS_9VP97NMW (sdp)

×

unRAID Disk 3 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 47245361217

ST31500341AS_9VS1MA5Q (sdq)

×

unRAID Disk 4 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 47245361166

ST31500541AS_6XW0M4TZ (sdh)

×

unRAID Disk 12 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 1

ST32000641AS_9WM45ZH4 (sdl)

 

Anything to be concerned about? I note they reference just some of the Seagates and none of the WD's.

 

...Donovan

Link to comment

I'm not sure what to make of these notifications after rebooting:

 

unRAID Disk 2 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 90195689498

ST31500341AS_6VS03J6M (sdo)

×

unRAID Disk 1 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 8590065670

ST31000528AS_9VP97NMW (sdp)

×

unRAID Disk 3 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 47245361217

ST31500341AS_9VS1MA5Q (sdq)

×

unRAID Disk 4 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 47245361166

ST31500541AS_6XW0M4TZ (sdh)

×

unRAID Disk 12 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 1

ST32000641AS_9WM45ZH4 (sdl)

 

Anything to be concerned about?

 

...Donovan

 

I got similar messages for 2 drives. Googled "S.M.A.R.T command timeout" and what I found concerned me enough that I am replacing the two drives with new 4TBs. The drives in question are oldish and have a lot of hours on them so better safe than sorry I decided.

 

ps. interesting to note that I see your warnings are Seagate drives too. Both of mine were as well.

Link to comment

I'm not sure what to make of these notifications after rebooting:

 

unRAID Disk 2 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 90195689498

ST31500341AS_6VS03J6M (sdo)

×

unRAID Disk 1 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 8590065670

ST31000528AS_9VP97NMW (sdp)

×

unRAID Disk 3 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 47245361217

ST31500341AS_9VS1MA5Q (sdq)

×

unRAID Disk 4 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 47245361166

ST31500541AS_6XW0M4TZ (sdh)

×

unRAID Disk 12 SMART health [188]: 2015-02-26 06:31 PM

Warning [CRUSHINATOR] - command timeout is 1

ST32000641AS_9WM45ZH4 (sdl)

 

Anything to be concerned about? I note they reference just some of the Seagates and none of the WD's.

 

...Donovan

 

One of my disks (also Seagate) is showing the same issue. Now I do recall having an issue where I booted the server after installing a new WD disk and this disk wasn't showing up, I powered down checked the cables and powered up again, that fixed the issue. I assumed that this command time out error was due to that problem and not an lingering issue with the disk... if it is an ongoing issue I've not seen any signs of it, but would like to know more. 

 

Is there a good guide to use to understand smart report questions and if we should be concerned about them?

Link to comment

Just tried a parity check on this beta and it was going very slow. The system log is filled with these

 

Feb 26 21:25:07 Tower kernel: mdcmd (61): check CORRECT
Feb 26 21:25:07 Tower kernel: md: recovery thread woken up ...
Feb 26 21:25:07 Tower kernel: md: recovery thread checking parity...
Feb 26 21:25:07 Tower kernel: md: using 1536k window, over a total of 2930266532 blocks.
Feb 26 21:26:01 Tower sSMTP[11098]: Creating SSL connection to host
Feb 26 21:26:02 Tower sSMTP[11098]: SSL connection using RC4-SHA
Feb 26 21:26:03 Tower sSMTP[11098]: Sent mail for ####### (221 know-smtprelay-4-imp bizsmtp closing connection) uid=0 username=root outbytes=746
Feb 26 21:26:09 Tower kernel: INFO: rcu_sched self-detected stall on CPU { 2}  (t=6001 jiffies g=10526 c=10525 q=90297)
Feb 26 21:26:09 Tower kernel: Task dump for CPU 2:
Feb 26 21:26:09 Tower kernel: unraidd         R  running task        0  3155      2 0x00000008
Feb 26 21:26:09 Tower kernel: 0000000000000000 ffff88030fc83da8 ffffffff8105e0b5 0000000000000002
Feb 26 21:26:09 Tower kernel: 0000000000000002 ffff88030fc83dc8 ffffffff81060780 0000000000000004
Feb 26 21:26:09 Tower kernel: ffffffff81834400 ffff88030fc83df8 ffffffff8107845f ffffffff81834400
Feb 26 21:26:09 Tower kernel: Call Trace:
Feb 26 21:26:09 Tower kernel:   [] sched_show_task+0xbe/0xc3
Feb 26 21:26:09 Tower kernel: [] dump_cpu_task+0x35/0x39
Feb 26 21:26:09 Tower kernel: [] rcu_dump_cpu_stacks+0x6a/0x8c
Feb 26 21:26:09 Tower kernel: [] rcu_check_callbacks+0x1db/0x4f9
Feb 26 21:26:09 Tower kernel: [] ? tick_sched_handle+0x34/0x34
Feb 26 21:26:09 Tower kernel: [] update_process_times+0x3a/0x64
Feb 26 21:26:09 Tower kernel: [] tick_sched_handle+0x32/0x34
Feb 26 21:26:09 Tower kernel: [] tick_sched_timer+0x37/0x61
Feb 26 21:26:09 Tower kernel: [] __run_hrtimer.isra.29+0x57/0xb0
Feb 26 21:26:09 Tower kernel: [] hrtimer_interrupt+0xd9/0x1c0
Feb 26 21:26:09 Tower kernel: [] local_apic_timer_interrupt+0x50/0x54
Feb 26 21:26:09 Tower kernel: [] smp_apic_timer_interrupt+0x3c/0x4e
Feb 26 21:26:09 Tower kernel: [] apic_timer_interrupt+0x6d/0x80
Feb 26 21:26:09 Tower kernel:   [] ? xor_sse_5_pf64+0xc3/0x3c0
Feb 26 21:26:09 Tower kernel: [] ? xor_sse_5_pf64+0x57/0x3c0
Feb 26 21:26:09 Tower kernel: [] xor_blocks+0x49/0x4b
Feb 26 21:26:09 Tower kernel: [] handle_stripe+0xd84/0x120f [md_mod]
Feb 26 21:26:09 Tower kernel: [] unraidd+0xda/0x194 [md_mod]
Feb 26 21:26:09 Tower kernel: [] md_thread+0xd2/0xe8 [md_mod]
Feb 26 21:26:09 Tower kernel: [] ? __wake_up_sync+0xd/0xd
Feb 26 21:26:09 Tower kernel: [] ? 0xffffffffa00c9000
Feb 26 21:26:09 Tower kernel: [] kthread+0xd6/0xde
Feb 26 21:26:09 Tower kernel: [] ? kthread_create_on_node+0x172/0x172
Feb 26 21:26:09 Tower kernel: [] ret_from_fork+0x7c/0xb0
Feb 26 21:26:09 Tower kernel: [] ? kthread_create_on_node+0x172/0x172

 

@jonp @limetech yet another RFS cpu stall issue to add to the growing list.

 

By RFS I take it you mean ReiserFS. That's interesting because all my drives are XFS. I have added a system log and wanted to add it does not happen on B14a.

Link to comment

Just updated to 14b and tried notifications for the first time.

 

I am getting incorrect notifications for all my disks being overtemperature, eg:

 

Event: unRAID Cache disk temperature

Subject: Alert [TOWER] - Cache disk overheated (91 )

Description: WDC_WD10EADS-65L5B1_WD-WCAU4C801686 (sdd)

Importance: alert

 

When looking at the GUI none of the disk temps are over 33C.

 

Is this normal, is the feature not working yet?

Link to comment

Just updated to 14b and tried notifications for the first time.

 

I am getting incorrect notifications for all my disks being overtemperature, eg:

 

Event: unRAID Cache disk temperature

Subject: Alert [TOWER] - Cache disk overheated (91 )

Description: WDC_WD10EADS-65L5B1_WD-WCAU4C801686 (sdd)

Importance: alert

 

When looking at the GUI none of the disk temps are over 33C.

 

Is this normal, is the feature not working yet?

 

Which is correct,  33C is 91.4F so the notification is correct

Link to comment

Thanks.

 

So, two questions:

 

Why does GUI report in C and alerts are in F ?

 

And how do I change the temperature threshold reporting because those are normal temps for me?

 

You can change the temp threshold in settings -> display settings at the bottom Warning disk temperature threshold:  &  Critical disk temperature threshold

 

Not sure why the alerts are not using the configured Temperature unit

Link to comment

Thanks.

 

They were set to 45 and 55 already and temperature unit set to Celsius so should not be alerting?

 

Perhaps I need to update them once, will give it a go.

 

 

edit: changed them to 46 and 56, then got notifications saying temp returned to normal. suspect some sort of bug with first time use.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.