**** BEGIN LOGGING AT Thu Jun 23 23:59:56 2005 Jun 24 04:52:50 cool. I did not realize there was a separate channel for the openslug :) Jun 24 04:53:16 <[g2]> it's much quieter over here :) Jun 24 04:54:00 So how is the testing of the new kernel going on? Jun 24 04:54:49 <[g2]> openslug kernel ? Jun 24 04:55:00 <[g2]> you mean 2.6.12 ? Jun 24 04:55:27 <[g2]> I think jbowler's been running it Jun 24 04:55:52 <[g2]> I ran 12-rc5 and 12 for a little while Jun 24 04:56:18 <[g2]> the serial messages don't come out while the kernel is booting so I haven't switched over to it Jun 24 04:56:39 <[g2]> I haven't tracked down that problem or seen the fix for it yet Jun 24 04:56:57 Oh yes, I remeber reading about the serial device name problems Jun 24 05:00:41 <[g2]> I think I saw a little something about that too but I haven't tracked it all down Jun 24 05:15:26 g2: I am trying to follow your docs for swap over nfs. I get the following error when doing losetup: Jun 24 05:15:28 root@LKG7F6525:/# losetup /mnt/swap/swapfile /dev/loop0 Jun 24 05:15:28 losetup: ioctl: LOOP_SET_FD: Inappropriate ioctl for device Jun 24 05:15:38 any ideas? Jun 24 05:16:31 <[g2]> do you have the loop module ? Jun 24 05:16:39 yes, it is loaded Jun 24 05:16:53 <[g2]> which OpenSlug ? Jun 24 05:16:56 root@LKG7F6525:/# lsmod Jun 24 05:16:56 Module Size Used by Jun 24 05:16:56 loop 8296 0 Jun 24 05:16:57 nfs 74380 2 Jun 24 05:16:57 lockd 44824 2 nfs Jun 24 05:16:58 sunrpc 97184 5 nfs,lockd Jun 24 05:16:59 af_packet 11560 0 Jun 24 05:17:01 ixp425_eth 15492 0 Jun 24 05:17:03 ixp400 614600 1 ixp425_eth Jun 24 05:17:29 hmm, a custom build from 20050613 Jun 24 05:18:19 the only difference is that I am not having a nfs exported dev, but I kept the ramfs Jun 24 05:22:23 the loopback module is from:kernel-module-loop_2.6.11.2-r10_nslu2.ipk Jun 24 05:22:42 <[g2]> I'd guess that would be fine Jun 24 05:24:00 <[g2]> hanjo, let me try setting that up with my current setup Jun 24 05:24:54 <[g2]> were you the guy that did a the deploy of some units ? Jun 24 05:26:39 yes, I have 50-slug testbed Jun 24 05:27:31 <[g2]> way cool Jun 24 05:27:53 <[g2]> how testing going ? Jun 24 05:27:58 <[g2]> how's Jun 24 05:27:59 I found the errror Jun 24 05:28:09 losetup /mnt/swap/swapfile /dev/loop0 Jun 24 05:28:21 the arguments shoud be the other way around Jun 24 05:29:04 well testing is doing good. I have been running the network for a month or so using static IP assignments and separate nfs roots for each slug Jun 24 05:29:16 but it turned to be an administration nightmare Jun 24 05:29:43 <[g2]> really ? Jun 24 05:30:31 <[g2]> before I get you side tracked Jun 24 05:30:35 So for the last 10 days I am fighting with turnup, unionfs and nfs to create a shared root setup where all the slugs are sharing the common files (ro) Jun 24 05:30:54 <[g2]> losetup /dev/loop0 /mnt/swap/swapfile Jun 24 05:30:56 plus per slug (rw) for the specific files Jun 24 05:31:01 <[g2]> that worked ? Jun 24 05:31:03 yes that works Jun 24 05:31:07 <[g2]> cool Jun 24 05:31:13 at least /proc/meminfo says so Jun 24 05:31:22 <[g2]> :) Jun 24 05:31:28 <[g2]> sorry about the confusion Jun 24 05:31:42 no prob Jun 24 05:31:50 tnx for the info Jun 24 05:31:55 <[g2]> np Jun 24 05:32:12 anyhow, this unionfs thing works almost well Jun 24 05:32:47 but there are consistency problems when I change the shared root on the server from beneath the union. Then nfs gets confused and locks the slugs Jun 24 05:32:50 <[g2]> excellent Jun 24 05:33:27 <[g2]> the stuff before the lockup is the excellent stuff :) Jun 24 05:33:52 so I have to detach the exports, purge unionfs cache, then reattach to make it work. The unionfs guys are working on a "persistent inodes" feasture that will address this. Shoud be available in a month or so Jun 24 05:34:15 <[g2]> super Jun 24 05:34:23 So this setup plus ipkg-cl in offline mode is the way I plan to address the administration issue Jun 24 05:34:24 <[g2]> so is 32MB getting cramped ? Jun 24 05:35:39 <[g2]> I'm curious about the admin issues Jun 24 05:35:39 Well, I don't have many demanding applications, but since I have /dev and /var left on the slugs in tempfs, I wanted to have swapfs as backup in case some process goes mad and fills up the /var Jun 24 05:35:57 <[g2]> nod. Jun 24 05:36:28 Well it was a pain to log into 50 slugs and start ipkg to get them in consistent state Jun 24 05:36:39 <[g2]> From the admin side, I'd think the default image would dhcp Jun 24 05:36:42 i.e. a script was doing that, but nontheless Jun 24 05:37:01 the one I have defaults in static Jun 24 05:37:23 I had a chat with jbowler and he said that he will change it to dhcp as default on the first boot Jun 24 05:37:38 <[g2]> right. but I was thinking that each slug could register first then get it's static IP Jun 24 05:38:02 <[g2]> I'd think, the IP, and keys Jun 24 05:38:22 That works ok, once I chage the sysconf Jun 24 05:38:49 I keep the hostname, keys, etc. on the perslug exported dirs Jun 24 05:40:01 <[g2]> that makes sense Jun 24 05:41:07 the only remaining problem apart from the unionfs caching is that ipkg-cl when executed in the server in offline mode with offline root being the shared nfs root, does not execute the postinstall scripts in the packages Jun 24 05:41:08 <[g2]> so on the first dhcp, the unit could the be contacted and updated with it's per unit mount Jun 24 05:42:43 Well, I have modified the turnup nfs -i script a bit, so insted of copying the whole root it just puts the slug specific files. Then this dir is fused with the shared nfs root to create the new root for the slug Jun 24 05:45:10 <[g2]> what does the ipkg-cl buy over just having the ipkg point to a local package repo on the per slug nfs mount ? Jun 24 05:45:33 <[g2]> src .... file://nfsmount/.... Jun 24 05:46:46 <[g2]> or if all the slugs are running the same package builds it could be on the main rootfs Jun 24 05:46:58 nothing, It just keeps all actions on the server side. But even with that, the postinstall scripts are only going to be executed on this slug Jun 24 05:47:06 Ok, I lost you there Jun 24 05:48:09 what can be on the main rootfs? Jun 24 05:48:37 <[g2]> your package repository if it's the same for all the slugs Jun 24 05:49:14 I thought you were suggesting to execurte a normal ipkg install from one of the slugs Jun 24 05:49:22 <[g2]> I was Jun 24 05:49:29 yes, the repository is the same Jun 24 05:51:08 <[g2]> Ok...so if the repo of built ipks is available on the rootfs (via nfs/unionfs) what over the normal ipkg utilization is needed ? I'm missing that Jun 24 05:52:19 <[g2]> sorry I'm not familiar with ipkg-cl to know its benefits Jun 24 05:52:37 ipkg-cl is just native version of the ipkg Jun 24 05:52:55 both approaches give me problems with the postinstall part of the packages Jun 24 05:53:08 if I do it on the server, the postinstall part is not executed at all Jun 24 05:53:44 if I do it via one of the slugs, the postinstall will be executed only on that slug, leaving the rest just as before Jun 24 05:54:14 So I choose the first option, since I can do everything from the server, without loging onto the slug Jun 24 05:55:03 <[g2]> Ok, thanks for all the info and help Jun 24 05:55:16 <[g2]> I've been thinking about the problem in a different way Jun 24 05:56:14 no prob. Sorry for bothering you with my troubles :) Jun 24 05:56:35 <[g2]> actually it's a great help not a problem at all Jun 24 05:57:19 <[g2]> i've been thinking about 2 different roll out issues Jun 24 05:57:26 <[g2]> 1 a generic one Jun 24 05:57:52 <[g2]> and the second a specific 1-time config issue Jun 24 05:59:04 <[g2]> for the first, the key for the box would be able to identify it's current expected configuration Jun 24 05:59:23 <[g2]> and the system would know how to update it's config accordingly Jun 24 05:59:45 <[g2]> all though scp Jun 24 06:00:33 does it have to be over secured link? Jun 24 06:00:41 <[g2]> I the second, all the boxes have a starting image and then wake up to find out there new idendity and purpose as a machine Jun 24 06:00:57 <[g2]> no it doesn't really Jun 24 06:01:19 <[g2]> but I'd either be on a very secure / closed network or do it securely Jun 24 06:01:51 I understand option 2, option 1 is not so clear to me Jun 24 06:02:31 <[g2]> option 1 would be for a generic managed sevice Jun 24 06:02:34 <[g2]> option 1 would be for a generic managed service Jun 24 06:03:00 <[g2]> which could be either push or pull in nature Jun 24 06:03:23 <[g2]> and automated or manual in kick off Jun 24 06:04:22 what is the extent of the configuration we are taling about? dhcp can pass many config options if configured properly Jun 24 06:04:51 <[g2]> I was thinking md5/sha1 on *every* file Jun 24 06:05:05 <[g2]> and sets are in the known area and user area Jun 24 06:05:27 <[g2]> basically most every bit on the box Jun 24 06:06:07 Ok. I start to understand now :) Jun 24 06:07:04 <[g2]> the default openslug jffs2 only has a little over 1000 files it's 900 something without dev Jun 24 06:07:36 you want a clean box with almost nothing on, and then get all the config and files over this management service Jun 24 06:08:00 <[g2]> there are 2 scenarios for me Jun 24 06:08:36 <[g2]> 1) somebody flashes an image somehow and it phones home or someone phone it and then can be completely managed from that point Jun 24 06:09:02 <[g2]> 2) A box arrives from manufacturing and needs to be setup for shipment to customers Jun 24 06:09:19 <[g2]> and 2) is one of the ways 1 could happen Jun 24 06:09:48 <[g2]> I've started a hardware company Jun 24 06:10:14 <[g2]> so 2) describes receiving slug like devices from the OEM Jun 24 06:12:55 :) Jun 24 06:15:30 I don't have any good ideas, but it sound similar to the management of the set-top boxes for cable etc. They have been doing such remote management (with firmware reflashing etc.) for a long time. Maybe you can apply some of their methods Jun 24 06:16:39 they have the viewing card as the base of the security model, and can proceed from there Jun 24 06:17:24 brb Jun 24 06:18:56 <[g2]> sorry, phone call Jun 24 06:40:03 np Jun 24 10:45:54 NAiL: the samba changes are in to monotone, 45b2b362a24b9ed9a2abb7165d98ea77f86b19f7 Jun 24 10:46:35 jbowler: Cool. What changes are there? paths/initscript/config? Jun 24 10:46:56 Yes, all of those. Jun 24 10:47:14 The config is the example. Jun 24 10:47:39 Yeah, I know Jun 24 10:48:04 I'll probably try to get OpenLDAP up with the samba schema sometime - as a separate package. Jun 24 10:48:06 I'm gonna do a new build as soon as I get a patch from mr_claus. I'll check the build then Jun 24 10:49:12 Try using modprobe for netconsole. Jun 24 10:49:38 I'm not gonna bother until I do the new build actually Jun 24 10:52:04 It won't make any difference - I just checked, netconsole.ko doesn't have any dependencies. Jun 24 10:52:58 I haven't tried it for a while. I do remember it is very sensitive to having the right insmod options and the error messages are incomprehensible (but that's the kernel) Jun 24 10:53:07 haha Jun 24 10:55:56 netconsole works for me (OpenSlug 2.0), using the modprobe line in the web page (but then, it's got the right numbers for my slug ;-) Jun 24 10:55:57 http://www.nslu2-linux.org/wiki/OpenSlug/SettingUpNetConsoleForRemoteSystemLogging Jun 24 10:56:57 hmm. I looked at some other page Jun 24 10:58:25 yeah... I just looked at http://www.nslu2-linux.org/wiki/OpenSlug/EnableNetconsole Jun 24 10:59:28 The 'archived home page' needs cleaning up and moving back into the main page. Jun 24 12:04:06 jbowler-away: Added a note on EnableNetConsole that points towards the other one. And added info on that page about a windows syslog daemon. Jun 24 12:21:26 jbowler-away: By the way, there's a bug in the initscript I wrote. It doesn't waie long enough for the old processes to die off. I have updated the script. Jun 24 16:35:35 anyone building openslug on debian? Jun 24 16:36:48 nudi is debian Jun 24 16:36:58 the official build server Jun 24 16:37:41 aha, good Jun 24 16:37:47 * NAiL is considering a switch to debian Jun 24 17:59:36 Anyone know why "logger" (busybox) won't log stuff when I've stared netconsole? Jun 24 18:01:37 It would be very handy to debug my startup problems right now :( Jun 24 18:37:14 hmm... what is the purpose of /.recovery? My filesystew went screwed, and that's what made my slug not boot Jun 24 18:50:52 jbowler-away: ping? Jun 24 19:01:38 jbowler-away: Just tried installing the new samba ipkg. Now that was hilarious. The new paths are worse :-P Jun 24 19:03:00 When starting samba it asked for a configfile in /samba. Jun 24 19:03:22 Fixed and committed. (Yay, my first commit! ;) Jun 24 19:21:42 NAiL: what was the problem? Jun 24 19:22:43 Because I just did a sync and update and nothing has changed. Jun 24 19:23:29 jbowler-away: the first line has $sysconfigdir Jun 24 19:23:37 should have been $sysconfdir Jun 24 19:23:54 rev. b7317c3b0cb815c2508ae376ab1e08cf662137a7 Jun 24 19:24:33 Yes, it does... oops, but why don't I see your change... Jun 24 19:24:57 Dunno... Where are you pulling from? Jun 24 19:25:19 mtn.nslu2-linux.org Jun 24 19:25:33 Oh, did you do an 'mt sync' ? Jun 24 19:27:20 heh, no Jun 24 19:27:26 and now I can't connect Jun 24 19:27:27 monotone: read from fd 4 (peer mtn.nslu2-linux.org) failed, disconnecting Jun 24 19:27:39 You typed the 'collection' name wrong. Jun 24 19:28:04 'read from fd 4 failed' is monotone for 'exit 1' Jun 24 19:28:44 check mt list branches, see if you created a new one. Jun 24 19:29:26 no new branches Jun 24 19:29:39 So what was the exact sync command you used? Jun 24 19:30:11 I haven't synced, apparently Jun 24 19:30:14 only committed Jun 24 19:30:52 ah, I was assuming the 'now I can't connect' was the result of monotone sync Jun 24 19:31:13 (in the working tree monotone sync should be sufficient on it's own.) Jun 24 19:31:13 no, just mt sync Jun 24 19:31:28 That's what I thought .. Jun 24 19:31:43 Hum, temporary problem? What happens if you try it again? Jun 24 19:31:58 still the same Jun 24 19:32:37 Are you 80.202.25.169? Jun 24 19:33:09 yes Jun 24 19:33:14 I think... ;) Jun 24 19:33:21 yeah Jun 24 19:34:10 Ok, this is useful - I think it's another instance of a problem I've had pushing changes to OE. Jun 24 19:35:06 nail, so you edited some file, mt commited it; then mt sync; mt push ? Jun 24 19:35:23 Yes, here's the full log - I can't see any problem but nothing changed! Jun 24 19:35:26 monotone: accepted new client connection from 80.202.25.169:53451 Jun 24 19:35:27 monotone: rebuilding merkle trees for collection org.nslu2-linux Jun 24 19:35:27 monotone: including branch org.nslu2-linux.unslung Jun 24 19:35:27 monotone: including branch org.nslu2-linux.monotone Jun 24 19:35:28 monotone: including branch org.nslu2-linux.openslug Jun 24 19:35:29 monotone: including branch org.nslu2-linux.openembedded Jun 24 19:35:31 monotone: ticks: c="certs"/256, k="keys"/1 Jun 24 19:35:33 monotone: Jun 24 19:35:35 monotone: fd 5 (peer 80.202.25.169:53451) processing finished, disconnecting Jun 24 19:36:21 Ok? So where is the problem? Jun 24 19:36:57 Mystery, here's the evidence that your change isn't there: Jun 24 19:37:00 jbowler@nudi:/home/monotone$ monotone --db=nslu2-linux.db cat revision b7317c3b0cb815c2508ae376ab1e08cf662137a7 Jun 24 19:37:01 monotone: misuse: no revision b7317c3b0cb815c2508ae376ab1e08cf662137a7 found in database Jun 24 19:37:24 nail, did you push? Jun 24 19:37:37 So this is exactly what I see when I try to push org.nslu2-linux.openembedded back to OE - it just doesn't take. Jun 24 19:37:43 dyoung-web: I've tried. Jun 24 19:37:55 dyoung-web: yes: see the server log on nudi Jun 24 19:38:29 (I believe 70.98.218.127 is me doing a sync, the preceding stuff is NAiL). Jun 24 19:38:35 jbowler-away: There's one small change I forgot to do with the init scripts... should I commit that and try to sync, or should I wait until we figure out exactly what's wrong? Jun 24 19:39:06 If you are happy with a potentially broken source control system go ahead. Jun 24 19:39:22 hehe, ok. I'll wait ;) Jun 24 19:39:44 Well, just keep backups. Jun 24 19:40:02 There's no harm commiting it that I can see - more test cases ;-) Jun 24 19:41:22 Ok, this is good - we have a way of reproducing the problem without involving OE. Still, I've spent much of today trying to figure out what is wrong and got nowhere. Jun 24 19:41:25 nah, still can't sync/push Jun 24 19:43:20 bbl, but I don't have any ideas what is going on here... Jun 24 19:47:53 nail, does monotone diff tell you anything? Jun 24 19:48:59 dyoung-web: yeah, but that's the stuff I haven't committed. All the committed stuff is gone from diff. I diffed to make sure I didn't screw up ;) Jun 24 19:54:30 <[g2]> BTW how did you guys work-around the --strip problem with procps ? Jun 24 19:55:21 didn't Jun 24 19:55:44 <[g2]> didn't have the problem or didn't work-around the OE build ? Jun 24 19:55:54 somone in #oe was threatening to patch it to not strip after I submitted a bug report Jun 24 19:55:58 not a good fix IMHO Jun 24 19:56:21 [g2], did you ask because you build procps and it succeeded? Jun 24 19:56:52 <[g2]> no I built it and it failed, but I haven't pulled in several days Jun 24 19:58:01 I want someone in #oe to fix it properly - the oe way, which I don't know but would take one of their devs about 2 minutes Jun 24 19:59:01 but it seems that nobody cross-builds procps in oe Jun 24 19:59:20 at least not cross-arch Jun 24 19:59:39 <[g2]> *sigh* Jun 24 20:00:07 jbowler-away: this has got to be some sort of certs thing. perhaps we can dump the db and see if that gives any clues Jun 24 20:00:57 back later ... Jun 24 20:01:21 BTW, let's use #nslu2-linux for all monotone stuff, cause it's not OpenSlug-specific Jun 24 20:02:45 <[g2]> rwhitby-away, nod. It's just that all the OpenSlug stuff builds with it :) Jun 24 20:05:17 yep, as does Unslung and Optware :-) Jun 24 20:05:52 * rwhitby-away is going out and about Jun 24 21:37:48 NAiL: I believe you don't have write access due to an error (still, this may be my problem with OE too...) Jun 24 21:39:58 jbowler: Uh.. some of the changes has been pushed Jun 24 21:43:05 Curious, we now have two heads ;-) Jun 24 21:48:38 * NAiL makes a snide remark about rearing ugly heads :P **** ENDING LOGGING AT Fri Jun 24 23:59:56 2005