cyphermox | smoser: blackboxsw: rharper: I would have guessed that your network device is not virtio, but that shouldn't be a big deal /now/ since E1000 is also enabled in this case, and that looks like it's been detected. | 01:09 |
---|---|---|
smoser | cyphermox: well i had actually attached *no* network devices. which clearly should mean "all networking that will be configured is configured". | 01:28 |
cyphermox | smoser: I saw your command-line, but I don't think it behaved quite as expected | 01:32 |
cyphermox | or I don't understand what the kernel does, because it tries to rename an ens3 or eth0 that isn't there. | 01:33 |
smoser | what command line? | 01:37 |
smoser | there is no network device. | 01:37 |
smoser | i blieve there is no built-in network configuration in images any more. | 01:38 |
smoser | yeah, the cloud-images have nothing in /etc/netplan/ | 01:39 |
cyphermox | err, that's not "no network device" | 01:46 |
cyphermox | and in your paste: http://paste.ubuntu.com/25832717/ | 01:47 |
cyphermox | [ 1.848991] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56 | 01:47 |
cyphermox | [ 1.849784] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection | 01:47 |
cyphermox | [ 1.851505] e1000 0000:00:03.0 ens3: renamed from eth0 | 01:47 |
cyphermox | despite your line 1 being "xkvm --netdev= ..." | 01:47 |
cyphermox | unless you mean something else | 01:48 |
smoser | yea, so the --netdev= did the right thing and did not add a device itself, but qemu must add one if you dont have a network device | 01:48 |
smoser | and don't add '-nodefaults' | 01:49 |
cyphermox | on cloud images it is fair to expect that cloud-init will write your netplan config, I think | 01:49 |
smoser | either way, there was no configuration in /ec/ so no blocking and waiting for magical configuration to appear should have been done. | 01:49 |
cyphermox | sure | 01:49 |
smoser | cyphermox: yeah, your thought process is sane, except it explicitly did *not* write config. | 01:49 |
smoser | and when it does, it writes it pre-networking | 01:49 |
cyphermox | that's right, you disabled cloud-init | 01:49 |
smoser | so no blockign and waiting makes any sense. | 01:50 |
cyphermox | blocking and waiting is correct there; that is what you *should* do if there is config, to ensure that the device has had time to come up before you try to send packets over it | 01:50 |
smoser | well yeah. | 01:51 |
smoser | but there is no config. | 01:51 |
smoser | so blockin and waiting for config to appear is kind of pointless. | 01:51 |
smoser | or for network devices to appear. | 01:51 |
cyphermox | I agree there is a bug in wait-online though, which should not have waiting in your case with cloud-init disabled, because all the devices are unmanaged (since there is no config) | 01:51 |
cyphermox | that's a bug in wait-online | 01:51 |
cyphermox | https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1728181 | 01:51 |
ubot5 | Ubuntu bug 1728181 in systemd (Ubuntu) "systemd-networkd-wait-online waits when devices are unmanaged" [Undecided,New] | 01:51 |
smoser | right. | 01:51 |
cyphermox | but I don't think booting a cloud image with no metadata provider is something supported | 01:52 |
cyphermox | smoser: so, what were you trying to achieve? | 01:53 |
smoser | cyphermox: well its actually something we've spent way to much time on | 01:54 |
smoser | but that is explicitly required. | 01:54 |
smoser | cloud-init should disable itself entirely when not in a cloud | 01:55 |
smoser | and it does. | 01:55 |
cyphermox | right | 01:55 |
cyphermox | and that's working as expected | 01:55 |
smoser | but then if you have a network device you wait for 120 seconds for no reason. | 01:55 |
smoser | http://paste.ubuntu.com/25833672/ | 01:55 |
smoser | thanks for pointing out that it got a nic | 01:55 |
smoser | the above paste there is the same thing but with no nics at all | 01:55 |
smoser | at least then, systmed-networkd-wait-online does the right thing. | 01:55 |
cyphermox | ok | 01:55 |
cyphermox | well, the real question is: "Is a cloud image booted with no datasource something we should support", and I was told "no", if I understood correctly | 01:57 |
cyphermox | so yes, there's a bug in wait-online, and it's one we need to fix anyway, but it seems like you got a different answer than I did to the question above. | 01:57 |
smoser | well, i've had actual users ask to build an image that would boot in the cloud, but when booted with no cloud would let them log in. | 02:00 |
smoser | they'd put a local user in it with a known password | 02:00 |
smoser | then they'd have their image on cloud and local to debug and can login | 02:00 |
smoser | (or even no password but a shared ssh key) | 02:01 |
smoser | which makes sense. | 02:01 |
cyphermox | yeah, but then they'd have cloud-init running to create the user, no? | 02:01 |
cyphermox | the ssh key case we need to ignore since it requires network, in which case you do need to wait-online. | 02:02 |
cyphermox | the other one we'll fix once wait-online is fixed (bug above), and I expect we'd SRU that fix | 02:02 |
smoser | well, this would be someone created the imag themselfvs. | 02:02 |
smoser | i just did this locally | 02:03 |
cyphermox | well, it doesn't really matter at this level, that's "just" the wait-online bug | 02:04 |
cyphermox | maybe metoo it? | 02:04 |
smoser | $ qemu-img create -f qcow2 -b artful-cloud-image.img my.img | 02:04 |
smoser | $ sudo ~/bin/backdoor-image my.img -v --user=user1 --password=passw0rd1 | 02:04 |
smoser | # backdoor image is http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/backdoor-image | 02:04 |
cyphermox | smoser: don't worry about the process, I frankensteined my own image earlier to put in a root password | 02:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!