[03:10] <henry> hi, how do i get help on module missing in slapd package?
=== cpaelzer_ is now known as cpaelzer
[05:53] <cpaelzer> good morning
[05:54] <utkarsh2102> cpaelzer: o/
[05:54] <cpaelzer> hi utkarsh2102
[08:43] <OutBackDingo> seem to be seeing disk enumerations issues on ubuntu with multi disk systems, like 2 256gb ssd boot drives and 6 3.5Tb storage drives, ubuntu sees the boot drives last and installs to the 3.5TB, specifically using MAAS
[08:43] <OutBackDingo> we noticed it also trying an install from usb stick where sda was 3.5T, and not 128Gb
[09:22] <mirespace> good morning
[13:10] <icey> jamespage: any idea why this doesn't have logs: https://launchpad.net/~chris.macnaughton/+archive/ubuntu/focal-ussuri/+build/23490887 ?
[13:25] <JanC> OutBackDingo: I'm not sure why you expect drives to be enumerated in a particular order?
[13:26] <OutBackDingo> every other linux os sees the 2 ssd drives as sda / sdb except ubuntu
[13:26] <OutBackDingo> JanC: so curiously ubuntu sees them as sdi / sdj
[13:27] <OutBackDingo> and i would "expect" them to be enumerated in slot order at a minimal
[13:27] <JanC> AFAIK this enumeration has no guaranteed order, and might even differ between installer runs...
[13:28] <OutBackDingo> JanC: would make sense but mostly occurs only with ubuntu
[13:28] <JanC> there are many types of "slots"
[13:35] <JanC> I suppose /dev/disk/by-path/* is the closest you can get to a "slot order" ?
[13:39] <ogra> any guaranteed drive enumerration in linux has been dropped around linux 3.x ... it is sheer luck if you see them enumerated the same all the time 
[13:40] <ogra> (or was it 2.x ??? definitely some time after udev got common standard)
[13:40] <JanC> well, some distros keep a cache to keep them the same over reboots after install
[13:40] <JanC> but on install, there would be no such cache
[14:16] <ahasenack> sergiodj: around?
[14:17] <ahasenack> sergiodj: you are not including the patches from https://code.launchpad.net/~sergiodj/ubuntu/+source/bind9/+git/bind9/+merge/417404 in the bind 9.18.1 merge because of the FFe?
[14:17] <ahasenack> because it might not be granted?
[14:17] <jamespage> icey: some other infrastructure issue in the build farm - my ceph upload from yesterday died in a mysterious way as well
[14:37] <sergiodj> ahasenack: yeah, I thought it was better to have two separate processes.  but I can refactor things here and include the patches in the merge if you think it's best, no problem
[14:38] <ahasenack> sergiodj: if that ffe goes through, it will need the patches, so I think better add them now
[14:38] <ahasenack> I'm reviewing the 9.18.0 one, to unblock that in case the FFe doesn't go through
[14:38] <sergiodj> ahasenack: makes sense, I will add the patches to the merge
[14:38] <sergiodj> thanks for reviewing
[19:09] <sergiodj> ahasenack: thanks for the review
[19:28] <Comnenus> After I remove a static IP from netplan and change it to DHCP, # netplan try is getting the DHCP address but not releasing the static.  How can I get rid of that?
[19:34] <genii> Did you issue: sudo netplan apply   
[19:37] <ogra> if "apply" behaves different from "try" thats clearly a bug though (not saying that apply wont work indeed, but behaviour is supposed to be identical for both)
[19:43] <Comnenus> I did not try apply yet.
[19:44] <Comnenus> (haha)
[19:44] <sarnold> lol