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

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

DD bs=4M option on USB mem-stick creates false format

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

Contents

  DD bs=4M option on USB mem-stick creates false format kAt <giathnygeia@openmailbox.org> - 2017-03-26 19:40 +0200
    Re: DD bs=4M option on USB mem-stick creates false format Darac Marjal <mailinglist@darac.org.uk> - 2017-03-26 19:50 +0200
    Re: DD bs=4M option on USB mem-stick creates false format Richard Owlett <rowlett@cloud85.net> - 2017-03-26 20:00 +0200
    Re: DD bs=4M option on USB mem-stick creates false format kAt <giathnygeia@openmailbox.org> - 2017-03-26 20:10 +0200
    Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-26 20:20 +0200
      Re: DD bs=4M option on USB mem-stick creates false format kAt <giathnygeia@openmailbox.org> - 2017-03-27 12:20 +0200
        Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-27 14:20 +0200
          Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-27 14:40 +0200
            Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-28 12:20 +0200
              Re: DD bs=4M option on USB mem-stick creates false format Richard Owlett <rowlett@cloud85.net> - 2017-03-28 14:00 +0200
                Re: DD bs=4M option on USB mem-stick creates false format <tomas@tuxteam.de> - 2017-03-28 14:20 +0200
                  Re: DD bs=4M option on USB mem-stick creates false format Richard Owlett <rowlett@cloud85.net> - 2017-03-28 15:50 +0200
                    Re: DD bs=4M option on USB mem-stick creates false format <tomas@tuxteam.de> - 2017-03-28 15:50 +0200
                    Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-28 16:30 +0200
                      Re: DD bs=4M option on USB mem-stick creates false format Richard Owlett <rowlett@cloud85.net> - 2017-03-28 17:40 +0200
                        Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-28 19:10 +0200
                Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-28 14:20 +0200
                  Re: DD bs=4M option on USB mem-stick creates false format <tomas@tuxteam.de> - 2017-03-28 14:20 +0200
                  Re: DD bs=4M option on USB mem-stick creates false format Richard Owlett <rowlett@cloud85.net> - 2017-03-28 14:40 +0200
                  Re: DD bs=4M option on USB mem-stick creates false format Richard Owlett <rowlett@cloud85.net> - 2017-03-28 15:20 +0200
              Re: DD bs=4M option on USB mem-stick creates false format songbird <songbird@anthive.com> - 2017-03-28 19:30 +0200
                Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-28 20:40 +0200
                  Re: DD bs=4M option on USB mem-stick creates false format songbird <songbird@anthive.com> - 2017-03-29 07:50 +0200
                    Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-29 10:30 +0200
                      Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-29 12:20 +0200
                        Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-29 12:40 +0200
              Re: DD bs=4M option on USB mem-stick creates false format kAt <giathnygeia@openmailbox.org> - 2017-03-29 00:50 +0200
                Re: DD bs=4M option on USB mem-stick creates false format songbird <songbird@anthive.com> - 2017-03-29 07:50 +0200
                Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-29 10:20 +0200
                  Re: DD bs=4M option on USB mem-stick creates false format kAt <giathnygeia@openmailbox.org> - 2017-03-29 22:30 +0200
                    Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-30 00:00 +0200
                Re: DD bs=4M option on USB mem-stick creates false format Curt <curty@free.fr> - 2017-03-29 16:40 +0200
                  Re:Movie 'n Book recommendations by Curt kAt <giathnygeia@openmailbox.org> - 2017-03-29 22:10 +0200
                    Re: Movie 'n Book recommendations by Curt Lisi Reisz <lisi.reisz@gmail.com> - 2017-03-29 23:40 +0200
                      Re: Movie 'n Book recommendations by Curt kAt <giathnygeia@openmailbox.org> - 2017-03-30 20:10 +0200
                        Re: Movie 'n Book recommendations by Curt Lisi Reisz <lisi.reisz@gmail.com> - 2017-03-30 20:20 +0200
                          Re: Movie 'n Book recommendations by Curt Richard Owlett <rowlett@cloud85.net> - 2017-03-30 20:50 +0200
                      Re: Movie 'n Book recommendations by Curt Catherine Gramze <rhiamom@mac.com> - 2017-03-30 20:30 +0200
                      Re: Movie 'n Book recommendations by Curt Eike Lantzsch <zp6cge@gmx.net> - 2017-03-30 20:40 +0200
                        Re: Movie 'n Book recommendations by Curt John Hasler <jhasler@newsguy.com> - 2017-03-30 21:30 +0200
                          Re: Movie 'n Book recommendations by Curt Terence <terence.john@gmail.com> - 2017-03-30 22:00 +0200
                            Re: Movie 'n Book recommendations by Curt Catherine Gramze <rhiamom@mac.com> - 2017-03-30 22:40 +0200
                              Re: Movie 'n Book recommendations by Curt Lisi Reisz <lisi.reisz@gmail.com> - 2017-03-31 00:20 +0200
                                Re: Movie 'n Book recommendations by Curt Catherine Gramze <rhiamom@mac.com> - 2017-03-31 01:30 +0200
                            Re: Movie 'n Book recommendations by Curt Jonathan Dowland <jmtd@debian.org> - 2017-03-31 09:50 +0200
                              Re: Movie 'n Book recommendations by Curt Terence <terence.john@gmail.com> - 2017-03-31 12:40 +0200
                                OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) rhkramer@gmail.com - 2017-03-31 15:10 +0200
                                  Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) Lisi Reisz <lisi.reisz@gmail.com> - 2017-03-31 15:40 +0200
                                    Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) Greg Wooledge <wooledg@eeg.ccf.org> - 2017-03-31 15:50 +0200
                                      Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) rhkramer@gmail.com - 2017-03-31 16:20 +0200
                                        Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) Eike Lantzsch <zp6cge@gmx.net> - 2017-03-31 16:30 +0200
                                      Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re:  Movie 'n Book recommendations by Curt) Curt <curty@free.fr> - 2017-03-31 18:00 +0200
                                        Re: OT: speaking of days (weeks, months, years, etc.) kAt <giathnygeia@openmailbox.org> - 2017-04-01 00:20 +0200
                                    Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) rhkramer@gmail.com - 2017-03-31 16:20 +0200
                                      Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) Lisi Reisz <lisi.reisz@gmail.com> - 2017-03-31 17:00 +0200
                                        Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re:  Movie 'n Book recommendations by Curt) Liam O'Toole <liam.p.otoole@gmail.com> - 2017-04-01 19:20 +0200
                                          Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re: Movie 'n Book recommendations by Curt) Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-01 20:10 +0200
                                            Re: OT: speaking of days (weeks, months, years, etc.)  (was: Re:  Movie 'n Book recommendations by Curt) Liam O'Toole <liam.p.otoole@gmail.com> - 2017-04-01 21:30 +0200
                                    Re: OT: speaking of days (weeks, months, years, etc.) Peter Hillier-Brook <phb@hbsys.plus.com> - 2017-03-31 17:20 +0200
                                    Re: OT: speaking of days (weeks, months, years, etc.) kAt <giathnygeia@openmailbox.org> - 2017-04-01 00:20 +0200
                                      Re: OT: speaking of days (weeks, months, years, etc.) Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-01 00:50 +0200
                                        Re: OT: speaking of days (weeks, months, years, etc.) GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-01 18:10 +0200
                                  Re: OT: speaking of days (weeks, months, years, etc.) Stefan Monnier <monnier@iro.umontreal.ca> - 2017-03-31 16:50 +0200
                                    Re: OT: speaking of days (weeks, months, years, etc.) Lisi Reisz <lisi.reisz@gmail.com> - 2017-03-31 17:00 +0200
                                    Re: OT: speaking of days (weeks, months, years, etc.) Eike Lantzsch <zp6cge@gmx.net> - 2017-03-31 17:10 +0200
                                      Re: OT: speaking of days (weeks, months, years, etc.) kAt <giathnygeia@openmailbox.org> - 2017-04-01 00:40 +0200
          Re: DD bs=4M option on USB mem-stick creates false format Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-27 21:00 +0200
            Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-27 21:50 +0200
    Re: DD bs=4M option on USB mem-stick creates false format David Christensen <dpchrist@holgerdanske.com> - 2017-03-27 06:10 +0200
      Re: DD bs=4M option on USB mem-stick creates false format kAt <giathnygeia@openmailbox.org> - 2017-03-27 14:10 +0200
        Re: DD bs=4M option on USB mem-stick creates false format rhkramer@gmail.com - 2017-03-27 14:30 +0200
        Re: DD bs=4M option on USB mem-stick creates false format Greg Wooledge <wooledg@eeg.ccf.org> - 2017-03-27 14:40 +0200
          Re: DD bs=4M option on USB mem-stick creates false format "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-27 15:10 +0200
          Re: DD bs=4M option on USB mem-stick creates false format David Christensen <dpchrist@holgerdanske.com> - 2017-03-27 20:20 +0200
            Re: DD bs=4M option on USB mem-stick creates false format Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-28 00:00 +0200
        Re: DD bs=4M option on USB mem-stick creates false format David Christensen <dpchrist@holgerdanske.com> - 2017-03-27 19:40 +0200

Page 4 of 4 — ← Prev page 1 2 3 [4]

#179671 — Re: OT: speaking of days (weeks, months, years, etc.)

On Friday 31 March 2017 22:53:00 kAt wrote:
> As there is a domination of the
> industrial North and elitism against the dominated South.

Not here!!!!  The non-industrial white collar south-east dominates the 
industrial north economically.  The Northern Powerhub is so far a figment of 
the politicians' imaginations.  Banks trump factories.

Lisi

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

#179687 — Re: OT: speaking of days (weeks, months, years, etc.)

Lisi Reisz:
> On Friday 31 March 2017 22:53:00 kAt wrote:
>> As there is a domination of the
>> industrial North and elitism against the dominated South.
> 
> Not here!!!!  The non-industrial white collar south-east dominates the 
> industrial north economically.  The Northern Powerhub is so far a figment of 
> the politicians' imaginations.  Banks trump factories.

It does not have to do with geography but with history.  The north of
the uk did not go into a bloody civil war with the south and for
economical reasons (cheap industrial labor) vs even cheaper
non-industrial labor.  As the discussion started from the remark about
bumkins down in N.Carolina to draw parallels about North and South Korea
would be meaningless.  It relates to the social issues about the
"economical development" against the "underdevelopment" of the south.
The social implications in which case relate to differentiation in
education, health, infrustructure of "developed" areas and
underdeveloped areas.  Before the civil war started things were pretty
reversed with S.Carolina having almost 10 times the per capita income of
the rest of the US, the best schools and the best of everything.

In the UK the NHS and public schools were pretty much equal for all, it
had nothing to do with regional economic development.

> Lisi

I don't know why you are derailing the issue to something completely
irrelevant, unless there is a N.Carolina down south in the UK I don't
know about!

We do want southerners (down southerners) of all kinds equally welcome
in this Debian community, don't we?  Even Aboriginees from S.Australia.
That is my point!

-- 
 "The most violent element in society is ignorance" rEG

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

#179647 — Re: OT: speaking of days (weeks, months, years, etc.)

I tried "aptitude install Thursday" and that failed miserably.
Then I tried with `apt-get`: same result.

The worst part is that I get the same kinds of failures when I try
"aptitude install this Thursday" or "aptitude install next Thursday".


        Stefan "confused about this Debian thing"


>>>>> "rhkramer" == rhkramer  <rhkramer@gmail.com> writes:

> On Friday, March 31, 2017 06:30:25 AM Terence wrote:
>> There is no ambiguity if (as I have always understood) "Thursday" means
>> "this (or the coming) Thursday" and "next Thursday" or "Thursday next"
>> means "a week on Thursday".
>> 
>> And having lived in Yorkshire for two very happy years, I would agree that
>> York is above London in so many ways...

> To me, all that has been discussed is (potentially) confusing and ambiguous.

> To me, I prefer the following--ohh, most of the examples assume that the 
> current day is not Thursday (but maybe that makes no difference):

> Thursday can refer either to the coming Thursday or the previous Thursday 
> based on the context, for example:

> On Thursday, we played baseball.  (obvious (to me) that was the (just) 
> previous Thursday)

> The paper is due on Thursday.  (obvious (to me) that is the (just) coming 
> Thursday)

> Last Thursday, we played baseball.  (clear to me, but the "last" is redundant 
> and may be ambiguous to some--might some mean the Thursday before the most 
> recent??)

> The paper is due next Thursday.   (clear to me, but the "next" is redundant 
> and is ambiguous to some--some seem to mean the Thursday after the coming / 
> really next Thursday)

> The paper is due Thursday next.  (clear to me, but the "next" is redundant and 
> is ambiguous to some--some seem to mean the Thursday after the coming / really 
> next Thursday--it might be a Briticism (to coin or mangle a word))

> To specify the Thursday before the last Thursday, use something like: "the 
> Thursday before last Thursday".

> To specify the Thursday after the coming Thursday, use something like: "the 
> Thursday after next Thursday".

> Use similar constructs for other days, weeks, months, years, millennia, 
> minutes, hours, etc., or better, specify a date, year, time, or similar.

> I'm not aware of whether the grammar lords have established a clear preferred 
> usage pattern--if they have, I'm sure it differs on the two sides of the 
> Atlantic.

> (Maybe this is my subconcious bid to become a grammar lord??  Uuh, I think 
> I'll shut up now, I'd hate to be tagged with that label.)

> Randy Kramer







 

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

#179650 — Re: OT: speaking of days (weeks, months, years, etc.)

On Friday 31 March 2017 15:43:50 Stefan Monnier wrote:
> I tried "aptitude install Thursday" and that failed miserably.
> Then I tried with `apt-get`: same result.
>
> The worst part is that I get the same kinds of failures when I try
> "aptitude install this Thursday" or "aptitude install next Thursday".
>
>
>         Stefan "confused about this Debian thing"

:-)  Sorry.

