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

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

burn iso to usb

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

Contents

  burn iso to usb Gunnar Gervin <dofeelok@gmail.com> - 2021-07-31 14:10 +0200
    Re: burn iso to usb Nicolas George <george@nsup.org> - 2021-07-31 14:10 +0200
      Re: burn iso to usb <tomas@tuxteam.de> - 2021-07-31 14:40 +0200
      Re: burn iso to usb Hans <hans.ullrich@loop.de> - 2021-07-31 18:50 +0200
        Re: burn iso to usb Nicolas George <george@nsup.org> - 2021-07-31 18:50 +0200
        Re: burn iso to usb Greg Wooledge <greg@wooledge.org> - 2021-07-31 19:40 +0200
          Re: burn iso to usb <tomas@tuxteam.de> - 2021-07-31 20:00 +0200
        Re: burn iso to usb <tomas@tuxteam.de> - 2021-07-31 19:40 +0200
          Re: burn iso to usb Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-31 20:40 +0200
            Re: burn iso to usb <tomas@tuxteam.de> - 2021-07-31 20:50 +0200
              Re: burn iso to usb "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-31 21:10 +0200
            Re: burn iso to usb Anssi Saari <as@sci.fi> - 2021-08-02 15:20 +0200
              Re: burn iso to usb David Wright <deblis@lionunicorn.co.uk> - 2021-08-02 17:50 +0200
                Re: burn iso to usb Anssi Saari <as@sci.fi> - 2021-08-02 18:10 +0200
                  `pv` rates (was: burn iso to usb) Stefan Monnier <monnier@iro.umontreal.ca> - 2021-08-02 19:30 +0200
                    Re: `pv` rates (was: burn iso to usb) David Wright <deblis@lionunicorn.co.uk> - 2021-08-02 21:00 +0200
                      Re: `pv` rates Stefan Monnier <monnier@iro.umontreal.ca> - 2021-08-02 21:20 +0200
                        Re: `pv` rates David Wright <deblis@lionunicorn.co.uk> - 2021-08-04 18:00 +0200
                        [OFFTOPIC] Fun with pv and broken drive (was: `pv` rates) Stefan Monnier <monnier@iro.umontreal.ca> - 2021-08-04 19:30 +0200
              Re: burn iso to usb Gunnar Gervin <dofeelok@gmail.com> - 2021-08-02 21:10 +0200
                Re: burn iso to usb Greg Wooledge <greg@wooledge.org> - 2021-08-02 21:50 +0200
                  Re: burn iso to usb <tomas@tuxteam.de> - 2021-08-02 22:00 +0200
                  Re: burn iso to usb Nicolas George <george@nsup.org> - 2021-08-02 22:00 +0200
                    Re: burn iso to usb Gunnar Gervin <dofeelok@gmail.com> - 2021-08-03 14:30 +0200
                  Re: burn iso to usb Gunnar Gervin <dofeelok@gmail.com> - 2021-08-03 14:40 +0200
          Re: burn iso to usb Robbi Nespu <robbinespu@gmail.com> - 2021-08-02 12:30 +0200
      Re: burn iso to usb Gunnar Gervin <dofeelok@gmail.com> - 2021-08-01 21:10 +0200

Page 1 of 2  [1] 2  Next page →

#237941 — burn iso to usb

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

How mount iso to usb in terminal? (Debian 10.10 i386 32 bit)

Multiwriter does not work;
Debian Mate answers in the red: "Cannot find program".

Terminal is also difficult; "cannot find or open file" etc, but at least
responds a little

geg

[toc] | [next] | [standalone]

#237942

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

Gunnar Gervin (12021-07-31):
> How mount iso to usb in terminal? (Debian 10.10 i386 32 bit)

Mount? or "burn"? I'll assume the later.

Just:

cp /path/to/file.iso /dev/sdX

where sdX is the device for your USB drive. You will need to make sure
you have the permissions for the devices; I advise it over using rood
privileges for the cp: you could wipe your install if you get the device
wrong.

But if your goal is to also learn, there is a better way, and one that
lets you keep using the USB drive normally. I have written an old and a
newer tutorial:

http://nsup.org/~george/comp/live_iso_usb/
http://nsup.org/~george/comp/live_iso_usb/grub_hybrid.html

Regards,

-- 
  Nicolas George

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

#237945

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

On Sat, Jul 31, 2021 at 02:05:59PM +0200, Nicolas George wrote:
> Gunnar Gervin (12021-07-31):
> > How mount iso to usb in terminal? (Debian 10.10 i386 32 bit)
> 
> Mount? or "burn"? I'll assume the later.
> 
> Just:
> 
> cp /path/to/file.iso /dev/sdX

...but make sure /dev/sdX is not mounted. Otherwise hilarity ensues.

Cheers
 - t

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

#237952

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

Am Samstag, 31. Juli 2021, 14:05:59 CEST schrieb Nicolas George:
> Gunnar Gervin (12021-07-31):

> Just:
> 
> cp /path/to/file.iso /dev/sdX
> 

Hi,

isn't it just:

dd if=whatever.iso of=/dev/sdX  

Best

Hans

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

#237953

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

Hans (12021-07-31):
> isn't it just:
> 
> dd if=whatever.iso of=/dev/sdX  

No. cp is more efficient by default, and this case does not need the
fine control offered by dd.

Regards,

-- 
  Nicolas George

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

#237956

On Sat, Jul 31, 2021 at 07:30:42PM +0200, tomas@tuxteam.de wrote:
> On Sat, Jul 31, 2021 at 06:42:50PM +0200, Hans wrote:
> > Am Samstag, 31. Juli 2021, 14:05:59 CEST schrieb Nicolas George:
> > > Gunnar Gervin (12021-07-31):
> > 
> > > Just:
> > > 
> > > cp /path/to/file.iso /dev/sdX
> > > 
> > 
> > Hi,
> > 
> > isn't it just:
> > 
> > dd if=whatever.iso of=/dev/sdX  
> 
> It's up to taste. Some get worked up one way or the other.
> This discussion comes around cyclically :)
> 
> Personally, I settled on dd, mainly because oflag=sync and
> status=progress. But I'm OK with others using copy, cat or
> whatever :)

If you're going to use dd for this, be sure to increase the block size
from the default 512 bytes to something more appropriate in this century.

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

#237959

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

On Sat, Jul 31, 2021 at 01:34:31PM -0400, Greg Wooledge wrote:
> On Sat, Jul 31, 2021 at 07:30:42PM +0200, tomas@tuxteam.de wrote:
> > On Sat, Jul 31, 2021 at 06:42:50PM +0200, Hans wrote:
> > > Am Samstag, 31. Juli 2021, 14:05:59 CEST schrieb Nicolas George:
> > > > Gunnar Gervin (12021-07-31):
> > > 
> > > > Just:
> > > > 
> > > > cp /path/to/file.iso /dev/sdX
> > > > 
> > > 
> > > Hi,
> > > 
> > > isn't it just:
> > > 
> > > dd if=whatever.iso of=/dev/sdX  
> > 
> > It's up to taste. Some get worked up one way or the other.
> > This discussion comes around cyclically :)
> > 
> > Personally, I settled on dd, mainly because oflag=sync and
> > status=progress. But I'm OK with others using copy, cat or
> > whatever :)
> 
> If you're going to use dd for this, be sure to increase the block size
> from the default 512 bytes to something more appropriate in this century.

Absolutely. I actually run some tests from time to time, and the
general pattern is a very flat maximum somewhere beyond 64 and
below 1G. I tend to use 1M, because it's easy to memorise :)

Cheers
 - t

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

#237957

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

On Sat, Jul 31, 2021 at 06:42:50PM +0200, Hans wrote:
> Am Samstag, 31. Juli 2021, 14:05:59 CEST schrieb Nicolas George:
> > Gunnar Gervin (12021-07-31):
> 
> > Just:
> > 
> > cp /path/to/file.iso /dev/sdX
> > 
> 
> Hi,
> 
> isn't it just:
> 
> dd if=whatever.iso of=/dev/sdX  

It's up to taste. Some get worked up one way or the other.
This discussion comes around cyclically :)

Personally, I settled on dd, mainly because oflag=sync and
status=progress. But I'm OK with others using copy, cat or
whatever :)

Cheers
 - t

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

#237960

>> > cp /path/to/file.iso /dev/sdX
>> dd if=whatever.iso of=/dev/sdX  
> It's up to taste.

Not at all.  The only right answer is:

    pv -parIe </path/to/file.iso >/dev/sdX

Anyone who says otherwise is trying to trick you,


        Stefan

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

#237961

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

On Sat, Jul 31, 2021 at 02:34:14PM -0400, Stefan Monnier wrote:
> >> > cp /path/to/file.iso /dev/sdX
> >> dd if=whatever.iso of=/dev/sdX  
> > It's up to taste.
> 
> Not at all.  The only right answer is:
> 
>     pv -parIe </path/to/file.iso >/dev/sdX

I had to look /that/ up, and I consider myself a command-line junkie.

Thanks for this one
 - t

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

#237962

Hi,

was
  https://www.debian.org/CD/faq/#write-usb
already mentioned in this thread ?
Besides the already mentioned Unix methods it gives advise for users of
MS-Windows, to which i would add program Rufus and its "dd" mode.


Greg Wooledge wrote:
> > If you're going to use dd for this, be sure to increase the block size
> > from the default 512 bytes to something more appropriate in this century.

tomas@tuxteam.de wrote:
> Absolutely. I actually run some tests from time to time, and the
> general pattern is a very flat maximum somewhere beyond 64 and
> below 1G. I tend to use 1M, because it's easy to memorise :)

For the finer operations with ISO images i prefer bs=2048, because that
is the natural granularity of ISO 9660 filesystems.


Stefan Monnier wrote:
> pv -parIe </path/to/file.iso >/dev/sdX

cat(1) on steroids :))


Have a nice day :)

Thomas

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

#238033

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > cp /path/to/file.iso /dev/sdX
>>> dd if=whatever.iso of=/dev/sdX  
>> It's up to taste.
>
> Not at all.  The only right answer is:
>
>     pv -parIe </path/to/file.iso >/dev/sdX

Actually I'm not sure how good it is to have both -a and -r, pv doesn't
really show which rate counter is which...

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

#238040

On Mon 02 Aug 2021 at 16:14:15 (+0300), Anssi Saari wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>> > cp /path/to/file.iso /dev/sdX
> >>> dd if=whatever.iso of=/dev/sdX  
> >> It's up to taste.
> >
> > Not at all.  The only right answer is:
> >
> >     pv -parIe </path/to/file.iso >/dev/sdX
> 
> Actually I'm not sure how good it is to have both -a and -r, pv doesn't
> really show which rate counter is which...

No need: the rate is far more variable than its average, as time passes.

Cheers,
David.

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

#238046

David Wright <deblis@lionunicorn.co.uk> writes:

> On Mon 02 Aug 2021 at 16:14:15 (+0300), Anssi Saari wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> >>> > cp /path/to/file.iso /dev/sdX
>> >>> dd if=whatever.iso of=/dev/sdX  
>> >> It's up to taste.
>> >
>> > Not at all.  The only right answer is:
>> >
>> >     pv -parIe </path/to/file.iso >/dev/sdX
>> 
>> Actually I'm not sure how good it is to have both -a and -r, pv doesn't
>> really show which rate counter is which...
>
> No need: the rate is far more variable than its average, as time passes.

I guess it depends. Before that comment I tried it on an old USB
stick. Read speed was pretty much constant if low. So I think it was the
left rate counter that showed current rate but wouldn't bet on it.

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

#238047 — `pv` rates (was: burn iso to usb)

Anssi Saari [2021-08-02 19:04:59] wrote:
> David Wright <deblis@lionunicorn.co.uk> writes:
>> On Mon 02 Aug 2021 at 16:14:15 (+0300), Anssi Saari wrote:
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> >>> > cp /path/to/file.iso /dev/sdX
>>> >>> dd if=whatever.iso of=/dev/sdX  
>>> >> It's up to taste.
>>> >
>>> > Not at all.  The only right answer is:
>>> >
>>> >     pv -parIe </path/to/file.iso >/dev/sdX
>>> 
>>> Actually I'm not sure how good it is to have both -a and -r, pv doesn't
>>> really show which rate counter is which...
>>
>> No need: the rate is far more variable than its average, as time passes.
>
> I guess it depends. Before that comment I tried it on an old USB
> stick. Read speed was pretty much constant if low. So I think it was the
> left rate counter that showed current rate but wouldn't bet on it.

