=== micahg_ is now known as micahg === Jack87|Away is now known as Jack87 === apachepanda is now known as apachelogger === doko_ is now known as doko [10:04] plop [10:05] doko, I would like to help on https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/713985 [10:05] Launchpad bug 713985 in eglibc "[armel] Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on ARM" [Undecided,Confirmed] [10:12] doko, if you have a clue about the problem but no time to work on it, I'll take the clue and try to do something with it [10:12] if you have no clue, I'll just try anyway :-p [10:14] Snark, I won't work on it. first thing might be to recheck with 2.13 and 2.15 [10:14] it's still there with 2.13 [10:14] where can I get 2.15 ? [10:18] in the ubuntu-toolchain-r/glibc ppa [10:19] and there is an armel package too? [10:21] aie [10:21] found it [10:29] hmmm... adding the ppa isn't enough :-/ [10:30] it basically wants to remove the rest of the system [10:50] doko, the only place where I find lgammal mentioned in eglibc_2.13-20ubuntu5.diff.gz is in a patch for sysdeps/ia64/fpu/libm_error.c, so I guess the bug is upstream [11:24] you should debootstrap a precise chroot [11:32] doko, I don't think I have enough room on this poor box :-/ [13:16] How can I generate an installer uInitrd (as found at http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/uInitrd)? I'm trying to test different kernels with the installer. [13:17] rbasak, only by building the installer [13:17] which is highly complex [13:17] what exactly do you want to test ? [13:18] The current installer kernel panics on my panda sometimes. I've now automated a repeated test to find out if a given installer uImage/uInitrd is good or bad. [13:18] (if its only the booting of the installer you can just replace the uImage [13:18] ppisati asked me to test the latest kernel that is in the archive but not in the installer right now [13:18] and if it is I'll need to bisect [13:18] if its more than just booting it gets more complex since d-i uses the udeb packages your kernel build created during the package creation [13:18] Won't I need the modules in uInitrd though? [13:19] Yeah it panics some time in userspace after the kernel boots [13:19] ah, yeah, that would mean to roll d-i from scratch and make it use the newly created udebs [13:19] Surely there's a script somewhere that builds the installer? Or does that depend heavily on hitting the archive? [13:19] (and indeed that means creating the udebs, not sure that works in a cross way at all) [13:20] the "script" is a makefile in the installer source [13:20] in fact a ton of different scripts [13:20] that are used by that makefile [13:20] It hits the archive for the kernel I take it? [13:20] well... apt-get source debian-installer [13:21] I'll have a poke around, thanks [13:21] building it pulls in a lot of other packages, then takes the udebs (from the kernel and elsewhere) and generates the initrd from it [13:21] what I'd really like is an archive overlay system [13:21] there might be a way to pull in the udebs manually from tty4 [13:22] as long as you manage to do the boot up to that point [13:22] (apt-install is the command to install udebs iirc, i havent touched the installer for a while) [13:22] Can I get to tty4 down ttyO2? [13:23] i dont think so, but on serial you can use the "back" option in the installer, that gets you to the menu where you can select the shell [13:23] ah ok, thanks [13:24] I wonder if I could just hack the uInitrd and insert the kernel modules manually [13:26] you could try indeed... === Ursinha` is now known as Ursinha === Quintasan_ is now known as Quintasan [14:07] what can we do to get the installer updated to use the new kernel? [14:42] hello [14:42] is there a place with a known-working version of MLO+u-boot.bin+kernel+Ubuntu rootfs that works on BeagleBoard XM rev C, with USB and graphics? [14:43] so far, we have something that boots, but no USB devices are detected (nothing in the kernel logs) [15:48] doko, where are the file dependencies to be found in glibc's sources?! I don't know if my platform uses sysdeps/ieee754/ldbl-128/e_lgammal_r.c or sysdeps/ieee754/ldbl-96/e_lgammal_r.c... === Jack87 is now known as Jack87|Away [17:06] GrueMaster: question, did you try to change eth0 mac address with latest omap3 kernel? [17:07] My latest omap3 kernel I tested had a serious bug with mmc. Haven't tried anything later. [17:07] I'll check it shortly though. What rev? [17:15] rbasak: Have you filed a bug against the kernel in the netinstaller for panda? [17:15] no [17:16] I was wondering whether to add a debian-installer task to the existing bug [17:16] I've been working on trying to test the latest kernel but that turns out to be quite complicated [17:18] Well, it appears to only affect armhf. I just rebuilt a panda with armel no problem. I'm checking my mirror now to make sure the two are in sync. [17:19] They appear to be. [17:19] would be hard fro them to be out of sync :) [17:20] (same source and d-i would ftbfs if they werent the same version) [17:20] you haven't seen my mirror. [17:20] It occasionally gets out of sync with ports.u.c. [17:27] Hmmm. armel failed on the same platform as armhf, but one machine reimaged with armel just fine. This may need further research. [17:27] any output? [17:28] ppisati: http://paste.ubuntu.com/822806/ [17:29] GrueMaster: this is the 1404 kernel, and that bug was fixed in 1405 [17:48] Right, just odd that it fails on some of my platforms but not others. And it appears to be older ones only (EA1, A1). [17:59] rbasak: While you are waiting for an updated netinstall, I have found that using the newer kernel with the exisiting uInitrd works fine for installing. Running here now w/o errors so far, and it is into the base system step. === chrisccoulson is now known as chrisccoulson2 === chrisccoulson2 is now known as chrisccoulson [18:23] GrueMaster: that's great, thanks! I was writing a script to inject the newer kernel modules into an older uInitrd, but I can leave that for now then :-) [18:24] Yea, I'm not sure what modules get loaded during netinstall, but obviously no critical modules. [22:51] GrueMaster: I'm getting occasional failures on armhf with a hand-built latest git tree kernel on armhf. But quite rare, and unhelpfully the error message is reported to be in syslog, which I can't get to over ttyO2. [22:51] GrueMaster: I'm running the install in a loop, I'll see tomorrow what the success/failure proportion is. [22:51] Try adding "earlyprintk=ttyO2,115200". [22:52] And make sure "quiet" is not in your boot.scr. [22:52] yes, i have those. It's a debootstrap failure [22:53] http://paste.ubuntu.com/823204/ [22:53] Ah. Well, there is a way to enable the web interface in the preseed so that you can monitor syslog from the web. [22:53] I've seen it twice now [22:54] debootstrap failures are generally mirror/network issues. [22:54] But you could skip doing this as an installer loop and just loop debootstrap a few dozen times. [22:54] I haven't seen this at all. Can you past your preseed and I'll see if I can reproduce it here? [22:55] I'm running through a squid proxy, don't see any errors in the log though I might be missing it [22:55] Squiq won't show errors, but the client system sure might. [22:55] Stale caches can do horrible things to apt-like clients. [22:56] (Not that debootstrap is apt, but it still verifies signatures and hashes, which means cache coherency (or no cache) is required) [22:56] preseed: http://paste.ubuntu.com/823207/ - it's got a proxy in there you might want to change [22:56] yeah but the previous and following installs work OK, so it can't be a stale cache problem [22:56] Sure it can. [22:57] If the timeouts are staggered enough, you'd have what appears to be a consistent mirror, followed by inconsistent, followed by consistent. [22:57] That is more than likely the issue. I see issues occasionally here, and just rekick after my mirror update runs (every 2h). [22:57] Assuming a mirror pulse in the middle, and getting one caches result and one fresh. [22:57] s/caches/cached/ [22:58] so we can't reliably run a netinst over a proxy cache? that sounds like an issue to me. [22:58] (I have Packages.gz etc. configured to be refreshed every time) [22:59] And Release*? [22:59] refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz)$ 0 0% 0 [22:59] refresh_pattern \/Release(|\.gpg)$ 0 0% 0 [22:59] On a stable release, it's much less of an issue, since we don't change the release pocket. [22:59] But yeah, 99% of issues like this are usually a proxy's fault. [23:00] The other 1% are actual broken mirrors. [23:03] thanks [23:08] I see it usually when installing at the same time my mirror is updating packages and hasn't finished updating all of the Packages.[gz|bz2] files. [23:08] So not as often.