Re: Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

[David Wright]

On Fri 20 Sep 2024 at 07:53:28 (-0500), Richard Owlett wrote:
> On 09/19/2024 10:04 AM, David Wright wrote:
> > On Thu 19 Sep 2024 at 09:16:25 (-0500), Richard Owlett wrote:
> > > Is the AMD64 version of "Debian GNU/Linux Installation Guide"
> > > available as a single file.
> > > 
> > > I need it available when the network is not.
> > > 
> > > It would be convenient if a copy of the menus appearing when
> > > installing from DVD1 were available.
> > 
> > Have you tried googling:
> > 
> >debian stable installation guide pdf amd64
> > 
> > which should lead you to:
> > 
> >https://www.debian.org/releases/stable/amd64/install.en.pdf
> 
> No ;}
> For two primary  reasons:
> 1. due to vision/perception problems I avoid PDF in favor of HTML.
>SeaMonkey simplifies consistent font size across documents.
> 2. My work style uses tabs to group (and save across restarts)
>related references conveniently.
> 
> Secondarily, for those preferring PDF, in my use of SeaMonkey since
> days of Squeeze I never noticed mention of its documentation being
> available as PDF.

The PDF is ~650kB, but for ~17MB you can get all three formats
(PDF/text/HTML) as one file (in the sense it seems you mean) in
the Debian package installation-guide-amd64.

Using tabs isn't affected by whether the HTML code itself is in
a "single" file or a tree.

> Because I'm doing a "from scratch" install for the first time in
> several years, I said:
> > It would be convenient if a copy of the menus appearing when installing
> > from DVD1 were available.

Sorry, I would have thought you could recite them from memory by now :)

> I recall most of what has to be accomplished but am hazy on some
> details. So I went looking at https://www.debian.org/ from a "newbie"
> point of view. ~Nada:{
> Drilling down leads to https://www.debian.org/do_c/ which first points

FTR remove the "_".

> our possibly non-geek newbie to "Installation Guide" and "Debian
> GNU/Linux FAQ" which, though brimming with facts, are inconveniently
> organized.

Oh dear, I thought that was how the Installation Guide had been
organised since the days of yore.

> *HOWEVER* there is something _NEW_ on the page!
> Who, me, excited ;}
> There is now something called _The Debian Bookworm beginner’s
> handbook_ [
> https://debian-beginners-handbook.tuxfamily.org/index-en.html ].
> For reasons stated above I'll be using the HTML more than the PDF.
> 
> This resource should be linked to on https://www.debian.org/ or at
> most down only one level.

I don't think it makes sense to promote this above the two you've
already mentioned.

> I addresses some of my questions, though it only mentions others.
> I'll be doing a lot of reading this weekend.

If you like it. I prefer the detail of the other two, and it now
sounds as if you might.

> One question. There are two HTML versions. What's difference between
> the_beginners_handbook.html and the_beginners_handbook_night.html ?

It should be as clear as night and day from the very start of each,
but:

  $ diff -U0 the*/the* > diff (attached)

Cheers,
David.
--- the_beginners_handbook/the_beginners_handbook.html  2024-08-30 
11:57:09.0 -0500
+++ the_beginners_handbook/the_beginners_handbook_night.html2024-08-30 
11:57:09.0 -0500
@@ -15 +15 @@
-background-color: #fafafa;
+background-color: #2F343F;
@@ -22 +22 @@
-color: #222;
+color: #D4D4D4;
@@ -28 +28 @@
-color: #005885;
+color: #0077B4;
@@ -33 +33 @@
-border-bottom: 1px dotted #005885;
+border-bottom: 1px dotted #0077B4;
@@ -61 +61 @@
-figure img {box-shadow: 0 0 3px 1px rgba(0, 0, 0, .2);}
+figure img {box-shadow: 0 0 3px 1px rgba(255, 255, 255, .2);}
@@ -92,3 +92,3 @@
-color: #111;
-background-color: #f4fbff;
-border: 1px solid #333;
+color: #ccc;
+background-color: #000;
+border: 1px solid #ccc;
@@ -105 +105,2 @@
-background-color: #eee;
+border: 1px solid #ccc;
+background-color: #222;
@@ -147 +148 @@
-
+

Re: Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

[Richard Owlett]

On 09/19/2024 10:04 AM, David Wright wrote:

On Thu 19 Sep 2024 at 09:16:25 (-0500), Richard Owlett wrote:

Is the AMD64 version of "Debian GNU/Linux Installation Guide"
available as a single file.

I need it available when the network is not.

It would be convenient if a copy of the menus appearing when
installing from DVD1 were available.


Have you tried googling:

   debian stable installation guide pdf amd64

which should lead you to:

   https://www.debian.org/releases/stable/amd64/install.en.pdf

Cheers,
David.



No ;}
For two primary  reasons:
1. due to vision/perception problems I avoid PDF in favor of HTML.
   SeaMonkey simplifies consistent font size across documents.
2. My work style uses tabs to group (and save across restarts)
   related references conveniently.

Secondarily, for those preferring PDF, in my use of SeaMonkey since days 
of Squeeze I never noticed mention of its documentation being available 
as PDF.


Because I'm doing a "from scratch" install for the first time in several 
years, I said:

It would be convenient if a copy of the menus appearing when installing
from DVD1 were available. 


I recall most of what has to be accomplished but am hazy on some 
details. So I went looking at https://www.debian.org/ from a "newbie" 
point of view. ~Nada:{
Drilling down leads to https://www.debian.org/do_c/ which first points 
our possibly non-geek newbie to "Installation Guide" and "Debian 
GNU/Linux FAQ" which, though brimming with facts, are inconveniently 
organized.


*HOWEVER* there is something _NEW_ on the page!
Who, me, excited ;}
There is now something called _The Debian Bookworm beginner’s handbook_ 
[ https://debian-beginners-handbook.tuxfamily.org/index-en.html ].

For reasons stated above I'll be using the HTML more than the PDF.

This resource should be linked to on https://www.debian.org/ or at most 
down only one level.


I addresses some of my questions, though it only mentions others.
I'll be doing a lot of reading this weekend.

One question. There are two HTML versions. What's difference between
the_beginners_handbook.html and the_beginners_handbook_night.html ?

Re: Brightness Control Hotkeys not working on Debian 12, Lenovo IdeaPad3

[Jörg-Volker Peetz]

First thing is to check if any events are produced by the keys in question.
Try the 'xev' program from package 'x11-utils'.

Regards,
Jörg.

Brightness Control Hotkeys not working on Debian 12, Lenovo IdeaPad3

[John Kerr Anderson]

Dear Debian Users:

I recently got a Lenovo IdeaPad3 with an Intel i5 1135G7 CPU with Iris XE
graphics.  I can adjust the screen brightness by manually sliding the
controls in the quick settings at the top of the screen, but the hotkeys on
the keyboard do not work to adjust the screen brightness.  The hotkeys do
work for adjusting audio, airplane mode, locking the screen and turning the
touchpad on or off.

Any easy way to get the brightness controls to work?

Here's the output from: inxi -SGMz

System:
  Kernel: 6.1.0-25-amd64 arch: x86_64 bits: 64 Desktop: GNOME v: 43.9
Distro: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Laptop System: LENOVO product: 81X7 v: IdeaPad 3 14ITL05
serial: 
  Mobo: LENOVO model: LNVNB161216 v: SDK0T76465 WIN
serial:  UEFI: LENOVO v: GCCN30WW date: 08/05/2022
Graphics:
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
  Device-2: Luxvisions Innotech Integrated Camera type: USB driver: uvcvideo
  Display: wayland server: X.Org v: 1.22.1.9 with: Xwayland v: 22.1.9
compositor: gnome-shell driver: dri: iris gpu: i915
resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel Xe Graphics (TGL GT2)

Thank you in advance and I wish you all a great day.

Regards,

John Anderson

Re: Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

[David Wright]

On Thu 19 Sep 2024 at 09:16:25 (-0500), Richard Owlett wrote:
> Is the AMD64 version of "Debian GNU/Linux Installation Guide"
> available as a single file.
> 
> I need it available when the network is not.
> 
> It would be convenient if a copy of the menus appearing when
> installing from DVD1 were available.

Have you tried googling:

  debian stable installation guide pdf amd64

which should lead you to:

  https://www.debian.org/releases/stable/amd64/install.en.pdf

Cheers,
David.

Re: Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

[DdB]

Am 19.09.2024 um 16:16 schrieb Richard Owlett:
> Is the AMD64 version of "Debian GNU/Linux Installation Guide" available
> as a single file
How about doing your homework?

> perplexity.ai:
> 
> Is the AMD64 version of "Debian GNU/Linux Installation Guide" available as a 
> single file?
> (...)
> 
> Yes, the AMD64 version of the "Debian GNU/Linux Installation Guide" is 
> available as a single PDF file. The search results indicate that the 
> installation guide for the 64-bit PC ("amd64") architecture can be found at 
> the following URL: 
> https://www.debian.org/releases/stable/amd64/install.en.pdf[2] This PDF 
> contains the complete installation instructions for Debian GNU/Linux on the 
> amd64 architecture, including information on hardware requirements, 
> partitioning, package installation, and post-installation configuration. The 
> guide is comprehensive and provides a step-by-step walkthrough for installing 
> Debian on 64-bit PCs.

Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

[Richard Owlett]

Is the AMD64 version of "Debian GNU/Linux Installation Guide" available 
as a single file.


I need it available when the network is not.

It would be convenient if a copy of the menus appearing when installing 
from DVD1 were available.


TIA

Re: Really ancient debian images? (potato or older)

[David Wright]

On Sun 15 Sep 2024 at 12:08:29 (+0200), Anders Andersson wrote:
> On Sun, Sep 15, 2024 at 7:59 AM  wrote:
> > On Sat, Sep 14, 2024 at 10:27:01PM +0200, Christian Groessler wrote:
> >
> > [...]
> >
> > > Now for the main question: Why do you need ancient Debian?
> >
> > Was in the original post: "This is to build some ancient software."
> >
> > (I've been in a similar situation myself)
> 
> Just have to add a "me too". Often a piece of software that hasn't
> been maintained for 20 years or so fails to compile, or the support
> scripts are using tools no longer available etc. It's way easier to
> FIRST make it work on the environment it was designed for, and then
> gradually fix whatever prevents it from being built with modern tools.
> 
> I feel that this is one of the key strengths using free software.
> While you can probably easily find old CDs with Windows 2000, and MAY
> find old CDs with the popular development tools at the time, it may be
> very difficult getting it to run legally (if you care) and just pray
> that you don't need a non-existing dongle.

Or that you have the dongle, but now have to find a parallel port
to plug it into.

> I'm very happy that debian offers even really ancient versions.

Cheers,
David.

Re: Really ancient debian images? (potato or older)

[Anders Andersson]

On Sun, Sep 15, 2024 at 7:59 AM  wrote:
>
> On Sat, Sep 14, 2024 at 10:27:01PM +0200, Christian Groessler wrote:
>
> [...]
>
> > Now for the main question: Why do you need ancient Debian?
>
> Was in the original post: "This is to build some ancient software."
>
> (I've been in a similar situation myself)

Just have to add a "me too". Often a piece of software that hasn't
been maintained for 20 years or so fails to compile, or the support
scripts are using tools no longer available etc. It's way easier to
FIRST make it work on the environment it was designed for, and then
gradually fix whatever prevents it from being built with modern tools.

I feel that this is one of the key strengths using free software.
While you can probably easily find old CDs with Windows 2000, and MAY
find old CDs with the popular development tools at the time, it may be
very difficult getting it to run legally (if you care) and just pray
that you don't need a non-existing dongle.

I'm very happy that debian offers even really ancient versions.

Re: Really ancient debian images? (potato or older)

[tomas]

On Sat, Sep 14, 2024 at 10:27:01PM +0200, Christian Groessler wrote:

[...]

> Now for the main question: Why do you need ancient Debian?

Was in the original post: "This is to build some ancient software."

(I've been in a similar situation myself)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Really ancient debian images? (potato or older)

[Christian Groessler]

Hi Tim,

On 9/14/24 6:32 PM, Tim Woodall wrote:

On Sat, 14 Sep 2024, Michael Kjörling wrote:


On 14 Sep 2024 16:15 +0100, from debianu...@woodall.me.uk (Tim Woodall):
Is there anywhere I can download really, really ancient debian 
images. I

need potato or older (i386). I'd like a mountable disk image.


And, of course, as soon as I sent that I found a potato CD on
archive.org. Downloading now - it's going to take a while - about 20x
faster than it would have been back in the day over dialup but
definitely not a high speed archive :-)


There's also archive.debian.org. See for example
https://archive.debian.org/debian/dists/potato/main/disks- 
i386/2.2.26-2001-06-14/images-1.44/





This is fantastic, thanks all!

And for anyone who might want to do something like this in the future,
the only file I actually needed was:

https://archive.debian.org/debian/dists/potato/main/disks- 
i386/2.2.26-2001-06-14/base2_2.tgz


I downloaded the CD, mounted it and got it that way but it can be
downloaded directly. I assume the other old things are similar.

I've managed to build versions going all the way back to 1999.



Now for the main question: Why do you need ancient Debian?


best regards,
chris

Re: Really ancient debian images? (potato or older)

[Tim Woodall]

On Sat, 14 Sep 2024, Michael Kjörling wrote:


On 14 Sep 2024 16:15 +0100, from debianu...@woodall.me.uk (Tim Woodall):

Is there anywhere I can download really, really ancient debian images. I
need potato or older (i386). I'd like a mountable disk image.


And, of course, as soon as I sent that I found a potato CD on
archive.org. Downloading now - it's going to take a while - about 20x
faster than it would have been back in the day over dialup but
definitely not a high speed archive :-)


There's also archive.debian.org. See for example
https://archive.debian.org/debian/dists/potato/main/disks-i386/2.2.26-2001-06-14/images-1.44/




This is fantastic, thanks all!

And for anyone who might want to do something like this in the future,
the only file I actually needed was:

https://archive.debian.org/debian/dists/potato/main/disks-i386/2.2.26-2001-06-14/base2_2.tgz

I downloaded the CD, mounted it and got it that way but it can be
downloaded directly. I assume the other old things are similar.

I've managed to build versions going all the way back to 1999.

Re: Really ancient debian images? (potato or older)

[Tim Woodall]

On Sat, 14 Sep 2024, Tom Furie wrote:


On Sat, Sep 14, 2024 at 04:15:46PM +0100, Tim Woodall wrote:


The oldest backups I still have go back to 2006 which, sadly, is way too
modern. Checking the potato release information says security updates
were discontinued in 2003. I switched from Redhat to Debian around that
time so I'm likely not to have had any backups for potato anyway
although I did at least boot it at that time.


And, of course, as soon as I sent that I found a potato CD on
archive.org. Downloading now - it's going to take a while - about 20x
faster than it would have been back in the day over dialup but
definitely not a high speed archive :-)


https://cdimage.debian.org/mirror/cdimage/ has images going all the way back
to 1.3. Prior to 3.0 is in the "older-contrib" directory.



Thanks! I didn't see that "older-contrib" directory and I assumed they'd
been deleted.

That's downloading much, much faster than archive.org.

Tim.

Re: Really ancient debian images? (potato or older)

[Michael Kjörling]

On 14 Sep 2024 16:15 +0100, from debianu...@woodall.me.uk (Tim Woodall):
>> Is there anywhere I can download really, really ancient debian images. I
>> need potato or older (i386). I'd like a mountable disk image.
> 
> And, of course, as soon as I sent that I found a potato CD on
> archive.org. Downloading now - it's going to take a while - about 20x
> faster than it would have been back in the day over dialup but
> definitely not a high speed archive :-)