[ I'm glad my silly intervention brings up a more constructive
  discussion ;-)  ]

If they're both pretty much constant, they're presumably both pretty
much equal, so it doesn't matter which is which ;-)

But indeed, it's not always the case.  I'm right now using `pv` to read
data off of a broken drive (a 2TB 2½" drive which apparently has
problems seeking, resulting in a transfer rate of about 45kB/s), and
it's currently showing me 45.0KiB/s and 70.6KiB/s both of which are
quite stable.  If it weren't for the first sometimes changing to
44.xKiB/s it'd be hard to know which is which (IIUC the average is
higher because occasionally the drive gives a more reasonable transfer
rate than that measly 45kB/s).


        Stefan

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

#238051 — Re: `pv` rates (was: burn iso to usb)

On Mon 02 Aug 2021 at 13:26:19 (-0400), Stefan Monnier wrote:
> Anssi Saari [2021-08-02 19:04:59] wrote:
> > David Wright <deblis@lionunicorn.co.uk> writes:
> >> On Mon 02 Aug 2021 at 16:14:15 (+0300), Anssi Saari wrote:
> >>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >>> >>> > cp /path/to/file.iso /dev/sdX
> >>> >>> dd if=whatever.iso of=/dev/sdX  
> >>> >> It's up to taste.
> >>> >
> >>> > Not at all.  The only right answer is:
> >>> >
> >>> >     pv -parIe </path/to/file.iso >/dev/sdX
> >>> 
> >>> Actually I'm not sure how good it is to have both -a and -r, pv doesn't
> >>> really show which rate counter is which...
> >>
> >> No need: the rate is far more variable than its average, as time passes.
> >
> > I guess it depends. Before that comment I tried it on an old USB
> > stick. Read speed was pretty much constant if low. So I think it was the
> > left rate counter that showed current rate but wouldn't bet on it.
> 
> [ I'm glad my silly intervention brings up a more constructive
>   discussion ;-)  ]
> 
> If they're both pretty much constant, they're presumably both pretty
> much equal, so it doesn't matter which is which ;-)
> 
> But indeed, it's not always the case.  I'm right now using `pv` to read
> data off of a broken drive (a 2TB 2½" drive which apparently has
> problems seeking, resulting in a transfer rate of about 45kB/s), and
> it's currently showing me 45.0KiB/s and 70.6KiB/s both of which are
> quite stable.

Writing "quite stable" cloaks the information nicely. The average can
never move away from the rate: a change in the least significant digit
gives the game away.

> If it weren't for the first sometimes changing to
> 44.xKiB/s it'd be hard to know which is which (IIUC the average is
> higher because occasionally the drive gives a more reasonable transfer
> rate than that measly 45kB/s).

So now we're left wondering how you came by this situation. Perhaps
you slumped onto the Return key, then woke up after a few minutes,
having missed the initial burst that gave rise to the average being
more than 50% faster than the current rate.

Cheers,
David.

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

#238054 — Re: `pv` rates

>> If it weren't for the first sometimes changing to
>> 44.xKiB/s it'd be hard to know which is which (IIUC the average is
>> higher because occasionally the drive gives a more reasonable transfer
>> rate than that measly 45kB/s).
>
> So now we're left wondering how you came by this situation. Perhaps
> you slumped onto the Return key, then woke up after a few minutes,
> having missed the initial burst that gave rise to the average being
> more than 50% faster than the current rate.

I don't know either.  Reading the whole drive would take a few years, so
I'm only fetching the few parts which have changed since the last
backup, and when I look the rate seems to be always ~45kB/s, but
obviously there have to be bursts at higher speeds (presumably because
the drive's defect doesn't affect every cylinder in the same way or
something like that.  E.g. the average has moved up to ~80kB/s since my
last message).


        Stefan

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

#238136 — Re: `pv` rates

