Re: dd - proper use or more suitable program

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Nov 12, 2016 at 01:25:50PM -0600, Richard Owlett wrote:
> On 11/12/2016 12:26 PM, Pascal Hambourg wrote:
> >Le 12/11/2016 à 18:22, Richard Owlett a écrit :
> >>
> ddrescue /dev/sda /mnt/defective_drive.img
> /mnt/defective_drive.log
> >(...)
> >>Can this be run as a user, or are root permissions required.
> >
> >Unless the user has read permission on the raw device, it must be
> >run as root.
> 
> I have a STRONG suspicion that by "raw device" you refer to the
> defective device which is enumerated as /dev/sdc . *ALL*
> documentation and tutorials I found make a *MAJOR POINT* of *NOT*
> mounting the defective device. "Permissions" therefor are a murky
> issue.

In this case, the permissions on /dev/sdc were meant (as opposed
to the permissions on the files whithin the file system in /dev/sdc,
which don't count in this case)

> Point of fact, the specific physical defective object
> predates me having more than casual interest in *nix.

Yes: I remember there's a DOS file system in the disk in question,
so no permissions in there anyway. But as stated above, this doesn't
matter, because you're looking at the container: access to that
is ruled by the permissions on the device file, i.e. /dev/sdc.

> There's a reason I asked for "hand holding" and specifically asked
> for tolerance.
> In a "user to user" support enviroment ther is an expectation of
> querent doing his due diligence. I tried. I failed. M'aidez s'il
> vous plait.

In a nutshell: you mount your *new* disk to a directory of your
choice (let's say /mnt). Possibly your OS is set up to do that
for you: it'll typically end then somewhere in /media/blah (for
some suitable value of "blah"). Let's use /mnt as a placeholder.

Then you insert you defective disk, which (let's say) appears
as /dev/sdc. Make sure the OS doesn't mount it automatically,
otherwise unmount yourself.

Then you do

  dd if=/dev/sdc of=/mnt/my-disk-backup bs=4096 count=100

(this is over-simplified: you'll probably use ddrescue instead
of dd, or at least use the option 'noerror').

An image of your disk will hopefully appear on 'my-disk-backup'.
You need read access to /dev/sdc and write access to the directory
/mnt (either by doing sudo, I'd do that or by other means).

Those steps are a rough sketch. Many details already flew back
and forth in this thread, so I didn't want to bloat the thing
too much. Feel free to ask where things are unclear.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgngikACgkQBcgs9XrR2kYjmACeJyeAvYCCrcfx2UuSglH7Dnvb
eg0An14EEu9c0jwQTcjF5/4bNCm9qHTV
=c2+e
-END PGP SIGNATURE-

Re: dd - proper use or more suitable program

[Brian]

On Sun 13 Nov 2016 at 08:54:05 +1300, Ben Caradoc-Davies wrote:

> On 13/11/16 08:25, Richard Owlett wrote:
> >I've gone to lenghts to defeat Debian's attempts to out-M$ Wm Gates.
> 
> Redmond is now our ally against the closed garden at Cupertino, with cloud
> image support, open-sourced language platforms, and even Ubuntu integration
> on the desktop.
> 
> We've always been at war with Eastasia.

I imagine Richard Owlett's comment has attracted this sort of response.
Neither helps with a solution to the issue.

-- 
Brian.

Re: dd - proper use or more suitable program

[Ben Caradoc-Davies]

On 13/11/16 08:25, Richard Owlett wrote:

I've gone to lenghts to defeat Debian's attempts to out-M$ Wm Gates.


Redmond is now our ally against the closed garden at Cupertino, with 
cloud image support, open-sourced language platforms, and even Ubuntu 
integration on the desktop.


We've always been at war with Eastasia.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: dd - proper use or more suitable program

[Richard Owlett]

On 11/12/2016 12:26 PM, Pascal Hambourg wrote:

Le 12/11/2016 à 18:22, Richard Owlett a écrit :



ddrescue /dev/sda /mnt/defective_drive.img
/mnt/defective_drive.log

(...)

Can this be run as a user, or are root permissions required.


Unless the user has read permission on the raw device, it must be
run as root.


I have a STRONG suspicion that by "raw device" you refer to the 
defective device which is enumerated as /dev/sdc . *ALL* 
documentation and tutorials I found make a *MAJOR POINT* of *NOT* 
mounting the defective device. "Permissions" therefor are a murky 
issue. Point of fact, the specific physical defective object 
predates me having more than casual interest in *nix.


There's a reason I asked for "hand holding" and specifically 
asked for tolerance.
In a "user to user" support enviroment ther is an expectation of 
querent doing his due diligence. I tried. I failed. M'aidez s'il 
vous plait.





My defective drive is /dev/sdc .
Partition /dev/sdb6 {formatted ext4} is much larger than the
defective
drive.
/dev/sdb is a 1 TB rotating platter drive connected via USB.
How do I mount it and run ddrescue?


Mount what ?


Whatever that needs to be mounted.
There *IS* a reason I explicitly stated that I needed an atypical 
amount of hand holding!



You don't mount anything from the defective drive.
You mount the filesystem which will receive the disk image file
anywhere you like with mount. In the above example it was
expected to be mounted on /mnt, the usual temporary mount point.
So :

mount /dev/sdb6 /mnt

The file manager of your desktop environment may have already
mounted it for you elsewhere in /media/. Check df or mount.



I've gone to lenghts to defeat Debian's attempts to out-M$ Wm Gates.
I predate the 8085 when it was acceptable manufacturing practice 
to cut/jumper etchs to "reprogram" 7400 series devices.


Tolerant help please.

Re: dd - proper use or more suitable program

[Pascal Hambourg]

Le 12/11/2016 à 18:22, Richard Owlett a écrit :



ddrescue /dev/sda /mnt/defective_drive.img /mnt/defective_drive.log

(...)

Can this be run as a user, or are root permissions required.


Unless the user has read permission on the raw device, it must be run as 
root.



My defective drive is /dev/sdc .
Partition /dev/sdb6 {formatted ext4} is much larger than the defective
drive.
/dev/sdb is a 1 TB rotating platter drive connected via USB.
How do I mount it and run ddrescue?


Mount what ?
You don't mount anything from the defective drive.
You mount the filesystem which will receive the disk image file anywhere 
you like with mount. In the above example it was expected to be mounted 
on /mnt, the usual temporary mount point. So :


mount /dev/sdb6 /mnt

The file manager of your desktop environment may have already mounted it 
for you elsewhere in /media/. Check df or mount.

Re: dd - proper use or more suitable program

[Richard Owlett]

On 11/12/2016 2:29 AM, Richard Owlett wrote:

On 11/12/2016 1:31 AM, Christian Seiler wrote:

On 11/11/2016 10:38 PM, Richard Owlett wrote:

I was wondering about that.
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
is
not first time user friendly. Will re-read after a good night's
sleep. Will also look for appropriate tutorials. Suggestions?


Well, I would suggest not dumping the result on another partition
but rather into an image file. In that case you'd have the old
drive (not mounted), let's call it /dev/sda, and the new drive
with a partition on it and mounted on /mnt with sufficient free
disk space there.

In the simplest case you'd do:

ddrescue /dev/sda /mnt/defective_drive.img
/mnt/defective_drive.log


I can't get that performing correctly. I have a strong suspicion 
I'm even more confused about mounting than the group suspects :<


Can this be run as a user, or are root permissions required.

May I have a little hand-holding please?
My defective drive is /dev/sdc .
Partition /dev/sdb6 {formatted ext4} is much larger than the 
defective drive.

/dev/sdb is a 1 TB rotating platter drive connected via USB.
How do I mount it and run ddrescue?
I'm tired and likely going in circles. Need to get groceries, 
will be back soon.


Thank you for patience.

Re: dd - proper use or more suitable program

[Richard Owlett]

On 11/11/2016 10:45 PM, Andy Smith wrote:

Hi Richard,

On Fri, Nov 11, 2016 at 03:31:21PM -0600, Richard Owlett wrote:

How big might the logfile be when trying to recover a known flaky 300
GB drive. I've lots of space? Some convienient, some not.


TL;DR: this depends on how many bad sectors you expect to find. If
the number is likely to be low then the map file should be a matter
of kilobytes in size.


Based on your example calculations I should be in good shape. 
Only one partition [the old c: drive] seems to be in bad shape. 
I've found some tutorial material that clears up enough that I'm 
confident of running safely even if not optimized.







I've never looked into this before as it's never been an issue for
me, but looking at:

 
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Mapfile-structure

The header of the map file looks like:

  # Mapfile. Created by GNU ddrescue version 1.21
  # Command line: ddrescue -d -c18 /dev/fd0 fdimage mapfile
  # Start time:   2015-07-21 09:37:44
  # Current time: 2015-07-21 09:38:19
  # Copying non-tried blocks... Pass 1 (forwards)
  # current_pos  current_status
  0x0012 ?
  #  possize  status

…which is 304 bytes.

After that there is one line for each range of blocks depending on
their status (finished, not tried yet, failed etc).

I am thinking that the absolute worst case in terms of maximal
number of lines in this file would be if every other sector were
failed, so you'd have an alternating sequence of:

0x  0x0001  +
0x0001  0x0001  -
0x0002  0x0001  +
0x0003  0x0001  -

for the entire device. That's 52 bytes for every two blocks.

The default block size is 512 bytes in ddrescue, so two blocks
covers 1024 bytes of your device.

If your device is 300 gigabytes in size—and I'll assume that is SI
power of ten giga- (not binary power of two gibi-) as is common with
drive manufacturers, so 300,000,000,000 bytes—then that's
300,000,000,000 / 1,024 = 292,968,750. That times 54 bytes is
15,820,312,500 bytes. Or 14.73GiB. Plus a ~304 byte header.

As far as I can see that is the absolute worst case and for a more
realistic scenario of a device with only a couple of bad sectors
you'd be looking at mere kilobytes of map file size.

For example, if merely 1% of the sectors were bad (and I would
suggest that even that would represent a catastrophically damaged
device that you will find very difficult to extract any sense out
of) then you'd still only be looking at a map file with 5,859,375
bad blocks in it (5,859,375 bad sectors out of 585,937,500 total
512-byte sectors in a 300,000,000,000 byte device). This would
require 5,859,376 different ranges in the map file, with each range
being 27 bytes, so 27 * 5,859,376 = 158,203,152 bytes = 150.9MiB.

I doubt you will see 5.9 million bad sectors on your 300G drive!

Basically whenever my destination has had noticeably more space than
the source device I haven't spared a thought to this so have never
worked it out before. I think the above is correct but look forward
to a correction from anyone who knows better.

Also do note that should you run out of space when writing the map
file, you still have the map file that has been written to date, so
you can extricate yourself from the situation and rerun ddrescue,
safe in the knowledge that it will pick up from where it got to.

If you are expecting serious numbers of bad sectors then your most
precious resource may actually be time. ddrescue tries REALLY HARD
to read a bad sector with each try potentially taking 2 or more
minutes. So on the hypothetical "1% broken" drive with 5.9 million
bad sectors, a single pass could take upwards of 10 million minutes
(19 years). And sometimes multiple passes are required to read a bad
sector.

Cheers,
Andy

Re: dd - proper use or more suitable program

[Christian Seiler]

On 11/11/2016 10:38 PM, Richard Owlett wrote:
> I was wondering about that. 
> https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html is
> not first time user friendly. Will re-read after a good night's
> sleep. Will also look for appropriate tutorials. Suggestions?

Well, I would suggest not dumping the result on another partition
but rather into an image file. In that case you'd have the old
drive (not mounted), let's call it /dev/sda, and the new drive
with a partition on it and mounted on /mnt with sufficient free
disk space there.

In the simplest case you'd do:

ddrescue /dev/sda /mnt/defective_drive.img /mnt/defective_drive.log

If the drive is farther gone and has quite a few defective
sectors you may get better results if you use direct disk access
for the phase where you try to read defective sectors. In that case
you'd copy the bulk of the data while disabling the scraping phase
manually,

ddrescue -n /dev/sda /mnt/defective_drive.img /mnt/defective_drive.log

And then use direct access to scrape the rest:

ddrescue -d /dev/sda /mnt/defective_drive.img /mnt/defective_drive.log

Note that ddrescue assumes a default sector size of 512 bytes,
which is likely to be correct for older hard drives smaller than
2 TiB. If you have a newer hard drive, especially if it's rather
large, the physical sector size could be 4096 bytes instead.
(You can check the physical sector size of your disk by running
hdparm -I /dev/sda - that will tell you a lot of things about
your drive, among them the physical sector size in bytes. Note
that the physical sector size is relevant here, not the logical
one.)

In addition, you may also want to specify a number of retries
when trying to read defective sectors. (Default is 0.) You can
do that with the -r flag, e.g. -r3 for three retries per sector.

To recap:

 - Simplest way of calling the program is

   ddrescue /dev/sda output_image_file log_file

 - If the condition of your hard drive is a bit worse, you might
   achieve better results with:

   ddrescue -n /dev/sda output_image_file log_file
   ddrescue -d -r2 /dev/sda output_image_file log_file

   (-r2 is for 2 retries per defective sector, you can change
   that number; you can also call the second ddrescue command
   again in case you want to do more retries.)

 - If you have a new disk with 4096 bytes / sector (not likely)
   please also add a -b4096 to the command line.

 - If your target is not an image file, but a disk drive itself,
   also specify the -f option. (I would really recommend using
   image files though, gives you more flexibility.)

 - I wouldn't really bother with the other options, the default
   behavior is very sensible.

 - Finally, get some coffee or similar, this may take a while.

Regards,
Christian

Re: dd - proper use or more suitable program

[Andy Smith]

Hi Richard,

On Fri, Nov 11, 2016 at 03:31:21PM -0600, Richard Owlett wrote:
> How big might the logfile be when trying to recover a known flaky 300
> GB drive. I've lots of space? Some convienient, some not.

TL;DR: this depends on how many bad sectors you expect to find. If
the number is likely to be low then the map file should be a matter
of kilobytes in size.

I've never looked into this before as it's never been an issue for
me, but looking at:


https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Mapfile-structure

The header of the map file looks like:

 # Mapfile. Created by GNU ddrescue version 1.21
 # Command line: ddrescue -d -c18 /dev/fd0 fdimage mapfile
 # Start time:   2015-07-21 09:37:44
 # Current time: 2015-07-21 09:38:19
 # Copying non-tried blocks... Pass 1 (forwards)
 # current_pos  current_status
 0x0012 ?
 #  possize  status

…which is 304 bytes.

After that there is one line for each range of blocks depending on
their status (finished, not tried yet, failed etc).

I am thinking that the absolute worst case in terms of maximal
number of lines in this file would be if every other sector were
failed, so you'd have an alternating sequence of:

0x  0x0001  +
0x0001  0x0001  -
0x0002  0x0001  +
0x0003  0x0001  -

for the entire device. That's 52 bytes for every two blocks.

The default block size is 512 bytes in ddrescue, so two blocks
covers 1024 bytes of your device.

If your device is 300 gigabytes in size—and I'll assume that is SI
power of ten giga- (not binary power of two gibi-) as is common with
drive manufacturers, so 300,000,000,000 bytes—then that's
300,000,000,000 / 1,024 = 292,968,750. That times 54 bytes is
15,820,312,500 bytes. Or 14.73GiB. Plus a ~304 byte header.

As far as I can see that is the absolute worst case and for a more
realistic scenario of a device with only a couple of bad sectors
you'd be looking at mere kilobytes of map file size.

For example, if merely 1% of the sectors were bad (and I would
suggest that even that would represent a catastrophically damaged
device that you will find very difficult to extract any sense out
of) then you'd still only be looking at a map file with 5,859,375
bad blocks in it (5,859,375 bad sectors out of 585,937,500 total
512-byte sectors in a 300,000,000,000 byte device). This would
require 5,859,376 different ranges in the map file, with each range
being 27 bytes, so 27 * 5,859,376 = 158,203,152 bytes = 150.9MiB.

I doubt you will see 5.9 million bad sectors on your 300G drive!

Basically whenever my destination has had noticeably more space than
the source device I haven't spared a thought to this so have never
worked it out before. I think the above is correct but look forward
to a correction from anyone who knows better.

Also do note that should you run out of space when writing the map
file, you still have the map file that has been written to date, so
you can extricate yourself from the situation and rerun ddrescue,
safe in the knowledge that it will pick up from where it got to.

If you are expecting serious numbers of bad sectors then your most
precious resource may actually be time. ddrescue tries REALLY HARD
to read a bad sector with each try potentially taking 2 or more
minutes. So on the hypothetical "1% broken" drive with 5.9 million
bad sectors, a single pass could take upwards of 10 million minutes
(19 years). And sometimes multiple passes are required to read a bad
sector.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: dd - proper use or more suitable program

[Mark Fletcher]

On Fri, Nov 11, 2016 at 10:49:37AM -0600, Richard Owlett wrote:

> I had been removed after becoming unreliable. 

Sorry to hear that. Advanced years don't come on their own, do they?

(Sorry, couldn't resist it)

Re: dd - proper use or more suitable program

[Richard Owlett]

On 11/11/2016 11:49 AM, Nicolas George wrote:

Le primidi 21 brumaire, an CCXXV, Andy Smith a écrit :

You are better off using GNU ddrescue for taking images of
possibly-failing devices.


IIRC, there is a catch there: there is another program with a very
similar name that does not work the same way. Be careful when installing
it.


Jessie DVD's catch that. What Synaptic fetches is gddrescue, but 
after loading you invoke it as just ddrescue.





Amongst other issues, dd will either give up or produce zeroes when
it encounters problems whereas ddrescue will keep track of where it
was unable to read and keep trying.


For the record, when using dd to copy data from a damaged medium, always
use conv=noerror,sync. Without noerror, dd would stop at the first
error and without sync it would just skip the block, making the dump
useless.

But of course, as you say, ddrescue keeps a log of the parts that could
not be read, which is even more useful.

Also, I would advise to dump to a file, not a raw partition.



I was wondering about that.
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html 
is not first time user friendly. Will re-read after a good 
night's sleep. Will also look for appropriate tutorials. Suggestions?

Re: dd - proper use or more suitable program

[Richard Owlett]

On 11/11/2016 12:13 PM, The Wanderer wrote:

On 2016-11-11 at 12:37, Christian Seiler wrote:


Hi,

Am 11. November 2016 17:57:27 MEZ, schrieb Andy Smith
:


Hi Richard,

On Fri, Nov 11, 2016 at 10:49:37AM -0600, Richard Owlett wrote:


I was considering using dd to copy the entire drive to a
*SINGLE* partition of a 1 TB drive with the intention making a
"byte perfect" of of the defective drive to a new 300 GB drive at
a later time to then attempt "data rescue". Partitions other than
the first are evidently readable.

Suggestions/comments please.


You are better off using GNU ddrescue for taking images of
possibly-failing devices.


Full ACK: GNU ddrescue has saved my data multiple times in the past,
I can really recommend it. (The "log file" is very helpful with
resuming at a later point in time if you had to cancel it.)

Just don't confuse it with dd_rescue, which I don't recommend unless
you are an expert and have a very special case.


There's also myrescue, which is similar in function to both but which
I've found easier and less confusing to use in the past - if perhaps
only because it eliminates the confusion about remembering which of the
other two is the one which is more problematic.


http://myrescue.sourceforge.net/ doesn't indicate whether it will 
attempt to do what I want.
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html 
is long and not oriented to first time user. But explicitly 
claims to do what I want. I'll have to re-read after a good 
night's sleep.





The trouble with all of these is that not only do you need a device with
enough space to store the entire device you're drawing from (ideally in
a file rather than on the device directly), to do it properly and safely
you also need enough extra space - on another device is fine - to store
the log file which gets created during the rescue process.



How big might the logfile be when trying to recover a known flaky 
300 GB drive. I've lots of space? Some convienient, some not.

Re: dd - proper use or more suitable program

[The Wanderer]

On 2016-11-11 at 12:37, Christian Seiler wrote:

> Hi,
> 
> Am 11. November 2016 17:57:27 MEZ, schrieb Andy Smith
> :
> 
>> Hi Richard,
>> 
>> On Fri, Nov 11, 2016 at 10:49:37AM -0600, Richard Owlett wrote:
>> 
>>> I was considering using dd to copy the entire drive to a
>>> *SINGLE* partition of a 1 TB drive with the intention making a
>>> "byte perfect" of of the defective drive to a new 300 GB drive at
>>> a later time to then attempt "data rescue". Partitions other than
>>> the first are evidently readable.
>>> 
>>> Suggestions/comments please.
>> 
>> You are better off using GNU ddrescue for taking images of
>> possibly-failing devices.
> 
> Full ACK: GNU ddrescue has saved my data multiple times in the past,
> I can really recommend it. (The "log file" is very helpful with
> resuming at a later point in time if you had to cancel it.)
> 
> Just don't confuse it with dd_rescue, which I don't recommend unless
> you are an expert and have a very special case.

There's also myrescue, which is similar in function to both but which
I've found easier and less confusing to use in the past - if perhaps
only because it eliminates the confusion about remembering which of the
other two is the one which is more problematic.

The trouble with all of these is that not only do you need a device with
enough space to store the entire device you're drawing from (ideally in
a file rather than on the device directly), to do it properly and safely
you also need enough extra space - on another device is fine - to store
the log file which gets created during the rescue process.

-- 
   The Wanderer can't figure out why he's now thinking of the game IVAN

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: dd - proper use or more suitable program

[Nicolas George]

Le primidi 21 brumaire, an CCXXV, Andy Smith a écrit :
> You are better off using GNU ddrescue for taking images of
> possibly-failing devices.

IIRC, there is a catch there: there is another program with a very
similar name that does not work the same way. Be careful when installing
it.

> Amongst other issues, dd will either give up or produce zeroes when
> it encounters problems whereas ddrescue will keep track of where it
> was unable to read and keep trying.

For the record, when using dd to copy data from a damaged medium, always
use conv=noerror,sync. Without noerror, dd would stop at the first
error and without sync it would just skip the block, making the dump
useless.

But of course, as you say, ddrescue keeps a log of the parts that could
not be read, which is even more useful.

Also, I would advise to dump to a file, not a raw partition.


signature.asc
Description: Digital signature

Re: dd - proper use or more suitable program

[Christian Seiler]

Hi,

Am 11. November 2016 17:57:27 MEZ, schrieb Andy Smith :
>Hi Richard,
>
>On Fri, Nov 11, 2016 at 10:49:37AM -0600, Richard Owlett wrote:
>> I was considering using dd to copy the entire drive to a *SINGLE*
>> partition of a 1 TB drive with the intention making a "byte perfect"
>> of of the defective drive to a new 300 GB drive at a later time to
>> then attempt "data rescue". Partitions other than the first are
>> evidently readable.
>> 
>> Suggestions/comments please.
>
>You are better off using GNU ddrescue for taking images of
>possibly-failing devices.

Full ACK: GNU ddrescue has saved my data multiple times in the past, I can 
really recommend it. (The "log file" is very helpful with resuming at a later 
point in time if you had to cancel it.)

Just don't confuse it with dd_rescue, which I don't recommend unless you are an 
expert and have a very special case.

Regards,
Christian

Re: dd - proper use or more suitable program

[Andy Smith]

Hi Richard,

On Fri, Nov 11, 2016 at 10:49:37AM -0600, Richard Owlett wrote:
> I was considering using dd to copy the entire drive to a *SINGLE*
> partition of a 1 TB drive with the intention making a "byte perfect"
> of of the defective drive to a new 300 GB drive at a later time to
> then attempt "data rescue". Partitions other than the first are
> evidently readable.
> 
> Suggestions/comments please.

You are better off using GNU ddrescue for taking images of
possibly-failing devices.

Amongst other issues, dd will either give up or produce zeroes when
it encounters problems whereas ddrescue will keep track of where it
was unable to read and keep trying.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting