[07:40] We have Microsoft DHCP server that identifies Ubuntu machines with a long string as unique ID, but these strings change per restart, resulting new IP assigning to the machine. If we change the identifier in netplan settings to mac, it won't change the IP anymore; Is there any solution to use default setting, but not change in the unique ID? [08:31] moha: configuring the "dhcp-identifier" setting in netplan YAML is the recommended way to do this (as you already did) [08:32] what it does is setting systemd-networkd's "ClientIdentifier=" field (https://systemd.network/systemd.network.html#ClientIdentifier=) [08:32] sd-networkd provides one more option (duid-only) if you want to give this a try, e.g. using a sd-networkd override config. But I'd recommend sticking with netplan's "dhcp-identifier: mac" [14:25] Found'em. :) [14:26] I had a feeling people moved to Libera with it becoming a home to a lot of projects. [14:26] Do people still happen to provide guidance on using Netplan over here? [14:27] I'm currently in a bit of a sticky situation after using some of the older tools that were prevalent before Ubuntu started using Netplan and I suspect I may have caused a service that Netplan commands to go rogue and try things by itself. [14:27] As a consequence, I'm unable to get wifi working, after it having worked for some miraculous reason. [14:28] I initially went into grub's startup linux defaults to add the tag/switch that enabled the "ifnames" thing, because I wanted wlan0 back. But then that didn't work out all too well when it broke Ethernet. miraculously, wireless did work after I had discovered that my installed gdm3 & LXDE actually worked, somewhat, which was for the purpose of [14:28] trying VNC. [14:28] The wireless worked after configuring through the GUI, though. [14:29] sure. we'll try our best to help [14:29] I then instructed the networkd service to restart, and ever since, it has not worked for wireless again. After some mucking, I ended up reverting the GRUB file change I made, where I now have everything back to how it used to be. Ethernet works again, but I can not for the life of me figure out why wlan won't work, despite having literally copied [14:29] one of the example files :( [14:30] Thank you! I've described what I've done over the past day and a half, but I may have missed something. [14:30] would you mind sharing your netplan config from /etc/netplan/*.yaml as a first step? [14:30] Yes. I'm in the process of posting it to a bin [14:31] also, do you want to use your wifi via GUI (i.e. NetworkManager) or CLI? [14:33] https://www.toptal.com/developers/hastebin/ceqezowegu.yaml [14:33] I intend to use this only via CLI. [14:33] The window manager and desktop being installed was merely for trying VNC, which I hadn't completed, and was not intending to complete. [14:34] Wireless says "NetworkManager" as renderer there, but that's only an addition from about fifteen minutes ago. I've tried it extensively on just networked, and that was a last attempt at solving it myself. [14:36] This is my ifconfig output: https://www.toptal.com/developers/hastebin/raw/kariwuremo [14:37] I would have reinstalled Ubuntu Server if it wasn't for the fact that I know this will happen again in the future, and I would like to know what's up and how to troubleshoot this :) [14:40] if you're using it via CLI only, I'd recommend removing the "renderer: NetworkManager" stanza and let it all be managed by systemd-networkd/wpa_supplicant. Furthermore, I'd recommend removing the empty "match: {}" stanza, as this is a special case not needed if you're only applying this config to wlx00e04c818b01 [14:41] Okay. Those were both applied at last before I came here. Unfortunately, it didn't work without those either. [14:42] I have removed them from the active config. :) [14:44] so if you apply this configuraiton ('netplan try/apply') what's the status of 'networkctl' and 'systemctl status netplan-wpa-*.service'? [14:45] networkctl: eno1 is working and configured, wlx is stuck on 'configuring' [14:46] the other command returns this: https://www.toptal.com/developers/hastebin/raw/waworakuke [14:46] Which seems helpful. This was a command I didn't know about yet. [14:47] Running `sudo cat /run/wpa_supplicant/wlx00e04c818b01` returns a file not found [14:47] do you have the wpasupplicant package installed? – apparently yes. And it seems to be configured somewhere outside of netplan... [14:48] It is installed, yes. And yes, it seems to be. I suspect that's the issue. [14:48] I do not know where wpa_supplicant stores files beyond just /etc/wpa_supplicant.conf [14:48] which files do you have in /run/systemd/system/systemd-networkd.service.wants/ ? especially the *wpa* units? [14:49] sudo ls /run/systemd/system/systemd-networkd.service.wants/ | grep *wpa* [14:49] returns nothing [14:49] In fact, there's nothing there at all [14:52] interesting... there should be at least the netplan-wpa-wlx00e04c818b01.service unit/link that shows up in the logs pasted above... (after running 'netplan apply' or 'netplan generate') [14:53] does running `ps ax | grep wpa` give any clue about an additional wpa_supplicant daemon? [14:54] I see one line saying [14:54] > 868 ? Ss 0:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant [14:54] The other line is about grep and colour [14:55] is netplan generate or netplan apply supposed to run fine without root? [14:55] I just re-ran netplan generate and the file mentioned *is* there, along with an ovs cleanup service file [14:56] no, both need root privileges [14:56] okay... I think this 868 wpa_supplicant process shouldn't be there and is in conflict with netplan [14:56] Okay. [14:56] This service has then clearly persisted across reboots. [14:56] you must have setup some kind of networking service starting this [14:57] maybe you can check your systemd services... Maybe using something like `systemctl | grep -i wpa` [14:57] or `systemctl | grep -i network` [14:57] wpa supplicant service is running independently [14:59] maybe you can "systemctl stop" or even "systemctl mask" that wpa_supplicant service? [14:59] I have stopped the independent service, ran netplan apply, and now it runs properly [14:59] nice :) [14:59] I assume that means i need to remove wpa_supplicant.service from any auto-start? [14:59] just stopping it, it will probably pop up next reboot. so you either need to install whatever package containing this service or "systemctl mask" it [14:59] yes [15:00] I need to drop for an appointment now. But I guess you're on a good path! [15:01] Thank you! Good luck! Drop me a message when you can. I'd like to see if there's anything I can send you way :) [15:01] systemctl status now returns https://www.toptal.com/developers/hastebin/raw/anahemolod - a good return/result. :) [15:05] I checked the journalctl entry for wpa_supplicant.service and it tells me it's being started by just systemd [15:05] Jun 26 20:17:44 botlan-elitedesk systemd[1]: Starting WPA supplicant... [15:10] I ran systemctl disable wpa_supplicant.service, restarted, and checked again what the status was of the services containing wpa in the name. It now shows only wpa_supplicant in relation to the wireless interface configured by netplan. [15:12] however, when checking ifconfig I still don't have any sign of configuration having worked, and `systemctl | grep -i network` shows only a few service entries related to eno1 (the onboard ethernet.) [15:16] I now tried to apt purge wpasupplicant to try and get all old configs for itself out of the way, and I got [15:16] Purging configuration files for network-manager (1.22.10-1ubuntu2.3) ... [15:16] dpkg: warning: while removing network-manager, directory '/etc/NetworkManager/system-connections' not empty so not removed [15:16] Purging configuration files for wpasupplicant (2:2.9-1ubuntu4.3) ... [15:16] as a response. Somehow that doesn't sound right to me since I should not be using NetworkManager at all. [15:17] -- scrap that. the contents of the files point towards a much earlier attempt at fixing this, still mentioning wlan0 [15:24] dhclient does not seem to be receiving any DHCP lease from the DHCP server, but running it with -v (verbosity) does not really point out why, as the broadcast address is fine [15:26] And just like before there seems to be an entry in the startup log (when monitoring through the HDMI output) for 'waiting for network to be configured' which tells me that something is not completing successfully. I might try setting "optional: true" on the wxl just to avoid this long boot time issue. [15:57] Back but from HexChat now. :) [18:04] Something seems to be wrong with the hardware or alike because it's not even working in the ubuntu setup now