There's also archive.debian.org. See for example
https://archive.debian.org/debian/dists/potato/main/disks-i386/2.2.26-2001-06-14/images-1.44/

-- 
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Really ancient debian images? (potato or older)

[Tom Furie]

On Sat, Sep 14, 2024 at 04:15:46PM +0100, Tim Woodall wrote:

> > The oldest backups I still have go back to 2006 which, sadly, is way too
> > modern. Checking the potato release information says security updates
> > were discontinued in 2003. I switched from Redhat to Debian around that
> > time so I'm likely not to have had any backups for potato anyway
> > although I did at least boot it at that time.
> 
> And, of course, as soon as I sent that I found a potato CD on
> archive.org. Downloading now - it's going to take a while - about 20x
> faster than it would have been back in the day over dialup but
> definitely not a high speed archive :-)

https://cdimage.debian.org/mirror/cdimage/ has images going all the way back
to 1.3. Prior to 3.0 is in the "older-contrib" directory.

Cheers,
Tom

-- 
Sometimes I worry about being a success in a mediocre world.
-- Lily Tomlin


signature.asc
Description: PGP signature

Re: Really ancient debian images? (potato or older)

[Tim Woodall]

On Sat, 14 Sep 2024, Tim Woodall wrote:


Is there anywhere I can download really, really ancient debian images. I
need potato or older (i386). I'd like a mountable disk image.

I have no idea if debootstrap supports this, I haven't tried (yet), I
was hoping there was somewhere I could download an image.

This is to build some ancient software. I've tried Jessie, which is the
oldest release I have images for but unfortunately that has e2fslibs-dev
1.42 while the software will not build with e2fslibs >1.19.

The oldest backups I still have go back to 2006 which, sadly, is way too
modern. Checking the potato release information says security updates
were discontinued in 2003. I switched from Redhat to Debian around that
time so I'm likely not to have had any backups for potato anyway
although I did at least boot it at that time.



And, of course, as soon as I sent that I found a potato CD on
archive.org. Downloading now - it's going to take a while - about 20x
faster than it would have been back in the day over dialup but
definitely not a high speed archive :-)

Really ancient debian images? (potato or older)

[Tim Woodall]

Is there anywhere I can download really, really ancient debian images. I
need potato or older (i386). I'd like a mountable disk image.

I have no idea if debootstrap supports this, I haven't tried (yet), I
was hoping there was somewhere I could download an image.

This is to build some ancient software. I've tried Jessie, which is the
oldest release I have images for but unfortunately that has e2fslibs-dev
1.42 while the software will not build with e2fslibs >1.19.

The oldest backups I still have go back to 2006 which, sadly, is way too
modern. Checking the potato release information says security updates
were discontinued in 2003. I switched from Redhat to Debian around that
time so I'm likely not to have had any backups for potato anyway
although I did at least boot it at that time.

Tim.

Printer recommendations for Debian (was: Just a simple question)

[Stefan Monnier]

> I am great friend of "Brother" printers. They are cheap and reliable and they 
> are well supported  by linux. Brother is offering deb packages for installing 
> or a linu script, which is downloading and installing these packages 
> automatically.

Of course, that means you're at the mercy of Brother providing the
drivers which work for your printer&computer and those deb packages
typically aren't as nicely integrated into your Debian system as if
they'd been packaged by Debian.

E.g. do they provide armhf builds?  Are they for Ubuntu?  Debian?
Stable?  Testing?  Sid?  Oldstable?  Do they risk messing up other parts
of your config?  Can you determine that they can't send confidential
info back to Brother or act as puppets after they've been hacked
because of an undisclosed security hole somewhere?

If the drivers (print&scan) are not distributed in Debian's main
archive, I can't recommend it.

> Before you buy: Be sure, the manufacturer is sopporting linux.

Where "supporting" means that it provides code as Free Software, so it
can be adapted to any other OS and architecture you like.

Luckily, nowadays most printers support the standard APIs for
"driverless" printing and scanning, so the nasty proprietary code is
confined to the actual printer, but you might still prefer to put that
printer on a separate non-routed subnetwork so *you* control it rather
than the manufacturer.


Stefan

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 06/09/2024 14:53, Thomas Schmitt wrote:

i wrote:

I let xorriso-dd-target use
bs=1M oflag=dsync


Max Nikulin wrote:

May too small bs value cause write multiplication if internal flash erasure
block size is much larger? [...] My concern is wearing,


Is there evidence that sync size a smaller than such an internal size
is harmful ?


It is no more than my guess. My expectation that some flash firmware may 
respect explicit syncs.



Sequential writing by dd would well fit into such a caching strategy.


...unless explicit syncs force writing received data. Sequential writing 
with frequent syncs should not be an issue (besides some buggy devices) 
if the drive has been fully erased in advance. I am unaware how to erase 
a USB pendrive or a SD card. Perhaps some vendors provide special tools.


My hypothesis is that writing to 8MiB erase block in 1MiB chunks over 
old data may result in

- erasure or next free segment
- write 0 new data, 1-7 old data
- erasure or next free segment
- write 0-1 new data, 2-7 old data
...
- erasure or next free segment
- write 0-6 new data, 7 old data
- erasure or next free segment
- write 0-7 new data
Of course, firmware may react on syncs in a different way.


Max Nikulin wrote:

I have no idea if firmware may perform
partial overwrites without apparent impact on speed.


Is there evidence ?


No.


I know from own experiments that very small sizes like bs=512 cause slow
copying with and without oflag=dsync. Also very large sizes yielded less
throughput than bs=1M. (My sample set of USB sticks used is small.)


I have only a few USB sticks and SD cards as well and I use some of them 
for backup, some are rather old. That is why I asking questions rather 
than making statements.


Are there confirmed cases when dd with fixed bs works faster (or more 
reliable) than cp built-in strategy? Of course, it better to have some 
evidence that dd bs=1M may cause negative impact as well.


Due to my preference to non-destructive way of making bootable media, I 
unlikely will be a source of data points. I noticed that people were 
arguing concerning oflag=sync so I expected that they may provide more info.



 From my point of view, simple cp suggested by the install guide
is quite reasonable in comparison to dd.


cp is not suitable for erasing the last block of the USB stick where the
header of the backup GPT may reside, if the stick was GPT partitioned.


It is a perfectly valid case of dd usage. However I do not expect that 
many users have GPT partition table on USB pendrives, so cp should be 
suitable for the install guide. On the other hand, some may forget about 
their experiments, so the additional measure is suitable for scripts and 
for troubleshooting docs.

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 06/09/2024 14:53, Thomas Schmitt wrote:

Jeff wrote:

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 would be interested in more details (error messages ? no booting ?).


My expectation is that "boot" is not really relevant here. Verification 
of written data should fail. The question if it is an issue with flash 
firmware or with a board where dd was running. Comparison of original 
image and data read back may reveal some pattern of corrupted bytes. 
Another variant that flash firmware could not tell the host to wait till 
a portion of data was actually written.


I would be really surprised if reading resulted in exactly same data, 
attempt to boot from the device failed.

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

i wrote:
> > I let xorriso-dd-target use
> >bs=1M oflag=dsync

Max Nikulin wrote:
> May too small bs value cause write multiplication if internal flash erasure
> block size is much larger? [...] My concern is wearing,

Is there evidence that sync size a smaller than such an internal size
is harmful ?

Writing small chunks would also happen with any scattered writing with
smaller chunks, which would happen when medium sized files get written
here and there in the (FAT) filesystem.
Firmware could try to accumulate data in finer granulated memory as long
as the data would go to the same physical chunk, and only later write
to the coarsly granulated memory.
Sequential writing by dd would well fit into such a caching strategy.


Jeff wrote:
> 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 would be interested in more details (error messages ? no booting ?).

> I don't recall it happening lately.

If it happens again, please report.

If ever, bs=512 would invite for more extra block erasures than bs=1M.


Max Nikulin wrote:
> I have no idea if firmware may perform
> partial overwrites without apparent impact on speed.

Is there evidence ?
I know from own experiments that very small sizes like bs=512 cause slow
copying with and without oflag=dsync. Also very large sizes yielded less
throughput than bs=1M. (My sample set of USB sticks used is small.)


> Are you against "sync" command because it syncs all drives,

I understand dd oflag=sync only applies to the target file or device and
that the difference to oflag=dsync is about metadata of the target file
like its timestamps.

But xorriso-dd-target runs sync(1) in the end. Just to be sure.
(Sorry for any other data which get onto storage device early.)


> From my point of view, simple cp suggested by the install guide
> is quite reasonable in comparison to dd.

cp is not suitable for erasing the last block of the USB stick where the
header of the backup GPT may reside, if the stick was GPT partitioned.
cp does not display pacifier messages and may end substantially earlier
than the write process from kernel to USB stick.


> 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".

If you put emphasis on avoiding dd, then this would be an alternative.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Jeffrey Walton]

On Thu, Sep 5, 2024 at 10:51 PM Max Nikulin  wrote:
>
> On 05/09/2024 16:25, Thomas Schmitt wrote:
> > 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? I have seen claims that it can be
> e.g. 12M
> 
> I have an impression that actual value is not exposed, so it is unknown
> to kernel. My concern is wearing, I have no idea if firmware may perform
> partial overwrites without apparent impact on speed.

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 prefer the larger block size because the image writes faster. But if
the board fails to boot, I drop back to 512 to (re)write the image.

And I always finish the `dd` command with a `&& sync`.

> Are you against "sync" command because it syncs all drives, not the
> specific one (besides smooth progress report)? If USB mass storage
> driver does not allow to turn port power off before write completion
> then it might be a workaround. 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".

Jeff

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 05/09/2024 16:25, Thomas Schmitt wrote:

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? I have seen claims that it can be 
e.g. 12M


I have an impression that actual value is not exposed, so it is unknown 
to kernel. My concern is wearing, 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, not the 
specific one (besides smooth progress report)? If USB mass storage 
driver does not allow to turn port power off before write completion 
then it might be a workaround. 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".

