Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178510 > unrolled thread

Some help with dd backing up into an iso

Back to article view | Back to linux.debian.user

Contents

  Some help with dd backing up into an iso GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-03-07 01:20 +0100
    Re: Some help with dd backing up into an iso Michael Lange <klappnase@freenet.de> - 2017-03-07 02:10 +0100
    Re: Some help with dd backing up into an iso David Christensen <dpchrist@holgerdanske.com> - 2017-03-07 06:10 +0100
      Re: Some help with dd backing up into an iso David Christensen <dpchrist@holgerdanske.com> - 2017-03-07 07:00 +0100
        Re: Some help with dd backing up into an iso "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-07 09:00 +0100
          Re: Some help with dd backing up into an iso GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-03-07 18:30 +0100
            Re: Some help with dd backing up into an iso "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-07 20:20 +0100
              Re: Some help with dd backing up into an iso GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-03-08 05:00 +0100
                Re: Some help with dd backing up into an iso David Christensen <dpchrist@holgerdanske.com> - 2017-03-08 07:00 +0100
                Re: Some help with dd backing up into an iso "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-08 12:10 +0100
                  MBR partitioning, and content after partition table but before first  partition David Christensen <dpchrist@holgerdanske.com> - 2017-03-09 06:50 +0100
                    Re: MBR partitioning, and content after partition table but before  first partition Felix Miata <mrmazda@earthlink.net> - 2017-03-09 08:00 +0100
                      Re: MBR partitioning, and content after partition table but before  first partition David Christensen <dpchrist@holgerdanske.com> - 2017-03-10 06:10 +0100
                        Re: MBR partitioning, and content after partition table but before  first partition Jonathan Dowland <jmtd@debian.org> - 2017-03-10 10:00 +0100
                          Re: MBR partitioning, and content after partition table but before  first partition David Christensen <dpchrist@holgerdanske.com> - 2017-03-11 07:10 +0100
                            Re: MBR partitioning, and content after partition table but before  first partition Jonathan Dowland <jmtd@debian.org> - 2017-03-13 10:10 +0100
                              Re: MBR partitioning, and content after partition table but before  first partition David Christensen <dpchrist@holgerdanske.com> - 2017-03-14 04:40 +0100
                                Re: MBR partitioning, and content after partition table but before  first partition David <bouncingcats@gmail.com> - 2017-03-14 11:40 +0100
                                  Re: MBR partitioning, and content after partition table but before  first partition David Christensen <dpchrist@holgerdanske.com> - 2017-03-15 03:50 +0100
                                Re: MBR partitioning, and content after partition table but before  first partition The Wanderer <wanderer@fastmail.fm> - 2017-03-14 13:00 +0100
                                  Re: MBR partitioning, and content after partition table but before  first partition David Christensen <dpchrist@holgerdanske.com> - 2017-03-15 04:10 +0100
                                Re: MBR partitioning, and content after partition table but before  first partition Andy Smith <andy@strugglers.net> - 2017-03-15 04:40 +0100
                                Re: MBR partitioning, and content after partition table but before  first partition Jonathan Dowland <jmtd@debian.org> - 2017-03-15 13:00 +0100
                    Re: MBR partitioning, and content after partition table but before first partition "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-09 08:30 +0100
                    Re: MBR partitioning, and content after partition table but before  first partition Jonathan Dowland <jmtd@debian.org> - 2017-03-09 15:40 +0100
      Re: Some help with dd backing up into an iso Teemu Likonen <tlikonen@iki.fi> - 2017-03-07 09:30 +0100
        Re: Some help with dd backing up into an iso <tomas@tuxteam.de> - 2017-03-07 09:40 +0100
          Re: Some help with dd backing up into an iso Teemu Likonen <tlikonen@iki.fi> - 2017-03-07 10:00 +0100
            Re: Some help with dd backing up into an iso <tomas@tuxteam.de> - 2017-03-07 10:10 +0100
            Re: Some help with dd backing up into an iso David Wright <deblis@lionunicorn.co.uk> - 2017-03-07 16:20 +0100
        Re: Some help with dd backing up into an iso Jonathan Dowland <jmtd@debian.org> - 2017-03-07 11:10 +0100
        Re: Some help with dd backing up into an iso David Christensen <dpchrist@holgerdanske.com> - 2017-03-08 06:00 +0100
    Re: Some help with dd backing up into an iso Mark Fletcher <mark27q1@gmail.com> - 2017-03-07 12:10 +0100
    Re: Some help with dd backing up into an iso Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2017-03-07 14:50 +0100
    Re: Some help with dd backing up into an iso Elimar Riesebieter <riesebie@lxtec.de> - 2017-03-07 15:20 +0100
    Re: Some help with dd backing up into an iso David Wright <deblis@lionunicorn.co.uk> - 2017-03-07 16:20 +0100
      Re: Some help with dd backing up into an iso "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-07 18:10 +0100
        Re: Some help with dd backing up into an iso David Wright <deblis@lionunicorn.co.uk> - 2017-03-07 19:00 +0100
          Re: Some help with dd backing up into an iso "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-07 20:30 +0100
            Re: Some help with dd backing up into an iso David Wright <deblis@lionunicorn.co.uk> - 2017-03-07 21:30 +0100
              Re: Some help with dd backing up into an iso "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-07 22:10 +0100
                Re: Some help with dd backing up into an iso GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-03-08 18:30 +0100
                  Re: Some help with dd backing up into an iso David Wright <deblis@lionunicorn.co.uk> - 2017-03-08 19:20 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#178851 — Re: MBR partitioning, and content after partition table but before first partition

