Allegedly, on or about 26 January 2019, Patrick O'Callaghan sent:
> Since magnetic domains have hysteresis, suitable equipment can
> recover the previous state at a physical level. That's why proper
> trashing takes several passes.
Some drives are supposed have a built in secure erase function. I
On 1/26/19 5:29 PM, Wolfgang Pfeiffer wrote:
I think, yes: simply encrypting the whole disk should do it: IIRC this
should be *a lot* faster than piping /dev/urandom to a disk, or even
using shred:
Encrypting the whole disk involves writing the same amount of data, so
it can't be faster.
Ex
On 1/26/19 2:45 PM, Jonathan Ryshpan wrote:
They both do it at about the same speed, about 40Mbytes/sec., which is
probably about the max transfer rate to the drive. Another instance of
shred
$ shred -v -n1 /dev/sdb
applied to an internal drive (which I also plan to dispose of) ran at
least t
On Fri, Jan 25, 2019 at 06:45:25PM -0800, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away.
So far it has taken 8 hours to shred 50% of the drive, which implies
that it will take about 16 hours to shred the whole drive. I have
another 2 drives to go.
I
This is an updated Fedora29 workstation and I think I've installed
thetwo required exfat app's via dnf.
I would like to list the contents of a Western Digital MyBook external
drive that uses "exfat." Apparently it feels abused by the user when
unmounted.
[root@Box83 bobg]# mount -t exfat
On 1/25/19 3:14 PM, Jon LaBadie wrote:
When selection a multi-line URI in a terminal window
I've noticed two behaviors. Some will ?ignore? the
extra lines and only select to the end of the first
line. Others will select the entire URI, typically
to an ending ">". Obviously I would prefer the l
On Sat, 2019-01-26 at 20:26 +0800, Ed Greshko wrote:
> On 1/26/19 7:55 PM, Patrick O'Callaghan wrote:
> > The plot thickens. First of all, my snippet from wireshark was of
> > course wrong as I was monitoring virbr0 instead of vnet0. Silly me.
> >
> > Secondly, after a reboot to make sure everythi
On Sat, 2019-01-26 at 11:09 -0800, Samuel Sieb wrote:
> On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > I'm using shred on some 2Tb USB disk drive that I plan to give away. So
> > far it has taken 8 hours to shred 50% of the drive, which implies that
> > it will take about 16 hours to shred the w
Allegedly, on or about 26 January 2019, sixpack13 sent:
> maybe "hdparm security erase" is an option (don't know if disk
> content is afterwards still recoverable)
Of course you could leave a drive filled with non-private files, just
to lead them down the garden path. ;-)
--
[tim@localhost ~]
On Sat, 2019-01-26 at 20:01 +, Jonathan Dieter wrote:
> On Fri, 2019-01-25 at 20:24 -0800, Gordon Messmer wrote:
> > On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > > Is there a quicker way to protect my data when I give the drives away,
> > > other than smashing the drives to bits?
> >
> > T
On Sat, 26 Jan 2019 12:42:31 -0700
stan wrote:
> If you are up to it, you could try building a custom kernel to see if
> that would fix the issue.
> https://fedoraproject.org/wiki/Building_a_custom_kernel
> https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM
A further thought. Be
On Fri, 2019-01-25 at 20:24 -0800, Gordon Messmer wrote:
> On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
> > Is there a quicker way to protect my data when I give the drives away,
> > other than smashing the drives to bits?
>
> The quickest would be to encrypt the drives from the beginning. When yo
maybe "hdparm security erase" is an option (don't know if disk content is
afterwards still recoverable)
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
It works with spinning drives too.
At least bother of my Samsung drives are supported. (time: 500 GB 112 min)
I'm not quit sure, but I m
On Thu, 24 Jan 2019 23:33:29 -0500
Nate Pearlstein wrote:
> List ate my reply, it was too long included entire console output
>
> Ok, broke out the old Keyspan:
>
>
> This is on 4.20.3-200.fc29.x86_64
So, still failing with the new kernel, though the line number in the
error has changed, ind
On 01/26/2019 12:04 PM, Samuel Sieb wrote:
Sure, but do you expect someone to find your hard drive and put that
much money and effort into extracting your data? For most people, it's
just that you don't want some random person finding your hard drive in a
second hand store and checking out y
On Sat, 2019-01-26 at 11:04 -0800, Samuel Sieb wrote:
> On 1/26/19 2:47 AM, Patrick O'Callaghan wrote:
> > On Fri, 2019-01-25 at 22:43 -0800, ToddAndMargo via users wrote:
> > > On 1/25/19 9:38 PM, fred roller wrote:
> > > > You can wipe your drive with:
> > > >
> > > > dd if=/dev/zero of=/dev/[de
On 1/25/19 6:45 PM, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away. So
far it has taken 8 hours to shred 50% of the drive, which implies that
it will take about 16 hours to shred the whole drive. I have another 2
drives to go.
Is there a quicker wa
On 1/26/19 9:50 AM, Beartooth wrote:
On Fri, 25 Jan 2019 18:45:25 -0800, Jonathan Ryshpan wrote:
I'm using shred on some 2Tb USB disk drive that I plan to give away.
So far it has taken 8 hours to shred 50% of the drive, which implies
that it will take about 16 hours to shred the whole drive.
On 1/26/19 2:47 AM, Patrick O'Callaghan wrote:
On Fri, 2019-01-25 at 22:43 -0800, ToddAndMargo via users wrote:
On 1/25/19 9:38 PM, fred roller wrote:
You can wipe your drive with:
dd if=/dev/zero of=/dev/[device to be wiped]
/dev/zero is the fastest I have found.
All that does is set ever
On Sat, Jan 26, 2019 at 05:50:20PM -, Beartooth wrote:
> On Fri, 25 Jan 2019 18:45:25 -0800, Jonathan Ryshpan wrote:
>
> > I'm using shred on some 2Tb USB disk drive that I plan to give away.
> > So far it has taken 8 hours to shred 50% of the drive, which implies
> > that it will take about 1
On Fri, 25 Jan 2019 18:45:25 -0800, Jonathan Ryshpan wrote:
> I'm using shred on some 2Tb USB disk drive that I plan to give away.
> So far it has taken 8 hours to shred 50% of the drive, which implies
> that it will take about 16 hours to shred the whole drive. I have
> another 2 drives to go.
>
On 1/26/19 7:55 PM, Patrick O'Callaghan wrote:
> The plot thickens. First of all, my snippet from wireshark was of
> course wrong as I was monitoring virbr0 instead of vnet0. Silly me.
>
> Secondly, after a reboot to make sure everything was in default state,
> I fired up the Fedora guest alone, an
On Sat, 2019-01-26 at 07:18 +0800, Ed Greshko wrote:
> > I tried reloading firewalld and got the same result. I fired up the
> > firewall applet and suddenly the guests had network access, even though
> > I didn't change anything. I quit the applet and boom, the guests lost
> > network access again
On Fri, 2019-01-25 at 22:43 -0800, ToddAndMargo via users wrote:
> On 1/25/19 9:38 PM, fred roller wrote:
> > You can wipe your drive with:
> >
> > dd if=/dev/zero of=/dev/[device to be wiped]
>
> /dev/zero is the fastest I have found.
All that does is set every bit to 0. Since magnetic domains
adding
status=progress
to the dd command i believe will let you know how long it has so you can
keep an eye on it in the terminal.
On Fri, Jan 25, 2019 at 11:32 PM Samuel Sieb wrote:
> On 1/25/19 10:58 PM, Jonathan Ryshpan wrote:
> > I'll give dd a try; but I don't see offhand why
> > dd if
25 matches
Mail list logo
