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

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

Installation instructions.

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

Contents

  Installation instructions. peter@easthope.ca - 2020-12-02 00:10 +0100
    Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-02 03:20 +0100
      Re: Installation instructions. peter@easthope.ca - 2020-12-02 22:00 +0100
        Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-02 22:20 +0100
        Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-02 23:30 +0100
          Re: Installation instructions. peter@easthope.ca - 2020-12-03 17:40 +0100
            Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-03 20:30 +0100
            Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-03 21:30 +0100
              Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-04 00:10 +0100
                Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-04 02:30 +0100
              Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-04 10:10 +0100
                Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-04 13:00 +0100
                  Re: Installation instructions. David Wright <deblis@lionunicorn.co.uk> - 2020-12-04 22:20 +0100
                    Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-04 23:40 +0100
                      Re: Installation instructions. David Wright <deblis@lionunicorn.co.uk> - 2020-12-05 03:20 +0100
                    Re: Installation instructions. peter@easthope.ca - 2020-12-06 16:40 +0100
                      Re: Installation instructions. David Wright <deblis@lionunicorn.co.uk> - 2020-12-10 01:10 +0100
                  Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-05 16:00 +0100
                  Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-05 20:50 +0100
                    Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-05 22:20 +0100
                Re: Installation instructions. peter@easthope.ca - 2020-12-05 21:00 +0100
                  Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-05 21:40 +0100
                    Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-05 22:00 +0100
                      Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-05 22:10 +0100
                        Re: Installation instructions. John Boxall <jboxall47@gmail.com> - 2020-12-05 22:40 +0100
                          Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-06 01:20 +0100
                        Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-06 01:20 +0100
                          Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-06 01:40 +0100
                    Re: Installation instructions. peter@easthope.ca - 2020-12-06 06:10 +0100
                      Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-06 19:30 +0100
                  Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-05 21:40 +0100
              Re: Installation instructions. peter@easthope.ca - 2020-12-05 22:10 +0100
                Re: Installation instructions. David <bouncingcats@gmail.com> - 2020-12-05 22:20 +0100
        Re: Installation instructions. Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-03 10:00 +0100
    Re: Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-02 20:00 +0100
      Re (2): Installation instructions. peter@easthope.ca - 2020-12-02 22:40 +0100
        Re: Re (2): Installation instructions. Brian <ad44@cityscape.co.uk> - 2020-12-03 00:10 +0100
    Re: Installation instructions. John Boxall <jboxall47@gmail.com> - 2020-12-02 23:00 +0100

Page 1 of 2  [1] 2  Next page →

#229202 — Installation instructions.

https://www.debian.org/releases/stable/i386/ch05s01.en.html#boot-initrd
gives this sample Grub2 configuration.

menuentry 'New Install' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
linux /boot/newinstall/vmlinuz
initrd /boot/newinstall/initrd.gz
}

No problem with vmlinuz and initrd.gz but the CD image is not found.

The configuration which worked in the past had parameters on the linux 
command. Similar to this.

linux /vmlinuz root=UUID=50e0fa4b-6c62-40f8-8a84-46ab1413eb5a ro from=hd fromiso=debian-10.6.0-i386-netinst.iso load=all reboot=bios

The instructions at the URL above appear incomplete. Does anyone 
happen to know how the ISO should be accessed?  Loop mount at 
/dev/cdrom?

Thx,               ... P.

-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [next] | [standalone]

#229203

On Wed, 2 Dec 2020 at 10:06, <peter@easthope.ca> wrote:

> Installation instructions.

> the CD image is not found.

Please describe at exactly what point in your attempt you reached
this conclusion. What screen messages did you see exactly?

Due to the flexibility of Debian installation there are so many
possible scenarios that to write a comprehensive reply would be time
consuming for us and probably lack clarity for you (eg the existing
documentation). If you provide more information (requested below) to
exactly describe your situation, someone might be able to offer custom
suggestions or even a tested solution ...

> https://www.debian.org/releases/stable/i386/ch05s01.en.html#boot-initrd

Quoting paragraphs 2 and 3 from your link above ...

"""
If you intend to use the hard drive only for booting and then download
everything over the network, you should download the
netboot/debian-installer/i386/initrd.gz file and its corresponding
kernel netboot/debian-installer/i386/linux. This will allow you to
repartition the hard disk from which you boot the installer, although
you should do so with care.

Alternatively, if you intend to keep an existing partition on the hard
drive unchanged during the install, you can download the
hd-media/initrd.gz file and its kernel, as well as copy a CD (or DVD)
iso to the drive (make sure the file is named ending in .iso). The
installer can then boot from the drive and install from the CD/DVD
image, without needing the network.
"""

So:
1) Which of the above are you attempting? Paragraph 2 or paragraph 3?
    Please describe what is on the hard drive before the installation,
and what you want to be there after.
2) Given that choice (para 2 or 3), where did you get the vmlinuz and
initrd.gz you are using?
    Please provide a full URL to them so we can reproduce your situation.
3) Which CD image are you using?
    Please provide a full URL to it so we can reproduce your situation.
4) The instructions that you linked to begin with this sentence:
"""
To boot the installer from hard disk ...
"""
So from that we might assume (you didn't explicitly say yet) that your
goal is to run
the Debian installer from a CD image data that is available in a file
on an ext4 partition on a local hard drive. Is that correct?

And your CD image is *not* on a removable media, is that correct?

> Does anyone
> happen to know how the ISO should be accessed?  Loop mount at
> /dev/cdrom?

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 don't know about para 2 method, I never tried that.

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

#229229

> > https://www.debian.org/releases/stable/i386/ch05s01.en.html#boot-initrd
> 
> Quoting paragraphs 2 and 3 from your link above ...
> 
> Alternatively, if you intend to keep an existing partition on the hard
> drive unchanged during the install, you can download the
> hd-media/initrd.gz file and its kernel, as well as copy a CD (or DVD)
> iso to the drive (make sure the file is named ending in .iso). The
> installer can then boot from the drive and install from the CD/DVD
> image, without needing the network.

> 1) Which of the above are you attempting? Paragraph 2 or paragraph 3?

3.

>     Please describe what is on the hard drive before the installation, ...

Before the installation, the HDD can have any information at all. It 
can be new, fresh from the factory.  It can be an old drive with a 
bootable MS Windows system.  Any information be overwritten or 
dereferenced  by steps below.  

> ... and what you want to be there after.

After the installation the drive should have Debian 10 system from 
which  the target machine can boot and work.

Required ingredients.
* Debian workstation with network connection. (In fact any Linux or Unix 
  should work.  A few details below may vary.)
* Target machine with hardware allowing a network connection.
* HDD which will work in the target machine when this process is 
  complete.

This procedure is performed.  Most steps require root priviledge.  On 
the workstation use su or sudo.

The system is to be installed on a "target HDD".  Connect the target 
HDD to a Debian workstation using a ATA cable or USB-ATA adapter. To 
my understanding the machine should be unpowered when ATA is connected 
or disconnected.  USB can be hot-plugged.

Using gparted in the workstation, make these four parts on the target 
HDD. 
Part 1 labeled ROOT.  7 GB.  Format ext4. 
Part 2 labeled SWAP.  1 GB.  Format swap or linux-swap. 
Part 3 labeled HOME.  3.5  GB.  Format ext4. 
Part 4 labeled INSTLR.  520 MB.  Format ext4.

Mount INSTLR at /mnt/.
mount /dev/sdx4 /mnt/           # x represents the actual drive letter.  Eg. "c".

Make a grub directory. 
mkdir /mnt/grub

Install grub on the target HDD. 
grub-install  --boot-directory=/mnt/  /dev/sdx

Ref. 5.1.5. Booting from Linux using LILO or GRUB
https://www.debian.org/releases/stable/i386/ch05s01.en.html#boot-initrd
Note the GRUB2 example stanza.

open /mnt/grub/grub.cfg with an editor.  If the following stanza is 
not present, add it. Note that we have the files at /, not at 
/boot/newinstall/ as the example.

menuentry 'CDless CD install' { 
insmod part_msdos 
insmod ext2 
set root='(hd0,msdos1)' 
linux /vmlinuz 
initrd /initrd.gz 
}

> 3) Which CD image are you using?

https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.6.0-i386-netinst.iso

(I'd be happy to retrieve the image from a local server, 
http://mirror.it.ubc.ca/debian/dists, but did not find it there.)

Put that .iso file in /mnt/

> 2) Given that choice (para 2 or 3), where did you get the vmlinuz and 
> initrd.gz you are using?

vmlinuz and initrd.gz are in the .iso.  No need to retrieve again.

mkdir /loop 
mount -t iso9660 -o loop,ro /mnt/debian-10.6.0-i386-netinst.iso /loop 
cp /loop/initrd.gz  /mnt/ 
cp /loop/vmlinuz  /mnt/

Verify that INSTLR is organized. 
ls /mnt
debian-10.6.0-i386-netinst.iso  grub  initrd.gz  lost+found  vmlinuz

Good.

umount /mnt

Disconnect the HDD from the workstation and connect it to the target 
machine. Connect, keyboard, monitor, mouse and power cord.  Turn on 
power. The GRUB2 menu should appear.  The title of the GRUB2 stanza 
above should appear.  "CDless CD install"  Scroll to that and press 
the <Enter> key.

vmlinuz should load and execute.  Then the initrd.gz.

If there is a complaint about low memory, go to <Go back> and "Execute 
a shell". The swap part can be verified with "blkid /dev/sdy".  Note 
that y # x, x mentioned above. If the machine has only one HDD, y = "a".
Execute "swapon /dev/sdy".  Eg. "swapon /dev/sda". Exit the shell and 
continue the installation process.

After setting location and language the installer will search for the 
CD.  Ideally the .iso image should be found as you suggested.  Here 
this message appears.

"No common CD-ROM dirve was detected. ..." 

No obvious way to proceed.

Regards,                            ... P.


-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

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

#229230

On Wed 02 Dec 2020 at 12:10:33 -0800, peter@easthope.ca wrote:

> > 2) Given that choice (para 2 or 3), where did you get the vmlinuz and 
> > initrd.gz you are using?
> 
> vmlinuz and initrd.gz are in the .iso.  No need to retrieve again.

You have a complete misunderstanding of what you are doing. The vmlinuz
and initrd.gz in the .iso will not enable you to boot using the hd-media
technique.

-- 
Brian

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

#229233

On Thu, 3 Dec 2020 at 07:54, <peter@easthope.ca> wrote:

> > > https://www.debian.org/releases/stable/i386/ch05s01.en.html#boot-initrd

> > Quoting paragraphs 2 and 3 from your link above ...

> > Alternatively, if you intend to keep an existing partition on the hard
> > drive unchanged during the install, you can download the
> > hd-media/initrd.gz file and its kernel, as well as copy a CD (or DVD)
> > iso to the drive (make sure the file is named ending in .iso). The
> > installer can then boot from the drive and install from the CD/DVD
> > image, without needing the network.

> > 1) Which of the above are you attempting? Paragraph 2 or paragraph 3?

> 3.

Ok great. Thanks for putting a decent effort into your reply, it helps greatly
to know better the situation we are responding to :)

Looking at your method, it looks quite misguided and over complicated,
perhaps you are working from obsolete information sources. The current
method is much easier.

The starting point is that you have chosen
https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.6.0-i386-netinst.iso
(current, stable, i386)

Per the "paragraph 3" I mentioned previously and quoted at the top
of this message, the required vmlinuz and initrd.gz for (current, stable, i386)
can be downloaded from:
http://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/

These are different to the ones inside the iso (because those don't
support the installation method that you have chosen).

Now we have obtained the 3 files required for installation, we can
next prepare the target HDD on your workstation. The only necessary
steps are to make the target HDD bootable with at least one ext4
partition containing our 3 files. Let's name that parition INSTLR as
you did. Next do these steps ...

> Mount INSTLR at /mnt/.
> mount /dev/sdx4 /mnt/           # x represents the actual drive letter.  Eg. "c".

> Make a grub directory.
> mkdir /mnt/grub

> Install grub on the target HDD.
> grub-install  --boot-directory=/mnt/  /dev/sdx

> open /mnt/grub/grub.cfg with an editor.  If the following stanza is
> not present, add it. Note that we have the files at /, not at
> /boot/newinstall/ as the example.

