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 email@example.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel