[00:10] infinity: what do you do to unmount a / that you're currently using, just dont? mount it ro and hope it doesn't fail? [00:12] the 'reason' things are copied to an initramfs at all is because you need them to prepare /, you also need the same tools to 'unprepare' it; having them somewhere in the / you eventually mount is the same problem that you have an initramfs for in the first place, finding the things to mount / [00:13] pivoting back just keeps the entire responsibility for it in the initramfs, it can also unmount things cleanly because it's still not on / [00:14] and even disregarding network or weirder filesystems for /, any given local filesystem is going to vary in how cleanly remount -o ro / is going to be at shutdown, so you depend implicitly on the behaviour of any existing and future filesystem behaviour [00:15] i like the term vortex rather than some allusion to a force that can't exist, btw [00:15] there are a lot of people being introduced to these problems for the first time, and not many of them are choosing to know or care about them [01:37] apw: thanks for the information. so I'm guessing the vivid kernel at the v3.18.7 would be the closest to 3.18.9? [01:39] preempt-rt has a patch for 3.18.9 and one for 3.14.34, as well as some older ones, but I would like to use the latest patch. === gerald is now known as Guest95868 === Elimin8r is now known as Elimin8er === inaddy is now known as tinoco === cking_ is now known as cking [09:46] henrix, the kernel version looks weird if I enable -proposed to try to run few SRU test [09:46] henrix, for example: [09:46] henrix, 3.13.0-46-generic #79~precise1-Ubuntu SMP Tue Mar 10 20:25:33 UTC 2015 [09:47] henrix, 3.13.0-47-generic #78~precise1-Ubuntu SMP Thu Mar 5 15:38:11 UTC 2015 [09:47] henrix, 3.13.0-47 is not there anymore, and 3.13.0-46 has newer built stamp [09:48] henrix, this issue block me to perform certification part of SRU [09:49] taihsiang: correct, that's because 3.13.0-46.79 was a security fix kernel. we had to respin early this week [09:49] taihsiang: this should be fix soon, i'm currently working on respinning the kernels again [09:50] taihsiang: the -47.78 kernel had to be dropped from -proposed and replaced by the security fix kernel [09:51] henrix, ok, that sounds great. one more question: so only precise(lts-trusty-backport) and trusty has such security fix and respinning? [09:51] taihsiang: no, *all* the kernels have that fix [09:51] henrix, e.g. how about precise(3.2) and utopic? [09:51] henrix, oops, understood, thanks! [09:51] taihsiang: np [10:04] henrix, are we going to skip the certification test of the upcoming security-fixed kernel because the kernel team may want to release the security-fixed kernel as early as possible? [10:05] henrix, or the kernel team would like to release the security-fix kernel as the original SRU cycle date? (21 Mar) Then the certification team could have time to have certification test. [10:07] taihsiang: the security kernel has been released already; i believe certification testing will run on the kernels that will be in proposed later this week, for this SRU cycle [10:08] henrix, I see, thanks. === clopez_ is now known as clopez [13:57] zequence: There's a new precise kernel spinning up shortly, FWIW. [13:57] zequence: You'll have a bug number later tonight, I suspect. [15:30] sforshee, hi :), is there an eta for trusty-backport of 3.16.0-33.44? [15:43] ricotz: the utopic 3.16.0-33.44 is still building, so it will take a while. i would say that tomorrow it will be in -proposed [15:53] amitk, is a new tag'd version of idlestat coming out soon? [15:56] henrix, ok, thanks [15:57] cking: I've been thinking about tagging this one. I need to run a few more tests to ensure it is stable enough [15:57] cking: we've already added several new features [15:57] even it it's a 0.5.1 or something, it looks kinda useful with the new features and man page [15:58] *if it's [15:58] cking: ack, let me do some more testing over the weekend and I'll tag it next week [15:59] that's great, no rush [16:01] infinity, Do you know from the top of your head what apt is doing when it "configures" a package as opposed to "unpacking" it? I am having a peek on fixing the false dkms failures and finding it a tad more complex than initially thought. I would imagine configuring runs a package post-inst. Or is there more? [16:02] smb: configure is "postinst configure", yes. [16:03] Ok, so I have to check what magic the headers do there... thanks [16:03] smb: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html [16:03] smb: See 6.6 for the ordering. [16:03] infinity, cool. ta [16:21] infinity, Hm... one starts to wonder why there is a hook for dkms in kernel/postinst.d at all... The one in header_postinst.d probably should be enough... [16:22] smb: Probably. Are you looking into the bug we were talking about the other day? [16:22] infinity, yeah (with other day being last week) [16:23] smb: I still think the fix I suggested should be made anyway. [16:23] infinity, So I looked today at the term.log of an upgrade that produced false positives. And saw that basically those fails all came from kernel postinst runs [16:23] smb: But you may be right that the hook doesn't need to live in both places. [16:24] The problem is that the headers are unpacked at that stage, so the checks for existing directories fail to detect anything wrong [16:26] The check we miss by exec is actually done in the dkms script again... so any echo is a duplicate. The only advantage would be that then the exit would be the rc code from the echo... [16:27] but then the only sucessful run is the one in the headers_postinst... so *shrug* [16:39] smb: Yeah, perhaps just removing the kernel image one is enough, then. [16:39] infinity, yep, typing a patch as we type..err speak [16:40] infinity, btw, we are past the "magic" time [16:42] smb: \o/ [16:42] smb: Time to find my decapulator. [17:02] infinity: Alright, thanks. [17:44] does the standard kernel support Flash file systems? https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems [17:44] i want to run lubuntu in microSD card without wearing it out [17:55] which flash FS is good? === hugbot is now known as swordmsnaz === swordmsnaz is now known as swordsmanz === FreezingAlt is now known as FreezingCold [20:33] zequence: http://launchpad.net/bugs/1431501 is your new bug, FWIW. [20:33] Ubuntu bug 1431501 in Kernel SRU Workflow "linux-lowlatency: -proposed tracker" [Medium,In progress]