On 03/14/2017 04:52 AM, The Wanderer wrote:
> On 2017-03-13 at 23:36, David Christensen wrote:
>
>> Is anyone aware of a utility that can walk a file system and replace
>>  identical files with hard links?
>
> Try rdfind. It's in Debian; I don't use it myself, largely because the
> (accepted upstream years ago) feature request for a "-minsize" option
> (to replace or extend the "-ignoreempty" option) which I need for my use
> case has not apparently been implemented yet - but finding duplicate
> files is exactly what it's meant for, and one of its available "actions"
> is to replace the duplicate files with hardlinks.

rdfind looks like just what I wanted.  Thanks for the tip.  :-)


David

[toc] | [prev] | [next] | [standalone]

#178852 — Re: MBR partitioning, and content after partition table but before first partition

Hello,

On Mon, Mar 13, 2017 at 08:36:59PM -0700, David Christensen wrote:
> Is anyone aware of a utility that can walk a file system and replace
> identical files with hard links?

As an alternative to doing this, you could consider using a
filesystem with block-level de-duplication support.

ZFS and btrfs can do this online, though that uses a very large
amount of memory. btrfs and recently XFS can do it offline, which
means that you trigger it at a time of your choosing.

Support in XFS only arrived in kernel version 4.9.1, and is still
marked as experimental. The kernel in jessie-backports right now is
new enough. I did a write up a while ago about experimenting with
this in XFS:

    http://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/

Cheers,
Andy

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

[toc] | [prev] | [next] | [standalone]

#178858 — Re: MBR partitioning, and content after partition table but before first partition

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 13, 2017 at 08:36:59PM -0700, David Christensen wrote:
> >and the destination ended up bigger,
> >possibly because one or more of the backups on the source had been using some
> >kind of hardlink de-dupe (I've ranted about hardlink trees being a problem in
> >various backup topics on -user, too...) and I didn't think to supply -S to
> >rsync.
> 
> -S is for sparse files.

Sorry, you are right. I did not use -S nor -H, so sparse files would be expanded,
and hard links re-referenced in my copy. I'm not sure which (or both) were a
problem in my case.


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#178596 — Re: MBR partitioning, and content after partition table but before first partition

Hi,

David Christensen wrote:
> Examining a Windows XP disk, the first partition (C:\) starts at block 63
> (track 1):
> [...]
> Number  Start  End         Size        Type     File system  Flags
>  1      63s    156296384s  156296322s  primary  ntfs         boot

