[09:21] Mar 25 09:00:52 babbage init: Re-executing /sbin/init [09:21] getty on ttymxc0 doesn't come up anymore [10:28] lool, on my image or on an installed system [10:33] ogra: Any system where you upgrade libc6 or run "init u"; see #-devel [10:33] heh, i just read the latest changes on the bug :) [10:34] lool, btw, how about seeding flash-kernel to desktop on armel and make redboot-tools a dep ? [10:36] so we have it in at least, even though there might be hooks missing we can write a howto to make an sd bootable from a running system [10:37] ogra: Perhaps boot instead? [10:37] we have a separate boot seed ? [10:37] thats new to me [10:37] We do [10:37] oh [10:37] does desktop/live use it = [10:37] ? [10:40] Dunno [10:40] ogra: I just grepped for grub in the seeds, I would expect flash-kernel to be selected in similar situations [10:40] i'll talk to colin [10:41] ogra@osiris:~/Devel/seeds/ubuntu.jaunty$ ls [10:41] blacklist desktop development dns-server doc dvd dvd-live lamp-server live mail-server openssh-server postgresql-server print-server samba-server server server-ship ship ship-live STRUCTURE supported tomcat-server virt-host [10:41] hmm, where do you see that boot seed ? [10:46] lool, grub is a dep of the linux-image-* package on x86 and amd64 [10:47] ogra: That's how I'd expect flash-kernel as well [10:47] i'll file a bug against linux-image-*-imx51 so flash-kernel gets in there, we need a MIR for redboot-tools though [10:48] ogra: The boot seed is in platform.jaunty [10:48] intresting [10:48] ogra: Happy if you do the redboot-tools MIR; I can then review it [10:48] ok [10:48] redboot-imx is still not approved :/ [10:48] i think doko looked at it but didnt even leave comments on the bug [10:49] (its funny that ecos made it but redboot didnt yet) [10:50] I think people are reluctant to touch archive-ish stuff at the dawn of a beta release [10:51] well, we want it in post beta at least [11:01] Bug #348382 [11:01] Launchpad bug 348382 in linux "linux-image-*-imx51 is missing a dependency on flash-kernel" [High,New] https://launchpad.net/bugs/348382 [11:02] ogra: arm tag... [11:03] lool, what about the redboot binary ? do we want flash-kernel to depend on it and overwrite redboot on every flash-kernel run (i assume thats the safest to guarantee the SD is actually bootable) [11:04] genarally on arm systems updating users's bootloader is to be avoided [11:04] well, but we cant be sure the binary is actually in place [11:04] all we see from flash-kernel is the fis table [11:05] which doesnt mean there is a redboot binary [11:05] i was wondering if we can just rely on the presence of redboot once we find a fis table [11:06] i'm not sure we can [11:18] ogra: I think installing redboot is entirely different from flash-kernel's task [11:18] ogra: And isn't needed [11:18] flash-kernel is run on kernel installs and upgrades, and on initramfs creation and updates [11:19] If we need to install redboot, we will need a redboot udeb and a tool to write it, perhaps flash-kernel, perhaps a new one [11:19] Just like install-grub [11:20] s/install-grub/grub-install [11:33] We need an MIR for flash-kernel [11:33] ^- lool ogra [11:33] NCommander, ?? [11:33] its used on nslu2 [11:33] flash-kernel is in universe [11:33] unless someone moved it without me looking [11:34] Correction [11:34] It was promoted two weeks ago [11:34] (er, three) [11:35] we need redboot-tools in main though [11:36] Ugh [11:36] wh yugh [11:36] its tiny enough [11:37] more important is that someone finally approves redboot-imx [11:56] lool, geezy, ubiquity seems to work on the babbage [11:56] it went properly through partitioning and is now in base install [11:56] Cool [11:57] i'm sure it will fail with the last step, but if we can get the rootfs installed properly we can worst case add a howto for setting the SD to do a local boot === Omegamoon is now known as Omegamoon|work [12:29] hmm, ubiquity is at 66% of base install already :) [12:30] though i just noticed i picked the wrong usb key as targe device :/ [12:30] *target [12:30] 2G will not suffice [15:16] dave_m_: http://people.ubuntu.com/~ogra/arm/babbage/ has a recent image with redboot, kernel, desktop live session and all [15:17] sadly my board commits suicide at 80-90% of the install every time [15:18] ogra: are you sure it's not the bug which was affecting persia? [15:18] i'm just trying with shut down syslog [15:18] lets see where that gets me [15:19] ogra, Don't shut down syslog. Just comment out the kern.* line in /etc/syslog.conf, and kill -HUP syslogd. [15:20] persia, that makes /var/log/debug and /var/log/syslog still grow to 1200s of megabytes [15:20] *100s [15:21] so now i'm trying without any syslog and without USB NIC [15:21] its at 60% [15:21] OK. I just had syslog and kern.log. /var/log/debug wasn't so bad. [15:21] I'm at 64% with kern.log commented out right now. [15:21] the same messages go into all three [15:22] i really like the option to attach partitions to the end of the disk [15:22] that makes it easy to keep 20M free space on my target SD [15:22] where i then can install and configure redboot and fis manually i hope [15:24] i also switched to install from SDHC to SDHC now ... std. SD was just to slow [15:49] dave_m_: You might run into https://bugs.launchpad.net/ubuntu/+source/linux/+bug/348504 if installing to USB; happy to hear about your install report [15:49] Launchpad bug 348504 in linux "USB issues with linux-image-2.6.28-11-imx51 fill /var/log" [Undecided,New] [15:50] Not currently trying this, but I'll keep my eyes open... [15:52] ogra, lool: I now have updated RedBoot and the kernel, but it looks like the MMC driver is not built in... it looks like I need an initrd to boot fully. Can someone advise me on how to set up RedBoot to pass the initrd data? [15:54] dave_m_: I can boot fully of the SD card without an initramfs [15:54] dave_m_: Try to add a rootdelay [15:55] lool: Not used that before... it is rootdelay=, or what? [15:56] Yes [15:58] ok [16:03] lool: Seems to be working for me now. No rootdelay= option needed; perhaps I got the root= argument wrong before. [16:10] Good morning [16:10] lool, is there a way to get the live image to use a serial console instead of the framebuffer? [16:10] or does the live image lack a serial getty? [16:10] Martyn: It lacks the serial getty [16:11] poodles [16:12] *grumble* [16:12] that means I'm going to have to poke around the office for a monitor, keyboard .. -sigh- [16:15] Martyn: you can probably add a serial login just by adding an extra file for ttymxc0 in /etc/event.d (using e.g., tty1 as a template) [16:16] dave_m_: It's not trivial to do for the lice image [16:16] *live [16:16] Because it's a read-only rootfs with a ramdisk overlay [16:16] lool: Ah, yes, I see the problem... [16:17] Martyn, we have a way to modify redboot without the need of serial now btw [16:17] lool: Is the rootfs really non-modifiable, or is it just mounted ro by default? [16:18] ogra : yay! the commandline tool works! [16:18] dave_m_: You can't write to squashfs [16:18] dave_m_, its modifiable while it run [16:18] lool: Right, I wasn't sure what type of fs was used. Fair enough. [16:18] yay for unionfs [16:18] aufs :) [16:19] okay, aufs :) [16:20] ogra : where can I snag the new tool? [16:20] its about to enter the archive, but lool made a pre packaged version ... [16:22] https://launchpad.net/~lool/+archive/ppa redboot-tools ... [16:22] we still get ttyfail on the new image? [16:22] thank you lool [16:23] Martyn, depends on your hwclock :) [16:26] ogra : I set the hwclock a while ago though. Shouldn't it be able to survive being unplugged for a day? [16:26] there's a huge honking capacitor or battery on the board, after all [16:28] aw, come ON [16:28] if I go into text mode, none of the tty's will work if the hwclock has reset? [16:28] it doesnt survive more than 10min here [16:28] i -have- to reset it in X? [16:29] Oh, I'm -so- going to go solder in a damned lithium battery to the RTC now [16:29] heh [16:29] because this is frigging annoying [16:29] shrink wrap, two wires, some double sticky tape, and my handy capacitive welder [16:29] this is like the /ninth/ board I've seen from pegatron where they pull this crap [16:29] if i set it once it survives reboots ... if i unplug it goes back to 1970 after a while [16:30] yeah, it means they used a /really/ weak capacitor with a leak characteristic equivalent to a sieve [16:31] and as usual, they don't even provide a couple pins to connect a battery to. "Who would need it?" [16:31] i'll make up a lithium cell battery backup, document the procedure, and make the link available later [16:32] ogra : is there a way to address this in 9.04? It's definitely a bug. [16:32] Even if the date is insane, the getty should spawn >and< authentication should still work. [16:33] file it, its a bug in useradd that it enforces the password to be reset if your system is at 1970 [16:35] so the bug is in useradd and not in the PAM configuration? [16:38] Filed [16:38] or not? 500 error [16:41] why does the useradd bug cause tty to fail? [16:41] or the RTC clock being wrong? [16:44] useradd creates the autologin data during boot ... the second field in /etc/shadow is zero [16:44] *snarl* [16:44] which enforces that you should update your pw immediately [16:44] the ttys on the livesystem all use autologin [16:44] right, which snarfs login, and the tty's spin [16:44] which fails if the pw needs to be updated [16:44] right [16:47] Okay, I think I have a fix for the wonky network driver [16:48] if you file a bug for it and attach a patch we can get it included by the kernel team [16:48] should the bug be filed against mx51/kernel? [16:48] linux [16:48] mention imx51 in the description and add an arm tag [16:49] will do. I'm going to stress test the solution for a couple hours to see if I get lockups [16:55] asix diver works nicely now :) [16:56] but my patch makes the internal nic work too slowly [16:59] lool: Now I have the kernel working, I am seeing the ludicrously enourous amount of usb-storage debug you mentioned... Is there a way to turn this off without rebuilding the kernel? [17:04] dave_m_, I've been advised that it would be difficult, and have edited syslog.conf to reflect my desire for significantly less information to be saved to disk (commented out the kern.log and debug.log sections). [17:04] Mind you, one needs to do this *each boot* with the live environment, which is a bit annoying. [17:05] persia: Is the debug enabled on all architectures? This seems excessive for a production kernel... [17:05] dave_m : Won't they be turning that off in the final build? [17:05] Could be... wasn't sure whether a further rebuild was proposed. [17:05] I'm still looking for a way to disable the SCSI detection at boot. Costs 50 seconds for nothing. [17:05] But it makes sense. [17:06] dave_m_, No. As far as I can tell, it's just for armel. [17:06] I understand a new kernel is planned without the messages, but likely not until after the Beta release. [17:06] persia: No problem [17:06] that makes sense [17:07] Okay, I've corrected the error in the fec / SMSC LAN8700 code [17:07] Martyn: I'm not seeing the big SCSI detection delay, have you got something unusual plugged in? [17:07] I'm going to leave my tests running for a couple hours. If I see no errors, I'll submit the patch [17:08] dave_m : Nothing's plugged in at all, but the board has a USB->SATA on the motherboard [17:08] so it sits there and tries to detect a disk that isn't there. [17:08] too bad the live image doesn't pay attention to "noscsi" [17:09] Hmmm, I've got a disk plugged in there, but I haven't usually seen it actually wait even when nothing was plugged in. This sounds like a bug somewhere. [17:09] Martyn, can you subscribe (not assign) me to the bugs you file ? [17:10] fec.c is a bit of fail [17:10] absolutely [17:10] Just right now I got a 500 server error when trying to file a bug. [17:10] I'll look at it again when I come back from a trip to the computer store (Fry's) [17:11] <-- ran out of ethernet cable. [17:13] Martyn: Is your network bug causing really slow throughput? [17:18] dave_m_, That sounds like bug #348333 [17:18] Launchpad bug 348333 in linux "armel/imx51: Poor ethernet behavior with 2.6.28" [Undecided,New] https://launchpad.net/bugs/348333 [17:19] I may stick with FSL's 2.6.26 until this is resolved... network throughput appears 20-50x faster for me [17:20] ...so long as it's being dealt with in the meantime. [17:21] dave_m_: If you don't have an USB ethernet adapter, I recommend you do indeed [17:21] It's at least reported. Some people report that using a USB network adaptor works around it: it seems related specifically to the onboard adaptor. [17:22] lool, persia: In general, the new kernel seems fine though. I thought I ought to give it a try. [17:23] dave_m_: It works ok for me in, but then I use that ethernet usb adapter and I don't use usb storage [17:23] ogra: To clarify, the target install we discussed was not really SD card in an USB reader [17:23] ogra: We came back to this after the call on boot options [17:24] lool, oh [17:24] ogra: The target install scenario is to use the install SD card as install media *and* as the place to host kernel and initrd and all [17:24] ogra: That is, use the redboot partition with fis data, config and all from the install SD card to boot the installed system [17:24] so only modify the cmdline with fconfig then [17:24] So the SD media is destroyed [17:24] I've subscribed to https://launchpad.net/bugs/348333; I'll probably switch to this kernel when this issue has been sorted [17:24] Launchpad bug 348333 in linux "armel/imx51: Poor ethernet behavior with 2.6.28" [Undecided,New] [17:25] ogra: Yes, and install target kernel and initramfs [17:25] lool, fine with me, makes the howto a lot shorter [17:25] ogra: *however* I think installing to a SD card in an USB reader is an useful option, so if you like to document how to achieve it, that's welcome [17:25] well, i'd only modify the cmdline then [17:25] the install kernel and initramfs wont differ [17:25] Yes they will. [17:26] If nothing else, the installed initramfs won't contain casper. [17:26] not in functionallity [17:26] just in size [17:26] Well, size and content, but yes. [17:26] so highest priority: make sure we have an installer an a howto which covers install to anything + boot from install SD [17:26] as son as you drop boot=casper it will behave the same [17:26] right [17:26] And lower priority: have another guide for people who want to create an autonomous SD card [17:26] An installed one that is [17:26] yep [17:27] i'll do the latter post beta ... the former tonight [17:27] ogra: The install kernel will differ in that they will be generated from the installed system; typically after release you might get an updated kernel which has security updates [17:27] i just need to confirm the preseeding works, then i'll change the script and roll the final image [17:27] lool, we dont even have flash-kernel in beta [17:28] we can have all that for final [17:28] but beta will be different [17:28] ogra: All my arguments are for final and are what I would aim at for beta; I prefer looking at our release target and making concessions than looking at we can do now, and have to redo everything for final [17:29] For instance I don't mind instructions which tell you to use a PPA or to disable syslog or whatever for beta [17:29] for now my howto will be: install with ubiquity (working around the known bugs) ... install redboot-tools ... modify cmdline of SD [17:29] If that gives an installation experience which works technically like the final one will, but with extra steps [17:29] That's ok [17:29] right [17:30] for final some of that will be automated anyway by flash-kernel [17:30] Yes [17:30] ogra: One thing I didn't look into is who's responsible for setting the installed system to run flash-kernel [17:31] the linux-image package [17:31] oh, wait, you mean kernel-img.conf settings i guess [17:31] hmm [17:32] could we make flash-kernel postinst do that ? [17:32] i dont think kernel-img.conf is a conffile of any sort so a maintainer script could add it if its missing [17:34] Isn't that what flash-kernel-installer does? [17:34] whats flash-kernel-installer ? [17:34] * ogra never heard of it [17:35] is that a udeb ? i cant find it in apt-cache [17:35] Yes, it's a udeb. [17:36] ah [17:36] It consist primarily of a postinst that checks the subarchitecture, and maybe does stuff to make flash-kernel work. [17:36] s/consist/consists/ [17:36] persia: it is [17:37] yeah [17:37] its postinst writes kernel-img.conf [17:37] lool, OK. Then for alternates, we just need to have flash-kernel-installer in the initrd, which is done. For the live images, we need to have the relevant logic be performed during the ubiquity run. [17:38] I need to look at flash-kernel-installer a bit more, but I think that's just creating a component to drive it, and running that component out of install.py. [18:36] does anyone know how to get ahold of dave mandala? I met him @ the Canonical Booth @ SCALE and talked to him about making update-manager-core available for non-supported old releases available so that we could easily upgrade. [18:43] ka6sox-work, he is usually around here, might be in a meeting or so, just idle here for a while [20:17] re [20:17] The driver edit didn't work. I got a full lockup of the fec [20:18] Rx stops receiving packets. [20:26] dreck, I'm getting "no route to host" when trying to hit ports.ubuntu.com [23:22] hey guys [23:23] where I can download ubuntu-ARM source code? [23:24] it's opensource? [23:25] Hello? === Guest94492 is now known as _Carlo_ [23:28] _Carlo_: It's the ubuntu source code, it's at archive.ubuntu.com [23:29] <_Carlo_> witch folder? [23:30] <_Carlo_> dists -> indices -> poll -> project [23:40] _Carlo_: Perhaps you should start with the ubuntu wiki [23:40] * lool => bed & [23:45] <_Carlo_> or you tell me where I get