> menuentry 'CDless CD install' {
> insmod part_msdos
> insmod ext2
> set root='(hd0,msdos1)'
> linux /vmlinuz
> initrd /initrd.gz
> }

Next copy our 3 files from above (vmlinuz, intird.gz, and iso)
to the target HDD.

cp <the files> /mnt

Now put the target HDD into the target machine, boot it, and run the
installer. It can do the rest of the partitioning you want, there's no
need to use gparted beforehand although that could work as an
alternative method, it's not required.

That should work, let us know if it doesn't.

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

#229256

From: David <bouncingcats@gmail.com>
Date: Thu, 3 Dec 2020 09:27:45 +1100
> Per the "paragraph 3" I mentioned previously and quoted at the top
> of this message, the required vmlinuz and initrd.gz for (current, stable, i386)
> can be downloaded from:
> http://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/

OK, got them.

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

(For interest.
An .iso image could be booted from a HDD by 2010 at least.
https://antixlinux.com/forum-archive/problems-with-boot-from-iso-on-hard-disk-t2683.html

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 )

> ... no need to use gparted beforehand although that could work ...

I understand but find gparted easier to use.

> That should work, let us know if it doesn't.
 
 http://easthope.ca/BootFromISOinHD.jpg

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?

Thx,                                ... P.

-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

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

#229258

On Thu 03 Dec 2020 at 08:22:52 -0800, peter@easthope.ca wrote:

> From: David <bouncingcats@gmail.com>
> Date: Thu, 3 Dec 2020 09:27:45 +1100
> > Per the "paragraph 3" I mentioned previously and quoted at the top
> > of this message, the required vmlinuz and initrd.gz for (current, stable, i386)
> > can be downloaded from:
> > http://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/
> 
> OK, got them.
> 
> > 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?

Users make all sorts of assumptions. Do they all require catering for?
But you can try a wishlist bug against the Installation Guide.