On Mon 02 Aug 2021 at 15:09:38 (-0400), Stefan Monnier wrote:
> >> If it weren't for the first sometimes changing to
> >> 44.xKiB/s it'd be hard to know which is which (IIUC the average is
> >> higher because occasionally the drive gives a more reasonable transfer
> >> rate than that measly 45kB/s).
> >
> > So now we're left wondering how you came by this situation. Perhaps
> > you slumped onto the Return key, then woke up after a few minutes,
> > having missed the initial burst that gave rise to the average being
> > more than 50% faster than the current rate.
> 
> I don't know either.  Reading the whole drive would take a few years, so
> I'm only fetching the few parts which have changed since the last
> backup, and when I look the rate seems to be always ~45kB/s, but
> obviously there have to be bursts at higher speeds (presumably because
> the drive's defect doesn't affect every cylinder in the same way or
> something like that.  E.g. the average has moved up to ~80kB/s since my
> last message).

Yes, perhaps because the drive is broken, there was no initial burst
(which usually makes it obvious). 45kB/s is so slow that any normal-speed
bursts might be too short to notice unless you're watching like a hawk.
Most transfers are more likely to look something like below (narrowed).

Nice command though (I too had never noticed it), especially the wall
time, though I would say that having both I&e is less sensible than a&r
when using the command for real. Perhaps I should have used -i myself …

Cheers,
David.

$ pv -parIe <2021-01-20-inauguration-biden-harris-C-qYgs_yOXA.webm >/tmp/copy
[86.8MiB/s] [86.8MiB/s] [>              ]  1% ETA 0:01:25 ETA 18:51:46
[93.2MiB/s] [89.9MiB/s] [>              ]  2% ETA 0:01:22 ETA 18:51:44
[91.9MiB/s] [90.6MiB/s] [>              ]  3% ETA 0:01:20 ETA 18:51:43
[93.1MiB/s] [91.2MiB/s] [=>             ]  4% ETA 0:01:18 ETA 18:51:42
[92.1MiB/s] [91.4MiB/s] [==>            ]  6% ETA 0:01:17 ETA 18:51:42
[85.2MiB/s] [90.4MiB/s] [==>            ]  7% ETA 0:01:17 ETA 18:51:43
[41.6MiB/s] [82.5MiB/s] [==>            ]  7% ETA 0:01:22 ETA 18:51:49
[51.6MiB/s] [79.2MiB/s] [===>           ]  8% ETA 0:01:27 ETA 18:51:55
[3.90MiB/s] [66.4MiB/s] [===>           ]  8% ETA 0:01:37 ETA 18:52:06
[10.7MiB/s] [64.5MiB/s] [===>           ]  8% ETA 0:01:47 ETA 18:52:17
[3.83MiB/s] [58.6MiB/s] [===>           ]  8% ETA 0:01:57 ETA 18:52:28
[3.56MiB/s] [53.5MiB/s] [===>           ]  8% ETA 0:02:06 ETA 18:52:38
[3.80MiB/s] [50.4MiB/s] [===>           ]  8% ETA 0:02:16 ETA 18:52:49
[5.78MiB/s] [47.3MiB/s] [===>           ]  8% ETA 0:02:26 ETA 18:53:00
[5.86MiB/s] [44.4MiB/s] [===>           ]  8% ETA 0:02:34 ETA 18:53:09
[2.54MiB/s] [41.6MiB/s] [===>           ]  8% ETA 0:02:44 ETA 18:53:20
[2.79MiB/s] [39.4MiB/s] [===>           ]  8% ETA 0:02:53 ETA 18:53:30
[72.2MiB/s] [41.0MiB/s] [===>           ]  9% ETA 0:02:46 ETA 18:53:24
[93.1MiB/s] [43.7MiB/s] [====>          ] 10% ETA 0:02:34 ETA 18:53:13
[92.4MiB/s] [46.2MiB/s] [=====>         ] 12% ETA 0:02:24 ETA 18:53:04
[67.3MiB/s] [47.2MiB/s] [======>        ] 13% ETA 0:02:19 ETA 18:53:00
[92.9MiB/s] [49.2MiB/s] [======>        ] 14% ETA 0:02:11 ETA 18:52:53
[87.6MiB/s] [50.9MiB/s] [=======>       ] 15% ETA 0:02:05 ETA 18:52:48
[45.0MiB/s] [50.6MiB/s] [=======>       ] 16% ETA 0:02:04 ETA 18:52:48
[48.6MiB/s] [50.6MiB/s] [=======>       ] 16% ETA 0:02:04 ETA 18:52:49
[45.1MiB/s] [50.4MiB/s] [========>      ] 17% ETA 0:02:04 ETA 18:52:50
[20.4MiB/s] [49.2MiB/s] [========>      ] 17% ETA 0:02:06 ETA 18:52:53
[28.5MiB/s] [48.5MiB/s] [========>      ] 17% ETA 0:02:08 ETA 18:52:56
[35.2MiB/s] [48.0MiB/s] [========>      ] 18% ETA 0:02:08 ETA 18:52:57
[4.75MiB/s] [46.5MiB/s] [========>      ] 18% ETA 0:02:12 ETA 18:53:02
[1.30MiB/s] [45.1MiB/s] [========>      ] 18% ETA 0:02:16 ETA 18:53:07
[3.25MiB/s] [43.8MiB/s] [========>      ] 18% ETA 0:02:20 ETA 18:53:12
[2.93MiB/s] [42.5MiB/s] [========>      ] 18% ETA 0:02:24 ETA 18:53:17
[2.67MiB/s] [41.3MiB/s] [========>      ] 18% ETA 0:02:28 ETA 18:53:22
[4.17MiB/s] [40.2MiB/s] [========>      ] 18% ETA 0:02:32 ETA 18:53:27
[2.52MiB/s] [39.3MiB/s] [========>      ] 18% ETA 0:02:36 ETA 18:53:32
[5.58MiB/s] [38.4MiB/s] [========>      ] 18% ETA 0:02:40 ETA 18:53:37
[3.75MiB/s] [37.5MiB/s] [========>      ] 18% ETA 0:02:43 ETA 18:53:41
[3.90MiB/s] [36.6MiB/s] [========>      ] 18% ETA 0:02:47 ETA 18:53:46
[55.0MiB/s] [37.0MiB/s] [=========>     ] 19% ETA 0:02:44 ETA 18:53:44
[47.9MiB/s] [37.3MiB/s] [==========>    ] 20% ETA 0:02:41 ETA 18:53:42
[83.6MiB/s] [38.4MiB/s] [==========>    ] 21% ETA 0:02:35 ETA 18:53:37
[72.3MiB/s] [39.2MiB/s] [===========>   ] 22% ETA 0:02:30 ETA 18:53:33
[ 105MiB/s] [40.7MiB/s] [===========>   ] 23% ETA 0:02:22 ETA 18:53:26
[93.8MiB/s] [41.9MiB/s] [============>  ] 24% ETA 0:02:15 ETA 18:53:20
^C
$ 

