Re: Installation instructions.
On Sun, 6 Dec 2020 at 08:35, John Boxall <jboxall47@gmail.com> wrote:
> On 2020-12-05 4:07 p.m., David wrote:
> > I have both i386 and amd64 machines available to test, and I'm
> > using i386 when trying to assist Peter.
> In your testing have you been able to cleanly boot and run the installer
> through to completion, whether i386 or amd64? I have some results from a
> buster amd64 VirtualBox guest, but it isn't clean (kernel mismatch), but
> the install does progress. I will be testing on bare metal soon-ish.
Hi John,
Yes these days stable always works for me on actual hardware i386 and
amd64.
Due to lack of playtime I haven't done much with testing/unstable
releases or the testing versions of debian-installer, but that's where
I'm headed (if I wasn't too busy with too many projects).
With those development suites I guess mismatches between
installer/vmlinuz/initrd might be more likely. But stable should work
unless there are occasional bugs, it can happen when kernels change.
When I first tried this years ago I experienced the same problem as
Peter. Which was irritating, because on old hardware, removable media
installs can be very slow. I like fast installs, so I wanted to find a
better way.
My approach now is to create a very flexible setup on each machine,
disks these days are so huge that there's plenty of space. I use 4
primary partitions with an msdos partition table. Three of them are 12
GB and the fourth is much bigger consuming the rest of the drive using
LUKS and LVM.
The 12GB boot partition is big enough to hold the boot files of many
different installs regardless if outside or inside the LUKS/LVM, plus
however many different installation iso images that I want to play
with.
I do each install without a separate boot, and then move the boot images
to the boot partition and symlink to them. This keeps all the kernels
and initrds and installation ISOs on their own partition. Sometimes
an initrd from one install can be helpful to use to fix another. Another
benefit of this is that the grub of every install can do whatever stupid things
it wants to its grub.cfg without corrupting my actual grub.cfg that
boots the system, which I manage manually and keep simple without all
the overcomplicated default stuff makes the default grub.cfg hard to read.
The other two 12GB primary partitions are just throwaway play spaces
which are sometimes helpful if convincing the installer to install
into LUKS/LVM gets tricky, I can just do it outside and then move it
inside afterward if I want to keep it.
I also use 'approx' on another machine on my LAN as a repo cache which
speeds things up too.
All this gives me the ability to easily test these things on actual
hardware. I'm not claiming my way is "best" just sharing how I do it
and why.
So these days I expect hd-media install to work every time. And when
it doesn't then I'm curious to understand why. So my interest here is
purely academic curiosity to better understand something that I didn't
know how to troubleshoot when it was happening to me years ago. I
haven't tried VM's for a while but if I did I would use kvm not
VirtualBox.
Reply to: