one | What keys does the in kernel keys hold ssl keys or something else? | 05:36 |
---|---|---|
one | Why is pappy shut down? | 05:36 |
* apw yawns | 07:39 | |
one | Hi apw | 07:55 |
one | [D | 08:33 |
one | ;5C | 08:38 |
=== fmasi is now known as fmasi_lunch | ||
ppisati | ogra_: any reason why "link_in_boot = yes" in /etc/kernel-img.conf for ARM? | 10:19 |
ppisati | infinity: ^ | 10:19 |
ogra_ | define "for ARM" :P | 10:20 |
ogra_ | i think we disabled it on the arches that didnt support it | 10:20 |
ppisati | ogra_: arm boards and servers (i checked on calxeda) have that variable set that way | 10:20 |
apw | 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 |
ogra_ | 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:21 |
ogra_ | 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 |
ogra_ | (but we never defaulted to such nonsense) | 10:22 |
ogra_ | apw, i thought the kernel postinst does it ... | 10:23 |
apw | ogra_, it does, but doesn't appear to put the specific values ppisati finds in his | 10:25 |
ogra_ | hwo did ppisati install than ? | 10:26 |
ogra_ | *then | 10:26 |
ppisati | ogra_: i check an ubuntu-core+manual kernel installaion, an old panda installation and a calxeda server | 10:26 |
apw | ppisati, did you find the file in ubuntu-core without the kernel? | 10:27 |
apw | if not then it clearly must be us | 10:27 |
ogra_ | well, whatever creates it needs to be depending on the fact if someone was crazy enough to mount a vfat under /boot ... | 10:27 |
ogra_ | though the link wont break anyway ... simply because it breaks long before it can create it ... when unpacking the kernel package | 10:28 |
ppisati | ogra_: nope, ubuntu-core doesn't have it | 10:28 |
ogra_ | 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 |
ppisati | right | 10:28 |
ppisati | i'm playing around with the new uboot | 10:29 |
ppisati | and they have two nice fatures: | 10:29 |
ppisati | *features | 10:29 |
ppisati | 1) they can read file from ext4 and can boot from regular zImage | 10:29 |
ppisati | 2) a function that, given a couple of env cars, can detect which dtb this boards needs | 10:30 |
ppisati | so, actually 3 features | 10:30 |
ppisati | :) | 10:30 |
ogra_ | nice | 10:30 |
ppisati | anyway | 10:30 |
ppisati | i was able to put together a uEnv.txt that can exploit all those three | 10:30 |
ppisati | and if we can make a symlink (that's where that variable came into play...) to the dtbs directory | 10:31 |
ppisati | like: | 10:31 |
ppisati | /lib/firmware/$kernel-version/device-tree/blabla -> /dtbs | 10:31 |
ppisati | we can: | 10:31 |
ppisati | 1) drop flash-kernel as a dependency when installing kernel (since we load the zImage directly) | 10:32 |
ppisati | 2) always load the correct and most up to date dtb for the specific board | 10:32 |
ppisati | e.g.: | 10:32 |
ogra_ | right | 10:32 |
ogra_ | but only for platforms that fully support the new uboot | 10:32 |
ppisati | ogra_: yep, talking about arm boards here | 10:33 |
ppisati | paste.ubuntu.com/7462048/ | 10:33 |
ogra_ | 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 |
ppisati | here is the uEnv | 10:33 |
ppisati | dedicated flash partition? | 10:34 |
ogra_ | ppisati, well, there are still plenty arm boards that need/use mtd devices for their booting etc | 10:34 |
ppisati | all the boards i have: panda, beagle, beaglebone, exynos5, imx6, etc | 10:34 |
ogra_ | for these you will still need to use flash-kernel | 10:34 |
ppisati | we don't support them | 10:34 |
ppisati | so it's not a problem | 10:34 |
ppisati | even the exynos i received boot from sd | 10:35 |
ppisati | first partition u-boot, etcetc | 10:35 |
ppisati | anyway, my main point is that the board can choose which dtb to load | 10:35 |
ppisati | using the findfdt() function that it has | 10:35 |
ppisati | so i was trying to add a symlink (the /dtbs above) | 10:36 |
ppisati | and that's when i notced that x86 do all the symlinks in / | 10:36 |
ppisati | while arm does it in /boot | 10:36 |
ogra_ | right | 10:37 |
apw | is it because /boot is separate ? is /boot separate ? | 10:46 |
ppisati | apw: /boot has never been separated, they probably added that option to hanlde that case, but we never separated /boot | 10:47 |
apw | not that then | 10:48 |
ogra_ | but if you use d-i you are allowed to | 10:48 |
=== fmasi_lunch is now known as fmasi | ||
rtg | apw, what dkms packages are missing for the transition to 3.15 ? Anything particularly important ? | 12:09 |
apw | rtg, i think we are still waiting on actual testing of the two graphics ones, ie do they do anything | 12:12 |
apw | rtg, otherwise i think the package set was there, but let me double check the testing results | 12:12 |
apw | tseliot, did you get a chance to modprobe the graphics stacks yet ? | 12:13 |
rtg | apw, ok, I think I can test nvidia at least, perhaps fglrx as well | 12:13 |
apw | rtg, ack | 12:13 |
rtg | apw, if those drivers basically work, then it feels like its time to introduce 3.15 | 12:16 |
apw | rtg, yeah i know what you mean, i assume we'll fork 3.16 onto unstable when it comes | 12:51 |
rtg | apw, or just drag our feet about uploading much like we've done with 3.15 | 12:52 |
apw | or that | 12:55 |
tseliot | apw: no, I haven't tested those drivers yet | 13:14 |
bjf | jsalisbury, can you see if the person that wrote comment #19 on bug 1305522 is willing to bisect? | 13:55 |
jsalisbury | bjf, sure | 13:56 |
bjf | jsalisbury, thanks | 13:56 |
=== JanC is now known as Guest12750 | ||
=== JanC_ is now known as JanC | ||
tjaalton | 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:21 |
apw | tjaalton, -26.48foo1 should work just fine, i use similar shapes often | 15:31 |
apw | tjaalton, what was the failure | 15:31 |
smagoun | 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:36 |
tjaalton | 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:38 |
tjaalton | make: *** [module-check-generic] Error 1 | 15:39 |
apw | tjaalton, so did you add a new version on the top of the changelog ? | 15:40 |
apw | if so you need to update the ABI files in those directories, or what most of us do | 15:40 |
apw | is to just change the version of the latest entry rather than making a new one | 15:40 |
tjaalton | d/r clean isn't enough? | 15:42 |
tjaalton | I added a new entry after 3.13.0-26.48 yes | 15:43 |
rtg | tseliot, apw: no joy with nvidia-304 and 3.15 kernel | 15:50 |
rtg | does not compile | 15:50 |
tseliot | rtg: ok, I'll have a look at it | 15:51 |
apw | tjaalton, so best to just change the version of the last one, and then go for it | 16:17 |
jsalisbury | 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:42 |
infinity | 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 |
infinity | 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:50 |
jsalisbury | 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? | 16:52 |
=== fmasi is now known as fmasi_afk | ||
lesshaste | 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:21 |
lesshaste | in the grub options | 19:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!