Re: Need advice on a usable, inexpensive laptop for Debian

[Ryan Nowakowski]

On September 4, 2024 5:18:53 PM CDT, "Andrew M.A. Cater"  
wrote:
>On Wed, Sep 04, 2024 at 05:04:33PM -0500, Tom Browder wrote:
>> I'm trying to propose a computer lab for young wannabe coders, and I want
>> to use a Linux box (I prefer Debian, but I get the feeling Ubuntu is more
>> familiar with school systems and other institutions).
>> 
>
>If you're going to set it up from your own money - second hand Lenovo 
>Thinkpads / HP laptops ex-business.

 +1 to this. I've had great luck with used Thinkpads.

Re: Need advice on a usable, inexpensive laptop for Debian

[ael]

On Wed, Sep 04, 2024 at 05:04:33PM -0500, Tom Browder wrote:
> I'm trying to propose a computer lab for young wannabe coders, and I want
> to use a Linux box (I prefer Debian, but I get the feeling Ubuntu is more
> familiar with school systems and other institutions).

You seem to be across the pond, but I suggest that you look at Clevo
machines if you are looking at laptops. These are usually sold under
other names but come without any Windows. You can buy without any
operating system but often are available with the option to pre-install
various linux distributions.

A quick search suggested https://system76.com. There must be many more.
I have not used system76, so can't comment on their offerings.

I am writing this on a Clevo laptop which has been reliable and fast,
purchased in the UK with no operating system. It was very good value.

ael

Re: Usage: "debian ... amd64-netinst.iso"

[tomas]

On Thu, Sep 05, 2024 at 11:25:33AM +0200, Thomas Schmitt wrote:
> Hi,
> 
> to...@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 [...]

That was my take, too: in the "USB stick" case, there's practically no
difference. And when writing to a file, I'll happily take the hit of
updating the metadata too for consistent results.

So I decided to burden my dwindling memory with one letter less :-)

> 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.

You know far more about those innards than I can hope too :-)

> 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.

The sticks I've used (and the CPU and what not) are *much* faster with
bs=1M than with the default (512, with bs). The oflag=sync is more about
predictability, as you write above.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

to...@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.  For the output file, this
   forces a physical write of output data on each write.  For the
   input file, this flag can matter when reading from a remote
   file that has been written to synchronously by some other
   process.  Metadata (e.g., last-access and last-modified time)
   is not necessarily synchronized.

  ‘sync’
   Use synchronized I/O for both data and metadata.

I understand from
  https://sources.debian.org/src/coreutils/9.4-3.1/src/dd.c
and
  https://sources.debian.org/src/coreutils/9.4-3.1/lib/fd-reopen.c
that the difference is the one between open(2) flags O_SYNC and O_DSYNC.
man 2 open says:

  To understand the difference between the two types of completion,  con‐
  sider two pieces of file metadata: the file last modification timestamp
  (st_mtime) and the file length.  All write operations will  update  the
  last  file modification timestamp, but only writes that add data to the
  end of the file will change the file  length.   The  last  modification
  timestamp  is  not needed to ensure that a read completes successfully,
  but the file length is.  Thus, O_DSYNC would only  guarantee  to  flush
  updates  to  the file length metadata (whereas O_SYNC would also always
  flush the last modification timestamp metadata).

When writing to a device file, neither its length nor timestamp are of
importance for the resulting state of the USB stick. Length does not
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.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[tomas]

On Wed, Sep 04, 2024 at 08:31:09PM -0400, Michael Stone wrote:
> On Mon, Sep 02, 2024 at 08:30:03PM +0200, to...@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.

That's a strange thing to say.

I don't have any power to impose oflag=sync on anyone (and if I had, I wouldn't
use it for such a thing: why should I?)

BTW, my reason for using it is not that it's a "waste of time" otherwise, but
rather that waiting on an (unpredictable) sync to finish feels less comfy than
to have a rough idea of how long it'll take (thanks to status=progress).

Cheers
-- 
t 


signature.asc
Description: PGP signature

Re: Need advice on a usable, inexpensive laptop for Debian

[tomas]

On Thu, Sep 05, 2024 at 06:30:25AM +0200, to...@tuxteam.de wrote:

[...]

> Currently I buy them at a brick-and-mortar store in my city [...]

And, oh, by default they come empty or with pre-installed Ubuntu. You
can order them with Windows, but this costs extra (as it should be).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Need advice on a usable, inexpensive laptop for Debian

[tomas]

On Wed, Sep 04, 2024 at 10:18:53PM +, Andrew M.A. Cater wrote:
> On Wed, Sep 04, 2024 at 05:04:33PM -0500, Tom Browder wrote:
> > I'm trying to propose a computer lab for young wannabe coders, and I want
> > to use a Linux box (I prefer Debian, but I get the feeling Ubuntu is more
> > familiar with school systems and other institutions).
> > 
> 
> If you're going to set it up from your own money - second hand Lenovo 
> Thinkpads / HP laptops ex-business.

I second that. Linux-only since... uh... 1995 or something. Second-hand
thinkpads (with two exceptions: one eee-PC (was good, for the time) and
one Lenovo Ideapad (not so good, but my employer insisted), both new.

Currently I buy them at a brick-and-mortar store in my city specialised
in refurbished gear. Some markup wrt technofeudalist stores, but friendly
folks who know what they're doing, so worth my support every cent.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 03/09/2024 00:11, The Wanderer wrote:

On 2024-09-02 at 12:51, Lee wrote:

On Mon, Sep 2, 2024 at 5:25 AM Thomas Schmitt wrote:


MS-Windows can eject a stick ?

[...]

(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.

[...]

My understanding is that when you tell Windows to "eject" removable
media, it does whatever is necessary to prepare that media for clean
removal.


GNOME uses "eject" as well:

So users should be familiar with the word in this particular context.


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.


Dolphin (KDE) "Safely remove" additionally switches off power on the USB 
port. In the case of CLI it is


udisksctl power-off -b /dev/sdb

(or uhubctl, direct writing to /sys/bus/usb/devices/**/power, etc.)

I find it a reasonable measure in the case of a spinning external HDD to 
ensure that it is stopped. Another rule is to unplug it from the laptop 
USB port at first (without touching HDD) and only then detach the cable 
from the HDD case.

Re: Usage: "debian ... amd64-netinst.iso"

[Michael Stone]

On Mon, Sep 02, 2024 at 08:30:03PM +0200, to...@tuxteam.de wrote:

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.


It's a waste of time but if you make it happy you do you. Please don't 
impose it on others.

Re: Need advice on a usable, inexpensive laptop for Debian

[Russell L. Harris]

For inexpensive, low-mileage, office-quality machines (laptop &
desktop) try blairtech.com.

You'll get a W10 or W11 machine.

Re: Need advice on a usable, inexpensive laptop for Debian

[Tom Browder]

On Wed, Sep 4, 2024 at 17:47 Charles Curley
...

What did you replace the H&R Block program with?


Free TaxUSA, recommended by my lawyer son. it's free, but I paid extra
(still less that H&R) for some extra features. It worked great for 2023, I
will use it again for 2024.

Note I've been audited twice by the IRS, so I'm pretty reliant on a good
tax program. I tried going with a CPA once, but he had more forms for me to
fill out than the tax programs, and wanted a large fee besides.

Thanks, all respondents, for good advice on my laptop quest.

-Tom

Re: Need advice on a usable, inexpensive laptop for Debian

[Eike Lantzsch ZP5CGE / KY4PZ]

On Wednesday, 4 September 2024 18:47:25 -04 Charles Curley wrote:
> On Wed, 4 Sep 2024 17:04:33 -0500
>
> Tom Browder  wrote:
> > I am torn with whether dual boot is the way to go, given all the
> > problems I see with dual boot with Windows now. (I finally dumped
> > Windows entirely some months ago when I found a decent, modern
> > replacement for Microsoft Word and for the H&R Block US Federal tax
> > program).
>
> I've never had a problem with dual booting both Windows and Linux, and
> I started doing that in the 1990s. Install Windows first. It will hog
> the entire drive, so the next step is to shrink its partition to
> something reasonable. The Windows rescue partition is usually at the
> end of the disk; you can leave it there. Then install Linux on the
> newly freed up space.
>
> I find a 256GB SSD suitable for me; for your purpose a 128 GB drive
> should do it.
>
> What did you replace the H&R Block program with?

Hi Tom,
I shy away from HP Laptops since the time they still were COMPAQs. I
once was given a HP Laptop for free and it is only doing its job now as
an OpenBSD terminal with RS232 connections to several other boxes.
I preferred buying refurbished pro LENOVOs which are more likely to have
hardware which works fine with both Linux and OpenBSD and is inexpensive.
My last purchase of a Laptop was a TUXEDO with Ubuntu KDE preinstalled.
All devices are guaranteed to work and they do. But that does not fit
into you requirement of "inexpesive" I guess. O, and it hosts two
virtual machines with Win10home and Win11pro which also are working
flawlessly.

I wish you success
--
Eike Lantzsch KY4PZ / ZP5CGE

Re: Need advice on a usable, inexpensive laptop for Debian

[Charles Curley]

On Wed, 4 Sep 2024 17:04:33 -0500
Tom Browder  wrote:

> I am torn with whether dual boot is the way to go, given all the
> problems I see with dual boot with Windows now. (I finally dumped
> Windows entirely some months ago when I found a decent, modern
> replacement for Microsoft Word and for the H&R Block US Federal tax
> program).

I've never had a problem with dual booting both Windows and Linux, and
I started doing that in the 1990s. Install Windows first. It will hog
the entire drive, so the next step is to shrink its partition to
something reasonable. The Windows rescue partition is usually at the
end of the disk; you can leave it there. Then install Linux on the
newly freed up space.

I find a 256GB SSD suitable for me; for your purpose a 128 GB drive
should do it.

What did you replace the H&R Block program with?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Need advice on a usable, inexpensive laptop for Debian

[Alain D D Williams]

On Wed, Sep 04, 2024 at 05:04:33PM -0500, Tom Browder wrote:
> I'm trying to propose a computer lab for young wannabe coders, and I want
> to use a Linux box (I prefer Debian, but I get the feeling Ubuntu is more
> familiar with school systems and other institutions).

I suggest an HP stream. I got myself an 11" one for £210 about 2 years ago. I
get 12+ hours from the battery.
11" screen is great for me to carry around in my ruck sack, for a student maybe
a 14" one:

https://www.argos.co.uk/product/3419636

Other models, I do not know the difference, dig deep in the specs:

https://www.argos.co.uk/product/7085891

I live in the UK so prices in £ (pounds).

I wiped it completely and installed Linux Mint. Works well, the only thing that
needed fiddling was to get it to hibernate when I shut the lid.

> All the cheap laptops in local Best Buys and other local stores have
> Windows installed, and, to be fair, that's all most adults and young people
> have been exposed to.

Just wipe it install Linux.

A few years ago I bought 2 identical laptops. At the same time I switched both
on and on one let MS Windows set itself up. The other I installed Linux.
The Linux one was installed & ready to work while the other was still wallying
around - which I did not let it finish.

I would suggest that any machine you are thinking of buying you go to the shop
and boot it from a memory stick‡‡ to check that it all works under Linux. The
most important thing that you might have problems with is the WiFi card.

‡‡ Booting from memory stick will not change the hard disk, ie is safe to do.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Need advice on a usable, inexpensive laptop for Debian

[Andrew M.A. Cater]

On Wed, Sep 04, 2024 at 05:04:33PM -0500, Tom Browder wrote:
> I'm trying to propose a computer lab for young wannabe coders, and I want
> to use a Linux box (I prefer Debian, but I get the feeling Ubuntu is more
> familiar with school systems and other institutions).
> 

If you're going to set it up from your own money - second hand Lenovo 
Thinkpads / HP laptops ex-business.

Relatively cheap, robust and available - and there will likely be more
given Windows 11 requirements.

A very good friend once taught a class of teenagers Linux after helping
them build their own computers from junk and older donated hardware.
Each teen got a free computer but had to research manuals, motherboard
connectors, motherboard and processor specifications ...

This gave them a really good grounding for appreciating hardware and
software. Most of them ended up running Debian, I think.

> I am torn with whether dual boot is the way to go, given all the problems I
> see with dual boot with Windows now. (I finally dumped Windows entirely
> some months ago when I found a decent, modern replacement for Microsoft
> Word and for the H&R Block US Federal tax program).
> 

With UEFI, it's possible.

> All the cheap laptops in local Best Buys and other local stores have
> Windows installed, and, to be fair, that's all most adults and young people
> have been exposed to.
> 

A fun exercise is to ask them to reinstall windows from scratch,
help them partition the disk and then install Debian from scratch.

All best, with whatever you decide to do

Andrew Cater
(amaca...@debian.org)
> Note I do not  want to get involved with Chromebooks.
> 
> Thanks for any suggestions.
> 
> -Tom

Re: Need advice on a usable, inexpensive laptop for Debian

[Pierre-Elliott Bécue]

Tom Browder  wrote on 05/09/2024 at 00:04:33+0200:

> I'm trying to propose a computer lab for young wannabe coders, and I
> want to use a Linux box (I prefer Debian, but I get the feeling Ubuntu
> is more familiar with school systems and other institutions).
>
> I am torn with whether dual boot is the way to go, given all the
> problems I see with dual boot with Windows now. (I finally dumped
> Windows entirely some months ago when I found a decent, modern
> replacement for Microsoft Word and for the H&R Block US Federal tax
> program).

I have a Windows 11/Debian Trixie dualboot on my workstation, never had
a single issue. FWIW, when you install Debian after Windows in general
things go well. Of course depending on the UEFI BIOS, things can be a
bit rough to configure properly, but when it's done it's good.

> All the cheap laptops in local Best Buys and other local stores have
> Windows installed, and, to be fair, that's all most adults and young
> people have been exposed to.
>
> Note I do not  want to get involved with Chromebooks.

Good idea.

So, to come back to your point: if you buy cheap laptops with windows,
no one is forcing you to keep it. But dual boot shouldn't be an issue
and can ease the switch for people you're trying to onboard.

Remember to shrink the windows partition from Windows itself, as
otherwise it might really get screwed up.
-- 
PEB


signature.asc
Description: PGP signature

Need advice on a usable, inexpensive laptop for Debian

[Tom Browder]

I'm trying to propose a computer lab for young wannabe coders, and I want
to use a Linux box (I prefer Debian, but I get the feeling Ubuntu is more
familiar with school systems and other institutions).

I am torn with whether dual boot is the way to go, given all the problems I
see with dual boot with Windows now. (I finally dumped Windows entirely
some months ago when I found a decent, modern replacement for Microsoft
Word and for the H&R Block US Federal tax program).

All the cheap laptops in local Best Buys and other local stores have
Windows installed, and, to be fair, that's all most adults and young people
have been exposed to.

Note I do not  want to get involved with Chromebooks.

Thanks for any suggestions.

-Tom

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Franco Martelli wrote:
> 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.

Hm. I expected that
  --keyserver keyring.debian.org
would avoid the need for importing keys to the local keyring.
But the man page indeed does not promise this.

I ran
  gpg --list-keys
and really, the key DF9B9C49EAA9298432589D76DA87E80D6294BE9B is listed
as being in
  $HOME/.gnupg/pubring.kbx

Moving that file away causes failure to verify.

Thanks for reviewing and testing.


> 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

Probably i once followed my own example at
  https://www.gnu.org/software/xorriso/#download

Replaying it with end pieces of the Debian keys:

  gpg --keyserver keyring.debian.org --recv-keys 64E6EA7D 6294BE9B 09EA8AC3

fixes the verification for me.

So i changed the wiki page to

  gpg --keyserver keyring.debian.org --recv-keys 64E6EA7D 6294BE9B 09EA8AC3
  gpg --with-fingerprint --verify SHA512SUMS.sign SHA512SUMS

and will do with the debian-cd proposal. (Damn. I hit "Save Changes"
instead of "Preview". I must slow down. Rush brings bad luck.)


Actually i do not know how option --with-fingerprint came to me.
On Debian 12, verification works the same with and without it.
So it could be cargo cult. But most such cult has true roots in the past.
The man page is fewly enlightening with that option.

Does anybody know what benefit it is/was supposed to bring ?
If it is obsolete, since when ?


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Franco Martelli]

On 03/09/24 at 18:45, Thomas Schmitt wrote:

Hi,

due to popular resistence i created a new wiki page
   https://wiki.debian.org/VerifyISOImage
with the content which i would propose to
   https://www.debian.org/CD/faq/#verify

Regrettably i was unable to mimick the bullet list paragraphs of the FAQ,
so that i had to change the text for a more unstructured presentation.
(This does not have to be a disadvantage. But now i have two versions
which i need to maintain until a decision is made at debian-cd.)

Interested people are invited to proof-read it, but please make only
cosmetic changes and discuss any substantial change with me in advance.
Technical correctness and portability beyond the currently supported
releases of Debian are important to me.


First of all: thanks Thomas, this is a useful page for newcomers.
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.


If you agree, a paragraph like the following it could be useful at the 
beginning:


--- --- --- ---

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


--- --- --- ---

Just my 2¢ hint, cheers

--
Franco Martelli

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Max Nikulin wrote:
> "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}'`

Indeed. Some variable evaluations slipped through unquoted.
Two others are intentionally capable of becomming zero to many words and
as safe as can be without excluding some old shells:
  grep $update_v
  | $checksummer |

I dimly remember that $(...) did not work on one of the tested machines
back in 2011. I don't see hard reasons to avoid it in the particular
use cases in check_debian_iso. So i keep it as is and hope that the old
tests are not invalidated by the other changes.

shellcheck on Debian 12 also complains about SC2197 (fgrep) and
SC2003 (expr), which are normal for an old script. They are not really
wrong. So i keep them for the same reason as the backticks and the
unquoted variables.


I prepared a new version and put it into libisoburn's git:

  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/xorriso-dd-target/check_debian_iso

PGP signature file:

  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/xorriso-dd-target/check_debian_iso.asc



--- a/check_debian_iso  2011-12-17 19:33:50.0 +0100
+++ b/check_debian_iso  2024-09-04 14:19:43.987633803 +0200
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# check_debian_iso, copyright 2011 Thomas Schmitt 
+# check_debian_iso, copyright 2011,2024 Thomas Schmitt 
 # License:   GPLv2 or later
 # Tested on: Little-endian GNU/Linux with bash
 #Little-endian FreeBSD-8 with sh and "md5 -q"
@@ -145,12 +145,12 @@ fi

 # The two 16 bit numbers, which are of the appropriate byte sex,
 # get combined to a 32 bit number.
-blocks=`expr $lo + $hi '*' 65536`
+blocks=`expr "$lo" + "$hi" '*' 65536`

 echo "Piping $blocks blocks of '$file' through '$checksummer'" >&2
 echo "to verify checksum list item '$name_from_list'." >&2

-sum_from_file=`dd if=$file bs=2048 count=$blocks | $checksummer | head -1 | 
awk '{print $1}'`
+sum_from_file=`dd if="$file" bs=2048 count="$blocks" | $checksummer | head -1 
| awk '{print $1}'`

 if test "$sum_from_list" = "$sum_from_file"
 then



Regrettably the version in
  https://people.debian.org/~danchev/debian-iso/
is out of my reach. I will have to ask debian-cd to adopt the new one.
(For now it is only the user who can shoot the own foot by submitting
a hopeless image name.)


> Should the command line be prefixed with "#" instead since regular user can
> not do it?

Indeed. I had a script enable rw before copying the test ISO to the USB
stick. So i did not notice that superuser authority is needed.


> On the other hand
> $ sudo mount "$path_to_image_or_usb_device" "$mountpoint"
> can be done as a regular user (an alternative is pmount)
> udisksctl mount -b /dev/sdb1

I really dislike udisks.

> "d-live 12.7.0 kd amd64" is a bit weird from my point of view for the
> mountpoint, but unfortunately udisksd logic is hardcoded.

That's one of my reasons.

In general i think that "sudo" makes clearer what obstacle needs to be
surpassed.

Thanks for the review.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Greg Wooledge]