One of the best tempered reasonable objections I recall seeing.

Lisi

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

#179652 — Re: OT: speaking of days (weeks, months, years, etc.)

On Friday, 31 March 2017 10:43:50 -04 Stefan Monnier wrote:
> I tried "aptitude install Thursday" and that failed miserably.
> Then I tried with `apt-get`: same result.
> 
> The worst part is that I get the same kinds of failures when I try
> "aptitude install this Thursday" or "aptitude install next Thursday".
> 
> 
>         Stefan "confused about this Debian thing"
> 
it is e.g.:
date -d thursday

or:
date -d next-thursday

or:
date --date='TZ="America/Asuncion" 09:00 next Thu'

or
calendar -w -t 20170406

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

#179670 — Re: OT: speaking of days (weeks, months, years, etc.)

Eike Lantzsch:

> it is e.g.:
> date -d thursday
> or:
> date -d next-thursday
> or:
> date --date='TZ="America/Asuncion" 09:00 next Thu'
> or
> calendar -w -t 20170406

TZ='London' date | grep "Universal Time"

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

#179486

Le 27/03/2017 à 14:11, Thomas Schmitt a écrit :
>
> - APM partition table with block size 2048 (look here for a suspect !)

Right.
For whatever reason, libarted-based tools choose to consider that bogus 
Apple partition table. Unlike fdisk, you cannot force it to use another 
format.

