=== alow_ is now known as alow [09:59] I merged kexec-tools with Debian [10:00] nice ! [10:00] but it still doesnt work ? [10:00] (on arm) [10:03] ogra: It still hangs when you try to kexec within qemu/versatile [10:03] The Debian merge was mostly packaging stuff [10:04] The packaging is sane again? [10:05] Yes [10:05] The Ubuntu diff is absolutely bearable [10:06] We mostly disable kexec on boot by default and add kdump [10:06] Too bad I didn't notice there is a kernel.ubuntu.com/git kexec-tools git tree, but it has its own issues anyway [10:07] I suspect it's from that tree that last week's tests were executed. [10:07] I mailed cooloney on the kexec issue; I hope he can help us there, it's too low level for me [10:08] Probably best to coordinate with ericm_ and NCommander to make sure everyone is testing the same source. [10:08] I thought ericm was doing most of that, but cooloney may also be able to help. [10:08] persia: The tree has the same issues as lucid, it's out of date by one upload before my work and just misses the kdump init script [10:08] I rather suspect NCommander took Debian's or upstream's kexec-tools [10:08] Quite possibly. [10:12] I wonder whether ericm can be bothered for versatile kexec [10:12] lool: Did you ever get anywhere with the pbuilder-dist changes to do better detection of when to use the alternate debootstrap? Should I track down some other python person? [10:12] I didn't attack that [10:12] I suspect that getting versatile kexec working would be a good step towards getting it working anywhere else. [10:12] My real plan is to remove the need for pbuilder-dist altogether, but that's a longer term effort [10:12] No worries then. I'll try to find someone else. [10:13] If you remind me of everything we agreed to do, I can certainly do it [10:13] I have a solution to drop pbuilder-dist: migrate to schroot/sbuild :) [10:13] Eh [10:13] schroot/sbuild doesn't have cowdancer though; it does have LVM snapshot, but it's a bit different [10:13] You didn't like me using the architecture to determine when to use the emulator: you seemed to prefer to do host/guest arch compat comparison. [10:13] schroot *does* have COW now, in 1.4, although I haven't quite figured out how to get it working. [10:14] It's on my list to try to get schroot to work with pbuilder-style tarballs, COW, etc. in the next few months (although I'm not sure I can release with lucid) [10:14] I don't see that; are you sure you don't mean LVM COW? [10:14] I am. [10:14] persia: I don't see this in /usr/share/doc/schroot/NEWS.gz though; let me check sbuild [10:15] I don't see it in sbuild's NEWS either [10:15] persia: Do you have any name/reference for the feature? [10:15] "Support for union filesystems has been added ... loopback chroots with a temporary writable overlay ...". It's not quite COW, but should have similar performance. [10:16] Quote is from sbuild's NEWS.gz [10:16] Ah but that's not in lucid? [10:17] Yes it is :) [10:17] I was checking lucid files [10:17] So was I. Check item 8) in NEWS for 1.3.0-rc1 [10:17] Why don't I see union in NEWS.Debian and NEWS?? [10:17] sbuild doesn't have 1.3.0-rc1 [10:17] Err, sorry. From *schroot* NEWS.gz [10:17] sbuild is just a build script that runs against schroots. [10:17] Ack I see it now [10:18] lool: yeah, i'm looking at that. [10:18] Using union fses is much cleaner than pbuilder's approach [10:18] persia: ericm_ made it kexec works on dove, IIRC. [10:18] cooloney: let me know if you need any help with the setup [10:18] lool: And `sudo pbuilder` is just pointless escalation. schroot's selective mechanism is much richer. [10:18] persia: he will help me about this [10:19] persia: Tell me about it [10:19] cooloney: I thought it kinda worked, but then crashed on the call, but I may be mistaken. Great to hear you guys will be working together on this. [10:19] lool: yeah, do you know where can I download the rootfs for testing [10:19] cooloney: Best to create your own; it's quite easy [10:19] cooloney: Use rootstock to generate one :) [10:20] I still call debootstrap by hand, but the recommended tool is probably rootstock or just build-arm-chroot [10:20] persia: yeah, since imx51 also has some issue about kexec, i need to work on that as well as versatile [10:20] rootstock will setup misc configs for you, hostname, passwords and the like [10:20] Definitely rootstock. It does a lot of the installer bits that build-arm-chroot skips, like user creation, etc. [10:20] (which don't belong in build-arm-chroot, really) [10:20] lool: oh, it is very slow for me to download the evironment. i tried rookstock before. heh [10:21] cooloney: You don't have a mirror nearby? [10:21] cooloney, kexec didnt work on friday when NCommander tried it though that might be because kexec-tools was broken [10:21] cooloney: I can back you my rootfs if you like, hold on [10:21] lool: can i try common local ubuntu mirror for that? [10:22] lool: yeah, i love that. hehe [10:22] cooloney: You need a ports mirror sadly [10:22] ogra: yeah, ericm_ mention that before. [10:22] cooloney: What I recommend is that you use squid as a caching proxy [10:22] If the .debs don't change too often, nost of the debootstrap bits will be cached in there [10:22] lool: i guess there is no such ports mirror in China. [10:23] cooloney, use approx on your local machine [10:23] cooloney: squid-deb-proxy is a package which will setup squid to that effect [10:23] lool: great, is there any wiki for such setup? [10:23] then you at least only have to download once [10:23] cooloney: Then you just need to set http_proxy in /etc/environment and you're done [10:23] cooloney: squid-deb-proxy might have some doc [10:23] or as lool said [10:23] cooloney: I'm scp-ing my rootfs, but will take a while [10:23] lool: got you [10:24] approx needs no setup though ... you just point to your local IP [10:24] on port 9999 [10:24] lool: thanks a lot, if it is done, just email me [10:24] ogra: right, i think i tried approx before. any wiki about that? [10:25] lool: email me the url, heh [10:25] cooloney: URL will be http://people.canonical.com/~lool/rootfs.img [10:25] but not finished yet [10:26] cooloney, apt-get install approx ... then use -mirror http://:9999/ubuntu-ports in your scripts (or set http_proxy to :9999) [10:26] i use it with rootstock all the time to speed up my testbuilding [10:27] * lool simply has a local mirror [10:27] A local mirror tends to be the easiest way to deal with limited bandwidth, but does require a bit more hardware. [10:27] * ogra thinks lool is a rich man who can waste useful diskspace [10:28] * lool thinks his time is more valuable than hardware [10:28] with a disk that costs €20/GB i really dont like to waste it [10:29] 20 EUR/GB? are these made of gold? [10:29] well, i rarely need most of the packages from the mirror ... so just caching the ones i use over and over makes a lot more sense [10:29] OMG, you guys all have local mirror? [10:29] lool, no, of super speedy flash :) [10:29] https://www.materiel.net/ctl/Disques_durs_internes_SATA/46461-Barracuda_7200_12_S_ATA_1000_Go_32_Mo.html [10:29] so normally, how big disk is enough for setup a mirror? [10:30] cooloney, nope, as i said above, i think a local mirror is a waste of diskspace [10:30] ogra: apparently, you don't have, heh [10:30] ogra: you got faest speed maybe. heh [10:30] That's .075790 EUR/GB :) [10:31] a local proxy will only cache what i need, a local mirror copies the whole archive [10:31] ogra: right. [10:31] lool, does it boot in 8sec ? :P [10:31] ogra: That only works if you always the same stuff [10:31] but lool doesn't care about that [10:31] ogra: Actually about that yes [10:31] indeed, its perfect for image builds [10:31] Because it's in RAID10 and doesn't start the desktop [10:31] haha [10:31] cheater [10:32] lool, http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png :P [10:32] and thats a slow boot ... i usually have around 230MB/s [10:33] Stop wagging :p [10:33] lool: how big is your rootfs? heh [10:33] ogra: Err you know I have SSD on my laptop since a year and a half? [10:33] lool: 1G? [10:33] Plus mine is bigger than yours [10:34] lool, yeah, as i said, youre a rich man ... i'm a poor german, cant spend on wine for lunch :P [10:34] ogra: lol [10:34] Just don't try teasing me! [10:50] cooloney: Done uploading [10:50] cooloney: There isn't much free space, you can grow the rootfs by appending some zeroes to the file and growing with ext2resize [11:11] lool, was it you who added the if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then check to rootstock ? [11:12] * ogra cant remember from where that got merged, but it seems silly to additionally keep the version check code [11:12] * persia suggests `bzr blame ...` [11:12] persia, bah, trying to kill my lazyness ? [11:13] Every day, in every way :) [11:13] 23 ogra@ub | if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then [11:13] hrm [11:13] committer: Oliver Grawert [11:13] add a check if debootstrap supports $DIST, thanks to Erik Corry for the fix ! [11:13] oh, k [11:13] i think i got that one by mail [11:14] adn i think i'll just kill all the silly version checking then [11:16] ogra: This check doesn't seem too bad though, what's the issue with it? [11:16] lool, nothing apart from bloating the code if we check for /usr/share/debootstrap/scripts/$DIST anyway [11:17] its kind of a duplication imho [11:17] ogra: Where do you do that? in build-arm-chroot? [11:17] rootstock [11:17] So where is it duplicated? [11:17] if $(dpkg --compare-versions $DBSV lt $DEBOOTSTRAP_MIN_VER);then [11:17] vs [11:18] if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then [11:18] The version check is the one I'd drop [11:18] right, thats what i said :) [11:18] The data-driven check seems more future proof than a version requirement which will be out of date every release [11:18] right [11:25] * ogra -> break [12:02] lool: i am downloading now. [12:03] lool: it is 300M, need I append some zeroes? I don't understand heh [12:06] its an img not a rootfs [12:06] so to have more space on it you need to make it bigger by adding zero byte blocks and resize the partition [12:07] ogra: got you. so normally how to do that : adding zero? [12:07] use dd [12:16] ogra: dd conv=notrunc oflag=append if=/dev/zero of=rootfs.img bs=1M count=1024 [12:17] ogra: is this kind of command, right? add 1G zeroes at end of rootfs.img [12:19] cooloney, hmm, never used append, but if it does the same as skip and seek that should work [12:19] best to try it on a copy of the image i guess :) [12:20] ogra: heh, right. hehe [13:11] cooloney: That seems about right [13:11] cooloney: Or just dd if=/dev/zero bs=something count=something >> rootfs.img [13:12] * ogra guesses cooloney would already have shouted and cired if it hadnt worked :) [13:12] *cried [13:12] ogra: But it's actually a rootfs [13:12] It's just that most people say rootfs when they mean rootfs tarball [13:15] well, one is an imag the other is the content of a filesystem [13:15] neither is named right anyway :) [13:15] since neither is actually a filesystem per se [13:26] the rootfs.img is a filesystem [13:26] i.e. root file system [13:41] asac: is bug #474322 on your radar? [13:41] Launchpad bug 474322 in linux-fsl-imx51 (Ubuntu Jaunty) (and 1 other project) "linux-image-2.6.28-16-imx51 appears broken on armel (affects: 1)" [Critical,Triaged] https://launchpad.net/bugs/474322 [13:41] it's from November and is a regression in a security update of the kernel in jaunty [13:44] rcn-ee: Re: your qemu-arm-static -> qemu-kvm-extras-static issues: this should be fixed in latest versions [13:44] rcn-ee: let me know if it isn't [13:46] rcn-ee: Do you have a place where you publish your daily rootstock build logs, or is http://rcn-ee.homeip.net:81/dl/rootstock/ just updated manually? [13:46] I wonder whether we should publish daily built rootfs like the UEC images [13:47] I wonder why devtmpfs breaks for you [13:49] rcn-ee: Regarding the "fixed" statement above, note that setuid binaries still won't work, but this is an inevitable consequence of how the emulation is done. [13:51] ogra, lool, i've built some kernel .deb's for lool's versatile configuration changes, want to get some testing on them before i upload them; see the 13.18 kernels here: http://people.canonical.com/~apw/misc/arm/ [13:52] apw, will test soon, thanks a lot [14:00] apw: Tested with serial console, works fine up to a console login prompt [14:03] cooloney: can you check the bug lool mentioned? [14:03] 474322 [14:03] that is [14:04] cooloney: seems it stopped working on bbg1 after security update... thanks! [14:05] apw: Checking with graphics now (vga/fb video output) [14:06] apw: Boots fine; NB: I just extracted the vmlinuz file and usese that [14:06] ok [14:07] apw: I don't think it's a regression, but I can't actually poweroff/reboot the system [14:07] lool, yeap it looks fixed... (worked friday night when i was testing things for ogra)... For reference my 'nightly' builds are here.. http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log i need to do a bzr pull thou, it's karmic + lucid tweak... [14:07] The userspace bits seem to happen fine, but it doesn't actually reboot/stop [14:07] i think reboot never worked [14:07] at least with the archive kernels [14:08] Is this an issue with qemu, or with the kernel? [14:08] ok .. i guess i am trying to ensure its not a regressing kernel for you guys [14:08] persia: I don't know, and it's a case where it's hard for me to tell [14:08] I do see "Restarting" on the console, and then nothing happens [14:08] ah, no shutdown never worked for me ... [14:08] asac: no problem, but I need to setup my bb1 board tomorrow. [14:08] apw: I really don't think it's a regression, but I never paid attention [14:08] apw: The current archive kernel doesn't work at all, so... :) [14:09] its very likely not a regression [14:09] thats fine with me, as long as ogra is happy i'll call it good [14:09] apw, just upload, if it works for lool it will surely work for me too (i use way less features) [14:10] * ogra only needs ext2/NIC and serial console [14:12] lool, rm /bin/installer && reboot -fp ... thats in rootstock since day one ... i wouldnt have used -f if it would power doen properly [14:12] *down [14:13] not clear though if its qemu ... [14:32] weird, i cant get it to boot [14:32] it works if i dont use serial [14:32] apw, lool ^^^ [14:33] * apw puts those changes on one side [14:34] hrm [14:34] if i add mem=256M to the append line it works [14:37] weird [14:39] So it just can't handle much memory? I thiought there was a patch for 512M (and seem to remember fiddling with it in jaunty) [14:39] no, its not that, i copied another append line that differs in ro vs rw and mem=256M [14:40] its not the mem but the ro/rw [14:40] it boots fine with ro [14:40] Aha. [14:40] but not with rw [14:40] Very odd. [14:40] apw, i can work around that in the script [14:40] so please upload [14:40] yes, odd indeed [14:40] hrm, ok i suppose [14:40] ogra: How much memory are you using? [14:40] lool, 256M [14:40] but see above [14:41] its not that [14:41] That works for me without mem= [14:41] it seems it cant boot with rw on the cmdline [14:41] qemu-system-arm -m 256 -drive file=rootfs.img,media=disk -M versatilepb -cpu cortex-a8 -kernel vmlinuz-2.6.32-13-versatile -append 'rootwait root=/dev/sda 2' is what I use [14:41] * ogra tries with dropping ro/rw completely [14:42] [ 5.451770] VFS: Mounted root (ext2 filesystem) readonly on device 8:0. [14:42] ok, it defaults to ro [14:42] lool, does it boot if you add rw ? [14:42] Yes [14:42] for me it panics with "cant find rootfs" [14:42] It works fine here [14:43] * ogra tries rootwait, probably a race [14:43] Err yes if you don't have a large rootdelay or rootwait it wont find your rootfs in time [14:43] the scsi disk typically appears a couple of seconds after the kernel tries mounting the rootfs [14:44] [ 5.430661] VFS: Cannot open root device "sda" or unknown-block(8,0) [14:44] [ 5.430938] Please append a correct "root=" boot option; here are the available partitions: [14:44] nope [14:44] i usually dont need rootwait or anything ... never did [14:45] qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel tmp/boot/vmlinuz-2.6.32-13-versatile -hda /var/build/qemu-armel-201002081506.img -m 256 -nographic -append "console=ttyAMA0,115200n8 root=/dev/sda rootwait rw" [14:45] doesnt work [14:45] exactly the same line but dropping rw works [14:46] lool, can you try adding rw ? [14:46] ogra: I already did [14:47] hmm [14:47] i wonder why it reliably breaks here [14:47] Do you actually have read/write on /var/build/qemu-armel-201002081506.img? [14:47] heh [14:47] no, indeed [14:47] pfff [14:47] * ogra re-adds the sudo bit to the README ... [14:47] You don't need sudo to run qemu-system-arm [14:47] Just move your images to your home [14:48] i just removed that from the rootstock doc ... now i remember again why i added it [14:48] Advising sudo is actually dangerous [14:48] well, the image is created as root [14:48] so owned by root [14:48] Well you don't need to [14:48] You just need to mount the file as root and run debootstrap as root, but you don't need to dd the file as root [14:48] i do [14:49] Look, I just created this file as user [14:49] And it worked [14:49] yes, but you dont use it loop mounted until you finished [14:49] I sudo loop mount it [14:49] it is loop mounted during rootstock [14:49] Yes, so $sudo loop mount it [14:49] hrm [14:49] Here's an example script I use http://paste.ubuntu.com/371731/ [14:50] You can run it as root or not, it will call sudo when it needs to [14:50] thats ugly because i will pop passwd prompts all the time [14:50] Actually, one should put a check on that class of script to fail if run as root (see mk-sbuild-lv for a nice check) [14:50] There is some caching, so it will only prompt if it's too late; you can workaround that with a helper [14:50] * ogra sighs [14:50] persia: That's an option; you can easily flip the check [14:51] i will not stop running the script as root [14:51] i want it to run automated if needed [14:51] ogra: So run qemu-system-arm as root then, but don't advise people to do so by default [14:51] ogra: So how are you going to automate running your script as root? [14:51] yeah, i'll add inof the the doc [14:52] i dont, users do [14:52] and they usually set up root cronjobs [14:52] i'll just add info to the doc ... i wont scatter sudo calls across the script [14:59] did you actually read the link? [14:59] it doesn't call sudo if called as root... [15:01] i have the very same check in rootstock ... just not the $sudo var [15:02] * ogra curses about broken userspace [15:02] * Starting init crypto disks... [ OK ] [15:02] hangs :( [15:02] silly ubiquity -> oem-config merge [15:03] pulls in half the world and breaks ... old oem-config worked [15:03] and didnt pull in many deps [15:05] if [ $(id -u) != 0 ];then [15:05] echo "must be run as root" [15:05] exit 2 [15:05] fi [15:05] lool, ^^^ fyi [15:53] bah, so oem-config goes into an endless loop on my rootstock image [17:41] i think we need to forget about oem-config usage in rootstock thats way to messed up and only focused on d-i installs it seems [17:41] s/d-i/d-i or ubiquity/ [17:42] the ui requires metacity which in turn pulls in 400M of deps [17:42] the debconf frontend doesnt finish and goes into an endless loop [17:46] ah, well, without recommends its less but still 30MB [17:51] rcn-ee, had disk transfers running over the weekend on that kernel, no random usb reconnects or errors that I can see [17:51] rcn-ee, i.e., looks great :) === Martyn is now known as Guest34918 [18:28] lool, hmm, did you try running any X programs in qemu yet ? [18:28] specifically pygtk stuff [18:28] seems to fail pretty badly here [18:31] ugh, even metacity [18:47] i dont think its actually happy with the faked cortex-a8 [18:53] hmm, cpuinfo thinks its capable of thumb and neon [19:00] * ogra calls it a day [22:25] persia: According to linux/Documentation/binfmt_misc.txt, one can set a flag to preserve the original security bits of a program [22:25] persia: It changes the calling convention though, so I don't think it would work with out current qemu-system-arm [22:25] lool: Cool! [22:26] Aha. [22:38] lool: Reading the docs, I'm not sure I understand why we can't just pass the 'C' flag and have it work. [22:38] persia: Because it doesn't pass a real file to the qemu-arm command-line [22:38] It is because of the implied 'O'? [22:39] persia: Currently, when the binfmt hook is triggered for e.g. /bin/sh, what happens is that the kernel calls qemu-arm /bin/sh [22:39] persia: Yes [22:39] Ah, so we'd need to modify qemu-arm-static to take file descriptors rather than file names. [22:40] Yes [22:40] Or have a wrapper [22:41] A wrapper can do FD -> path changes? [22:42] That's more shell than I know, or do you mean a compiled wrapper? [22:50] lool: Reading the docs more carefully, I think we do want to change the calling convention. I can well imagine cases where a user wants to execute a file to which that user doesn't have read access when dealing with nested chroots, etc. [22:51] But I'm entirely unsure how to do that with a wrapper: I suspect it needs changes to qemu-arm-static itself. I'd appreciate any pointers if you have them. [22:57] persia: I'm trying to write such a wrapper, but I fail miserably [22:58] When trying to run my x86-64 static wrapper under an armel chroot I get: Error -8 while loading /usr/bin/qemu-arm-static [22:59] persia: I think we would just need a wrapper which passes /dev/fd/N to qemu-system-arm, but I'm not sure; that's what I wanted to verify [22:59] But in the end we would likely patch qemu [23:00] I thought that /dev/fd/N was defined on a per-process basis. [23:00] It is :-) [23:01] In that case, we can't pass it to a new process :) [23:01] So a qemu patch *is* required. [23:01] persia: exec is the same process [23:01] I think my exec doesn't work because it needs to be handled by binfmt [23:02] Hrm? [23:03] persia: exec() is implemented with binfmt, if my wrapper called from binfmt tries to exec it wont work (well that's my guess) [23:03] not sure it's correct [23:04] Another static utility which just puts() argv / argc works, so it's not my build [23:04] * lool will check this out tomorrow & [23:04] Have a good night :)