+invirt-xen-config (0.0.60) unstable; urgency=low
+
+ * Fix autoinstalls to work around a modern d-i bug
+
+ Modern d-i (at least Debian Buster, and probably others) reads
+ /proc/consoles and adds entries to /etc/inittab to spawn a d-i
+ on each of them. With debconf/priority>=high (i.e. without
+ the menu showing, and with d-i autodriving through the items),
+ if there are multiple consoles, this results in the d-i's racing
+ to use /var/lib/dpkg/status to record what happens as they
+ run the postinst of each udeb, and as a result, menu items
+ fail and the autoinstall fails. See Debian Bug #944125.
+
+ We only set console=hvc0, but for reasons unknown, tty0 also
+ appears in /proc/consoles despite not being in /proc/cmdline,
+ and we don't seem to have control over that. The script that
+ reads /proc/consoles is /sbin/reopen-console, which also
+ happens to be the main rc script on sysinit in /etc/inittab.
+ That script (through a chain of other scripts) is also what
+ runs preseed/early_command if it's set.
+
+ Normally, preseed/early_command cannot run until way too late
+ to address this, because you don't have the preseed until several
+ tasks into the install by which point it will have failed.
+ However, if you get the quoting right, you can set it as a
+ boot argument and it will run before any of the menu items,
+ and in fact, before d-i has started.
+
+ Because /sbin/reopen-console ultimately is what runs
+ preseed/early_command, when the command runs, it is too late
+ to use sed to edit reopen-console, and you can't kill it
+ because it runs the rest of the process. At the point where
+ preseed/early_command runs, reopen-console has already found
+ the consoles and added d-i jobs for each of them to /etc/inittab.
+ However, it doesn't send the HUP to init until just after the
+ scripts including preseed/early_command are run.
+
+ Yank the tty0 job out from inittab just in the nick of time.
+ This should be safe for old distros because we have always
+ forced the desired console to hvc0; while the problem that
+ necessitates this kludge didn't exist in the past, removing
+ any inittab job for tty0 shouldn't have any noticeable effect
+ on them.
+
+ -- Mitchell Berger <mitchb@mit.edu> Wed, 01 Jan 2020 03:43:00 -0500
+
+invirt-xen-config (0.0.59) unstable; urgency=low
+
+ * Fix the fact that we can't bump RAM quotas above 2048M
+ (and acknowledge the reality that 2048M really isn't the rarest
+ thing to need these days)
+
+ Quoting from history:
+
+ """
+ invirt-xen-config (0.0.15) unstable; urgency=low
+
+ * Set the max memory to a really high number so we can bump it for users
+ * Pass the correct networking device to vif-invirtroute
+
+ -- Evan Broder <broder@mit.edu> Fri, 14 Nov 2008 00:03:47 -0500
+ """
+
+ i,i "640K ought to be enough for anyone."
+
+ -- Mitchell Berger <mitchb@mit.edu> Tue, 23 Jul 2019 18:50:00 -0400
+
+invirt-xen-config (0.0.58) unstable; urgency=low
+
+ * Support kickstart-based Fedora autoinstalls.
+
+ -- Quentin Smith <quentin@mit.edu> Sat, 15 Jun 2019 20:59:54 -0400
+
+invirt-xen-config (0.0.57) unstable; urgency=low
+
+ * invirt-database: Fix the autoinstall logic so that if we've
+ increased the memory temporarily for the autoinstall above
+ the machine's database setting, we also bring maxmem up to
+ the same level. Otherwise the machine doesn't turn on
+ because it's requesting to start with more memory than maxmem,
+ and this failure mode is silent to the user.
+
+ -- Mitchell Berger <mitchb@mit.edu> Sat, 02 Feb 2019 16:52:00 -0500
+
+invirt-xen-config (0.0.56) unstable; urgency=low
+
+ * vif-invirtroute: Kill arpspoof with SIGKILL when we're done. The
+ version in this distro (which is the latest beta from the
+ unmaintained upstream) tries to "clean up" when you normally
+ terminate it. This involves trying to perform an ARP lookup
+ without interfering to see what the MAC should've been and then
+ sending replies for that. This appears to cause a race depending
+ on whether the entry for the machine's old domain (if it's being
+ rebooted) is listed as <incomplete> in the ARP table or is totally
+ flushed. If you lose the race, it sends further gratuitous ARPs
+ telling the router that your MAC is all-zeros because of a bug
+ where it fails to check for an incomplete ARP entry. This is
+ believed to cause the bug that has plagued XVM for years where
+ you sometimes lose off-network connectivity on reboot.
+
+ -- Mitchell Berger <mitchb@mit.edu> Mon, 25 Jun 2018 22:04:00 -0400
+
projects / invirt/packages/invirt-xen-config.git / blobdiff