[00:06] <lunaphyte> i got disconnected, sorry
[00:06] <lunaphyte> TJ-: it looks like it's usb 1 and usb 2
[00:06] <lunaphyte> there are two black ports on the front, which i suppose should be usb 2?  and two white ports on the back, which would i guess then probably be usb 1?
[00:06] <lunaphyte> it's an older dell poweredge server
[00:06] <lunaphyte> [sorry if those are repeats]
[00:06] <lunaphyte> i'd been using the usb 2 socket, so i can try the usb 1 socket
[00:07] <lunaphyte> TJ-: right now i have a shell to the system, having booted from a flash drive - is there anything useful i might do before rebooting?
[00:07] <TJ-> lunaphyte: oooo... ability to play, so wait!
[00:08] <TJ-> lunaphyte: firstly, you can determine how the keyboard is currently connected (what devices/drivers it requires)
[00:09] <lunaphyte> here's what lsusb says: http://dpaste.com/0MQEZRM.txt
[00:09] <TJ-> lunaphyte: I'd start with "ls -l /sys/class/input/ | grep usb "
[00:09] <lunaphyte> ok, one moment
[00:09] <TJ-> lunaphyte: then you can drill down in the path(s) that reveals to figure out which kernel modules are required
[00:10] <lunaphyte> http://dpaste.com/29Y89J3.txt
[00:10] <lunaphyte> fwiw, the drac virtual keyboard doesn't work in initramfs either
[00:11] <TJ-> lunaphyte: DRAC! that explains it
[00:11] <TJ-> lunaphyte: is the DRAC input not working right now?
[00:12] <lunaphyt_> ugh, i keep getting disconnected
[00:13] <lunaphyt_> ideally, i'd like to get the drac remote console keyboard working
[00:14] <lunaphyt_> oops, that sys/class/input paste was useless, i'd forgotten to plug the keyboard back in
[00:14] <lunaphyt_> http://dpaste.com/3KET45Z.txt
[00:16] <tomreyn> lunaphyte: the "recue broken install" option is an option provided by the "debian installer" type installer, now dubbed the ubuntu alternative server installer.
[00:17] <tomreyn> (those server ISOs without "live" in the file name)
[00:17] <lunaphyt_> tomreyn: oh, ok, thanks
[00:18] <TJ-> lunaphyt_: hmmm, I was just trying to figure out if the DRAC is regular usbhid - it seems to be from what I can see in the kernel source, there is no specific driver for it
[00:19] <TJ-> lunaphyt_: so when there is a keyboard plugged into it there is no system input?
[00:20] <lunaphyt_> sorry, i'm not sure i'm following the question
[00:21] <TJ-> lunaphyt_: presumably you're connecting to DRAC5 via a management station?
[00:21] <lunaphyt_> oh, i connect to the drac5 via a java application
[00:22] <lunaphyt_> i run a jnlp java file on my computer here, which then connects via the network to the drac
[00:23] <TJ-> right, and does it bring up the poweredge console correctly, showing the video output?
[00:23] <lunaphyt_> oh, yes, it does
[00:23] <TJ-> I'm just trying to get an idea as to where the issues are
[00:23] <lunaphyt_> the drac5 remote console works fine, up until the kernel gets involved
[00:23] <TJ-> lunaphyt_: right, that is what I wanted to get at
[00:23] <lunaphyt_> so i can interact with bios, and with grub, and that all is working as it should be
[00:24] <lunaphyt_> ok
[00:24] <TJ-> lunaphyt_: does it continue OK with video but lose keyboard input?
[00:24] <lunaphyt_> yes
[00:25] <tomreyn> try this (instructions for idrac8, but might also apply): in the iDRAC, go to Virtual Console under Server, and the bottom option is for the Keyboard/Mouse Attach State. Make sure this is not set to Detached. If it is, change it to auto or plain attached and hit apply.
[00:26] <TJ-> lunaphyt_: Here's another possibility: https://www.itdroplets.com/idrac-remote-keyboard-not-working/
[00:27] <tomreyn> also this: Right above the "attach state" is an option for "Automatic System Lock", disabling this may help if you loose keyboard functionality after getting disconnected
[00:27] <tomreyn> (last post on https://www.dell.com/community/PowerEdge-Hardware-General/Keyboard-and-mouse-not-working-in-iDRAC8/td-p/5169237# )
[00:29] <TJ-> I also found one, saying "I just had the same issue.  Login to your DRAC and change the console type from Native to Java."
[00:30] <TJ-> This was in relation to multiple identical PowerEdge + CentOS where only 1 had this problem
[00:30] <lunaphyt_> it doesn't look like this system has the settings described for drac8
[00:31] <lunaphyt_> it does have the console type setting, though.  it's currently set to java - that's what i'm using now
[00:31] <TJ-> lunaphyt_: is it worth changing it to native then?
[00:31] <TJ-> lunaphyt_: as a test at least
[00:31] <lunaphyt_> yeah, i'll try
[00:33] <TJ-> what web browser are you using to access DRAC?
[00:33] <lunaphyt_> firefox
[00:33] <TJ-> this issue could affect FF too I guess: https://help.serversaustralia.com.au/hc/en-us/articles/202436724-Keyboard-not-working-in-Dell-DRAC-Console-on-Internet-Explorer
[00:34] <TJ-> however, no, since it works for BIOS/GRUB! forget that one
[00:34] <lunaphyt_> yeah, i think if i solve my physical usb keyboard issue, i have a feeling it will solve the drac5 keyboard issue too
[00:35] <TJ-> lunaphyt_: If Linux is seeing the DRAC input devices and attaching them it does point to an issue on the DRAC side
[00:36] <TJ-> lunaphyt_: as for the external keyboard, it's a Logitech isn't it?
[00:37] <lunaphyt_> but when i boot, both physical and drac work, in bios, in grub, and both stop working once i get to initramfs
[00:37] <lunaphyt_> TJ-: it's a dell
[00:37] <lunaphyt_> http://dpaste.com/37CFC5C.txt
[00:37] <TJ-> The 046D:1017 device shown in your last pastebin needs the module hid_logitech_hidpp which I bet isn't included in the initrd.img by default
[00:37] <lunaphyt_> "Dell Computer Corp. SK-8125 Keyboard"
[00:38] <lunaphyt_> if i'm not mistaken, that would seem to indicate it's using the usbhid driver?
[00:38] <TJ-> lunaphyt_: is the SK-8125 a wired keyboard ?
[00:38] <lunaphyt_> yes, a usb wired keyboard
[00:39] <TJ-> so presumably you've also attached a Logitech unifying receiver ?
[00:39] <lunaphyt_> yes, i have a wireless mouse connected at the moment
[00:39] <TJ-> Ahhh, I just picked the wrong device! Because all the others were Dell (046D) I ignored them!
[00:40] <lunaphyt_> that was just so i could navigate the ubuntu desktop i'd booted into from a flash drive
[00:40] <lunaphyt_> oh, hah :)
[00:40] <lunaphyt_> sorry for the red herring
[00:40] <TJ-> OK, and this wired keyboard also doesn't work?
[00:40] <lunaphyt_> that's right
[00:40] <lunaphyt_> it works in bios and grub, but stops working in busybox/initramfs
[00:40] <TJ-> lunaphyt_: this USB boot you currently have, is it the LiveISO ?
[00:41] <lunaphyt_> it's ubuntu-18.10-desktop-amd64.iso
[00:41] <TJ-> right, so it's running 'live' in memory, not as an installed OS
[00:41] <lunaphyt_> right
[00:41] <TJ-> lunaphyt_: OK! so, let is set things up to do a chroot investigation and fix
[00:42] <lunaphyt_> sounds good
[00:42] <TJ-> lunaphyt_: in a terminal gain root ("sudo -i")
[00:42] <lunaphyt_> done
[00:42] <TJ-> lunaphyt_: then "mkdir /target" which we'll use to mount the rootfs of the poweredge later
[00:43] <TJ-> lunaphyt_: then do "lsblk | nc termbin.com 9999" so I can see what block devices we are dealing with
[00:43] <lunaphyt_> just so i'm not being inconsiderate, i'll have to run for a bit in about 10 minutes again - i don't want you to invest too much just to get interrupted
[00:43] <TJ-> OK. We should be able to do this pretty quickly
[00:44] <lunaphyt_> ok
[00:44] <lunaphyt_> https://termbin.com/rlwx
[00:44] <TJ-> basically, we're going to check what kernel modules are in the initrd.img, and if needed add the usbhid etc
[00:44] <lunaphyt_> for background, it's 4 disks, in a raid 1+0 setup, with lvm on top of that
[00:45] <lunaphyt_> oh - no, wait
[00:45] <lunaphyt_> sorry, it's raid 5 across all 4
[00:45] <TJ-> Now everything is making more sense, and see the /usr/ file-system there
[00:45] <lunaphyt_> my mistake
[00:46] <lunaphyt_> https://termbin.com/z9e2e
[00:46] <TJ-> OK, let's get going: "mount /dev/mapper/vg_1-root /target"
[00:46] <TJ-> oh and lets get a handy pastebin helper: "apt install pastebinit"
[00:46] <lunaphyt_> done
[00:47] <lunaphyt_> should i mount the rest of the filesystems as well?
[00:47] <TJ-> what are the 95MB partitions for on sda/b/c/d ?
[00:47] <TJ-> No
[00:47] <lunaphyt_> ok
[00:47] <lunaphyt_> those are bios grub partitions
[00:47] <TJ-> sda1 etc
[00:47] <TJ-> really!? You know that never uses more than about 1MB ? I was thinking they might be for /boot/ :)
[00:48] <lunaphyt_> https://termbin.com/0aag
[00:48] <lunaphyt_> yeah, i know it's way overkill
[00:48] <TJ-> OK so we've already got /boot/ mounted at /target/boot/, so "pastebinit <( ls -latr /target/boot/)
[00:48] <lunaphyt_> i've had some issues in the past where grub didn't fit in the mbr
[00:48] <lunaphyt_> it's just me being overly cautious
[00:49] <lunaphyt_> http://paste.ubuntu.com/p/WMhDgHGMsP/
[00:49] <TJ-> usually that's due, on MBR, to partition #1 starting early (not being aligned to sector 2048) and thus no space for GRUB's core
[00:49] <lunaphyt_> oh, hmm
[00:50] <TJ-> OK, now let's look at the initrd. "pastebinit <( lsinitramfs /target/boot/initrd.img-3.13.0-164-generic )"
[00:50] <lunaphyt_> http://paste.ubuntu.com/p/BmGvXR2tyy/
[00:51] <TJ-> No usbhid
[00:51] <lunaphyt_> oh - also, if it's of value, i've tried both kernels, and both suffer the same symptom
[00:51] <lunaphyt_> where should usbhid be shown?
[00:52] <TJ-> let's just check it isn't a builtin - "pastebinit <( find /target/lib/modules -name usbhid.ko -ls )"
[00:52] <TJ-> I just did a grep, the usbhid.ko module should have shown up
[00:52] <lunaphyt_> http://paste.ubuntu.com/p/JR3MGzPK2m/
[00:52] <lunaphyt_> i see
[00:52] <TJ-> At one time it was builtin to the kernel so I'm checking this isn't the case for you
[00:53] <lunaphyt_> ah ok
[00:53] <TJ-> OK, confirmed, it is needed. So "echo usbhid >> /target/etc/initramfs-tools/modules"
[00:53] <TJ-> Now we build the chroot fully.
[00:54] <TJ-> "for n in proc sys dev dev/pts run etc/resolv.conf; do mount --bind /$n /target/$n; done "
[00:54] <lunaphyt_> so since lib/modules/3.13.0-164-generic/kernel/drivers/hid/usbhid/usbhid.ko is there, that implies usbhid is a module and not built in?
[00:54] <TJ-> lunaphyt_: correct
[00:54] <lunaphyt_> i see
[00:54] <TJ-> lunaphyt_: but isn't in initrd.img, ergo, no usb keyboard
[00:54] <lunaphyt_> got it
[00:55] <lunaphyt_> whose silly idea was that :)
[00:55] <TJ-> done the for ... command?
[00:55] <lunaphyt_> catching up, one moment
[00:55] <TJ-> after that, enter the chroot with "chroot /target" then do "mount -a" to have it mount all the file-systems from its /etc/fstab automatically
[00:56] <lunaphyt_> chroot /target returned "bash: groups: command not found"
[00:56] <lunaphyt_> is that safe to ignore?
[00:57] <TJ-> hmmm, possibly due to the /usr/ outside rootfs
[00:57] <lunaphyt_> oh
[00:57] <TJ-> if it has entered the chroot, do "exit" and drop back to the host shell
[00:57] <lunaphyt_> it had.  i've exited and am back to the host shell
[00:57] <TJ-> then you can do "mount /dev/mapper/vg_1-usr /target/usr" then re-enter with "chroot /target" and "mount -a"
[00:58] <lunaphyt_> that looks better
[00:58] <lunaphyt_> shoot, i've got to run :( - sorry!
[00:58] <TJ-> Now finally do "update-initramfs -vu -k 3.13.0-164-generic |& tee /tmp/initrd.log "
[00:58] <lunaphyt_> oh, ok
[00:58] <TJ-> This is the LAST step :)
[00:58] <lunaphyt_> ok, done
[00:59] <TJ-> once that has completed just check the module has been added, with "grep usbhid /tmp/initrd.log"
[00:59] <lunaphyt_> "Adding module /lib/modules/3.13.0-164-generic/kernel/drivers/hid/usbhid/usbhid.ko"
[00:59] <TJ-> lunaphyt_: sorted :)
[00:59] <lunaphyt_> nice!
[00:59] <TJ-> next boot you should have USB keyboard
[00:59] <TJ-> "exit" and shutdown
[00:59] <lunaphyt_> i really appreciate this
[01:00] <lunaphyt_> i'll give it a try as soon as i get back
[01:00] <TJ-> It's gone 1am here so I'll likely hear about it tomorrow
[01:05] <lunaphyt_> ah, then have a good night, and thanks again
[07:27] <lordievader> Good morning
[11:01] <ahasenack> good morning
[11:08] <nascentmind> Hi. I am setting up Ubuntu server on a machine and I am having trouble with networking. My ethernet interface has 2 IP addresses. I have a 50-cloud-init.yaml file in netplan directory and have set 99-disable-network-config.cfg with network: {config: disabled}. I still get a static IP and a dhcp address set on the interface.
[11:08] <nascentmind> How can I fix it?
[11:18] <rbasak> nascentmind: how do you expect to configure your server's IP addresses?
=== cpaelzer__ is now known as cpaelzer
=== lunaphyt_ is now known as lunaphyte
[15:40] <kstenerud> I'm getting a strange error when calling git ubuntu lint: https://pastebin.ubuntu.com/p/PHgGcyGvQx/
[15:40] <kstenerud> I'm not sure what it means about an unexpected file change
[18:09] <Hackerpcs> I'm on 18.10. I have a problem with DNS as it doesn't work (ping google.com, Temporary failure in name resolution. systemd-resolved is running and I have netplan configured to CF DNS (systemd-resolve --status shows it). What could be the problem? /etc/resolv.conf shows 127.0.0.1
[18:10] <teward> that sounds like it's wrong, IIRC resolved listens on 127.0.0.53; how did your /etc/resolv.conf get set up?  Did you alter it at all?
[18:10] <cyphermox> Hackerpcs: you have dnsmasq or bind running and probably confusing things for systemd-resolved
[18:10] <lordcirth> Hackerpcs, /etc/resolv.conf contains "nameserver 127.0.0.53" on my 18.04 system
[18:11] <Hackerpcs> cyphermox: both aren't installed
[18:11] <cyphermox> easiest is to start with making sure systemd-resolved can indeed resolve google.com (ie. systemd-resolve google.com)
[18:11] <teward> ^ this, also on my 18.10 system and containers
[18:11] <cyphermox> and then yeah, it should be 127.0.0.53; maybe the file was immutable if you did an upgrade from previous releases?
[18:12] <lordcirth> Hackerpcs, ls -l /etc/resolv.conf?
[18:12] <Hackerpcs> yes, I upgraded from 18.04 but to be honest I don't remember if it was a clean install on 18.04 or 17.XX
[18:12] <lordcirth> Should be a symlink to ../run/systemd/resolve/stub-resolv.conf
[18:12] <Hackerpcs> yes it's linked to there
[18:13] <Hackerpcs> cyphermox: yes it can resolve it
[18:14] <cyphermox> probably should check if anything else is currently running and listening on port 53
[18:15] <cyphermox> (ss --listen -u)
[18:16] <Hackerpcs> nothing seems relevant, only mdns (isn't it 5353?)
[18:17] <cyphermox> right, 53 is 'domain'
[18:17] <cyphermox> systemd-resolved should pretty much just be 127.0.0.53%lo:domain
[18:18] <cyphermox> so, something might have modified that file; but if it's not running and you upgraded it could be because of attributes -- people did that for some releases
[18:21] <Hackerpcs> https://pastebin.com/jfNawi1k
[18:21] <Hackerpcs> nothing relevant I think
[18:33] <Hackerpcs> removing the resolv.conf and rebooting doesn't restore it
[18:33] <Hackerpcs> something's off
[18:37] <TJ-> Hackerpcs: have you checked nsswitch 'hosts' ?
[18:37] <sdeziel> Hackerpcs: resolved won't recreate the resolv.conf symlink if you rm'ed it
[18:41] <Hackerpcs> re-linked it, edited it and it get fixed to 127.0.0.53 after reboot
[18:42] <Hackerpcs> TJ-: hosts: files mdns4_minimal [NOTFOUND=return] dns
[18:45] <TJ-> Hackerpcs: that looks sane
[18:47] <Hackerpcs> I've tried a pihole installation some weeks ago but it didn't work (I think it's not compatible with systemd resolved) but removed it, don't know if it matters
[18:47] <Hackerpcs> I started having the problem today, no problems before
[18:54] <lunaphyte> TJ-: no luck with the keyboard so far, unfortunately
[18:55] <Hackerpcs> I really don't get how did this happen, everything seems normal
[18:55] <TJ-> lunaphyte: you dropped to the initialramfs shell?
[18:57] <Hackerpcs> guess I'll just edit resolv.conf manually to CF DNS and don't bother more with it
[18:57] <lunaphyte> TJ-: oh, wait - i just realized, i forgot to do the break=premount bit, but when /usr fails to mount and it drops to initramfs, there's still no keyboard
[18:58] <sdeziel> Hackerpcs: you could tell systemd-resolved to use CF DNS instead, if you want
[18:58] <Hackerpcs> it has it
[18:58] <Hackerpcs> but it doesn't work
[18:59] <sdeziel> you said you configured it this way but also that your resolv.conf was pointing to 127.0.0.1 (!= 127.0.0.53) so I'm wondering if you were really hitting resolved
[19:00] <Hackerpcs> I deleted it, re-linked it, tried to edit it to see if resolved really touched and after a reboot it changes to .53
[19:00] <TJ-> lunaphyte: right; at that point it should be available. The list in /etc/initramfs-tools/modules is included in the initrd.img (as we checked yesterday) and are supposed to be loaded when the /init script is running
[19:00] <Hackerpcs> 127.0.0.53
[19:00] <Hackerpcs> but the damn thing doesn't work
[19:00] <sdeziel> Hackerpcs: define doesn't work please
[19:01] <Hackerpcs> https://pastebin.com/0uGvfwux my netplan
[19:01] <Hackerpcs> ping: google.com: Temporary failure in name resolution
[19:01] <sdeziel> Hackerpcs: OK, please share systemd-resolve --status
[19:01] <Hackerpcs> if resolv.conf is set to 127.0.0.53
[19:02] <Hackerpcs> https://pastebin.com/XEWFwC0B systemd-resolve --status
[19:03] <sdeziel> Hackerpcs: paste the output of systemd-resolve google.com
[19:03] <sdeziel> Hackerpcs: any idea where the "fe80::1" resolver is coming from?
[19:04] <Hackerpcs> netplan doesn't indicate anything
[19:04] <lunaphyte> TJ-: yeah, i thought that was the expectation
[19:04] <Hackerpcs> google.com: 172.217.21.206 -- Information acquired via protocol DNS in 17.7ms. -- Data is authenticated: no
[19:04] <TJ-> I'd assume a link-local router advertisement
[19:05] <TJ-> lunaphyte: So... it probably also needs some intermediate modules for the USB chipset
[19:05] <sdeziel> Hackerpcs: that seems to be working. Maybe the problem is that fe80::1 not responding and being asked once in a while by resolved
[19:05] <TJ-> lunaphyte: Does the system take a traditional PS/2 style keyboard, and if so, do you have one?
[19:05] <Hackerpcs> where could it be coming from? Can I see that somehow?
[19:06] <TJ-> Hackerpcs: check "journalctl -u systemd-resolved"
[19:06] <TJ-> Hackerpcs: that may contain clues as to what is going wrong
[19:06] <sdeziel> Hackerpcs: could be coming from a Router Advertisement (RDNS IIRC)
[19:07] <sdeziel> Hackerpcs: if you have dig available, please paste the output of the following: dig google.com @fe80::1%enp5s0
[19:07] <TJ-> lunaphyte: if it does not, then I think we have to tackle this in 2 stages 1) add a verbose script that displays the loaded modules and hardware and waits so you get time to photograph its output, and 2) add whatever modules we see are missing compared with the Live boot list
[19:08] <Hackerpcs> https://pastebin.com/a2FY15br
[19:10] <lunaphyte> TJ-: it's usb only, no ps/2
[19:10] <Hackerpcs> I don't see something relevant on resolved systemd log
[19:10] <sdeziel> Hackerpcs: OK so that theory was wrong, fe80::1 behaves normally
[19:10] <TJ-> lunaphyte: so the latter process then
[19:11] <sdeziel> Hackerpcs: when ping cannot resolve, could you check if dig @127.0.0.53 works?
[19:12] <Hackerpcs> connection timed out; no servers could be reached
[19:12] <TJ-> sdeziel: it really looks like nsswitch teritory if ping is failing - presumable gethostbyname()/getnameinfo()
[19:13] <sdeziel> Hackerpcs: ss -nlu
[19:13] <Hackerpcs> well any program from curl to rtorrent can't resolve
[19:13] <Hackerpcs> not just ping
[19:14] <sdeziel> Hackerpcs: your resolved should be listening on that socket otherwise we'll need to check how you did the symlink
[19:14] <TJ-> Hackerpcs: yes, my point is any program relying on the standard library resolver functions is failing, and those rely on nsswitch
[19:14] <Hackerpcs> https://pastebin.com/Sx5PWuvT
[19:15] <Hackerpcs> ss -nlu
[19:15] <sdeziel> Hackerpcs: please paste /etc/systemd/resolved.conf
[19:15] <sdeziel> Hackerpcs: would you mind sharing resolved's journal output as well?
[19:16] <Hackerpcs> w8 a sec, I might accidentally ln'ed stub resolved
[19:16] <lunaphyte> TJ-: understood, just on a phone call atm
[19:17] <Hackerpcs> sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf insted of plain resolved.conf
[19:17] <sdeziel> Hackerpcs: that's the one you want AFAIK
[19:17] <Hackerpcs> stub?
[19:19] <Hackerpcs> well with /run/systemd/resolve/resolv.conf resolving works
[19:19] <Hackerpcs> it uses the DNS servers provided by netplan
[19:20] <Hackerpcs> on /etc/resolv.conf
[19:20] <sdeziel> but this bypasses resolved for programs using resolv.conf directly
[19:20] <Hackerpcs> https://wiki.archlinux.org/index.php/Systemd-resolved#DNS -- I must be on 2nd case
[19:21] <sdeziel> Hackerpcs: please paste /etc/systemd/resolved.conf
[19:22] <Hackerpcs> https://pastebin.com/ur5wKgqV
[19:24] <sdeziel> Hackerpcs: you added "DNSStubListener=no", which is why resolved doesn't listen on 127.0.0.53
[19:25] <sdeziel> Hackerpcs: the default is to have that line set to yes and commented out
[19:25] <sdeziel> and resolv.conf pointing to the stub- version of the file
[19:25] <Hackerpcs> hm, I don't remember when (because I should have) fiddled with it
[19:25] <sdeziel> Hackerpcs: maybe when playing the pihole?
[19:26] <Hackerpcs> maybe its automated script modifies it
[19:26] <Hackerpcs> but I didn't have a problem
[19:26] <Hackerpcs> even though I haven't rebooted for like 10-12 days till today
[19:26] <Hackerpcs> so that must have been it
[19:26] <sdeziel> Hackerpcs: I don't know pihole but if it's meant to be a local resolver then it could very well be the culprit
[19:27] <Hackerpcs> rm'ed etc/resolved, ln'ed to stub, commented out and set to yes the stub setting and reboot
[19:28] <sdeziel> Hackerpcs: that should get you back to the "default" setup
[19:30] <Hackerpcs> alright it works
[19:30] <Hackerpcs> sorry for being a PIA :P
[19:31] <Hackerpcs> PITA*
[19:31] <sdeziel> Hackerpcs: glad it's working again!
[19:32] <Hackerpcs> yeah pihole is a adblocker on dns level
[19:32] <Hackerpcs> but it seems doesn't play well with netplan and resolved
[19:33] <Hackerpcs> https://github.com/pi-hole/pi-hole/blob/master/automated%20install/basic-install.sh#L1485
[19:33] <Hackerpcs> here's the cause
[19:37] <sdeziel> Hackerpcs: It's OK to disable the stub resolver socket of resolved but in that case, the pihole server needs to fill in the role of DNS resolver
[19:38] <Hackerpcs> https://discourse.pi-hole.net/t/cant-install-pi-hole-v4-0-on-ubuntu-server-18-04/11616 "Ubuntu 18.04 removes some of the packages that we need for the installation process. dialog and dhcpcd5 are no longer in Ubuntu 18.04, so at this time we are unable to install to that distribution."
[19:38] <sdeziel> Hackerpcs: presumably, when you removed pihole, it didn't undo the resolved.conf change leaving you with a broken setup
[19:40] <Hackerpcs> pihole -uninstall seems to have that oversight
[19:45] <sdeziel> Hackerpcs: would be nice if you reported this bug :)
[19:47] <sdeziel> Hackerpcs: hmm, looks like it does attempt to cleanup: https://github.com/pi-hole/pi-hole/blob/master/automated%20install/uninstall.sh#L155
[19:48] <Hackerpcs> hm the file is there but it wasn't reset
[19:48] <Hackerpcs> strange
[19:49] <sdeziel> Hackerpcs: what's its content? Maybe you ran the installer twice and the .orig file got overwitten
[19:49] <Hackerpcs> the corrent one, stub commented out and yes
[19:49] <Hackerpcs> diff is empty between the two :P
[19:50] <sdeziel> Hackerpcs: OK then yeah, it's worth reporting to them
[19:51] <Hackerpcs> well I don't have the logs but I'll try to report it to look into it
[19:52] <Hackerpcs> "The issue I am reporting can be replicated." -- not sure about that :P
[19:54] <Hackerpcs> maybe I'll run pihole in a docker to not mess up my host system
[20:07] <lunaphyte> TJ-: it's mostly just a hypothesis right now, i need to look closer, but at a glance, it almost seems like the initrd is recognizing the hub in the keyboard, but not recognizing the actual keyboard itself
[20:08] <lunaphyte> at the initramfs shell, when i plug in the keyboard, it prints output about "recognized usb device, etc", so it seems to be seeing something and recognizing it, but obviously there's still something missing since the keyboard isn't functioning
[20:09] <TJ-> lunaphyte: from our investigation yesterday we showed in the Live environment the required modules so I'm struggling to think of what more could be missing to prevent console input. I don't suppose the kernel command-line has a param setting the console to a serial terminal or some such?
[20:11] <lunaphyte> it might, but i'd have to track down a serial port somewhere else to use it
[20:21] <TJ-> lunaphyte: no, I meant, is it set to use a serial tty now - you'd see if it was on the kernel command-line because it'd have console=ttyS0,115200n8 or similar
[20:21] <TJ-> lunaphyte: I doubt you do but its one long-shot possibility
[20:21] <lunaphyte> oh, i see.  no i don't believe so - at least i don't recall seeing that on the kernel command line
[20:30] <TJ-> No, I don't but I was mostly asleep at the keys last night so forgotten a lot of what we saw :)
[20:34] <lunaphyte> no worries, you weren't the only one!
[20:35] <TJ-> lunaphyte: it's annoying because without that working, we can't chase down the /usr problem
[20:36] <lunaphyte> you're telling me :)
[20:38] <lunaphyte> TJ-: i'm just in the process of trying to get a little bit more useful recovery boot drive
[20:39] <lunaphyte> i've just booted from ubuntu-18.10-server-amd64.iso, and so far the rescue environment is working via the drac5 remote console
[20:40] <lunaphyte> hopefully this will work better
[20:40] <lunaphyte> if it does, it will at least make this process way less burdensome
[20:46] <TJ-> lunaphyte: definitely :)
[20:48] <lunaphyte> i can't reference the notes in my wiki for all of this :p
[20:48] <lunaphyte> the wiki is on the server :)
[20:49] <lunaphyte> sigh
[20:49] <lunaphyte> no bonding module on the iso, it seems like
[20:50] <lunaphyte> oh, wait, no
[20:50] <lunaphyte> that's my filesystem i'm in
[20:50] <lunaphyte> hmm
[20:50] <TJ-> lunaphyte: Why not make an install onto a USB, and have it boot from that, rather than an installer/live environment
[20:50] <lunaphyte> i was just thinking about that earlier
[20:57] <lunaphyte> doing that now
=== mwhahaha_ is now known as mwhahaha
=== noganoo_ is now known as noganoo
=== kierank_ is now known as kierank
=== popey_ is now known as popey