Bottom line : libparted-based tools do not handle ISO-hybrid images 
correctly. Do not use them with such images.

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

#179493

Hi,

i wrote:
> > - APM partition table with block size 2048 (look here for a suspect !)

Pascal Hambourg wrote:
> For whatever reason, libarted-based tools choose to consider that bogus
> Apple partition table.
> Bottom line : libparted-based tools do not handle ISO-hybrid images
> correctly. Do not use them with such images.

But why on the first hand does debian-cd instruct xorriso to create APM ?
(By option -isohybrid-apm-hfsplus)

I understand from Matthew Garrett's blog and from discussions with
GRUB developer Vladimir Serbinenko that Macs which expect APM also
expect HFS+ with "blessed" files and not FAT with EFI files.

The Fedora ISOs have HFS+ images. grub-mkrescue ISOs can have HFS+.
But Debian and Ubuntu ISOs only have the EFI FAT filessystem image
in their APM. Is there any Mac known which boots only by this APM ?


Have a nice day :)

Thomas

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

#179422

On 03/26/2017 10:18 AM, kAt wrote:
> dd if=/media/------/image.iso of=/dev/sdb bs=4M; sync
>
> the image works but the format of the drive seems false gparted when
> starting says that linux thinks it is a 256k block and not the 4m it
> indicates.  It shows on an 8G drive an empty space of 28G
>
> Is it the option of bs=4M that creates this problem. The free space
> can not be formatted and partitioned.  As Gparted tried to claim and
> format this space as a 6.7G which seemed right it crashed.
>
> Any advise would greatly be appreciated

