What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
Thanks,
John
--
John Conover, conover@panix.com, http://www.johncon.com/
What does a "debian ... amd64-netinst.iso" do with an .iso?
Can it be coverted to a USB. How?
On Fri 30 Aug 2024 at 20:48:38 (-0700), John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
I plug in a USB stick (which will get completely overwritten),
check from the logs what its device name is (/dev/sdX),
then, as root, execute:
# dd bs=1M if=debian…amd64-netinst.iso of=/dev/sdX
# sync
and wait for the prompt after the sync command.
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
# cp debian.iso /dev/sdX
On 8/30/24 20:48, John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
When I input that string into a computer running Debian, it produces
an error message:
2024-08-31 13:07:57 dpchrist@laalaa ~
$ echo $PS1 ; cat /etc/debian_version ; uname -a
\n\D{%Y-%m-%d %H:%M:%S} ${USER}@\h \w\n\$
11.10
Linux laalaa 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10)
x86_64 GNU/Linux
2024-08-31 13:17:14 dpchrist@laalaa ~
$ debian ... amd64-netinst.iso
bash: debian: command not found
On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:
On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
# cp debian.iso /dev/sdX
The disadvantage of this method is how to check the USB has a good copy.
Cheers,
David.
.
The disadvantage of this method is how to check the USB has a good copy.
Why should that be difficult? Just do a sha### sum on the device itself.
On Sat, Aug 31, 2024 at 11:15 PM David Christensen wrote:
On 8/30/24 20:48, John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
When I input that string into a computer running Debian, it produces an
error message:
2024-08-31 13:07:57 dpchrist@laalaa ~
$ echo $PS1 ; cat /etc/debian_version ; uname -a
\n\D{%Y-%m-%d %H:%M:%S} ${USER}@\h \w\n\$
11.10
Linux laalaa 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10)
x86_64 GNU/Linux
2024-08-31 13:17:14 dpchrist@laalaa ~
$ debian ... amd64-netinst.iso
bash: debian: command not found
The iso file is not a command that you run on a Debian system.
If you have
cd'd to the present working directory that the iso is located in you still have to use "./" ./ tells the OS that the file is located in the present working directory pwd.
On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
# cp debian.iso /dev/sdX
I plug in a USB stick (which will get completely overwritten),
check from the logs what its device name is (/dev/sdX),
then, as root, execute:
# dd bs=1M if=debian…amd64-netinst.iso of=/dev/sdX
# sync
and wait for the prompt after the sync command.
My recommendation is to add "oflag=sync status=progress" to that "dd"
command above.
Having bothched some sticks with the above method (that "sync" can take
a *long* time with big images).
On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:
On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
# cp debian.iso /dev/sdX
The disadvantage of this method is how to check the USB has a good copy.
On 8/31/24 23:16, Timothy M Butterworth wrote:
On Sat, Aug 31, 2024 at 11:15 PM David Christensen wrote:
On 8/30/24 20:48, John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Yes -- but the command in the given string is "debian", which is not a valid command.
On Sat, Aug 31, 2024 at 09:59:47PM -0500, David Wright wrote:
On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:
On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
# cp debian.iso /dev/sdX
The disadvantage of this method is how to check the USB has a good copy.
I don't understand why it would be any harder or easier to check that
there's a good copy with cp vs some other tool, so this seems like
strange advice.
So your command line would read …
# … …
Cheers,
David.
So your command line would read …
# … …
I believe, instead of using dd for copying to the usb-stick, one might want to
use dcfldd for it.
dcfldd is en enhanced version of dd with hashsum check during copy. It was created for forensic matters, where no data may have gone lost.
On Sun 01 Sep 2024 at 17:20:41 (+0200), Hans wrote:
So your command line would read …
# … …
I believe, instead of using dd for copying to the usb-stick, one might want to
use dcfldd for it.
dcfldd is en enhanced version of dd with hashsum check during copy. It was >> created for forensic matters, where no data may have gone lost.
Same response: please write me a command line, but in this case
for writing the stick rather than just checking it.
[...] I'd spin my wheels trying to
figure out what's wrong and not too much later say f*kkit and boot off
my just written USB drive.
[...]
$ check_debian_iso SHA512SUMS debian-12.7.0-amd64-netinst.iso /dev/sdb
...
661651456 bytes (662 MB, 631 MiB) copied, 7.11874 s, 92.9 MB/s
MISMATCH: '/dev/sdb' checksum differs from 'debian-12.7.0-amd64-netinst.iso' in 'SHA512SUMS'
[...]
$ check_debian_iso SHA512SUMS debian-12.7.0-amd64-netinst.iso
...
661651456 bytes (662 MB, 631 MiB) copied, 2.65785 s, 249 MB/s
Ok: 'debian-12.7.0-amd64-netinst.iso' matches 'debian-12.7.0-amd64-netinst.iso' in 'SHA512SUMS'
On Sun, Sep 01, 2024 at 01:19:45 -0700, David Christensen wrote:
On 8/31/24 23:16, Timothy M Butterworth wrote:
On Sat, Aug 31, 2024 at 11:15 PM David Christensen wrote:
On 8/30/24 20:48, John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Yes -- but the command in the given string is "debian", which is not a valid >> command.
Stop being so blindly literal. It's pretty obvious to *most* of us
that John was referring to an .iso file, presumably one that he had downloaded, and now was asking what to do with.
So many of the replies in this thread have been disappointing.
The best reply would be to point John to the Debian Installation Guide: <https://www.debian.org/releases/bookworm/amd64/>
Specifically, Chapter 4, "Obtaining System Installation Media": <https://www.debian.org/releases/bookworm/amd64/ch04.en.html>
This tells you what to do with the .iso file, if you're already on a
Linux system with appropriate hardware. It also links to the Debian CD
FAQ, which contains hints on what to do on non-Linux systems.
Thomas, are you intentionally linking raw man page instead of a
formatted > one [[DebianMan:xorriso-dd-target|xorriso-dd-target(1)]]?
Is there a reason why the page is not cross-linked with <https://wiki.debian.org/DebianInstaller/CreateUSBMedia>?
From my point of view this kind of pages should have links to the
Debian install manual and to the Debian CD FAQ in either
"Debian official" block or at least in the "See also" section".
Oops.. I wrote to the stick using the Cygwin cp on an MS-Windows
machine, so I'm guessing the damage was done even before ejecting the
stick.
But I'm more interested in what went wrong than exactly where
the write/verification failed.
so yeah, the obvious conclusion is that "what went wrong" is that I
used a Windows machine. *sigh*
As a very low priority, how was I able to install Debian on my laptop
and have everything work when I did the exact same thing for my
laptop?
https://wiki.debian.org/XorrisoDdTarget
Is there a reason why the page is not cross-linked with <https://wiki.debian.org/DebianInstaller/CreateUSBMedia>?
- It does not mention that superuser powers are needed for copying
to /dev/sdX and that a wrong substitute for X can spoil a big
spinning disk if present.
From my point of view this kind of pages should have links to the Debian install manual and to the Debian CD FAQ
Maybe you might want to add a suggestion for readers, which might be the
best way, to get an ISO to an usb-stick?
The debian manual suggests using the "dd" command and claims, not to use Rufus, as it might not work.
I myself made good eperiences with dcfldd instead of using dd.
As these are large files (greater than 25GB),
the danger, something gets lost during copy, is high.
A little side effect of this was, that some manufacturers obviously do not like ext2/3/4 format (to which the usb-stick were reformatted). After about 10th to 15th time of reformate, they died (memory segments got lost).
Hi,
i added a new section
https://wiki.debian.org/XorrisoDdTarget#How_to_verify_the_result
instead of a mere link because i deem the Debian instructions too
scattered for being suitable for already puzzled and stressed users.
I would appreciate checkreading of this new section by interested
bystanders.
Have a nice day :)
Thomas
That's the actual topic of that wiki page.
Just scroll up and read it from start.
The debian manual suggests using the "dd" command and claims, not to use Rufus, as it might not work.
How often do you experience bad copy runs ?
A good USB stick's firmware will care for wear leveling, so that
frequently overwritten logical blocks get written to different physical blocks.
https://en.wikipedia.org/wiki/Wear_leveling
Have a nice day :)
Thomas
I've had some thumb drives die and that might be the cause. Have you noticed any patterns?
--
Your pretended fear lest error might step in is like the man who
would keep all wine out of the country lest men should be drunk.
-- Oliver Cromwell
A little side effect of this was, that some manufacturers obviously do not like ext2/3/4 format (to which the usb-stick were reformatted). After about 10th to 15th time of reformate, they died (memory segments got lost). Others I
already during years are reformatted about 50 times or more and are still in best health.
What I meant is more a desciption,
why xorriso-dd-target is better than dd or dcfldd.
The last times I would say, every 2nd or 3rd run I got copy errors. Thisis because the stick itself. I had several from the same manufacturer, all failed> after a while. [...] All sticks were 16GB and newly bought. (say: about 1
year old)
Hardware issue in the bootloader.
Guess, the reformat is not intended for it. But this is crystal
clear: usb-sticks are made for Windows , for Windows and only for Windows.
On Sat, Aug 31, 2024 at 09:59:47PM -0500, David Wright wrote:
On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:I don't understand why it would be any harder or easier to check that
On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
# cp debian.iso /dev/sdX
The disadvantage of this method is how to check the USB has a good copy. >>
there's a good copy with cp vs some other tool, so this seems like
strange advice.
So your command line would read …
That sounds like really bad hardware. Mind to share manufacturer name
and model name ?
(I have a 2 GB Intenso model "USB", a 4 GB SanDisk Cruzer,
a 8 GB Corsair Flash Voyager, and a 128 GB Intenso Ultra Line.
They all are more than 5 years old. I use them rarely, except for the Corsair, which has a sturdy rubber coating and serves me as encrypted
pocket backup medium.)
So your command line would read …
# … …
Cheers,
David.
I believe, instead of using dd for copying to the usb-stick, one might want to >use dcfldd for it.
dcfldd is en enhanced version of dd with hashsum check during copy. It was >created for forensic matters, where no data may have gone lost.
I have always treated the *nix equivalent to "eject", for the purpose of
a USB flash drive, as being 'umount /path/to/mount/location' - which, if
I'm not mistaken, does include an implicit sync operation.
On Mon, Sep 2, 2024 at 5:25 AM Thomas Schmitt wrote:
Hi,
Lee wrote:
Oops.. I wrote to the stick using the Cygwin cp on an
MS-Windows machine, so I'm guessing the damage was done even
before ejecting the stick.
MS-Windows can eject a stick ?
xorriso silently fails to do so:
xorriso -outdev stdio:/dev/sdc -eject out
(Sorry i could not refrain from this nonsense :))
but it isn't nonsense. Welcome to the world of Windowz, where one
'ejects' a USB stick and then gets a pop-up saying something about
safe to remove the hardware now.
Maybe there's a command to unmount / sync / whatever a USB stick but
I've always used Windows Explorer and the only option for what to do
before unplugging a USB stick is to eject it.
On Mon, Sep 02, 2024 at 01:11:24PM -0400, The Wanderer wrote:
I have always treated the *nix equivalent to "eject", for the purpose of
a USB flash drive, as being 'umount /path/to/mount/location' - which, if I'm not mistaken, does include an implicit sync operation.
Yes. Windows actually does have an option to eliminate the eject step by performing all writes synchronously (I think it may even be the default in current versions) but it makes working with removable media painfully slow. Linux has a similar option (mount with the "sync" option) but it is
generally not used because of the really significant performance impact, and because it can cause much faster wear on flash devices (because there is no opportunity to coalesece small writes into larger writes).
I have always treated the *nix equivalent to "eject", for the purpose of
a USB flash drive, as being 'umount /path/to/mount/location' - which, if
I'm not mistaken, does include an implicit sync operation.
What you wrote in that section it's so searched/wanted by newcomers that it's a pity that it's published as a section into "XorrisoDdTarget".
consider to move that to a new wiki page with a title that
sounds like: "Verify authenticity of a Debian downloaded ISO image".
On Sun, Sep 01, 2024 at 09:58:22AM -0500, David Wright wrote:
On Sat, Aug 31, 2024 at 09:59:47PM -0500, David Wright wrote:
On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:
On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
What does a "debian ... amd64-netinst.iso" do
with an .iso?
Can it be coverted to a USB. How?
https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
# cp debian.iso /dev/sdX
The disadvantage of this method is how to check the USB has a good copy.
I don't understand why it would be any harder or easier to check that there's a good copy with cp vs some other tool, so this seems like strange advice.
So your command line would read …
What are you even going on about?
Well, I might expect you to use a command something like:^^^^^^^^^^^^^^^^
# dd bs=1M if=/dev/sdX of=/dev/stdout count=N | sha512sum
Do not try to cover everything exhaustively from the beginning. Just move
the section from XorrisoDdTarget as a starting point.
I think, <https://www.debian.org/doc/>, <https://www.debian.org/CD>,
and wiki articles should have mutual cross-links and wiki pages should
be most detailed documents.
The commandline I use it's:
~$ sha512sum --ignore-missing -c SHA512SUMS
no need to use "grep", since the "sha512sum" command looks for in the
current working directory the files listed in SHA512SUMS and it calculates the checksum automatically.
Is it really necessary to verify the data written on the device?
Wouldn't it be better to focuses on verify correctness and authenticity
of a downloaded ISO? Wouldn't that be enough? In which circumstances is
it necessary?
Do you mean something like <https://wiki.debian.org/EnvironmentVariables#Quick_guide>?
* Item
{{{
code
}}}
until a decision is made at debian-cd.
Please, drop a note here in the case of some progress.
On Wed, 4 Sept 2024 at 11:03, Max Nikulin <manikulin@gmail.com> wrote:
On 04/09/2024 15:17, Thomas Schmitt wrote:
In /tmp/check_debian_iso line 153:
sum_from_file=`dd if=$file bs=2048 count=$blocks | $checksummer | head
-1 | awk '{print $1}'`
^---^ SC2086 (info): Double quote to prevent
globbing and word splitting.
Hi, that particular SC2086 warning can be ignored because the
$1 that it is mistakenly complaining about is awk syntax, and the
shell will not touch that because it is inside single-quotes.
Whether and whether any of $file, $blocks, $checksummer
need to be double quoted is a matter of preference, if their
contents is known to not contain whitespace or globbing
characters.
"shellcheck -e SC2006" (to silence complains concerning ``) suggests double quotes around "$file"
sum_from_file=`dd if=$file bs=2048 count=$blocks | $checksummer | head -1 | awk '{print $1}'`
I was testing the procedure in a virtual machine, the first "gpg --keyserver keyring.debian.org ..." command fails because I hadn't imported the public keys.
Before you begin, if you haven't already done, you must import the Debian public keys. You can download the keys from the authenticity verification page: https://www.debian.org/CD/verify once done, then imports the keys with the command:
gpg --import key-988021A964E6EA7D.txt key-DA87E80D6294BE9B.txt key-42468F4009EA8AC3.txt
On Mon, Sep 02, 2024 at 01:49:03PM -0400, Michael Stone wrote:
On Mon, Sep 02, 2024 at 01:11:24PM -0400, The Wanderer wrote:
I have always treated the *nix equivalent to "eject", for the purpose of >> > a USB flash drive, as being 'umount /path/to/mount/location' - which, if >> > I'm not mistaken, does include an implicit sync operation.
Yes. Windows actually does have an option to eliminate the eject step by
performing all writes synchronously (I think it may even be the default in >> current versions) but it makes working with removable media painfully slow. >> Linux has a similar option (mount with the "sync" option) but it is
generally not used because of the really significant performance impact, and >> because it can cause much faster wear on flash devices (because there is no >> opportunity to coalesece small writes into larger writes).
This is exactly why I'm always trying to "sell" the "oflag=sync" option of >dd. You are going to write each block exactly once, then plop the medium
out. So whithout, it'll take you 10 sec, with it'll take you as much. But >it's more transparent with, because without, the OS is flushing cache in
the background.
On Mon, Sep 02, 2024 at 08:30:03PM +0200, tomas@tuxteam.de wrote:
This is exactly why I'm always trying to "sell" the "oflag=sync" option of dd [...]
It's a waste of time but if you make it happy you do you. Please don't
impose it on others.
Hi,
tomas@tuxteam.de wrote:
This is exactly why I'm always trying to "sell" the "oflag=sync" option of dd. You are going to write each block exactly once, then plop the medium out. So whithout, it'll take you 10 sec, with it'll take you as much. But it's more transparent with, because without, the OS is flushing cache in the background.
I let xorriso-dd-target use
bs=1M oflag=dsync
with the dd run which copies the ISO image. Not only to minimize the time
of the final sync command but also to get realistic numbers from
status=progress
which elsewise reports fantastic write speeds in the beginning and then
looks quite erratic when the kernel decides to write data to the USB stick before buffering more of the data sent by dd.
What i experienced as puzzling in the documentation was the difference between oflag=dsync and oflag=sync (not to be confused with conv=sync).
The info document of dd is more verbous than the man page but still not really helpful in this aspect:
‘dsync’
Use synchronized I/O for data [...]
‘sync’
Use synchronized I/O for both data and metadata.
When writing to a device file, neither its length nor timestamp are of importance for the resulting state of the USB stick [...]
change during writing and the timestamp vanishes with the device file
when the stick gets unplugged.
Nevertheless i add a standalone sync command to the last dd run of xorriso-dd-target, just to care for any other remaining buffered data
e.g. from zeroizing the potential GPT backup header at the end of the
USB stick.
Michael Stone wrote:
It's a waste of time
My experience with or without bs=1M oflag=dsync is like the sniffles:
They last seven days with a doctor and a week without.
This is exactly why I'm always trying to "sell" the "oflag=sync" option of dd. You are going to write each block exactly once, then plop the medium
out. So whithout, it'll take you 10 sec, with it'll take you as much. But it's more transparent with, because without, the OS is flushing cache in
the background.
It's a waste of time
I let xorriso-dd-target use
bs=1M oflag=dsync
May too small bs value cause write multiplication if internal flash erasure block size is much larger? [...] My concern is wearing,
I've run into this situation (more than once)... `dd` fails to write a bootable image with a block size of 1M. But using a block size of 512
results in a bootable image. It used to happen regularly on arm dev
boards, like BeagleBoards and CubieTrucks and Wandboards.
I don't recall it happening lately.
I have no idea if firmware may perform
partial overwrites without apparent impact on speed.
Are you against "sync" command because it syncs all drives,
From my point of view, simple cp suggested by the install guide
is quite reasonable in comparison to dd.
Another my question is concerning reading of media and -x argument of isosize. Is it really necessary? I can not figure out what corner cases
are not covered by "head -c BYTES /dev/sdc".
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 162:10:54 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,500 |