[03:04] <hashwagon> Anyone know why in the world I can't ssh to an Ubuntu 16.04 server from my Ubuntu 18.04 desktop? Get this, if I ssh into this CentOS server, I can ssh to the Ubuntu 16.04 server. All on the same network. From the 16.04 server I can ssh to my desktop. WTF is happening haha...
[03:07] <sarnold> check your RSA key sizes? https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base_system_changes_since_16.04_LTS
[03:11] <ChmEarl> hashwagon, on 16.04 you have a stale key in .ssh/known_hosts... open it and remove the key for the CentOS
[03:13] <nacc> ssh -vvv is your friend for debugging, as well
[03:13] <hashwagon> I did with no luck :( I was able to SSH to it successfully once after the install. It seems like SSH works bi-directionally between it and every box on my network, besides my 18.04 destop to the 16.04 machine.
[03:17] <hashwagon> It seems like it may be an issue on the 16.04 server. On my desktop I ran 'sudo -i' and couldn't ssh from the root user either. No prompts for key recognition or anything.
[03:19] <hashwagon> ssh -vvv doesn't seem to have much stick out: [line 5] debug2: ssh_connect_direct: needpriv 0 [line 6] debug1: Connecting to 1.1.1.1 [1.1.1.1] port 22.
[03:21] <hashwagon> So attempt the ssh connection - nothing - wait 60 seconds - Connection timed out. I can ping it.
[03:23] <ChmEarl> hashwagon, while in 18.04, can you ping hostname? if not, alias hostname in /etc/hosts to 127.0.0.2
[03:26] <hashwagon> ChmEarl, when I ping $HOSTNAME it responds
[03:27] <hashwagon> responds as 127.0.1.1
[03:30] <ChmEarl> hashwagon, good enough, don't change it
[03:31] <hashwagon> good suggestion though I wouldn't have thought of that
[04:51] <cpaelzer> moin
[06:01] <lordievader> Good morning
[08:24] <rbasak> nacc: can do (delete those git branches). For now the snap jobs are disabled from automatically uploading to the store.
[08:24] <rbasak> Longer term, I don't know.
[10:57] <jamespage> coreycb: ok I think I have all of the oslo.*'s done
[11:07] <jamespage> coreycb: I did the 3parclient rename as well - pending AA review - I'll see if I can get that into Debian as well
[12:28] <coreycb> jamespage: great, thanks. is that still under the python-hp3parclient source package?
[12:30] <coreycb> jamespage: i think most of the clients are done but will take a scan now to make sure. i have openstacksdk in the works but having trouble with a hanging test atm.
[13:03] <coreycb> jamespage: these are below upper-constraints but only openstacksdk and osc-lib are below lower-constraints so just going to focus on them for b2: https://paste.ubuntu.com/p/XQ6MqxbNgf/
[13:11] <jamespage> coreycb: ok do you want me todo some?
[13:11] <coreycb> jamespage: i think we're good for b2. actually i think a few of those were bumped just since yesterday.
[13:12] <coreycb> jamespage: thanks for the help :) I can probably focus on the core packages now.
[13:12] <jamespage> coreycb: awesome
[13:28] <jamespage> coreycb: sqlalchemy popped up in my merge list - seems like one to get done IMHO
[13:28] <coreycb> jamespage: ok i can add it to my list if you want
[13:29] <jamespage> coreycb: no I've got it in flight
[14:02] <ahasenack> does something need to happen with this ticket now for the dep8 tests to run? https://bileto.ubuntu.com/#/ticket/3293
[14:02] <ahasenack> or will that happen eventually, it's just in a queue somewhere?
[14:02] <jamespage> ahasenack: no you need a lander signoff from someone with the right perms
[14:03] <ahasenack> ok, not me then
[14:03] <jamespage> no prob needs to be a core-dev or suchlike
[14:03] <ahasenack> is it tied to upload perms?
[14:03] <jamespage> yah
[14:03] <jamespage> ish
[14:03] <jamespage> I think
[14:04] <ahasenack> I can't create new tickets, and that's even before I tell it what package I want the ticket for, so I think it's a blanket core-dev permission
[14:04] <jamespage> coreycb: do you want me todo the neutron-*/networking-* set? happy to help push this one out of the door
[14:05] <coreycb> jamespage: sure!
[14:08] <jamespage> coreycb: ok on it
[14:08] <coreycb> jamespage: thanks
[14:37] <jamespage> coreycb: get b2 in and then workon the switched to py3 right?
[14:37] <jamespage> i.e. move forwards where possible, incremental changes
[14:39] <coreycb> jamespage: sorry, sure that's fine
[15:05] <lopta> Ah crap.  I don't think Ubuntu Server (or perhaps just the Linux kernel) will run on my 32-bit test rig.
[15:07] <rbasak> Ubuntu dropped support for non-PAE i386 a while ago. I think it was Precise or pre-Precise. Could that be it?
[15:07] <rbasak> Apart from that I think it should still work on i386 at the moment.
[15:08] <lopta> I'm probably non-PAE.  Time to recycle this test rig, I think.
[15:18] <lopta> I /could/ put a 64-bit board in it.
[15:18] <lopta> Not sure I can justify the expense though.
[15:22] <l4m8d4> Hello there, I am facing a problem when I try to configure an ubuntu 18.04 server. First I do a normal install with the new installer to a single drive with a big btrfs single partition and an ESP before that. This works. I got a second drive though, which I want to add in to the system. I want there to be 2 LUKS containers, one on each drive, containing a btrfs raid1 mirror each. After I configure all
[15:22] <l4m8d4> that, creating the partitions and LUKS volumes and migrating the filesystems around, adding in fstab entries, adding in the necessary crypttab entries, adding "GRUB_ENABLE_CRYPTODISK=y", updating the initramfs and update-grub, and reinstalling grub into the ESP, the system will not boot anymore. I just land in the grub shell. cryptomount commands are unavailable though, so I can't mount the luks
[15:22] <l4m8d4> volumes.
[15:23] <l4m8d4> I can't figure out why it fails, because grub doesn't give me errors, it just goes to the terminal...
[15:24] <l4m8d4> Also, it's not the first time I've done this on ubuntu, so I know it is possible in principle. Only difference is now it is ubuntu 18.04 and also this time the system was installed in EFI mode
[15:25] <l4m8d4> First thing that's strange is that luks module
[15:25] <l4m8d4> is not found
[15:27] <compdoc> last time I tried drive encryption, it would not boot unless you entered the password each time. something I couldnt have on a server
[15:28] <l4m8d4> Entering the password on a reboot is not a problem for me. But unfortunately, grub doesn't ask for a password, it just drops me into a shell without the possibility to decrypt the luks containers...
[15:47] <l4m8d4> both "btrfs" and "crypto" module seem to be present (listed when using "lsmod") but that alone isn't enough to give me cryptomount
[16:05] <nacc> rbasak: ack re: branches/snap
[16:06] <jamespage> coreycb: ok neutron*/networking-* and ovsdbapp done
[16:06] <jamespage> I suspect they will wedge in -proposed but I can deal with that tomorrow
[16:08] <coreycb> jamespage: great, thanks
[16:13] <jamespage> coreycb: np
[16:13] <jamespage> coreycb: I really need to loop back to ceph mimic now
[16:13] <jamespage> 32 bit was not happy
[16:15] <coreycb> jamespage: ack
[19:39] <l4m8d4> It seems that after setting up full disk encryption with a LUKS partition and an ESP, there are some modules missing, which makes the cryptomounts fail. Is there anything known about issues like that on 18.04?
[19:41] <l4m8d4> I think I did everything correctly, modifying fstab, crypttab and /etc/default/grub accordingly, and the config files in /boot/efi/... and /boot/grub... look good as far as I can see. It drops me right into a shell on reboot, and for example the module cryptodisk is unavailable, making it impossible to unlock the volumes from the grub shell.
[19:42] <l4m8d4> Also, I reinstalled grub-efi-amd64, which caused changes in /boot/efi/... to accomodate the configuration, so I was confident at first that it would work
[19:57] <ahasenack> do we have a standard way to tell grub to reboot into a specific kernel that was just installed?
[19:57] <ahasenack> I've seen grub-reboot, and grub-set-default, but I was wondering if there was some debian or ubuntu wrapper
[20:03] <nacc> ahasenack: not that i know of
[20:15] <genii> Doesn't it just normally boot to the highest numbered one?
[20:20] <ahasenack> apparently not
[20:20] <ahasenack> for example, I'm in an aws instance
[20:20] <ahasenack> where it's running some -aws kernel
[20:20] <ahasenack> $ uname -r
[20:20] <ahasenack> 4.4.0-1061-aws
[20:20] <ahasenack> I installed linux-image-generic
[20:20] <ahasenack> and rebooted, just like that
[20:20] <ahasenack> it's still the aws kernel that it booted into
[20:21] <ahasenack> so it's a case of switching flavors, actually
[20:22] <sdeziel> ahasenack: the grub menu items are ordered by numeral order
[20:22] <sdeziel> and -generic uses -128
[20:23] <ahasenack> where do you see that?
[20:23] <sdeziel> cat /boot/grub/grub.cfg?
[20:23] <ahasenack> that is not a trivial file to parse :)
[20:23] <sdeziel> ahasenack: at least that's the conclusion I reached when installing some such kernels, maybe not your exact issue
[20:24] <sdeziel> please paste it :)
[20:24] <ahasenack> menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-84ce5b56-30b1-4479-a864-7296bb549cec' {
[20:24] <ahasenack> for example
[20:24] <ahasenack> that's the first "menuentry" I see in that file
[20:24] <ahasenack> what id is that?
[20:24] <ahasenack> don't tell me 0 :)
[20:24] <sdeziel> I usually look at the bottom and work my way up
[20:24] <ahasenack> the second entry is a submenu
[20:25] <sdeziel> then I look at the first item's vmlinuz name
[20:25] <ahasenack> so if I wanted to boot into something from that, the syntax, from what I have read, would be like "1>n", where "n" is the index of the submenu
[20:25] <sdeziel> ahasenack: I don't want to induce you in error so I'd like to look at the actual grub.cfg file please
[20:25] <ahasenack> -128 is just the kernel rev, it's not related to grub
[20:26] <ahasenack> just happens to be the current linux-image-generic kernel. It was 127 some days ago, etc
[20:27] <sdeziel> the -127/128 is involved in the grub menu ordering is what I'm saying
[20:41] <powersj> nacc: does git-ubuntu use serverstack?
[20:41] <nacc> powersj: yes
[20:41] <powersj> thx
[20:42] <nacc> powersj: the bastion is running there, which is then used to spin up the vm the instance that is actually running the importer
[20:42] <powersj> nacc: any data on there?
[20:43] <nacc> powersj: minimal, just the state of the importer (as in where it got to last). No effect if we hve to pick it back up from a fresh VM
[20:43] <nacc> powersj: are they doing some maint?
[20:43] <powersj> yeah was asked to blow away and recreate our instances
[20:43] <nacc> ok, that'll be for rbasak to do then
[20:43] <nacc> or is it running under the team now, i can't recall
[20:44] <powersj> I'll confirm with rbasak, thanks!