On 03/26/2017 10:41 AM, kAt wrote:
> Correction to the error message, it is this: The driver descriptor
> says the physical block size is 2048 bytes, but Linux says it is 512
> bytes.
>
> or at least that is what I get without using the bs=4M option
>
> I am wondering whether it is a fault of the iso image (recent
> download of the Rescatux 4.0beta) which I am trying to use without
> luck on an old 32bit Celeron?? .. with Win XP to repair its admin
> pass and booting which seems to take for ever.
>
> I am trying to use the empty part of the stick to copy and store
> temporatily some important files before I mess with it or install
> debian

Please post console sessions -- prompt, command, and full output. 
Paraphrasing and omitting information wastes everybody's time.


Always start a new thread with these:

2017-03-26 19:50:42 dpchrist@jesse ~
$ cat /etc/debian_version
8.7

2017-03-26 19:50:46 dpchrist@jesse ~
$ uname -a
Linux jesse 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07)
x86_64 GNU/Linux


Also, please post the URL for image.iso/Rescatux 4.0beta.


Did you checksum your download?  If not, checksum it.  If the download 
checksum is bad, download and checksum again until you get a good 
checksum.  For example:

2017-03-18 12:40:50 root@cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# grep debian-8.7.1-i386-xfce-CD-1.iso SHA256SUMS
a258af89540a64e6d16d6a546ec554a07ef0d46168d74bfc2073cc60d6a9ecde
debian-8.7.1-i386-xfce-CD-1.iso

