Re: please supply some documentation for bootnetx64.efi. Also choosing different preseed for each netboot.

[Raymond Burkholder]

On 9/23/23 15:17, Alex King wrote:
I need to do a EFI network (boot and) install, and I'm wondering if 
this file (bootnetx64.efi) can help me.  But there is no documentation 
on it (except the suggestion in the install manual 
https://www.debian.org/releases/stable/amd64/ch04s05.en.html#dhcpd 
"specify a boot loader appropriate for UEFI machines, for example...")


There are quite a few moving parts required to make this work.



My problem is this: I can UEFI netboot using grubx64.efi. However, it 
loads a standard grub.cfg which runs an interactive installer.  I need 
to preseed the install, and I need to load a different preseed file 
for each server booted.


Yep, a custom grub.cfg file is needed.



For non-uefi this is achieved using pxelinux's behaviour of tftp-ing a 
configuration based on MAC addresses etc. and fallback to a standard 
location.


I'm wondering if grubx64.efi or bootnetx64.efi support similar 
behaviour?  Or else how to get specific information into the installer 
(such as IP address and hostname), if not via specific pre-seed files 
per machine?


there are some settings in the dnsmasq config file to make some of this 
selection happen


(We can overwrite the grub.cfg each time with the needs of a specific 
server, but this is not ideal, as it will cause a failure if more than 
one machine is being net-installed at the same time.)


In general though I'm also looking for pointers to documentation. If 
someone could point to anything that explains what bootnetx64.efi is 
and what it does, I'd be happy to contribute that back to the wiki or 
install manual.




For me, building a preseeded machine with efi boot became a complicated 
affair involving grub config options, pxelinux options, dnsmasq, tftp, 
partman, and various preseed files and options.  I ended up coding all 
this into a large series of saltstack based state files to handle 
building the related service files and automatically updating everything 
as machines were added to the operation.


If you can read salt state files, I could see about showing my 
repository, and you could derive whatever you can from it.


Raymond Burkholder
https://blog.raymond.burkholder.net/

Re: ifupdown/dhcp

[Raymond Burkholder]

On 2022-05-08 2:07 p.m., Steve Langasek wrote:

On Sun, May 08, 2022 at 11:24:12AM -0400, Michael Stone wrote:


I've been trying to make sense of the NEWS item in isc-dhcp-client (that
alternatives are needed) in combination with the functionality of ifupdown
and what the implications are for debian upgrades generally.


I figure I'll copy the ifupdown2 package in here as well, as they are a 
replacement for ifupdown in some installations. [if they aren't tracking 
changes to ifupdown]





isc-dhcp-client as of the last upgrade is telling users to stop using it
(the default dhcp client for debian).



ifupdown (the traditional tool for managing networking on debian systems)
has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a
virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been
touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a
working configuration managed by ifupdown if installed, as it will try to
take over interfaces currently set, e.g., to manual). This seems suboptimal
at best.



I believe that ifupdown will attempt to use udhcpd if installed, which
should be a mostly-transparent change (except for the potential loss of
lease information and any customization of dhclient scripts) but it isn't
even on the ifupdown recommends list.



ifupdown also (used to?) use pump, but that package went away a long time
ago.



So what's the path forward, maintaining compatibility and not breaking
systems upgrading from current stable? Do we come up with a dhcpcd5 variant
that *only* touches interfaces it is directed to touch via
/etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual
package and/or make it the default for ifupdown? Do we fork isc's dhcp suite
and just continue to use dhclient? Revive pump? Something else?


Not an answer to your question, but a related issue I'll mention here.

Ubuntu no longer uses isc-dhcp by default, because it no longer uses
ifupdown; NetworkManager and networkd both have their own implementations of
dhcp clients which are used by preference.  *However*, isc-dhcp is still
installed as part of all Ubuntu systems, because it is the only client
implementation that integrates with initramfs-tools
(/usr/share/initramfs-tools/hooks/zz-dhclient) so if you are using nfsroot
or any other network-based rootfs, it appears to still be the only game in
town.  It would be a good idea to make sure as part of the deprecation of
isc-dhcp-client that we get initramfs integration of whatever is the
preferred replacement.

