**** BEGIN LOGGING AT Sun Jul 10 23:59:57 2005 Jul 11 01:25:17 uhm.. Jul 11 01:25:18 ( cd bitbake ; svn "-r 269" update ) Jul 11 01:25:18 svn: Syntax error in revision argument ' 269' Jul 11 01:25:18 make: *** [update-bitbake] Error 1 Jul 11 01:25:55 I get that too. Jul 11 01:26:05 my stopgap is comment out that first line in the makefile. Jul 11 01:26:42 279 worked for me Jul 11 01:26:43 yeah, thought that, but, they said there was something wrong with later revisions.. Jul 11 01:26:51 hm.. ok.. Jul 11 01:26:57 272 has problems which I experienced Jul 11 01:27:05 when I updated to 279 my build completed Jul 11 01:27:25 the real solution is to unquote it, which I'll do in a moment... Jul 11 01:28:23 r279 work for me too. Jul 11 01:30:37 "At revision 285.", seems to work too.. Jul 11 01:37:40 Okay, its repaired. Jul 11 01:38:18 <[g2]> dyoung, morning sunshine Jul 11 01:38:24 morning sunshine. Jul 11 01:38:40 <[g2]> you guys are busy today :) Jul 11 01:38:53 I didnt do anything today. Jul 11 01:39:10 <[g2]> dyoung org.nslu2-linux.dev * r1972dc78... /Makefile: Fix the bitbake fixing line Jul 11 01:39:22 <[g2]> your evil robot twin ? Jul 11 01:39:26 that was a courtesy fix. :-) Jul 11 01:39:57 <[g2]> and the nfs-utils fix ? Jul 11 01:40:04 that wasnt me Jul 11 01:40:12 that was jbowler. Jul 11 01:40:41 <[g2]> nod. Jul 11 01:40:49 <[g2]> but who put it in there ? Jul 11 01:41:08 He did I believe... Jul 11 01:41:24 It worked on my end! Jul 11 01:41:38 * NAiL goes screaming and kicking Jul 11 02:15:36 NAiL: ok, now I can probably go to the window and wave to you :) Jul 11 02:22:16 hm.. r285 didn't work, but with the fixed makefile and r269 everything is ok Jul 11 02:23:15 I could probably send up a rocket that you can see from your window... with a large telescope Jul 11 02:33:45 hihi Jul 11 02:33:54 feel free.. :) Jul 11 05:47:19 kolla_: ok, what if I launch this: http://david.thg.se/bilder/raket/ Jul 11 09:28:18 heya. after turnup memstick -i /dev/sda1 and rebooting the device is supposed to boot with /dev/sda1 as root, isn't it? Jul 11 09:28:39 <[g2]> mickeyl, nod Jul 11 09:28:43 hmm Jul 11 09:28:48 <[g2]> you formated /dev/sda1 right ? Jul 11 09:28:50 ok, then the quest is why doen't it here Jul 11 09:28:59 yes. /dev/sda1 formatted as ext2 Jul 11 09:29:23 <[g2]> are you serial enabled ? Jul 11 09:29:34 unfortunately not. my serial cable is still in the mail Jul 11 09:29:58 mickeyl: does it not boot, or does it boot with some other rootfs? Jul 11 09:30:22 jbowler-zzz: it boots, but with mtdblock4 as rootfs Jul 11 09:30:57 would pastebin'ing dmesg help? Jul 11 09:31:15 It might Jul 11 09:31:38 http://pastebin.ca/17457 Jul 11 09:31:55 Check the /linuxrc - it should contain a couple of lines, post the first 'exec' line. Jul 11 09:32:17 exec '/boot/disk' '/dev/sda1' '-t' 'ext2' '-o' 'noatime' Jul 11 09:32:59 Ok, try "mount -t ext2 -o noatime /dev/sda1 /mnt" - see if the rootfs is in there... Jul 11 09:33:25 oops Jul 11 09:33:25 root@sluggy:~# mount -t ext2 -o noatime /dev/sda1 /mnt Jul 11 09:33:26 mount: Mounting /dev/sda1 on /mnt failed: No such file or directory Jul 11 09:33:42 hmm guess i broke this usb stick Jul 11 09:33:44 * mickeyl investigates Jul 11 09:34:08 Not necessarily, it may not be at /dev/sda any more if there is something else in the USB ports. Jul 11 09:35:06 No, it's not that - from your dmesg: Jul 11 09:35:10 usb-storage: device found at 3 Jul 11 09:35:10 usb-storage: waiting for device to settle before scanning Jul 11 09:35:11 Vendor: Yakumo Model: Quicksave 2.0 Rev: 1.00 Jul 11 09:35:13 Type: Direct-Access ANSI SCSI revision: 00 Jul 11 09:35:15 SCSI device sda: 512000 512-byte hdwr sectors (262 MB) Jul 11 09:35:34 fdisk reports one primary partition Jul 11 09:35:45 |/dev/sda1 1 1015 255779+ 83 Linux Jul 11 09:35:59 hmm looks good so far Jul 11 09:36:02 but i can't mount it Jul 11 09:36:10 * mickeyl formats again Jul 11 09:36:13 The only thing I can see in the dmesg is some 'sense key' errors. Jul 11 09:36:38 aah i see somthing Jul 11 09:36:49 that usb stick has an internal hub Jul 11 09:36:53 (oddly enough) Jul 11 09:36:57 would that confuse the device? Jul 11 09:37:42 I think if fdisk sees it ok it shuld not, what does /proc/partitions have to say? Jul 11 09:38:11 8 0 256000 sda Jul 11 09:38:11 8 1 255779 sda1 Jul 11 09:38:44 oops Jul 11 09:38:44 heh Jul 11 09:38:49 there's no /mnt Jul 11 09:38:51 that's why the mount failed Jul 11 09:38:58 mount -t ext2 -o noatime /dev/sda1 /media works Jul 11 09:39:20 Urgh, what happened to /mnt... Jul 11 09:39:33 Is there a /initrd? Jul 11 09:39:45 yes, but it's empty Jul 11 09:40:40 Either /initrd or /mnt (if /initrd does not exist) is used to pivot_root into the real rootfs on boot. There may be some problem with no /mnt. Jul 11 09:40:51 Can you check /media/.recovery (i.e. check if it exists?) Jul 11 09:41:44 Ok - no, /mnt must exist... Jul 11 09:42:05 OE changed to /media some months ago to be consistent with lsb Jul 11 09:42:13 we have /mnt as symlink to /media though Jul 11 09:42:19 i wonder where that has gone Jul 11 09:42:38 Line 26 of /boot/disk: if mount "$@" "$device" /mnt Jul 11 09:42:54 ah of course. ok let me see what happens when i recreate the symlink Jul 11 09:43:48 There's quite a lot of stuff in openslug which assumes that /mnt will exist as a temporary mount point. Jul 11 09:44:25 here we are Jul 11 09:44:34 root@sluggy:~# mount Jul 11 09:44:44 | /dev/sda1 on / type ext2 (rw,noatime) Jul 11 09:45:06 thanks Jul 11 09:45:31 * mickeyl adds ipkg sources Jul 11 09:45:44 mickeyl: Was that using your own file system hierarchy, not the openslug one? Jul 11 09:46:34 jbowler-zzz: no, that was an openslug-2 beta binary. however... i played with it until deep in the night... so ... perhaps I removed /mnt for some reason ... *shrug* :) Jul 11 09:47:00 i tend to do strange things when I'm overtired Jul 11 09:47:00 heh Jul 11 09:47:08 ok - just worried that turnup memstick might delete /mnt Jul 11 09:48:05 the turnup thing is a nice frontend for administrative tasks. is that an openslug idea or did linksys do something similar? Jul 11 09:49:09 someone else had the same problem last night iirc Jul 11 09:49:14 [g2] wrote the initial version as a way to document how to get a bootable disk Jul 11 09:50:19 I tried to capture all the stuff specific to getting a workable system in there - it's not really a general admin interface. LinkSys stuff is all via a web interface (and is general admin). Jul 11 09:52:48 i see. it's definitly handy. i reckon the openslug team is not really interested in recreating the web interface :) Jul 11 09:53:05 guess that's what unslung is for Jul 11 10:02:20 <[g2]> mickeyl, actually I think a web interface will probably be provided for end users. Jul 11 10:02:49 <[g2]> it's just the highest priority by a long shot Jul 11 10:02:57 <[g2]> s/just/just not/ Jul 11 10:03:05 yeah sure Jul 11 10:03:36 <[g2]> I think we are at the point we can have our first non-Beta release Jul 11 10:07:12 <[g2]> mickeyl, BTW jbowler-zzz is being way too modest about the turnup/devio sw. The original was a 12-15 line shell script Jul 11 10:07:39 hehe. that's common behaviour for us open source architects :) Jul 11 14:01:49 is it normal that the kernel reports 1.0 average load when the `nslu2 is idle? Jul 11 14:01:57 2.6.11.2 here Jul 11 14:03:20 well, same here on 2.6.12.2 Jul 11 14:03:47 <[g2]> mickeyl, yes Jul 11 14:04:38 <[g2]> that doesn't make it "right" just normal :) Jul 11 14:04:49 yeah. that's what i was supposing :) Jul 11 14:04:58 oh and also i got a kernel oops Jul 11 14:05:06 but it looks like it's continuing to work Jul 11 14:05:17 <[g2]> irq_26: nobody cared ? Jul 11 14:05:24 *nod* right after that Jul 11 14:05:50 <[g2]> we've got 2 real significant issue Jul 11 14:05:52 i read about the irq26 but didn't know about an oops following Jul 11 14:06:15 <[g2]> what's the oops ? Jul 11 14:06:44 <[g2]> That's one significant issue the irq:26 Jul 11 14:06:54 http://pastebin.com/311495 Jul 11 14:07:04 <[g2]> Lennert may be on the hunt on the irq:26 issue Jul 11 14:07:41 hmm... i'm surprised that we don't get kernel symbols. I thought kernel 2.6 enables these by default Jul 11 14:07:44 <[g2]> the other is shutdown -r from the memstick/disk doesn't always seem to work, there may be chip eratta related Jul 11 14:10:37 uhm.. no inetd or xinetd in openslug? Jul 11 14:12:04 <[g2]> DaKa2, not right now Jul 11 14:12:29 anyone fixing that, or should I? Jul 11 14:12:39 any problem with them? Jul 11 14:13:20 <[g2]> not that I'm aware of. It's just we haven't gone quite that heavy weight yet Jul 11 14:13:46 ok, Ill see if I can whip up an xinetd package Jul 11 14:14:54 <[g2]> I think we may have to make some decisions about what we want to support out-of-the-box Jul 11 14:15:26 ok, should I wait? Jul 11 14:15:55 <[g2]> currently, it's very minimal Jul 11 14:30:26 DaKa2: It won't hurt if you add the package. Whether or not it'll be included in the default build is another thing ;) Jul 11 14:31:40 sounds good, ill see if it works Jul 11 15:38:28 <[g2]> beewoolie-afk, near keyboard ? Jul 11 17:10:46 NAiL: alive? Jul 11 17:11:32 barely Jul 11 17:11:34 ;) Jul 11 17:11:47 :) ahh, well.. you feel like adding a package? Jul 11 17:11:54 :) Jul 11 17:12:08 xinetd? Jul 11 17:12:11 yup Jul 11 17:12:50 last thing to make scanner server working Jul 11 17:13:00 http://david.thg.se/saker/xinetd.tar.gz Jul 11 17:14:10 was writing a howto for saned, and noticed there was no inetd, at all... Jul 11 17:15:59 well, inetd exists in netkit-base Jul 11 17:16:16 added it Jul 11 17:16:21 :) Jul 11 17:16:31 thank you :) Jul 11 17:16:47 <[g2]> jbowler-zzz, ping! Jul 11 17:16:48 should probably get some sleep now, bbl Jul 11 17:16:51 thank you. You're the one doing work ;) Jul 11 17:17:00 :)) Jul 11 17:19:42 <[g2]> rwhitby, have you used reflash ? Jul 11 17:21:26 yes Jul 11 17:21:41 <[g2]> I just tried with the -i Jul 11 17:21:51 yep, that's what I used Jul 11 17:22:16 <[g2]> but it appears that the kernel modules and deps didn't make it to the memstick Jul 11 17:23:22 <[g2]> hmmm... Jul 11 17:23:28 <[g2]> looks like a bad kernel build Jul 11 17:23:41 <[g2]> the ixp drivers are in 11.2 :( Jul 11 17:23:50 <[g2]> but the kernel is 12.2 Jul 11 17:24:03 yep, when you change kernel versions, you need to clean and rebuild the ixp modules Jul 11 17:24:24 we need to automate that somehow, as it gets me every time too Jul 11 17:24:35 <[g2]> amen to the automate that Jul 11 17:26:03 dunno how to automate that though. I guess we could just manually bump the PR on the ixp packages whenever we change kernel versions .... Jul 11 17:26:13 any reason why the OE built cross compiler disables threads? My old version (gcc-3.4.3) had full pthreads enabled. Jul 11 17:27:27 <[g2]> rwhitby, I wonder if there's a hook the could trigger a clean of ixp425-eth and ixp4xx-csr when there's a new rev level, like maybe in the do_fetch or something ? Jul 11 17:27:59 trouble is that it wouldn't get rebuilt in that same bb run, as all the bb stuff is worked out ahead of time Jul 11 17:30:01 OK, I'm bumping the ixp PRs Jul 11 17:32:25 rwhitby: rsyncing now, probably done in a minute or two. Going to sleep Jul 11 17:32:54 sent 3460458 bytes received 45318 bytes 57946.71 bytes/sec Jul 11 17:32:54 total size is 164626321 speedup is 46.96 Jul 11 17:34:23 rwhitby: satisfied? =) Jul 11 17:34:30 NAiL: can you push the new IXP modules too ? Jul 11 17:34:37 (CIA should report them soon) Jul 11 17:34:47 You bumped the rev after the build finished Jul 11 17:34:51 yep Jul 11 17:35:54 There's two heads, btw Jul 11 17:36:44 and apparently, one cannot fix that without a key? Jul 11 17:36:45 monotone: trying 3-way merge Jul 11 17:36:45 monotone: misuse: no unique private key for cert construction Jul 11 17:37:20 fixing now Jul 11 17:39:50 guess I need to make the push target do a merge first Jul 11 17:40:05 or do a pull, then merge if necessary, then push Jul 11 17:40:20 should be merged now Jul 11 17:40:23 yes, that is actually a very good idea Jul 11 17:44:54 rwhitby: pushing now Jul 11 17:44:58 done Jul 11 17:46:53 * NAiL goes to sleep Jul 11 17:47:17 night NAiL Jul 11 17:47:20 thx Jul 11 17:55:01 rwhitby, [g2] - I couldn't think of any way of fixing the ixp problem (I hit it too)... Jul 11 17:55:54 <[g2]> we might want to put a check in the openslug-image build that fails if the ipx and kernel aren't the same versions Jul 11 17:56:35 <[g2]> then it'd stop one from the reflash part Jul 11 17:56:49 I think maybe we don't want to push either kernel or modules into the feed. Jul 11 17:57:09 ipkg upgrade will certainly make a disk unbootable because it removes the old modules. Jul 11 18:00:20 <[g2]> hmmm... looks like the drivers didn't get copied :( Jul 11 18:02:01 <[g2]> jbowler-zzz, do you have to re-turnup after the reflash ? Jul 11 18:02:27 No, but if you reflash a different kernel you can be sure it won't boot. Jul 11 18:02:34 jbowler-zzz: I like having kernel and modules in feed Jul 11 18:02:57 <[g2]> is the ixp stuff in the feed ? Jul 11 18:03:21 yep. to get the binary firmware which accesses the feed, you have clicked through the license already Jul 11 18:03:41 and if you built it yourself, you have accepted the license too Jul 11 18:05:22 and since you can access the file on the Intel site without actually clicking through the license, then if it's good enough for Intel to only have the web-based route to the software click-through-enabled, then it's good enough for us too :-) Jul 11 18:06:32 modules in the feed (and kernel) would be fine if the old ones weren't removed - or, to be more precise, if x.y.z/... was not removed when x.y.z+1/... is installed. Jul 11 18:07:20 maybe do a kernel modules postinst which does a chmod u-w on them :-) Jul 11 18:07:29 Then everything would work fine - before and after reflash -i. As it is if you don't do both ipkg upgrade then (immediately) reflash -i the system will probably be broken. Jul 11 18:08:01 Maybe go in and echo "" into the relevant ipkg (list) file... Jul 11 18:08:35 although if you follow instructions and run reflash, then you don't want the old ones lying around. Jul 11 18:09:01 <[g2]> ok... so let me see if I've got this straight Jul 11 18:09:02 if opensluggers can't follow instructions to run reflash after a kernel update, then they should be running unslung instead :-) Jul 11 18:09:08 I guess it would be possible to install an init.d script to remove them Jul 11 18:09:22 Ah, well, I'm complaining about it because I forgot and rebooted... Jul 11 18:10:11 <[g2]> a -i replaces the kernel and jffs2 and preserves the files to the jffs2 ? Jul 11 18:10:21 Yes. Jul 11 18:10:47 <[g2]> but id doesn't update the external devices at all Jul 11 18:10:51 <[g2]> but it Jul 11 18:11:04 jbowler: is there a way we can access the config file saving stuff in reflash? I'd like to be able to make that part of a turnup-upgrade style workflow Jul 11 18:11:05 Correct Jul 11 18:11:42 <[g2]> rwhitby, look at /etc/default/connfiles Jul 11 18:11:43 e.g, a turnup overwrite saves the configs, then copies rootfs, then restores configs (on the target drive) Jul 11 18:11:47 rwhitby: do you want 'reflash --preserve' which just saves the config? Jul 11 18:12:13 oh, ok, that should be easy. Jul 11 18:12:13 not sure whether I want that, or whether I want a turnup -i -f --preserve Jul 11 18:13:08 the idea being that you can do things one of two ways: Jul 11 18:13:26 1) whilst running on external disk, do an ipkg upgrade and reflash Jul 11 18:13:35 Yes, I think just a matter of moving the two blocks of code out of reflash into /etc/default/functions Jul 11 18:13:48 2) get into upgrade mode, reflash using upgrade tool, then turnup -i -f --preserve Jul 11 18:14:07 and get the same result via either method Jul 11 18:14:47 Right. The reason it won't work is that the reflash stuff doesn't preserve enough of the ipkg config. Jul 11 18:15:47 /usr/lib/ipkg/... needs to be merged in some horrible way. Jul 11 18:16:42 It's tempting to try just 'turnup disk -i -f ...' and see what happens, but I think any installed packages will become magically 'deinstalled' Jul 11 18:17:43 Hmm - yes, that is a fly in the ointment. Jul 11 18:17:55 It doesn't matter on /dev/mtdblock4 because the reflash removes any extra installation (this might be a little unexpected...) Jul 11 18:17:58 the status file is the problem Jul 11 18:19:06 <[g2]> BTW the ixp modules are not in the ipk list by default Jul 11 18:19:15 I'm hoping I can think of a way for 'ipkg upgrade' to just work, even across kernel upgrades. I think that's easier... Jul 11 18:19:43 <[g2]> jbowler, I'm with you there Jul 11 18:19:54 <[g2]> I think an APEX version will work like that Jul 11 18:20:01 <[g2]> for the most part Jul 11 18:20:15 [g2]: the ixp modules are in the status file, and they are installed in the rootfs image. Jul 11 18:21:10 <[g2]> then an upgrade will never work for them right ? Jul 11 18:21:24 It works fine if the PR is bumped. Jul 11 18:22:02 <[g2]> so how do those files get propagated to the external device without a turnup or explicit copy ? Jul 11 18:22:23 ixp modules are in the feed Jul 11 18:22:57 ipkg upgrade will upgrade the kernel, the installed modules and the ixp modules (the latter only if the PR is bumped). Jul 11 18:23:47 <[g2]> ok... so the ipkg's are driven by the PR rev level Jul 11 18:23:47 It would be possible to make the ixp ipks named after the kernel, but that would require a bit of python hackery. Jul 11 18:24:21 jbowler: that would be the best solution Jul 11 18:24:27 <[g2]> this should be cool... removing and reinstlling those on a live system :) Jul 11 18:24:50 [g2]: no problem - kernel modules are locked into ram and never swapped to disk Jul 11 18:25:14 <[g2]> rwhitby, I know... I *still* think it's cool! Jul 11 18:25:18 No problem so long as they have all been loaded beforehand... Jul 11 18:25:31 <[g2]> yes they are running :) Jul 11 18:27:01 One way of making it all safer is to (cd /lib/modules; ln -s /initrd/lib/modules/* . 2>/dev/null) Jul 11 18:27:21 That doesn't quite work though because ipkg leaves the directories there. Jul 11 18:34:47 I need to think about this some more. It seems clear that the ixp* builds a broken, because there is code in modules.bbclass to prepend the kernel version number and it doesn't happen to the ixp modules. Jul 11 18:47:23 <[g2]> jbowler-away, rwhitby THX for all the help and ideas Jul 11 18:48:39 * [g2] will have to noodle a little more on this also **** ENDING LOGGING AT Mon Jul 11 23:59:57 2005