Hostname on RPi client is always the first octet of the IP address

[intelliant01]

Hostname on Pi client is always the first octet of the IP address.
Server address is 192.168.2.97/24
Hostname is always 192.
Defining HOSTNAME=ltsp%{IP} explicitly in ltsp.conf fixes it to the expected ltsp+last octet of IP address e.g. ltsp115
This problem manifests only on Pis and not on x86 clients.

[alkisg]

Could you please:

1. Upload the contents of your /run/net-*.conf on a booted client,
2. and the contents of cat /proc/cmdline,
3. and test with the latest version from the ltsp proposed ppa?

[intelliant01]

Updated ltsp from the proposed ppa. Do note that herein I am trying to get Ubuntu Mate 20.04 image working on the RPi.

1. When booting in rw mode into the chroot, the displayed hostname at the top of the login screen is 192. Earlier this was 192.
   Logged in as root and the requested contents are -

---

2. When booting in ltsp mode i.e. the image, the displayed hostname at the top of the login screen is the entire IP address - 192.168.2.105. Earlier this was 192.
   Logged in as a user teacher1 and the requested contents are -

---

3. Added HOSTNAME=mss%{IP} to ltsp.conf which fixed the displayed hostname on login screen as well as the terminal prompt to ms105. This used to work earlier as well.
   Logged in as user teacher1 and the requested contents are -

[alkisg]

As you can see, the contents of that file mention that HOSTNAME=192.
This is NOT set by LTSP. It's sent by your DHCP server and it's set by initramfs-tools.
LTSP then just reads the HOSTNAME from that file.

What is the output of this command, as root on the client?

sudo /usr/lib/klibc/bin/ipconfig -n eth0

If it says hostname=192, then the issue is in your DHCP server configuration.
If it doesn't say hostname=192, then it would be a bug in initramfs-tools; possibly Ubuntu-specific as it doesn't happen in Raspberry Pi OS.

[intelliant01]

sudo /usr/lib/klibc/bin/ipconfig -n eth0

If it says hostname=192, then the issue is in your DHCP server configuration.

It doesn't return hostname, not even the key/label, in any of the tested scenarios - (proxy or non-proxy) x (x86 or rpi). I even tested the non-proxy scenario to have better control over the DHCP part.

However, it does return a key-value pair for host in 2 scenarios - proxy x (x86 or rpi) only when I have a hostname explicitly defined in the DNS server which is also functioning as the authoritative DHCP server.
And that value is being honoured as is by ltsp. That's fine.

If it doesn't say hostname=192, then it would be a bug in initramfs-tools; possibly Ubuntu-specific as it doesn't happen in Raspberry Pi OS.

Since there is no key-value pair except for host only when it is explicitly defined in the DNS server, and yet everything is working fine with x86 + Ubuntu 18.04 image, do you still think that there could be a problem of initramfs-tools in RPi + Ubuntu 20.04 image case?

As you can see, the contents of that file mention that HOSTNAME=192.
This is NOT set by LTSP. It's sent by your DHCP server and it's set by initramfs-tools.
LTSP then just reads the HOSTNAME from that file.

Prior to upgrade from the proposed ppa, this did seem consistent.
Do note the scenario 2 (RPi in ltsp mode) above at #582 (comment). Prior to upgrade, the login screen did show 192 and so did the terminal prompt. But after upgrade, though it shows HOSTNAME='192' yet the login screen shows 192.168.2.105 and the terminal root@192. So there is definitely some logical change now within ltsp that may need attention.

Whenever HOSTNAME value is blank i.e. HOSTNAME='', ltsp takes over and renders the default ltsp%{IP} name for the client.
HOSTNAME='192' is only being sent to RPi by dnsmasq and not to x86 systems everything else remaining same, hence this seems to be a dnsmasq+RPi specific issue. I shall take this part to the dnsmasq ml.

---

Scenarios tested:

[alkisg]

When dnsmasq is used in proxy mode, ipconfig returns the hostname from the REAL dhcp server, e.g. the router.
What are you using as the real dhcp server when you're testing the proxy dnsmasq mode?

[intelliant01]

When dnsmasq is used in proxy mode, ipconfig returns the hostname from the REAL dhcp server, e.g. the router.

So initramfs-tools seem consistent in their function in all these scenarios. Do you see hostname : when booting a Raspberry OS client in non-proxy mode?

What are you using as the real dhcp server when you're testing the proxy dnsmasq mode?

dnsmasq from the gateway server of my network.

[alkisg]

Yes, host is properly defined; I'm using the stock ltsp dnsmasq configuration, in the 192.168.67.x internal subnet:

root@raspberrypi:~# /usr/lib/klibc/bin/ipconfig -n eth0
IP-Config: eth0 hardware address b8:27:eb:c4:a5:4a mtu 1500 DHCP RARP
IP-Config: eth0 complete (dhcp from 192.168.67.1):
 address: 192.168.67.100   broadcast: 192.168.67.255   netmask: 255.255.255.0   
 gateway: 192.168.67.254   dns0     : 192.168.67.1     dns1   : 0.0.0.0         
 host   : rpi                                                             
 domain : ioa.sch.gr                                                      
 rootserver: 192.168.67.1 rootpath: 
 filename  : 

