[01:17] RoyK: i think i found the problem... this workstation has an nvidia card in it and has drivers installed for the ability to utilize the GPU for some data processing. I think that Failed to Build and caused the issues. [01:17] or that the version of the kernel or something exploded it, it *looks* like it's OK now but not sure... [01:18] we'll see if this fixes it *yanks out the graphics driver while in the older kernel* [02:04] teward: hehe [02:12] aaaaand it still explodes. I'll just say "Screw It" and nuke it and put 16.04 on it, then containerize the 18.04 instances (or Virtualize them in my VMware cluster instead, depending on what resources I need) === rchavik_ is now known as rchavik [07:03] Hello. Unfortunately, I'm in need of installing a very old version of PHP, a large site that currently uses PHP 5.1 and the size of the system makes it almost an impossible task to update. Is it possible, in any way, to install that old a version of PHP? [07:23] repox: You could try creating an lxd or docker container that's based off an older version of the OS which has packages for that version od PHP [07:58] Hello! [08:01] I'm responsible for a server that keeps crashing about 30-40mins every night or so, is there a way to monitor the status of the machine in order to see if it's a hw issue or something else? [08:06] I should say it's a VM the company rent from another company so I don't have access to any BIOS or such [12:12] xnox, hi. re: systemd in xenial-proposed. i see you verified the pending LP bugs, cool. anything else i should be doing other than leaving you alone and waiting (hm, and because it's sytemd, the #days in proposed criterion is like, more than the usual 7 days?) thanks :) [12:33] good morning [12:46] kstenerud: I see you grabbed the fetchmail bug, correct? [12:50] ahasenack: yes, but I'm hitting a git ubuntu build bug [12:50] which one? :) [12:50] 10/24/2018 05:29:23 - ERROR:stderr: awk: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory [12:50] awk: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory [12:50] [12:51] ok [12:51] I did some snap reverts to fix that [12:51] let me show you what I'm running [12:51] core 16-2.35.5 5742 beta canonical✓ core [12:51] git-ubuntu 0.7.4+git107.2aadcff 438 edge canonical✓ classic [12:52] That should have been fixed in edge a while ago. [12:53] (edge git-ubuntu with any core snap) [12:53] kstenerud: can you try the above revisions [12:53] ? [12:53] umm not sure how to do that. There's nothing to revert to [12:53] kstenerud: check the revisions first, use snap list --all [12:54] git-ubuntu 0.7.4+git16.0a79cbc 391 stable canonical✓ classic [12:54] that's all there is [12:54] kstenerud: switch to the edge channel for git-ubuntu [12:54] Switch to edge and that should be sufficient I think. [12:54] Except for this new build-source regression :-/ [12:54] how do I do that? [12:54] * rbasak should fix that [12:54] kstenerud: snap refresh --classic --edge git-ubuntu [12:54] kstenerud: check arguments for snap refresh [12:55] (with sudo probably) [12:55] ^that [12:55] rbasak: no ping from smoser yet? [12:55] No. I'll revert. [12:56] kstenerud: if you get git-ubuntu r439, there is another bug, you have to revert to r438 then. I ssume that is still available in the store, and not just locally [12:58] ahasenack: I can only revert to 439 [13:00] kstenerud: have you tried snap revert --revision=438 git-ubuntu ? [13:00] I've pushed the revert and fired off a build. I should be able to fix edge in about half an hour if the build succeeds. [13:00] cannot find revision 438 [13:00] kstenerud: ok :( [13:00] kstenerud: I guess use the traditional way for now. Create the container, scp the git tree there, and build there [13:00] ok [13:00] or sbuild, or any other of the common tools to build packages in a pristine environment [13:01] kstenerud: did you reproduce the fetchmail ssl problem with gmail? [13:01] yup [13:01] cool [13:06] ahasenack: git ubuntu build and build-source both fail. Is there another way to build? [13:07] kstenerud: create a container, scp/rsync the git tree there, cd into it, run "sudo apt-get build-dep ./" to install build dependencies, and then run "dpkg-buildpackage -us -uc -S" for source, and sans the -S for binaries [13:07] -us -uc is to not debsign it, you can omit those if you want to sign [13:27] bleh [13:27] builddeps:./ : Depends: libgssglue-dev but it is not installable [13:28] did you run apt-get update? [13:28] oh right [13:32] hmm [13:32] dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../fetchmail_6.3.26.orig.tar.{bz2,gz,lzma,xz} [13:38] Uh... I noticed this morning that MySQL was dead in the water. Before it shutdown systemd in journalctl says "Starting Daily apt download activities", then "Stopping MySQL Community Server"... Then mysql shutsdown then systemd says "Stopped MySQL Community Server" and then it says reloading a bunch of times, does it and is complete. [13:39] What is the best way to turn that off? Do I just kill app-daily.timer, app-daily-upgrade.timer? [13:51] made a NTP server config https://paste.ee/p/glq8t#9epWVpo4XpxTPHodZQSQqoghZwOLePeo is this accurate? [13:55] kstenerud: you can fetch the upstream tarball via git ubuntu: git ubuntu export-orig [13:55] or install ubuntu-dev-tools and use "pull-lp-source -d