> (For interest.
> An .iso image could be booted from a HDD by 2010 at least.
> https://antixlinux.com/forum-archive/problems-with-boot-from-iso-on-hard-disk-t2683.html
> 
> In that method, the vmlinuz and initrd.gz inside the .iso were used.

A red herring in the context of your initial inquiry. Nothing to do with                                       
Debian. And its from 2010!

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

Another red herring.
 
> > ... no need to use gparted beforehand although that could work ...
> 
> I understand but find gparted easier to use.
> 
> > That should work, let us know if it doesn't.
>  
>  http://easthope.ca/BootFromISOinHD.jpg
> 
> 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?

Yes.

I trust me!

-- 
Brian.

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

#229259

Hi Peter,

Replies below ...

On Fri, 4 Dec 2020 at 03:39, <peter@easthope.ca> wrote:
> From: David <bouncingcats@gmail.com> 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
you".

> (For interest.
> An .iso image could be booted from a HDD by 2010 at least.
> https://antixlinux.com/forum-archive/problems-with-boot-from-iso-on-hard-disk-t2683.html
>
> 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.
>
>  http://easthope.ca/BootFromISOinHD.jpg

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

Yes ...
On Wed, 2 Dec 2020 at 13:11, David <bouncingcats@gmail.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
needed.

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

#229265

On Fri 04 Dec 2020 at 07:20:19 +1100, David wrote:

[...]

> 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

Preseeding paramters on the linux line may be used to specify where the
ISO resides:

  shared/ask_device=manual
  shared/enter_device=/dev/disk/by-label/<LABEL>

[...]
 
> That's why I asked exactly which files you are using. It's good that

You certainly did ask that earlier:
  
 > 2) Given that choice (para 2 or 3), where did you get the vmlinuz and
 > initrd.gz you are using?

The response from the OP was

     > vmlinuz and initrd.gz are in the .iso. No need to retrieve again.

This will almost certainly lead to a failure to discover and mount the
ISO. BootFromISOinHD.jpg (provided by the OP) provides confirmation of
this assertion.

-- 
Brian.

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

#229267

On Fri, 4 Dec 2020 at 10:05, Brian <ad44@cityscape.co.uk> wrote:
> On Fri 04 Dec 2020 at 07:20:19 +1100, David wrote:

> > 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
>
> Preseeding paramters on the linux line may be used to specify where the
> ISO resides:
>
>   shared/ask_device=manual
>   shared/enter_device=/dev/disk/by-label/<LABEL>

Great tip, thank you!

That will give me the ability to find out what kind of errors occur
when I deliberately specify the wrong one, I might learn something
useful from that exercise.

> The response from the OP was
>
>      > vmlinuz and initrd.gz are in the .iso. No need to retrieve again.
>
> This will almost certainly lead to a failure to discover and mount the
> ISO. BootFromISOinHD.jpg (provided by the OP) provides confirmation of
> this assertion.

Yep, knew that for sure. And thanks for your previous tip about
looking for the loop module in the initrd, that was educational
for me and I have put that on my list of interesting things to look
into. It's a long list :D

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

#229287

On Fri, 4 Dec 2020 at 03:39, <peter@easthope.ca> wrote:

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

Looking now, I can confirm that I did a Debian installation here on 20
Oct 2020 using these files. There is no doubt because they are still
on the hard drive.

I give their md5sums below so you can check we are using the same
files.

On Thu, 3 Dec 2020 at 09:27, David <bouncingcats@gmail.com> wrote:

> The starting point is that you have chosen
> https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.6.0-i386-netinst.iso
> (current, stable, i386)

$ md5sum *iso
f327723426dc90a4daaf1609595d8306  debian-10.6.0-i386-netinst.iso

> Per the "paragraph 3" I mentioned previously and quoted at the top
> of this message, the required vmlinuz and initrd.gz for (current, stable, i386)
> can be downloaded from:
> http://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/

$ md5sum *
d3f41e1b683fa87cca189f8595b80a7c  initrd.gz
b30966bc534a606bb8dafab40e106ca9  vmlinuz

What next?
I suggest to check the installer log just after the search fails.

The method of doing that is here:
https://www.debian.org/releases/stable/i386/ch06s03.en.html#di-miscellaneous

I think the logs are usually scrolling into virtual console 4, or you
could start a shell on virtual console 2 and look for them. in the
/var/log directory.

See if you can find any error messages from the 'iso-scan' process in
the file /var/log/syslog.

The installer main menu offers a method of saving the log files if
you want to paste anything you find here.

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

#229297

On Fri, 4 Dec 2020 at 20:00, David <bouncingcats@gmail.com> wrote:
> On Fri, 4 Dec 2020 at 03:39, <peter@easthope.ca> wrote:

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

> > Yes ...

> Looking now, I can confirm that I did a Debian installation here on 20
> Oct 2020 using these files. There is no doubt because they are still
> on the hard drive.

Actually it was 14 Oct, just for the record :)

I have just now done another fresh install, this time using the same 3 files
on a blank hard drive, it worked to completion without your complaint
occurring.

Due to actually going through the entire procedure on a blank drive
so as to catch any unanticipated hiccups due to the process being
different to my usual one, I can add some more thoughts about that:

1) grub needs a partition table on the target device so it can do
embedding, so the target device can't be an entire block device (eg
sdx) it must be a partition[*] (eg sdxN where N is some natural number)

2) And you probably need at least N=2 on an older machine.
If there is sufficient RAM, the installer offers to load itself
into RAM which frees up the partition where the iso is, so that it can
be overwritten by the new install. If the RAM is insufficient this is
not possible, so the partition where the iso is must be specified
"do not use" because it is mounted and in use by the installer, so
the new install must be done into another partition. I would
deal with this by converting our installer boot partition to a /boot
partition manually after the install is complete and rebooted
into the new partition.

3) The grub.cfg I used was

menuentry 'Debian Installer' {
  insmod part_msdos
  insmod ext4
  set root='(hd0,msdos1)'
  linux /vmlinuz priority=medium
  initrd /initrd.gz
}

I suggest the use of priority=medium which allows you to
choose which [*]partitions are searched for the iso, which might help.
Once the problem is resolved you can remove that or
change it to what you prefer: low or high (which eg specifies
that only a few high priority questions are asked during install).

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

#229333