That's an oldfashioned layout. Bad for disks with blocksize larger than
512 bytes, because of the odd block count.


> 000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa

This is the end of the MBR. The first partition slot is at address
000001be.


> 00007c00  12 91 f2 60 90 a0 2f 19  01 00 00 00 85 00 67 68 |...`../.......gh|
> 00007c10  46 44 23 cc 22 52 1d ac  22 52 32 4e 6f 72 74 6f |FD#."R.."R2Norto|
> 00007c20  6e 20 47 68 6f 73 74 20  32 30 30 33 00 00 00 00 |n Ghost 2003....|

That's in the last block before partition 1 begins.
No idea whether it is trash or whether Norton Ghost dumped a tag there.
(In this case it belongs to GiaThnYgeia's list of occasions which change
the unclaimed disk area.)


> Examining a Jesse system drive, the first partition starts at block 2048 (1
> MB = 2**20 bytes):

That's the modern layout. I wonder how long it will last until 1 MiB are
considered too small.


> 0000c990  b0 b3 2c fa a4 38 f1 f8  77 f0 2d dd c2 4a a4 a9 |..,..8..w.-..J..|
> What is in blocks 1-101?

Could be GRUB program code. Do you see cleartext messages in the first
100 blocks ?

With
  dd if=/dev/sda bs=512 count=100 | strings | less
i get from my system disk
  ZRr=
  `|f     
  \|f1
  GRUB 
  Geom
  Hard Disk
  Read
  Error
  loading
  Geom
and much more text salad.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#178618 — Re: MBR partitioning, and content after partition table but before first partition

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 08, 2017 at 09:46:32PM -0800, David Christensen wrote:
> What is in blocks 1-101?

I believe it's part of grub. My limited understanding of how it works is
it's split up into separate stages designed to fit within the "holes" in
a typical MBR layout, each stage having enough code to initialise some
stuff and then jump to the next stage.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#178523

[Multipart message — attachments visible in raw view] — view raw

David Christensen [2017-03-06 21:05:31-08] wrote:

>     # dd if=/dev/sda | gzip > myimage.img

What's the point of using dd?

    gzip </dev/sda >myimage.img

I don't know about you but many people seem to think that dd is some
kind of special tool for reading and writing block device files. But
after all the devices are just files that can be read with normal
commands like cat or cp. These are even faster normally because they use
larger buffers. Write operations on device files should be finished with
sync command to flush the buffers.

To copy a device file:

    cat /dev/foo >image.img

To write to a device:

    cp image.img /dev/foo
    sync

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#178524

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Mar 07, 2017 at 10:26:25AM +0200, Teemu Likonen wrote:
> David Christensen [2017-03-06 21:05:31-08] wrote:
> 
> >     # dd if=/dev/sda | gzip > myimage.img
> 
> What's the point of using dd?
> 
>     gzip </dev/sda >myimage.img
> 
> I don't know about you but many people seem to think that dd is some
> kind of special tool [...]

> To copy a device file:
> 
>     cat /dev/foo >image.img
> 
> To write to a device:
> 
>     cp image.img /dev/foo
>     sync

Yep. That's when you want to copy all the source, whereas dd comes in
handy whin you know how much to copy. So this idiom makes sense

  dd if=/dev/zero of=lotsofnull bs=1024 count=1024 # copy 1M of zeros

