[04:29] <cpaelzer> hi frickler, the default size changed - as you found - from 32M to 1G
[04:29] <cpaelzer> frickler: I have managed via the discussion to get this one in https://gitlab.com/qemu-project/qemu/-/commit/c83d628b7fba050e59ccf7bda050bc27af241b61
[04:29] <cpaelzer> which kind of set a lower bound
[04:29] <cpaelzer> and resolved it for all "small test systems" to not totally blow into OOM
[04:29] <cpaelzer> since then everyone seems to have been fine
[04:30] <cpaelzer> and it was considered upstream that for the few potential bad cases left, cli options could be used to tune it
[06:40] <frickler> cpaelzer: well OpenStack CI isn't fine with that, we run hosts with 8GB "phys"mem, so we are still left with 1GB tb-size
[06:41] <frickler> which makes things go boom if there are multiple small instances spawned like in parallel tempest tests
[06:41] <frickler> to use cli options, we'll need libvirt to be able to pass those, which is what I'll do an RFE for next, but not sure if that'll make it into distros in time
[06:55] <cpaelzer> sad to hear that frickler, back then I couldn't convince upstream to go fully back to the old values
[06:56] <cpaelzer> the (correct) argument for it is, that the majority of users get a performance benefit out of it
[06:57] <cpaelzer> And indeed, your use case of concurrent TCG runs breaks the current mitigation as the code only knows about system-size but can't know about potential other processes
[08:16] <johk> Hi, I'm running ubuntu server 20.04.3 arm64 on a raspberry pi. I have trouble getting a pi camera module v1.3 to work. Using the impish repo I apt-src installed libcamera0. I added start_x=1 to usercfg.txt and vcgencmd get_camera returns "vcgencmd get_camera". Yet cam/qcam don't list a camera device and there does not to seem a device in /dev/... Anyone got this to work?
[08:17] <johk> (I have also asked this over in #raspberrypi - I'm not sure which channel is more appropriate)
[08:25] <TJ-> johk: I /think/ there's an ubuntu channel for the pi but I may be wrong - but the person you want to ask is waveform who does the Ubuntu Pi images
[08:26] <ogra> johk, TJ- i guess #ubuntu-arm is the closest to a Pi channel ... 
[08:27] <ogra> johk, though i think you'll need to edit config.txt to use fkms instead of the kms overlay to enable the camera
[08:30] <TJ-> sounds like ogra is more familiar. I stick to RasberryPiOS on the Pis
[08:40] <jamespage> sdeziel: thanks for that MP - that bug is unique to a two step install process which is not usual and actually impacts a wider set of the ceph-* packages
[08:41] <johk> ogra, I'm trying this right now
[08:42] <johk> ogra, interestingly adding the dtoverlay for the cam v1.3 changed the vcgencmd get_camera return to supported=1 detected=0
[08:51] <ogra> johk, well, if it still does not work, ask waveform ... he's the pi specialist (i only use UbuntuCore on Pis ...)
[09:02] <johk> I'll switch over to #ubuntu-arm
[14:07] <jamespage> sdeziel: can I understand what you're doing with regards to ceph-fs and ceph-osd's on the same machine?
[14:07] <jamespage> the bug you logged does need fixing just trying to understand the full context
[14:11] <sdeziel> jamespage: we are trying trying to get a working ceph cluster on small amount of machines which is why the charms ceph-fs and ceph-osd are colocated on the same machines
[14:11] <jamespage> sdeziel: is this driven using the existing ceph-* charms?
[14:12] <sdeziel> jamespage: yes
[14:12] <sdeziel> jamespage: ceph-{fs,mon,osd}
[14:12] <jamespage> sdeziel: can you use lxd containers for fs and mon?
[14:12] <jamespage> that's typical for what the charms actually get validated with
[14:14] <sdeziel> jamespage: I can try that as a workaround, sure
[14:15] <jamespage> sdeziel: the charms will all assume they are the only ceph-* charm operating in the filesystem
[14:15] <jamespage> sdeziel: so ymmv on both deployment and subsequent operations such as upgrades between ceph versions
[14:15] <jamespage> (if they are not isolated from each other in containers)
[14:16] <sdeziel> ah, good to know :)
[14:16] <jamespage> sdeziel: for example, all three charms will want to manage /etc/ceph/ceph.conf
[14:18] <sdeziel> jamespage: I see how that could lead to problems, thanks for the heads up!
[14:19] <jamespage> sdeziel: no worries - I will work your proposed change to the packaging into my next upload for jammy
[14:19] <jamespage> alongside the other postinst that need a little attention in this area.
[14:21] <sdeziel> jamespage: thank you!
[21:17] <hax> is netplan the way to go for connecting to wifi? If so, it's not working for me. I get no yaml errors, but I do get a warning after netplan apply: "Warning: The unit file, source configuration file or drop-ins of netplan-wpa-wlan0.service changed on disk. Run 'systemctl daemon-reload' to reload units."
[21:17] <hax> running the systemctl doesn't fix it
[21:19] <hax> I've rebooted and run netplan generate && netplan apply to the same effect.
[21:22] <sarnold> hax: try systemctl list-units 'netplan*'   -- I think that'll give you some threads to pull on
[21:40] <hax> hm...it says loaded fine, but failed failed wpa_supplicant for that netplan
[21:41] <hax> I don't seem to be able to start wpa_supplicant, either. I connected with it during the install, but I didn't do manual package selection, just chose web server + ssh
[21:41] <mason> hax: FWIW, unless you're doing it as a learning experience, I tend to think of netplan as being more intended for servers.
[21:41] <hax> this is ubuntu server with no gui, mason
[21:42] <mason> oh, but with wifi - unusual, but okay
[21:42] <mason> hax: Verify your assumptions about what's installed. The install environment can and does have things that might not be in your initial install.
[21:43] <hax> haha yeah I'm making it hard on myself. it's an old desktop that I'm trying to set up on wifi because the room I'm in only has one wire for the desktop I'm using now. I guess I should just go plug it in beside the router and use ssh rather than doing this
[21:43] <sarnold> hmm, bummer, I don't spot any specific wpa_supplicant logs on my one system..
[21:43] <hax> mason, yeah I hadn't considered that fact.
[21:43] <mason> Should just be /var/log/syslog
[21:43] <mason> Or maybe that's all been subsumed by journalctl now. Not sure.
[21:56] <hax> after moving wpasupplicant and its deps over on usb I got it installed and then netplan worked. thanks sarnold and mason 
[21:56] <mason> nice nice
[21:56] <mason> hax: That's bitten me too way more than once.
[21:57] <sarnold> *weird*
[21:57] <mason> hax: For extra credit, now, figure out how in netplan to hook in firewall rules.
[21:57] <sarnold> thanks for reporting back the solution hax :)
[22:22] <sdeziel> mason: AFAIK, netplan doesn't support firewalling. For those, you are probably better off with `iptables-persistent`
[22:22] <mason> sdeziel: Ah, I don't have this up now, but you can also use a hook directory (IIRC) and just drive iptables or whatever from a shell script that way.
[22:22] <mason> sdeziel: It was an almost direct drop-in replacement for the post-up I do with ifupdown.
[22:23] <sdeziel> mason: maybe you are referring to `networkd-dispatcher`?
[22:23] <mason> no no
[22:23] <mason> By which I mean, yes, now that I look.
[22:23] <mason> Heh.
[22:23] <mason> https://netplan.io/faq/#use-pre-up%2C-post-up%2C-etc.-hook-scripts
[22:24] <mason> I got that far, saw that it worked correctly, and went right back to ifupdown, being the dinosaur that I am.
[22:25] <mason> hax: ^ that link might be useful to you
[23:50] <hax> I've got 2 good places to put my little server, both at the end of an ethernet cable, but both of those cables are already in use. One for my desktop, which needs ports open for a few things, and the other for my roku tv. would you recommend putting a second nic into the server and putting my pc or tv into it, or using a spare router as a switch?
[23:51] <hax> ethernet goes through tight hole in wall that would be difficult to expand, so another run isn't feasible
[23:53] <genii> If you don't need 100+ mbit you can split a cat5 into 2 connectors on each end
[23:53] <hax> interesting. I hadn't thought of that...