[03:16] <Deihmos> anyone use unattended updates? how do i blacklist kernel updates?
[03:17] <sarnold> Unattended-Upgrade::Package-Blacklist in the right config file, /etc/apt/apt.conf.d/50unattended-upgrades on my bionic laptop
[03:17] <tomreyn> i'm curious on the use case, can you discuss it?
[03:18] <sarnold> I don't know the apt config system real well, maybe you can put it into a new file withotu modifying whichever one already exists..
[03:18] <Deihmos> what do i use "linux-generic"
[03:20] <tomreyn> linux-image-generic and / or linux-image-generic-hwe-* i would guess.
[03:20] <sarnold>         if re.match(blacklist_regexp, pkgname):
[03:20] <sarnold> maybe linux-image.*
[03:21] <tomreyn> actually linux-.* may be better if you want to prevent module updates, too.
[03:22] <tomreyn> + headers + firmware + tools.
[03:23] <Deihmos> does livepatch update modules?
[03:23] <Deihmos> maybe i will just skip live patching
[03:24] <tomreyn> are you aware that unattended-upgrades will, by default, only install security patches and newer kernel versions, but not actually boot into them?
[03:24] <tomreyn> i mean it won't trigger a reboot
[03:24] <tomreyn> unless you ask it to
[03:25] <sarnold> Deihmos: yes, livepatch can patch modules
[03:26] <Deihmos> yes i know but you can set it to reboot if needed
[03:28] <tomreyn> okay, just making sure you're not trying to workaround an issue which does not exist.
[03:58] <Deihmos> are security updates always kernel related?
[03:59] <Deihmos> answer is no
[06:30] <lordievader> Good morning
[07:02] <geodb27> People : hi ! I'm on a fresh install of ubuntu 18.04 (server) and face a problem with network setup. Indeed, all my parameters (ip, mask, dns servers) are provided by a dhcp server. This is quite fine. However, with the new setup for dns provided by ubuntu, my machine can resolve all but what resides on my own domain.
[07:02] <nikolam> Hi, Is there a smarter way to handle BTRFS snapshots (after installing apt-btrfs-snapshot to create snapshot on every apt install/upgrade operation) , then to delete them manually in CLI, one by one?  Like some GUI?..
[07:03] <geodb27> What would be the best practice to have my dns servers be provided by my dhcp server and not have this uggly 127.0.0.53 fake server that serves nothing at all ?
[07:11] <tomreyn> geodb27: 127.0.0.53 is not really a 'fake' server, it is a real locally running dns caching service, systemd-resolved
[07:12] <geodb27> tomreyn: I can believe you on this. However, what I see on my machine is that with this default setup, my machine can't get any name resolved on my local domain name.
[07:12] <tomreyn> if you'll propagate a  search domain you could make your organizations' servers and service hostnames resolvable by users just providing the very service name.
[07:14] <tomreyn> geodb27: does    systemd-resolve --status    list a 'DNS Domain' on the network link whihc connects to your organization network?
[07:15] <tomreyn> and do the dns servers listed there match your organizations' authoritative DNS servers for internal use (allowing to resolve some internalservice.organizationdomain.tld)?
[07:16] <tomreyn> i'm assuming you run your own auth dns servers there for internal use. other orgs just push everything out ot the internet.
[07:18] <geodb27> let me check
[07:24] <geodb27> Don't think I've left all... The machine has just been rebooted and can't be reached...
[07:31] <tomreyn> geodb27: maybe the issue is really just your auth dns?
[08:00] <geodb27> Indeed, we have two dns servers that are authoritative on our network for our local.domain.tld. The two dns server addresses are listed when U do a systemd-resolved --status.
[08:00] <geodb27> However, my guess is that the 127.0.0.53 local dns wants to be authoritative also on this local.domain.tld, which is weird.
[08:03] <tomreyn> geodb27: when you run    systemd-resolve --flush-caches && systemd-resolve some.local.domain.tld    does it then seem to resolve those correctly? and can you      ping -c1 some.local.domain.tld    without getting resolver errors?
[08:04] <geodb27> no to all, I've already tried all this, ping some.logal.domain.tld fails with "Temporary failure in name resolution". But...
[08:04] <geodb27> I say but... Because there seem to be another network error somewhere I'm trying to figure out.
[08:06] <tomreyn> if you install dig and run    dig -t A some.local.domain.tld @resolver.listed.on.systemd-resolve--status   does it report that it was able to resolve it properly?
[08:07] <tomreyn> what makes you think there is "another network error somewhere"?
[08:07] <geodb27> I can't install anything, the machine can't reach our proxy (proxy.local.domain.tld)...
[08:08] <geodb27> Machine boot 1 : I can ssh to it. Reboot, I can't.. Reboot, I can, and so on. Ping never reaches this id address... Well, there *DEFINETLY* is something wrong.
[08:12] <tomreyn> can you ping -c1 the resolver?
[08:12] <tomreyn> also the proxy, by ip address
[08:13] <tomreyn> but i agree this looks like a network issue (probably outside of this system), not just dns.
[08:17] <blackflow> geodb27: and what if you set up a static IP? does the connection flip-flop on reboot as well?
[08:27] <geodb27> I'm waiting for one of our Network engineer to look at it closer.
[08:50] <JonTheNiceGuy> Hi, just tried to use the Ubuntu server 18.04.02 image downloaded this morning with the new installer (I normally use Vagrant images, so I've not used the installer since circa 14.04)... Struggling to do an install on an inherited server (Fujitsu Primergy RX200S8) with static IPs and an LSI raid card. I've had to manually set up the IP addressing via a separate TTY (ip addr/ip route and tinyproxy on another host to work
[08:50] <JonTheNiceGuy> around DNS) and now it's not finding the raid drives. I can generally work around things, but identifying where the issues are to improve other's experiences would be better. What can I give you to start working out where to file bugs? Bearing in mind, I'm not planning to do lots of rebuilds on this box after today :)
[09:16] <tomreyn> JonTheNiceGuy: the RAID controller should be supported out of the box. maybe it is set to some bad mode in the firmware configuration. you can post a kernel log from a tty using: dmesg | nc termbin.com 9999
[09:17] <tomreyn> JonTheNiceGuy: note that there is also an alternate server installer (which is based on the old debian-installer) available. it is better suited for complex configurations.
[09:19] <tomreyn> https://wiki.debian.org/LinuxRaidForAdmins#megaraid_sas and https://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS may help you manage the RAID controller properly.
[09:21] <JonTheNiceGuy> G7vri95129
[09:23] <tomreyn> JonTheNiceGuy: you'll want a new passwrd
[09:23] <JonTheNiceGuy> Fortunately it's only half a password..... However.... Yes.
[09:27] <JonTheNiceGuy> http://termbin.com/7x24
[09:30] <JonTheNiceGuy> Don't know if it's relevant, but I was using UEFI boot too?
[09:30] <tomreyn> it may be if you had secure boot on.
[09:31] <JonTheNiceGuy> Hmm, I might try without UEFI and see what happens next :
[09:31] <JonTheNiceGuy> :)
[09:34] <tomreyn> JonTheNiceGuy: you have a very old mainboard firmware installed there, too
[09:35] <tomreyn> http://support.ts.fujitsu.com/IndexDownload.asp?Softwareguid=9BDBC15C-F1C1-467F-B1BE-94C787AF9501
[09:35] <tomreyn> R1.19.0 (06/06/2018), you have R1.3.0 (12/04/2013)
[09:36] <tomreyn> personally, i'd keep uefi booting
[09:38] <JonTheNiceGuy> Looks like I'm running fwupd on there too then :)
[09:38] <tomreyn> [    1.904433] megaraid_sas 0000:01:00.0: Failed to init firmware
[09:39] <tomreyn> [    1.904685] ------------[ cut here ]------------
[09:39] <tomreyn> [    1.904686] Trying to free already-free IRQ 34
[09:39] <tomreyn> that's from your log
[09:39] <tomreyn> firmware update may help
[09:39] <JonTheNiceGuy> Ugh. OK. Fab thanks.
[09:48] <tomreyn> JonTheNiceGuy: there are separate RAID Controller firmware downloads provided as disk images for this system (two different ones, not sure which one you need), to be boot an usb attached storage and carry out the controller firmware upgrade.
[09:49] <tomreyn> http://support.ts.fujitsu.com/IndexDownload.asp?Softwareguid=3E48AED0-4A10-4354-9E83-78948AB08B62 and http://support.ts.fujitsu.com/IndexDownload.asp?Softwareguid=DBE58F8E-46EE-449D-A678-50090680CD32 (read "important information")
[11:59] <Delvien> running ubuntu-server as a guest in KVM, i resized the disk and verified the new size on the host, but ubuntu is not picking up the change. Not running LVM.
[12:01] <qman__> run partprobe
[12:01] <andol> Delvien: On the guest, did you check the size of the block device or the size of the file system?
[12:03] <Delvien> Hmm, i was mistaken, it does show the correct value (checking with lsblk) but running resize2fs states nothing to do.. odd
[12:03] <qman__> you have to increase the size of the partition
[12:04] <qman__> the process works like this: 1. Expand virtual disk 2. Run partprobe for the kernel to detect the new size 3. extend the partition
[12:04] <qman__> 4. resize2fs
[12:04] <Delvien> The filesystem is already 2620672 (4k) blocks long.  Nothing to do!
[12:05] <qman__> I usually use fdisk/gdisk to do it
[14:33] <coreycb> jamespage: sahid is going to handle the cinder and keystone rc2's for stein
[14:34] <geodb27> Hi again ! I've ended up to re-create a vm with latest ubuntu 18.04.02 server iso, and at install set up a fixed ip address for my ens160 network interface. However, after reboot, the interface is not up and no ip are set. What did I do wrong ?
[14:35] <teward> is your VM configured to connect the network at power on?  Is the VM's settings set to have the virtual nic on it "Connected"?
[14:36] <geodb27> Yes it is.
[14:37] <Ool> how did you fix the IP add ? into the netplan/file.cfg ?
[14:38] <geodb27> It seems to have been filled in in /etc/netplan/50-cloud-init.yaml by the installer. I haven't modified anything by hand
[14:42] <geodb27> Well, these problems killed me for today. Thanks Ool and teward for your kind help. I'll see for this tomorow...
[14:42] <tomreyn> check whether netplan created a matching systemd-networkd configuration file with the static ip address in it as a result
[14:43] <tomreyn> it should be in /etc/systemd/network, i think
[14:44] <tomreyn> or in /run/systemd/network rather
[14:48] <jamespage> coreycb: +1
[15:29] <DK2> is there a way to logg the complete console for ssh session?
[15:32] <leftyfb> DK2: screen can do it
[15:33] <tomreyn> auditd
[15:34] <sdeziel> "script" can also do it but only auditd is the secure way to do it