" [13:55] that will download the source package which will contain the orig tarball, and -d is to not extract it [13:56] SJr: that's from unattended-upgrades, a package [13:56] SJr: it has config options in /etc/apt/apt.conf.d/* [13:56] SJr: you can blacklist packages there, for example, and adjust many other settings [13:57] SJr: or remove it entirely if you prefer, of course [14:35] SJr: that was a MySQL security update. You should probably be updating these. If there was a problem with the update, let's fix that :) [14:42] * RoyK thought mysql was replaced by mariadb [14:43] i though only maria could use mariadb [14:48] rbasak: my samba bionic sru upload was correctly rejected because it missed this: https://pastebin.ubuntu.com/p/VBS6vz7Jtv/ [14:48] rbasak: can I just fix, push the tag and upload again, or do we want to review this change? [14:49] "Rejected by Brian Murray: No Launchpad-Bugs-Fixed in the changelog / .changes file." [14:50] it's correct in cosmic [14:51] ahasenack: I don't think I need to review that. I think self-approving that kind of thing is fine. [14:52] rbasak: ok, I'll update the upload tag as well [14:55] rbasak: is the snap published yet? [14:57] I'd left Jenkins running. Let me see if I can upload it now. [14:57] It's ready, publishing now. [14:58] kstenerud: ^that snap should work wrt build{,-source} [14:58] r440 I suppose [14:59] Uploaded, just waiting for the store now. It's usually a minute or two. [14:59] Yeah I see it'll be r440 if it is approved [15:03] RoyK: nope. [15:03] RoyK: both are packaged and available in Ubuntu. [15:03] MySQL is in main. [15:04] MariaDB is in universe. It gets looked after by a volunteer. [15:09] ahasenack: kstenerud: fixed git-ubuntu published in edge. [15:09] nice [15:09] I shouldn't have hesitated yesterday to revert. Sorry. [15:10] Download snap "git-ubuntu" (440) from channel "edge" - [15:10] Download snap "git-ubuntu" (440) from channel "edge" - [15:10] Download snap "git-ubuntu" (440) from channel "edge" [15:10] ops, sorry [15:10] copy & paste of terminal lines that have progress status is bound to be a mistake [15:46] rbasak, how would I fix that, submit a bug to the package maintainer? [15:50] SJr: start by identifying whether it's a problem on your local system first please. [15:50] (I am the maintainer) [16:40] Ah well I'm not sure rbasak, just to make sure, I'm using MySQL Community 5.7.24 (not Maria DB, which is the default in Ubuntu). I don't see anything in the logs, other than systemd shutting it down. I don't see any attempt at starting it back up. [16:42] The only log entry in the mysql unit is that systemd is stopping it, apt-daily doesn't mention anything. The apt log, just says mysql-server and mysql-server-core were changed. [16:42] It started right back up, when started mysql up without incident, and the shutdown was clean. [16:43] SJr: MariaDB is not the default on Ubuntu. [16:45] I found a stack overflow post about this with no real answer. [16:45] https://askubuntu.com/questions/1037285/starting-daily-apt-upgrade-and-clean-activities-stopping-mysql-service [16:45] SJr: you could try downgrading and then trying an upgrade manually to get an idea of what might be going wrong. Or indeed just "apt-get install --reinstall mysql-server-5.7" might reveal any problems. [16:45] The upgrade absolutely will stop and start the service. That part is expected. [16:46] You shouldn't need to manually restart it though. [16:46] Yeah that part I expect to, but the stack over flow post is complaining about it not being restarted. [16:47] Hrm running that apt command says "AUtomatic maintenance of MySQL server daemon disabled. Packaging maintainer scripts detected a case that it does not know how to handle and cannot continue configuring MySQL. Automatic management of your MySQL installation has been disabled to allow other packaging tasks to complete, For more details, see /etc/mysql/FROZEN" [16:49] "In this particular case, an incompatible downgrade attempt has been detected. This can be resolved in one of two ways..." [16:50] Ah [16:50] I'm not sure what it is detecting, apt says: "Unpacking mysql-server-5.7 (5.7.24-0ubuntu0.18.04.1) over (5.7.24-0ubuntu0.18.04.1) ..." [16:50] That's your problem. It's not a bug in the package - your system has a broken installation caused by switching from MariaDB to MySQL. [16:52] I dunno if I would say it's a bug in the package per say, but this is less than ideal. Basically a working mysql installation will get stopped without incident, and then upgraded, and then just not restarted for reasons that have no visibility in the system logs and aren't apparent looking at that folder. [16:53] This kind of failure, should not upgrade the package and just leave it stopped. [16:57] I agree it's not ideal. [16:58] We started doing it this way because we didn't think the situation was enough to warrant breaking users systems by failing the maintainer script. [16:58] The intention was to leave the system alone rather than mess with it. [16:58] Shutting down the daemon first is obviously not desireable. [17:00] The error reporting is not great either, the status of the mariadb packages was rc (removed but config files present), I have purged those packages, and yet it still won't install. [17:00] Is it time to bust out strace to see what it's looking at [17:01] It's because your database in /var/lib/mysql isn't clean. It's likely been modified by MariaDB (internal schema upgrade to MariaDB-specific things) in a way that MySQL can't necessarily understand. [17:01] Yet mysql has run without issue for months [17:01] You should treat your databases as corrupt and recover them as if MySQL encounters something that MariaDB did you might get undefined behaviour. [17:01] Depends on what queries you run. [17:02] Or a future security update might cause it to fail, etc. [17:02] You might even be getting bad query results without realising. [17:05] How many heuristics are there that you are checking? This seems unlikely, I'm 80% confident I completely nuked this directory during the switch. [17:08] You definitely didn't, because it's the mismatching /var/lib/mysql/*.flag files that are stopping the maintainer scripts from touching it. [17:08] That's the only heuristic. [17:09] There are no files in there. [17:09] with *.flag [17:09] Oh [17:09] Then you need to remove /etc/mysql/FROZEN [17:09] There is an old directory called /var/lib/mysql-5.7 that might be left over garbage. [17:09] Mismatching *.flag enters the frozen state. You have to remove FROZEN to get out of it. This is documented in the message. [17:10] I don't believe the packaging will touch that. [17:10] I forgot about the latching behaviour, so I was wrong about "definitely" above, sorry. [17:11] Oh so yes, FROZEN is very old actually. [17:12] Once you've removed FROZEN, I'd run the reinstall again just to check that the maintainer scripts will no longer complain. Note that they'll try to touch the database for the first time in a while, so depending on the previous state you may get an attempted schema upgrade etc, so watch out for your data (have backups etc). [17:13] Is there anything to write a bug report about or improve it? For instance actually log something in systemd? Not do unattended upgrades if you are frozen? [17:13] The stack overflow post number one suggestion is to disable automatic updates. [17:13] :) [17:15] I think there are improvements that can be made, yes, so please feel free to file a bug. [17:15] I think the essence is that once in frozen mode, after a reboot the daemon may still start, and upgrading will stop it. [17:16] And secondarily that it didn't log the message where you expected to find it. [17:17] So the bug gets filed on launchpad against the mysql-server-5.7 package? [17:19] Yes, thanks! [17:19] Please could you also explain in your report where exactly you looked for the logs (ie. where you expected to find the note)? [17:19] That'll help inform where to put things. [17:20] For example using logger to dump to syslog (which should end up in the systemd journal I think) that we refused to start the daemon should be really easy to do, if that would have worked for you. [17:21] Yeah also for your edification you should know that much of my config is actually managed by ansible with explicit stops and starts of services around installation and upgrades. [17:22] I remember maria having some weird issue that I didn't want to deal with and then being in hell for an hour while I switched. [17:22] In that case consider using mysql-server-core-5.7 only, without mysql-server-5.7. [17:22] That'll give you full control. You'll get the binaries only. [17:22] (though in case of security update you'll have to take care of restarting the service yourself) [17:23] I don't understand how you got MariaDB accidentally. It's not the default. [17:23] Though also, if you're using ansible, then redeploy your server when you make a major change, please! [17:25] I didn't accidentally get it, I thought I should get with the times and use it, so I tried it and there was some small problem I didn't want to deal with. [17:25] Oh, I see, thanks. [17:26] It's a good tip knowing about mysql-server-core-5.7, because yeah I found ansible is really going against the grain with a lot of ubuntu and interacts weirdly. [17:26] MySQL development is still active, FWIW. The next Ubuntu release may have MySQL 8.0 if all goes well. [17:31] Interesting, well in 5 years when I upgrade this server off 18.04 I can finally partake :) [17:39] Is there a reason launchpad doesn't let me select mysql-server-5.7 as a bug and only mysql-5.7? [17:40] Oh, sorry, yes. [17:40] SJr: because mysql-server-5.7 is a binary package created from the mysql-5.7 source package [17:40] ^ that's why [17:40] Right :) [17:41] so filing against mysql-5.7 on Launchpad is the correct thing to do. [17:41] *hands rbasak the "You forgot to mention that" card* [17:41] Thank you rbasak, and teward, I would not have figured this out at all without your help :) [17:42] Not just that but I confirmed the wrong thing earlier. It even felt wrong to me at the time but I couldn't figure out why, so I concluded it was right :-/ [17:42] SJr: you're welcome. Thank you for the report. It will help us improve things for all users. [17:46] mdeslaur: you might also want to chime in on https://answers.launchpad.net/ubuntu/+source/php7.0/+question/675535, if you have a moment [17:49] nacc: ack, done [17:49] mdeslaur: thanks! [18:00] any one else reporting issues with cosmic in vmware? [18:02] Epx998: someone else had trouble with it in #ubuntu today. [18:02] vmware workstation though, but i guess it boils down to the same thing regarding vmware tools? [18:13] Bug submitted, rbasak: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1799763 [18:13] Launchpad bug 1799763 in mysql-5.7 (Ubuntu) "Frozen MySQL-Server does everything fine except security updates don't restart" [Undecided,New] [18:15] heh, love the launchpad id :) [18:17] tomreyn: not sure, i cannot get thru the install. Though I have esxi on a desktop upstairs and had no issue. baremetal on another chassis and vmwar+dell resulted in failed deployments [18:17] SJr: thanks! [18:17] SJr: what a short IRC nick you have! :) [18:18] Too short for freenode? [18:18] Too short for your Launchpad ID :) [18:20] does anyone here use the nextcloud snap? i can't figure out how to change the https port [18:20] on ubuntu server 18.04.1 [18:21] this is also the first time i've used snaps [18:21] munsking_: `snap info nextcloud` -> contact: https://github.com/nextcloud/nextcloud-snap [18:21] you'd want to file an issue there, or look through their docs, etc. [18:21] "If you'd like to change the HTTP port (say, to port 81), run:" [18:21] neat [18:22] next line in the README includes https port :) [18:22] nacc: thanks a ton, that's exactly the info i need, my own fault for not looking at github [18:22] nacc: does that also include where to file bugs? [18:22] sarnold: i assume so, based upon it being the contact line [18:22] there are a ton of issues filed :) [18:22] 20 different guides and not a single one mentioned it [18:23] munsking_: `snap info...` is the first place i'd go to for any given snap [18:23] nacc: thanks, i've just seen a fair number of complaints about snaps just filed on any old random package on launchpad and wondered where to send people [18:23] sarnold: yeah, it's a per-snap thing [18:23] https://docs.snapcraft.io/configuration-in-snaps/510 [18:23] munsking_ [18:24] yep, that's what's referred to on github as well [18:24] yea, i'm sorry, i should have RTFM, i usually do... [18:24] looks like it's documented then. [18:24] thanks a ton though, all of you [18:26] munsking_: not a problem! snaps are not obvious until you are used to them :) [18:27] how do snaps update? are they "included" with apt update/upgrade ? or does it have its own manager? [18:27] munsking_: their own manager, they updated on a periodic timer [18:27] munsking_: iirc, it's a systemd timer, and it fires in some semi-random offset N times a day, where N might be 4 ? [18:27] I can't recall for sure [18:27] munsking_: you might want to ask that in #snappy [18:28] nacc: oookay, automatic or does it require user input? if it's automatic it sounds a bit too windows-y [18:28] nacc: alright, i'll have a look [18:28] munsking_: automatic fully [18:28] ouch [18:28] munsking_: with snaps, you are trusting the upstream to know when you need updates [18:28] (at least, that's how i see it) [18:28] it looks like it's part of the snapd systemd service [18:29] nacc: this might have been a mistake, windows broke all my trust for auto updates, maybe snaps can restore some of it [18:30] munsking_: tbc, snaps are more confined than windows updates. They aren't OS updates, but applications. [18:31] aren't snap shipping a full OS (16.04?) too? [18:31] nacc: true true, but still, configs might break, or defaults might be the opposite of what i need, and this nextcloud is live and public, not just some internal thing. [18:31] i'll check if i can disable or delay it or something [18:32] or maybe it just works [18:37] ok the https stuff worked :D thanks! [18:45] munsking_: well, that's what CI is for upstream. Again it's a trust model :) [18:45] sdeziel: you mean the core snap? yes, but that's only used by other snaps [18:46] nacc_: hmm, I though that each snap bundled one which would have explained why vlc's snap weights 555M === sarnold_ is now known as sarnold [18:46] nacc_: I can't read, vlc's snap weigths 204M, still a bit high for just a media player, I always though there was more to it [18:47] nacc_: i'm forced to be a windows admin at work, i assume you can guess where my trust is ;) to be fair, in the ~6 years i've been linux (main OS at home, several webservers) my trust in linux has never been broken (only the trust in my own abilities lol) [18:48] is it possible to rebuild the squashfs and kernel with the vmtools already added? [18:50] Epx998: anything is possible :) [18:50] sdeziel: it depends on the type of snap, tbc [18:51] sdeziel: vlc is confined, so it relies on the core snap for the base OS interface [18:51] nacc_: I came to the conclusion I should read more on snaps :) [18:51] sdeziel: the reason for the bloat is all of the dependencies are shipped in the snap [18:52] sdeziel: yeah, it's a very different way to do things, tbh === albert23` is now known as albert23 === kees_ is now known as kees [20:33] Hi all [20:34] $ sudo losetup -P /dev/loop0 rootfs.img [20:34] losetup: rootfs.img: failed to set up loop device: Device or resource busy [20:34] Anyone know why this error? I just boot my ubuntu host and try that. [20:35] A information. Yesterday I updated my ubuntu host 16.4 [20:36] plm: something already on loop0 ("losetup -a" ) [20:37] TJ-: $ losetup -a [20:37] /dev/loop0: []: (/var/lib/snapd/snaps/pycharm-community_85.snap) [20:37] /dev/loop1: []: (/var/lib/snapd/snaps/core_5662.snap) [20:37] plm: use "losetup --show --find --partscan rootfs.img" and it'll pick a free loop for you [20:37] Or possibly rootfs.img is in use [20:38] TJ-: with "losetup --show --find --partscan rootfs.img" works =D [20:38] plm: you can reduce those options to "--show -f -P" [20:38] TJ-: right =D [20:39] TJ-: $ sudo losetup --show --find --partscan rootfs.img [20:39] /dev/loop2 [20:39] TJ-: now I just use '/dev/loop2' on my mounts/umount options,right? [20:40] plm: well, if there are partitions, no. You'd use /dev/loop2pX where X is the partition number [20:41] plm: If I recall correctly the partition nodes are under /dev/mapper/ [20:42] TJ-: I just substitute loop0 by loop2: [20:42] $ cat mount.sh [20:42] sudo losetup -P /dev/loop2 rootfs.img; sudo mount /dev/loop2p1 /target; sudo mount --bind /etc/resolv.conf /target/etc/resolv.conf; sudo mount --bind /proc/ /target/proc/; sudo chroot /target /bin/bash [20:43] $ cat umount.sh [20:43] sudo umount /target/proc; sudo umount /target/etc/resolv.conf; sudo umount /target; sudo losetup -d /dev/loop2 [20:43] TJ-: ^ [20:43] and that works [20:51] TJ-: are there a way to change name of bash$ when go to chroot? Becouse I always do 'df -h' to know if I'm in a chrooted or not. Any idea? [20:53] the ubuntu default PS1 value knows how to show you schroot names: $ echo $PS1 [20:53] \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$ [20:53] but if you don't use schroot then I think it won't help much [20:53] anyway you can fiddle with PS1 as you need [21:33] Hi all [22:02] hi guys, I'm trying to remove the livepatch notification from my 18.04 LTS Server MOTD [22:03] I've already edited /etc/default/motd-news and set enabled=0 [22:03] is there anything else I should do? [22:03] I've removed the script from /etc/update-motd.d/ too [23:09] RoyK: sarnold: turns out (thanks to #ubuntu-kernel for helping!) it was traced to a firmware/microcode problen [23:09] updated the BIOS in my Z400 workstation and the kernel started working [23:10] anyone have any idea about my issue? :o [23:11] tried restarting and that didn't do it [23:12] ¯\(º_o)/¯ [23:12] dxc: you only want to not display the livepatch info? [23:13] Correct. [23:13] * Canonical Livepatch is available for installation. < that wohle bit [23:13] I did it on some other machines [23:13] But I can't remember how I did it, and I can't find the guide online that I followed [23:14] so I tried bruteforcing it...which didn't seem to work :p [23:14] i think setting it to enabled=0 was incorrect, that would disable all of the updates, aiui; but it sounds like you are saying that it still is displayin the info [23:15] https://patdavid.net/2018/08/ubuntu-ssh-ads-motd/ [23:15] dxc: right, that would remove all of it, which isn't what you said you wanted to do, but let's move past that [23:17] in my motd, I see the welcome message, the documentation links, the sysinfo, then the livepatch crap, then the packages that can be updated/security updates [23:17] I want to remove the livepatch stuff, I've already nuked the news part [23:18] basically, this is how it looks now [23:18] https://paste.ubuntu.com/p/Yf9scTbm3R/ [23:19] https://paste.ubuntu.com/p/ZsqVDKRsf2/ this is how I want it to look [23:24] dxc: i don't know, it seems like removing that /etc/update-motd.d/ file would have been sufficient [23:25] yeah. [23:25] I tried setting it to -x first [23:25] didn't work [23:25] removed it [23:25] rebooted [23:25] etc [23:25] :D [23:27] dxc: is there anything odd about your config? those files all result in generated content in /run/motd.dynamic aiui [23:28] not really, no.. [23:28] I mean, its a bog-standard DO droplet [23:28] using it as a mailserver [23:32] ... [23:32] omfg [23:32] :| [23:33] I fixed it [23:33] lmao [23:33] I was chmod'ing the wrong file :V [23:34] it works now, I'm an idiot, is it friday yet [23:35] thanks nacc_ o/