On Wed, Sep 04, 2024 at 12:57:52 +, David wrote:
> On Wed, 4 Sept 2024 at 11:03, Max Nikulin  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.

Is it, though?  It looks more like it's pointing to the if=$file part.
Perhaps the indentation was mangled by the layers of quoting.

> 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.

There is no sane world in which $file should be left unquoted.
Filenames *frequently* contain whitespace.  It should be assumed that
*all* filenames contain whitespace -- you're just better off writing
from that perspective.

count=$blocks ... now, that one could go either way.  The quotes are
*probably* not needed, assuming the contents of $blocks are a number.
But it's still better to include the quotes, to save the shell from
having to undergo the additional work of scanning the word for IFS and
globbing characters.

$checksummer here is a special case.  The way it's written is a horrible
hack that Bourne shell programmers seem to have embraced.  The idea is
that you can put a command and its arguments inside a variables, separated
by spaces, and use the variable unquoted to expand to the command.

This "works" in the simplest cases, where every argument word is just
a series of alphanumeric characters with carefully constrained punctuation
characters (dot, hyphen, underscore).

It **completely fails** if one of the arguments is a filename that
contains whitespace.  Or contains whitespace for any other reason, such
as being something like CFLAGS='-g -O'.

The workaround for that is to use an array instead of a string variable
to hold the command and its arguments.

checksummer=( md5sum --magic-arguments )
dd if="$file" | "${checksummer[@]}" | awk 'stuff'

Of course, that's a bash extension, and not available in sh.  In sh,
there is simply no way to do this safely, unless of course the contents
of checksummer are static.  In that case, checksummer can be written
as a function.

checksummer() { md5sum --magic-arguments; }
dd if="$file" | checksummer | awk 'stuff'

Re: Usage: "debian ... amd64-netinst.iso"

[David]

On Wed, 4 Sept 2024 at 11:03, Max Nikulin  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. Personally I would use double-quotes there, because
I always double quote expansions like that, unless I actually
want wordsplitting or expansion. I prefer that style, because it
has the benefit of providing a visual cue for the rare cases
that wordsplitting or expansion of the variable content is intended.
And it is visually clearer after the editor applies syntax coloring too.

With all that happening, it seems that shellcheck has missed
modern advice about the backticks. See here:
  http://mywiki.wooledge.org/BashFAQ/002
and here:
  http://mywiki.wooledge.org/BashFAQ/082

For example, entering
  foo=`echo bar`
at shellcheck.net gives:
  SC2006 (style): Use $(...) notation instead of legacy backticks `...`.
with explanation at:
  https://www.shellcheck.net/wiki/SC2006

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 04/09/2024 15:17, Thomas Schmitt wrote:

I tried "*" for bullet list. But it works only for a single line,
not for a multi-line text paragraph as on
   https://www.debian.org/CD/faq/#verify


I do not see anything special there. I have tried to convert to a bullet 
a random paragraph from the new page and I do not see any issue with 
generated HTML (in preview):


 * To verify the downloaded ISO image file, compute the checksum of the
 ISO image files by a tool such as "sha512sum" and "sha256sum".
 A successful verification looks like the following program run.
 (The $-sign is shown as example of the shell prompt, which might look
 different on your system.):
 {{{
 $ grep ' debian-12.7.0-amd64-netinst.iso$' SHA512SUMS | sha512sum -c -
 debian-12.7.0-amd64-netinst.iso: OK
 }}}

 Another paragraph


I now sent a proposal to debian...@lists.debian.org :
  https://lists.debian.org/debian-cd/2024/09/msg00011.html


From my point of view, the proposed variant is too long for that huge 
enough page.


Perhaps check_debian_iso should be put into a VCS.

"shellcheck -e SC2006" (to silence complains concerning ``) suggests 
double quotes around "$file"


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.


On 03/09/2024 23:45, Thomas Schmitt wrote:

Interested people are invited to proof-read it


$ computed=$(dd if=/dev/sdc count=323072 bs=2048 | sha512sum | awk 
'{print $1}')


Should the command line be prefixed with "#" instead since regular user 
can not do it?


dd: failed to open '/dev/sdb': Permission denied

ls -l /dev/sdb
brw-rw 1 root disk 8, 16 Sep  4 17:27 /dev/sdb

On the other hand

$ sudo mount "$path_to_image_or_usb_device" "$mountpoint"

can be done as a regular user (an alternative is pmount)

udisksctl mount -b /dev/sdb1

or

udisksctl loop-setup -r --file debian-live-12.7.0-amd64-kde.iso
Mapped file debian-live-12.7.0-amd64-kde.iso as /dev/loop0.

udisksctl mount -b /dev/loop0p1

"d-live 12.7.0 kd amd64" is a bit weird from my point of view for the 
mountpoint, but unfortunately udisksd logic is hardcoded.


udisksctl unmount -b /dev/loop0p1
udisksctl loop-delete -b /dev/loop0

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Max Nikulin wrote:
> Do you mean something like
> <https://wiki.debian.org/EnvironmentVariables#Quick_guide>?
> * Item
> {{{
>  code
> }}}

I tried "*" for bullet list. But it works only for a single line,
not for a multi-line text paragraph as on
  https://www.debian.org/CD/faq/#verify


I wrote:
> > until a decision is made at debian-cd.

> Please, drop a note here in the case of some progress.

I now sent a proposal to debian...@lists.debian.org :
  https://lists.debian.org/debian-cd/2024/09/msg00011.html


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 03/09/2024 23:45, Thomas Schmitt wrote:

