**** BEGIN LOGGING AT Mon Dec 12 02:59:56 2011 Dec 12 12:28:46 hi all. Is there fix or workaround of this bug? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/901847 Dec 12 12:28:48 Launchpad bug 901847 in ubiquity "armhf+omap4 desktop installer dies in plugininstall.py" [High,Confirmed] Dec 12 12:30:09 not yet, no Dec 12 12:30:23 thx for answer Dec 12 12:33:14 janimo, ping on bug 861296, linux-ac100 Dec 12 12:33:16 Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296 Dec 12 12:42:33 bah, someone was faster on giving back gst-plugins-good Dec 12 12:42:40 * ogra_ bets infinity ... Dec 12 12:42:42 Gave back gst-plugins-good0.10/armel (and /powerpc) against latest libavc1394 to pick up multiarch .la file change Dec 12 12:42:48 ogra_: I was :-0 Dec 12 12:42:51 haha Dec 12 12:43:15 it took me a bit long to figure out that the .la file had been fixed already Dec 12 14:31:59 doko, yes? Regarding the mmap bug? Dec 12 14:46:45 janimo, yes, apply to linux-ac100 Dec 12 14:48:40 doko, will for precise, I am not sure it's worth the hassle for oneiric Dec 12 14:48:57 only for consistency maybe Dec 12 14:50:23 janimo: please do it for consistency then. Dec 12 14:52:01 janimo, while youre at it you could also do the config change :) Dec 12 14:52:13 so that the internal mic works Dec 12 15:08:52 ogra_, which change is that? I was not aware we're only one config toggle away from mic working Dec 12 15:09:10 just that one :) Dec 12 15:10:01 (usb sound stuff) Dec 12 16:42:39 lool, poke Dec 12 16:43:14 lool, david pointed me to you, we seem to have some weird armhf behavior in bug 901847 Dec 12 16:43:16 Launchpad bug 901847 in ubiquity "armhf+omap4 desktop installer dies in plugininstall.py" [High,Confirmed] https://launchpad.net/bugs/901847 Dec 12 16:43:30 seems users cant execute shells in hf installs Dec 12 16:44:58 ogra_: Do you have such an environment? Dec 12 16:45:07 I would suspect it could be due to the runtime linker Dec 12 16:45:19 i only have the chroot i mentioned... where it apparently works ... Dec 12 16:45:29 but xranby has an install on his ac100 Dec 12 16:45:34 xranby: Oy Dec 12 16:45:48 (the bug manifests the same way on all hf images it seems) Dec 12 16:50:43 other chroot calls work, so probably something with sudo / pam Dec 12 16:51:00 I wonder whether this is relevant: Dec 8 19:55:41 localhost ubiquity: dpkg-trigger: error: must be called from a maintainer script (or with a --by-package option) Dec 12 16:51:09 lool: No, that's a red herring. Dec 12 16:51:29 I wonder if this relates to the procps "when I upgrade, my system explodes" madness somehow. Dec 12 16:51:58 Cause users can definitely execute shells on armhf. If they couldn't, our buildds wouldn't work. Dec 12 16:52:02 but thats not a chroot ... (the breakage i mean) Dec 12 16:52:16 ogra_: What do chroots have to do with anything? Dec 12 16:52:25 well, in chroots it works ... Dec 12 16:52:45 i can chroot/sudo into a user shell Dec 12 16:52:59 while the same thing doesnt work on a bare install Dec 12 16:53:09 To add to that, I have a semi-working netinstall (prior to the libc6 udeb issue) that will only log me in if I have init=/bin/sh. Dec 12 16:53:10 root can run any shell on that same install though Dec 12 16:53:42 ogra_: Sure, but I still suspect it's the same issue. Dec 12 16:53:48 hmm Dec 12 16:54:09 I can't log in to the same image with a normal init, even with ssh. Gets most of the way in, but chokes on giving me a shell prompt. Dec 12 16:54:32 Boom, killed. Dec 12 16:54:32 try systemd instead :P Dec 12 16:54:34 Just like that. Dec 12 16:54:41 ogra_: /etc/init.d/procps start Dec 12 16:54:57 ogra_: Do that in a chroot with proc mounted, watch system explode for all !root users. Dec 12 16:55:05 ogra_: Now, realise that any installed system does that on boot. Dec 12 16:55:18 GrueMaster: Remove procps's init script and see if it boots. Dec 12 16:55:36 infinity, hmm, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631807 ?? Dec 12 16:55:37 Debian bug 631807 in libcap-ng0 "segfault in libcap-ng0 is back on armel - filecap , bluetoothd etc" [Important,Open] Dec 12 16:55:46 ok. Will try (if the system is still imaged). Dec 12 16:56:19 i wonder if that could reach into our issue Dec 12 16:56:48 Maybe. Dec 12 16:56:52 But I don't see a SEGV here. Dec 12 16:57:03 yeah Dec 12 16:58:35 GrueMaster: (note that it's actually an upstart job, so /etc/init/procps.conf is what needs to go) Dec 12 16:58:47 I know. Dec 12 16:58:59 So, something in "cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -" is killing us. Dec 12 16:59:10 Just need to iterate through reboots until I find the culprit. Dec 12 16:59:23 does it die if you run it manually ? Dec 12 16:59:43 I can reboot and see. Dec 12 17:00:38 bah. System was reimaged to precise armel. I don't have that install to test (and netinst is borked due to libc6-udeb). Dec 12 17:00:48 Will muck with a server image. Dec 12 17:01:12 Server dies in the installer with the same issue. Dec 12 17:02:54 ogra_: Yeah, doing it manually produces the same result. Which is comforting. It's not upstart's fault. Dec 12 17:03:01 ogra_: Just one of these settings is broken. Dec 12 17:03:39 yay Dec 12 17:03:50 * infinity is inclined to blame one of: Dec 12 17:03:50 kernel.yama.ptrace_scope = 1 Dec 12 17:03:50 vm.mmap_min_addr = 65536 Dec 12 17:03:59 and since its on panda as well, it cant be my tewaks in the ac100 Dec 12 17:04:04 Another reboot and testing. Dec 12 17:04:27 hmm, the min addr thing was required for something on armel Dec 12 17:04:34 * ogra_ forgot what though Dec 12 17:04:47 Wait, does the file installed on armel differ? Dec 12 17:05:10 no Dec 12 17:05:14 same file Dec 12 17:05:20 but apparently different behavior Dec 12 17:05:21 No, it's a different value. Dec 12 17:05:28 At least, it is here... Dec 12 17:05:29 cant Dec 12 17:05:41 Why can't it be? :P Dec 12 17:06:07 the bit putting it there is the same on both Dec 12 17:06:22 cat attack, cant type atm ... Dec 12 17:07:01 Well, the default is: Dec 12 17:07:02 vm.mmap_min_addr = 65536 Dec 12 17:07:08 My quickstart has: Dec 12 17:07:09 right Dec 12 17:07:12 # ARM-specific default: Dec 12 17:07:13 vm.mmap_min_addr = 32768 Dec 12 17:07:17 ugh Dec 12 17:07:28 how does that get there Dec 12 17:07:48 jasper puts it in place on non ac100 Dec 12 17:07:58 Eh? Dec 12 17:08:06 It does no such thing. Dec 12 17:08:10 and ac100-tarball-installer in ac100 Dec 12 17:08:23 adconrad@cthulhu:~/pps/jasper-initramfs-0.66$ rgrep zeropage * Dec 12 17:08:23 adconrad@cthulhu:~/pps/jasper-initramfs-0.66$ Dec 12 17:08:27 You may be mistaken. Dec 12 17:08:28 jasper_setup should Dec 12 17:08:30 Interesting on the mmap_min_addr thing. On omap kernel, that is the correct value, but on omap4 it is 32768 Dec 12 17:09:05 Makes kernel SRU testing fail btw. Dec 12 17:10:41 For the record, this fixes it: Dec 12 17:10:42 sed -i -e 's/65536/32768/' /etc/sysctl.d/10-zeropage.conf Dec 12 17:10:50 So, we should probably just ship the right value in procps. Dec 12 17:10:58 yep Dec 12 17:11:05 Cause editing conffiles from other packages is wrong, wrong, wrong. Dec 12 17:11:27 jasper never did that Dec 12 17:11:34 But what did? Dec 12 17:11:35 its a .d dir Dec 12 17:11:42 Something gave me the right value on my QS. Dec 12 17:11:46 And even with a comment! Dec 12 17:11:52 jasper puts an override file in place Dec 12 17:11:57 ogra_: Yes, but this is the same file. Dec 12 17:12:05 ogra_: Same filename as the one in procps. Dec 12 17:12:08 strange Dec 12 17:12:27 Anyhow, now that I've found the issue, will fix after my call. Dec 12 17:12:35 awesome Dec 12 17:22:37 infinity, oh, i was wrong anyway wrt jasper ... vm.min_free_kbytes = 8192 is what we set there (for an USB NIC issue) Dec 12 17:23:00 workaround for bug 746137 Dec 12 17:23:01 Launchpad bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released] https://launchpad.net/bugs/746137 Dec 12 17:23:40 see sysctl/30-jasper-smsc-min-free-kbytes.conf Dec 12 17:23:45 in the jasper tree Dec 12 17:32:45 # If a non-arch-specific default exists, install the arch-specific Dec 12 17:32:45 # version of the conf in place of it, otherwise, build up a general Dec 12 17:32:45 # 10-arch-specific.conf file. Dec 12 17:32:45 for archconf in debian/sysctl.d/*.conf.$(DEB_HOST_ARCH); do \ Dec 12 17:33:04 infinity, ... nothing modifies it, procps itself puts a different file in place for armel Dec 12 17:33:31 (thats from debian/rules ... i think we just need to drop the armel file from the source) Dec 12 17:34:35 err, other way round, cp the armel file to an armhf file Dec 12 17:35:00 * ogra_ does that Dec 12 17:39:20 uploaded Dec 12 17:39:39 ogra_: \o/ Dec 12 17:42:55 Was this the sudo chroot issue? Dec 12 17:43:08 lool, right Dec 12 17:43:23 vm.mmap_min_addr being set to a too high value Dec 12 17:44:06 since the original fix was bound to the armel arch naming Dec 12 17:45:42 Ok; I'll stop the install I was running -- it's really painful to work with full images instead of a small armhf chroot! Dec 12 17:46:02 just use ubuntu-core if you need a minimal one :) Dec 12 17:46:43 (just take an existing install and replace the rootfs with ubuntu-core and add a root pw) Dec 12 18:14:49 ogra_: I do wonder how many other armel-specific hacks we might be missing for armhf. :/ Dec 12 18:15:12 well, iirc there were a few made by the security team like this one Dec 12 18:15:28 but they were rather kernel defaults so we should be good here Dec 12 18:15:59 i guess we'll run into them over time Dec 12 18:16:30 the bad thing is that i really cant remember all of them anymore ... i only remembered the procps thing that kees did when i actually looked at the code Dec 12 18:16:46 the bad part here is that it wasnt even mentioned in the changelog or anything Dec 12 18:47:00 infinity, hmm, i was hoping the janitor just had a hiccup Dec 12 18:47:16 (thats why i didnt manually close yet) Dec 12 18:47:40 ogra_: I didn't check timing, but I assume you uploaded before you added the procps task. Dec 12 18:48:01 yeah, in the hope it just closes by bug number :P Dec 12 18:48:08 Yeah, it won't. ;) Dec 12 18:48:14 which it apparently doesnt anymore Dec 12 18:48:21 A procps upload can only close a bug in procps. Dec 12 18:48:39 well, it used to not care for the package in the past Dec 12 18:48:44 (Which I think is a silly limitation that creates busywork, but whatever) Dec 12 18:48:50 right Dec 12 18:50:49 We should still make sure the kernels have the correct CONFIG_LSM_MMAP_MIN_ADDR setting. Currently, they are different on omap vs omap4. Dec 12 18:51:26 GrueMaster: Except that, on boot, they all get set to the procps-provided one anyway. Dec 12 18:51:28 doesnt matter since procps overrides them (on all arches) anyway Dec 12 18:51:33 (But yes, the kernel defaults should match) Dec 12 18:51:35 *snap* Dec 12 18:51:40 agreed Dec 12 18:51:50 GrueMaster: Which one's wrong? Dec 12 18:51:54 and there are plenty of packages that modify them as well Dec 12 18:52:01 Oh, I'm betting omap, because it probably matches the x86 kernels. Dec 12 18:52:02 Right? Dec 12 18:52:05 via sysctl.d files Dec 12 18:52:07 Well, the QRT scripts look at the kernel config settings. Dec 12 18:52:20 which is completely wrong in this case Dec 12 18:52:24 Not sure, but I would assume the omap4, since it is out-of-main. Dec 12 18:53:13 What should be correct, 32768 or 65536? Dec 12 18:53:19 32768 Dec 12 18:53:37 Ok, them omap is wrong. At least in the kernel config. Dec 12 18:53:41 fun Dec 12 18:53:43 Though, that's questionable. I wish I could track down WHY arm was set differently. Dec 12 18:53:52 ogra_: Any ideas there? Dec 12 18:54:01 i dont remember it anymore Dec 12 18:54:05 i was involved in it Dec 12 18:54:09 Awesome. Dec 12 18:54:12 we should ask kees Dec 12 18:54:25 he probably remembers it better than me Dec 12 18:54:27 He didn't know. Dec 12 18:54:31 it dates back to jaunty Dec 12 18:54:33 GrueMaster: For now, then, making omap match the rest sounds "correct", until we can sort out why not. Dec 12 18:54:37 I worked with him all day Friday on these scripts. Dec 12 18:55:56 iirc it blocks a security feature of the kernel on arm if it is set to high Dec 12 18:56:23 null pointer dereference or some such Dec 12 18:57:00 That's what it's for in the first place (preventing null dereferencing) Dec 12 18:57:11 hola Dec 12 18:57:14 But I'm willing to believe it's weird on ARM. We should just get the omap default fixed. Dec 12 18:57:20 Well, none of the scripts are broken now. I worked with him Friday, and we have everything running on all arm HW. Dec 12 18:57:20 kees: Yo. Dec 12 18:57:53 mmap_min_addr on arm needed to be 32k because, IIRC, qemu and some of the dynamic loaders put stuff below 64k. Dec 12 18:58:12 kees: Wouldn't that be true on all arches...? Dec 12 18:58:42 infinity: all arch flavors? yes, I assumed so. Dec 12 18:59:00 kees: No, I meant !arm... Curious why qemu would be different only there. Dec 12 18:59:01 I have no problem seeing it raised, btw. this was a requirement from ogra_ originally. Dec 12 18:59:08 yay Dec 12 18:59:14 it was the dynamic loader thing Dec 12 18:59:17 now i remember Dec 12 18:59:20 Raising it seems to make the system explode, so I suspect we were right. :P Dec 12 18:59:22 infinity: oh, I assume because memory layouts were different between archs Dec 12 18:59:34 I just wish the reasoning had been documented. Dec 12 18:59:46 infinity, qemu even explodes with values above 4k iirc Dec 12 19:00:02 and wine or dosemu have other values as well Dec 12 19:00:04 oh! that's right, qemu was 4k, hence a sysctl file on install. yeah Dec 12 19:00:17 * infinity nods. Dec 12 19:00:19 Alright. Dec 12 19:00:22 and there might be other packages i dont re,ember Dec 12 19:00:34 So, ARM's ld.so is weird or something. Having been in there, I can buy that. Dec 12 19:00:35 dosemu is fully emulated so it doesn't care about mmap_min_addr. wine in 32bit mode doesn't care either. wine in 16bit mode beens access to 0 addr. Dec 12 19:00:48 ah, right Dec 12 19:00:49 beens? needs. Dec 12 19:00:52 beens! Dec 12 19:00:57 heh Dec 12 19:01:02 what an odd typo Dec 12 19:01:19 kees: You're an odd fellow. Dec 12 19:01:24 kees: Sees to fit. Dec 12 19:01:28 infinity: fair point Dec 12 19:01:32 Seems, too. Dec 12 19:01:34 Fuck typing. Dec 12 19:01:41 infinity: where would you have expected the 32k thing to be documented, btw? Dec 12 19:01:45 * ogra_ wants a t-shirt with that Dec 12 19:01:58 kees: In the sysctl fragment that's different on ARM, perhaps? Dec 12 19:02:02 kees, iirc there was a bug for it Dec 12 19:02:09 but launchpad doesnt like to find it Dec 12 19:02:19 kees: Right now, it has a very unhelpful "# ARM-secific default:" comment. Dec 12 19:02:20 for the arm part at lest Dec 12 19:02:27 infinity: ah, yeah Dec 12 19:02:34 i find all the wine bugs though Dec 12 19:03:11 # ARM-specific default, due to the dynamic loader using regions below 64k: Dec 12 19:03:15 ^^ how about that? Dec 12 19:03:16 and i know we discussed it at lenght back then Dec 12 19:03:25 so there *must* be irc logs Dec 12 19:03:33 but i cant find them either Dec 12 19:03:36 kees: If that's the truth, then yes, sounds lovely. ;) Dec 12 19:04:04 kees: If by "the dynamic loader", you mean "ld.so", being specific doesn't hurt. Dec 12 19:04:19 ogra_: how should that comment read? was there a bug for it? Dec 12 19:05:11 I just did a google for arm sysctl mmap_min_addr site:launchpad.net and all the results point to qemu. Dec 12 19:05:16 Karmic timeframe. Dec 12 19:05:18 kees, i *think* we had a bug ... but seriously, that was jaunty or karmic my mind doesnt date back that far Dec 12 19:05:24 yeah, me either Dec 12 19:05:48 i remember discussing the qemu part with you in dublin Dec 12 19:06:02 yeah, that was a whole different issue. that was the 4k part, not the 32k Dec 12 19:06:08 but at that time the procps side was already in place Dec 12 19:06:16 and we did that one online Dec 12 19:06:38 its weird that google doesnt find a single irc log Dec 12 19:07:06 http://irclogs.ubuntu.com/2009/03/18/%23ubuntu-kernel.txt Dec 12 19:07:09 ha ! Dec 12 19:07:54 doesnt have the explanatiojn though :( Dec 12 19:07:58 only the discussion Dec 12 19:08:19 yeah Dec 12 19:08:26 [17:38] the help of SECURITY_DEFAULT_MMAP_MIN_ADDR says "On arm and other archs it should not be higher than 32768." Dec 12 19:08:33 thats the reason :) Dec 12 19:08:46 we did it because i read docs :P Dec 12 19:09:19 [17:29] according to the Kconfig help text, anyway Dec 12 19:09:20 [17:29] ia64, ppc64, x86: 65536, all others: 32768 Dec 12 19:09:26 yep Dec 12 19:09:57 Alright, well. Fixed now. I have eglibc things to do. Dec 12 19:09:59 So we need to fix omap. Good to know. Dec 12 19:10:18 GrueMaster: Want to file a bug? Dec 12 19:10:44 yep. I like filing kernel bugs. Keeps them on their toes. Dec 12 19:10:50 Thankfully, init/procps probably starts early enough for it to be a non-issue, but... Dec 12 19:20:57 Other than kconfig saying we should set it this way, is there any other compelling reason? Dec 12 19:21:28 on ubuntu 11.10 touchscreen freezes after some time Dec 12 19:21:46 i use http://www.amazon.com/e2239Fwt-21-5-LED-Touchscreen-Monitor/dp/B0056J9JPC Dec 12 19:23:22 infinity, kees, ogra_: current qemu does not need any special handling of minimum memory addresses; we killed that sysctl file off a while ago Dec 12 19:23:40 slangasek: cool Dec 12 19:24:02 GrueMaster: Well, Kconfig seems to be right. ;) Dec 12 19:25:30 I'm just curious as to what it would affect. It has been 65536 on omap since we started using main (natty or oneiric - can't remember). Dec 12 19:25:52 GrueMaster: Except that it's reset on boot. Dec 12 19:25:58 GrueMaster: So, it's not actually that at all. Dec 12 19:26:14 GrueMaster: if it wasn't for the procps init job setting it to 32k, everything non-root would fail. Dec 12 19:26:24 GrueMaster: (As seen by the current armhf bug that Oli just fixed) Dec 12 19:26:46 Ah. Dec 12 19:26:48 ok. Dec 12 19:27:55 So this may impact booting w/o initrd possibly? Dec 12 19:28:29 Nah. Dec 12 19:28:30 * GrueMaster needs to see how far back this affects omap kernels. Dec 12 19:28:49 But it impacts anything that one might try to start from init as !root before the procps job runs. Dec 12 19:29:00 (Which, in practice, seems to be little or nothing, but still) Dec 12 19:29:11 A kernel default that doesn't allow non-root use seems suboptimal. ;) Dec 12 19:31:04 I'm just wondering if it needs attention for the next SRU run. Dec 12 19:31:54 It should probably be fixed in omap SRU kernels. Can't hurt to fix it. Dec 12 19:32:03 But it's not particularly critical, if things have been working. Dec 12 19:32:37 infinity: why does this affect !root? Does this imply qemu should in fact re-add the sysctl file, even though I haven't been able to find any failures with it gone? Dec 12 19:32:53 Ok, so I need to backtrack and see how far back it is affected. I'll put a med priority on it. Dec 12 19:34:06 slangasek: The setting only affects !root. Root can map whatever they want. Dec 12 19:34:19 yes, and when I run qemu, I run !root Dec 12 19:34:22 slangasek: In the ARM case, having the wrong setting (64k) breaks. Dec 12 19:34:38 slangasek: The qemu thing is entirely unrelated. Dec 12 19:34:41 ok Dec 12 19:42:06 any one used touchscreen on ubuntu 11.10? Dec 12 19:51:17 infinity: ogra_ Bug #903346 filed. Will list broken kernel releases that need to be addressed shortly. Dec 12 19:51:18 Launchpad bug 903346 in linux "On omap, CONFIG_DEFAULT_MMAP_MIN_ADDR needs to be set to 32768 per kconfig notes" [Medium,Confirmed] https://launchpad.net/bugs/903346 Dec 12 19:59:50 GrueMaster, awesome, great Dec 12 20:00:45 Confirmed also in Natty. Pulling maverick to see if it is affected as well. Dec 12 20:01:18 funny that omap still works though Dec 12 20:01:42 why are you able to exec anything if its 65k Dec 12 20:01:50 ogra_: Because procps resets it. Dec 12 20:01:53 * GrueMaster sheepishly admits to accidentally purging release images on desktop before checking internal mirror to verify backup). Dec 12 20:02:03 The sysctl is there to correct it. Dec 12 20:02:15 then we have been really really lucky with our initrd and upstart Dec 12 20:02:26 ogra_: The initrd runs entirely as root. Dec 12 20:02:32 oh, indeed Dec 12 20:02:37 ogra_: As do most/all upstart jobs before the procps script. Dec 12 20:02:40 and pid 0 as well Dec 12 20:02:58 you mentioned it before, now i understand what you meant :P Dec 12 20:03:20 * ogra_ didnt relate that comment to omap before Dec 12 20:03:48 Right. I need a short nap to recover from last night before I finish this eglibc merge. Dec 12 20:03:50 So this really only would affect users that take our code and do weird embedded work with it (or other things). Dec 12 20:04:02 I suspect it's best not to upload libc when I'm in this state. :P Dec 12 20:04:12 nobody doing embedded work would use our stff anyway Dec 12 20:04:28 infinity, go to bed Dec 12 20:04:37 * ogra_ goes back to TV Dec 12 20:05:19 * GrueMaster considers searching for lunch. Dec 12 20:05:29 GrueMaster: Or someone naively removing the config file, or disabling the procps init, or trying to run an init job as !root before procps's runs, or... Dec 12 20:05:53 GrueMaster: In the end, the procps bits and the kernel defaults should match, it's pretty unexpectedly strange when they don't, I'd say. Dec 12 20:06:02 if i *would* do embedded work with ubuntu i would do it as initrd hooks and abuse update-initramfs to build my rootfses though Dec 12 20:06:07 (Especially since the sysctl snippets claim to mirror the defaults) Dec 12 20:06:21 to keep it as tiny as possible Dec 12 20:07:09 and i bet others doing embedded stuf would do something similar ... anyway i would expect most stuff to run as root in embedded Dec 12 20:07:18 anyway, really TV now Dec 13 00:05:52 lilstevie: OK wifi problem solved -- I mis-transcribed the *MAC* address into the AP Dec 13 00:06:09 Problem was obvious when running hostapd by hand: wlan0: STA 74:2f:68:23:46:8d WPA: no PSK configured for the STA Dec 13 00:06:25 Sorry to trouble you with my fat fingers Dec 13 00:08:23 twb: Good to hear you got it solved. Dec 13 00:21:15 OK, so apparently to set the keyboard rate, you run something like "kbdrate -d 500 -r 5". Dec 13 00:21:57 I run that as root on tty1, and it says "set rate to 0, delay to 0. Was rate 0, delay 0" Dec 13 00:22:00 Grr! Dec 13 00:33:20 Is it supposed to fail to set CPU frequency Dec 13 00:46:49 lilstevie: /etc/fstab ends up with two / mount entries in it; UUIDs corresponding to p8 and p2; the latter is all but empty; I think it's wrong. Dec 13 00:48:09 lilstevie: uboot-mkimage is a stub and doesn't need to be installed. Dec 13 00:50:35 Likewise uboot-envtools Dec 13 00:58:08 twb: Yeah they are transitional packages I guess. Dec 13 01:05:22 Right Dec 13 01:08:30 Wow, modern ubuntu has a huge hard-on for dpkg triggers, huh. Dec 13 01:12:41 twb: Sometimes it makes sense, like with the kernels. much easier to apt-get install linux-omap4 than linux-image-2.6.35-903-omap4 for example. Also, the meta will always require the latest version of the main package, so easier to check updates. Dec 13 01:14:49 GrueMaster: it's not a metapackage, it's a transitional package. There are no rdeps installed. This suggests that lilstevie asked for it by the old name, and could profitably update his script to ask for the new name. **** ENDING LOGGING AT Tue Dec 13 01:20:13 2011 **** BEGIN LOGGING AT Tue Dec 13 01:22:14 2011 Dec 13 01:26:19 twb: huh Dec 13 01:26:34 I did not install uboot-mkimage or uboot-envtools Dec 13 01:26:49 they are probably reminants left over from the fact that it is the omap base image Dec 13 01:27:23 lilstevie: ah, that makes sense Dec 13 01:28:45 * twb is having fun ripping out all the useless GUI packages Dec 13 01:29:07 lilstevie: btw any idea what to do about the keyboard repeat rate? Dec 13 01:29:12 no idea Dec 13 01:29:16 bugger Dec 13 01:29:43 my keyboard repeat is fine in GUI userland, but non existant in ttys **** ENDING LOGGING AT Tue Dec 13 01:30:04 2011 **** BEGIN LOGGING AT Tue Dec 13 01:32:14 2011 **** ENDING LOGGING AT Tue Dec 13 02:59:57 2011