whereas (kids, *don't try this at home)

  cp /dev/zero of=lotsofnull # try to fill up your hard disk

ain't what you're usually looking for ;-P

But yes dd is a dinosaur from olden times where block sizes were a
thing (although I have seen slight speed differences by varying bs
on a fairly modern system, but that might have been some voodoo).

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

iEYEARECAAYFAli+cLoACgkQBcgs9XrR2kZkTwCeI39NI4d06CtufHonaI2u4Ekd
XDEAn2QKG+3SAspnF92iNbMpUNwFifUJ
=elCY
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178525

[Multipart message — attachments visible in raw view] — view raw

tomas@tuxteam.de [2017-03-07 09:35:06+01] wrote:

> dd comes in handy whin you know how much to copy. So this idiom makes
> sense
>
>   dd if=/dev/zero of=lotsofnull bs=1024 count=1024 # copy 1M of zeros

That particular thing can be made faster without transferring any data:

    $ dd obs=1M count=0 seek=1 of=file
    0+0 records in
    0+0 records out
    0 bytes (0 B) copied, 1,1289e-05 s, 0,0 kB/s

    $ ls -lh file
    -rw-r--r-- 1 dtw dtw 1,0M 2017-03-07 10:52:14 file

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#178526

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Mar 07, 2017 at 10:55:01AM +0200, Teemu Likonen wrote:
> tomas@tuxteam.de [2017-03-07 09:35:06+01] wrote:
> 
> > dd comes in handy whin you know how much to copy. So this idiom makes
> > sense
> >
> >   dd if=/dev/zero of=lotsofnull bs=1024 count=1024 # copy 1M of zeros
> 
> That particular thing can be made faster without transferring any data:
> 
>     $ dd obs=1M count=0 seek=1 of=file
>     0+0 records in
>     0+0 records out
>     0 bytes (0 B) copied, 1,1289e-05 s, 0,0 kB/s
> 
>     $ ls -lh file
>     -rw-r--r-- 1 dtw dtw 1,0M 2017-03-07 10:52:14 file

Provided you want holes in it.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAli+doIACgkQBcgs9XrR2kZsVwCeONbK4j0nQ8NSfjsuR35nDfdt
GPQAniS6O9XP51LjWgAo3lggqBK40T1r
=DxLy
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178538

On Tue 07 Mar 2017 at 10:55:01 (+0200), Teemu Likonen wrote:
> tomas@tuxteam.de [2017-03-07 09:35:06+01] wrote:
> 
> > dd comes in handy whin you know how much to copy. So this idiom makes
> > sense
> >
> >   dd if=/dev/zero of=lotsofnull bs=1024 count=1024 # copy 1M of zeros
> 
> That particular thing can be made faster without transferring any data:
> 
>     $ dd obs=1M count=0 seek=1 of=file
>     0+0 records in
>     0+0 records out
>     0 bytes (0 B) copied, 1,1289e-05 s, 0,0 kB/s
> 
>     $ ls -lh file
>     -rw-r--r-- 1 dtw dtw 1,0M 2017-03-07 10:52:14 file

In which case, why did you write:

"I don't know about you but many people seem to think that dd is some
kind of special tool for reading and writing block device files. But
after all the devices are just files that can be read with normal
commands like cat or cp."

Those clunky parameters you've used explain one of the reasons
for its being special. Here's another: the OP could have ascertained
how long the (reckless) second copy was going to take by typing
kill -USR1 <pid-of-dd>   to see how much had been copied so far.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#178528

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 07, 2017 at 10:26:25AM +0200, Teemu Likonen wrote:
> What's the point of using dd?
> 
>     gzip </dev/sda >myimage.img
> 
> I don't know about you but many people seem to think that dd is some
> kind of special tool for reading and writing block device files. But
> after all the devices are just files that can be read with normal
> commands like cat or cp. These are even faster normally because they use
> larger buffers. Write operations on device files should be finished with
> sync command to flush the buffers.

You're right, but I would advocate people use gddrescue instead, rather
than cp etc., since (unlike cp, cat, dd, etc.) gddrescue is very careful
about which blocks it has read, can do retries, keeps a log file, can be
interrupted and resumed safely, and can recover data from failing devices.


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#178562

On 03/07/2017 12:26 AM, Teemu Likonen wrote:
> David Christensen [2017-03-06 21:05:31-08] wrote:
>
>>     # dd if=/dev/sda | gzip > myimage.img
>
> What's the point of using dd?
>
>     gzip </dev/sda >myimage.img

Habit -- I use 16 GB SSD or USB flash drives for my system drives, with 
10% under-provisioning.  'dd' allows me to grab just the blocks I need 
(via the 'count' option).  I also find it reassuring that 'dd' tells me 
how many blocks it copied.


David

[toc] | [prev] | [next] | [standalone]

#178529

On Tue, Mar 07, 2017 at 12:11:00AM +0000, GiaThnYgeia wrote:
> I am not very confident I am doing this right and it seems wrong,  I
> can't locate any documentation that results into proper options.
> I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
> of data on it.
> I used dd if=/dev/sdb of=usbfilename.iso
> The resulting image was the full size of the disk.
> To test the validity I restored reversing the order of the filenames
> if/of  but that took for ever and it was a hog on resources.  After a
> while I just gave up and killed the process.  I looked at the disk and
> it seemed complete with all files in tact, so maybe I killed it
> somewhere in the verification process.
> So I used a program called etcher which I have used with 100% success in
> the past and was surprisingly fast in burning images.
> It took for ever as well, eventually it run a verification routine and
> it was done.
> Is there someway one can avoid creating such a large iso for no reason,
> when the filesize is a fraction of the whole disk.  One way I thought of
> was to shrink the partitions to just about 99% full, and leave the blank
> part of the disk as not allocated.  Would that help?
> Is there some fancy command line that does just that?
> 

Most of the replies seem to have assumed you didn't really want to back 
up to an ISO file system, eg to write to a CD, DVD or Blu Ray. Just in 
case that's wrong and you actually did, you'll want the growisofs 
command line tool or the brasero GUI tool.

growisofs is in a package of the same name, as is brasero.

growisofs can definitely let you choose whether to just generate the 
.iso file, or to also burn it to a disc. brasero also can I THINK, 
certainly it can burn CDs / DVDs.

In both cases the .ISO that is generated will be big enough to 
accommodate the data actually on the source disk (or SSD or USB or 
whatever) and no bigger.

Mark

[toc] | [prev] | [next] | [standalone]

#178532

On Seg, 06 Mar 2017, GiaThnYgeia wrote:
> Is there someway one can avoid creating such a large iso for no reason,
> when the filesize is a fraction of the whole disk.  One way I thought of
> was to shrink the partitions to just about 99% full, and leave the blank
> part of the disk as not allocated.  Would that help?

It is possible, but on a filesystem level.

You can copy the contents with rsync.

Or take a look at partclone, which is meant to create images of  
partitions, if you don't want to deal with individual files.

clonezilla is a front-end to several tools (including partclone) to  
backup and restore drives or partitions.

-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

[toc] | [prev] | [next] | [standalone]

#178534

* GiaThnYgeia <GiaThnYgeia@openmailbox.org> [2017-03-07 00:11 +0000]:

> I am not very confident I am doing this right and it seems wrong,  I
> can't locate any documentation that results into proper options.
> I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
> of data on it.
> I used dd if=/dev/sdb of=usbfilename.iso
> The resulting image was the full size of the disk.

/dev/sdX is always the whole device. If you want the two partitions
sepearated you have to choose /dev/sdXA, which in your case should
be /dev/sdb1 and /dev/sdb2 I assume.

Elimar
-- 
  On the keyboard of life you have always
  to keep a finger at the escape key;-)

