[00:01] <vegardx> Using NoCloud, what part of meta-data or keys take presence of values provided in SMBIOS or values defined in meta-data and user-data? I was hoping to create a somewhat generic user-data, but be able to provide the instance with a unique hostname using the parameters in SMBIOS.
[00:02] <vegardx> Unless I've misunderstood something I have to basically specify the same thing twice. Which means I have to generate a new disk image for every machine.
[00:02] <vegardx> (using KVM with libvirt and virt-install locally)
[02:23] <blackboxsw> vegardx: could you provide a bit more information on that. NoCloud can obtain metadata from a seedfrom url so you can provide dynamic metadata from custom urls if we wish.
[02:23] <blackboxsw> if *you* with I mean https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[02:23] <blackboxsw> e.g. you can pass this option to QEMU: ...    -smbios type=1,serial=ds=nocloud-net;s=http://<IP_ADDRESS>:8000/
[02:24] <blackboxsw> 's' a short option for  seedfrom= which can be customized with whatever meta-data and user-data you want to provide
[02:26] <blackboxsw> vegardx: and for more generic userdata you could use jinja templates in your cloud-config that react to the underlying environment of a system (dhcp hostnames, ip address range, distro etc) https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data
[02:29]  * blackboxsw has to fall off into the end-of-week abyss. see folks later
[17:01] <LongLiveCHIEF> 👋 new to the room! I'm the maintainer of the official octoprint docker image. Came here as a result of some testing I'm doing to prepare new user docs for the octoprint image
[17:03] <LongLiveCHIEF> what I'm running into atm, is user-data being ignored at boot on raspberry-pi devices when it's in the root of the `system-boot` partition, and i'm wondering if I should be placing user-data in the writable partition instead
[17:10] <LongLiveCHIEF> i've spent a few days getting up to speed with cloud-init, so i'm familiar with the boot stages, user-data and meta-data formats, etc..  don't be afraid to ask low-level questions if you need more info from me