2017-03-18 12:41:30 root@cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# sha256sum debian-8.7.1-i386-xfce-CD-1.iso
a258af89540a64e6d16d6a546ec554a07ef0d46168d74bfc2073cc60d6a9ecde
debian-8.7.1-i386-xfce-CD-1.iso


Did you checksum the image on your USB flash drive immediately after 
burning?  Use a calculator to find the largest power of 2 that divides 
evenly into the image size:

2017-03-18 12:41:06 root@cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# ll debian-8.7.1-i386-xfce-CD-1.iso
-rw-r--r-- 1 dpchrist dpchrist 678428672 2017/03/04 17:02:57
debian-8.7.1-i386-xfce-CD-1.iso


In this case, it's 2^20.  Do the burn with 'bs=1M'.  Also, run 'sync' 
after 'dd' to ensure that the command prompt is not returned until all 
the bytes have been written:

2017-03-18 12:41:54 root@cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# time dd if=debian-8.7.1-i386-xfce-CD-1.iso of=/dev/sdc bs=1M; sync
647+0 records in
647+0 records out
678428672 bytes (678 MB) copied, 161.132 s, 4.2 MB/s

real    2m41.135s>
user    0m0.012s
sys    0m1.640s


Note '647+0 records in' and '647+0 records out'.  The '647' part must 
match and both must have '+0', or something is wrong.  Use 'dd' with 
'bs=1M' and 'count=647' to do the checksum:

2017-03-18 12:51:52 root@cd2533
/var/local/data/dpchrist/iso/debian/8.7.1/i386
# time dd if=/dev/sdc bs=1M count=647 | sha256sum
647+0 records in
647+0 records out
a258af89540a64e6d16d6a546ec554a07ef0d46168d74bfc2073cc60d6a9ecde  -
678428672 bytes (678 MB) copied, 33.1367 s, 20.5 MB/s

real    0m33.141s
user    0m5.992s
sys    0m1.948s