Re: serial console install issues

[Raymond Burkholder]

On 4/11/21 8:37 PM, Richard Hector wrote:

On 11/04/21 11:51 am, Richard Hector wrote:
Then finally, I can't remember how, I discovered that it didn't like 
displaying on a 24-line terminal, which most of the terminals I tried 
default to.


With a 25-line terminal, it all seems useable - and Minicom mostly 
displays it ok too (not quite right; the blue box isn't quite drawn 
properly, and seems too low on the screen?


I'm not sure where I got the idea that minicom was displaying a blue 
box; I think I was mistaken and still using screen.


Using Minicom, I found I have to use a 26-line terminal, because 
Minicom displays a status line, so a 25-line terminal only leaves 24 
lines usable, and the same problems remain.


Minicom also doesn't display the line-drawing characters correctly, 
and I don't see any difference between selected and unselected lines 
in Syslinux, so I have to select the right option by counting keypresses.


Loading the mc.pc8 (rather than .mcpc8 as referred to in the manpage) 
didn't help.


Minicom is also a pain because it assumes the existence of a modem, 
and tries to initialise it on startup - I got rid of all the modem 
control strings, which works - but really screen is much easier. 
That's probably worth mentioning in the Installation Guide.


I haven't (this time) tried cu (seems to need a config file or 
something in advance) or any other options. seyon looks likes it needs 
a lot of setup too.




This has gone back and forth quite a bit, so not sure where you are at, 
but


I use the following with a USB dongle:

screen /dev/ttyUSB0 115200

Screen is superior to minicom.

There is probably something similar when using the serial port directly.

I've always had problems with funny characters and such, it comes down 
to BIOS settings in the target device, as well as emulator set in 
screen.  I've never really had problems with 24 or 25 line issues.  
Maybe because of used putty or screen as the app for interaction.

Re: Bug#983835: base-installer: hostname= is ignored if reverse-dns exists

[Raymond Burkholder]

On 3/2/21 10:15 AM, Phil Dibowitz wrote:

On 3/2/21 1:58 AM, Holger Wansing wrote:

Am 2. März 2021 09:52:06 MEZ schrieb Cyril Brulebois :

The preseed doc[2] suggests the former is behind the (bare) hostname
alias. Try setting the latter?

Yes, the installation-guide under
https://www.debian.org/releases/bullseye/amd64/apbs04.en.html
even explicitly states this, indeed:

# If you want to force a hostname, regardless of what either the DHCP 
# server returns or what the reverse DNS entry for the IP is, 
uncomment # and adjust the following line. #d-i netcfg/hostname 
string somehost
However, that requires a per-host preseed, where as with kernel 
command line I can have the same preseed for all my hosts (or at least 
all hosts in a certain category) and simply just pass in a hostname in 
the tftpseed (which has to be host specific anyway and for me is 
already generated by my provisioning system).
You can use that parameter on the kernel command line.  And thus retain 
the generic preseed file.
So perhaps it would be useful to have a like netcfg/hostname_priority 
flag where one can choose a priority order?

No priority flag required.

Bug#982995: Installation Report

[Raymond Burkholder]

On 2/17/21 3:20 PM, Jeff Forsyth wrote:

Comments/Problems:

RPI4 with 4GiB Ram.  This system is netbooted using RPI-UEFI 1.22 and
iPXE 1.2.x.

DNSMASQ send the RPI-UEFI to the RPI.  The RPI-UEFI pulls the arm64
EFI/ipxe.  The iPXE

shows a menu for booting into the Debian Installer.  The Installer
loads and starts the

interactive menu installation system.  Everything seems good until
input is required.  The

keyboard is dead.


You are probably using a serial port to monitor progress?

If so, you need the following appended on the kernel line to redirect to 
the serial console:


kernel debian-installer/amd64/linux TERM=linux ..  yadda yadda ... 
console=ttyS0,115200n -- console=ttyS0,115200n8

