Please Help - Disk showing Unformatted


Recommended Posts

I have been running the unraid server for about 1.5 years and never had any issues or drive fails.  This is my first major problem so please bear with me.  I was having a issues with my disk 2 where it was showing "not installed".  It ended up being the cable because was bad because when I put a new cable one on it worked.  I checked the files out on disk 2 and all the data was there, so I used the restore button.  Then I stared rebuilding the parity and the power went out.  When I rebooted the parity was invalid "in red" and disk 1 was showing now showing not installed.  So I used the restore button again and when I went to rebuild the parity disk 1 was showing unformatted.  Now disk 1 is a 1TB drive, but it's showing 32,532 as the size and under free is says "unformatted".  Figures, this was the only disk on my unraid server that had important data and it had all of my personal files on it.  If it was just music or movies then I wouldn't care because I can always put them back on.  But these were all my personal files and I am freaking out right now because I cannot believe this happened.  I have been trying to search the forums and wiki for helpful info, but I am so stressed out I cannot even focus.  Plus I don't want to try anything else that might screw things up.  I never clicked on the "format drive" button, so hopefully that means the data is still there.  This is honestly one of the sickest feeling I have ever felt and cannot believe it just happened.  If anyone is willing to help me out please let me know.

Link to comment

First off, let me say I'm sorry and I feel for you.  :(

 

I still haven't implemented unRAID yet, so I can't offer any advice or suggestions, except to say stop touching it and trying to fix it.  Wait until one of the "gurus" tells you what's going on and what to do to fix it.  When you're so worked up and upset, the worst thing to do is to get frantic and start pushing buttons.  Good luck, and I will be watching this thread intently to see what happens.

Link to comment

I don't want to try anything else that might screw things up.  I never clicked on the "format drive" button, so hopefully that means the data is still there.  This is honestly one of the sickest feeling I have ever felt and cannot believe it just happened.  If anyone is willing to help me out please let me know.

Good that you did not click on the format button....

 

Your description of what you did helps, but we have NO idea of what is happening on your server because you did not attach a syslog to any of your posts  so far.    To help you in any way, that is the next step.  Attach a syslog.

 

The other thing we need to know is if you used the "trust my parity" procedure when you used the "restore" button? (I'm guessing you did not... but please confirm)

 

Third, what version of unRAID are you running?  There have probably been 16 or so releases in the past 1.5 years.  It might make a difference as to what can be suggested as a possible corrective fix.

 

Fourth, describe your hardware configuration....

 

Joe L.

Link to comment

Joe, thanks so much for the response.  Sorry for not attaching the syslog file, but at the time of my post I didn't know how to do that.  I also attached a screen shot of my overview.  When I reboot it wants to do a parity sync, so I stopped that so I could grab a syslog file.

 

Yes, I used the "trust my parity" approach because the data was good on the drives and I have used the technique in the past with good success. 

 

I am running version 4.5 on Unraid.  Tried going back to 4.4.2 to see if that would help because I seen someone mentioned doing that in a post, but it didn't so went back to 4.5.

 

My hardware is:

Gigabye GA-K8N51GMF-9

4 1TB drives an 1 750 GB drive

SYBA SD-LP-PEX2IR PCI Express Low Profile SATA II Controller Card

 

Before I was using 4 sata ports on the MB and one on the controller card, but now I am using 3 sata ports on the MB and 2 sata ports on the controller card because it appears it might not have been a bad cable before on disk 2, but yet a bad sata connector on the MB because I did get "not installed shortly after installing a new cable.  I never installed a HD on disk 4, so that is why it shows not installed.

 

Let me know what other info you need.

syslog.txt

screenshot.JPG.d3609ded6459173ef09edd4e58578b66.JPG

Link to comment

Joe, thanks so much for the response.  Sorry for not attaching the syslog file, but at the time of my post I didn't know how to do that.  I also attached a screen shot of my overview.  When I reboot it wants to do a parity sync, so I stopped that so I could grab a syslog file.

 

Yes, I used the "trust my parity" approach because the data was good on the drives and I have used the technique in the past with good success.  

 

I am running version 4.5 on Unraid.  Tried going back to 4.4.2 to see if that would help because I seen someone mentioned doing that in a post, but it didn't so went back to 4.5.

 

My hardware is:

Gigabye GA-K8N51GMF-9

4 1TB drives an 1 750 GB drive

SYBA SD-LP-PEX2IR PCI Express Low Profile SATA II Controller Card

 

Before I was using 4 sata ports on the MB and one on the controller card, but now I am using 3 sata ports on the MB and 2 sata ports on the controller card because it appears it might not have been a bad cable before on disk 2, but yet a bad sata connector on the MB because I did get "not installed shortly after installing a new cable.  I never installed a HD on disk 4, so that is why it shows not installed.

 

Let me know what other info you need.

 

Your gigabyte BIOS has apparently applied a HPA on the Hitachi disk that will not mount making it appear to the OS as a small fraction of its real size.

 

To read about the HPA see here in the wiki: http://lime-technology.com/wiki/index.php?title=UnRAID_Topical_Index#HPA

 

These lines show what the kernel is seeing  disk1 (currently /dev/sde) is being detected as a tiny fraction of its native size.:

Jan 14 01:49:38 Tower kernel: ata5.00: HPA detected: current 65134, native 1953525168

Jan 14 01:49:38 Tower kernel: ata5.00: ATA-8: Hitachi HDT721010SLA360, ST6OA31B, max UDMA/133

Jan 14 01:49:38 Tower kernel: ata5.00: 65134 sectors, multi 16: LBA48 NCQ (depth 31/32)

Jan 14 01:49:38 Tower kernel: scsi 5:0:0:0: Direct-Access     ATA      Hitachi HDT72101 ST6O PQ: 0 ANSI: 5

Jan 14 01:49:38 Tower kernel: sd 5:0:0:0: [sde] 65134 512-byte logical blocks: (33.3 MB/31.8 MiB)

Jan 14 01:49:38 Tower kernel: sd 5:0:0:0: [sde] Write Protect is off

Jan 14 01:49:38 Tower kernel: sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00

Jan 14 01:49:38 Tower kernel: sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

 

It has also added an HPA to two other disks, although it is only making them about a meg smaller than native size.  

(disk2 - /dev/sda)

Jan 14 01:49:38 Tower kernel: ata1.00: HPA detected: current 1953523055, native 1953525168

Jan 14 01:49:38 Tower kernel: ata1.00: ATA-7: Hitachi HDS721010KLA330, GKAOAB0A, max UDMA/133

Jan 14 01:49:38 Tower kernel: ata1.00: 1953523055 sectors, multi 16: LBA48 NCQ (depth 31/32)

Jan 14 01:49:38 Tower kernel: ata1.00: configured for UDMA/100

Jan 14 01:49:38 Tower kernel: scsi 0:0:0:0: Direct-Access     ATA      Hitachi HDS72101 GKAO PQ: 0 ANSI: 5

Jan 14 01:49:38 Tower kernel: sd 0:0:0:0: [sda] 1953523055 512-byte logical blocks: (1.00 TB/931 GiB)

Jan 14 01:49:38 Tower kernel: sd 0:0:0:0: [sda] Write Protect is off

Jan 14 01:49:38 Tower kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00

Jan 14 01:49:38 Tower kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

and disk3 - /dev/sdd

Jan 14 01:49:38 Tower kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Jan 14 01:49:38 Tower kernel: ata4.00: HPA detected: current 1953523055, native 1953525168

Jan 14 01:49:38 Tower kernel: ata4.00: ATA-7: Hitachi HDS721010KLA330, GKAOAB0A, max UDMA/133

Jan 14 01:49:38 Tower kernel: ata4.00: 1953523055 sectors, multi 16: LBA48 NCQ (depth 31/32)

Jan 14 01:49:38 Tower kernel: ata4.00: configured for UDMA/133

Jan 14 01:49:38 Tower kernel: scsi 4:0:0:0: Direct-Access     ATA      Hitachi HDS72101 GKAO PQ: 0 ANSI: 5

Jan 14 01:49:38 Tower kernel: sd 4:0:0:0: [sdd] 1953523055 512-byte logical blocks: (1.00 TB/931 GiB)

Jan 14 01:49:38 Tower kernel: sd 4:0:0:0: [sdd] Write Protect is off

Jan 14 01:49:38 Tower kernel: sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00

Jan 14 01:49:38 Tower kernel: sd 4:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

 

You must use a low level disk utility to reset the HPA to the native size of the disk.  DO NOT bother with the two disks that can properly mount at this time.  Concentrate on fixing the drive that is reporting as only being 65134 blocks in size.

You "might" be able to use the hdparm command to reset the HPA.  This will only work if the BIOS did not already set it on this power cycle, since the size cannot be set but once per power cycles.

 

Before moving the disk to another PC where you can use one of the windows based tools to reset the HPA, You can try

hdparm -N p1953525168 /dev/sde

(the "1953525168" is the native size as reported in your syslog for that disk. Preceding it with a "p" is the syntax for the hdparm command to make the change permanent. )

 

followed by

hdparm -N /dev/sde

to see if it was effective.  You can read about the hdparm command here: http://lime-technology.com/forum/index.php?topic=4194

 

If the HPA was able to be removed/reset to full size of the drive, then a reboot might get you to where all the disks will mount.  (there still might be corruption of the file-system, so first priority is to get the disk to report its full size.)

 

If the hdparm command is un-successful, you might need to try a utility like "hdat2" ( http://www.hdat2.com/ )

Another tool mentioned in these forums that can reset an HPA is "Seatools (may be seagate specific)"

 

You'll still need to deal with the parity, as you may have corrupted it to where it is un-usable.  We'll deal with that once we get the disks to report their true size.   Apparently, there is a BIOS update for the Gigabyte MB that allow you to turn off the "feature" where it adds  an HPA.  I'd look into that if I were you too if you do not already have the ability to disable it in your existing BIOS.

 

Joe L.

Link to comment

I used those commands and they seemed to have worked, so maybe there still is a chance I can recover that data.  The drive no longer shows 32,532 as the size and now it's at full capacity.  So what should I do next?  I messed things up enough already and will wait to hear what you think I should try.  I also posted the syslog and a screenshot.

syslog2.txt

screenshot2.JPG.db401926ef96cdcab7cddbe324d9e3c0.JPG

Link to comment

That is good news.  Yes, there is some hope.

 

the unRAID server will not start now because it "thinks" that you changed disk1.  (It expected it to be the smaller size that it had when you last told it to initialize the configuration by pressing the button labeled "restore"  Now it is bigger and it thinks it is a different disk. )

 

You will need to initialize the configuration once more, but before you do that, let's do a quick file-system check of the file system on disk1

 

Type

reiserfsck /dev/md1

It should prompt you to answer "Yes" if you are sure you want to continue.  Answer "Y" (capital) "es" (lower case)

 

It will advise if additional options are needed.   First let's see if the file system was corrupted by the HPA your BIOS added.

 

Once the file-system is sane, you need to go through the "trust-my-parity" process once more AND LET THE PARITY CHECK RUN TO ITS COMPLETION.  It will likely make corrections to parity.  Expect them. (but your data should be back)

 

Joe L.

Link to comment
Did you have a chance to look at your BIOS, and disable HPA?

 

Yes, I looked all over and in the advanced bios and could not find anything there about disabling HPA.  It is a slightly older board, so maybe that was before they starting having that option.  I checked the manual and nothing there either.

 

Can a sata port on the motherboard go bad?  I thought disk2 was acting up because of the cable, but the problem showed up again later shortly after swapping in a new cable.  The port still works, but sometimes it will not recognize the hard drive during the boot or it will kick out while running.  The problem seems to have started ever since I lost power that one night.  When I moved the cable to a different sata port the problem seemed to have went away (at least for now).  If that is the case, then I will probably need to buy a new motherboard since that would limit me to 5 sata slots and I really need 6 of them for unraid plus.

 

Link to comment

You will need to initialize the configuration once more, but before you do that, let's do a quick file-system check of the file system on disk1

 

Type reiserfsck /dev/md1

 

It should prompt you to answer "Yes" if you are sure you want to continue.  Answer "Y" (capital) "es" (lower case)

 

It will advise if additional options are needed.  First let's see if the file system was corrupted by the HPA your BIOS added.

 

Unfortunately it did not work.  Got the following error:

 

Failed to open the device '/dev/md1': No such file or directory

Link to comment

You will need to initialize the configuration once more, but before you do that, let's do a quick file-system check of the file system on disk1

 

Type reiserfsck /dev/md1[/b]

 

It should prompt you to answer "Yes" if you are sure you want to continue.  Answer "Y" (capital) "es" (lower case)

 

It will advise if additional options are needed.   First let's see if the file system was corrupted by the HPA your BIOS added.

 

Unfortunately it did not work.  Got the following error:

 

Failed to open the device '/dev/md1': No such file or directory

Ok, we'll need to run it on the raw device

 

reiserfsck /dev/sde1

 

(Note the "1" at the end of the device name, indicating you wish to run it on the first partition on the disk)

 

Link to comment

The port still works, but sometimes it will not recognize the hard drive during the boot or it will kick out while running.  The problem seems to have started ever since I lost power that one night.

It sure sounds like an intermittent connection.   It could easily be the power cable to the drive.

Losing power causes everything to cool down and might aggravate any loose connection.

Link to comment
You will need to initialize the configuration once more, but before you do that, let's do a quick file-system check of the file system on disk1

 

Type reiserfsck /dev/md1[/b]

 

It should prompt you to answer "Yes" if you are sure you want to continue.  Answer "Y" (capital) "es" (lower case)

 

It will advise if additional options are needed.  First let's see if the file system was corrupted by the HPA your BIOS added.

 

Unfortunately this did not seem to work either since I got the following error:

 

*************************************************************

 

Will read-only check consistency of the filesystem on /dev/sde1

Will put log info to 'stdout'

 

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

bread: Cannot read the block (244190373): (Invalid argument).

 

reiserfs_open: Your partition is not big enough to contain the

filesystem of (244190373) blocks as was specified in the found super block.

Failed to open the filesystem.

 

If the partition table has not been changed, and the partition is

valid  and  it really  contains  a reiserfs  partition,  then the

superblock  is corrupted and you need to run this utility with

--rebuild-sb.

 

*************************************************************

 

  :(

Link to comment

The port still works, but sometimes it will not recognize the hard drive during the boot or it will kick out while running.  The problem seems to have started ever since I lost power that one night.

It sure sounds like an intermittent connection.  It could easily be the power cable to the drive.

Losing power causes everything to cool down and might aggravate any loose connection.

 

I have a few unused power cables, so can easily try another one from the power supply.  The reason I figured the sata port was the problem is it seemed to go away when I switched to a sata port and kept the same power cable.

Link to comment

It wants us to rebuild the superblock...   before we do that, we need to make sure the partition on the disk is the size we expect it to be. (odds are it correct, but just to be sure)

 

Type

sfdisk -g /dev/sde

 

and

blockdev --getsz /dev/sde

and

fdisk -l -u /dev/sde

 

and lastly

od -x -A d /dev/sde | head

 

Those are all different ways of displaying the geometry of the drive and the current partitioning.   If the partition is the correct size, then we can rebuild the file system superblock.  To do that you will be prompted for a series of prompts... The responses are critical, and are not the defaults... so don't do that command just yet.  Not until we know the partitioning is correct.

 

Basically, your brain-damaged BIOS did not just create an HPA (host protected area) but put some data there to "help" you if the BIOS ever got corrupted.   Yeah, some help...  I cannot envision any BIOS that should make your disk look so tiny as they did, but let's just say I'll never build a computer with a GigaByte MB unless it could disable that "feature"

 

Let's see if the partitioning looks sane.  If it is, then I'll direct you to the post that describes how to respond to the rebuild-sb prompts.

 

Joe L.

Link to comment

Here are the results.  Not quite sure what the protocol is for posting logs like this in the forum, but if it should just be attached as a text file like the syslog let me know and I will change it.

 

 

root@Tower:~# sfdisk -g /dev/sde

/dev/sde: 121601 cylinders, 255 heads, 63 sectors/track

 

 

root@Tower:~# blockdev --getsz /dev/sde

1953525168

 

 

root@Tower:~# fdisk -l -u /dev/sde

 

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes

1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x247daecd

 

  Device Boot      Start        End      Blocks  Id  System

/dev/sde1              63      65133      32535+  83  Linux

Partition 1 does not end on cylinder boundary.

 

 

root@Tower:~# od -x -A d /dev/sde | head

0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

0000432 0000 0000 0000 0000 aecd 247d 0000 0000

0000448 0000 0083 0000 003f 0000 fe2f 0000 0000

0000464 0000 0000 0000 0000 0000 0000 0000 0000

*

0000496 0000 0000 0000 0000 0000 0000 0000 aa55

0000512 0000 0000 0000 0000 0000 0000 0000 0000

*

0097792 0ca6 0e8e 4ed0 060b 000d 078a 0012 0000

root@Tower:~#

Link to comment

Here are the results.  Not quite sure what the protocol is for posting logs like this in the forum, but if it should just be root@Tower:~# fdisk -l -u /dev/sde

 

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes

1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x247daecd

 

   Device Boot      Start         End      Blocks   Id  System

/dev/sde1              63       65133       32535+  83  Linux

Partition 1 does not end on cylinder boundary.

In-line like this for short output is easier for me.  Your protocol is fine.

 

On the other hand, your partition on the disk is tiny.  It is nowhere near correct.  No wonder the file-system check complained.

 

We need to fix the partition table fist, then re-run the reiserfsck command.

I need to give a bit of thought how to fix the partition table... (the easiest way, that is)  Basically, the "start" is correct on sector 63, but the "end" should be  (I think) sector 1953525167.

 

Joe L.

Link to comment

Cooch,

 

I created a utility program to "partition" a disk exactly as unRAID would partition it.  (it is attached to this post) It is loosely based on the preclear_disk.sh script I created, but it does not clear anything.  It only writes the first 512 bytes of a disk.

 

Edit: March 1, 2011 -  I modified the script to work properly with newer versions of unRAID.  It also now has a "-A" option to fix partitions starting on sector 64.

Edit: February 2013 - Do NOT use this script on disks > 2.2TB.  It will NOT work properly on disks that do not use an MBR partition scheme.

 

The first 512 bytes on a disk are the master boot record and the partition table.  The attached script will completely overwrite the first 512 bytes, creating a correct single partition definition.  This program does not create a file system, nor does it delete any existing file system.  It is entirely designed to fix a corrupted MBR partition table.

 

All that said, for others following this thread, if you have no need to use this, do not invoke it on one of your disks.  It is un-likely to harm anything, but you've been warned.  Odds are good it will simply write exactly what is already there.  Never invoke it on your parity disk... the parity disk does not have a partition table since it has no file system.

Edit; I've been corrected.  The parity disk does have an MBR structure. It is OK to run the utility on the parity disk if its MBR is mangled.

 

If you invoke it with no parameters (other than a disk device) it will do a test only and print if your disk is partitioned for unRAID.  If you invoke it in test mode on a pre-cleared disk it will tell you the partitioning is OK, but the file-system type is not set.

 

Invoking this with the "-p" option will set the partitioning according to the reported geometry of the disk.  If, as in this thread, the reported geometry is wrong, because something set an HPA to make the disk artificially shorter, the partition will not be set to the full size of the disk.  In other words, fix the HPA first, then run this procedure.

 

If you invoke this procedure on a pre-cleared disk, (and use the "-p" option) it will no longer be recognized as pre-cleared.

 

So  to invoke this script to test the existing partition only, and make no changes type:

unraid_partition_disk.sh  /dev/XXX

To invoke it to fix the existing partition, add the "-p" option. type:

unraid_partition_disk.sh  -p /dev/XXX

 

where XXX = the raw disk  /dev/hda, /dev/hdb, /dev/sda, /dev/sdb, etc.

 

If you invoke it with the "-p" option, you will be prompted for a response before it continues to write to the disk.

Answer "Yes" to the prompt.  Any other response will abort and no changes will be made to the disk.

 

You are on your own if use of this creates a new black-hole, or re-formats all the hard-disks on your LAN.  (It shouldn't) ;D  Since most of the logic was cut-and-pasted from my preclear script, odds are you'll be safe.

 

Cooch, run this on your sde disk, then re-run the very first reiserfsck on the first partition on the disk without any special options.  If it still complains about a missing superblock, proceed with the rebuild-sb option, USING THE RESPONSES to its prompts, as described in the other thread.  Only run that once.  Respond back with whatever it says.

Your commands will be:

unraid_partition_disk.sh  /dev/sde

It should complain the partition is not correct.

 

Then:

unraid_partition_disk.sh  -p /dev/sde

reiserfsck /dev/sde1

and if it still complains of a missing superblock:

reiserfsck --rebuild-sb /dev/sde1

 

Be aware that working on the "raw" device, as we are, will not keep parity in sync when the file-system is repaired, so once the disk is back to where it can be mounted, we need to do a full parity check.  (We'll probably need to use the trust-my-parity procedure once more)

 

Joe L.

unraid_partition_disk.zip

Link to comment

Yes, I am sitting here patiently watching the clock go by.  I am hanging in there, but at this point I am just expecting the worst but still hoping for the best.  That way if the data is lost them I am prepared to deal with it.  I just fear too much damage was done already and the data is gone.  If Joe can help me recover the data then I will truly be amazed and count my blessings, but like I said I have to prepare myself for the worst now.

 

What sucks is I built the server mainly so I wouldn't have to worry about loosing my personal files if my PC's ever crashed and it was such a good feeling knowing my data was always going to be safe.  This allowed me to get ride of a lot of the external drives I used to store my backup files on.  I never expected this to happen and now I am kicking myself for it.  I hate being one of those "newbie" people who always just post their problems on the forum without researching how to fix it.  I spent hours reading the forum's and wiki for help, but there is a lot of information to take in and the technical stuff can be intimidating at times.  I thought I was doing the right things, but now looking back I probably did some things that made the situation worse.  I guess the lesson to be learned is to double check with the people here before trying to fix a problem when it occurs because it's always better to be safe then sorry.

Link to comment

Yes, I am sitting here patiently watching the clock go by.  I am hanging in there, but at this point I am just expecting the worst but still hoping for the best.  That way if the data is lost them I am prepared to deal with it.  I just fear too much damage was done already and the data is gone.  If Joe can help me recover the data then I will truly be amazed and count my blessings, but like I said I have to prepare myself for the worst now.

 

What sucks is I built the server mainly so I wouldn't have to worry about loosing my personal files if my PC's ever crashed and it was such a good feeling knowing my data was always going to be safe.  This allowed me to get ride of a lot of the external drives I used to store my backup files on.  I never expected this to happen and now I am kicking myself for it.  I hate being one of those "newbie" people who always just post their problems on the forum without researching how to fix it.  I spent hours reading the forum's and wiki for help, but there is a lot of information to take in and the technical stuff can be intimidating at times.  I thought I was doing the right things, but now looking back I probably did some things that made the situation worse.  I guess the lesson to be learned is to double check with the people here before trying to fix a problem when it occurs because it's always better to be safe then sorry.

 

Sorry to have to remind you of this, (you brought it up) but unRAID is not a backup of your critical files.  All it takes is a single fire/flood/tornado/lightning hit and your server is toast.  You should, at the least, make a copy of critical files and store them off-site.  See this post for some ideas: http://lime-technology.com/forum/index.php?topic=2601.msg21033#msg21033

 

However... all that said, your files are still there on that disk... we just need to get to them.  let's just take it one step at a time.  Once the file-system partition size is fixed, the odds are the rebuild of the reiserfs superblock will work.  Then, we may need to rebuild the file-tree in the file-system.  (We'll see what reiserfsck suggests first.  as you said, cool heads will be far better than rash actions and mistakes) 

 

Joe L.

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.