On Mon, Dec 17, 2018 at 02:29:27AM +0100, Cyril Brulebois wrote:
> Steve McIntyre <st...@einval.com> (2018-12-17):
> > But... The problem you're most likely seeing is caused by a simple
> > fact. The *netboot* image ends up downloading significant chunks of
> > the installer and the base system at runtime from the suite it
> > targets. For buster, that is still very much a moving target and it's
> > likely to already have incompatibilities with the released 20181206
> > netboot image.
> >
> > Netboot images are *only* useful and safe when they exactly match the
> > state of the Debian release they're targeting. That's either a stable
> > release, or within a couple of days of the build happening if you're
> > looking at testing.
> >
> > For any other purposes, IMHO you're massively better off using a
> > _netinst_ image instead. Or install stable and upgrade.
>
> What Steve says is particularly true when there's a difference in major
> libc version (2.27 vs. 2.28; the latter has just migrated to testing
> right after the general block-udeb in britney was lifted).
>
Thanks for the help. May I raise a related question?
Perhaps this is a doomed effort, please tell me if it is.
I have been trying to sort out a method of booting a buster netinst
image over the network, because I have hardware that needs the
buster kernel (I plan to install stretch with a backports kernel).
I want to be able to network boot because that makes it a lot easier
to supply preseed information than booting off a usb key.
I can get this to boot with PXE
LABEL buster_netinst
kernel memdisk
append iso initrd=debian/buster/amd64/netinst/netinst.iso raw vga=normal ---
But the installer gets stuck at cdrom-detect.
I can manually modprobe cdrom.ko but that doesn't seem to help,
cdrom-detect just repeats its search for installation media.
Is there some boot parameter I could give on the append line to
tell the installer it is being booted in this way?
Kind regards
Vince