Understand that many memstick images change once they have been booted, 
so you must checksum them immediately after burning.  (Thankfully, 
debian-8.7.1-i386-xfce-CD-1.iso doesn't, so I can verify my USB flash 
drive at any time.)


Once you are confident your USB flash drive has a good image, try 
booting it in your newest x86 computer.  If that fails, try other x86 
computers.  If none of them boot, contact your vendor.


If the USB flash drive boots correctly in newer computers, it is 
probably in "isohybrid" format -- meaning, it's supposed to boot when 
burned to optical media (CD-R, DVD-R, BD-R) and it's supposed to boot 
when burned to a USB drive.  I have found that this "one size fits most" 
approach doesn't boot on all computers, especially older computers.  If 
this is the case, possible solutions include:

1.  Burn the ISO image to optical media and boot that.

2.  Download a memstick.img file that is meant to be burned to a USB
drive, burn it to a USB drive, and boot that.  (If your vendor doesn't 
offer such, you might need to find a different tool.)


David

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

#179440

David Christensen:
> uname -a
>Always start a new thread with these:

2017-03-26 19:50:42 dpchrist@jesse ~
$ cat /etc/debian_version
9.0
$ uname -a
Linux debian9 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64
GNU/Linux

>Also, please post the URL for image.iso/Rescatux 4.0beta.

http://www.supergrubdisk.org/2016/09/24/rescatux-0-40-beta-11-released/
http://sourceforge.net/projects/rescatux/files/rescatux_0_40_b11/rescatux-0.40b11.iso/download

>Did you checksum your download?  If not, checksum it.  If the download
>checksum is bad, download and checksum again until you get a good
>checksum.  For example:

$ md5sum -c rescatux-0.40b11.iso.md5
rescatux-0.40b11.iso: OK

>In this case, it's 2^20.  Do the burn with 'bs=1M'.  Also, run 'sync'
>after 'dd' to ensure that the command prompt is not returned until all
>the bytes have been written:

Yes, all this was done, the image on the stick is fine and functional!
I did not say there was a problem with it, but the rest of the unused
space ob the disk/mem-stick

>Understand that many memstick images change once they have been
>booted, so you must checksum them immediately after burning.
>(Thankfully, debian-8.7.1-i386-xfce-CD-1.iso doesn't, so I can verify
>my USB flash drive at any time.)

I have done this 3 times bs=4M bs=1M and without a bs= tag, no difference!

>Once you are confident your USB flash drive has a good image, try
>booting it in your newest x86 computer.  If that fails, try other x86
>computers.  If none of them boot, contact your vendor.

No, the image works, it has a problem bringing up the full graphical
part on a an old pc with very little RAM and video memory on its 586
option (it has both a 64 and 32b live parts) and are both jessie based.
The debian 32bit 8,7,1 works fine on the sane machine

>If the USB flash drive boots correctly in newer computers, it is
>probably in "isohybrid" format -- meaning, it's supposed to boot when
>burned to optical media (CD-R, DVD-R, BD-R) and it's supposed to boot
>when burned to a USB drive.  I have found that this "one size fits
>most" approach doesn't boot on all computers, especially older
>computers.  If this is the case, possible solutions include:
>
>1.  Burn the ISO image to optical media and boot that.

Tough luck, the one machine has no such thing, the ill box has its cd
player jammed shut with a CD in it from 13 years ago that plays fine on
live jessie

>2.  Download a memstick.img file that is meant to be burned to a USB
>drive, burn it to a USB drive, and boot that.  (If your vendor doesn't
>offer such, you might need to find a different tool.)

Again the question is not so much at the vendor's magic system but why
would a 0.6G image rent the rest of the disk useless for copying stuff
in and out, which I have done with many live systems.

>David

Have a nice day
kAt

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

#179443

On Monday, March 27, 2017 07:45:00 AM kAt wrote:
> Again the question is not so much at the vendor's magic system but why
> would a 0.6G image rent the rest of the disk useless for copying stuff
> in and out, which I have done with many live systems.

To me this is not an unexpected result.  I don't remember the details, but, 
depending on how you copy the install image to the disk, it will make the disk 
(even a much larger disk) look like it can hold only the installation disk.  

IIRC, it has to do with how many partitions you have on the disk and where you 
copy the image to--again, iirc, if you partition the disk first, and then put 
the image in one partition, it will fill only that partition.  If you put the 
image on the entire disk, it will fill the entire disk.

In your copying / dding / whatever of the image to the disk, (again, iirc) if 
you specify, for example, the target as /dev/sdc the entire disk is filled, if 
you specify /dev/sdc1, you fill only partition 1.

Whether you can then boot the image is another question.  I don't remember 
enough to give more details atm.

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

#179447

On Mon, Mar 27, 2017 at 11:45:00AM +0000, kAt wrote:
> Yes, all this was done, the image on the stick is fine and functional!
> I did not say there was a problem with it, but the rest of the unused
> space ob the disk/mem-stick

When you write a disk-image onto a "disk" (in this case, a USB mass
storage device), you are overwriting all of the metadata at the start
of the "disk", including the partition table.  If the disk-image came
from a 4 GB disk, and you write it onto an 8 GB disk, then the 8 GB
disk will *believe* that it is a 4 GB disk, because it has the metadata
from a 4 GB disk.

As others have said, this has absolutely nothing to do with the bs=
option in dd.  All that does is make the dd command run a tiny bit
faster or slower.

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

#179451

Hi,

Greg Wooledge wrote:
> If the disk-image came
> from a 4 GB disk, and you write it onto an 8 GB disk, then the 8 GB
> disk will *believe* that it is a 4 GB disk, because it has the metadata
> from a 4 GB disk.

The device size is not determined by the image data which get written to it.
I assume that firmwares and operating systems obtain it by SCSI commands
from the stick hardware.

The device file in Linux is simply a string of the determined number
of blocks.

The partition tables are simply data written to those blocks.
Their block addresses and the meaning of their bytes is subject to
conventions of software producers.

I understand Microsoft and IBM specified the MBR partition table.
Later Intel specified EFI and GUID Partition Table (GPT) as replacement
of BIOS and MBR partition table.
Apple had its own Apple Partition Map. Sun has disklabels. SGI had MIPS
Volume Headers. FreeBSD installs its slices inside MBR partitions.


Have a nice day :)

Thomas

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

#179484

On 03/27/2017 05:38 AM, Greg Wooledge wrote:
> ... the bs= option in dd.  All that does is make the dd command run a
> tiny bit faster or slower.

As I understand it, writes smaller than a flash page size cause the 
flash drive firmware to fetch or erase an available page of flash, 
combine the unmodified bytes from the existing page with the new bytes, 
and then burn the page (and internal meta-data).  So, if flash pages are 
8K, burning in 512 blocks could cause 16 such operations, taking longer 
and eating up the life of your flash cells.  That said, RAM buffering by 
the operating system, RAM buffering by the USB flash drive, and firmware 
that anticipates serial writes should mitigate these effects.


For example, here is an ADATA 4 marketing-GB USB flash drive:

2017-03-27 10:50:16 root@jesse ~
# dmesg | tail -n 17
[ 2794.868073] usb 3-3: new high-speed USB device number 3 using ehci-pci
[ 2795.003837] usb 3-3: New USB device found, idVendor=125f, idProduct=c08a
[ 2795.003845] usb 3-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 2795.003851] usb 3-3: Product: ADATA USB Flash Drive
[ 2795.003856] usb 3-3: Manufacturer: ADATA
[ 2795.003861] usb 3-3: SerialNumber: 1392303332110024
[ 2795.026206] usb-storage 3-3:1.0: USB Mass Storage device detected
[ 2795.026718] scsi2 : usb-storage 3-3:1.0
[ 2795.026845] usbcore: registered new interface driver usb-storage
[ 2796.025404] scsi 2:0:0:0: Direct-Access     ADATA    USB Flash Drive 
0.00 PQ: 0 ANSI: 4
[ 2796.027040] sd 2:0:0:0: Attached scsi generic sg2 type 0
[ 2796.028370] sd 2:0:0:0: [sdb] 7592960 512-byte logical blocks: (3.88 
GB/3.62 GiB)
[ 2796.031242] sd 2:0:0:0: [sdb] Write Protect is off
[ 2796.031251] sd 2:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 2796.032626] sd 2:0:0:0: [sdb] Write cache: disabled, read cache: 
enabled, doesn't support DPO or FUA
[ 2796.041663]  sdb: sdb1 sdb2
[ 2796.072615] sd 2:0:0:0: [sdb] Attached SCSI removable disk


Burning 10 MB using 'bs=1M':

2017-03-27 11:01:23 root@jesse ~
# time dd if=/dev/urandom of=/dev/sdb seek=3000 count=10 bs=1M && sync
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 2.93679 s, 3.6 MB/s

real	0m2.941s
user	0m0.000s
sys	0m1.020s


Burning 10 MB using default bs:

2017-03-27 11:01:57 root@jesse ~
# time dd if=/dev/urandom of=/dev/sdb seek=6144000 count=20480 && sync
20480+0 records in
20480+0 records out
10485760 bytes (10 MB) copied, 5.38085 s, 1.9 MB/s

real	0m5.385s
user	0m0.012s
sys	0m1.388s


David

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

#179497

Le 27/03/2017 à 20:11, David Christensen a écrit :
>
> For example, here is an ADATA 4 marketing-GB USB flash drive:
(...)
> Burning 10 MB using 'bs=1M':
>
> 2017-03-27 11:01:23 root@jesse ~
> # time dd if=/dev/urandom of=/dev/sdb seek=3000 count=10 bs=1M && sync
> 10+0 records in
> 10+0 records out
> 10485760 bytes (10 MB) copied, 2.93679 s, 3.6 MB/s
>
> real    0m2.941s
> user    0m0.000s
> sys    0m1.020s
>
>
> Burning 10 MB using default bs:
>
> 2017-03-27 11:01:57 root@jesse ~
> # time dd if=/dev/urandom of=/dev/sdb seek=6144000 count=20480 && sync
> 20480+0 records in
> 20480+0 records out
> 10485760 bytes (10 MB) copied, 5.38085 s, 1.9 MB/s
>
> real    0m5.385s
> user    0m0.012s
> sys    0m1.388s

This is not specific to write operation on flash devices.
Default 512-byte block size has also consistently shown degraded 
performance in read and write operation on hard disk drives.

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

#179482

On 03/27/2017 04:45 AM, kAt wrote:
> David Christensen:
>> Understand that many memstick images change once they have been
>> booted, so you must checksum them immediately after burning.
>> (Thankfully, debian-8.7.1-i386-xfce-CD-1.iso doesn't, so I can verify
>> my USB flash drive at any time.)
>
> I have done this 3 times bs=4M bs=1M and without a bs= tag, no difference!

Without seeing the command and output, we cannot check it.  But, if 
you're happy with the image on the USB flash drive, then okay.


>> Once you are confident your USB flash drive has a good image, try
>> booting it in your newest x86 computer.  If that fails, try other x86
>> computers.  If none of them boot, contact your vendor.
>
> No, the image works, it has a problem bringing up the full graphical
> part on a an old pc with very little RAM and video memory on its 586
> option (it has both a 64 and 32b live parts) and are both jessie based.
> The debian 32bit 8,7,1 works fine on the sane machine

Okay.


>> 1.  Burn the ISO image to optical media and boot that.
>
> Tough luck, the one machine has no such thing, the ill box has its cd
> player jammed shut with a CD in it from 13 years ago that plays fine on
> live jessie

Many optical drives have a small hole in the front door that you can 
insert an unbent paper clip into to manually open the drawer.


>> 2.  Download a memstick.img file that is meant to be burned to a USB
>> drive, burn it to a USB drive, and boot that.  (If your vendor doesn't
>> offer such, you might need to find a different tool.)
>
> Again the question is not so much at the vendor's magic system but why
> would a 0.6G image rent the rest of the disk useless for copying stuff
> in and out, which I have done with many live systems.

isohybrid images have non-standard on-disk data structures to get them 
to boot when burned to CD and when burned to USB; basically, they are 
hacks that "mostly work".  You're not going to get meaningful results 
with gparted, fdisk, parted, or the others.


David

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web