Cheers,
David.

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

#238144 — [OFFTOPIC] Fun with pv and broken drive (was: `pv` rates)

Stefan Monnier [2021-08-02 15:09:38] wrote:
> E.g. the average has moved up to ~80kB/s since my last message).

For your entertainment: I managed to bring the average rate up to about
1MB/s by running `lvs` in a loop at the same time (and that let me see
occasionally a transfer rate around 10MB/s).

I have no idea what it is that makes `lvs`s interference
so beneficial.  I tried a few other operations (like `du`, and `dd`) but
to no avail.

Without any interference from `lvs` I get a long term average slightly
below 100kB/s.


        Stefan

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

#238053

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

Hi.
The different suggestions are not complete, are they??
Like:
pv -parle </path/to/file.iso >/dev/sdX
would rather be:
sudo pv -parle </path/to/debian-live-10.10.0-amd64-gnome.iso>/dev/sdb
And even not sure on that example as being correct. Please correct my
possible failure/s in the above try.
As you can see, I`m trying a -64bit- because Macbook 2.1 might fit it. And
Gnome because it seems more complete.
Saw another (relative) newbie said something similar concerning man pages
in terminal: "Would be nice with example/s".
BR,
geg

On Mon, 2 Aug 2021 at 16:14, Anssi Saari <as@sci.fi> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >>> > cp /path/to/file.iso /dev/sdX
> >>> dd if=whatever.iso of=/dev/sdX
> >> It's up to taste.
> >
> > Not at all.  The only right answer is:
> >
> >     pv -parIe </path/to/file.iso >/dev/sdX
>
> Actually I'm not sure how good it is to have both -a and -r, pv doesn't
> really show which rate counter is which...
>
>
>

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web