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:04 |
---|---|---|
sarnold | check your RSA key sizes? https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base_system_changes_since_16.04_LTS | 03:07 |
ChmEarl | hashwagon, on 16.04 you have a stale key in .ssh/known_hosts... open it and remove the key for the CentOS | 03:11 |
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:13 |
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:17 |
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:19 |
hashwagon | So attempt the ssh connection - nothing - wait 60 seconds - Connection timed out. I can ping it. | 03:21 |
ChmEarl | hashwagon, while in 18.04, can you ping hostname? if not, alias hostname in /etc/hosts to 127.0.0.2 | 03:23 |
hashwagon | ChmEarl, when I ping $HOSTNAME it responds | 03:26 |
hashwagon | responds as 127.0.1.1 | 03:27 |
ChmEarl | hashwagon, good enough, don't change it | 03:30 |
hashwagon | good suggestion though I wouldn't have thought of that | 03:31 |
cpaelzer | moin | 04:51 |
=== giraffe is now known as Guest28040 | ||
=== success is now known as Guest81159 | ||
lordievader | Good morning | 06:01 |
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. | 08:24 |
jamespage | coreycb: ok I think I have all of the oslo.*'s done | 10:57 |
jamespage | coreycb: I did the 3parclient rename as well - pending AA review - I'll see if I can get that into Debian as well | 11:07 |
coreycb | jamespage: great, thanks. is that still under the python-hp3parclient source package? | 12:28 |
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. | 12:30 |
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:03 |
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:11 |
coreycb | jamespage: thanks for the help :) I can probably focus on the core packages now. | 13:12 |
jamespage | coreycb: awesome | 13:12 |
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:28 |
jamespage | coreycb: no I've got it in flight | 13:29 |
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:02 |
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:03 |
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:04 |
coreycb | jamespage: sure! | 14:05 |
jamespage | coreycb: ok on it | 14:08 |
coreycb | jamespage: thanks | 14:08 |
=== z0 is now known as sonhadora | ||
=== sonhadora is now known as z0 | ||
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:37 |
coreycb | jamespage: sorry, sure that's fine | 14:39 |
lopta | Ah crap. I don't think Ubuntu Server (or perhaps just the Linux kernel) will run on my 32-bit test rig. | 15:05 |
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:07 |
lopta | I'm probably non-PAE. Time to recycle this test rig, I think. | 15:08 |
lopta | I /could/ put a 64-bit board in it. | 15:18 |
lopta | Not sure I can justify the expense though. | 15:18 |
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:22 |
l4m8d4 | I can't figure out why it fails, because grub doesn't give me errors, it just goes to the terminal... | 15:23 |
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:24 |
l4m8d4 | First thing that's strange is that luks module | 15:25 |
l4m8d4 | is not found | 15:25 |
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:27 |
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:28 |
l4m8d4 | both "btrfs" and "crypto" module seem to be present (listed when using "lsmod") but that alone isn't enough to give me cryptomount | 15:47 |
nacc | rbasak: ack re: branches/snap | 16:05 |
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:06 |
coreycb | jamespage: great, thanks | 16:08 |
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:13 |
coreycb | jamespage: ack | 16:15 |
=== markthomas_ is now known as markthomas | ||
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:39 |
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:41 |
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:42 |
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 | 19:57 |
nacc | ahasenack: not that i know of | 20:03 |
genii | Doesn't it just normally boot to the highest numbered one? | 20:15 |
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:20 |
ahasenack | so it's a case of switching flavors, actually | 20:21 |
sdeziel | ahasenack: the grub menu items are ordered by numeral order | 20:22 |
sdeziel | and -generic uses -128 | 20:22 |
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:23 |
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:24 |
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:25 |
ahasenack | just happens to be the current linux-image-generic kernel. It was 127 some days ago, etc | 20:26 |
sdeziel | the -127/128 is involved in the grub menu ordering is what I'm saying | 20:27 |
powersj | nacc: does git-ubuntu use serverstack? | 20:41 |
nacc | powersj: yes | 20:41 |
powersj | thx | 20:41 |
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:42 |
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:43 |
powersj | I'll confirm with rbasak, thanks! | 20:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!