[toc] | [prev] | [next] | [standalone]

#178537

On Tue 07 Mar 2017 at 00:11:00 (+0000), GiaThnYgeia wrote:
> I am not very confident I am doing this right and it seems wrong,  I
> can't locate any documentation that results into proper options.
> I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
> of data on it.
> I used dd if=/dev/sdb of=usbfilename.iso
> The resulting image was the full size of the disk.

…and various people have commented on what that actually does,
and better methods of achieving it.

> To test the validity I restored reversing the order of the filenames
> if/of  but that took for ever and it was a hog on resources.  After a
> while I just gave up and killed the process.  I looked at the disk and
> it seemed complete with all files in tact, so maybe I killed it
> somewhere in the verification process.

But only Thomas has mentioned what might be expected as the result of
this action, and no one has pointed out the recklessness of the
action in the first place.

Making a backup and then immediately copying it back over the top of
the original is an obvious recipe for data-loss. And how would this
second operation test the validity? What's the criterion for pass/fail?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#178547

Hi,

tomás wrote:
> But yes dd is a dinosaur from olden times where block sizes were a
> thing

It is also about EBCDIC and byte sex. Last century's topics.
Love, 36 bit, and punched cards.


David Wright wrote:
> no one has pointed out the recklessness of the
> action in the first place.
> Making a backup and then immediately copying it back over the top of
> the original is an obvious recipe for data-loss.