On Fri 04 Dec 2020 at 22:56:41 (+1100), David wrote:
> On Fri, 4 Dec 2020 at 20:00, David <bouncingcats@gmail.com> wrote:
> > On Fri, 4 Dec 2020 at 03:39, <peter@easthope.ca> wrote:
> 
> > > > 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?
> 
> > > Yes ...
> 
> > Looking now, I can confirm that I did a Debian installation here on 20
> > Oct 2020 using these files. There is no doubt because they are still
> > on the hard drive.
> 
> Actually it was 14 Oct, just for the record :)
> 
> I have just now done another fresh install, this time using the same 3 files
> on a blank hard drive, it worked to completion without your complaint
> occurring.
> 
> Due to actually going through the entire procedure on a blank drive
> so as to catch any unanticipated hiccups due to the process being
> different to my usual one, I can add some more thoughts about that:
> 
> 1) grub needs a partition table on the target device so it can do
> embedding, so the target device can't be an entire block device (eg
> sdx) it must be a partition[*] (eg sdxN where N is some natural number)
> 
> 2) And you probably need at least N=2 on an older machine.
> If there is sufficient RAM, the installer offers to load itself
> into RAM which frees up the partition where the iso is, so that it can
> be overwritten by the new install. If the RAM is insufficient this is
> not possible, so the partition where the iso is must be specified
> "do not use" because it is mounted and in use by the installer, so
> the new install must be done into another partition. I would
> deal with this by converting our installer boot partition to a /boot
> partition manually after the install is complete and rebooted
> into the new partition.

With such a small disk, I'd try modifying that suggestion: dispense
with /home, but only during the installation, making partition 3 the
one used for the iso ( and marked "do not use"):

  Part 1 labeled ROOT.  7 GB.  Format ext4.
  Part 2 labeled SWAP.  1 GB.  Format swap or linux-swap.
  Part 3 labeled HOME.  4 GB.  Format ext4. (The LABEL doesn't affect things.)

When the installation has completed, you can now, as root,

  . mount Part 3 as /mnt
  . clear any installation files off it
  . cp -a /home/<sysadmin> /mnt/ (which should be user 1000's ~,
    containing just the files that were copied from /etc/skel)
  . edit /etc/fstab to mount LABEL=HOME on /home
  . umount /mnt/
  . mount -a (to mount /home)
  . login ordinarily, as sysadmin.

That increases your space on /home by 14%.

> 3) The grub.cfg I used was
> 
> menuentry 'Debian Installer' {
>   insmod part_msdos
>   insmod ext4
>   set root='(hd0,msdos1)'
>   linux /vmlinuz priority=medium
>   initrd /initrd.gz
> }
> 
> I suggest the use of priority=medium which allows you to
> choose which [*]partitions are searched for the iso, which might help.
> Once the problem is resolved you can remove that or
> change it to what you prefer: low or high (which eg specifies
> that only a few high priority questions are asked during install).

… and low gives you expert installation.

Cheers,
David.

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

#229337

On Sat, 5 Dec 2020 at 08:12, David Wright <deblis@lionunicorn.co.uk> wrote:

> With such a small disk, I'd try modifying that suggestion:

Thanks for adding that, my attention was focussed on just
getting the installer working in a minimal way and I completely
forgot to adapt my instructions to fit Peter's desired partition layout.

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

#229343

On Sat 05 Dec 2020 at 09:34:14 (+1100), David wrote:
> On Sat, 5 Dec 2020 at 08:12, David Wright <deblis@lionunicorn.co.uk> wrote:
> 
> > With such a small disk, I'd try modifying that suggestion:
> 
> Thanks for adding that, my attention was focussed on just
> getting the installer working in a minimal way and I completely
> forgot to adapt my instructions to fit Peter's desired partition layout.

No, you followed Peter all right. I was going to make my suggestion to
one of his posts, but was still checking my notes from when I played
around with this type of installation process. That was with jessie
(for which I never burnt a CD) on my Pentium III, which doesn't know
how to boot from a stick. I was also reviewing his posts to see
whether he'd earlier expressed a need for a separate /boot partition
(I believe not).

I always leave my (encrypted) /home partition out of any new
installation, because any interference with the LUKS header
could be terminal. So all my systems have an occluded home
directory of three files, hidden under the /home mountpoint.

