On Thu, Jan 11, 2024 at 10:10:43AM +0700, Max Nikulin wrote: > On 11/01/2024 03:25, Greg Wooledge wrote: > > On Wed, Jan 10, 2024 at 07:19:41PM +0000, Rodolfo Medina wrote: > > > Greg Wooledge <g...@wooledge.org> writes: > > > > What is the output of the "hostname" command? > > > > > > It's: `thinkpad'. > > > > > > > What is the output of "grep -F $(hostname) /etc/hosts"? > > > > > > 127.0.1.1 caterina-thinkpad.home caterina-thinkpad > > > > There's the problem, then. You do not have "thinkpad" as an entry in > > your /etc/hosts file, so the system is unable to lookup "the IP address" > > for its own hostname. X sessions tend to frown upon that. > > > > Adding "thinkpad" to the 127.0.1.1 line should take care of this. You > > can retain the other fields, and simply use thinkpad as a second alias. > > I would say that it is better to fix discrepancy between (likely) > /etc/hostname and /etc/hosts and to use a consistent name. If "thinkpad" is > the preferred one then update /etc/hosts otherwise check > > hostnamectl > > and update (as root) > > hostnamectl hostname caterina-thinkpad
There's clearly some back story here that we're not privy to. I wouldn't want to assume that nothing is using the name "caterina-thinkpad", so it would be wise to retain it. > 127.0.1.1 thinkpad.home.arpa thinkpad If something tries to look up "caterina-thinkpad" after you've removed that alias, then we're back to the same problem, just in reverse. The safe move is to retain both names, until the owner is sure that it's safe to discard one of them. Also, for the love of glob, WHY THE SYSTEMD bullshit... you change the hostname on Debian by editing the /etc/hostname file, and then by running the "hostname" command as root with the new name as its argument (or rebooting). I don't know why "hostnamectl" even exists as a concept. It's repulsive. It also fails to be init-system-agnostic, with no upside to compensate.
