Don't reboot during cloud-init?

[jfmatth]

Win11 Pro + HV

So I'm noticing that if anything reboots the system during provisioning (i.e. cloud-init) that either the stream closes unexpectedly (i.e. "Stream removed") or MP never figures out what happened?

I had issues with trying to update the system packages and rebooting:

package_update: true
package_upgrade: true
package_reboot_if_required: true

BUT... if i removed the reboot required line, it all worked.

I can even now install my linux-azure package.

I just need to reboot once it's provisioned.

FYI, not sure if I'm doing anything wrong or just nature of MP and Windows?

[jfmatth]

Well... more information.

I guess the linux-azure package for hyper-v does some wonky IP stuff, cause MP reports two IP's now, even though the VM only has one:

PS C:\Users\john\scripts> multipass list
Name                    State             IPv4             Image
big                     Running           172.18.230.51    Ubuntu 24.04 LTS
                                          172.18.237.14
huge                    Running           172.18.238.49    Ubuntu 24.04 LTS
std                     Running           172.18.230.86    Ubuntu 24.04 LTS
                                          172.18.235.37

REBOOT huge

PS C:\Users\john\scripts> multipass list
Name                    State             IPv4             Image
big                     Running           172.18.230.51    Ubuntu 24.04 LTS
                                          172.18.237.14
huge                    Running           172.18.238.49    Ubuntu 24.04 LTS
                                          172.18.228.17
std                     Running           172.18.230.86    Ubuntu 24.04 LTS
                                          172.18.235.37

ubuntu@huge:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 52:54:00:49:2a:49 brd ff:ff:ff:ff:ff:ff
    inet 172.18.228.17/20 metric 100 brd 172.18.239.255 scope global dynamic eth0
       valid_lft 86118sec preferred_lft 86118sec
    inet6 fe80::5054:ff:fe49:2a49/64 scope link 
       valid_lft forever preferred_lft forever
ubuntu@huge:~$ 

Any thoughts?

[jfmatth]

Hi @ricab thanks for asking, NO.

I ran a quick test, building a testip VM via MP on HV (win11 pro).

First build

host.ics shows 172.21.221.150 testip.mshome.net # 2024 9 1 9 18 44 19 888 and that matches MP.

Reboot after install (due to linux-azure package requiring it)

host.ics shows 172.21.208.93 testip.mshome.net # 2024 9 1 9 18 48 0 729 and MP shows that as Public IP and Private IP as the old address.

Second reboot

MP continues to shows the public IP as the actual, and the Private IP is the original one it booted with.

For me not a problem, since MP and HV are doing what I need (update host.ics) file correctly. It's only when I reboot during the install that it mucks everything up - odd.

HTH, let me know if you need more info.

[ricab]

Thank you @jfmatth, that is useful info! I have added it to #3354, which we're using to track stale IPs.

[jfmatth]

@ricab I noticed on that issue, the IP's are all 192.168.... I had a lot of trouble with those addresses, namely not getting to the Internet. Assuming you're using the default switch?

I had this exact issue the other day on my laptop with Windows 11, same machine that showed all the testing above. Somehow, I was getting the same thing as the test's you're showing in that issue. I had to mess with the network settings to bring the IP range back to the 172.17-172.31 ranges and then it worked better.

Not sure if this helps, and if u need more info let me know. MP is amazing, HV is amazing and I think it's probably something very simple.

[ricab]

Hi @jfmatth, I am not sure why the IP range in that issue. It could have been a configuration by the user or some Windows default. Also, notice that it is 192.168.176.... in there, which need not overlap with home/office networks (usually 192.168.1.... or similar). If it did overlap, without the switch being an external switch (which the default switch isn't), then there would be collisions and things would get messed up.

[jfmatth]

Not sure either. HV is supposed to check that the range is OK, but every time the 192... range shows up, nothing works 😮

Also, my IPv6 was enabled on my network interface which was causing issues as well.

[jfmatth]

I can confirm that once the VM is built by MP and then issuing a multipass restart --all will work 100% of the time.

I have a batch file that creates a k3s cluster and i've been testing it dozens of times and not one issue with MP the whole time.

Thank you team for an amazing product, the GUI is so nice!