**** BEGIN LOGGING AT Fri Jun 13 02:59:57 2008 Jun 13 03:26:36 03bzhou * r8483 10optware/trunk/make/postgresql.mk: postgresql: 8.2.7 -> 8.2.9 Jun 13 03:34:57 anyone here use slugos 4.10 alpha - do "turnup" scripts work correctly? Seems after rebooting, root is not mounted at the location specified by the turnup disk command. Jun 13 03:40:22 RobNC: should be working Jun 13 03:41:52 rwhitby: thanks, either it's because of ObeseSlug is breaking the turnup scripts, or operator error. Unfortunately, not much useful information in the wiki - if searching on "turnup". Jun 13 03:42:36 it should be orthogonal to obeseslug Jun 13 03:43:16 what command did you give, and what are you seeing happening? Jun 13 03:43:28 I just booted up my slug with 4.10-alpha; it mounts the rootfs on / just as it should. Jun 13 03:44:25 mwester - thanks, I just rebuilt with 4.10-alpha - only change I made was to change common-pci.c value as specified previously (attempt to fix OOM bug) Jun 13 03:44:32 rwhitby: did the following: Jun 13 03:45:29 1) re-compile slugosbe, 2) slugimage extract all parts (-F), 3) slugimage pack, replacing apex and redboot with 16MB variants Jun 13 03:45:55 ok Jun 13 03:46:26 4) boot into "brokenslu2", 5) umount /dev/sda1 6) mkfs.ext3 -b 1024 -f 1024 -m 5 -L root /dev/sda1 Jun 13 03:46:40 ok Jun 13 03:46:53 (I forgot a step - 4.5) turnup init) Jun 13 03:47:17 4.7) turnup preserve Jun 13 03:47:29 7) turnup disk -i /dev/sda1 -t ext3 Jun 13 03:47:32 8) reboot Jun 13 03:47:59 will 5 seconds be fast enough for your disk to be recognised and mounted? Jun 13 03:48:21 (you can tell from the kernel bootlog) Jun 13 03:48:41 yes but I can try longer delay - see if it makes a diff. I see msgs like this when booting: Jun 13 03:49:29 sd 0:0:0:0: [sda] Attached SCSI removable disk Jun 13 03:49:40 bootclean.sh: Skipping /tmp (not a directory) Jun 13 03:49:56 bootclean.sh: Skipping /var/lock (not a directory) Jun 13 03:50:09 if you got nothing between the first two, then your disk has not been mounted Jun 13 03:50:32 try -s 10 on the turnup disk line Jun 13 03:50:54 then I saw "EXT3 FS on sda1, internal journal" (sorry I can't copy/paste - limitation of VNC) Jun 13 03:51:20 the mounting by /linuxrc should happen before bootclean.sh Jun 13 03:51:30 ok, that's a thought. I'm a little surprised, because it's a compact flash drive and spins up really quick Jun 13 03:52:08 oh, one other thing - do you have init=/linuxrc on the apex kernel command line? Jun 13 03:52:38 I didn't change apex command line, let me look ... Jun 13 03:53:47 in apex looks like it just has the "copy fis://kernel 0x00008000" and then "boot" - I don't see "init=/linuxrc" Jun 13 03:53:58 look in cmdline Jun 13 03:54:08 yep I see it - ATAG_CMDLINE Jun 13 03:54:49 only has "root=/dev/mtdblock4 rootfstype=jffs2 console=ttyS0,115200" Jun 13 03:54:58 ok, add init=/linuxrc to the end Jun 13 03:55:47 ok, thanks, hmm, maybe build of apex should be changed then - to add this - perhaps this has been the problem all along. Jun 13 03:56:15 which apex are you using? Jun 13 03:56:33 1l5l13 Jun 13 03:56:36 1.5.13 Jun 13 03:56:56 built from where? Jun 13 03:58:33 via instructions I wrote in wiki in CentOS cross-compile Jun 13 03:59:23 svn co http://svn.nslu2-linux.org/svnroot/kernel/trunk /home/slug/kernel Jun 13 03:59:49 svn up Jun 13 04:00:03 make apex Jun 13 04:01:33 you mean to add "init=/linuxrc;" before the "boot" right? Jun 13 04:01:57 no, to the end of the cmdline variable Jun 13 04:02:28 Ah gotcha - another parameter - was thinking "startup" but literally cmdline Jun 13 04:05:07 Wow that was it! One beep, then three beeps. Previously it was just three beeps. Jun 13 04:05:13 03rwhitby * r1070 10kernel/trunk/Makefile: Updated to apex 1.5.14 Jun 13 04:05:17 Thanks! I'll put that in wiki Jun 13 04:06:24 03rwhitby * r1071 10kernel/trunk/patches/apex/series: All apex patches are now upstream Jun 13 04:07:09 03rwhitby * r1072 10kernel/trunk/patches/apex/ (19 files): All apex patches are now upstream Jun 13 04:12:48 03rwhitby * r1073 10kernel/trunk/patches/apex/ (init-linuxrc.patch series): Added init=/linuxrc to slugos jffs2 configs Jun 13 04:13:04 RobNC: try building 1.5.14 now and it should work out of the box Jun 13 04:13:57 mwester: what can you tell me about this external toolchain stuff? Jun 13 04:16:47 Built by target "meta-toolchain-slugos" (I think that's what I named it), it creates a pair of tarballs in the deploy/sdk directory. Currently only the one has data; that's the toolchain itself. The toolchain can be augmented with other "essentials"; I've added devio. Jun 13 04:16:57 ok, thanks I appreciate that! I will do that and let you know. Jun 13 04:17:13 rwhitby: ok, thanks I appreciate that! I will do that and let you know. Jun 13 04:17:16 mwester: is that in our feed? Jun 13 04:17:34 (i.e. instead of building a new toolchain so I can build apex, can i download one of yours from somewhere?) Jun 13 04:17:40 One untar's the toolchain; it ends up in /usr/local/slugos, and setting that before running the master makefile will build the lot. :) Jun 13 04:18:03 We're not yet building that on the the buildserver; we should discuss the plans. Jun 13 04:18:24 any reason why we shouldn't just autobuild it? Jun 13 04:19:17 Nope; I think we can autobuild it without worry. It's what we add to the feeds, and how users can track the binary tarball to the exact sources that might be more tricky. Jun 13 04:20:00 BTW, we can also enable packaged staging; that does nothing for the end packages but it may make recovery of a botched build environment less painful (at the cost of some disk space). Jun 13 04:21:07 yeah, can we do that right now? Jun 13 04:22:38 Sure. I've had it turned on for weeks now, with nary a problem, so I'm reasonably comfortable that it won't break anything. Jun 13 04:33:32 mwester: I just tried: slug@builder:~/slugos$ bitbake meta-toolchain-slugos Jun 13 04:33:32 ERROR: Task 361 (/home/slug/slugos/openembedded/packages/m4/m4-native_1.4.11.bb, do_populate_staging) failed Jun 13 04:37:05 Ouch. Jun 13 04:37:37 date Jun 13 04:37:42 (oops) Jun 13 04:39:55 I bet we have to remove tmp and start anew to change to packaged staging... Jun 13 04:42:24 Is there anything we particularly value in the tmp directory right now? :) Jun 13 04:43:29 hmm... let me try something else first. This will take a while, but let's not experiment on builder. Jun 13 04:44:02 we're due for a rebuild anyway ;-) Jun 13 04:44:34 Ok. I just want to make sure that my guess is correct; that the meta-toolchain requires packaged staging to be enabled. Jun 13 04:57:58 RobNC: 1.5.14 binaries available in http://ipkg.nslu2-linux.org/feeds/kernel/ Jun 13 04:59:26 rwhitby: thanks will get that shortly and report back. Jun 13 05:04:22 so who would I talk to about the udev scripts in slugos? :-) Jun 13 05:05:22 depends on if you intend to just comment or to complain! :) Jun 13 05:07:15 Well, I think the approximate behaviour I'd like could be achieved by running fixfstab at the top of the udev mount.sh script, but this is like some sort of huge kludge... Jun 13 05:09:56 There are a number of problems with udev, fixfstab, and the SlugOS pivot from internal flash to external storage; it's hideously complicated and the corner cases are bad... Jun 13 05:10:29 hm Jun 13 05:11:08 That's why I haven't dared touch fixfstab yet.. Jun 13 05:12:45 I've left it pretty much alone as well; there was one recent change in 4.10-alpha but I disremember the specifics. Jun 13 05:13:39 It's the hotplug behaviour I'd want to change actually, I'd want to have LABEL=foo or UUID=whatever in fstab, so that drives appear in predictable locations Jun 13 05:14:28 Basically on my list is to redesign the entire mechanism. I expect that will end up adding some restrictions (such as requiring the rootfs to be mounted by UUID). The LABEL approach is interesting, but fraught with difficulty on USB-based systems; I think we'll not be supporting that. Jun 13 05:15:02 So I guess what I'd need to do is make mount.sh parse output of blkid for the device that's being added, see if the uuid or label is in /etc/fstab, and in that case try mount it that way instead of creating a new mountpoint in /media Jun 13 05:15:05 It'll probably be UUID-based, with perhaps a shell script to assist in selecting a mount point for each UUID or such. Jun 13 05:15:57 The big challenge is that there are two fstabs. Jun 13 05:16:19 I think my root is mounted by uuid as it is now, though I'm not sure :-) Jun 13 05:17:22 There's the one on the flash rootfs, which is copied to the external rootfs by turnup init. Thereafter they are never sync'd. As long as your rootfs never changes, you're ok -- when it does, things get really difficult. Jun 13 05:18:24 If your root is mounted by UUID, consider what happens if you plug in a disk that used to contain the rootfs for an older Fedora system (with a label of "/")... Jun 13 05:18:37 \o/ Jun 13 05:18:50 hopefully the UUID would be different Jun 13 05:19:24 I think Fedora no longer uses label for rootfs anymore either; and yes the UUID is supposed to be completely unique. Jun 13 05:19:51 Fedora 9 does by uuid atleast Jun 13 05:20:11 I thought so; I haven't upgraded to Fedora 9 yet. Jun 13 05:21:00 actually it has root on lvm.. Jun 13 05:21:43 So at any rate, I suspect that the right way, long term, is to do it by UUID only, but the open issue is what to do if the UUID is not listed for "special mounting" -- mount it on /media/big-long-uuid-string or on /media/sda1 or not mount it at all? Jun 13 05:22:05 Is the udev mount.sh script executed for devices that are already plugged in at boot? Jun 13 05:22:40 /media/sd?x probably sanest Jun 13 05:22:50 I don't recall, but I think that udev is up and running when the devices become ready -- which will trigger the script. Jun 13 05:23:16 hm Jun 13 05:23:55 That's one of the challenges, because we can't let the rootfs end up mounted twice. It gets messy. Jun 13 05:24:55 it's mounted twice on my slug according to /proc/mounts ... :-) Jun 13 05:25:25 The other thing associated with all that is that it would be appropriate to add a means for a user trigger when the mount occurs -- an easy way to trigger a script to NFS export it or add it to Samba as a share... Jun 13 05:25:47 rootfs / rootfs, and /dev/sda1 / ext3. Not sure if one should pay attention to the first one Jun 13 05:26:05 pseudo-device; can be ignored. Jun 13 05:26:37 Ah yeah, I'm taking the reverse approach here. I have the shares for my harddrive in samba already, now all the harddrive needs to do is appear in a predictable place :-) Jun 13 05:28:09 Well, all I can say right now is to modify the mount.sh script as necessary to make it work, but watch out that you don't alter the way the rootfs is mounted - that's been a problem whenever messing about with those scripts occurs. Jun 13 05:30:55 Right, root is mounted by the internal-flash's /boot/disk, getting passed the uuid from /linuxrc Jun 13 05:32:02 i think I'll keep the root directly connected to slug, to the port that always got assigned as /dev/sda in my brief tests Jun 13 05:32:39 'tis easiest that way! Jun 13 05:32:58 (and connect USB hub to the other port and see if I can get it working sanely) Jun 13 05:33:57 slugos is so much fun, it's tiny enough that you can figure out roughly what goes on... I find Fedora a gigantic maze in comparison :) Jun 13 06:07:49 03bzhou * r8484 10optware/trunk/make/py-duplicity.mk: py-duplicity: 0.4.2 -> 0.4.11 Jun 13 06:11:28 03rwhitby * r1074 10kernel/trunk/ (Makefile patches/2.6.25/KERNEL): Updated kernel to 2.6.25.6 Jun 13 13:48:28 03engy * r8485 10optware/trunk/make/openvpn.mk: openvpn: enable password save Jun 13 13:53:40 re the udev mount.sh script... Jun 13 13:54:17 This terrible scripting of mine seems to do what I wanted, I stole uuid_by_partition from elsewhere in /etc: http://enivax.net/jk/mount.diff Jun 13 16:13:21 03bzhou * r8486 10optware/trunk/make/py-routes.mk: py-routes: 1.8 -> 1.9 Jun 13 17:26:36 rwhitby: kernel updated for slugobe? Jun 13 17:28:00 and new apex version.. good. Jun 13 17:45:35 03bzhou * r8487 10optware/trunk/make/py-pexpect.mk: py-pexpect: added py25 sub-ipk Jun 13 22:27:31 I just flashed my new NSLU2 with unslug but cannot access it via a browser. It looks like it is pulling a DHCP address off my DHCP server, but when I cannot ping it or browse it. Any suggestions? Jun 13 22:35:18 hmm now its beeping at me and I haven't done anything to it Jun 13 22:48:46 VoodooZ: kernel hasn't been updated in slugosbe, just in our kernel repo. **** ENDING LOGGING AT Sat Jun 14 02:59:56 2008