| ohsix | 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:10 |
|---|---|---|
| ohsix | 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:12 |
| ohsix | 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:13 |
| ohsix | 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:14 |
| ohsix | i like the term vortex rather than some allusion to a force that can't exist, btw | 00:15 |
| ohsix | 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 | 00:15 |
| mozmck | 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:37 |
| mozmck | 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. | 01:39 |
| === gerald is now known as Guest95868 | ||
| === Elimin8r is now known as Elimin8er | ||
| === inaddy is now known as tinoco | ||
| === cking_ is now known as cking | ||
| taihsiang | henrix, the kernel version looks weird if I enable -proposed to try to run few SRU test | 09:46 |
| taihsiang | henrix, for example: | 09:46 |
| taihsiang | henrix, 3.13.0-46-generic #79~precise1-Ubuntu SMP Tue Mar 10 20:25:33 UTC 2015 | 09:46 |
| taihsiang | henrix, 3.13.0-47-generic #78~precise1-Ubuntu SMP Thu Mar 5 15:38:11 UTC 2015 | 09:47 |
| taihsiang | henrix, 3.13.0-47 is not there anymore, and 3.13.0-46 has newer built stamp | 09:47 |
| taihsiang | henrix, this issue block me to perform certification part of SRU | 09:48 |
| henrix | taihsiang: correct, that's because 3.13.0-46.79 was a security fix kernel. we had to respin early this week | 09:49 |
| henrix | taihsiang: this should be fix soon, i'm currently working on respinning the kernels again | 09:49 |
| henrix | taihsiang: the -47.78 kernel had to be dropped from -proposed and replaced by the security fix kernel | 09:50 |
| taihsiang | henrix, ok, that sounds great. one more question: so only precise(lts-trusty-backport) and trusty has such security fix and respinning? | 09:51 |
| henrix | taihsiang: no, *all* the kernels have that fix | 09:51 |
| taihsiang | henrix, e.g. how about precise(3.2) and utopic? | 09:51 |
| taihsiang | henrix, oops, understood, thanks! | 09:51 |
| henrix | taihsiang: np | 09:51 |
| taihsiang | 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:04 |
| taihsiang | 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:05 |
| henrix | 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:07 |
| taihsiang | henrix, I see, thanks. | 10:08 |
| === clopez_ is now known as clopez | ||
| infinity | zequence: There's a new precise kernel spinning up shortly, FWIW. | 13:57 |
| infinity | zequence: You'll have a bug number later tonight, I suspect. | 13:57 |
| ricotz | sforshee, hi :), is there an eta for trusty-backport of 3.16.0-33.44? | 15:30 |
| henrix | 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:43 |
| cking | amitk, is a new tag'd version of idlestat coming out soon? | 15:53 |
| ricotz | henrix, ok, thanks | 15:56 |
| amitk | 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 |
| amitk | cking: we've already added several new features | 15:57 |
| cking | even it it's a 0.5.1 or something, it looks kinda useful with the new features and man page | 15:57 |
| cking | *if it's | 15:58 |
| amitk | cking: ack, let me do some more testing over the weekend and I'll tag it next week | 15:58 |
| cking | that's great, no rush | 15:59 |
| smb | 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:01 |
| infinity | smb: configure is "postinst configure", yes. | 16:02 |
| smb | Ok, so I have to check what magic the headers do there... thanks | 16:03 |
| infinity | smb: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html | 16:03 |
| infinity | smb: See 6.6 for the ordering. | 16:03 |
| smb | infinity, cool. ta | 16:03 |
| smb | 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:21 |
| infinity | smb: Probably. Are you looking into the bug we were talking about the other day? | 16:22 |
| smb | infinity, yeah (with other day being last week) | 16:22 |
| infinity | smb: I still think the fix I suggested should be made anyway. | 16:23 |
| smb | 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 |
| infinity | smb: But you may be right that the hook doesn't need to live in both places. | 16:23 |
| smb | The problem is that the headers are unpacked at that stage, so the checks for existing directories fail to detect anything wrong | 16:24 |
| smb | 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:26 |
| smb | but then the only sucessful run is the one in the headers_postinst... so *shrug* | 16:27 |
| infinity | smb: Yeah, perhaps just removing the kernel image one is enough, then. | 16:39 |
| smb | infinity, yep, typing a patch as we type..err speak | 16:39 |
| smb | infinity, btw, we are past the "magic" time | 16:40 |
| infinity | smb: \o/ | 16:42 |
| infinity | smb: Time to find my decapulator. | 16:42 |
| zequence | infinity: Alright, thanks. | 17:02 |
| absk007 | does the standard kernel support Flash file systems? https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems | 17:44 |
| absk007 | i want to run lubuntu in microSD card without wearing it out | 17:44 |
| absk007 | which flash FS is good? | 17:55 |
| === hugbot is now known as swordmsnaz | ||
| === swordmsnaz is now known as swordsmanz | ||
| === FreezingAlt is now known as FreezingCold | ||
| infinity | zequence: http://launchpad.net/bugs/1431501 is your new bug, FWIW. | 20:33 |
| ubot5 | Ubuntu bug 1431501 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] | 20:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!