=== cpaelzer_ is now known as cpaelzer
=== dbungert1 is now known as dbungert
=== woky_ is now known as woky__
=== woky__ is now known as woky_
[17:04] <Guest38> Hello everyone!  Proxmox 8.3.0 Debian 12 host and VM's with latest apt update.
[17:04] <Guest38> datasource_list: [ NoCloud, None ]
[17:04] <Guest38> Two NIC's, both are deliberately assigned IP's through rc.local. Everything is great on first boot, but on subsequent reboots, randomly, the IP assignments don't take - first NIC grabs a DHCP address (that it's not supposed to), and the second NIC doesn't take one of it's assigned IP's (multiple IP's for different subnets are assigned to second
[17:04] <Guest38> NIC). Sometimes, other second NIC IP's also don't take.
[17:04] <Guest38> cloud-init clean --logs --reboot makes everything happy for the next boot, but problems come screaming right back on subsequent reboots.
[17:04] <Guest38> This problem has been brutalizing me for days. I'm completely open to (non-free) direct help, if anyone has the magic solution (hopefully, this plead doesn't offend the rules or anyone's sensibilities). :-).
[17:04] <Guest38> Thanks!
[17:05] <Guest38> Version: 22.4.2-1+deb12u2
[17:22] <minimal> Guest38: did you look at /var/log/cloud-init.log to see what is happening?
[17:46] <Guest38> Yes, no errors or warnings, but deprecation notices and I get the sense maybe my config isn't optimal, which possibly is contributing to struggles. Is there a way to somewhat privately post the log without it being permanently logged by the Internet?
[18:04] <minimal> Guest38: I wasn't thinking about errors/warning, rather what the cloud-init.log shows regarding network configuration
[18:05] <minimal> normally with NoCloud then the ISO/FAT device provided a network-config YAML file and if that is not provided then cloud-init falls back to DHCP on an interface
[18:07] <minimal> I suspect rc.local is not consulted during boot until AFTER cloud-init has run
[18:08] <Guest38> Yes, indeed, I compared a working VM (because cloud-init clean --logs --reboot was ran) vs another VM that failed. The failed VM's 50-cloud-init.yaml is missing everything that cloud-init should have pushed into it. Unsure why, especially why clean works, but VM networking always fails after subsequent reboots.
[18:10] <Guest38> To your other point, yes, sort of smells like a timing issue, but that's my noob sense
[18:11] <Guest38> I'm open to another pair of eyes on my config, if anyone has a few minute$$ :-)
[18:15] <minimal> Guest38: I wasn't thinking of timing, rather is your rc.local writing network config file(s) or just configuring interfaces direct? (i.e. "ip" command)
[18:15] <Guest71> Guest38 rejoined at Guest71
[18:16] <minimal> Guest71: I  wasn't thinking of timing, rather is your rc.local writing network config file(s) or just configuring interfaces direct? (i.e. "ip" command)
[18:18] <Guest71> just configuring interfaces direct (i.e. "ip" command), only additional IP's and only to second NIC.  cloud-init is handling first NIC IPv4 (static) and IPv6 (DHCP), and second NIC (static).
[18:19] <minimal> Guest71: hint - cloud-init will write a network config file for the OS
[18:20] <Guest71> Yes, thanks, I see that.  My rc.local called script is not writing or touching the 50-cloud-init.yaml file
[18:22] <Guest71> On a related note, Debian cloud-init is v22.4.2, while Ubuntu cloud-init is 24.2.  Is there a way to use 24.2 on Debian, just to see if the newest version solves this problem?
[18:23] <minimal> I'm not familiar with the 50-cloud-init.yaml and so don't know what it relates to
[18:23] <Guest71> 50-cloud-init.yaml is for netplan, the replacement for /etc/network/interfaces
[18:23] <minimal> ok