...where my dhcp-hosts/plinet.csv contains:

b8:27:eb:c4:a5:4a,set:plinet,192.168.67.100,rpi

[intelliant01]

I guess if you remove the contents from the csv, host will vanish.

If that's the case, then there is nothing to probe further into initramfs-tools.

But after upgrade, though it shows HOSTNAME='192' yet the login screen shows 192.168.2.105 and the terminal root@192. So there is definitely some logical change now within ltsp that may need attention.

Your thoughts on this?

[alkisg]

I guess if you remove the contents from the csv, host will vanish.

Right.

Your thoughts on this?

I'm not sure what's wrong with root@192, what did you expect to see other than user@hostname? Also above, you said that the displayed hostname at the top of the login screen is 192. Earlier this was 192. which is the same thing.
Is anything lost due to github punctuation?

Regarding the Ubuntu MATE login screen, I don't know how it works, maybe it shows the IP in some cases, e.g. when it considers the hostname to be invalid (all numbers)?

[intelliant01]

Nothing wrong with root@192. It is as expected.

What has changed after the upgrade from the proposed ppa is the "string" displayed on the login screen. Earlier it was just 192. After ltsp upgrade from the proposed ppa, it is showing 192.168.2.105. So some change in ltsp has caused this.

[alkisg]

The related change is this one: d4a67e7

If your DHCP server sends hostname=192.168.2.105, LTSP eventually runs hostname 192.168.2.105.
This means that your hostname is:

• full (hostname -f): 192.168.2.105
• short (hostname -s): 192
• domain (hostname -d): 168.2.105

So, lightdm displays your full hostname, including its "domain name" of 168.2.105. Everything is working as expected except for your main dnsmasq configuration (which also might be working as expected, if you've set some option to provide the IP as hostname; see what the dnsmasq list says about that).

[intelliant01]

Related dnsmasq mailing list post - https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015875.html

[alkisg]

From what I can see, in https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015882.html you uploaded the wrong configuration files, as they are the ones from the LTSP server, instead of the real DHCP server which causes the issue.

Proxy dhcp servers cannot send hostnames; they are sent from real dhcp servers.

[intelliant01]

I checked again. I have uploaded the correct file (ltsp-dnsmasq-noproxy.conf) when ltsp server is in fact the authoritative DHCP server. The problem manifests in both the proxy and non-proxy modes with the RPi as I have shared in the screenshots herein above.

[alkisg]

Ah, sorry I misunderstood then. Heh, it seems I can't reproduce any of the issues that you're reporting! Running dnsmasq in real DHCP mode, and ipconfig -n eth0 from an rpi, doesn't cause the hostname=ip issue here.

Could it be related to the recent dnsmasq patches? Have you tried with the stock Ubuntu 20.04 dnsmasq?

[intelliant01]

Running dnsmasq in real DHCP mode, and ipconfig -n eth0 from an rpi, doesn't cause the hostname=ip issue here.

I am using a RPi 4B. And yours is 2B? But it is eerie that my hardware seems to be from another world always (at least 2 of 2 cases now). ;)

Have you tried with the stock Ubuntu 20.04 dnsmasq?

Yes same result. Rather this was the first problem I had noticed when testing with a RPi but since there is an easy workaround via HOSTNAME in ltsp.conf, I considered this a lesser demon to address than the pxe-service issue related to EFI boot in proxy mode.

[alkisg]

At my office I have an rpi2b, the one I tested with. At home I also have rpi3 and rpi4.
I might test Ubuntu MATE on rpi4 for 22.04, we'll see later on as I'm a bit busy currently.

[intelliant01]

@alkisg pls try to address this -

There is definitely something wierd in the way dnsmasq's handling of serving the IP address as hostname works when one is not explicitly set anywhere. Leaving this to the dnsmasq ml.

Why would the same ltsp server config, without HOSTNAME explicitly defined in ltsp.conf for RPi or x86 clients, and without any other source of hostname with dnsmasq working in proxy or non-proxy mode produce different results for RPi and x86 clients ? -

RPi - IP address - e.g. 192.168.67.105
X86 - ltsp + <last octet of the IP address> - ltsp134

Ideally for RPi it should have been ltsp105, isn't it?

Isn't this something ltsp is handling implicitly?

As stated earlier, when I define HOSTNAME=ltsp%{IP} in ltsp.conf in the Clients section then both RPi and x86 display ltsp105 and ltsp134 respectively. So the override works fine.

I rest with this note and am fine with the workaround via ltsp.conf.

[alkisg]

without any other source of hostname

LTSP reads HOSTNAME from /run/net*.conf, which comes from the initramfs DHCP request, which is outside the LTSP code base.
Since that one is already wrong, LTSP is not to blame here.
Of course, if you set HOSTNAME=ltsp%{IP}, then you're asking LTSP to ignore the DHCP result, which is what's causing the issue.

I don't think this issue is related to the LTSP code; I'll convert it into a discussion.
It might be related to dnsmasq, or it might be related to initramfs-tools, or even to Ubuntu-specific netplan code inside the initramfs, and it needs to be solved there, not in LTSP...