**** BEGIN LOGGING AT Mon Dec 11 02:59:57 2006 Dec 11 03:02:12 guess I need to go read some man pages and stuff ... Dec 11 03:07:13 ah - hmm... I would have to read the docs too, or email Martin (he may know) Dec 11 03:18:40 I'm sure he will know. Dec 11 03:19:58 initramfs-tools(8) Dec 11 03:22:46 manual_add_modules and add_modules_from_file look promising Dec 11 03:24:49 dumfrac: http://svn.nslu2-linux.org/svnroot/debian/trunk/Makefile now builds 2.6.19 experimental Dec 11 03:25:06 dumfrac: do you have any other devices than nslu2 ? Dec 11 03:25:45 no - only my laptop :-) Dec 11 03:26:50 I've been looking at the Thecus N2100, but since we have our first baby on the way in January, I suspect that toys for me will have to wait Dec 11 03:27:38 yeah, our second child was one of the reasons why Unslung 6.8 came so long after 5.5 :-) Dec 11 03:27:49 (and why SlugOS 3 took so long after SlugOS 3. Dec 11 03:27:51 2. Dec 11 03:29:01 since it is our first, I'm blissfully unware of what lies ahead Dec 11 03:30:20 well, for a start, I'll be able to contact you at completely different times of the day, when you're up in the middle of the night ... Dec 11 03:31:03 :-) yeah, I've heard something about not getting much sleep Dec 11 03:49:55 aha - /usr/share/initramfs-tools/{hooks,scripts/local-top}/nslu2 Dec 11 04:03:35 03rwhitby * r78 10debian/trunk/Makefile: Fixed LINUX_DIR Dec 11 04:31:06 there is no linux-image-2.6.17 in debian testing anymore, how does the Debian/NSLU2 install/upgrade procedure work now? Dec 11 04:32:09 tuv: tricky :-) yeah, I guess rc-1 is now broken Dec 11 04:33:05 dumfrac, probably the proper linux-image*.deb package should be hosted together with the ixp4xx modules and the flash image Dec 11 04:33:41 tuv: have you tried installing rc-1 since 2.6.18 moved to testing ? Dec 11 04:34:01 dumfrac, no.. i've been running debootstrapped slugos Dec 11 04:34:01 it looks like the mirrors still have 2.6.17 Dec 11 04:34:33 I could be wrong, but I think as long as 2.6.17 is on the mirrors, rc-1 should work Dec 11 04:35:10 dumfrac, i'm trying to upgrade from debootstrapped to debian/NSLU2 Dec 11 04:36:17 dumfrac, there is linux-image-2.6-ixp4xx 2.6.18 now Dec 11 04:36:34 tuv: yeah, I've never actually tried that - however, actually, now that I am thinking properly again, rc-1 (and debootstrap, I think) should continue to work - only now, 2.6.18 will be installed Dec 11 04:37:09 dumfrac, yeah.. but the ixp4xx modules are extracted to a 2.6.17 modules directory Dec 11 04:37:26 dumfrac, is a rename enough to fix this? Dec 11 04:38:23 tuv: ah right - hmm... no, Ithe modules in 2.6.18 are the open source ethernet driver modules whereas, 2.6.17 used the Intel propriatery driver Dec 11 04:39:13 tuv: to use the built in ethernet port with 2.6.18, you need the NPE microcode (which Debian can't distribute) Dec 11 04:39:15 dumfrac, so 2.6.18 does not need the ixp4xx modules anymore? is the ixp4xx download/extract step not needed if i'm installing 2.6.18 directly? Dec 11 04:39:51 tuv: depends what you mean by " ixp4xx modules" anymore - do you mean the Intel driver ? Dec 11 04:39:57 yes Dec 11 04:39:59 s/anymore/ Dec 11 04:40:24 yes - that driver isn't built for 2.6.18 Dec 11 04:40:40 to make 2.6.18 work, you need the NPE microcode Dec 11 04:40:44 as of 2.6.18, no NSLU2 linux firmware uses Intel NPE drivers. Dec 11 04:40:53 and where can i get that from? Dec 11 04:41:15 I'll see if I can find the link for the instructions to build the microcode Dec 11 04:41:21 tuv: do you have an openembedded build environment available? Dec 11 04:41:31 rwhitby, no.. using binaries only here Dec 11 04:41:44 it's in the etch rc1 debian binary Dec 11 04:42:10 i'm trying to upgrade from debootstrapped slugos to debian/nslu2 Dec 11 04:42:30 ok, so you've flashed di-nslu2.bin? Dec 11 04:42:55 no.. i'm following this page: Dec 11 04:42:56 http://www.cyrius.com/debian/nslu2/upgrade.html Dec 11 04:43:20 rwhitby, no d-i.. upgrading a working system without formatting Dec 11 04:43:47 tuv: that page hasn't been updated for 2.6.18 Dec 11 04:43:53 tuv: right - that page only works up to 2.6.17 Dec 11 04:43:55 that page was linked to from: Upgrade from manual bootstrap to testing ("etch") at http://www.nslu2-linux.org/wiki/Debian/HomePage Dec 11 04:44:11 dumfrac, rwhitby: yes.. hence my questions Dec 11 04:44:43 rwhitby: is the NPE microcode in the initramfs of rc-1 ? Dec 11 04:45:20 i probably can get the 2.6.17 image deb from snapshot.debian.net, but i was wondering if there is another known solution Dec 11 04:46:26 tuv: do you have the debian rc1 image available ? Dec 11 04:46:42 yes, you will have to get it out of the initramfs for rc-1 Dec 11 04:46:44 if 2.6.17 uses intel's ixp4xx module, why would it have the NPE Dec 11 04:46:45 ? Dec 11 04:46:49 from http://www.slug-firmware.net/ Dec 11 04:46:57 dumfrac, d-i? no Dec 11 04:47:07 it will only be in the image on slug-firmware.net - it will *never* be in a debian repository Dec 11 04:47:10 dumfrac, but i don't want to reinstall Dec 11 04:47:23 tuv: you don't have to install - here is what you do Dec 11 04:47:26 (since to get the microcode, you need to go through a click-through) Dec 11 04:47:36 tuv: download the d-i rc1 image from http://www.slug-firmware.net/ Dec 11 04:48:00 (and the microcode is not allowed to be distributed separately from "software with substantial functionality" (or something like that - I have to read the license again) Dec 11 04:48:00 tuv: unpack the image using slugimage (which you can install using apt-get) Dec 11 04:48:26 yeah, what dumfrac is saying is the only way to upgrade in place without reflash Dec 11 04:48:45 tuv: one of the files will be ramdisk.gz Dec 11 04:49:08 rwhitby, if i can get the 2.6.17's deb, wouldn't that be another solution? Dec 11 04:49:25 tuv: whoops ! ignore the comment about ramdisk.gz Dec 11 04:49:56 tuv: debian cannot distribute the microcode Dec 11 04:50:15 tuv: arrh ! ok - don't ignore the comment about ramdisk.gz - this is me thinking in real time :-) Dec 11 04:50:38 dumfrac, i'm still following Dec 11 04:51:06 tuv: you need to endian swap the ramdisk.gz file using devio '<< ramdisk.gz; xp $ 4' > ramdisk-swap.gz Dec 11 04:51:20 tuv: install devio using apt-get if you don't have it Dec 11 04:51:21 rwhitby, i understand, but if i have access to 2.6.17 deb i'd simply follow the webpage Dec 11 04:51:44 tuv: the 2.6.17 deb doesn't have the microcode in it. Dec 11 04:51:55 tuv: then do mkdir initrd Dec 11 04:52:00 tuv: cd initrd Dec 11 04:52:14 I say again, Debian cannot distribute the microcode. That's why we have unofficial images on slug-firmware.net Dec 11 04:52:16 tuv: whoops, go back a step Dec 11 04:52:34 rwhitby, then probably sda1-2.6.17-2.bin does, since the upgrade page doesn't say anything about extrating the d-i image Dec 11 04:52:39 tuv: don't go back a step :-) really do the cd... Dec 11 04:52:49 :) Dec 11 04:53:01 tuv: where does sda1-2.6.17-2.bin come from? Dec 11 04:53:18 tuv: then do su -c 'zcat ../ramdisk-swap.gz | cpio -i' Dec 11 04:53:18 rwhitby, http://cyrius.com/debian/nslu2/files/sda1-2.6.17-2.bin Dec 11 04:53:37 if that has microcode in it, then Martin is in danger of litigation from Intel. Dec 11 04:53:38 rwhitby, i think it's also included with the d-i download Dec 11 04:54:04 You can *only* get microcode through a click-through of the Intel license. Getting it any other way is a violation of the Intel license. Dec 11 04:54:08 tuv: the 'su' is not really necessary - it just keeps the files owned by root, but since you won't be modifying the initramfs, it isn't a problem if they are not owned by root Dec 11 04:54:20 rwhitby, how else would you explain the fact that there is no need to extract the d-i image according to the upgrade webpage? Dec 11 04:54:42 tuv: I'm checking that image now. If it does have microcode, then Martin will have to pull it. Dec 11 04:54:49 tuv: that last command should unpack the initramfs, and the microcode should be in the directory (NPE-B.01000201) Dec 11 04:55:36 tuv: the way dumfrac is explaining is the only legal way to get the pre-built microcode (i.e. from something you downloaded through the click-through on slug-firmware.net Dec 11 04:56:32 tuv: copy this file (NPE-B.01000201) to /lib/firmware/ on your slug, and then in /lib/firmware make a symlink called NPE to NPE-B.01000201 (i.e. ln -s NPE-B.01000201 NPE-B) Dec 11 04:56:38 rwhitby, yes.. but how is it possible to bypass all this work when upgrading to 2.6.17? Dec 11 04:57:00 2.6.17 does not require the microcode as a separate file. Dec 11 04:57:06 tuv: remember that etch hasn't been released yet - it is not perfect Dec 11 04:57:30 dumfrac, ln -s NPE-B.01000201 NPE-B? or * NPE? Dec 11 04:58:35 NPE-B, ...When etch is released, the upgrade procedure should work - but also remember that it is likely that Debian will never work with the built in ethernet port out of the box (unless rwhitby does some clever stuff) Dec 11 04:59:38 dumfrac: actually, I doubt that there can be an easy automatic upgrade from anything other than an installed di-nslu2.bin, cause that would require debian to distribute the microcode, which they cannot do. Dec 11 04:59:50 tuv: sda1-*.bin does not have the microcode in it. Dec 11 04:59:53 tuv: ... like figuring out a clean way to load the microcode from flash Dec 11 05:01:15 tuv: try using the di-nslu2.bin from http://www.slug-firmware.net/d-dls.php (i.e. debian-etch-rc1-20061102.zip) Dec 11 05:01:31 tuv: ignore that last comment Dec 11 05:02:05 tuv: I thought that you had said "sda1-*.bin does not have the microcode in it", not rwhitby - it getting late here Dec 11 05:02:18 s/it/it's Dec 11 05:02:40 rwhitby, i'm still puzzled then. how is it possible then to upgrade from debootstrapped slugos to debian/nslu2 without extracting the image, as explained in the upgrade page Dec 11 05:02:52 rwhitby, http://tech.groups.yahoo.com/group/nslu2-linux/message/15925 Dec 11 05:02:56 only images directly downloaded from www.slug-firmware.net have the Intel drivers (pre-2.6.18) or microcode (2.6.18+) in them. Dec 11 05:03:01 I should probably write this procedure up - I guess other are going to be asking this question Dec 11 05:03:12 tuv: simple - it's not possible. Dec 11 05:03:28 dumfrac, i have written for you if you like :) Dec 11 05:03:51 tuv: that procedure works for 2.6.17, not later. Dec 11 05:03:57 tuv: can you post to the nslu2-linux wiki in the debian section Dec 11 05:04:33 rwhitby, well how does it work for 2.6.17. it still needs something with a license Dec 11 05:04:41 tuv: i.e. http://www.nslu2-linux.org/wiki/Debian/HomePage Dec 11 05:05:27 dumfrac, sure Dec 11 05:06:08 tuv: thanks - is the procedure working - do you need anymore details (some of the step outlined above were a little vague) ? Dec 11 05:06:28 rwhitby, did you read: 'Upgrade from manual bootstrap to testing ("etch")' on http://www.nslu2-linux.org/wiki/Debian/HomePage Dec 11 05:06:29 tuv: for 2.6.17, you already had the ixp400_eth module (which includes the microcode compiled it) in your rootfs. Dec 11 05:07:13 tuv: yes, I read that. and I tell you again, it only works up to 2.6.17 Dec 11 05:08:04 dumfrac, i've to try it first.. i haven't yet. i'll post it as soon as it works for me. if it doesn't i'll be back :) Dec 11 05:08:04 for 2.6.18, you need to do what dumfrac is saying. there is no other way. Dec 11 05:08:33 rwhitby, what if i followed the upgrade procedure when 2.6.17 was available and want to upgrade to 2.6.18 now? would i still need this procedure? Dec 11 05:08:56 yes Dec 11 05:09:12 unless you flashed the etch rc1 di-nslu2.bin Dec 11 05:09:14 ok - good luck - I will probably be going to sleep soon, but send me an email at gordonfarquharson at gmail dot com if you need any help - I suspect that we are about to get a lot of questions about this now that 2.6.18 has migrated to testing, so a procedure on the wiki will be very useful Dec 11 05:09:25 hmm.. so automatic kernel upgrades are still a dream Dec 11 05:10:46 dumfrac, uhm.. will this procedure allow me to upgrade to newer kernels after 2.6.18 automatically? Dec 11 05:11:43 tuv: you won't have to do this procedure every time - once the microcode is in /lib/firmware, newer kernels should just work Dec 11 05:11:44 tuv: automatic kernel upgrades work if you started with di-nslu2.bin etch rc1 Dec 11 05:12:10 There is *no* automatic upgrade patch from SlugOS/LE to Debian/NSLU2. Dec 11 05:12:14 rwhitby, will they work after this procedure? Dec 11 05:12:25 tuv: yes, they should. Dec 11 05:12:33 rwhitby, yes i understand that and i wasn't expecting it Dec 11 05:12:41 good.. great Dec 11 05:26:02 hmm.. the upgrade procedure has an ixp4xx download, which does have the NBE files and put them in /lib/firmware.. i don't suppose these are kernel-specific, so i think i don't need to go through this procedure, do i? Dec 11 05:26:50 http://cyrius.com/debian/nslu2/files/ixp400-eth-2.6.17-2.tar.gz Dec 11 05:27:42 that file has file that go into /lib/modules and other that go into /lib/firmware. the lib/modules ones should be kernel-specific, but the lib/firmware ones shouldn't. right? Dec 11 05:28:00 that file will need to be pulled. Dec 11 05:28:21 since I can get to it without going through the intel license. Dec 11 05:29:12 rwhitby, besides that, am i right? Dec 11 05:29:33 eys Dec 11 05:29:35 yes Dec 11 05:30:07 but we can't put that in a public procedure, cause I expect the file won't be there for long after Martin gets my email. Dec 11 05:30:21 well then unfortunately i cannot verify the procedure, should i just post it without testing it? Dec 11 05:32:37 rwhitby, if that file is pulled, it will invalidate all the debootstrapped-to-debian/nslu2 upgrade procedures already in the wkik Dec 11 05:32:43 *wiki Dec 11 05:33:01 tuv: yes, unfortunately, that file is illegal. Dec 11 05:33:57 it will even invlalidate the debian/nslu2 upgrade from a pre-rc1 Dec 11 05:35:21 tuv: seems the only references to that file are on Martin's site, not the wiki. Dec 11 05:36:06 rwhitby, yes, but the wiki states that one can upgrade from debootrapped to debian/nslu2 and links to martin's page with the file Dec 11 05:36:28 rwhitby, those sections will be useless without the file Dec 11 05:36:38 correct. Dec 11 05:37:04 something doesn't become legal just cause someone needs it. Dec 11 05:37:35 well if no one needs it, then it won't be illegal Dec 11 05:37:37 it will need to be replaced with a procedure like the one dumfrac posted above, using released image files from www.slug-firmware.net Dec 11 05:37:51 pardon/ Dec 11 05:37:53 ? Dec 11 05:38:12 the alternative is that Martin puts a click-through license in front of that file. Dec 11 05:38:29 but I doubt that he will want a click-through license on his debian site :-) Dec 11 05:38:33 or the file gets added to slug-firmware Dec 11 05:39:32 a follow up, things are not announced illegal if no one is interested in them Dec 11 05:40:11 I still don't understand that sentence Dec 11 05:41:20 something doesn't become legal just cause someone needs it. => things become illegal only if someone needs them Dec 11 05:41:48 and the opposite is not true, hopefully :) Dec 11 05:42:01 What I said was that the existence of that file on Martin's site, without needing to go through a click-through, is a violation of the Intel license. Dec 11 05:42:20 i understand what you were saying Dec 11 05:42:42 and i'm not contradicting you Dec 11 05:42:53 Just because some wiki pages need that file doesn't mean that it is no longer a violation. So whether or not some wiki pages link to a page which links to the file is immaterial as far as determining whether the file should be pulled or not. Dec 11 05:43:23 So we need to rewrite the procedures so that they don't require files that are not behind click-through licenses. Dec 11 05:43:31 (as per dumfrac's procedure above) Dec 11 05:43:33 i have absolutely no problems with what you're saying, you don't need to say it again Dec 11 05:43:57 ok, I just didn't understand what you meant by "well if no one needs it, then it won't be illegal" Dec 11 05:44:57 i meant people who *decide* what's legal and what's not usually won't 'illegalize' something that no one needs Dec 11 05:45:22 ah, I see. Sorry, I completely took the wrong meaning to what you said. Dec 11 05:45:29 so if something is illegal there must be some need/interest in it Dec 11 05:45:36 indeed. yes. Dec 11 05:47:47 now should i post dumfrac's procedure untested? or should i not? i don't think i'll go through it now that i have the microcode Dec 11 05:48:23 test first, then post. Dec 11 05:48:34 tuv: I would post it, but make a note that it is untested - I have a feeling that we will be using it :-) Dec 11 05:48:46 either way :-) Dec 11 05:49:18 yeah - i'm still not in bed - I am testing hacked version of the d-i to sort out this apt problem (I really should go to bed soon) Dec 11 05:49:28 s/version/versions Dec 11 06:04:14 dumfrac, initial version: http://www.nslu2-linux.org/wiki/Debian/HomePage Dec 11 06:04:29 dumfrac, feel free to modify it Dec 11 06:04:43 or correct it, of course Dec 11 06:05:05 tuv: thanks Dec 11 06:05:49 dumfrac, np Dec 11 07:10:16 dumfrac: seems the answer for update-initramfs is to add a machine-specific hook (like /usr/share/initramfs-tools/hooks/nslu2) Dec 11 07:10:22 hey jacques Dec 11 07:10:59 hi rwhitby Dec 11 07:11:21 jacques: now have a kernel-image .deb which includes the artop ide modules Dec 11 08:16:07 morning Dec 11 08:29:24 hey likewise Dec 11 08:30:57 rwhitby: hi Dec 11 11:48:22 http://pastebin.ca/275293 <- 2.6.19-experimental kernel upgrade for Debian/NSLU2 Dec 11 11:48:47 (using linux-image package built by http://svn.nslu2-linux.org/svnroot/debian/trunk/Makefile) Dec 11 12:20:04 03rwhitby * r79 10debian/trunk/patches/kernel/2.6.19/config.ixp4xx.patch: Removed the patches that have been accepted into the Debian kernel (nas100d IDE module enables). Dec 11 14:50:03 03oleo * r4659 10optware/trunk/ (make/transmission.mk sources/transmission/S80busybox_httpd): transmission: add /local/leon check to httpd startup Dec 11 16:16:29 03bzhou * r4660 10optware/trunk/make/py-mercurial.mk: py-mercurial: 0.9.1 -> 0.9.2 Dec 12 00:25:01 hi Dec 12 00:25:48 do you know why I get this error when I try to compile s.th.? Dec 12 00:25:54 error: expected ')' before '*' token Dec 12 00:27:34 well, some details about what you're trying to compile, and what compiler you're using, would be helpful for a start ... Dec 12 00:28:08 otherwise, I could only guess that the compiler you're using is expecting a ')' before the '*' ;-) Dec 12 00:30:17 ok, its a self-written script which I comipled a while ago for my nslu2 successfully Dec 12 00:30:43 I try to compile lsusb.c with the same result, so I think its not a syntax error Dec 12 00:31:03 the compiler is gcc 4.1.0 Dec 12 00:33:56 void eject(usb_dev_handle *udev){ <--this is where the error is Dec 12 00:36:14 do you so what is wrong with this line? Dec 12 00:36:18 see Dec 12 01:23:58 thanks, I found it. libusb was missing Dec 12 01:27:14 n8 Dec 12 02:04:31 nas100d 2.6.19 clean Debian boot, including internal IDE support: http://pastebin.ca/276204 Dec 12 02:38:35 03rwhitby * r80 10debian/trunk/ (Makefile patches/kernel/2.6.19/nas100d-support.patch): nas100d debian kernel that boots from internal hard disk **** ENDING LOGGING AT Tue Dec 12 02:59:57 2006