Bug#859509: partman-auto uses memory size to determine disk partitioning and fails on high ram installs

[Raymond Burkholder]

On 2020-02-28 1:41 p.m., Jelle de Jong wrote:
So I hit this issue installing on my HP server while with the same 
preseed succesfully installed on a few other systms


So I made a virtual machine put 20GB ram in there and an 8GB drive and 
could reproduce the problem.


How can we force partman-auto to not use memory size in its calculation.


Sometimes you  can't use partman-auto.  Sometimes you have to perform 
your own partition management.  This doesn't solve your problem, but 
does show how an example customized partitioning scheme might be 
configured.  This scheme does away with a swap partition. More ideas can 
be found at 
https://blog.raymond.burkholder.net/index.php?/archives/662-Using-Debian-PreSeed-files-and-a-PXEBoot-Server-to-Auto-Build-Hosts.html


There are many example schemes you can find with a search.

## **
# Partitioning scheme:
# Choices:
#partman-auto   partman-auto/choose_recipe  select
d-i partman-auto/choose_recipe  select  custom1

## **
# for internal use; can be preseeded
d-i partman-auto/expert_recipe  string  \
  custom1 ::  \
75 1000 100 ext4\
  $primary{ } $bootable{ }  \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /boot }   \
  . \
1000 4000 5000 ext4 \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ / }   \
  . \
5000 1 10 btrfs \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ btrfs } \
  mountpoint{ /var }\
  . \
4000 8000 1 ext4\
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /home }   \
  . \
1000 1000 4000 ext4 \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /tmp }\
  .





I found out it tries to make swap the same size as memory for suspend, 
but how to disable this??


d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
#d-i partman-swapfile/size string"{{ swap | default('512') }}"

Kind regards,

Jelle de Jong

Re: pxe booting qemu

[Raymond Burkholder]

On 2019-09-23 5:26 a.m., john doe wrote:

On 9/23/2019 12:41 PM, Michael Kesper wrote:

On 23.09.19 10:27, john doe wrote:
I'm currently using the netinst.iso file to install Debian as a 
guest VM

using Qemu.
This approach works fine if you want to install multiple VM on the same
host.
My goal with using PXE booting is to test how to install from the
network using Qemu, that way, I can get everything the way I like 
before

implementing PXE booting on my network.




Depending upon how far along you are with preseed and tftp and such, 
there might be some additional hints in:


https://blog.raymond.burkholder.net/index.php?/archives/637-DebConf-Debian-Installer-Preseed.html 

https://blog.raymond.burkholder.net/index.php?/archives/662-Using-Debian-PreSeed-files-and-a-PXEBoot-Server-to-Auto-Build-Hosts.html 

https://blog.raymond.burkholder.net/index.php?/archives/899-Debian-Preseed-Backport-Kernel.html 



I was able to boot and build totally automatically with a netboot file.

I was able to do this onto bare metal and into vagrant.  Should work 
with qemu/kvm.

Re: Creating my own Preseeded ISO with partman replaced by a ZFS step

[Raymond Burkholder]

On 2018-08-10 04:51 PM, Bailey Parker wrote:

I'd like to somehow modify the installer ISO that I create when preseeding to
include ZFS (so that before the package manager is configured, a ZFS pool can
be created), replace the partman step with some custom scripting that [creates
a zpool and sets up the datasets][2], and finally install zfs-dkms (also
zfsutils-linux and zfs-initramfs).
I use the late_command to install kernel modules, packages, mirrors, 
kernels, etc.  I have used this to install the zfs modules for 
non-root-zfs boots where zfs partitions are used in other capacities


The late-command allows package install as well as 'in-target' style 
commands, which could call scripts loaded via the preseed process.

In digging through mail archives, I also came across [this script][5], but it's
unclear to me how exactly that would fit into my desired workflow. This sounds
like you'd need to manually drop to a shell to install/setup ZFS.

could probably be handled by the preseed late_command in-target abilities

Is there a sane way to go about adding ZFS root support to my preseeded install
or should I abandon this and wait for better support?  If the latter, are there
steps I could take to add better support given my limited knowledge of d-i?