Cheers,
David.

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

#229391

From: David Wright <deblis@lionunicorn.co.uk>
Date: Fri, 4 Dec 2020 15:12:16 -0600
> With such a small disk, I'd try modifying that suggestion: dispense
> with /home, but only during the installation, making partition 3 the
> one used for the iso ( and marked "do not use"):
> 
>   Part 1 labeled ROOT.  7 GB.  Format ext4.
>   Part 2 labeled SWAP.  1 GB.  Format swap or linux-swap.
>   Part 3 labeled HOME.  4 GB.  Format ext4. (The LABEL doesn't affect things.)
> 
> When the installation has completed, you can now, as root,
> 
>   . mount Part 3 as /mnt
>   . clear any installation files off it
>   . cp -a /home/<sysadmin> /mnt/ (which should be user 1000's ~,
>     containing just the files that were copied from /etc/skel)
>   . edit /etc/fstab to mount LABEL=HOME on /home
>   . umount /mnt/
>   . mount -a (to mount /home)
>   . login ordinarily, as sysadmin.
> 
> That increases your space on /home by 14%.

That's similar to the proceedure described in this message.
https://lists.debian.org/debian-user/2020/12/msg00197.html

Thanks,                        ... P.


-- 
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

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

#229593

On Sun 06 Dec 2020 at 07:20:38 (-0800), peter@easthope.ca wrote:
> From: David Wright <deblis@lionunicorn.co.uk>
> Date: Fri, 4 Dec 2020 15:12:16 -0600
> > With such a small disk, I'd try modifying that suggestion: dispense
> > with /home, but only during the installation, making partition 3 the
> > one used for the iso ( and marked "do not use"):
> > 
> >   Part 1 labeled ROOT.  7 GB.  Format ext4.
> >   Part 2 labeled SWAP.  1 GB.  Format swap or linux-swap.
> >   Part 3 labeled HOME.  4 GB.  Format ext4. (The LABEL doesn't affect things.)
> > 
> > When the installation has completed, you can now, as root,
> > 
> >   . mount Part 3 as /mnt
> >   . clear any installation files off it
> >   . cp -a /home/<sysadmin> /mnt/ (which should be user 1000's ~,
> >     containing just the files that were copied from /etc/skel)
> >   . edit /etc/fstab to mount LABEL=HOME on /home
> >   . umount /mnt/
> >   . mount -a (to mount /home)
> >   . login ordinarily, as sysadmin.
> > 
> > That increases your space on /home by 14%.
> 
> That's similar to the proceedure described in this message.
> https://lists.debian.org/debian-user/2020/12/msg00197.html

Yes, that's because I based the partitioning on your own
https://lists.debian.org/debian-user/2020/12/msg00045.html
to which I was going to thread it until David's comment came in.
But I posted my reply merely to place this method (using future
/home) on record. You'd rather modify the partition table
instead, which I've always avoided.

Your new partition layout is not one I'd personally use, but then,
I don't know what your first two (unused) partitions are going to
be used for. (I presume they're not reserved for BIOS Boot and
ESP, like the two I always put on my GPT disks.) I haven't created
an extended partition since 1997, and eliminated those I'd created
or inherited by 1999.

Cheers,
David.

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

#229352

On Fri 04 Dec 2020 at 22:56:41 +1100, David wrote:

> On Fri, 4 Dec 2020 at 20:00, David <bouncingcats@gmail.com> wrote:
> 
> > Looking now, I can confirm that I did a Debian installation here on 20
> > Oct 2020 using these files. There is no doubt because they are still
> > on the hard drive.
> 
> Actually it was 14 Oct, just for the record :)
> 
> I have just now done another fresh install, this time using the same 3 files
> on a blank hard drive, it worked to completion without your complaint
> occurring.
> 
> Due to actually going through the entire procedure on a blank drive
> so as to catch any unanticipated hiccups due to the process being
> different to my usual one, I can add some more thoughts about that:
> 
> 1) grub needs a partition table on the target device so it can do
> embedding, so the target device can't be an entire block device (eg
> sdx) it must be a partition[*] (eg sdxN where N is some natural number)

Indeed.
 
> 2) And you probably need at least N=2 on an older machine.
> If there is sufficient RAM, the installer offers to load itself
> into RAM which frees up the partition where the iso is, so that it can
> be overwritten by the new install. If the RAM is insufficient this is
> not possible, so the partition where the iso is must be specified
> "do not use" because it is mounted and in use by the installer, so
> the new install must be done into another partition. I would
> deal with this by converting our installer boot partition to a /boot
> partition manually after the install is complete and rebooted
> into the new partition.

Suppose vmlinuz, initrd.gz, grub.cfg and the ISO are on a USB stick. The
stick can be booted and the installation done to a hard drive, which I
would guess is common place to put it. This avoids having to consider
the memory situation or mess with the installation afterwards.

Those users who cannot boot from a USB stick can have vmlinuz, initrd.gz
and grub.cfg on the hard disk and the ISO on a USB stick, where it should
found.

-- 
Brian.

> 
> 3) The grub.cfg I used was
> 
> menuentry 'Debian Installer' {
>   insmod part_msdos
>   insmod ext4
>   set root='(hd0,msdos1)'
>   linux /vmlinuz priority=medium
>   initrd /initrd.gz
> }
> 
> I suggest the use of priority=medium which allows you to
> choose which [*]partitions are searched for the iso, which might help.
> Once the problem is resolved you can remove that or
> change it to what you prefer: low or high (which eg specifies
> that only a few high priority questions are asked during install).
> 

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

#229362

On Fri 04 Dec 2020 at 22:56:41 +1100, David wrote:

> 2) And you probably need at least N=2 on an older machine.
> If there is sufficient RAM, the installer offers to load itself
> into RAM which frees up the partition where the iso is, so that it can
> be overwritten by the new install. If the RAM is insufficient this is
> not possible, so the partition where the iso is must be specified
> "do not use" because it is mounted and in use by the installer, so
> the new install must be done into another partition. I would
> deal with this by converting our installer boot partition to a /boot
> partition manually after the install is complete and rebooted
> into the new partition.

I have been using the hd-media installation method with preseeding
at priority-high for many years and never encountered this. It turns
out it was introduced as a consequence of #868900:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868900

The default for iso-scan/copy_iso_to_ram is false, which is why I
never saw it. Thanks for drawing the option to our attention.

Choosing "true" doesn't suit me because hd-media is then unmounted.
All the files I use during an installation, including the critical
preseed.cfg, then become unavailable.

> 3) The grub.cfg I used was
> 
> menuentry 'Debian Installer' {
>   insmod part_msdos
>   insmod ext4
>   set root='(hd0,msdos1)'
>   linux /vmlinuz priority=medium
>   initrd /initrd.gz
> }

My grub.cfg is

menuentry 'Debian Installer' {                                                                               
   linux /boot/vmlinuz priority=medium
   initrd /boot/initrd.gz                                                                                          
}

I think this would make "set root='(hd0,msdos1)'" superfluous. I wonder
whether the other two directives are defaults for GRUB?

-- 
Brian.

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

#229372

On Sun, 6 Dec 2020 at 06:41, Brian <ad44@cityscape.co.uk> wrote:
> On Fri 04 Dec 2020 at 22:56:41 +1100, David wrote:

> > 2) And you probably need at least N=2 on an older machine.
> > If there is sufficient RAM, the installer offers to load itself
> > into RAM which frees up the partition where the iso is, so that it can
> > be overwritten by the new install. If the RAM is insufficient this is
> > not possible, so the partition where the iso is must be specified
> > "do not use" because it is mounted and in use by the installer, so
> > the new install must be done into another partition. I would
> > deal with this by converting our installer boot partition to a /boot
> > partition manually after the install is complete and rebooted
> > into the new partition.

> I have been using the hd-media installation method with preseeding
> at priority-high for many years and never encountered this. It turns
> out it was introduced as a consequence of #868900:

>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868900

> The default for iso-scan/copy_iso_to_ram is false, which is why I
> never saw it. Thanks for drawing the option to our attention.

> Choosing "true" doesn't suit me because hd-media is then unmounted.
> All the files I use during an installation, including the critical
> preseed.cfg, then become unavailable.

Thanks again for sharing interesting info about different work
methods.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web