[03:14] ok seems like I managed to use this cloud-localds properly [03:14] I can log in to my new server === xispita_ is now known as xispita [12:04] hi, seems like I managed to use cloud-localds properly. Can I just convert the image to raw and dd to the target machine? [12:40] imi: no, the idea with cloud-localds is that the data source disk needs to remain attached. Otherwise when the VM reboots, it won't know what it is. [12:41] ok so it does not update the rootfs? aqre you sure? [12:41] The rootfs will be changed on first boot, but I don't think it "locks it in" or anything. The point is that you can clone a VM and it'll do the right thing if it sees a different instance ID. [12:42] If you want to lock a VM in to its identity and you're in a position to modify the filesystem, then you can use nocloud instead. [12:42] Write to /var/lib/cloud/seed/nocloud/meta-data and /var/lib/cloud/seed/nocloud/user-data. [12:44] Oh sorry, that's inaccurate. [12:44] cloud-localds also uses nocloud [12:44] https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html [12:45] not to confuse with mc-cloud ... which is the highlander 🙂 [12:46] Maybe it is OK to remove the data source disk then. I'm not sure now, sorry. [13:21] gpg: key 7FF3F408476CF100: new key but contains no user ID - skipped -- that seems like a bug [13:30] has anyone using LXD run into a problem where LXD bridges suddenly for no real reason become "UNAVAILABLE" while multipass, etc. are present? I ask because my LXD bridges seem busted because I needed multipass for snapcraft, but now my LXD bridges don't work and show as 'unavailable' [13:30] teward, snap changes ? (did lxd get updated underneath you ?) [13:31] ogra: it might've but that wouldn't explain why it can't load bridges anymore [13:31] unless lxd erased that functionality which makes zero sense [13:32] oh i somehow thought they were temporary unavailable [13:32] ogra: they are but they're listed as "UNAVAILABLE". Reboots, etc. don't return them [13:32] it should surely not trash them permanently with an update [13:32] and i don't think the snap has adequate logging to help me debug that, unless you know where those logs'd be [13:33] snap changes ... then snap change [13:33] and indeed journalctl ... [13:33] oh this explains it [13:33] looks like the internal dnsmasq is hosed [13:33] ouch [13:33] ep 29 09:31:45 tau-volantis lxd.daemon[2554]: time="2022-09-29T09:31:45-04:00" level=error msg="Failed initializing network" err="Failed starting: The DNS and DHCP service exited prematurely: Process exited with non-zero value 1 (\"dnsmasq: --auth-server required when an auth zone is defined.\")" network=InternalDHCP project=default [13:34] Sep 29 09:31:45 tau-volantis lxd.daemon[2554]: time="2022-09-29T09:31:45-04:00" level=error msg="Failed initializing network" err="Failed starting: The DNS and DHCP service exited prematurely: Process exited with non-zero value 1 (\"dnsmasq: --auth-server required when an auth zone is defined.\")" network=static-local project=default [13:34] so looks like a major LXD bug/regression in the update [13:34] who do i even yell at about that... stgraber perhaps? [13:35] or someone from his team. yeah [13:49] sdeziel: does that maybe ring a bell? ^ [13:50] We haven't changed the way we spawn dnsmasq in a long time though I believe we have made a change so that startup failures are better reported now [13:51] teward: can you show `lxc network show static-local` ? [13:51] stgraber: unfortunately, no [13:54] stgraber: sdeziel: once i am at my pc again yes. ft job all hands meeting [13:55] so like a couple hours. the *only* reason i went to the office today >.> [13:57] the best explanation for the behavior would be a raw.dnsmasq on that particular network which was already causing dnsmasq to crash prior to the update but which is now correctly being reported and so is preventing dependent instances from starting up [13:58] stgraber: could be leftover from the old system i'll pull the config down. [13:58] once this meeting is over [14:04] stgraber: i wonder, did older LXD with bridges have taw [14:04] raw.dnsmasq values entered*? [14:05] when lxd builds the bridge I mean. [14:05] hmm, no, LXD never sets it itself [14:05] then i bet you it isnt set or if it is its old. [14:07] but we'll find out. both InternalDHCP (handled by an isc dhcp server in the lxd network) and static-local are lxd born bridges from a while ago so i'll pull both configs and share in a bit [15:45] xnox: Hmm, so prepending a stanza with a decremented Version (i.e. ~test appended) doesn't work: debootstrap uses that stanza to fetch the package and install it in the chroot, after which point `dpkg` sees the version built into the package (which isn't decremented), and so the bug doesn't trigger. [16:04] hmmmm.... but if some other package wants the big version; installing that should fail [16:04] no? [16:05] i.e. if i prepend libext2fs2 1.46.5-2ubuntu1.1~noexistent in the packages file, it should find and use 1.46.5-2ubuntu1.1 version for later one [16:05] in the packages file, instead of failing to download ~nonexistent one [16:10] Ooh, right, let me change Filename too [16:12] OK, yeah, that's looking more promising, thanks! [16:14] I'm also running into problems running autopkgtests locally. I ran `autopkgtest-buildvm-ubuntu-cloud` and then `autopkgtest debootstrap -- qemu autopkgtest-kinetic-amd64.img` and autopkgtest reported 6 tests out of 58: should I be running them differently, somehow? [16:14] 6 tests _failed_ === EnchanterTim is now known as Linux [16:30] stgraber: sdeziel: found that there IS some raw added to dnsmasq but i don't know / remember where it came from. https://pastebin.ubuntu.com/p/dHbczfdbc2/ [16:31] not sure what i need to do to fix that now though. [16:32] teward: per the error, sounds like you need an auth-server key to match that auth-zone entry [16:35] i'll have to prod that then, i don't know where auth-zone came from [16:37] stgraber: looks like a resurgence of https://github.com/lxc/lxd/issues/8905 which is odd [16:37] Issue 8905 in lxc/lxd "dnsmask process exited prematurely if raw.dnsmasq auth-zone set when using core20 snap" [Closed] [16:37] guess i get to unset some things and test. [16:38] ... after food. [16:47] stgraber: i unset auth-zone but left the dns loop detection part in and got my bridges back. We might need to document this because i think this is inner-workings stuff that goes ignored until latest-update / version of the LXD snap. Might post a note about it on the snap focumrs and such. [17:06] teward: to be clear, we haven't changed what we feed dnsmasq, it just means that until this update, your dnsmasq just crashed immediately and wasn't running at all :) [17:30] stgraber: you mean without breaking the bridges and hardfailing them [17:30] interesting though that the errors weren't previously crit-failures so :P [17:30] right, they may have gotten logged but that was it, which definitely would hide some pretty critical stuff, hence the fix in 5.6 :) [17:32] right, makes sense. [17:32] at least the dns loop detection argument works without breaking xD [17:51] where do the cloud images search for the seed image? can I provide it on an usb pendrive? [17:53] imi: there is #ubuntu-cloud [17:53] thanks [17:55] hi all. I am having a problem with a relatively simple rsyslog configuration. It's here: https://gist.github.com/fbb1e10ccd1665cd20503abfc17c7880 - the problem is that daemon.debug messages are still getting logged from hostname "wap1". Any advice? === jgee11 is now known as jgee1 [18:35] xnox: https://pastebin.ubuntu.com/p/fqHR348szF/ <-- autopkgtest which does what you proposed [22:10] I'm getting 404s with `apt-get install sagemath` on an ubuntu-20.04 image on Github. Specifically: Err:29 http://azure.archive.ubuntu.com/ubuntu focal-updates/main amd64 libgs9-common all 9.50~dfsg-5ubuntu4.5 [22:10] 404 Not Found [IP: 52.147.219.192 80] [22:10] Err:33 http://azure.archive.ubuntu.com/ubuntu focal-updates/main amd64 libgs9 amd64 9.50~dfsg-5ubuntu4.5 [22:10] 404 Not Found [IP: 52.147.219.192 80] [22:10] Err:79 http://azure.archive.ubuntu.com/ubuntu focal-updates/main amd64 ghostscript amd64 9.50~dfsg-5ubuntu4.5 [22:10] 404 Not Found [IP: 52.147.219.192 80] [22:10] Fetched 661 MB in 14s (46.5 MB/s) [22:10] E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/g/ghostscript/libgs9-common_9.50~dfsg-5ubuntu4.5_all.deb 404 Not Found [IP: 52.147.219.192 80] [22:10] E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/g/ghostscript/libgs9_9.50~dfsg-5ubuntu4.5_amd64.deb 404 Not Found [IP: 52.147.219.192 80] [22:10] E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/g/ghostscript/ghostscript_9.50~dfsg-5ubuntu4.5_amd64.deb 404 Not Found [IP: 52.147.219.192 80] [22:11] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? [22:11] Error: Process completed with exit code 100. [22:11] Anyone else run into this? [22:20] evilyoda: try: sudo apt update ; sudo apt install sagemath [22:20] hah [23:05] does github CI run on azure then? [23:05] oh that mirror is public