[00:00] <tych0> oh, but i wonder how i pass that initially before the image spawns, so cloud init sees eth0 the first time it runs
[00:01] <tych0> hrm. my ifname is still called ens3?
[00:01] <tych0> i guess it's systemd renaming things?
[00:02] <rbasak> Did net.ifnames=0 get through? Check /proc/cmdline
[00:02] <slangasek> no, it's systemd /not/ renaming things
[00:02] <slangasek> ens3 is the new-style kernel naming
[00:03] <rbasak> https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html is my usual reference for all of this
[00:04] <rbasak> My understanding is that ens3 happens as a result of a udev rule
[00:04] <tych0> rbasak: yes, it did
[00:04] <tych0> BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=91bfde43-9e70-45e9-b215-ab15bfdf4c92 ro net.ifnames=0 console=tty1 console=ttyS0
[00:04] <rbasak> "...you disable it by booting with
[00:04] <tych0> so i wonder if i can install a new kernel now and it won't screw thing sup
[00:04] <rbasak> net.ifnames=0 or disabling 80-net-setup-link.rules"
[00:05] <rbasak> [upstream]
[00:05] <slangasek> ah
[00:05] <slangasek> sorry, I was under the impression this was the in-kernel name nowadays
[00:06] <tych0> well, it seems hung with my new kernel and net.ifnames=0 :(
[00:07] <rbasak> Hung on boot? Give it 60 seconds.
[00:07] <rbasak> (if you have console)
[00:08] <Unit193> (Isn't ln -s /dev/null /etc/systemd/network/99-default.link  the more recommended method anyway?)
[00:08] <tych0> yeah, i have console
[00:08] <tych0> you can reproduce this by just uvt-kvm create a vm, and then install a stock 4.17 kernel build from upstream with bindeb-pkg
[00:08] <tych0> it just hangs forever
[00:09] <tych0> anyway, based on irc timestamps 60 ceonds have passed and no luck :(
[00:09] <tych0> oh, there we go
[00:09] <tych0> huh, weird
[00:09] <tych0> it's still named ens3
[00:10] <slangasek> Unit193: well, I don't know what people who don't want ifnames recommend; I recommend not trying to outsmart ifnames
[00:10] <tych0> but it took like 3 minutes to get past something. what's the systemd command for showing what took what time in th eboot chain?
[00:10] <rbasak> What are you trying to achieve?
[00:10] <slangasek> tych0: systemd-analyze
[00:10] <tych0> rbasak: i want to run a mainline kernel on a uvt-kvm created vm
[00:10] <slangasek> and systemd-analyze critical-chain
[00:10] <rbasak> If you use a non-Ubuntu kernel with perhaps a different config, then things may not necessarily work.
[00:10] <tych0> slangasek: right, thanks
[00:10] <rbasak> You might have better luck with https://wiki.ubuntu.com/Kernel/MainlineBuilds
[00:11] <tych0> rbasak: naturally. but i've been using this setup for several years, 18.04 images brok eit :(
[00:11] <Unit193> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ near the bottom.
[00:11] <tych0> rbasak: i don't really want a mainline kernel, i want a kernel with patches that i have applied. but my patches are unrelated to ifnames and such
[00:12] <rbasak> Unit193: I don't think those instructions take into account backwards compatibility with older Ubuntu that pitti took care of so carefully - see my link above.
[00:31] <smoser> tych0: well, cloud-init should be configuring your networking once per instance.
[00:31] <smoser> on subsequent boots, cloud-init should not do anything in uvtool. pretty sure it should recognize its not a new instance and do nothing.
[00:32] <smoser> so... cloud-init *should* set the system up to always rename the nic that is there with the same name.  ie, it "pins" it to whatever it saw the first time for this instance.
[00:32] <tych0> smoser: but the contents of /etc/netplan/*cloud* mention that it will reconfigure it once per boot
[00:33] <smoser> easiest thing for you to do if you want to just get rid of cloud-init interaction with networking in boot is just: sudo touch /etc/cloud/cloud-init.disabled
[00:33] <smoser> then it wont even run on subsequent boots.
[00:34] <smoser> to be clear... http://paste.ubuntu.com/p/p3m9SPpCHB/
[00:35] <smoser> the behavior you're describing is definitely not intended. so feel free to file a bug.
[00:35] <smoser> but i suspect your test kernel doesn't have some drivers or can't see the uvt-provided filesystem or somthing
[00:35] <smoser> so cloud-init tries to re-configure
[00:35] <smoser> or possibly its something else.
[00:35] <smoser> anyway, feel free to file a bug.
[00:35] <smoser> if you just want cloud-init out of the way, touch that file and be done.
[00:35]  * smoser has to go afk
[00:36] <tych0> smoser: cool, thanks
[00:36] <tych0> i like it on first boot, but you're right that i'm probably missing some drivers that uvt kvm wants. the kernel is very small
[05:21] <razwelles> Hey, I'm trying to understand the underpinnings of how linux puts a system on sleep. I've followed up to s2ram, and /sys/power/state, but I'm trying to find source code and I don't know where to go from there.
[10:03] <cpaelzer> Laney: hi, I have checked bug 1708008 - if I read that correctly you know the code that runs there
[10:03] <ubottu> bug 1708008 in rabbitmq-server (Ubuntu) "rabbitmq-server 3.5.7-1ubuntu0.16.04.2 security update dumped durable queues for autopkgtest.ubuntu.com" [Undecided,Triaged] https://launchpad.net/bugs/1708008
[10:04] <Laney> hey cpaelzer
[10:04] <Laney> did you see my reply?
[10:04] <cpaelzer> Laney: do you know if we publish in persitent mode
[10:04] <Laney> ah yes, you replied again
[10:04] <cpaelzer> I only wrote mine and didn't refresh :-)
[10:04] <Laney> maybe you didn't see comment #6
[10:04] <Laney> :-)
[10:04] <cpaelzer> hehe
[10:04] <cpaelzer> the good things is we came to the same conclusion and the bug is no bug
[10:04] <cpaelzer> thanks Laney
[10:05] <Laney> cpaelzer: this is a more emegent issue for us https://bugs.launchpad.net/auto-package-testing/+bug/1772236 if you're interested in more rabbity things
[10:05] <ubottu> Launchpad bug 1772236 in rabbitmq-server (Ubuntu) "rabbit died and everything else died" [Undecided,New]
[10:06] <cpaelzer> I'm not particularly interested, was just going along bug queues and found this one could need some love
[10:06] <Laney> ok then
[10:06] <Laney> is there a procedure to get this on your team's queue somehow?
[10:07] <cpaelzer> rabbitmq is in for OpenStack which is why the team is also subscribed
[10:07] <cpaelzer> on the server team we mostly try to run away if we see it
[10:08] <cpaelzer> It would usually be picke dup on bug triage which is a daily round robin task
[10:08] <cpaelzer> don't ask me what happened to this one :-)
[10:08] <cpaelzer> the procedure if the former doesn't work is in ping in #server about it
[10:08] <cpaelzer> but you did now
[10:09] <Laney> I guess really I should test that security regression theory by reverting erlang eh
[10:10] <Laney> the update doesn't look that suspicious :/
[10:12] <cpaelzer> no it really doesn't
[10:12] <cpaelzer> so you want to downgrade/upgrade erlang to see if that was the trigger?
[10:12] <cpaelzer> or does it then also need time to reach the OOM that one can see in the bug
[10:13] <cpaelzer> I don't know what to do on rabbitmq on this bug for now, if anything consider making Restart=on-failure the default
[10:13] <Laney> they've been about a week apart
[10:13] <cpaelzer> what is your experience with that setting so far?
[10:13] <Laney> hasn't happened since then
[10:13] <cpaelzer> I'm subscribing the Team, but for now there is no clear action to take IMHO
[10:13] <cpaelzer> if you found something that should be changed let us know
[10:14] <cpaelzer> the subscription ensures it isn't totally lost
[10:14] <Laney> it's just suspicious to me that it started memleaking after all these years
[10:14] <cpaelzer> but also has no guarantees on 24/7 attention
[10:14] <Laney> so "feels" like something changed
[10:14] <Laney> but yeah, no real evidence
[10:14] <cpaelzer> yeah one would have expected that since the system was deployed
[10:14] <cpaelzer> Laney: rabbitmqctl has some logs about memory consumption per queue
[10:15] <cpaelzer> maybe you could set up a cron job to log hourly to a file or so
[10:15] <cpaelzer> to have some idea which queue might be the leaker
[10:16] <Laney> good idea, can you post a tip to the bug and I'll try to get to that later on
[10:16] <Laney> please?
[10:16] <cpaelzer> sure
=== caravena_ is now known as caravena
[14:17] <willdeberry> hello all. i am running some own deb repos for work and wanted to get your inputs on best practice on moving packages between levels of repos (eg: proposed and stable). currently using reprepro and have all the different levels segmented via different URLs and we sync between them using rsync. Is relying on rsync and different URLs against the grain? Is it better to manage packages at the
[14:17] <willdeberry> individual package level and use something like reprepro to move between levels?
[14:20] <willdeberry> not sure why that split between lines :-/
[14:24] <cjwatson> It's usually much better to have a single pool and have something like reprepro add extra references to the relevant packages to different suites under dists/
[14:24] <cjwatson> rsyncing things around is certainly possible but really painfully clunky
[14:25] <cjwatson> You can just use "reprepro copy" and friends
[14:53] <willdeberry> copy will overwrite all contents if you move from proposed to stable for instance?
[15:15] <cjwatson> willdeberry: What do you mean?  Presumably you don't have the same version of the same package in both proposed and stable with different contents in each; that would be weird and confusing and probably something you'd want to avoid.  So I'm not sure what would be overwritten.
[15:27] <psusi> am I crazy or is grub-efi-amd64-signed supposed to be included in the pool on the install image, otherwise you can't install on a secure boot system without a network?
[15:27] <psusi> and it doesn't seem to be listed in any of the cd manifests
[15:29] <cjwatson> $ curl -s http://releases.ubuntu.com/bionic/ubuntu-18.04-desktop-amd64.list | grep grub-efi-amd64-signed
[15:29] <cjwatson> /pool/main/g/grub2-signed/grub-efi-amd64-signed_1.93+2.02-2ubuntu8_amd64.deb
[15:30] <psusi> ahh... right... the .manifest is what is in the squashfs
[15:32] <cjwatson> Indeed
[15:32] <psusi> ahh, ubuntustudio is missing /pool
[15:35] <psusi> at least in 16.04.4
[15:52] <willdeberry> cjwatson: gotcha, by overwrite i should have said version bump. thanks or the direction and info
[16:15] <cjwatson> willdeberry: Oh, right.  I don't use reprepro very much but I think so.
[18:17] <powersj> anyone know if this page ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi was migrated anywhere before alioth was retired
[18:18] <tsimonq2> powersj: I don't think so.
[18:19] <tsimonq2> sil2100 (who needs to get a bouncer!) brought it up on some mailing list a week or two ago
=== not_phunyguy is now known as phunyguy
[20:59] <tsimonq2> bdmurray: Forgive my bikeshedding :)
[21:03] <bdmurray> tsimonq2: It'd be more helpful if you'd add what you'd like.
[21:05] <tsimonq2> bdmurray: Perhaps s/can take/takes/ but I was uncertain on it.
=== caravena_ is now known as caravena