[00:22] apw: Two patches sent to mailing list [07:55] BenC, thanks [08:33] apw: Hi, is there a wiki page describes the SRU kernel release schedule? I would like to know when I'll have a fixed (proposed) kernel if I submit a SRU now. [08:33] AceLan yeah there is, hang on [08:52] * AceLan is trying to find the reset button on apw, looks like he hangs [08:52] AceLan, i am more going a bit mad trying to find it :) [08:52] http://people.canonical.com/~kernel/reports/sru-report.html [08:53] that is part of the story, what is currently where and verified [08:53] plus ... [08:54] hmm [08:56] AceLan, the other part i get as email and in the IRC report, but i suspect it is also out there somewhere too [08:57] though this cycle does not appear to have beeen announced [08:59] apw: are there dates about the SRU freeze, testing, and release? [09:00] AceLan, yes there are [09:00] apw: on wiki? or only in email? [09:01] i am sure it is in the wiki, i cannot find it right now there, the latest dates were in the transcript of yesterdays meeting which is on email [09:01] and normally he emails them to kernel-sru-announce but does nto appear to have done so this cycle [09:01] bjf, ^ [09:03] apw: ok, please keep an eye on it, if you found the wiki, please let me know, thanks [09:04] https://lists.ubuntu.com/archives/kernel-sru-announce/2014-April/000015.html [09:04] so that was the announce for the previosu cycle [09:05] apw: cool, I'll keep an eye on that list, thanks [09:05] https://lists.ubuntu.com/archives/ubuntu-devel/2014-April/038262.html [09:05] that second one has the announced dates per our meeting yesterday [09:06] apw: thanks a lot [09:07] BenC, that makes things much happier ... thanks [11:12] apw: Excellent [12:18] https://launchpad.net/ubuntu/+source/u-boot-linaro [12:18] it's in main and it's available for T [12:18] _but_ [12:19] wget http://ports.ubuntu.com/dists/trusty/main/binary-armhf/Packages.gz [12:19] zgrep "Package: u-boot" Packages.gz [12:19] Package: u-boot [12:19] Package: u-boot-tools [12:19] no u-boot-linaro there [12:19] why? [12:19] and indeed, mt lb build complains: [12:20] e.g. E: Unable to locate package u-boot-linaro-omap3-beagle [12:20] *my [12:20] probably #ubuntu-devel was more appropriate, but anyway [12:21] infinity: can you help me here? ^ [12:24] the binaries are all called u-boot-linaro-* ... hmmm [12:25] what section are they in though [12:25] u-boot-linaro | 2012.08.2-ubuntu1 | trusty/universe | source [12:25] ok this is all in component universe, so you have the wrong Packages.bz file [12:26] doh [12:26] Component:* [12:26] main [12:27] apw@bark:~/plusone$ zgrep "Package: u-boot" Packages.gz [12:27] Package: u-boot-linaro-ca9x4-ct-vxp [12:27] https://launchpad.net/ubuntu/+source/u-boot-linaro [12:27] Package: u-boot-linaro-efikamx [12:27] Package: u-boot-linaro-highbank [12:27] [...] [12:27] *actual publishing details may vary in this distribution, these are just the package defaults. [12:27] ah [12:28] bloddy asterisk :) [12:28] *bloody [12:28] well, in saucy was in main [12:28] it was moved to universe in T [12:29] (/me is blackbelt in finding excuses...) [12:29] yep, rmadison is your friend there [12:29] you are italian ... [12:31] soooo [12:31] lb needs a fix [12:31] ubuntu-server) [12:32] ... [12:32] COMPONENTS='main' [12:32] that's why it was working before [12:32] ok [12:37] ogra_: shhht... i'm "fixing" your rootstock-ng [12:37] heh [12:43] * ppisati go grab a kebab... [13:12] uhm [13:12] E: Handler silently failed [13:12] E: config/hooks/100-preinstall-pool.chroot failed (exit non-zero). You should check for errors. [13:18] ppisati: Oh dear, are you trying to resurrect the icky server preinstalled images? [13:22] infinity: yes and no - i'm trying to teach rootstock-ng to build ubuntu images for arm boards but in the mean time i need a woarking target for lb thus i'm picking ubuntu-server [14:49] so apw I should be able to run the latest 'current' image on trusty? [15:34] yes, it is built with utopic's config but i am running that here [16:01] root@luxor:/build# cd chroot [16:01] root@luxor:/build/chroot# cat etc/apt/sources.list [16:01] root@luxor:/build/chroot# ls -la etc/apt/sources.list.d/ [16:01] total 8 [16:01] drwxr-xr-x 2 root root 4096 Apr 10 13:10 . [16:01] drwxr-xr-x 6 root root 4096 Apr 30 12:43 .. [16:01] root@luxor:/build/chroot# [16:01] that might be a problem... [16:08] apw, shall I grab the powerpc64-emb patches ? [16:26] i have applied them ? [16:26] rtg, [16:26] unless that doesn't mean the 2 benc sent this morning [16:26] and they work too [16:28] rtg, and i switched the base version to 3.15 cause we were still making binary packages with 3.14 as the name [16:28] apw, nm re: powerpc. I just forgot to update. [16:28] ahh [16:31] where and when the /run is mounted? [16:31] in the initrd [16:31] cking, uploaded sysvinit_2.88dsf-41ubuntu7 [16:31] first thing it does [16:32] rtg, /me tries it [16:32] cking, it'll take a bit to percolate into the archive [16:32] doh, too eager is me [16:33] niluje, /usr/share/initramfs-tools/init [16:33] hm [16:36] thansk ogra_ [16:51] ogra_: are you sure? [16:51] isn't it mounted by init? [16:51] my problem: I create a process in the initramfs that I want to exclude from the killing process of init when the system reboots or shutdowns [16:52] I need to write the PID of the process in /run/sendsigs.omit.d/ [16:52] so can't that process put itself in there ? [16:52] nope [16:53] why so [16:53] the process is nbd-client and is used to mount the rootfs [16:53] at the time the process is created /run doesn't exist yet [16:53] why not? [16:53] ? [16:53] i thought we mounted /run on the initramfs / [16:53] because init hasn't been called? [16:53] and real / on /root [16:54] and then move mounted /run into /root before pivoting into it [16:54] so if you are staring it before mounting real / you must have it in the initramfs and thus after the /run is made [16:55] hm [16:55] calling "mount" after the rootfs is mounted doesn't list the /run [16:55] (in the initramfs) [16:56] check out cat /proc/mounts, i'd not trust mtab [16:56] mtab? [16:56] mount just tells you what mtab the userspace copy of the mount table says [16:57] and that is often a lie in this two roots sceario [16:57] ok [16:57] * niluje still has a lot to learn :p [16:57] but if you look at the initrd /init which is just a shell script, it mounts /run [16:58] http://pastebin.com/W6jij8dD [16:58] and then we do this to move it into the real root before pivot [16:58] mount -n -o move /run ${rootmnt}/run [16:58] seem to be the same [16:58] where in the initramfs handling are you doing this [16:59] and actually what release [16:59] scripts/init-bottom [16:59] ubuntu 14.04 [16:59] as we mount /sys /proc /dev/pts and then /run [17:00] and during init-bottom it is mounted still and not yet moved [17:01] wait [17:01] I think I just understood something I should have known :p [17:01] where is the move from /root/run to /run and from /root to / ? [17:02] /run is on /run in the initramfs and your root is /root [17:03] last thing we do is move mount /run to /root/run (so the files stay in there) [17:03] and chroot into /root (approximatly) [17:03] hm ok [17:04] so in what hook should I put the nbd-client pid in /root/run/sendsigs.omit.d/ ? [17:04] you hsould put it in /run/sendsigs.omit.d/ in init-bottom [17:04] and that will be /run on the real root "later" [17:04] in theory [17:04] ok [17:05] cannot it be done sooner than init-bottom? [17:05] i thought that was where you started the thing [17:05] sorry, we misunderstood [17:05] I start the process in scripts/local-top [17:05] /run should be there for all of the hooks by the looks of it [17:08] niluje, i am confused if i boot this machine here and 'break=bottom' i can see /run mounted in /proc/mounts [17:15] :/ [17:17] cking: got down to the installer issues - efibootmgr upstream are working on supporting/generating entries for 1.1a devices, and i've sent patch for grub-mkdevicemap to colin which makes ubiquity/d-i just work with current efibootmanager and 1.0 devices. [17:17] rtg, just pushed and aufs update, seems to work again [17:17] xnox, cool, and I now have some working H/W again [17:17] cking: grub fix is not in utopic/trusty yet, but once it's in utopic i'll Shepard it for SRU to trusty. [17:18] cking: oh, excellent =) [17:18] xnox, ping me when it's ready to test and I'll get around to it [17:18] Asap [17:18] cking: cool! [17:18] xnox, I spent most of this afternoon breathing life back into my setup, had various firmware issues and a dead box that wouldn't boot, so this is quite timely :-) [17:32] cking: since grub is actually part of life-fs / debian-installer, and is executed from /target, i have no easy way for you test this until we spin an image with fixed up grub. [18:46] ... why do I seem to need to pass "nolapic" on my kernel cmdline to boot a trusty kernel in qemu/kvm? I must be doing something wrong. [18:46] Cause otherwise everyone would be complaining. [18:48] infinity, hmm, I run trusty kernels all the time using virt-manager on a trusty host (though I'd better re-check that just to be sure) [18:50] yup, works fine [18:50] rtg: I wonder if maybe grub2 pulls some magic here. I needed "nolapic" to boot it raw with -kernel and to boot it from grub1 (don't ask). [18:50] rtg: Can you confirm that a raw boot with -kernel vmlinuz-3.13.0-24 also fails for you? [18:50] rtg: Cause if not, I'm doing something odd. [18:50] (Also -enable-kvm -cpu host) [18:50] I've just got grub-pc [18:51] Maybe setting the CPU emulation lower would also "fix" it. [18:51] copy host CPU configuration ? [18:57] rtg: "-cpu host" is that, yes. [19:00] rtg: http://lucifer.0c3.net/~adconrad/Screenshot%20from%202014-04-30%2012:59:35.png <-- That's what I see if I boot without nolapic. [19:01] rtg: (Well, what I really see is that it reboot there and loops, but the tail end of my qemu commandline prevents that) [19:04] infinity, is this a new qemu in utopic ? looks like slightly different versions between trusty and utopic. I assume trusty _used_ to boot without the APIC setting ? [19:05] rtg: This is the trusty one. [19:05] Well, trusty-updates/uptopic-release, same version. [19:06] Maybe the one in -proposed fixes this. :P [19:06] * infinity upgrades to see. [19:06] I'm just running tip of trusty -updates [19:06] Right, so same version as me. [19:07] I'm on utopic, but that shouldn't matter here. [19:08] rtg, are you running a 3.13 kernel, or some home brew [19:09] apw, stock trusty [19:10] 3.13.0-24-generic [19:11] not that then [19:13] Very confusing, this is. [19:13] I'd like to at least see if someone else can reproduce it so I know I'm not crazy. :P [19:13] I suppose it may be specific to my hardware. [19:13] as you are passing through your cpu, yes [19:13] But weird that I can boot my actual laptop fine without nolapic, and then the KVM-emulated version of same doesn't work. [19:14] apw: Yeah, I tried with a more generic -cpu and same issue, though. [19:14] (But -enable-kvm in both cases) [19:17] ... and if I disable KVM, and feed it a -cpu that should be 64-bit, it tells me it's not. Man, I love qemu. [19:18] Oh, FFS> [19:19] lrwxrwxrwx 1 root root 25 Feb 9 2013 /etc/alternatives/qemu -> /usr/bin/qemu-system-i386 [19:19] THANKS HALLYN. [19:19] rtg: Fixed by running qemu-system-x86_64 [19:19] * infinity sighs. [19:19] How the heck -i386 "works" when I pass through my host CPU and turn off local APIC, I don't know. [19:19] But x86_64 works better. :P [19:20] hallyn: Why is the default qemu alternative on amd64 pointing to i386? [19:20] infinity, i386 likely doesn't have an APIC. I wonder how you got linked to the wrong binary ? [19:21] 4 /usr/bin/qemu-system-i386 20 manual mode [19:21] 24 /usr/bin/qemu-system-x86_64 10 manual mode [19:21] how the heck did we manage that [19:21] Because i386 has a higher prio. [19:22] yeah but how the heck did they not have the same... sigh [19:22] rtg@gbyte:~/linux/linux-firmware$ ls -l /etc/alternatives/q* [19:22] lrwxrwxrwx 1 root root 25 Mar 3 17:26 /etc/alternatives/qemu -> /usr/bin/qemu-system-i386 [19:22] They shouldn't be the same, x86_64 should be 20 on amd64 and 10 on i386, and vice versa on the other. [19:22] But they sure aren't. [19:22] hallyn: Plsfix. I just wasted precious time thinking I was crazy. [19:23] infinity, note that I _only_ have i386, which doesn't make sense [19:23] rtg: Hrm? You have both installed, surely, and your fancy virt-manager is calling qemu-system-x86_64 directly, not "qemu". [19:24] rtg: I call "qemu" cause I'm a lazy typist, which led me to this pain. :P [19:24] infinity, that is possible. I never use qemu from the CLI [19:24] (too lazy) [19:25] qemu-system-x86 must have both arches ? [19:26] It does, yes. [19:26] Which means its postinst needs to be more clever about the alternatives. [19:27] Cause the "qemu" binary is effectively useless. [19:27] Though, fun to see that a 686-class motherboard with my i7 CPU jammed in "works" with nolapic. :P [19:29] # Set i386 as highest priority, [19:29] # as it has been the default qemu for quite some time. [19:29] case $arch in i386) prio=20;; *) prio=10;; esac [19:29] And evidently, this is intentional. [19:30] seems like most folks using qemu are also likely to be running a 64bit host [19:31] these days [19:31] Well, I'd contend that the priority should just be set to match userspace. [19:31] So, people like Colin would get the wrong one. [19:31] But everyone else would get what they expect. [19:31] (Colin runs i386 userspace on amd64 kernels) [19:31] seems reasonable === ChickenCutlass_ is now known as ChickenCutlass [19:51] infinity: mjt feels pretty strongly about noth aving that be doen as an atlernative [19:52] hallyn: Bleh. [19:52] not sure if there is a better way to get waht we really want... [19:52] hallyn: That makes /usr/bin/qemu pretty much useless to most 64-bit users. [19:52] hallyn: And certainly surprisingly confusing. [19:53] hallyn: Having /usr/bin/qemu be a wrapper that checks the running kernel (not userspace) and picks the most appropriate emulator as default would probably actually be the best. [19:53] i thought /usr/bin/qemu hadn't existed for awhile already. i dont' have it in precise [19:53] hallyn: I have it in trusty/utopic... [19:53] /usr/bin/kvm is arlready a wrapper, though not as smart as thought [19:53] as that* [19:56] infinity: shall i revert the removal oft the alternative? [19:56] hallyn: Err, it wasn't removed? [19:56] i think actuall colin's case might be an example of where it *is* an alternative, [19:56] hallyn: I've done nothing special here, your postinst sets up this alternative. [19:56] stgraber, arges that kernel crash in conntrack is also reproduceable on Linus's tip [19:57] sconklin: cool did you get a reliable reproducer and/or crashdump? [19:57] infinity: aiui the whole point is that the alternatives are *removed* in utopic; [19:57] or, did i not take that change? i thought i rejected it for trusty, and i haven't knowingly taken it for u [19:58] hallyn: utopic and trusty are the same version... [19:58] hallyn: And in both cases, the alternative is there. [19:58] hallyn: And pointing to i386 on my amd64 system. [19:58] well, there's a one-lien change in utopic, probably still in -proposed [19:58] hallyn: Hence my incredible confusion. [19:58] hm [19:58] then i don't know whence the change [19:59] arges: we have a reliable reproducer but it's not very portable outside our environment. I pasted all the stack traces into both the Ubuntu and kernel.org bug reports. If you have anything you want us to try, we can probably do it [19:59] (meaning it's inadvertant) [20:01] ok, so postinst-in has [20:01] # Set i386 as highest priority, [20:01] # as it has been the default qemu for quite some time. [20:01] which i seem to recall being the case even prior to precise... [20:02] hallyn: Sure, it's entirely possible I've never run "qemu" on this machine before now. :) [20:02] hallyn: Doesn't change that the default being something that can't boot my arch is rather surprisingly confusing. [20:03] ok - sorry i thought you were saying something had changed [20:03] hallyn: No. I don't think anything's changed, I just think it's wrong. [20:03] so it soudns like the best way forward is in fact to proceed with dropping the /usr/bin/qemu alternative, andwrite an intelligent wrapper [20:03] mjt agrees with you :) [20:04] heck i dno't knwo when it was introduced, bc indeed precise does nto have it (which is why my box doesn't have /usr/bin/qemu)