We have the pvebanner.service in places which ensures this gets
called on boot before the getty target.
Thus this only had an effect if we changed the nodename to IP mapping
_and_ upgraded/reinstalled pve-manager, then switching to another TTY
would show the updated IP. But as this a) is for sure not a common
triggered path and b) a IP change suggest a reboot either way, and if
the user can handle it on their own without a reboot, they should be
able to also handle an outdated /etc/issue until the next reboot.
Also for PVE ontop of plain Debian a reboot is needed, so that the
PVE kernel gets booted, so this shouldn't be an issue ther neither.
Signed-off-by: Thomas Lamprecht <t.lampre...@proxmox.com>
---
debian/postinst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/debian/postinst b/debian/postinst
index 43011899..5f827933 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -105,9 +105,6 @@ EOF
deb-systemd-invoke start pvesr.timer >/dev/null || true
fi
- # rewrite banner
- test -e /proxmox_install_mode || pvebanner || true
-
if test -z "$2"; then
: # no old version, nothing to do
else
--
2.14.2
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
