On 9/9/19 7:20 PM, Tim via users wrote:
On Wed, 2019-09-04 at 23:58 -0700, ToddAndMargo via users wrote:
If Windows read Ext4, I'd convert all my flash drives over to it.
Apparently it can be done.
Indeed. And the results are tragic. Here are my notes on it:
Paragon EXTFS for Windows:
On Wed, 2019-09-04 at 23:58 -0700, ToddAndMargo via users wrote:
> If Windows read Ext4, I'd convert all my flash drives over to it.
Apparently it can be done.
--
uname -rsvp
Linux 3.10.0-957.27.2.el7.x86_64 #1 SMP Mon Jul 29 17:46:05 UTC 2019 x86_64
Boilerplate: All unexpected mail to my m
On 9/6/19 9:43 PM, ToddAndMargo via users wrote:
On 9/6/19 9:36 PM, Cameron Simpson wrote:
On 06Sep2019 20:16, ToddAndMargo wrote:
On 9/6/19 7:45 PM, Cameron Simpson wrote:
# dd status=progress bs=4096 if=/dev/sdb | gzip >
DeadStick.FC30.2019-09-06
34489798656 bytes (34 GB, 32 GiB) copied, 4
On 9/6/19 9:36 PM, Cameron Simpson wrote:
On 06Sep2019 20:16, ToddAndMargo wrote:
On 9/6/19 7:45 PM, Cameron Simpson wrote:
# dd status=progress bs=4096 if=/dev/sdb | gzip >
DeadStick.FC30.2019-09-06
34489798656 bytes (34 GB, 32 GiB) copied, 404 s, 85.4 MB/s
dd: error reading '/dev/sdb': Inpu
On 06Sep2019 20:16, ToddAndMargo wrote:
On 9/6/19 7:45 PM, Cameron Simpson wrote:
# dd status=progress bs=4096 if=/dev/sdb | gzip >
DeadStick.FC30.2019-09-06
34489798656 bytes (34 GB, 32 GiB) copied, 404 s, 85.4 MB/s
dd: error reading '/dev/sdb': Input/output error
8425692+0 records in
8425692
On 9/5/19 3:44 AM, Samuel Sieb wrote:
However, the other suggestion to pipe straight
through gzip (or other compression program) is better anyway.
Thank you!
Backup:
1) shutdown: zero out unused space
Figure out which partitions / and /boot are loated on. Gparted
work
On 9/6/19 7:45 PM, Cameron Simpson wrote:
On 06Sep2019 19:34, ToddAndMargo wrote:
I am going to test the straight pipe today on my USB3 ports
and see if the overhead slows down the dd enough to stop
crashing dd. [...]
"crashing" ?
[...]
Ahh poop! (Not my "exact" word.)
# dd status=progres
On 06Sep2019 19:34, ToddAndMargo wrote:
I am going to test the straight pipe today on my USB3 ports
and see if the overhead slows down the dd enough to stop
crashing dd. [...]
"crashing" ?
[...]
Ahh poop! (Not my "exact" word.)
# dd status=progress bs=4096 if=/dev/sdb | gzip > DeadStick.FC
On 9/6/19 3:21 PM, ToddAndMargo via users wrote:
On 9/5/19 3:44 AM, Samuel Sieb wrote:
On 9/4/19 10:55 PM, ToddAndMargo via users wrote:
# gzip DeadStick.[date] # creates DeadStick.[date].gz
# rm DeadStick.[date]
The rm will fail because gzip removes the original file whe
On 9/5/19 3:44 AM, Samuel Sieb wrote:
On 9/4/19 10:55 PM, ToddAndMargo via users wrote:
# gzip DeadStick.[date] # creates DeadStick.[date].gz
# rm DeadStick.[date]
The rm will fail because gzip removes the original file when it's
finished compressing. However, the other
On 9/4/19 10:55 PM, ToddAndMargo via users wrote:
# gzip DeadStick.[date] # creates DeadStick.[date].gz
# rm DeadStick.[date]
The rm will fail because gzip removes the original file when it's
finished compressing. However, the other suggestion to pipe straight
through gz
On 9/4/19 11:24 PM, francis.montag...@inria.fr wrote:
Hi.
On Wed, 04 Sep 2019 22:55:56 -0700 ToddAndMargo via users wrote:
This is what I finally wound up doing to back up this stick.
Dead Stick is a play on words off of Live USB:
Backup:
1) shutdown: zero out unused space
...
Hi.
On Wed, 04 Sep 2019 22:55:56 -0700 ToddAndMargo via users wrote:
> This is what I finally wound up doing to back up this stick.
> Dead Stick is a play on words off of Live USB:
> Backup:
> 1) shutdown: zero out unused space
...
> # zerofree -v /dev/sd..
Beware that zerofree
On 9/3/19 10:03 PM, ToddAndMargo via users wrote:
Hi All,
I have a flash drive with about four partitions on is.
Lets call it /dev/sdc.
Can I tar sdc or am I stuck with tarring the partitions?
Any drawback to this?
Many thanks,
-T
Followup.
This is what I finally wound up doing to back
On 9/3/19 11:32 PM, Eyal Lebedinsky wrote:
dd if=/dev/zero of=/path/to/mountPoint/zero
rm /path/to/mountPoint/zero
Oh, I finally understand! I was thinking /mnt/flash/big-file-o-zeros
was on the local drive, not the flash drive. Duh!
Thank you!
On Wed, 2019-09-04 at 12:44 -0700, Gordon Messmer wrote:
> On 9/4/19 8:20 AM, Patrick O'Callaghan wrote:
> > For a USB drive it probably doesn't make much difference. Output will
> > be buffered and speed is limited by the USB interface.
>
> If you aren't specifying a block size, the default block
On 9/4/19 1:48 PM, Ted Roche wrote:
scrub, in the Fedora repos, has a fillzero option and a freespace
specifier that should do the trick. MAKE A BACKUP FIRST, as scrub's
primary job is to erase any trace of everything on a device, so you'd
hate to get the options wrong!
Thank you!
Ya, backup
scrub, in the Fedora repos, has a fillzero option and a freespace specifier
that should do the trick. MAKE A BACKUP FIRST, as scrub's primary job is to
erase any trace of everything on a device, so you'd hate to get the options
wrong!
On Wed, Sep 4, 2019 at 4:41 PM ToddAndMargo via users <
user
On 9/4/19 1:25 PM, ToddAndMargo via users wrote:
On 9/4/19 2:44 AM, Patrick O'Callaghan wrote:
The point of Eyal's method is to ensure that all the free space on the
drive is filled with zeroes, thus improving the compression. Otherwise
you are just uselessly compressing junk.
poc
Is there a
On 9/4/19 6:16 AM, Dave Ihnat wrote:
On 4 Sep at 01:12, Ed Greshko wrote:
Of course a dd copy may be rather time consuming and space consuming
with no apparent advantage.
A lot less time consuming if you use the "bs=" option. Haven't seen anyone
mention that; I believe the default is still
On 9/4/19 2:44 AM, Patrick O'Callaghan wrote:
The point of Eyal's method is to ensure that all the free space on the
drive is filled with zeroes, thus improving the compression. Otherwise
you are just uselessly compressing junk.
poc
Is there a way to tell the stick itself to zero out
all unuse
On 9/4/19 8:20 AM, Patrick O'Callaghan wrote:
For a USB drive it probably doesn't make much difference. Output will
be buffered and speed is limited by the USB interface.
If you aren't specifying a block size, the default block size tends to
involve more round-trips through the kernel and thr
On Wed, Sep 04, 2019 at 04:20:14PM +0100, Patrick O'Callaghan wrote:
> On Wed, 2019-09-04 at 21:55 +0800, Ed Greshko wrote:
> > On 9/4/19 9:16 PM, Dave Ihnat wrote:
> > > On 4 Sep at 01:12, Ed Greshko wrote:
> > > > Of course a dd copy may be rather time consuming and space consuming
> > > > with
SORRY! That message was not intended for you.
-Original Message-
From:
Sent: Wed, 04 Sep 2019 16:20:14 +0100
To: 3603060...@txt.att.net
Subject: Re: tar a flash drive
>On Wed, 2019-09-04 at 21:55 +0800, Ed Greshko wrote:
>> On 9/4/19 9:16 PM, Dave Ihnat wrote:
>>
FOLLOW @gnome
-Original Message-
From:
Sent: Wed, 04 Sep 2019 16:20:14 +0100
To: 3603060...@txt.att.net
Subject: Re: tar a flash drive
>On Wed, 2019-09-04 at 21:55 +0800, Ed Greshko wrote:
>> On 9/4/19 9:16 PM, Dave Ihnat wrote:
>> > On 4 Sep at 01:12,
On Wed, 2019-09-04 at 21:55 +0800, Ed Greshko wrote:
> On 9/4/19 9:16 PM, Dave Ihnat wrote:
> > On 4 Sep at 01:12, Ed Greshko wrote:
> > > Of course a dd copy may be rather time consuming and space consuming
> > > with no apparent advantage.
> > A lot less time consuming if you use the "bs=" opti
On 9/4/19 9:16 PM, Dave Ihnat wrote:
> On 4 Sep at 01:12, Ed Greshko wrote:
>> Of course a dd copy may be rather time consuming and space consuming
>> with no apparent advantage.
> A lot less time consuming if you use the "bs=" option. Haven't seen anyone
> mention that; I believe the default is
On 4 Sep at 01:12, Ed Greshko wrote:
> Of course a dd copy may be rather time consuming and space consuming
> with no apparent advantage.
A lot less time consuming if you use the "bs=" option. Haven't seen anyone
mention that; I believe the default is still the old Unix 512b, painful.
Cheers,
On 9/4/19 5:00 PM, ToddAndMargo via users wrote:
> On 9/3/19 11:12 PM, Ed Greshko wrote:
>> The question would then arise as to how you would extract files/data from
>> that dd created
>
> No extraction. I just want to do a mass overwrite when
> the stick gets corrupted
OK.
Pro-Tip: Spelling o
On Wed, 2019-09-04 at 01:59 -0700, ToddAndMargo via users wrote:
> On 9/3/19 11:32 PM, Eyal Lebedinsky wrote:
> > What is the purpose of this exercise?
>
>
> I have a bootable Fedora 64 GB flash drive. I use it
> to troubleshoot customers' computers -- mostly Windows.
> Windows loved to eat thes
On 9/4/19 12:06 AM, Cameron Simpson wrote:
Shrug. "cat" is easier to invoke:
cat /dev/sdBLAH >sdBLAH.img
Cheers,
Cameron Simpson
I am use to dd. Kind of like I am use to vi when
EVERY other editor it the world is easier to use.
:-)
___
users ma
On 9/3/19 11:12 PM, Ed Greshko wrote:
The question would then arise as to how you would extract files/data from that
dd created
No extraction. I just want to do a mass overwrite when
the stick gets corrupted
___
users mailing list -- users@lists.fed
On 9/3/19 11:32 PM, Eyal Lebedinsky wrote:
What is the purpose of this exercise?
I have a bootable Fedora 64 GB flash drive. I use it
to troubleshoot customers' computers -- mostly Windows.
Windows loved to eat these sticks. (I have had great
luck switching to a Samsung stick.)
I have prev
On 03Sep2019 23:12, ToddAndMargo wrote:
On 9/3/19 10:56 PM, Cameron Simpson wrote:
On 03Sep2019 22:03, ToddAndMargo wrote:
I have a flash drive with about four partitions on is.
Lets call it /dev/sdc.
Can I tar sdc or am I stuck with tarring the partitions?
Any drawback to this?
Depends w
On 04/09/2019 16.12, ToddAndMargo via users wrote:
On 9/3/19 10:59 PM, John Harris wrote:
On Tuesday, September 3, 2019 10:03:21 PM MST ToddAndMargo via users wrote:
Hi All,
I have a flash drive with about four partitions on is.
Lets call it /dev/sdc.
Can I tar sdc or am I stuck with tarring
On 9/4/19 1:59 PM, John Harris wrote:
> On Tuesday, September 3, 2019 10:03:21 PM MST ToddAndMargo via users wrote:
>> Hi All,
>>
>> I have a flash drive with about four partitions on is.
>> Lets call it /dev/sdc.
>>
>> Can I tar sdc or am I stuck with tarring the partitions?
>>
>> Any drawback to
On 9/3/19 10:56 PM, Cameron Simpson wrote:
On 03Sep2019 22:03, ToddAndMargo wrote:
I have a flash drive with about four partitions on is.
Lets call it /dev/sdc.
Can I tar sdc or am I stuck with tarring the partitions?
Any drawback to this?
Depends what you want from it. If the partitions ha
On 9/3/19 10:59 PM, John Harris wrote:
On Tuesday, September 3, 2019 10:03:21 PM MST ToddAndMargo via users wrote:
Hi All,
I have a flash drive with about four partitions on is.
Lets call it /dev/sdc.
Can I tar sdc or am I stuck with tarring the partitions?
Any drawback to this?
If you were
On Tuesday, September 3, 2019 10:03:21 PM MST ToddAndMargo via users wrote:
> Hi All,
>
> I have a flash drive with about four partitions on is.
> Lets call it /dev/sdc.
>
> Can I tar sdc or am I stuck with tarring the partitions?
>
> Any drawback to this?
If you were to `tar` it, you'd be maki
On 03Sep2019 22:03, ToddAndMargo wrote:
I have a flash drive with about four partitions on is.
Lets call it /dev/sdc.
Can I tar sdc or am I stuck with tarring the partitions?
Any drawback to this?
Depends what you want from it. If the partitions have real filesystems
in them then mount them
Hi All,
I have a flash drive with about four partitions on is.
Lets call it /dev/sdc.
Can I tar sdc or am I stuck with tarring the partitions?
Any drawback to this?
Many thanks,
-T
--
~
When we ask for advice, we are usually loo
41 matches
Mail list logo