due to popular resistence i created a new wiki page
   https://wiki.debian.org/VerifyISOImage

[...]

Regrettably i was unable to mimick the bullet list paragraphs of the FAQ


Do you mean something like
<https://wiki.debian.org/EnvironmentVariables#Quick_guide>?
At first glance

 * Item
 {{{
 code
 }}}

results in proper HTML structure while
<https://wiki.debian.org/EnvironmentVariables#Desktop_Environments_and_systemd_user_services>
with

 * Item
 . {{{
  code
 }}}

renders the code as a separate  element.

Unfortunately it is not covered in <https://wiki.debian.org/HelpOnLists>.

I assume you were not trying to create
<https://wiki.debian.org/DebianWiki/EditorGuide#FAQ_sections>
FAQ sections.


until a decision is made at debian-cd.


Please, drop a note here in the case of some progress.

Re: Usage: "debian ... amd64-netinst.iso"

[eben]

On 9/3/24 01:07, David Wright wrote:


Well, I might expect you to use a command something like:

   # dd bs=1M if=/dev/sdX of=/dev/stdout count=N | sha512sum

  
This is the default for dd, so you don't have to specify it.  I mean, it
doesn't hurt if you do, it's just extra.

--
And we never failed to fail / It was the easiest thing to do -- CSN

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

due to popular resistence i created a new wiki page
  https://wiki.debian.org/VerifyISOImage
with the content which i would propose to
  https://www.debian.org/CD/faq/#verify

Regrettably i was unable to mimick the bullet list paragraphs of the FAQ,
so that i had to change the text for a more unstructured presentation.
(This does not have to be a disadvantage. But now i have two versions
which i need to maintain until a decision is made at debian-cd.)

Interested people are invited to proof-read it, but please make only
cosmetic changes and discuss any substantial change with me in advance.
Technical correctness and portability beyond the currently supported
releases of Debian are important to me.


Now for the restistence:

Max Nikulin wrote:
> Do not try to cover everything exhaustively from the beginning. Just move
> the section from XorrisoDdTarget as a starting point.

Naw. That would be botch. I want the real stuff. :))

> 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.

Now there is something to link to.
But i would like to discuss the official status of script check_debian_iso
with debian-cd before asking for links from the official Debian pages.
(See the ugly ">>> TODO" paragraph in the new page.)


Franco Martelli wrote:
> 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.

Problem is that --ignore-missing is a younger option of sha512sum.
I know that it does not work on Debian 8 and wonder when exactly it was
introduced. It is not mentioned in
  https://tracker.debian.org/media/packages/c/coreutils/changelog-9.4-3.1
and
  https://codesearch.debian.net/search?q=package%3Acoreutils+ignore-missing
drowns me in translation files. I really really hate i18n.

So i stay with the "grep -F" method and would offer resistence myself to
attempts to exclude users of old GNU/Linuxes. :))

> 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?

It is mentioned in the CD FAQ of which the new page shall be a superset.
Lee and Hans reported use cases for verifying on storage medium.

Lee allowed MS-Windows to touch the USB stick:
  https://lists.debian.org/debian-user/2024/09/msg00027.html
This case has an own section in the new wiki page.

Hans has a collection of unreliable USB sticks which give him the
impression that FAT, and only FAT, works on them.
  https://lists.debian.org/debian-user/2024/09/msg00059.html
This impression is quite surely not the whole story on his hardware.
A reliable verification after apparent success seems advisable.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Franco Martelli]

Hi,

On 02/09/24 at 22:32, Thomas Schmitt wrote:

Hi,

Franco Martelli wrote:

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".


Actually it is not the first time that i felt the urge to describe the
SHA and PGP verification:
   https://wiki.debian.org/JigdoOnLive#Verify_the_Debian_Live_download



consider to move that to a new wiki page with a title that
sounds like: "Verify authenticity of a Debian downloaded ISO image".


I'm not against that idea.
You could even get a wiki account
https://wiki.debian.org/DebianWiki/EditorQuickStart#Account
and do it on your own.


I've already an account on the Debian wiki, but I never created a new 
page, so for me it is a new things to do, probably I'd have to 
experiment a lot.




But i think there are some issues to address:

- How to generally advertise this page ?

- How to name it ?

- How to address all the stuff which is in
 https://www.debian.org/CD/faq/#verify
   and to which i pointed only briefly ?
   I think it is not good to send readers around in the web.
   Much better i'd like it all in one text (wearing my noob hat).



Max has already answered properly in the previous post and I agree with him.



So wouldn't it be better to start a petition at debian-cd mailing list
for an augmented https://www.debian.org/CD/faq/#verify ?
To my mind comes:

- Mention "USB keys" already in the section title.

- Replace "Detailed information ... authenticity verification page."
   by the last part of my new section: "PGP verification ...".
   (The current authenticity verification page is unsuitable for noobs.)



I'd prefer a wiki page, so users can easily changing/updating it and 
fill it of useful information.



- Add an example like
   $ grep -F debian-12.7.0-amd64-netinst.iso SHA512SUMS | sha512sum -c -
   debian-12.7.0-amd64-netinst.iso: OK
   $
   to "Checksums of the downloaded ... "sha256sum"."
   (We don't want to show deprecated "fgrep" to noobs. Of course i
   continue to use it at home.)


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.



- Add a new section about /md5sum.txt of the ISO.
 "How to find the altered files in case of no match"
   Derived from my text
 "If the verification attempt yields a non-matching checksum ...

- Augment
   "  $ dd if= count= bs= | sha512sum
* The computed checksum is to be compared ... SHA256SUMS, etc)."
   By an example how to compare the computed checksum with the one in
   the SHA512SUMS file.
   I currently can only propose
 $ grep -F $(dd if=/dev/sdc count=323072 bs=2048 2>/dev/null | \
 sha512sum | awk '{print $1}') SHA512SUMS \
   || echo "NO MATCH !"
   which would yield
 
e0bd9ba03084a6fd42413b425a2d20e3731678a31fe5fb2cc84f79332129afca2ad4ec897b4224d6a833afaf28a5d938b0fe5d680983182944162c6825b135ce
  debian-12.7.0-amd64-netinst.iso
   or
 NO MATCH !
   But the command and the positive answer are quite ugly.
   (I could get "OK. MATCH." by "if ... then ... else ... fi" which would
   be a nice script but an extra ugly command line.)
   Ideas for a more elegant way would be appreciated.


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?


Thanks

--
Franco Martelli

Re: Usage: "debian ... amd64-netinst.iso"

[David Wright]

On Mon 02 Sep 2024 at 11:16:53 (-0400), Michael Stone wrote:
> 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

to check for a good copy. And yet you seem awfully keen to
avoid using dd because of its alleged "cargo cult voodoo",
whatever that is, and because apparently you can screw it up
with typos (what, in "dd", "bs", "if" and "of"?). But about the
only method I've seen to check the copy is good is to use dd.

If you've copied the file with dd, you don't even have to type
half of the checking command because of command history. And
you don't have to calculate the count of blocks to check
because dd has just told you that.

That's leaving aside the fact that if copying (or checking) is
taking a suspiciously long time, you can ascertain dd's progress
even when you didn't ask for progress in the command line.

Like you, I can't see the point of using dcfldd. Its man page
advertises that it can verify the target drive, but that doesn't
work for this particular application. And ddrescue seems to be
another program that's pointless for this use. As for cp, I don't
see any particular benefit, and a disadvantage is that it's mute.

Sorry if I tried your patience. (BTW I am subscribed.)

Cheers,
David.

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 03/09/2024 03:32, Thomas Schmitt wrote:

Franco Martelli wrote:

consider to move that to a new wiki page with a title that
sounds like: "Verify authenticity of a Debian downloaded ISO image".

[...]

But i think there are some issues to address:

- How to generally advertise this page ?


Link it from articles having similar content or linking 
<https://www.debian.org/CD/faq/#verify>: JigdoOnLive, XorrisoDdTarget, 
DebianLive, CreateUSBMedia. The last one is referenced in the Debian 
install guide, so search engines should discover the new page.



- How to name it ?


ISOImageVerification, VerifyISOImage, maybe 
DebianInstaller/ISOImageVerification. I do not see a kind of portal for 
"debian-cd" or images.



- How to address all the stuff which is in
 https://www.debian.org/CD/faq/#verify


Do not try to cover everything exhaustively from the beginning. Just 
move the section from XorrisoDdTarget as a starting point.



So wouldn't it be better to start a petition at debian-cd mailing list
for an augmented https://www.debian.org/CD/faq/#verify ?


I do not read debian-cd, perhaps you know better if it should be done in 
advance of after creation of the draft. 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. E.g. primary value of 
<https://www.debian.org/CD/verify> is fingerprints that can not be 
edited by community, however step by step guide is more suitable for wiki.


I recall there was a quite detailed post on debian-user last couple of 
years, but I am unsure I can find it. Perhaps


Thomas Schmitt to debian-user. Re: No Public Key. Mon, 14 Nov 2022 
09:19:29 +0100.

<https://lists.debian.org/msgid-search/1352639982314990...@scdbackup.webframe.org>

Another candidate is more brief:
Gökşin Akdeniz to debian-user. Re: No Public Key. Sun, 13 Nov 2022 
23:46:22 +0300.

<https://lists.debian.org/msgid-search/ad2432d5-0ac7-5212-95e4-6e36ac250...@gmail.com>

Re: Any good Debian books highly recommended

[hohe72]

Hi,
here is no such thing like a Computer book what covers everything.

So go for an general purpose UNIX book.
Then for an advanced one covering Linux or Debian. Maybe an Admin Guide.
Because an Beginners Guide cannot cover every Shell available in detail,
you might buy a guide to your favoured shell.
For every day problems do the error on Google, cause some hints are
volatile.
Save money by installing man pages.

So first try to get an overview, then zoom in the topics needed. Go to
a book store and to scan through a book. Amazon will not help here.

This is an general advice,
Holger

ps:
Same goes for programming languages:
First go for language basics (the standard).
Then for advanced UNIX-programming or the Windows programming
or whatever you do.
And don't hesitate to by a book for C++ Templates only -- if required.
Here is no way it's being covered at a beginners guide usefully.



On Sun, 25 Aug 2024 04:08:27 +1200
Eric Richards <2eric.richa...@gmail.com> wrote:

> Hello
> As the Subject says Any good Debian books highly recommended or Linux
> for that matter.
> 
> I found one the other day Debian 12,  it only had a one star review
> and the buyer wishes he could get his money back
> 
> 
> 
> 
> 
> *From Eric.*
> 
> 
> *Sent from Raspberry Pi 5 *
> 
> 
> *Now we have wasted all our money on Widescreen TV and can not afford
> a holiday, a lot of news clips are shown in narrow vision from cell
> phones, it looks like the TV news producers have lost their marbl*
> *es. *
> 
> *Pedestrian "Cross Now" button is NOT wired to a pedestrian counter,
> it works on traffic flow, in fact it can change between school
> holidays and school days,  *
> 
> 
> *Sometimes the button does not work, because people like wearing it
> out. *



pgpf4YrrNZ6kj.pgp
Description: OpenPGP digital signature

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Franco Martelli wrote:
> 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".

Actually it is not the first time that i felt the urge to describe the
SHA and PGP verification:
  https://wiki.debian.org/JigdoOnLive#Verify_the_Debian_Live_download


> consider to move that to a new wiki page with a title that
> sounds like: "Verify authenticity of a Debian downloaded ISO image".

I'm not against that idea.
You could even get a wiki account
   https://wiki.debian.org/DebianWiki/EditorQuickStart#Account
and do it on your own.

But i think there are some issues to address:

- How to generally advertise this page ?

- How to name it ?

- How to address all the stuff which is in
https://www.debian.org/CD/faq/#verify
  and to which i pointed only briefly ?
  I think it is not good to send readers around in the web.
  Much better i'd like it all in one text (wearing my noob hat).


So wouldn't it be better to start a petition at debian-cd mailing list
for an augmented https://www.debian.org/CD/faq/#verify ?
To my mind comes:

- Mention "USB keys" already in the section title.

- Replace "Detailed information ... authenticity verification page."
  by the last part of my new section: "PGP verification ...".
  (The current authenticity verification page is unsuitable for noobs.)

- Add an example like
  $ grep -F debian-12.7.0-amd64-netinst.iso SHA512SUMS | sha512sum -c -
  debian-12.7.0-amd64-netinst.iso: OK
  $
  to "Checksums of the downloaded ... "sha256sum"."
  (We don't want to show deprecated "fgrep" to noobs. Of course i
  continue to use it at home.)

- Add a new section about /md5sum.txt of the ISO.
"How to find the altered files in case of no match"
  Derived from my text
"If the verification attempt yields a non-matching checksum ...

- Augment
  "  $ dd if= count= bs= | sha512sum
   * The computed checksum is to be compared ... SHA256SUMS, etc)."
  By an example how to compare the computed checksum with the one in
  the SHA512SUMS file.
  I currently can only propose
