Re: Installation instructions.
Replies below ...
On Fri, 4 Dec 2020 at 03:39, <email@example.com> wrote:
> From: David <firstname.lastname@example.org> Date: Thu, 3 Dec 2020 09:27:45 +1100
> > These are different to the ones inside the iso ...
> Thanks. My assumption of no difference was/is lethal. Any chance of
> mentioning the distinction in the instructions?
The instructions can be modified by anyone who is sufficiently
motivated to submit a patch to their maintainer. That's how this
project works, it's not a "we will hold everyone's hand" project.
That's one reason why there are dozens of distributions that are
"based on Debian". I understand Debian more as, "if you make an effort
to contribute in a meaningful and compatible way, we will work with
> (For interest.
> An .iso image could be booted from a HDD by 2010 at least.
> In that method, the vmlinuz and initrd.gz inside the .iso were used.
> Kernel parameters "from", "fromhd" and "fromiso" existed back then.
> Examples are in AntiX pages including that cited above. The from
> parameters are no longer listed.
> https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html )
Those might never have been kernel parameters, but rather parameters
that the kernel passed to the installer init process.
> > That should work, let us know if it doesn't.
["Failed to find an installer image"]
Sorry to see that :(
But I have seen this occur from time to time without understanding
exactly why it happens.
> David, the current procedure is simple enough. Have you or anyone you
> trust run the procedure with the specific three (iso, vmlinuz,
> initrd.gz) files you cited?
On Wed, 2 Dec 2020 at 13:11, David <email@example.com> wrote:
> In my recent experience (using para 3 method), the installer searches the
> local hard drives for files that it recognises. And this search can
> fail to succeed if I haven't done the proper dance first. The vmlinuz
> and initrd must match the iso.
I use the hd-media method for pretty much every install that I do, I
never use removable media. I do quite a lot of installs for a home
user. I have about half a dozen machines and they all have between 4
and 8 working installs (multiboot hdd) at any one time.
I don't begin with a blank drive so I skip the grub steps. I just put
the 3 required files into my unencrypted boot partition (it's big
enough to hold plenty of them), and I use them to install, mostly into
a new LVM volume on the rest of the HDD which is encrypted using LUKS.
Years back when I had less knowledge about all things, I
occasionally would try a hd-media install and *not unusually* see
these "Failed to find an installer image" messages and suspect that
there was some bug and give up. But maybe the problem was my lack of
knowledge at that time, combined with the many ways to get this wrong.
I think this is an area that possibly needs some investigation or
improvement. I would like to know how this ISO search is being done
and what is the reason for the failure (and why can't I just specify
the ISO I want to use, no compulsory search!). However I've not spent
any time attempting to understand or debug or even find and read the
installer code. The installer programming environment is an unfamiliar
and complicated situation for me to explore.
Once I realised that it had something to do with matching everything
up I had fewer failures. "Matching everything up" becomes more of a
challenge when working with the wide range of "official" and
"unofficial" (containing non-free firmware) ISO images, and working
with "unstable" or "testing" suites, different kernel versions, and
perhaps using under-development versions of the installer as well. I
have seen this failure recently during something more exotic than a
"stable" install, I don't recall the details. I tried again (because
these days this has become my standard procedure and I expect it to
work) with a different hd-media and it worked.
That's why I asked exactly which files you are using. It's good that
everything is from "official" and "stable", and I have sufficient
passing interest to investigate further and I'm happy to test with the
same files that you are using. I can't do it immediately because there
are some practical complications: to duplicate here what you are doing
exactly requires a 32bit machine plus a spare hard drive. My 32bit
machines require 2.5" or 3.5" PATA drives. I know I have a spare 2.5"
PATA drive but connecting it to my 3.5" host system requires opening
up the case and finding adapters, blah blah. I have other commitments
and priorities but I probably can do it sometime over the weekend if