Re: Net Install: Installation halts for disk change

[David Wright <deblis@lionunicorn.co.uk>]

On Thu 27 Feb 2020 at 17:13:26 (-0500), John Kaufmann wrote:
> On 2020-02-27 09:41, Lee wrote:
> > On 2/27/20, John Kaufmann wrote:
> 
> > > ... I'm beginning to get a sense
> > > that debian.org has /way/ over-complicated the installation images.
> > 
> > I think they don't do a good job of explaining things for newbies -
> > especially the implications of "free software only" (or whatever term
> > they use - I'm too lazy to go look) images.
> 
> Agreed: that is well-explained, and in fuzzy principle I like the explanation. In functional terms, it only became an issue for me when the image I was installing paused to ask for a disk with needed wifi drivers. (See the thread title.) So I have two problems with free/non-free - one philosophical/operational, one regarding the image installation script:
> 
>  1) If one can only make a working system with "non-free" drivers, what is the alternative? - a non-working system? What is the point of being a stickler about a "free" installation if that installation itself /requests/ "non-free" components? [Are all OEM hardware drivers by definition "non-free"?]

The premise of your question is wrong. None of my three desktop
machines needs any non-free driver. One uses a firmware blob for
sound, which it never saw until it was 12 years old when I ditched
its predecessor, a Tucson mobo'd PC. I don't think Debian has ever
carried it (Yamaha ymfpci) in the timespan over which I've used it.

>  2) When the installation pauses to ask for the insertion of a new medium (i.e., a disk change) requiring drivers, how is that supposed to execute if the installation does not prompt, or even allow, the CD drive to change disks (OP of this thread)? Despite excellent replies to this thread, I'm sad that no reply has addressed that issue.

I'm not certain the issue has been addressed at all, mainly because
there's never any real need. AIUI, and correct me if I'm wrong, you
downloaded both a free d-i and a firmware one onto two CDs, and
installed using the former. Then you needed to load the firmware from
somewhere, and wanted to use the other CD as the source.

Almost nobody finds themselves in this situation, nor are they intended
to. The idea is that you put any non-included drivers, whether they're
from Debian or elsewhere, onto a USB stick (or SD card, or whatever),
which you can insert at any time. (If it's already inserted, it won't
be asked for.)

> > > (If the choice of images seems too complicated, that's only because it is.)  For
> > > example, just look at the pages ...:
> > > ...
> > > cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current/multi-arch/iso-cd/
> > > cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.3.0+nonfree/amd64/iso-cd/
> > > 
> > > Two pages to serve the same purpose is too much churn.
> > 
> > except they do NOT serve the same purpose.  I've got machines with
> > Intel 32 and 64 bit CPUs.  The /multi-arch/ image works for both; the
> > /amd64/ will work only on an Intel 64 bit cpu.
> 
> Quite right; I was careless. That said, Debian targets many architectures. The special case of x64 evolving out of the x86 instruction set has made x86/x64 a common joint target (as opposed to other architectures), which my carelessness ignored.
> 
> Maybe, though, a case can be made for more formal regularity to highlight /intentional/ distinctions. For example,
>  - Should the x86/x64 distribution be under a directory tree "/images/.." while the the x86/x64 distribution is under a directory tree "/cdimage/.."? (Surely that is a distinction without intent or motivation?)
>  - Could the two pages have page *titles* to highlight their distinct purposes [the usual reason for page titles ;-)]?
>  - Could they be handled on a single page, along with other architecture targets (assuming a suitably clear and compact format - like a table?)?

I have no idea whether this is true, but there might be some intention
of evolving from cdimage to images, if only because using the term CD
to cover DVDs and USB sticks etc is confusing to some, according to
some posts here.

> > ...
> > nit: you're only "looking for a way to get started" once.
> > 
> > Yes, they could make it easier for someone without a linux background,
> > but look at it as a learning experience :)   And I suspect "the people
> > who matter" are current Debian users, not the clueless looking for a
> > MS Windows alternative (like me).
> 
> I do look at this as a learning experience, and in that effort am grateful not only for Debian but for this excellent list. "The people who matter" are all who want to use Debian, regardless where they come from.  Before it died, my last Thinkpad was running Mint/Xfce for years, and I found I was attracted to two communities which seemed to be excellent places to find answers: Arch and Debian. So I thought my next move would be to Arch (or Manjaro) or Debian.
> 
> My new Thinkpad came with Windows 10. I had to get concrete about the distro decision in a hurry, so reexamined my thinking and settled on Debian (because of a preference for stable rather than rolling releases - among other things, I wanted to learn more about the server side). I have not been disappointed.
> 
> > > I'm taking a lesson from this: some cleanup is in order.
> > 
> > Whereas I think the issue is that most linux documentation assumes too
> > much background knowledge.  But I suppose that's what the mailing
> > lists are for - a shortcut for finding out what info you're missing :)
> 
> That's a good point, but I actually don't mind the OS learning curve -- though I do try to shorten it for others (to get them to move to something cleaner than MS). My questions here have been about the Debian ecosystem and installation quirks, and I think I have learned some things that could be tidied up to make life simpler (which, among other things, could only help my objective of offering people a Windows escape route). With all the help received on this list, I have learned a meta-lesson: that the place to explore those apparent 'lessons learned' is with the Debian CD team.

I would agree that the paths through the web pages might be made a bit
more logical; not just the ISOs but also the md5sums etc. But I
imagine the d-i people have a lot on their (few) hands keeping up
with building the d-i software itself (if indeed it's the same people
responsible).

Cheers,
David.