**** BEGIN LOGGING AT Sun Feb 07 02:59:58 2010 Feb 07 17:51:28 lool: I picked Recommends because I thought most people *should* builde for armel :) Did you manage to fix the issue with the conflicting binfmt-misc handlers? Feb 07 18:20:36 persia: I think so Feb 07 18:20:51 persia: The issue was one present before the rename, but becoming serious after the rename Feb 07 18:21:20 Aha. I'm just installing the latest version, and will confirm then :) Feb 07 18:21:21 persia: The handler was registered on postinst/configure and unregistered in prerm/remove instead of postinst/install prerm/remove or postinst/configure and prerm/upgrade Feb 07 18:21:50 (Hope I'm making sense) Feb 07 18:22:02 Right. That would explain all sorts of things :) Sometimes I wish maintainer scripts weren't quite so complex, because more people might get them right the first time :) Feb 07 18:22:59 Sadly, I can't retrofix the qemu-arm-static packages, but I've added qemu-arm-static.postinst and qemu-kvm-extras-static.postinst configure snippets to remove the old name Feb 07 18:23:25 I didn't really test an old qemu-arm-static -> new world full upgrade though; if you do that, I'd love to hear the results Feb 07 18:23:45 I can't easily test the full upgrade, but I may be able to figure out a way. Feb 07 18:23:56 I can test broken -> fixed. Feb 07 18:24:09 Would a karmic -> lucid upgrade do it for the full upgrade case? Feb 07 18:25:02 Yes Feb 07 18:25:25 Or simply, removing everything, manually installing an old lucid qemu-arm-static and upgrading Feb 07 18:26:29 That's fairly trivial to do then: I can just install the karmic qemu-arm-static in a lucid chroot and dist-upgrade. Feb 07 18:27:21 Separately, I was thinking: would it make sense to use build-cross-chroot rather than build-arm-chroot, and then try to encourage enabling other architectures? Feb 07 18:27:37 I hear qemu powerpc is getting there, although sparc and ia64 probably need some work. Feb 07 18:28:00 My thought was that it would be nifty if developers could work on most architectures for most purposes from an amd64 install. Feb 07 18:28:49 persia: Ack, I don't like "-arm-" in "build-arm-chroot" Feb 07 18:28:59 I think qemu-debootstrap would be a better name for it Feb 07 18:29:18 I'd be happy with that name. Feb 07 18:29:53 Note that it's not currently command-line compatible with debootstrap. Specifically, `debootstrap --arch armel` works, but `build-arm-chroot --arch armel` doesn't. Feb 07 18:30:11 Both also work with "--arch=armel", but that's a separate case :) Feb 07 18:30:37 I've just upgraded from a broken system, and I still get "sudo: must be setuid root". Feb 07 18:30:38 or qemu-debootstrap-helper, but I would call it qemu-debootstrap and fix it to be compatible Feb 07 18:30:50 persia: Oh sudo is unrelated Feb 07 18:30:51 If you would, that would be great. Feb 07 18:31:10 Um, sudo is the problem I had, which ogra convinced me was related to the binfmt issue. Feb 07 18:31:13 What's the sudo issue? Feb 07 18:31:30 If you try running sudo with binfmt, the kernel will run qemu-arm-static which doesn't have the SUID bit set Feb 07 18:31:36 It can't work Feb 07 18:32:06 persia: Check whether you have one and only one arm entry in /var/lib/binfmt* and /proc/sys/filesystems/binfmt*/ Feb 07 18:32:17 The entry should be qemu-arm Feb 07 18:32:35 /var/lib/binfmts/qemu-arm and /proc/sys/fs/binfmt_misc/qemu-arm Feb 07 18:33:40 I do only have one of those. Feb 07 18:34:42 You have both and these are named qemu-arm though? Feb 07 18:35:14 If you do, then your system is correctly configured Feb 07 18:35:57 Right, but I still can't run sudo in my chroot, which was the original issue that brought the other to my attention. Feb 07 18:35:59 Any ideas? Feb 07 18:36:29 persia: I don't think that can work Feb 07 18:36:34 persia: Just avoid using sudo Feb 07 18:36:48 chroot as root and continue running stuff as root Feb 07 18:37:05 Why can't it work? Works for all my other chroots. Feb 07 18:37:27 Because the kernel runs a single binary for all binaries you run Feb 07 18:37:42 You could make qemu-arm-static suid root, but that would be a huge security hole Feb 07 18:38:15 Ah, I get it. I swear it worked on Tuesday, but maybe I did something else. Feb 07 18:38:51 It's probably worth noting that in a README somewhere, so people don't file bugs. Feb 07 18:38:51 persia: You might be able to run sudo as root Feb 07 18:38:59 That's probably it. Feb 07 18:39:13 my chroots were in a very primitive state on Tuesday. Feb 07 18:39:29 Anyway, I have to head off for a bit. Thanks a lot for explaining my issue. Feb 07 18:39:56 np, do feel free to pass the info to ogra :-) Feb 07 18:40:09 ogra: ^^ Feb 07 18:40:14 * ogra reads it ... i'm just in fuzzy jetlag state Feb 07 18:41:13 Ok, I give up trying to get virtio-pci to work under versatile Feb 07 18:41:53 It seems versatile has a very specific IRQ handling which might mess this up anyway Feb 07 18:49:41 lool, did andy talk to you ? seems your patch didnt build at all Feb 07 18:50:07 for now i asked him to just change the two config options you mentioned in the bug Feb 07 18:59:22 ogra: ? Feb 07 18:59:43 ogra: I talked to apw on #ubuntu-kernel; the kernel certainly built for me, as well as the modules Feb 07 18:59:51 I didn't build .debs though, so there might be some ABI issues Feb 07 19:00:25 he said it exploded in his face on the first modules it tried to build Feb 07 19:00:45 and said your patch changed more than just the two config options Feb 07 19:06:49 ogra: Which patch? Feb 07 19:07:00 Anyway, this is out of date, he merged my work AFAIK Feb 07 19:07:07 i think he said you gave him a git tree or something ? Feb 07 19:07:29 well, he said he didnt when we talked last night before i flew out Feb 07 19:07:39 since it failed to build Feb 07 19:08:22 I attached a patch to the bug and the first commits of the git tree were to fix the lucid tree and then my patch Feb 07 19:08:29 Followed by large config updates in a separate patch Feb 07 19:08:35 That built for me, and he merged it Feb 07 19:08:43 weird, he said it didnt Feb 07 19:08:44 He then decided to merge the updates in a single patch Feb 07 19:08:53 Check the tree yourself Feb 07 19:08:57 I certainly saw it merged Feb 07 19:09:22 intresting Feb 07 19:10:11 i only see the binutils.bin fix in the last upload Feb 07 19:10:53 It's in the git tree, not in the source package Feb 07 19:11:18 right, because it made the package ftbfs according to him Feb 07 19:21:54 lool: Maybe it's because I'm in a chroot, but installing karmic qemu-arm-static in my lucid chroot creates double entries for me in /proc/sys/fs/binfmt_misc/*. dist-upgrading fixes it. Feb 07 19:26:03 persia: Yes, if you have it in the host, you'll see the entry in the chroot Feb 07 19:26:20 However if you add it in the chroot, it wont be visible in the host Feb 07 19:26:33 Can't believe lucid kexec-tools doesn't allow armv7l... Feb 07 19:26:47 Well, kinda. That was my experience for /var/lib/bin... but I seem to have the same /proc in and out of the chroot. Feb 07 19:26:58 lool, huh ? we fixed that in jaunty ? Feb 07 19:27:06 NCommander was saying that kexec() hung his hardware. Feb 07 19:27:20 * ogra clearly remembers he added a patch to kexec-tools Feb 07 19:27:49 hmm, but that might have been before the disastrous repackaging that lieb did Feb 07 19:28:03 You might want to reinvestigate Feb 07 19:28:40 it wont apply anymore, the packaging lieb did isnt even remotely related to the debian packaging Feb 07 19:29:20 he just took the latest upstream source and ran dh-make on it Feb 07 19:29:38 Can we just purge dh-make already? Feb 07 19:29:59 and then copied all patches into debian/patches in case someone wants to re-apply (which indeed wouldnt work at all) Feb 07 19:30:31 (IIRC) Feb 07 19:30:54 Right. That deserves an investigation to reclose n bugs. Feb 07 19:31:58 kexec-tools 2.0.1 fixes it though Feb 07 19:32:43 did you reverse the mess ? Feb 07 19:32:50 I'm just reading the source Feb 07 19:33:33 lp:debian/kexec-tools and lp:ubuntu/kexec-tools don't relate at all, yeah Feb 07 19:33:56 haha I'm the one who uploaded the kexec-tools patch in jaunty Feb 07 19:34:01 actually I uploaded it to unstable Feb 07 19:34:10 http://paste.ubuntu.com/371141/ Feb 07 20:13:07 I pushed the new upstream release Feb 07 20:13:18 great Feb 07 20:13:32 to sad kexec is still broken in all supported kernels Feb 07 20:13:48 (we tested it last week) Feb 07 20:15:33 How did it run last week? Feb 07 20:15:50 quit good progress on the specs Feb 07 20:16:21 we actually managed to get the workitem tracker to show green under the trendline :) Feb 07 20:16:40 * ogra only has 4 items left in total and only tw in rootstock Feb 07 20:16:46 *two Feb 07 20:17:09 the marvell issue was kind of eating the first half of the week though Feb 07 20:18:37 Let me reword my question: how could you test kexec last week since it doesn't run for utsname == armv7l? Feb 07 20:19:12 hmm, ask NCommander :P he did the tests on both arches Feb 07 20:19:30 i only saw it hanging when looking over his sholder Feb 07 20:19:48 i guess he has to retest then tomorrow Feb 07 20:20:42 thanks for pointing that out, i was expecting he had checked that before Feb 07 20:21:10 ah ... Feb 07 20:21:33 * ogra feels relief that jackd gets removed with the most recent upgrade Feb 07 20:21:55 and off to reboot ... Feb 07 20:26:27 hmm, my boot got slower http://people.canonical.com/~ogra/osiris-lucid-20100207-3.png Feb 07 20:30:10 That's expected. Remember that the target is 10 seconds, not 8. Feb 07 20:30:50 well, my system is usually a few seconds faster than the average HW Feb 07 20:44:59 New kexec still doesn't take armv7l, odd Feb 07 20:48:41 Bah I thought it was in 2.0.1 because Debian had 2.0.1 and had it, but it's not Feb 07 20:48:52 (and upstream had it too) Feb 07 20:48:57 it was committed after 2.0.1 Feb 07 20:53:50 smells like another upload :) Feb 07 21:12:30 Ok, at least the new kexec crashes instead of refusing to run Feb 07 21:31:02 After the last fix, it does *something* Feb 07 21:31:17 "Starting new kernel Feb 07 21:31:46 That was the behaviour NCommander reported last week. At which point it hung. Feb 07 21:32:06 I see 100% CPU consumption from qemu Feb 07 21:32:29 Matches the previous report :) Feb 07 21:32:47 oddly, the versatile .deb build fails for me with /home/lool/qemu-versatile/linux-qemu/drivers/scsi/advansys.c:8352: error: implicit declaration of function 'dma_cache_sync' Feb 07 21:32:51 But only the debian way Feb 07 21:33:03 with the upstream make zImage and make modules, it builds Feb 07 21:34:28 I guess it's just not fatal for the upstream build, hmm Feb 07 22:01:26 I filed LP #518567 on the kexec issue Feb 07 22:01:28 Launchpad bug 518567 in linux (Ubuntu) (and 1 other project) "armel/versatile: Can't kexec (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518567 Feb 07 22:01:32 Got further by using a serial console Feb 07 22:19:28 Sent versatile fixes to kernel-team@ list **** ENDING LOGGING AT Mon Feb 08 02:59:57 2010