[08:13] bjf: Heads up: argyle is running in PS4 at the moment, and we've been asked to move it to PS4.5 by the end of the week. [09:29] did aufs go away in our 4.0? [09:29] my schroots broke :( [09:34] bjf: apw: Oh, it's not by the end of the week, it's by July 15 (next Wednesday). [09:35] bjf: apw: I've redeployed the service, and opened RT #82789 to open up the same firewall holes as we have for the PS4 deployment. [09:35] Laney: Erk, it sure did... [09:36] apw: Where'd aufs go? [09:36] Laney: You can s/aufs/overlay/ for now (or downgrade). [09:38] infinity: Ya, done that, thanks. [10:32] infinity, it was meant to be there, i am sure tim updated it [12:29] apw: I'm sure modinfo tells me I don't have it. [12:29] Althought, CONFIG_AUFS_FS=m ... [12:29] Wha? [12:52] infinity, yeah its disabled in the makefile, seems to build just fine, so i am proposing to do a non-abi bumper with it enabled [12:53] apw: If it works, that seems reasonable. [13:45] Odd_Bloke, so our "cloud provider" has asked us to move to a new cloud but it's up to us to do that? and i suppose any/all firewall exceptions are also up to us to tell them about? [13:49] awe: do you mind posting your /var/log/apt/history.log somewhere from yesterday's grub2 incident? I'd like to see what exactly did what when your system originally broke to understand the issue better. [13:54] rbasak, in a mtg, and just about to join a standup; I'll ping you when I free up [13:54] OK, thanks. [14:02] bjf: Something like that, yes. [14:03] bjf: But they have at least been fairly responsive; new rabbitmq is at 162.213.33.247 and the firewall holes should have been punched. [14:03] (In their defense, all I had to do was say "copy the PS4 firewall rules", so hopefully they should all be correct) [14:05] Odd_Bloke, since we access it via ip addr, it will require code changes [14:06] bjf: Yeah. :( [14:07] Odd_Bloke, from what you are telling me. the new one is in place and i should be able to switch over right now if i wanted ... correct? [14:08] bjf: That's my understanding; but check first? [14:09] Odd_Bloke, ok ... i'll do a little checking and if it goes well, make the switch [14:13] apw, ^^^^ i'll do some testing to make sure the msgq service is working for the systems we want it [14:16] bjf, sounds good, as i will need to shock-and-awe on the dashboard [14:18] did someone say my name? ;)- [14:18] :) [14:18] infinity, ok just enablnig aufs seems to work just fine, soooo ... i'll get that uploaded [14:19] ogasawara, seems we are missing aufs in the kernel we just did, so i am proposing to do a non-abi bumper for it [14:19] rbasak, http://pastebin.ubuntu.com/11848708/ [14:19] apw: ack [14:19] apw: Works for me. [14:20] apw: I can never decide from minute to minute if my schroots should be overlay, aufs, or lvm, but hey, it's nice to be spoiled for choice. [14:20] apw: (I still wish overlay could paper over the one or two things that make me keep turning to aufs...) [14:21] apw, the 4.0 Wily upload is missing AUFS ? [14:21] rtg: Yep. [14:21] rtg: It's in the config, but apparently disabled in the Makefile. [14:21] (oops) [14:21] infinity, oh, damn [14:22] sure is [14:22] better check the 4.1 branch [14:23] looks like that one is OK [14:23] awe: thanks! [14:23] rtg: Misplaced your cowboy hat in between versions? [14:23] np [14:24] rbasak: So, that totally has apt-get being the culprit, not update-manager. We can stop panicking. [14:25] rbasak: As in, *someone* got impatient that grub wasn't upgrading and ran "apt-get install grub" and said "sure, remove everything" when it prompted. [14:25] In fact, wait. That's grub1, even. [14:25] awe: So, that was totally self-inflicted. [14:26] awe: Your manual installation of grub1 removed grub2, and you said "yes". [14:26] infinity: AIUI, awe had a problem after the update, and he tried to fix it by installing grub [14:26] infinity: but yes, the problem wasn't cause because the grub2 signed package got removed. Must have been caused by some other thing. [14:26] rbasak: Well, there are no removals until that point. [14:26] Right [14:27] infinity, I only did the manual install of grub *after* my system stopped rebooting correctly [14:27] and yes, it was a mistake [14:28] but didn't really worsen or improve anything [14:28] awe: Check. What are/were the symptoms of "not booting correctly"? [14:29] rtg, yes, you ripped aufs out and switch the way it was updated for v4.1 [14:29] I'm dual-booting a macair osx + utopic [14:29] after yesterday morning's update [14:29] apw, right, I'm using the upstream mechanism [14:29] my machine no longer booted into rEFInd [14:29] I got a "Your screwed screen" [14:30] ( ie. do you wanna re-install OS X from TimeMachine backup, fresh install, go online for help, or bring up disk tools ) [14:30] rtg, indeed, i mean that is why the disablement didn't get carried over, one was against ubuntu/Makefile, the other against fs/Makefile [14:30] apw, yup [14:30] so now on restart, I need to do an Option+Pwr boot, and then select EFI boot [14:30] the other options being the two OSX recovery partions [14:31] awe: Curious. I don't know much of anything about rEFInd, but since rbasak's been trying to be helpful, I'll let him keep at it. :P [14:31] * awe heads to yet another mtg [14:31] thanks infinity [14:31] Well, I'm not sure any more :-/ [14:32] Not sure how much more helpful I can be. I was concerned yesterday that there might be a grub2-signed breakage problem, and so when awe's problem appeared, was concerned that it was that. [14:32] But it wasn't, so perhaps my concern isn't as big of an issue (that's the trouble with a sample size of 1). But that doesn't help at all with awe's actual problem, of which I have no idea. [14:36] rodsmith: hey, awe had some issues with rEFInd. Maybe you can help? [14:36] Hi. I'm told somebody has a rEFInd question. I'm the current maintainer. What's the question? [14:36] apw, there are significant changes to overlayfs in 4.2; perhaps you could add to your TODO list to forward port "UBUNTU: SAUCE: overlay: add backwards compatible overlayfs format support V3" [14:36] rtg, ack [14:36] apw, in unstable master [14:36] master or master-next ? [14:37] rodsmith, rbasak, I just joined a planning meeting; short version... I updated yesterday, and my macair no longer boots into rEFInd [14:37] apw, I think I'm gonna drop unstable master-next 'cause it really isn't very useful. what do you think ? [14:37] now, I have to do an 'Option' + Pwr, and select "EFI Boot" every time [14:37] not sure if I re-bless from OS X would fix this? [14:37] This is the first time an Ubuntu update has broken things for me [14:37] awe: Can you get into both OS X and Ubuntu via the Option key? [14:38] I get to rEFInd via the option key, and have only booted Ubuntu from there since [14:38] haven't checked OSX [14:38] awe: If you can get into OS X, try re-installing rEFInd. [14:38] without the option key [14:38] I get a "Do you want to re-install or fix things" screen [14:38] awe: The Ubuntu update probably tried to install/re-install GRUB, which messed things up. [14:39] right [14:39] I'll try a re-install from OS X and see if that fixes things [14:39] awe: The "re-install or fix things" prompt sounds like APT didn't quite set everything up right. [14:39] right [14:39] thanks [15:19] manjo, smb: I see that dm-raid45 hasn't been updated since April 2009. We are carrying it as a SAUCE driver. Do you think it is still relevant ? [15:20] rtg, wow... I will need to look coz I am not sure who is using that [15:20] rtg, depedns on how many people use a non-Intel fakeraid in bios mode... [15:21] Intel MSM and DDS should be handled by mdadm nowadays [15:21] rtg, Sure we will notice (after release) when you rip it out for now [15:22] smb, well, I haven't ripped it out yet. I'm just reviewing SAUCE patches [15:22] smb, wasint there an issue where softraid was not write able ? [15:22] smb, May be that issue with mdadm is already fixed [15:23] manjo, at some point long time ago. but afaict Trusty works without dmraid [15:23] rtg, will that impact backport kernels for lts ? [15:24] manjo, yup [15:24] ugh [15:24] maybe it should wait until after 16.04 to be removed [15:24] when does precise sunset? /me does the math [15:25] 12.04 .. so 17.04? [15:25] yup [15:25] s**t [15:26] rtg, Might be that is what we said before T... But with a crisp memory like mine and we should have written it down... but then maybe we did and I just forgot where [15:27] smb, its no big deal. so far maintenance has been easy, but I wanted to be sure the driver actually still worked [15:29] rtg: If it's any help I can do some tests with a Promise controller; which kernel/ubuntu release would you want testing? [15:29] rtg, I doubt I ever tested the other module ever again after mdadm worked for Intel... and none of my other hw would have fakeraid beyond levels 1 [15:29] rtg, also people using vmware stuff might still need that module on precise [15:29] ok, I'll defer removing the driver [15:47] rtg, we if we are removing it in 16.04 we should disable it in the main build and re-enable it in the lts-backport [15:47] apw, I was thinking _after_ 16.04 [15:53] then you might need to support it in the backports up to and including 18.04 in 16.04 even if it is disabled in those releases [15:53] because it _is_ enabled in 16.04 [15:55] apw, 16.04 is the last backport for 14.04. perhaps we should only enable dm-raid45 in the backport and not in 16.04 proper [15:57] rtg, that was my suggestion indeed [16:09] rtg: I concur with apw (and you). If you intend to drop drivers, do so in 16.04, but add them back to the lts-x kernel. [16:09] infinity, now I just gotta remember to do it [16:09] rtg: Though, you could also drop them in wily and add them back to the lts-w kernel too. [16:09] rtg: Which gives people some time to get used to the idea. [16:10] yup [16:11] rtg: Makes an argument for maintaining lts-w starting around, oh, now, though. So you don't end up with 73 post-its detailing "stuff that needs to happen on top of the backport". :) [16:11] thats just too logical [16:12] Greetings, does the 15.04 kernel have multi-layer overlayfs support? (multi-layer meaning more than 2) [16:15] unixabg, that is a feature of later kernels, so wily may have it iwth the very latest kernels [16:19] apw: humble appreciation for response. [16:20] unixabg, i don't think 3.19 had it, but i am not 100% sure [16:21] apw: would you know what version would have such support? [16:22] I ask since I am wanting to test it some and I need partial .squashfs files for service packs. [16:23] unixabg, looks like v4.0 was the first upstream release with it in [16:23] so only wily very latest kernel would have it [16:28] apw: thank you and I will work on testing with that then. [16:31] apw: what is the shortest route to install and test the 4.x kernel? [16:31] well other than running wily, you could install that kernel from the archive by hand [17:12] apw: thank you for the assistance I will download from http://cdimage.ubuntu.com/daily-live/current/ [18:59] hi, i read that Ubuntu Wily might be based on Linux 4.1. is there a Ubuntu kernel git tree for that already? [19:03] dsd, ultimately Wily will release with 4.2 [19:06] i see [19:07] and have you started the process of moving the patches from 3.19 to a newer kernel like that? [19:07] or is that going to happen a bit later [19:08] dsd, All 4.1 work is happening here until 4.2 is released: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily master-next [19:11] thanks! [20:01] apw: have you worked on casper? I ask since I see an apw there on a commit message. [21:13] unixabg, only in a very peripheral way, but the last upload was in my name in trusty yes [22:24] Good midnight! Anybody still awake?