[05:55] <icey> coreycb: cool
[07:05] <rantanran> Is it possible to use the ubuntu server installer to install on a btrfs raid 1 with luks on each disk?
[07:47] <rantanran> Is it possible to use the ubuntu installer with a btrfs raid1 on luks layout? The installer does not give me that option, but I would be fine providing the layout with parted.
[10:29] <kklimonda> where can I get debugging symbols for ubuntu cloud archive packages? in particular librbd1-dbg 15.2.1-0ubuntu2~cloud0 or equivalent
[12:59] <rafaeldtinoco> kklimonda: iirc there is no dbg packages for the cloud archives. when I was at SEG, and had to debug cloud archive, I would build the same package in a PPA with debug symbols enabled. That would give me "close enough" debug symbols so I could open core dumps and check (for example)
[13:02] <kklimonda> rafaeldtinoco: I actually managed to find (some of?) them here: https://launchpad.net/~ubuntu-cloud-archive
[13:02] <kklimonda> I found a random email somewhere I think that mentioned it
[13:02] <rafaeldtinoco> Oh they created it
[13:02] <rafaeldtinoco> they have now -ddeb PPA
[13:02] <rafaeldtinoco> awesome.. thats new =)
[13:02] <rafaeldtinoco> even to me
[13:02] <rafaeldtinoco> kklimonda: nice
[13:03] <kklimonda> oh, it was a bug - https://bugs.launchpad.net/cloud-archive/+bug/1649979
[13:03] <rafaeldtinoco> oh.. but they dont have all dbgsyms there yet
[13:03] <rafaeldtinoco> ok.. i was aware of this bug
[13:03] <rafaeldtinoco> so.. they're slowly creating them
[13:03] <rafaeldtinoco> as new releases are done (I think)
[13:03] <rafaeldtinoco> mitaka, for example, has only 4 packages
[13:04] <kklimonda> yeah, that seems to be a recent development
[13:04] <rafaeldtinoco> yep, they have just a few :\
[13:04] <rafaeldtinoco> kklimonda: the PPA trick helped a lot
[13:04] <rafaeldtinoco> in the past
[13:04] <rafaeldtinoco> the build machines are similar if not the same
[13:05] <rafaeldtinoco> orelse I just recompiled the source packages with nostrip as DEB_BUILD_OPTION
[13:05] <rafaeldtinoco> and would reproduce locally to check the dumps
[13:07] <kklimonda> yeah, pushing packages with stripping disabled to PPA is a decent workaround
[13:07] <kklimonda> although I already have a local build machine and apt repository, so I'd probably go this round myself
[13:07] <kklimonda> still, not having to do that is great :D
[13:36] <Ussat> So Ubuntu 18.04.4 LTS, How can I exclude the following from updates:  https://pastebin.com/3sNkYM7t
[13:38] <Ussat> I know I can use sudo apt-mark hold <name> but would *mysql* work in this case ?
[13:48] <rbasak> Ussat: within a single distribution release and using official distribution apt sources only, in general holding packages should never break your system if you don't otherwise override apt or dpkg. apt should be aware if an update elsewhere will break a package and refuse to do it. However this does rely on packagers correctly declaring breaking relationships so you're more likely to find packaging
[13:48] <rbasak> bugs than if not holding. However it should be safe to do what you're suggesting - except that of course by holding you're skipping security updates and other bugfixes so you'll be vulnerable in that sense.
[13:49] <rbasak> apt may also hold back other packages, so the security vulnerabilities and bugfixes apply to other packages, not just MySQL
[13:49] <sdeziel> "apt-mark hold '*mysql*'" holds more than the installed packages, it reports holding any package matching the regex
[13:50] <Ussat> rbask, the mysql would be updated seperately. The reason behind this is that it has a 126GB database with 2BILLION records and the update takes....quite a while to put it mildly
[13:50] <Ussat> sdeziel, correct, which is why I checked what was installed that matched that regex first
[13:51] <Ussat> The problem was, that I use an asnible play to update, which, workls flawlessly, except this run there was a mysql update that held everything up because it took, a LOONG time
[13:52] <Ussat> so long that I avctually stopped the update on that box, which failed the ansible gracefully. removed that system from ansible and re-ran the play. That system of course was hosed, to put it mildly , and I restored a backup
[13:53] <Ussat> Now, all is well, I am just trying to avoid the multi hour update on this one system because of a mysql update
[13:54] <Ussat> Honestly, if anyone has a better suggestion,. please feel free
[13:55] <Ussat> of course I would test this on my test system, the issue was not caught on the test system, because, well, I dont have the prod database size on the test box
[13:59] <sdeziel> Ussat: with MySQL 8.0, the Ubuntu package no longer runs the mysql_upgrade script in postinst
[13:59] <Ussat> really....
[14:00] <Ussat> thats what actually was hanging
[14:00] <Ussat> is 8.0 in 18.04.4 ?
[14:00] <sdeziel> Ussat: with 5.7, you might want to use /etc/mysql/FROZEN to bypass most of the postinst
[14:00] <sdeziel> Ussat: no :(
[14:00] <Ussat> sdeziel, I will look into FROZEN, thanks
[14:01] <Ussat> is FROZEN a file there, I dont see it
[14:05] <sdeziel> Ussat: I never used the FROZEN mode myself but was pointed to in comment #7 of LP: #1889472, hth
[14:06] <Ussat> Thanks, looking at that now
[14:09] <Ussat> sdeziel, that looks promising, will need to test
[14:09] <Ussat> It also, looks like the only good option :(