[03:04] 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] check your RSA key sizes? https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base_system_changes_since_16.04_LTS [03:11] hashwagon, on 16.04 you have a stale key in .ssh/known_hosts... open it and remove the key for the CentOS [03:13] ssh -vvv is your friend for debugging, as well [03:13] 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] 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] 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] So attempt the ssh connection - nothing - wait 60 seconds - Connection timed out. I can ping it. [03:23] hashwagon, while in 18.04, can you ping hostname? if not, alias hostname in /etc/hosts to 127.0.0.2 [03:26] ChmEarl, when I ping $HOSTNAME it responds [03:27] responds as 127.0.1.1 [03:30] hashwagon, good enough, don't change it [03:31] good suggestion though I wouldn't have thought of that [04:51] moin === giraffe is now known as Guest28040 === success is now known as Guest81159 [06:01] Good morning [08:24] nacc: can do (delete those git branches). For now the snap jobs are disabled from automatically uploading to the store. [08:24] Longer term, I don't know. [10:57] coreycb: ok I think I have all of the oslo.*'s done [11:07] 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] jamespage: great, thanks. is that still under the python-hp3parclient source package? [12:30] 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] 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] coreycb: ok do you want me todo some? [13:11] jamespage: i think we're good for b2. actually i think a few of those were bumped just since yesterday. [13:12] jamespage: thanks for the help :) I can probably focus on the core packages now. [13:12] coreycb: awesome [13:28] coreycb: sqlalchemy popped up in my merge list - seems like one to get done IMHO [13:28] jamespage: ok i can add it to my list if you want [13:29] coreycb: no I've got it in flight [14:02] does something need to happen with this ticket now for the dep8 tests to run? https://bileto.ubuntu.com/#/ticket/3293 [14:02] or will that happen eventually, it's just in a queue somewhere? [14:02] ahasenack: no you need a lander signoff from someone with the right perms [14:03] ok, not me then [14:03] no prob needs to be a core-dev or suchlike [14:03] is it tied to upload perms? [14:03] yah [14:03] ish [14:03] I think [14:04] 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] coreycb: do you want me todo the neutron-*/networking-* set? happy to help push this one out of the door [14:05] jamespage: sure! [14:08] coreycb: ok on it [14:08] jamespage: thanks === z0 is now known as sonhadora === sonhadora is now known as z0 [14:37] coreycb: get b2 in and then workon the switched to py3 right? [14:37] i.e. move forwards where possible, incremental changes [14:39] jamespage: sorry, sure that's fine [15:05] Ah crap. I don't think Ubuntu Server (or perhaps just the Linux kernel) will run on my 32-bit test rig. [15:07] Ubuntu dropped support for non-PAE i386 a while ago. I think it was Precise or pre-Precise. Could that be it? [15:07] Apart from that I think it should still work on i386 at the moment. [15:08] I'm probably non-PAE. Time to recycle this test rig, I think. [15:18] I /could/ put a 64-bit board in it. [15:18] Not sure I can justify the expense though. [15:22] 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] 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] volumes. [15:23] I can't figure out why it fails, because grub doesn't give me errors, it just goes to the terminal... [15:24] 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] First thing that's strange is that luks module [15:25] is not found [15:27] 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] 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] 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] rbasak: ack re: branches/snap [16:06] coreycb: ok neutron*/networking-* and ovsdbapp done [16:06] I suspect they will wedge in -proposed but I can deal with that tomorrow [16:08] jamespage: great, thanks [16:13] coreycb: np [16:13] coreycb: I really need to loop back to ceph mimic now [16:13] 32 bit was not happy [16:15] jamespage: ack === markthomas_ is now known as markthomas [19:39] 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] 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] 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] do we have a standard way to tell grub to reboot into a specific kernel that was just installed? [19:57] I've seen grub-reboot, and grub-set-default, but I was wondering if there was some debian or ubuntu wrapper [20:03] ahasenack: not that i know of [20:15] Doesn't it just normally boot to the highest numbered one? [20:20] apparently not [20:20] for example, I'm in an aws instance [20:20] where it's running some -aws kernel [20:20] $ uname -r [20:20] 4.4.0-1061-aws [20:20] I installed linux-image-generic [20:20] and rebooted, just like that [20:20] it's still the aws kernel that it booted into [20:21] so it's a case of switching flavors, actually [20:22] ahasenack: the grub menu items are ordered by numeral order [20:22] and -generic uses -128 [20:23] where do you see that? [20:23] cat /boot/grub/grub.cfg? [20:23] that is not a trivial file to parse :) [20:23] ahasenack: at least that's the conclusion I reached when installing some such kernels, maybe not your exact issue [20:24] please paste it :) [20:24] menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-84ce5b56-30b1-4479-a864-7296bb549cec' { [20:24] for example [20:24] that's the first "menuentry" I see in that file [20:24] what id is that? [20:24] don't tell me 0 :) [20:24] I usually look at the bottom and work my way up [20:24] the second entry is a submenu [20:25] then I look at the first item's vmlinuz name [20:25] 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] 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] -128 is just the kernel rev, it's not related to grub [20:26] just happens to be the current linux-image-generic kernel. It was 127 some days ago, etc [20:27] the -127/128 is involved in the grub menu ordering is what I'm saying [20:41] nacc: does git-ubuntu use serverstack? [20:41] powersj: yes [20:41] thx [20:42] 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] nacc: any data on there? [20:43] 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] powersj: are they doing some maint? [20:43] yeah was asked to blow away and recreate our instances [20:43] ok, that'll be for rbasak to do then [20:43] or is it running under the team now, i can't recall [20:44] I'll confirm with rbasak, thanks!