I've used SaltStack to build my various preseed scripts depending upon 
how physical or virtual machines are built.

RE: Beginner guidance sought - creating my own boot environment based on the Debian installer

[Raymond Burkholder]

You might be looking for debian preseed capability?  
https://www.debian.org/releases/stable/i386/apb.html

 

I pxeboot my servers, and feed them a preseed file to auto install the basic 
operating system to get to a minimal stable system.

 

I then use SaltStack to automatically install applications and associated 
configurations.

 

From: Mark Bettles [mailto:alo0taoran...@gmail.com] 
Sent: Saturday, December 16, 2017 20:25
To: debian-boot@lists.debian.org
Subject: Beginner guidance sought - creating my own boot environment based on 
the Debian installer

 

Hello,

I am looking to create a rescue system, there is active discussion on the topic 
here, 
https://forum.manjaro.org/t/linux-vs-windows-my-experiences-and-a-possible-idea/36377

I wish to go from boot, to the the start of the installer, where can I obtain 
documentation on this process?


-- 
This message has been scanned for viruses and 
dangerous content by   MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

You can tell me if I am 'beating a dead horse' but for the sake of 
argument, let us see where this goes 


On 12/11/2017 11:41 AM, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


hmm, almost like being asked to answer the question 'have you stopped 
beating your  yet?'.  One can't win by answering.


But things depend:

* servers can't can't be rebooted willy nilly

* when a package is updated with files open, the active process gets the 
existing files, and new processes get the new files, and is the patched 
package functional simultaneously in both activities (file formats, 
database schemas, )?


* does the patch introduce a functional change which may break 
operations (inverting logic on something, removing a flag, ... ) which 
breaks dependencies elsewhere





For my infrastructure, updates, of what ever kind, need to be
incorporated into the test/build/roll-out cycle.


