[00:11] <plm> TJ-: hey =D
[01:29] <xnox> RoyK, no, because it blocks releasing / finalising ticket across all series, yet when one publishes SRUs verification and publication w.r.t. each release can happen in parallel
[01:30] <xnox> hence we actively stopped adding more multi-release combos, as per archive/sru team decision.
[04:55] <cpaelzer> good morning
[08:00] <muhaha> /foo.file.core.windows.net/bar /data/sadisk/foo/bar cifs noauto,nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,vers=3.0,credentials=/etc/smbcredentials/foo.cred,dir_mode=0700,file_mode=0700,serverino does it makes sense?
[08:01] <muhaha> I am not sure about systemd.requires=network-online.target and automount.... This is network device. It has dependecy on cloud-init.service after (de)provisioning VM
[10:04] <blackflow> Is the certbot package broken in Ubuntu? Why is there a snap of it now?
[10:43] <rbasak> blackflow: it shouldn't be broken, but it is old.
[10:44] <rbasak> It's a huge amount of work to SRU it turns out, due to package renames and the dependency tree. So I've put up an experimental snap.
[10:46] <rbasak> blackflow: if you prefer the deb, the SRU welcomes volunteers. There are others interesting in the SRU bug too.
[10:46] <rbasak> others interested
[10:54] <MrMojit0> I have an Ubuntu 18.04 and I tried to do the following command: sudo apt install php-mbstring, but it says: E: Unable to locate package php-mbstring. How can I resolve this, it isn't for production but for my homelab
[11:01] <rbasak> MrMojit0: that might be because you don't have universe enabled. Try "sudo add-apt-repository universe", then "sudo apt update" and try again.
[11:32] <MrMojit0> rbasak: 'universe' distribution component is already enabled for all sources
[11:34] <avu> MrMojit0: beware when enabling universe, especially on servers, though. It doesn't receive security updates (or any updates) from the Ubuntu developers. And if and when the community acts and supplies these updates is sketchy at best
[11:35] <MrMojit0> avu: Thank you for the info, this is valuable for me. So never enable universe.
[11:35] <avu> MrMojit0: at least keep track of the packages you install from universe and beware of potentially unfixed security issues there
[11:36] <MrMojit0> avu: Well since I am new its better to aviod those options unless I get more experienced with that field.
[11:39] <RoyK> muhaha: add _netdev to the options in fstab
[12:23] <muhaha> _netdev works only for nfs
[12:23] <muhaha> not for cifs
[12:23] <muhaha> RoyK: ^
[12:32] <ahasenack> cpaelzer: hi, I could use some bileto help
[12:32] <ahasenack> cpaelzer: I don't understand why my trusty and xenial runs are like that
[12:32] <ahasenack> cpaelzer: https://bileto.ubuntu.com/excuses/3487/xenial.html stuck like that since yesterday
[12:32] <ahasenack> cpaelzer: and the trusty ones didn't even run: https://bileto.ubuntu.com/excuses/3486/trusty.html
[12:33] <ahasenack> is it some quirk of bileto with older releases of ubuntu?
[12:39] <cpaelzer> ahasenack: how is the test history of these in those releases?
[12:39] <ahasenack> there is none, I'm adding dep8 tests
[12:39] <RoyK> muhaha: oh - didn't know that
[12:40] <cpaelzer> ahasenack: I didn't run into the latter issue yet
[12:40] <cpaelzer> ahasenack: I have seen what you have on your xenial results
[12:41] <cpaelzer> ahasenack: my case was dying testers
[12:41] <ahasenack> hm
[12:41] <cpaelzer> so the tests got started, but something on the workload scheduling dies
[12:41] <cpaelzer> died
[12:41] <ahasenack> and the tests not running, in the trusty case?
[12:41] <cpaelzer> one of the infra team helped me to identify that, so eventually I just set it up again and it worked
[12:41] <cpaelzer> ahasenack: I didn't have the latter (=trusty) case yet
[12:42] <ahasenack> ok
[12:45] <RoyK> muhaha: on the other side, it's somewhat weird that nfs shold need the _netdev option, since, well, you don't really run nfs off a disk
[12:58] <muhaha> RoyK: btw I forgot to run daemon-reload and restart remote-fs.target ... to activate fstab gerenarot
[13:08] <RoyK> muhaha: does it work now?
[13:09] <muhaha> yes
[13:09] <RoyK> good :)
[13:09] <muhaha> *fstab generator
[14:12] <teward> rbasak: just an FYI since I see you're seeing all bug notices for the --with-compat bug, the PPAs have it now, so if anyone has any issues with it PPA users can report before we even turn it on for NGINX in Ubuntu :P
[14:14] <rbasak> teward: nice, thanks!
[14:15] <teward> yep.  There's some defaults I'm thinking about tweaking as well, because of the recent outbreak of security vulns that I find in the 'default' setups with Nessus and OpenVAS scanners
[14:15] <teward> but that's a discussion for another time (more or less disable certain protos, set certain SSL parameters)
[14:15] <teward> s/vulns/'risks'
[14:44] <ahasenack> I'm testing the server iso, the traditional one, not the new live one,
[14:44] <ahasenack> in the guided partitioning with lvm case, it's complaining that I don't have a /boot partition
[14:44] <ahasenack> why won't it create one for me, since it's "guided"?
[14:44] <ahasenack> powersj: do you remember that? ^
[14:52] <powersj> ahasenack, I don't recall needing to do that. Let me try that once I get the latest ISO
[14:53] <ahasenack> powersj: this is on powerpc, aka, uefi-like
[14:53] <ahasenack> not mbr
[14:53] <ahasenack> maybe that's the difference
[15:00] <adamretter> I just updated (apt-get dist-upgrade && shutdown -r now) my KVM host (Ubuntu 18.04) and now two of my KVM guest vm's (also 18.04) that were running perfectly fine before won't start up. I looked in the logs in /var/log/libvirt/qemu/ and there are no errors. How do I start fixing this?
[15:01] <ahasenack> do you get anything back from "virsh start <name>"?
[15:02] <ahasenack> or in virt-manager (the gui)
[15:07] <RoyK> adamretter: is the vm set to start automatically?
[15:07] <adamretter> RoyK: hehe yes
[15:08] <RoyK> just asking - first things first :)
[15:08] <adamretter> RoyK: totally agree
[15:09] <RoyK> adamretter: as ahasenack said - try to start it manually to see if you get any error message
[15:09] <adamretter> ahasenack: so `virsh start web` just returns
[15:09] <adamretter> ahasenack: `virsh list --all` then lists `web` as "running"
[15:10] <ahasenack> adamretter: sounds good?
[15:10] <adamretter> ahasenack: yeah except that it isn't running
[15:10] <RoyK> can you see it in "ps axf"?
[15:10] <ahasenack> is there a qemu process for it?
[15:10] <adamretter> ahasenack: if I try `virsh console web` then I get nothing. Also if I try to SSH or access the services from that VM I get nothing
[15:10] <ahasenack> that^
[15:11] <adamretter> ahasenack: yes there is a qermu process for it
[15:11] <adamretter> ahasenack: s/qermu/qemu/
[15:11] <RoyK> try to start virt-manager
[15:11] <adamretter> RoyK: I only have virtsh
[15:11] <RoyK> well, install virt-manager, then
[15:12] <RoyK> remote x works well
[15:12] <ahasenack> maybe it's stuck in boot somewhere
[15:12] <ahasenack> yeah, try to get a console somehow
[15:12] <ahasenack> I don't know if "virsh console" shows everything correctly, I also always use virt-manager for the console
[15:12] <adamretter> ahasenack: I would have thought so, but I get NOTHING on the console - i.e. `virsh console web` just shows:
[15:12] <adamretter> Connected to domain web
[15:12] <adamretter> Escape character is ^]
[15:13] <mason> virsh requires a serial console to be set up, doesn't it?
[15:13] <mason> whereas virt-manager defaults to SPICE, unless I'm confused.
[15:14] <adamretter> mason: hmm good question. One moment.
[15:14] <mason> So, if you don't have a serial console set up, I imagine 'virsh console web' is working, but not connected to an actual getty.
[15:18] <adamretter> mason: okay so, I just tried accessing it via vncdisplay. I can see the console via VNC and can see that it crashed during boot
[15:21] <adamretter> So the error on boot is: "VFS: Unable to mount root fs on unknown-block(0,0)"
[15:22] <adamretter> any idea why this would happen after updating the host
[15:23] <ahasenack> hm
[15:24] <ahasenack> can  you try booting into the previous kernel by intercepting the boot and using the grub menu? That would be one thing
[15:24] <ahasenack> maybe,
[15:24] <ahasenack> hm
[15:24] <ahasenack> maybe your /boot got full with kernels and the initramfs generation failed because of a disk full error, which you didn't notice?
[15:25] <ahasenack> I would check things like that
[15:33] <adamretter> ahasenack: when you say, booting into previous kernel, do you mean the host or the guest
[15:36] <mason> adamretter: The box that can't find its root.
[15:36] <mason> adamretter: The guest.
[15:36] <adamretter> mason: hmm I don't think I can intercept the boot menu over VNC as by time VNC connects the boot menu timeout has already passed
[15:41] <mason> adamretter: Boot the VM with rescue media then, and explore from there I think.
[15:43] <adamretter> mason: Wooohoo! okay cool. I managed to get to the boot menu via VNC and yeah seems to be a kernel bug. So the older 4.15.0-23-generic works fine. But the latest installed 4.15.0-33-generic causes the hang at startup.
[15:43] <mason> adamretter: It's probably not a kernel bug. You probably didn't get an initramfs properly generated.
[15:43] <adamretter> mason: hmm interesting
[15:44] <adamretter> mason: well i will try updating to the latest kernel etc via apt-get dist-upgrade and see if that fixes it
[15:44] <adamretter> mason: thanks for your help so far :-)
[15:44] <adamretter> ahasenack: thanks for your help too
[15:44] <mason> adamretter: See ahasenack's advice about looking at free space, also.
[15:44] <adamretter> I have to go get some dinner, back in an hour or so
[15:44] <adamretter> mason: I have 10GB of free disk space. Disk is only 20GB
[15:45] <adamretter> bbl
[16:39] <plm> Hi all
[17:13] <teward> how did I get parted from here :|
[17:27] <RoyK> ?
[17:31] <teward> nevermind >.>
[17:36] <tomvolek> anybody here has installed Openstack with Ubuntu ? Like to talk on sideline
[17:38] <ahasenack> powersj: so I ignored that prompt about /boot (in the guided lvm partitioning on ppc64el), told it to continue, and the installation finished just fine
[17:40] <powersj> hmm was the prompt a red warning?
[17:40] <powersj> or just asking?
[17:49] <RoyK> ahasenack: what sort of machine is this?
[17:50] <ahasenack> RoyK: ppc64el
[17:50] <ahasenack> powersj: a warning defaulting to "do not proceed"
[17:50] <ahasenack> I should have gotten a screenshot, hang on, give me aminute
[17:50] <ahasenack> powersj: I tried with amd64 and uefi (in a vm), and it didn't bug me about a missing /boot
[17:51] <RoyK> ahasenack: an old mac?
[17:52] <ahasenack> RoyK: no, a ppc64el vm inside a power8 big iron machine
[17:57] <ahasenack> RoyK: powersj: http://people.ubuntu.com/~ahasenack/guided-lvm-missing-boot.png
[17:58] <powersj> ah! I believe that message is fine as it is a final check to be sure you really didn't mean to have a /boot
[17:59] <powersj> but someone with more power/di experience can correct me
[17:59] <RoyK> ahasenack: is this thing using grub?
[17:59] <ahasenack> powersj: yeah, but I haven't seen it elsewhere, just ppc64el so far
[17:59] <ahasenack> RoyK: yes
[18:00] <RoyK> grub can boot from lvm
[18:00] <RoyK> at least on x86/x64
[18:00] <ahasenack> powersj: if /boot is needed, I would have expected the "guided" experience to create it for me. If it's not needed, then I would expect to not see this warning
[18:00] <ahasenack> RoyK: yes, and it works, my complaint is about the (seemingly useless) warning specially when I selected a "guided" style of partitioning, i.e., "please partition this whole disk for me"
[18:00] <powersj> ahasenack, right I forgot about the guided part
[18:01]  * RoyK prints out a small apatosaurs in almost natural size
[18:01] <powersj> that is worth a bug
[18:01] <ahasenack> agreed, just not a blocker one I think
[18:01] <ahasenack> I'll file it
[18:02] <adamretter> back
[18:05] <adamretter> So I have something very strange going on with this Ubuntu 18.04.1 VM. I did an `apt-get dist-upgrade` on it to get the latest kernel. I can see /boot/vmlinuz-4.15.0-36-generic. But 4.15.0-36 doesn't appear in the boot menu, and previously trying to boot 4.15.0-33  would crash at boot, but now boots fine.
[18:08] <RoyK> what sort of virtualisation?
[18:09] <adamretter> RoyK: KVM
[18:10] <adamretter> RoyK: Host is also Ubuntu 18.04.1
[18:10] <ahasenack> adamretter: maybe the update-grub step failed when you did the dist-upgrade
[18:11] <ahasenack> run this to verify nothing was left pending: "sudo apt update && sudo apt -f install"
[18:18] <adamretter> ahasenack: It said there was nothing to be done
[18:20] <ahasenack> check if the kernel package is really installed (dpkg -l|grep linux-image), and ls -la / and look for the vmlinuz symlink
[18:20] <ahasenack> if all checks out, just run sudo update-grub
[18:21] <ahasenack> that is what constructs the grub menu based on what is installed
[18:25] <adamretter> ii  linux-image-4.15.0-36-generic
[18:25] <adamretter> lrwxrwxrwx   1 root  root     30 Oct 17 18:53 vmlinuz -> boot/vmlinuz-4.15.0-36-generic
[18:25] <adamretter> lrwxrwxrwx   1 root  root     30 Oct 17 18:53 vmlinuz.old -> boot/vmlinuz-4.15.0-33-generic
[18:33] <ahasenack> powersj: just lacking arm tests now, as usual
[18:33] <powersj> ahasenack, 64 or hf?
[18:33] <ahasenack> both
[18:33] <ahasenack> er, hold
[18:33] <ahasenack> arm64 is done
[18:34] <powersj> ok
[18:34] <ahasenack> just "Ubuntu Server armhf+raspi2	"
[18:34] <ahasenack> is missing
[18:34] <powersj> we had testing on it earlier this week
[18:51] <adamretter> ahasenack: so I don't quite understand why it is saying that /vmlinuz is linked to /boot/vmlinuz-4.15.0-36-generic. But uname -av reports: Linux web 4.15.0-33-generic #36-Ubuntu
[18:51] <ahasenack> adamretter: the /vmlinuz link points at the kernel that you should boot into the next reboot, it's the "default" kernel
[18:59] <adamretter> ahasenack: okay I just ran "sudo grub-update" and rebooted. I still only see 4.15.0-33 in the Grub boot menu, when booted, uname -av still reports 4.15.0-33, but /vmlinuz still points to /boot/vmlinuz-4.15.0-36-generic --- super weird!
[19:00] <ahasenack> adamretter: it's update-grub
[19:01] <ahasenack> adamretter: and it will tell you which kernel images it is processing. Check if 4.15.0-36 is in its output
[19:01] <adamretter> ahasenack: ah right yeah, sorry, I did run `update-grub`
[19:01] <ahasenack> example: https://pastebin.ubuntu.com/p/dWZHfqkr4B/
[19:01] <adamretter> ahasenack: yes 4.15.0-36 is in the output
[19:02] <ahasenack> adamretter: then maybe you are selecting another kernel in /etc/default/grub, check GRUB_DEFAULT=0 there (0 means the first kernel from the list)
[19:02] <ahasenack> adamretter: or, the grub you are booting from is not the grub that is being updated. Maybe you have grub installed in another disk
[19:02] <adamretter> ahasenack: it isn't in the grub menu list at all
[19:02] <adamretter> ahasenack: this is grub2 is that any different?
[19:05] <adamretter> ahasenack: also the VM only has 1 disk
[19:05] <ahasenack> adamretter: I don't know at this point
[19:05] <ahasenack> adamretter: you could try booting into the grub menu, and editing it live
[19:06] <ahasenack> change the kernel and initramfs lines to point to the new kernel, and then reboot
[19:06] <ahasenack> see if that works
[19:06] <adamretter> ahasenack: okay let's try that
[19:06] <mason> ahasenack: Did you see a disk layout? I'm wondering if he has /boot separate and it's not mounting or somesuch.
[19:06] <ahasenack> I didn't see it
[19:07] <ahasenack> (didn't ask for it)
[19:08] <adamretter> ahasenack: so live editing the boot menu in Grub does then cause it to boot 4.15.0-36 correctly
[19:08] <adamretter> ahasenack: so i guess the question is, why is my grub boot menu not being updated
[19:08] <mason> Ah, discard my idea then. Not relevant.
[19:08] <ahasenack> so maybe it's what mason suggested
[19:08] <ahasenack> or not? :)
[19:09] <mason> ahasenack: I don't think it's my idea. If he can edit grub to boot, then the correct initramfs is available.
[19:09] <ahasenack> it looks like whatever update-grub is updating, it's not being used by the grub you are booting
[19:11] <TJ-> adamretter: can you show us "pastebinit <( lsblk; mount; ls -latr /boot/ /boot/grub/; cat /etc/fstab /etc/default/grub /boot/grub/grub.cfg )"
[19:12] <ahasenack> fancy :)
[19:12] <mason> <( ) is bash's "cartoon tell me" syntax
[19:13] <sarnold> lol
[19:13] <TJ-> mason: I thought it was bash's party hat
[19:13] <mason> TJ-: Only if you turn your head the right way.
[19:13] <adamretter> http://paste.ubuntu.com/p/WVytQqbz5b/
[19:13] <TJ-> mason: asleep zzzzz <( )-[=]<
[19:14] <mason> heh
[19:14] <adamretter> I wonder if I have a weird Grub 1 vs Grub 2 thing going on. I have a feeling this VM was upgraded some time about from Ubuntu 16 to Ubuntu 18
[19:14] <TJ-> ooo I see grub v1 there
[19:15] <mason> 16.04 used grub2
[19:15] <TJ-> adamretter: show us "pastebinit <( apt list --installed grub* )"
[19:16] <ahasenack> I see menu.lst, is that still used?
[19:16] <adamretter> http://paste.ubuntu.com/p/82xVWbThrq/
[19:16] <ahasenack> what happens when there are both menu.lst and grub.cfg files?
[19:16] <adamretter> I vaguely recall the dist-upgrade tool in the past telling me it was going to chain-load grub 1 from grub 2 and that a proper upgrade to grub 2 could be done later
[19:16] <TJ-> ahasenack: it depends on which grub has it's core image in the boot sectors I guess, looks like grub v1 won
[19:17] <ahasenack> adamretter: what's in that menu.lst file?
[19:17] <adamretter> ahasenack: /boot/grub/menu.lst looks like the menu I see when I reboot and Grub loads
[19:17] <TJ-> adamretter: so the installed packages from the distro are all grub v2 but the system has a residual grub v1 boot config. I'd suggest replaceing grub v1 boot-loader with v2, using "sudo grub-install /dev/sda"
[19:17] <ahasenack> maybe grub-install /dev/sda is what's needed?
[19:17] <ahasenack> that^
[19:18] <TJ-> adamretter: this command subject to other's agreement
[19:18] <adamretter> TJ-: okay well I have a backup of the VM's qcow2 image... so if it all goes wrong ;-)
[19:18] <TJ-> adamretter: we might want to ensure "grub-install" is the one from grub2
[19:18] <adamretter> grub-install (GRUB) 2.02-2ubuntu8.6
[19:18] <adamretter> already checked ;-)
[19:19] <TJ-> adamretter: check with "pushd /; md5sum -c /var/lib/dpkg/info/grub-common.md5sums | grep -v OK; popd"
[19:20] <TJ-> adamretter: that should not report any FAILED
[19:20] <adamretter> TJ-: I just get weird output from that like:
[19:20] <adamretter> ~
[19:21] <adamretter> \/ ~
[19:21] <adamretter> and then ~
[19:21] <TJ-> oh silly me I missed out the 2!
[19:21] <adamretter> if I just cd /
[19:22] <TJ-> adamretter: check with "pushd /; md5sum -c /var/lib/dpkg/info/grub2-common.md5sums | grep -v OK; popd"
[19:22] <adamretter> and then run the md5sum bit - then yes everuthing is "OK"
[19:22] <TJ-> grub2-common not grub-common :)
[19:22] <TJ-> adamretter: in which case go ahead with "sudo grub-install /dev/sda"
[19:22] <adamretter> sure.
[19:22] <adamretter> still OK
[19:22] <adamretter> okay - rebooting
[19:23] <adamretter> okay cool
[19:24] <adamretter> All is good. It booted into the new kernel 4.15.0-36
[19:25] <adamretter> Only thing to report is that whatever menu graphic Grub2 is trying to display at boot, does not export well over VNC - you just get coloured garabge
[19:25] <TJ-> adamretter: in /etc/default/grub uncomment "#GRUB_TERMINAL=console" and "sudo update-grub"
[19:27] <adamretter> TJ-: I find the fact that that is not the default setting just terrifying
[19:28] <adamretter> okay can I uninstall grub1 now?
[19:29] <TJ-> adamretter: the packages were not installed according to apt, or if they are, apt/dpkg lost track of them at some point. You'd need to identify which package they originally came from and get a copy of that package to identify the files/checksums, to remove them safely.
[19:30] <adamretter> TJ-: okay never mind then
[19:30] <adamretter> Okay TJ-, ahasenack, and mason. Many thanks for all your help and patience, we got there in the end
[19:31] <TJ-> adamretter: the files are dated "Mar 16  2012" which may suggest they came from the package in 12.03
[19:31] <TJ-> 12.04 even
[19:31] <adamretter> TJ-: could be, I have had this VM for many years and just dist-upgraded it from time to time
[19:32] <sarnold> you'd probably be better served to use do-release-upgrade instead
[19:32] <TJ-> adamretter: I'd guess it'll be http://old-releases.ubuntu.com/ubuntu/pool/main/g/grub/grub_0.97-29ubuntu66_amd64.deb since that is timestamped 2012-03-16 20:03
[19:33] <adamretter> sarnold: that might have been what I did. sorry I forget now, but that sounds familiar
[20:04] <plm> TJ-: hey, Can I to test the script? =D
[20:04] <plm> TJ-: Did you finished?
[20:06] <TJ-> plm: no, it requires more work. Although it can work for me it's not in supportable state. I'm looking for an alternate approach that ensures regular package upgrades don't break it fatally
[20:16] <plm> TJ-: hmm.. understood. Well, when you have a better approach, I would like to use/test the script! =D
[20:17] <plm> TJ-: do you think next week has something? =D