$ grep -F $(dd if=/dev/sdc count=323072 bs=2048 2>/dev/null | \
sha512sum | awk '{print $1}') SHA512SUMS \
  || echo "NO MATCH !"
  which would yield

e0bd9ba03084a6fd42413b425a2d20e3731678a31fe5fb2cc84f79332129afca2ad4ec897b4224d6a833afaf28a5d938b0fe5d680983182944162c6825b135ce
  debian-12.7.0-amd64-netinst.iso
  or
NO MATCH !
  But the command and the positive answer are quite ugly.
  (I could get "OK. MATCH." by "if ... then ... else ... fi" which would
  be a nice script but an extra ugly command line.)
  Ideas for a more elegant way would be appreciated.

- Change "Optical media verification." to
 "Optical media and USB key verification."


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[eben]

On 9/2/24 13:11, 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.


Thunar has "Safely Remove", which not only does sync && umount, it also
makes the partition disappear from its listing.  It (but not the drive) also
disappears from lsblk's output.  I'm not sure what happens if there's >1
mountable partition on the drive.  Must investigate further.

--
And we never failed to fail / It was the easiest thing to do -- CSN

Re: Usage: "debian ... amd64-netinst.iso"

[Franco Martelli]

On 02/09/24 at 13:01, Thomas Schmitt wrote:

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.


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".
Personally I'd like to have that as standalone wiki page in order to 
point the wiki link to a newbie that ask for a complete guide to verify 
a downloaded ISO image.


Again, it's ugly to have that as a section of "XorrisoDdTarget" wiki page.
So, please, consider to move that to a new wiki page with a title that 
sounds like: "Verify authenticity of a Debian downloaded ISO image".


By doing so me and other can easily answer a frequently asked question. 
If you agree or not please post your feedback.


Thanks

--
Franco Martelli

Re: Usage: "debian ... amd64-netinst.iso"

[tomas]

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.

I know, I repeat myself:

  dd if=/path/to/image of=/path/to/device bs=1M oflag=sync status=progress

In my experience, block sizes between a couple of hundred K and a couple
of M do well on flash drives. The default of 512 is very bad, and above
a couple of M it starts to degrade again. It's a very "flat" maximum.
YMMV on that.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Usage: "debian ... amd64-netinst.iso"

[Michael Stone]

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).

Re: Usage: "debian ... amd64-netinst.iso"

[The Wanderer]

On 2024-09-02 at 12:51, Lee wrote:

> 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.

My understanding is that when you tell Windows to "eject" removable
media, it does whatever is necessary to prepare that media for clean
removal.

With an optical disc, this includes unmounting the filesystem (and any
necessary cleanup related to the drive letter), and also includes
sending a physical eject command to the optical drive.

With a USB flash drive, it includes unmounting the filesystem, which
likely also includes an implicit sync operation.

If a new type of removable media comes along in the future, they'll
probably preserve the same prepare-for-safe-removal interface, and make
it do whatever the new type may need under the hood.

I have always inferred that the only reason for the "eject" terminology
is that the interface and terminology were established during a period
before USB flash drives existed, when optical drives were the only
removable media (other than floppy disks, which I think were already
largely obsolete by the time this interface came along).

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.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Usage: "debian ... amd64-netinst.iso"

[Lee]

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.

> > But I'm more interested in what went wrong than exactly where
> > the write/verification failed.
>
> IIRC i once learned from a report about a "FAILED" md5sum.txt check
> that it was the EFI partition which got altered and that various
> proprietary software companies feel entitled to add (rather harmless)
> files to any FAT filesystem which their software can see.
>
>
> > so yeah, the obvious conclusion is that "what went wrong" is that I
> > used a Windows machine.  *sigh*
>
> Well, you have to expect such things to happen there.

Well, no..  I used to have bash scripts that worked on SunOS and then
later Red Hat as well as cygwin.  I've gotten used to things Just
Working across platforms, so this failing is a bit of a surprise.

> They wipe your bottom and your nose ... using the same cloth.

They certainly are getting more .. abusive parental, thinking they
know better than you and doing whatever regardless of what you want.

> > 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?
>
> Maybe this time you pulled out the stick and put it back in while
> MS-Windows was still running ?
> I have no tangible idea other than to propose to do some experiments.

Me either.  I'm not going to worry about it - other than reinstall
Debian on my laptop from a USB stick written on a Debian machine :)

Regards
Lee

Re: Usage: "debian ... amd64-netinst.iso"

[Hans]

 
> 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.)
> 
>

I believe, it is no problem to share with which usb-sticks I ran into the 
problem. The sticks are from Intenso. They are silver, and you can buy it in a 
double pack to a very cheap price here in Germany at a well known market place 
with a big "M" starting its name.

At the moment I am using "SanDisk Ultra USB 3.0" with 64Gb and had no issues 
with these. These are black and made of plastic, shape is  tapering to its end 
and you can push the contacts out of the case. 

At the moment I am testing a new one also from SanDisk. This is itsy bity tiny 
(only 3 cm long, 1cm wide and 3mm high) with 128GB. I am using it as my 
"prepared-for-the-issue"-stick. I am using YUMI on it (exFAT) and it has now 
27 bootable livefilesystems on it (like KALI, GRML, DRBL-Live, clonezilla, 
TRK, UBCD4WIN, F4BCD usw. usw.). I think, you can imagine. Among these are 
also my own Version of KALI-Life (built with bootcdwrite, about 25GB) and 
bigger ones like security-onion (7GB) or TAILS (6,6GB) and smaller ones like 
Super-grub-disk, TRK, gparted-live and of course, Debian-Install-iso. 
Collection of proven software for many years.

We will see, how well this stick does, as all of these images are regularly 
upgraded by me.

Best

Hans

Re: Usage: "debian ... amd64-netinst.iso"

[Michael Stone]

On Sun, Sep 01, 2024 at 05:20:41PM +0200, Hans wrote:

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.


no, you should simply verify the checksum after you write it if you 
really want to waste time checking things. (the instructions include a 
reference to a handy script to do this.) I think it's mostly a waste of 
time as the installer validates packages as they're read from the drive. 
there's a small chance that the initial stages of the process could be 
messed up (the parts that do the validation) but the odds that they're 
both corrupt and working well enough to run and validate the later 
stages are low enough that I personally am not going to waste time 
worrying about it.

Re: Usage: "debian ... amd64-netinst.iso"

[Michael Stone]

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?

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 31/08/2024 14:07, Thomas Schmitt wrote:

https://wiki.debian.org/XorrisoDdTarget


Disclaimer: I prefer non-destructive way of making bootable media. For 
UEFI it is just copying files, for BIOS it requires some commands like 
syslinux and editing of grub configuration. Perhaps I just have not 
faced cases when it is not enough. That is why I do not expect that I 
will become a regular user of xorriso-dd-target.


If you prefer to keep the wiki page isolated, it is up to you. More 
people may discover it if e.g. CategoryDebianInstaller is added. Perhaps 
there is a better category.


On 02/09/2024 13:30, Thomas Schmitt wrote:

Thomas, are you intentionally linking raw man page instead of a
formatted > one [[DebianMan:xorriso-dd-target|xorriso-dd-target(1)]]?


Once it was intentional, when the package was only in Debian Testing
and no Debian online man page existed.


<http://manpages.debian.org/testing/xorriso-dd-target>
[[DebianMan:testing/xorriso-dd-target]]


where can learn about the style of a "Debian official" block or a
"See also" section ?


<https://wiki.debian.org/DebianWiki/EditorGuide#Debian_.22official_material.22_banner>

My point is that the purpose of your script is to enhance the recipe 
given in

<https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html>
so this link is suitable to give more context

In my opinion, when a user asks a question similar to the one started 
this thread then a link to "Debian GNU/Linux Installation Guide" should 
be first answer. This time the XorrisoDdTarget wiki page was posted 
earlier, so a link to the installation guide will increase a chance to 
make users aware of this document.


On 02/09/2024 15:07, Thomas Schmitt wrote:

Max Nikulin wrote:

Is there a reason why the page is not cross-linked with
<https://wiki.debian.org/DebianInstaller/CreateUSBMedia>?

[...]

But i have few idea how i should motivate a link from XorrisoDdTarget,


My opinion is that simple "See also" section at the end is enough for 
curious users to discover alternatives. I do not consider CreateUSBMedia 
as a perfect article, but it has some value. More users notice it means 
more chances that it will be improved.


On 02/09/2024 18:01, Thomas Schmitt wrote:


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.


Notice that you have a mention of .sig files in the beginning.

Step by step instruction how to verify a downloaded image is valuable. 
Some time ago I was surprised that there is no one in Debian manual and 
wiki. However it does not specific to xorriso-dd-target, I would 
consider moving content to another article.


Another part is mostly troubleshooting for the case of firmware writing 
to EFI/. I can not imagine a case when it may provide something useful 
if actual issue is namely writing to a USB block device. Is there an 
article on debugging of installer images?


I do not insist on any changes. If you do not like linking to the pages 
I asked about, just ignore it.

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Hans wrote:
> What I meant is more a desciption,
> why xorriso-dd-target is better than dd or dcfldd.

xorriso-dd-target is effectively a frontend to lsblk, umount, and dd.
Insofar i deem dd to be sufficient but not necessarily superior to other
programs which can copy data to a USB stick or memory card.
It's just that dd is nearly always available in a GNU/Linux system.

Originally xorriso-dd-target was only intended as frontend to lsblk
which can evaluate the suitability of target devices for any copy program.
Without any arguments it will just list proposals of device names.

  $ xorriso-dd-target
  sdc
  $

But during conversations with Nio Wiklund alias sudodus, who provides
a tool named "mkusb", it evolved to an optional helper for that program:
  https://help.ubuntu.com/community/mkusb#Additional_Feature:_mkusb-plug
and to a quite standalone copier itself.
The sequence of use cases in
  
https://manpages.debian.org/bookworm/xorriso-dd-target/xorriso-dd-target.1.en.html
reflects this evolution.
While mkusb mostly addresses desktop GUI users, xorriso-dd-target restricts
its dependencies to lsblk and vanilla shell equipment.


> 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)

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.)


> Hardware issue in the bootloader.

You probably mean the firmware, not the bootloader, which would be
data in the payload area of the stick.


> 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.

It's not _that_ bad. The difference is possibly that FAT filesystems
have less metadata than ext filesystems.
But in that context, nothing is as lightweight on firmware and hardware
as a sequentially written filesystem image. One sweep, no random access,
no repeated writing to a single logical block.

Are you sure that possible write errors to FAT filesystems aren't just
silently ignored by the stick's firmware ?
If you otherwise use it with programs which checkread and complain, then
the impression can appear that only those programs cause errors.
You might get a more realistic impression if you manually checkread and
compare the content of FAT with the data you have written.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Hans]

> 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

No, nothing special. Some IO-errors and one does not boot any more (kernel 
crash, due to copy errors, but the ISO itself is ok. Working perfrectly on 
another stick and after several copies, this stick is booting, also. However, 
too unsecure for my productive systems).

Best

Hans

Re: Usage: "debian ... amd64-netinst.iso"

[eben]

On 9/2/24 07:23, Hans wrote:

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.


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

Re: Usage: "debian ... amd64-netinst.iso"

[Hans]

Hi Thomas,


> That's the actual topic of that wiki page.
> Just scroll up and read it from start.

maybe I did not express myself well enough. What I meant is more a desciption, 
why xorriso-dd-target is better than dd or dcfldd. Just a little comparision, 
which advantages your way got or disadvantages compared to the other. 

This does not affect, that your wiki is detailed enough for everyone. Just a 
suggestion from me, what I personally would have expected to read. Please note 
I say "personally". :)
> 
> > The debian manual suggests using the "dd" command and claims, not to use
> > Rufus, as it might not work.
> 
You got me! It was not Rufus, it was Unetbootin. I confused both. My fault.

> 
> How often do you experience bad copy runs ?

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. Other sticks, older and other manufacturer, did not fail at 
all. All sticks were 16GB and newly bought. (say: about 1 year old)
> 
> 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

No no, they are defective. Hardware issue in the bootloader. When reformatting 
to vfat, they are still working and (as far as I could ses) no errors. 
However, three of my five sticks are completly unusabla. One could no more be 
recognized, one only has 128MB writable, and the third one got randomly read/
write errors. 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. Hey, 
are ther other OS in the world  :) 
> 
> 
> Have a nice day :)
> 
> Thomas

Have fun!

Hans

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Hans wrote:
> Maybe you might want to add a suggestion for readers, which might be the
> best way, to get an ISO to an usb-stick?

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.

Which manual in particular ?

  https://www.debian.org/releases/stable/amd64/ch04s03.en.html
warns of unetbootin, but not of Rufus.


