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
-    # rewrite banner
-    test -e /proxmox_install_mode || pvebanner || true
     if test -z "$2"; then
       : # no old version, nothing to do

pve-devel mailing list

Reply via email to