It has its use cases. E.g. before you put a Debian installation ISO
onto an USB stick, it can be used to backup the old stick content and
will also show by hardware blinking that you got the right device path.

Of course one should not do this with valuable data unless one knows
that those data got spoiled between backup and restore.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#178550

On Tue 07 Mar 2017 at 18:05:48 (+0100), Thomas Schmitt wrote:
> David Wright wrote:
> > no one has pointed out the recklessness of the
> > action in the first place.
> > Making a backup and then immediately copying it back over the top of
> > the original is an obvious recipe for data-loss.
> 
> It has its use cases. E.g. before you put a Debian installation ISO
> onto an USB stick, it can be used to backup the old stick content and
> will also show by hardware blinking that you got the right device path.

The stick blinks when you back it up. That confirms the device path.
Why would you now copy the old stick content onto the stick again?
That's what the OP wrote that they did, in order to "test the validity".
At this point, my reaction would be to cross my fingers for no power
failures¹. The OP's was to interrupt it!

¹We had two glitches yesterday evening as the tornadoes went by.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#178553

Hi,

i wrote:
> > It has its use cases. E.g. before you put a Debian installation ISO
> > onto an USB stick, it can be used to backup the old stick content

David Wright wrote:
> Why would you now copy the old stick content onto the stick again?

When you no longer need the installation ISO because the installation
is done, wouldn't it be nice to get the DOS formatted USB stick back
for carrying files between computers ?

A plain dd copy of the stick provides boot sector, partitioning,
filesystem, and data file content in one sweep. No fdisk, no mkfs,
no grub-install, no restoring of a backup archive needed.


> That's what the OP wrote that they did, in order to "test the validity".

Since she or he knows punching cards, i assume that there is knowledge
of Murphy's Law, too.


> ¹We had two glitches yesterday evening as the tornadoes went by.

I have a UPS between power provider and computer. Murphy's law ...


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#178554

On Tue 07 Mar 2017 at 20:25:30 (+0100), Thomas Schmitt wrote:
> Hi,
> 
> i wrote:
> > > It has its use cases. E.g. before you put a Debian installation ISO
> > > onto an USB stick, it can be used to backup the old stick content
> 
> David Wright wrote:
> > Why would you now copy the old stick content onto the stick again?
> 
> When you no longer need the installation ISO because the installation
> is done, wouldn't it be nice to get the DOS formatted USB stick back
> for carrying files between computers ?

Forgive me for asking, but have you read the OP?

The OP said they had a USB stick containing 1.7GB of data on it.
They copied the stick to a file, usbfilename.iso, with dd.
They then copied usbfilename.iso back onto the stick in order to
"test the validity" by running dd with if=/of= reversed.

There was no indication whether the stick contained a bunch of jessie
.deb files or a copy of their doctoral thesis. Either way, I can't see
the sense of backing up a filesystem to an image file and then, for
the sake of it, using the image file to overwrite the original filesystem.

And, assuming the process was left to completion (which it wasn't),
what validity would have been tested? What would constitute a pass,
and what would distinguish a fail?

There was no indication that the stick had been used for something
else in the interim.

> A plain dd copy of the stick provides boot sector, partitioning,
> filesystem, and data file content in one sweep. No fdisk, no mkfs,
> no grub-install, no restoring of a backup archive needed.

Yes, yes, this is back to the technical details of making copies.
That wasn't the subject of my first post and I said as much.

> > That's what the OP wrote that they did, in order to "test the validity".
> 
> Since she or he knows punching cards, i assume that there is knowledge
> of Murphy's Law, too.
> 
> > ¹We had two glitches yesterday evening as the tornadoes went by.
> 
> I have a UPS between power provider and computer. Murphy's law ...

…which cost €...?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web