[05:36] What keys does the in kernel keys hold ssl keys or something else? [05:36] Why is pappy shut down? [07:39] * apw yawns [07:55] Hi apw [08:33] [D [08:38] ;5C === fmasi is now known as fmasi_lunch [10:19] ogra_: any reason why "link_in_boot = yes" in /etc/kernel-img.conf for ARM? [10:19] infinity: ^ [10:20] define "for ARM" :P [10:20] i think we disabled it on the arches that didnt support it [10:20] ogra_: arm boards and servers (i checked on calxeda) have that variable set that way [10:21] ogra_, does our installer/image side for ARM pre-create /etc/kernel-img.conf at all do you remember, i have a feeling it might [10:21] well, depends how you set them up ... on pandas we always treated the uboot partition separately so it doesnt matter if there is a link in /boot or not ... on ac100 it was the same ... the fastboot partition was not mountable [10:22] if you actually want to mount a vfat under /boot instead of handling that bit via flash-kernel separately you need to modify that [10:22] (but we never defaulted to such nonsense) [10:23] apw, i thought the kernel postinst does it ... [10:25] ogra_, it does, but doesn't appear to put the specific values ppisati finds in his [10:26] hwo did ppisati install than ? [10:26] *then [10:26] ogra_: i check an ubuntu-core+manual kernel installaion, an old panda installation and a calxeda server [10:27] ppisati, did you find the file in ubuntu-core without the kernel? [10:27] if not then it clearly must be us [10:27] well, whatever creates it needs to be depending on the fact if someone was crazy enough to mount a vfat under /boot ... [10:28] though the link wont break anyway ... simply because it breaks long before it can create it ... when unpacking the kernel package [10:28] ogra_: nope, ubuntu-core doesn't have it [10:28] if flash-kernel is involved the setting is moot anyway btw ... it uses the full version string and wont use a link (unless that changed recently) [10:28] right [10:29] i'm playing around with the new uboot [10:29] and they have two nice fatures: [10:29] *features [10:29] 1) they can read file from ext4 and can boot from regular zImage [10:30] 2) a function that, given a couple of env cars, can detect which dtb this boards needs [10:30] so, actually 3 features [10:30] :) [10:30] nice [10:30] anyway [10:30] i was able to put together a uEnv.txt that can exploit all those three [10:31] and if we can make a symlink (that's where that variable came into play...) to the dtbs directory [10:31] like: [10:31] /lib/firmware/$kernel-version/device-tree/blabla -> /dtbs [10:31] we can: [10:32] 1) drop flash-kernel as a dependency when installing kernel (since we load the zImage directly) [10:32] 2) always load the correct and most up to date dtb for the specific board [10:32] e.g.: [10:32] right [10:32] but only for platforms that fully support the new uboot [10:33] ogra_: yep, talking about arm boards here [10:33] paste.ubuntu.com/7462048/ [10:33] and for platforms that dont use a dedicated flash partition (that would finally make flash-kernel again what you expect from its name :) ) [10:33] here is the uEnv [10:34] dedicated flash partition? [10:34] ppisati, well, there are still plenty arm boards that need/use mtd devices for their booting etc [10:34] all the boards i have: panda, beagle, beaglebone, exynos5, imx6, etc [10:34] for these you will still need to use flash-kernel [10:34] we don't support them [10:34] so it's not a problem [10:35] even the exynos i received boot from sd [10:35] first partition u-boot, etcetc [10:35] anyway, my main point is that the board can choose which dtb to load [10:35] using the findfdt() function that it has [10:36] so i was trying to add a symlink (the /dtbs above) [10:36] and that's when i notced that x86 do all the symlinks in / [10:36] while arm does it in /boot [10:37] right [10:46] is it because /boot is separate ? is /boot separate ? [10:47] apw: /boot has never been separated, they probably added that option to hanlde that case, but we never separated /boot [10:48] not that then [10:48] but if you use d-i you are allowed to === fmasi_lunch is now known as fmasi [12:09] apw, what dkms packages are missing for the transition to 3.15 ? Anything particularly important ? [12:12] rtg, i think we are still waiting on actual testing of the two graphics ones, ie do they do anything [12:12] rtg, otherwise i think the package set was there, but let me double check the testing results [12:13] tseliot, did you get a chance to modprobe the graphics stacks yet ? [12:13] apw, ok, I think I can test nvidia at least, perhaps fglrx as well [12:13] rtg, ack [12:16] apw, if those drivers basically work, then it feels like its time to introduce 3.15 [12:51] rtg, yeah i know what you mean, i assume we'll fork 3.16 onto unstable when it comes [12:52] apw, or just drag our feet about uploading much like we've done with 3.15 [12:55] or that [13:14] apw: no, I haven't tested those drivers yet [13:55] jsalisbury, can you see if the person that wrote comment #19 on bug 1305522 is willing to bisect? [13:56] bjf, sure [13:56] jsalisbury, thanks === JanC is now known as Guest12750 === JanC_ is now known as JanC [15:21] so I need to provide a test kernel for an oem image build, but what version number to use that is newer than the next kernel and such that it builds? tested -26.48foo1 and it failed, now testing -26.48.1 but will it fail too? [15:31] tjaalton, -26.48foo1 should work just fine, i use similar shapes often [15:31] tjaalton, what was the failure [15:36] bjf: Hi, I verified bug 1305133 - the fix does what's expected but it's not really complete. There is another related patch upstream but not in our kernel. Rather than fail verification of 1305133, I filed bug 1319457 as a follow-up. 1319457 has a link to the upstream patch we need [15:38] apw: II: Checking modules for generic...previous or current modules file missing! /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-26.48tja1/amd64/generic.modules /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-26.48/amd64/generic.modules [15:39] make: *** [module-check-generic] Error 1 [15:40] tjaalton, so did you add a new version on the top of the changelog ? [15:40] if so you need to update the ABI files in those directories, or what most of us do [15:40] is to just change the version of the latest entry rather than making a new one [15:42] d/r clean isn't enough? [15:43] I added a new entry after 3.13.0-26.48 yes [15:50] tseliot, apw: no joy with nvidia-304 and 3.15 kernel [15:50] does not compile [15:51] rtg: ok, I'll have a look at it [16:17] tjaalton, so best to just change the version of the last one, and then go for it [16:42] bjf, Looks like we have an answer for bug 1305522 in comment #29. It appears the two HID: rmi: SAUCE patches are what caused the touchscreen to regress. Reverting them allows the touchscreen to work again. [16:50] ppisati / apw: link_in_boot = yes is the "right" setting for pretty much everyone who doesn't use lilo, IMO. So, anyone !x86 !ia64, or x86 from the last decade. [16:50] ppisati / apw: The fact that it's probably still the inverse on default x86 installations doesn't mean ARM is wrong (why does anyone care, BTW?) [16:52] rtg, if you have a chance, can you take a look at bug 1319471 ? I'm not sure if I should ping the HWE folks about this? === fmasi is now known as fmasi_afk [19:21] hi.. how can you boot into single user mode in 14.04? It seems "sudo telinit 1" doesn't work and nor does adding "single" to "ro quiet splash $vt_handoff [19:22] in the grub options