[16:02] <penguin42> it's a shame there doesn't seem to be a way to link sourceforge bug reports into launchpad
[16:04] <TheLordOfTime> how so?
[16:04] <TheLordOfTime> penguin42, if there's an upstream tracker i think it can be linked?
[16:04] <TheLordOfTime> if the upstream project is set to use external stuff
[16:04] <TheLordOfTime> and then you provide a link...
[16:04] <TheLordOfTime> no?
[16:07] <penguin42> but if there is no upstream project in lp, if it's just a bug in an ubuntu package for which the upstream is in sf?
[16:07] <TheLordOfTime> good question.
[16:07] <TheLordOfTime> i'd just link "upstream"'s bug as a comment
[16:08] <TheLordOfTime> so its somewhere in the bug it was upstreamed.
[16:08] <TheLordOfTime> but... that's if it doesn't exist in LP
[16:09] <penguin42> yeh, I'm just going through universe type things that haven't seen any updates in years, some of them have sourceforge projects with bug trackers
[16:10] <TheLordOfTime> penguin42, were they synced form Debian?
[16:10] <TheLordOfTime> from*
[16:10] <TheLordOfTime> i know of a few upstream projects that only listen to the Debian BTS and don't bother chekcing Ubuntu's
[16:11] <penguin42> TheLordOfTime: Yeh, although I think in a lot of these cases the upstreams are pretty much dead
[16:11] <TheLordOfTime> which package if I might ask?
[16:12] <penguin42> TheLordOfTime: bug 376859
[16:12] <TheLordOfTime> (I know there's one package, display-dhammapadda, of which i'm apparently their go-to bugcontroller, which was recently taken over by someone, and its upstream tracks debian, LP, and fedora)
[16:12] <ubot2`> Launchpad bug 376859 in cccc (Ubuntu) "CCCC crashed on AMD64" [Medium,Triaged] https://launchpad.net/bugs/376859
[16:12] <TheLordOfTime> penguin42, https://launchpad.net/ubuntu/+source/cccc
[16:12] <TheLordOfTime> there's changes to the package over time...
[16:12] <TheLordOfTime> albeit minor changes...
[16:12] <penguin42> and looks like Colin has created an upstream bug for it, 3 years ago https://sourceforge.net/tracker/?func=detail&aid=2880497&group_id=7763&atid=107763
[16:12] <TheLordOfTime> ah okay.
[16:12] <TheLordOfTime> if upstream's dead, well...
[16:12] <TheLordOfTime> then upstream's dead :P
[16:13] <TheLordOfTime> was this imported/checked from Debian?
[16:13] <TheLordOfTime> yep, they're all debian imports
[16:13] <penguin42> but I've got a small collection of others as well
[16:13] <TheLordOfTime> wonder if this is reported there.
[16:14] <penguin42> didn't see this one reported in debian
[16:14] <TheLordOfTime> may want to consider reporting it there.
[16:14] <TheLordOfTime> (just so debian's aware the bug exists)
[16:14] <TheLordOfTime> since it appears these're debian imports, so a fix'd hit Debian before it hits Ubuntu.
[16:14] <TheLordOfTime> but...
[16:14]  * TheLordOfTime yawns
[16:14] <TheLordOfTime> bleh, i need more  coffee.
[16:15] <penguin42> TheLordOfTime: It looks like Colin is the maintainer for the package anyway, but hey Erwan put a bug in there 3.5 years ago - it seems a shame not to merge it
[16:15] <TheLordOfTime> mhm
[16:15] <TheLordOfTime> penguin42, any idea how widely used this is?
[16:15] <TheLordOfTime> if upstream's dead, well...
[16:16] <penguin42> nope, no idea
[16:16] <TheLordOfTime> "C and C++ Code Counter, a software metrics tool"
[16:16] <penguin42> nod
[16:17] <penguin42> I've been doing a bunch of universe fixes for crashers lately - but then I started looking at the patch queue, there's about 1500 bugs with patches that aren't going anywhere
[23:37] <garyseven> Could someone explain to me why bug #225732, a kernel null-ptr dereference resulting in system crash, is only assigned 'medium' priority?
[23:37] <ubot2`> Launchpad bug 225732 in linux (Ubuntu) "Unable to handle kernel paging request at ffff88087eee2ff8 RIP:; RIP: e030:[<ffffffff883b0080>] [<ffffffff883b0080>] :cpufreq_stats:cpufreq_stats_update+0x40/0x70" [Medium,Confirmed] https://launchpad.net/bugs/225732
[23:38]  * penguin42 looks
[23:38] <garyseven> aiee, i meant bug #1089794
[23:38] <ubot2`> Launchpad bug 1089794 in linux (Ubuntu) "kernel null pointer dereference on dell pe r210s" [Medium,Confirmed] https://launchpad.net/bugs/1089794
[23:38] <penguin42> oh an ancient one as well
[23:39] <penguin42> oh
[23:42] <penguin42> garyseven: https://wiki.ubuntu.com/Bugs/Importance are the guidelines, I personally would have set as a High, but Joseph owns a lot of the kernel stuff so I'll bow to his judgement
[23:44] <garyseven> yeah, i read that. i thought that it should be high, as well, as it "Renders essential features or functionality of the application or dependencies broken or ineffective"
[23:44] <garyseven> or possibly critical, in that it "Crashes the entire operating system"
[23:44] <penguin42> nod, or I would have quoted the has a severe impact....
[23:46] <penguin42> garyseven: The problem to some degree is that every oops ends up being a critical if you aren't careful, so you then don't end up separating the 'oopses for a small number of people/rare occasions' from the oopses for most people
[23:50] <garyseven> I don't understand. This bug would affect *all* people running a similar configuration on identical hardware. I can reproduce it on over a dozen servers.
[23:50] <garyseven> It is a show-stopper, in that it renders the systems completely unusable.
[23:51] <garyseven> The only real reason more people aren't affected is that it doesn't exist upstream, or in Precise.
[23:51] <penguin42> garyseven: ok, but you agree that say a bug that nuked the installation should be higher, or one that happened for most users should be higher?
[23:52] <garyseven> Not really. I don't see the benefit of being able to complete an installation only to boot into an unsusable system.
[23:52] <penguin42> garyseven: Most people using Quantal aren't hitting that oops
[23:52] <garyseven> And I suspect that the only reason more users aren't affected is because most users only take LTS releases. But I'd really not have to wait until 14.04 to see this fixed.
[23:53] <penguin42> garyseven: I realise for you that doesn't help, but I'm just saying in the scale of things there are worse bugs out there that affect more people
[23:53] <penguin42> garyseven: Looking at the logs, can I ask, are you using Xen?
[23:53] <garyseven> Yah.
[23:54] <penguin42> garyseven: Certainly the 2nd part of the oops looks xen specific, so probably only a small proportion of users use xen and thus hit it; it's a bit harder to tell whether the first part is due to xen
[23:55] <garyseven> I've only seen it happen under xen. But, it's still a kernel oops, Xen remains up and responsive during and after.
[23:59] <penguin42> garyseven: Anyway, so given you've found a version that it works on, what Joseph will probably ask you to do is to try a few kernel versions in between to see which one fixed/broke it