> I myself made good eperiences with dcfldd instead of using dd.

Yes. There are many ways to do the copying. It is the choice of the
target device file that i deem most risky. xorriso-dd-target strives
to make this choice unambiguous by asking the user to newly plug in
the intended USB stick at step 2 of its dialog.


> As these are large files (greater than 25GB),
> the danger, something gets lost during copy, is high.

That would be quite a bad USB stick, then.
Normally a good USB stick takes its capacity worth of data without error
or alteration. The new section in XorrisoDdTarget is for making sure
that you don't suffer from the unnormal cases.

How often do you experience bad copy runs ?


> 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).

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

Re: Usage: "debian ... amd64-netinst.iso"

[Hans]

Am Montag, 2. September 2024, 13:01:43 CEST schrieb Thomas Schmitt:
> 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

Hi Thomas,

nice tutorial, you wrote, very impressiv! 

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. In my case i am 
creating an ISO-Livefile of a running system with bootcdwrite and then copy it 
to an usb-stick using dcfldd. As these are large files (greater than 25GB), 
the danger, something gets lost during copy, is high. 

And in the past, dd worked not as good as dcfldd. With dd I got more errors. 

I already mentioned: dcfldd is testing very copied segment with a hashsum, 
that is correct, which dd does not. 

As I am doing this builds regularly, I already did about 60-70 copies in the 
last, so I think, meanwhile I know, what I am talking about.

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.

Anyway, just some ideas and maybe you or someone else finds it usefull.  

Best wishes

Hans

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

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

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

i wrote about 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.

I did not pay enough attention to the preamble, which warns of the
danger to spoil a hard disk.
(The warning sign ought to be larger with blinking lights.)

But i still lack a good reason to link from XorrisoDdTarget to
DebianInstaller/CreateUSBMedia.


Max Nikulin wrote:
> From my point of view this kind of pages should have links to the Debian
> install manual and to the Debian CD FAQ

The installation manual overlaps with XorrisoDdTarget mainly by
  https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
but i don't think that this would help much a potential user of
xorriso-dd-target. It proposes what i deem too dangerous for the general
public.

The FAQ
  https://www.debian.org/CD/faq/
indeed offers extra information.
I will think about how to point to it and especially to
  https://www.debian.org/CD/faq/#verify
which could put more emphasis on verification of USB sticks, especially
in its title
  "How can I verify the downloaded ISO images and written optical media?"
I'll think about a proposal which i can submit to debian-cd mailing list.

Maybe i should also mention how to make use of the file /md5sum.txt in
the ISOs.


Have a nice day :)

Thomas

RE: [HP][Debian Strixie] Unable to install Debian with GUI interface

[Tsai, Letitia (CW)]

Hi Ritter,

Yes, it works with the table version (Bookworm)
Just want to report as a reminder before official release.

Regards,
Letitia

From: Dan Ritter 
Sent: Thursday, August 29, 2024 8:22 PM
To: Tsai, Letitia (CW) 
Cc: debian-user@lists.debian.org
Subject: Re: [HP][Debian Strixie] Unable to install Debian with GUI interface

CAUTION: External Email
Tsai, Letitia (CW) wrote:
> Hi
> Not sure which category I should submit so I am writing this letter to gain 
> your guidance on the issue I encountered.
> Hope the information I provided is valid and easy to understand.
> Thank you !
>
> [Summary]
> Unable to install Debian with GUI interface
>
> [Steps to reproduce]
> 1. Download Image debian-testing-amd64-DVD-1.iso (dated: 2024/8/19 weekly 
> build : 
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/<https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd>)


Does it work with the stable image?

Testing is called testing because it is not stable. "Not working
right now" is fairly normal for it.


-dsr-

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

i wrote:
> >https://wiki.debian.org/XorrisoDdTarget

Max Nikulin wrote:
> Is there a reason why the page is not cross-linked with
> <https://wiki.debian.org/DebianInstaller/CreateUSBMedia>?

After skimming over that page, i see problems:

- It links to https://www.debian.org/devel/debian-installer/
  which links to the non-stable daily Debian Testing images
  
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/

- 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.

- It explains how to format an additional partition by mkdosfs
  but not how to create the partition. But that step is the difficult
  one, because the partitions in a Debian netinst ISO are so weird
  with a reason. I think fdisk is unscrupulous enough. But in
  general the hard-to-digest partitions of a Debian amd64 ISO caused
  other distros to abandon a few old machines in favor of a more
  conventional partition layout in their installation ISOs.

- It proposes to install firmware in the additional partition.
  I understand that the netinst ISOs have become so big because they now
  contain lots of firmware.

- In its "Method 3" it proposes SYSLINUX as boot loader.
  Although it is known to work via EFI from USB stick (other than from
  optical media), i have doubts that the proposed command makes the
  stick ready for EFI. Quite surely it does not care for Secure Boot.

It would make sense to link from CreateUSBMedia section "Method 1"
to XorrisoDdTarget, maybe even from "Method 2".

But i have few idea how i should motivate a link from XorrisoDdTarget,
which is for users who rarely operate as superuser on raw device files,
to CreateUSBMedia which looks like being for daring testers.
Proposals would be welcome. (Or a courageous wiki editor who feels
entitled to tell the developers what they shall tell the users.)


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

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 I'm more interested in what went wrong than exactly where
> the write/verification failed.

IIRC i once learned from a report about a "FAILED" md5sum.txt check
that it was the EFI partition which got altered and that various
proprietary software companies feel entitled to add (rather harmless)
files to any FAT filesystem which their software can see.


> so yeah, the obvious conclusion is that "what went wrong" is that I
> used a Windows machine.  *sigh*

Well, you have to expect such things to happen there.
They wipe your bottom and your nose ... using the same cloth.


> 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?

Maybe this time you pulled out the stick and put it back in while
MS-Windows was still running ?
I have no tangible idea other than to propose to do some experiments.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Max Nikulin wrote:
> Thomas, are you intentionally linking raw man page instead of a
> formatted > one [[DebianMan:xorriso-dd-target|xorriso-dd-target(1)]]?

Once it was intentional, when the package was only in Debian Testing
and no Debian online man page existed.
Now i changed it to your link proposal.


> Is there a reason why the page is not cross-linked with
> <https://wiki.debian.org/DebianInstaller/CreateUSBMedia>?

I will have to study this quite young wiki page ...


> 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".

Do you mean the man page or the wiki page ?

The man page is not specific to Debian.

If you mean the Debian wiki page, can you point me to an example page
where can learn about the style of a "Debian official" block or a
"See also" section ?


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Lee]

On Sun, Sep 1, 2024 at 5:00 PM Thomas Schmitt wrote:
>
> Hi,
>
> Lee wrote:
> > [...] 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'
>
> The script correctly truncated the data stream from /dev/sdb to the
> size that it read from the superblock of its ISO filesystem.
> If the checksums do not match, then some bytes in that range on /dev/sdb
> are not as they are in debian-12.7.0-amd64-netinst.iso.
>
>
> If you are interested in learning where, please keep the stick as it is
> now. Especially do not mount its EFI partition and do not plug it into
> a running MS-Windows system, which would happily alter bytes in that
> partition.

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.

I tried everything all over again on my Debian machine and .. it all works :)
as expected even!!

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?
download the .iso on the windows machine
cp the iso to /dev/sdb using cygwin on the windows machine
boot the laptop from the usb stick and install debian

My June "how2 format a flash drive" msg was after installing Debian on
the laptop.

Lee

Re: Usage: "debian ... amd64-netinst.iso"

[Max Nikulin]

On 31/08/2024 14:07, Thomas Schmitt wrote:

i add my two cents:

   https://wiki.debian.org/XorrisoDdTarget


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".

Re: Usage: "debian ... amd64-netinst.iso"

[David Christensen]

On 9/1/24 06:15, Greg Wooledge wrote:

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.



I agree that the question is broken.  Answering it literally points out 
that fact and sets the stage for the rest of my post.




So many of the replies in this thread have been disappointing.



There is a saying I heard while working in the electrical construction 
trade:


"Doing things right is a matter of experience.  Experience is a matter 
of doing things wrong."

-- Unknown



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.



I reviewed chapter 4, section 4.3, and subsection 4.3.1 of the "Debian 
GNU/Linux Installation Guide", and estimated that the OP needed simpler 
and more concise guidance.  So, I wrote the rest of my post.



David

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

Lee wrote:
> [...] 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'

The script correctly truncated the data stream from /dev/sdb to the
size that it read from the superblock of its ISO filesystem.
If the checksums do not match, then some bytes in that range on /dev/sdb
are not as they are in debian-12.7.0-amd64-netinst.iso.


If you are interested in learning where, please keep the stick as it is
now. Especially do not mount its EFI partition and do not plug it into
a running MS-Windows system, which would happily alter bytes in that
partition.

The ISO contains a file /md5sum.txt with MD5 checksums for most of the
files in the ISO. Although MD5 is nowadays easy to counterfei, it still is
a useful transport checksum.

For using that file, i choose two file names which suit me:

  mountpoint=/mnt/iso
  report_file=/tmp/md5_report

and mount the ISO filesystem. You would probably do:

  sudo mount /dev/sdb "$mountpoint"

I let md5sum verify the listed files

  cd "$mountpoint"
  md5sum -c ./md5sum.txt >"$report_file" 2>&1

Finally i look into "$report_file" by a text editor

  view "$report_file"

I search for lines which end by the text snipped ": FAILED".

My report file from debian-12.6.0-amd64-netinst.iso instead of /dev/sdb
shows one failure, to my surprise:
  ./boot/grub/efi.img: FAILED
That's the file which holds the EFI partition. I must have played with it.
The sha256sum result with the .iso file does not match the one in
  
https://cdimage.debian.org/mirror/cdimage/archive/12.6.0/amd64/iso-cd/SHA256SUMS
any more.

So i download debian-12.7.0-amd64-netinst.iso, check its SHA256,
and repeat above check procedure.
This time no lines with ": FAILED" at their end.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Lee]

On Sun, Sep 1, 2024 at 10:59 AM 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 never worried about it.  Yeah, I know... Bad Lee [slaps wrist]

> > 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 …

Same as what's in the FAQ[1] .. and then 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.

root@i3668 /cygdrive/c/temp/debian
$ cp debian-12.7.0-amd64-netinst.iso /dev/sdb

root@i3668 /cygdrive/c/temp/debian
$ sync

root@i3668 /cygdrive/c/temp/debian
$ check_debian_iso SHA512SUMS debian-12.7.0-amd64-netinst.iso /dev/sdb
Piping 323072 blocks of '/dev/sdb' through 'sha512sum'
to verify checksum list item 'debian-12.7.0-amd64-netinst.iso'.
323072+0 records in
323072+0 records out
661651456 bytes (662 MB, 631 MiB) copied, 7.11874 s, 92.9 MB/s
Found: 
9a165064baabd7ffb7063f02136e001a2c78c85c8b4a1ae97dfd81abd5641b32c6f04f4bdcd26d69bf6d78b1589bf2dcf75895106ae9e7794441fd2fc10dbe57
Expected:  
e0bd9ba03084a6fd42413b425a2d20e3731678a31fe5fb2cc84f79332129afca2ad4ec897b4224d6a833afaf28a5d938b0fe5d680983182944162c6825b135ce
MISMATCH: '/dev/sdb' checksum differs from
'debian-12.7.0-amd64-netinst.iso' in 'SHA512SUMS'

root@i3668 /cygdrive/c/temp/debian
$ check_debian_iso SHA512SUMS debian-12.7.0-amd64-netinst.iso
Piping 323072 blocks of 'debian-12.7.0-amd64-netinst.iso' through 'sha512sum'
to verify checksum list item 'debian-12.7.0-amd64-netinst.iso'.
323072+0 records in
323072+0 records out
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'

Regards,
Lee

[1]  https://www.debian.org/CD/faq/#verify

Re: Usage: "debian ... amd64-netinst.iso"

[Felix Miata]

David Wright composed on 2024-09-01 12:06 (UTC-0500):

> 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.

# /usr/bin/ddrescue amd64-netinst.iso /dev/sdj

# apt-get install gddrescue
...
# which ddrescue
/usr/bin/ddrescue
# apt-cache show gddrescue
...
Description-en: GNU data recovery tool
 The gddrescue tool copies data from one file or block device
 (hard disc, cdrom, etc) to another, trying hard to rescue data
 in case of read errors.
...
#

ddrescue automatically provides nice status reporting while it works.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: Usage: "debian ... amd64-netinst.iso"

[David Wright]

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.

  # … …

Cheers,
David.

Re: Usage: "debian ... amd64-netinst.iso"

[Hans]

> 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.

Best

Hans

Re: Usage: "debian ... amd64-netinst.iso"

[David Wright]

> 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.

Re: Usage: "debian ... amd64-netinst.iso"

[Michael Stone]

On Sat, Aug 31, 2024 at 01:31:28PM +0200, to...@tuxteam.de wrote:

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).


Do *not* use oflag=sync, it will unnecessarily slow things down with no 
advantage. Instead, if you really want to make sure things make it to 
disk, use oflag=fdatasync, which will prevent dd from exiting until 
everything has been written to disk, but without writing blocks one at a 
time.


In general the recommended "cp" mechanism (followed by sync) is better 
for most uses as it's a much simpler command line and much harder to 
screw up with typos. dd has quite a lot of cargo cult voodoo around it, 
but it's the best tool for a very small and specialized set of cases. 
(It's in the muscle memory of a lot of older users, but that's no 
reason we need to impose it on new users.)


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.

Re: Usage: "debian ... amd64-netinst.iso"

[Greg Wooledge]

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.

Re: Usage: "debian ... amd64-netinst.iso"

[debian-user]

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

You missed the next line

 # sync

It's there for a reason.

Monthly FAQ for Debian-user mailing list (last modified 20240901)

[Andrew M.A. Cater]

Debian-user is a mailing list provided for support for Debian users,
and to facilitate discussion on relevant topics.

Codes of Conduct


* The list is a Debian communication forum. As such, it is subject to both
  the Debian mailing list Code of Conduct and the main Debian Code of Conduct
  https://www.debian.org/MailingLists/#codeofconduct
  https://www.debian.org/code_of_conduct
  
Guidelines for this list

Some guidelines which may help explain how the list should work:

Language


* The language on this mailing list is English. There may be other mailing
  lists that are language-specific, for example, debian-user-french or
  debian-user-catalan

* It is common for users to be redirected here from other lists, for example,
  from debian-project. It is also common for people to be posting here when
  English is not their primary language. Please be considerate.

Answering questions and contributing to discussions constructively
==

* This is a fairly busy mailing list but even so you may have to wait some
  time for an answer - please be patient.

* Help and advice on this list is provided by volunteers in their own time.
  It is common for there to be different opinions or answers provided.
  
* It is not necessary to answer every post on the mailing list.
  
* Be constructive in your responses. It may be that somebody else answers
  a question before you - if so, you should not reply simply in order to get
  the last word in, only reply if you can add useful information.

* Don't feed the trolls: it's not necessary to reply to every post.

  If someone is trolling/misbehaving - don't amplify it by commenting
  on the list and giving them attention. Do report it to commun...@debian.org

  Do reference which post it is - user, date, mailing list and topic

Off-topic posts
===

* Please try to stay on topic.

* Off-topic posts will happen occasionally as threads wander.
  Don't reply to them to make them carry on.

* If you wish to introduce an off-topic subject that might be
  of interest to the wider list, start a new thread and preface
  the title with [OT].

* There is no debian-offtopic mailing list: please don't try
  to start one.

Partisan topics and political arguments
===

* Arguments for the sake of it are not
  welcome here. 

* Partisan political / religious / cultural arguments do not belong here
  either.

  Debian's community is world wide; do not assume others will agree with your
  views or need to read them on a Debian list.
  
Editing and answering mailing list posts


* It is helpful to write meaningful subject lines. If you change subject
  or emphasis in mid-thread, please change the subject line on your email
  accordingly so that this can be clearly seen. 

  For example: New question [WAS Old topic]

* It may also be useful for someone to post a summary email from time to
  time to explain long threads.
  
* Before posting, it may be useful to check your post for spelling mistakes
  and scan it for redundancy, duplicate words and redundancy.

* Clear replies and a short mailing list thread are much easier to
  read and follow than long threads.

* If you are replying to a post, please reply in-line if possible and 
  cut out extra text that is not relevant to your point.

Private replies and responding to posts off-list


* Please post answers back to the list so others can benefit: private
  conversations don't benefit people who may only be following
  along on the list or reading the archives later.

* We're only human: you may want to respond to someone off-list
  to make a point (or to wish them Happy Birthday / comment that you
  haven't seen them for a long time). We're also a community and the
  people you find on the list may become familiar friends
  
  BUT

* Posting outside the list can be unhelpful: bad behaviour outside the lists 
  can't easily be dealt with and will be invisible. You may inadvertently leak
  personal information by posting a private reply back to the list.

  If you *do* want to post outside the list - make it clear that you have done
  so at the top of the message. If someone replies to you privately and you
  think that this should go back to the list - ask them to post it to the list
  - do not just do so on their behalf without checking.

I can't see what I want here - help me!
===

* It is often useful to look through the archives to see whether the issue
  you wish to raise or a similar issue has been raised before by someone
  else. The top level link to the archives of this list is at
  https://lists.debian.org/debian-user/ organised by year, then month.

* Although there are only 20 or 30 regular 

Re: Usage: "debian ... amd64-netinst.iso"

[David Christensen]

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?


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. 



Yes -- but the command in the given string is "debian", which is not a 
valid command.




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.



"./" is required when a command is in the current working directory and 
the current working directory is not in the PATH environment variable. 
"./" is not required for file arguments in the current working directory:


2024-09-01 01:11:28 dpchrist@laalaa ~
$ echo 'hello, world!' > hello.txt

2024-09-01 01:11:37 dpchrist@laalaa ~
$ echo 'cat $@' > foo

2024-09-01 01:11:43 dpchrist@laalaa ~
$ chmod +x foo

2024-09-01 01:11:48 dpchrist@laalaa ~
$ ./foo hello.txt
hello, world!


David

Re: Usage: "debian ... amd64-netinst.iso"

[Thomas Schmitt]

Hi,

David Wright wrote:
> > The disadvantage of this method is how to check the USB has a good copy.

Gene Heskett wrote:
> Why should that be difficult? Just do a sha### sum on the device itself.

The difficulty is that media often are willing to hand out more
bytes than were written when copying the ISO image to them.
Therefore you have to curb reading for checksumming to the size of the
ISO image.
See
  https://www.debian.org/CD/faq/#verify
which explains this for optical media like DVD+RW and also for USB sticks.


Have a nice day :)

Thomas

Re: Usage: "debian ... amd64-netinst.iso"

[Timothy M Butterworth]

On Sat, Aug 31, 2024 at 11:15 PM David Christensen <
dpchr...@holgerdanske.com> 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.


> > Can it be coverted to a USB. How?
>
> A Debian Installer "isohybrid" file is compatible with optical media
> (e.g. CD-R, DVD-R, or BD-R) and with USB flash drives.
>
>
> If you wish to create Debian installation media, start by downloading a
> Debian Installer isohybrid file:
>
> https://www.debian.org/distrib/
>
>
> Different computer architectures require different Debian Installer
> isohybrid files.  Here is the one for 64-bit "Windows PC's":
>
>
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.6.0-amd64-netinst.iso
>
>
> Burning the Debian Installer isohybrid file onto an optical disc was
> easy when most PC's came with Windows, CD-RW drives, and burning
> software (e.g. Nero).  Today, Rufus seems to be a popular Windows
> application for copying ISO images to USB flash drives (untested):
>
> https://www.lifewire.com/how-to-burn-an-iso-file-to-a-usb-drive-2619270
>
>
> If you have a friend with Linux or BSD, they can use the dd(1) command
> to copy the Debian Installer isohybrid file to a USB flash drive:
>
> https://wiki.debian.org/DebianInstaller/CreateUSBMedia
>
>
> Alternatively, you can purchase Debian Installer media from vendors:
>
> https://www.debian.org/CD/vendors/
>
>
> Be very careful if you boot the Debian Installer on a computer that
> already has another operating system installed.  Using the Debian
> Installer Rescue Shell can be useful for troubleshooting, but requires
> advanced knowledge and skills.  Creating and maintaining a "dual boot"
> system requires even more knowledge and skills.
>
>
> I suggest obtaining a used 64-bit "Windows PC" and using it only for
> Debian.
>
>
> You can skip the installation media entirely by installing a hypervisor
> on your computer, creating a virtual machine (VM), loading the Debian
> Installer isohybrid file into the virtual optical disk drive, booting
> the VM, and installing Debian.  I like VirtualBox:
>
> https://www.virtualbox.org/
>
>
> I recommend that you buy and read "Learning the Unix Operating System"
> by Peek, et al:
>
> https://www.amazon.com/_/dp/0596002610
>
>
> Then "UNIX and Linux System Administration Handbook" by Nemeth, et al:
>
> https://www.amazon.com/dp/0134277554
>
>
> David
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Usage: "debian ... amd64-netinst.iso"

[gene heskett]

On 8/31/24 23:00, 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.

Cheers,
David.

Why should that be difficult? Just do a sha### sum on the device itself. 
Before its ever executed. Compare that to the .iso.

.


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Usage: "debian ... amd64-netinst.iso"

[David Wright]

On Sat 31 Aug 2024 at 15:20:46 (-0700), 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 string "..." is an ellipsis. This one stands for the version number
in any particular ISO file's name.

You can use "…" for an ellipsis in unicode, but it's tedious to insert
it unless you have a Compose sequence set up for it. I suspect most
people don't.

I define it as 'Compose..' myself, and use it a lot to save space.

Cheers,
David.

Re: Usage: "debian ... amd64-netinst.iso"

[David Wright]

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.

Re: Usage: "debian ... amd64-netinst.iso"

[Timothy M Butterworth]

On Sat, Aug 31, 2024 at 5:20 PM john doe  wrote:

> On 8/31/24 05:48, John Conover wrote:
> >
> > What does a "debian ... amd64-netinst.iso" do
> > with an .iso?


 A .iso file is a disk image file stored it ISO 9660 file format. An iso is
essentially and image of a CD or DVD. You can burn the iso to a disk very
easily or write it to a USB drive.

You have enough data in the iso file to start a Debian installation,
> most of the PKGs will be fetched from the internet.
>
> > Can it be coverted to a USB. How?
> >
>

You can write the iso to a USB drive using the dd command. Optionally you
can use https://etcher.balena.io/ which provides a simple GUI front end.


>
> cp  .
>
> --
> John Doe
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Usage: "debian ... amd64-netinst.iso"

[David Christensen]

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



Can it be coverted to a USB. How?


A Debian Installer "isohybrid" file is compatible with optical media 
(e.g. CD-R, DVD-R, or BD-R) and with USB flash drives.



If you wish to create Debian installation media, start by downloading a 
Debian Installer isohybrid file:


https://www.debian.org/distrib/


Different computer architectures require different Debian Installer 
isohybrid files.  Here is the one for 64-bit "Windows PC's":


https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.6.0-amd64-netinst.iso


Burning the Debian Installer isohybrid file onto an optical disc was 
easy when most PC's came with Windows, CD-RW drives, and burning 
software (e.g. Nero).  Today, Rufus seems to be a popular Windows 
application for copying ISO images to USB flash drives (untested):


https://www.lifewire.com/how-to-burn-an-iso-file-to-a-usb-drive-2619270


If you have a friend with Linux or BSD, they can use the dd(1) command 
to copy the Debian Installer isohybrid file to a USB flash drive:


https://wiki.debian.org/DebianInstaller/CreateUSBMedia


Alternatively, you can purchase Debian Installer media from vendors:

https://www.debian.org/CD/vendors/


Be very careful if you boot the Debian Installer on a computer that 
already has another operating system installed.  Using the Debian 
Installer Rescue Shell can be useful for troubleshooting, but requires 
advanced knowledge and skills.  Creating and maintaining a "dual boot" 
system requires even more knowledge and skills.



I suggest obtaining a used 64-bit "Windows PC" and using it only for Debian.


You can skip the installation media entirely by installing a hypervisor 
on your computer, creating a virtual machine (VM), loading the Debian 
Installer isohybrid file into the virtual optical disk drive, booting 
the VM, and installing Debian.  I like VirtualBox:


https://www.virtualbox.org/


I recommend that you buy and read "Learning the Unix Operating System" 
by Peek, et al:


https://www.amazon.com/_/dp/0596002610


Then "UNIX and Linux System Administration Handbook" by Nemeth, et al:

https://www.amazon.com/dp/0134277554


David

Re: Debian distros

[Michael Kjörling]

On 31 Aug 2024 22:55 +0200, from thus...@gmail.com (alejo):
> I was given a 14 year old laptop and I started installing Jessie then
> Stretch then Buster and now it uses Bullseye but I like all the distros..
> thanks Debian team

Those are Debian _releases_ (major versions), not distros. _Debian_ is
a distribution.

You should be aware that the only release that currently receives
mainline ongoing support is Bookworm (Debian 12). Bullseye (Debian 11)
entered the long-term support phase of the release lifecycle about two
weeks ago.

Based on the release cadence since circa 2005, it seems reasonable to
expect Trixie (Debian 13) to be released in about a year.

-- 
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Debian distros

[alejo]

I was given a 14 year old laptop and I started installing Jessie then
Stretch then Buster and now it uses Bullseye but I like all the distros..
thanks Debian team