From 3297717b099fdbe26bc58d4124b8d2435ce6fc68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org>
Date: Tue, 30 Jul 2019 17:07:34 -0400
Subject: [PATCH] reformat and refer to trac for routing issue
---
tsa/howto/upgrades/buster.mdwn | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/tsa/howto/upgrades/buster.mdwn b/tsa/howto/upgrades/buster.mdwn
index 8e492dba..1607abf6 100644
--- a/tsa/howto/upgrades/buster.mdwn
+++ b/tsa/howto/upgrades/buster.mdwn
@@ -105,21 +105,24 @@ Issues
Pending
-------
- * Warning: upgrading (restarting) openvswitch will mean all guests lose network.
-
- * At least on kvm5, brpub was having issues. Either ipv4 or ipv6 address was missing,
- or the v6 route to the guests was missing. Probably because the ipv6 route
- setting failed since we set a prefsrc and that was only brought up later?
-
-
- Rewrote network/interfaces to set things up more manually.
- On your host, check if brpub has both ipv4 and ipv6 addresses after boot before
- launching VMs, and that is has an ipv6 route into brpub with the configured
- prefsrc addr. If not, fiddle likewise.
+ * upgrading restarts openvswitch will mean all guests lose network
+
+ * At least on `kvm5`, `brpub` was having issues. Either ipv4 or ipv6
+ address was missing, or the v6 route to the guests was missing.
+ Probably because the ipv6 route setting failed since we set a
+ prefsrc and that was only brought up later?
+
+ Rewrote `/etc/network/interfaces` to set things up more manually.
+ On your host, check if `brpub` has both ipv4 and ipv6 addresses after
+ boot before launching VMs, and that is has an ipv6 route into `brpub`
+ with the configured `prefsrc` address. If not, fiddle
+ likewise.
+
+ See [ticket #31083](https://trac.torproject.org/projects/tor/ticket/31083) for followup on possible routing issues.
- * On physical hosts witch /etc/sysfs.d/local-io-schedulers.conf, note that 'deadline' no
- longer existsts. Probably it is also not necessary as Linux might pick the right
- scheduler anyhow.
+ * On physical hosts witch `/etc/sysfs.d/local-io-schedulers.conf`,
+ note that `deadline` no longer existsts. Probably it is also not
+ necessary as Linux might pick the right scheduler anyhow.
* the following config files had conflicts but were managed by Puppet
so those changes were ignored for now. eventually they should be
--
GitLab