If you have a test/build/roll-out cycle, then you presumably have a
local mirror (and if you don't, well, why not?) Just make sure your
servers only pull from that local mirror, and you're done.


I do have the local mirror (more like a package proxy at the moment),

But this mechansim does require a certain finesse.  running apt update 
&& apt upgrade against that local mirror/proxy may cause it to update to 
versions not quite desired, which leads to a specialized mirror with 
pre-cleared packages, but, well, I'm not that sophisticated quite yet.




[...]

So, as an accommodation,  a flag in the preseed mechanism to
enable/disable would be helpful.  But would need to be exposed in
maybe the expert mode menus, which I think was already mentioned.


What Raphaël was proposing is exactly that, yes.

Also, there is absolutely *no* technical difference between "the preseed
mechanism", "a low-priority debconf question", and "something in the
expert mode menus". None. Zero. Zilch.



--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

On 12/11/2017 11:51 AM, Steve McIntyre wrote:

On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


That's the point here, yes. We've had this discussion already several
times, and it was triggered by needs/desires of cloud providers. As a
*default*, it makes sense to have automated security updates to cover
the users who don't care, or don't know any better. Users with more
knowledge and hard requirements about downtime etc. should already be
managing this.


I think I got thrown off by the title 'unattended upgrades'.  If this is 
limited to security updates, I am more for it, but still scared of it.


Security updates tend to come in packages which have already have had 
other regular patches applied (except, I suppose in 'stable' versions), 
and sometimes one can get caught in functional changes.


I guess that is my greatest fear,  breakages due to updates.

But my experience has mostly been with regular package updates.  I 
haven't focused much on security updates.  Can security updates be 
applied with out generating dependency chains and their updates?




--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

> > So, as an accommodation,  a flag in the preseed mechanism to
> enable/disable would be helpful.  
> 
> You mean something like:
> 
> Template: pkgsel/update-policy
> Type: select
> Default: unattended-upgrades
> 
> pkgsel/update-policy=none thus seem the perfect preseed choice for your
> use case.
> 

Yes, thank you, that works for me.

Is there a dictionary somewhere where I can look these things up?  From
where did you get your Template extract?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

> 
> I think its totally adequate to assume people want automatic security
> updates, on all kinds of systems, unless they opt out.

Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.

For my infrastructure, updates, of what ever kind, need to be incorporated into 
the test/build/roll-out cycle.

Unless I misunderstand the intent of this thread.

So, as an accommodation,  a flag in the preseed mechanism to enable/disable 
would be helpful.  But would need to be exposed in maybe the expert mode menus, 
which I think was already mentioned.


> 
> And yes, this would be a change in behaviour we should prominently
> document, but nonetheless do.
> 
> 
> --
> cheers,
>   Holger, who has systems where he wants those and others where
>   not.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

install to harddrive, ignore connected usb, reboot with preseeded grub

[Raymond Burkholder]

Package: grub-installer
Version: 1.140+deb9u1

Is there a magic incantation for preseed files to install to a harddrive
when usb is present?

There are two stages:  usb appears as /dev/sda during install process, but
appears as something else, maybe /dev/sdd during normal boot

Therefore, the target drive might be /dev/sdb during install, but shows as
/dev/sda during normal boot.

My almost working preseed file has:


# install to /dev/sdb (main harddrive), when usb shows as /dev/sda
# these two lines are correct and working for the install process
d-ipartman-auto/select_diskselect  /dev/sdb
d-i partman-auto/disk   string  /deb/sdb

# grub 
# the first value is correct to install grub
d-i  grub-installer/bootdev  string /dev/sdb

# a couple of items I've seen both true and false, but do not seem to affect
the outcome:
d-i grub-installer/only_debian boolean false
d-i grub-installer/with_other_os boolean false

# I am not sure how to get these values to work properly, or maybe I am
missing something
d-i grub-installer/choose_bootdev   select  /dev/sda2
d-i grub-pc/install_devices multiselect /dev/sda2

=

The final boot should be /dev/sda2, but /boot/grub/grub.cfg seems to take on
/dev/sdb2.

The important piece here:  HOW does one get /dev/sda2 (instead of /dev/sdb2)
into /boot/grub/grub.cfg?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

debconf/priority=low has no effect on pxeboot

[Raymond Burkholder]

I picked up today's netboot:

https://d-i.debian.org/daily-images/amd64/daily/netboot/netboot.tar.gz

This is my pxeboot process via the dnsmasq tftp boot daemon:

Oct 16 15:28:53 dnsmasq dnsmasq-dhcp[2032]: PXE(ens160) 10.1.0.24
00:50:56:ae:8d:15 pxelinux.0
Oct 16 15:28:54 dnsmasq dnsmasq-tftp[2032]: error 0 TFTP Aborted received
from 10.1.0.24
Oct 16 15:28:54 dnsmasq dnsmasq-tftp[2032]: failed sending
/srv/tftp/pxelinux.0 to 10.1.0.24
Oct 16 15:28:54 dnsmasq dnsmasq-tftp[2032]: sent /srv/tftp/pxelinux.0 to
10.1.0.24
Oct 16 15:28:54 dnsmasq dnsmasq-tftp[2032]: sent /srv/tftp/ldlinux.c32 to
10.1.0.24
Oct 16 15:28:54 dnsmasq dnsmasq-tftp[2032]: file
/srv/tftp/pxelinux.cfg/422e2a4d-d50d-aa32-cf98-2e9abec076f2 not found
Oct 16 15:28:54 dnsmasq dnsmasq-tftp[2032]: sent
/srv/tftp/pxelinux.cfg/01-00-50-56-ae-8d-15 to 10.1.0.24
Oct 16 15:28:55 dnsmasq dnsmasq-tftp[2032]: sent
/srv/tftp/debian-installer/amd64/linux to 10.1.0.24
Oct 16 15:28:59 dnsmasq dnsmasq-tftp[2032]: sent
/srv/tftp/debian-installer/amd64/initrd.gz to 10.1.0.24

This is the pxeboot parameter file:

===
p# cat /srv/tftp/pxelinux.cfg/01-00-50-56-ae-8d-15
 D-I config version 2.0
default debian-installer/amd64/boot-screens/vesamenu.c32
DEFAULT auto
  SAY Booting new build 
LABEL auto
menu label ^Auto

# provides an expert style manual installation menu for creating seed files
kernel debian-installer/amd64/linux TERM=linux
boot-installer/install-recommends=false debconf/priority=low BOOT_DEBUG=3

# common append for all
append initrd=debian-installer/amd64/initrd.gz
prompt 0
timeout 3
=


With the debug=3, I get two or three command lines, but once I hit the
screen of selecting a language, no more Debug screens come available.

I am using files via port 3142 from a server providing apt-cacher-ng
service.  Maybe I need to purge packages there.

When I get to the partioner screen, I choose the default of everything on
one partition.

Once partitioning is done, the installation is automatic.  I don't even get
the screen that asks me if I want security packages or not (which blocks the
rest of the install, because when it ocmes time to install the security
packages, the installer can't reach that site, as it is blocked on our
network).

So are these known issues being worked through?

Looks like I may need to revert to using stretch until these netboot issues
are resolved, as I posted
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878553. Which is
preventing a fully automated boot.  

Thanx.








-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#878553: netcfg: "download debconf preconfiguration file"

[Raymond Burkholder]

Package: netcfg
Version: 1.145

I have been running pxeboot with preseed successfully for a while.
Recently, with a new version of netboot from (as of today 2017/10/13/):

https://d-i.debian.org/daily-images/amd64/daily/netboot/netboot.tar.gz

I am now getting a pop up box with "Download debconf preconfiguration file"
during the automated install process, which turns it into a non-automated
install process

This is what a pxelinux.cfg file looks like:

===
p# cat /srv/tftp/pxelinux.cfg/01-00-50-56-ae-8d-15
 D-I config version 2.0
default debian-installer/amd64/boot-screens/vesamenu.c32
DEFAULT auto
  SAY Booting new build 
LABEL auto
menu label ^Auto

# stretch / testing
kernel debian-installer/amd64/linux TERM=linux keymap=us
locale=en_US.UTF-8 country=BM language=en_US:en auto
url=tftp://10.10.0.10/seeds/vmware.testing.seed domain=qvs.bm
hostname=undefined interface=ens160 netcfg/get_ipaddress=10.11.0.24
netcfg/get_netmask=255.255.255.0 netcfg/get_gateway=10.11.0.1
BOOTIF=01-00-50-56-ae-8d-15

# common append for all
append initrd=debian-installer/amd64/initrd.gz
prompt 0
timeout 3
===

In the log, there are lines like (I am retyping them as they are in a
non-copyable window):

Date/time netcfg[25054]: INFO  Found interface ens160 with link-layer
address 00:50:56:ae:8d:15
Date/time netcfg[25054]: INFO: Taking down interface ens160

It is at this point, the interactive box pops up.

What settings do I need to change to make that go away?


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#771699: Provide A Preseed Option For Ignoring The Valid-Until Field of InRelease Files

[Raymond Burkholder]

> 
> Mostly "we take (working) patches"?
> 

Fair enough.  Would you be able give me push in the right direction and provide 
a hint as to which packages/files I should be looking at?

Bug#771699: Provide A Preseed Option For Ignoring The Valid-Until Field of InRelease Files

[Raymond Burkholder]

On Mon, 02 Nov 2015 18:58:34 +0100 Jonas Smedegaard  wrote:
> Quoting Cyril Brulebois (2015-11-02 17:20:04)
> > I've added this to my (not really ever-growing but yet non-empty) d-i 
> > to-do list, and I'll do the BTS dance (cloning and reassigning to 
> > debootstrap etc.) if I don't receive any negative feedback about the 
> > analysis above.

With the debian archives going through changes with sha1 deprecation, my 
pxeboot/preseed solution is failing due to reading Packages.xz and InReleases, 
amongst others.

So I attempted to revert to an older snapshot of the archives.  But I am 
encountering expiry issues.

Having this flag available in my preseed would be so handy at this point in 
time.  

How is the agenda for implementation?