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