[01:42] <groz> mbm, is it possible to pass some kind of environment setup into the kernel boot with an append ?
[01:42] <groz> i'd like to set up so that the init script can check an env variable, and decide wether or not to pivot onto the stick
[01:43] <groz> then have 2 lilo options, one for 'ramdisk only' and one for 'from the stick'
[01:43] <groz> and the only difference, a kernel append of some type ?
[01:43] <groz> ok, guess you aren't here, off to find docs
[01:44] <CIA-17> mbm * r4573 /branches/buildroot-ng/openwrt/ (Makefile include/package.mk): Show error messages when collecting the package info
[01:44] <[mbm]> groz: yes, lilo is able to pass arguments to the kernel
[01:45] <groz> yes, but what i mean
[01:45] <groz> do you know an arguement off the top of your head
[01:45] <groz> to set an environement variable
[01:45] <[mbm]> after the kernel has booted you can't change the kernel commandline
[01:45] <groz> then what i wanna do
[01:45] <groz> 2 lilo stanzas
[01:45] <groz> one sets, one doesn't
[01:45] <groz> then my boot script will use that env variable
[01:45] <[mbm]> all unhandled kernel arguments are treated as global variables and show up in the environment
[01:45] <groz> to decide wether or not to pivot onto th estick
[01:45] <groz> ashhh, okl, that'll work
[01:46] <groz> kewl
[01:46] <[mbm]> so if you add foo=1 to the kernel arguments, you'll have a $foo set in userspace
[01:46] <groz> so if i add nopivot=1
[01:46] <groz> then i can check for that just before the pivot
[01:46] <groz> and if it's there, dont pivot
[01:46] <groz> and run from ram
[01:46] <groz> otherwise pivot onto the stick
[01:46] <groz> and then have a lilo menu on the serial console
[01:46] <[mbm]> should work
[01:47] <groz> the menu works, and i'm doing it now with 2 initrd files
[01:47] <groz> but seems a waste
[01:47] <[mbm]> right
[01:48] <groz> i was looking at stuff again last nite, saw that ticket about bzImage
[01:48] <groz> here's a thought
[01:48] <groz> if we add one more dynamic param on that command line
[01:48] <groz> then it can be set per arch
[01:48] <groz> and for x86 it will be bzImage
[01:48] <groz> for others, it can be blank
[01:48] <groz> or something else as required
[01:48] <groz> cuz the x86 builds do need it
[01:49] <groz> to get netboot and such type useable images
[01:49] <groz> i was going to do that here yet today
[01:49] <groz> unless you have a better idea or method ?
[01:49] <groz> just add a $KERNELNAME to the end of it
[01:50] <groz> default, define it as blank
[01:50] <groz> being called, back shortly
[01:52] <CIA-17> mbm * r4574 /packages/net/mini_httpd/Makefile: fix numerous typos in Makefile
[01:53] <[mbm]> am I the only one that sees all the errors in the packages?
[01:55] <CIA-17> mbm * r4575 /packages/net/openntpd/Makefile: correct .built rule
[02:00] <groz> no, but i'm not building much of them yet
[02:00] <groz> i tried a 'build all of them' it failed, turned em all off again
[02:00] <groz> will get back to that, when i got my hardware all running the way i want it
[02:02] <CIA-17> mbm * r4576 /packages/libs/libjpeg/Makefile: description mistakenly removed in [4455]
[02:02] <[mbm]> sad thing is that I did all of this two weeks ago
[02:12] <CIA-17> mbm * r4577 /branches/buildroot-ng/openwrt/include/package.mk: fix accidental tab
[02:33] <CIA-17> mbm * r4578 /branches/buildroot-ng/openwrt/include/package.mk: tidy up output
[02:46] <[mbm]> nbd: around?
[04:53] <groz> mbm, i got sidetracked to go for dinner, but, back, and, that works slick with the lilo options
[04:53] <groz> so now, it's set up with a lilo menu, and, uses the same kernel/init on each of them
[04:53] <groz> just doesn't pivot if you choose the ramdisk boot
[05:22] <[mbm]> much better
[05:22] <groz> just gonna clean up a little crap in here now
[05:23] <groz> another thing i did, i added a bit to kernel.mk and kernel-build.mk so that we end up with bzImage on the command line for x86 builds
[05:23] <groz> but not on all the others
[05:23] <groz> a little more findstring crap
[05:25] <groz> oh, another thing
[05:25] <groz> base-files/default/S10boot
[05:26] <groz> it sets eth0 promiscuous
[05:26] <groz> i know th ehistorical reason for that on wrt
[05:26] <groz> but
[05:26] <groz> does that still really belong in the 'default' ?
[05:26] <groz> i'm thinking that line can come out in default
[05:26] <groz> and possibly go in an S11boot in arch specific
[09:20] <CIA-17> groz * r4579 /branches/buildroot-ng/openwrt/include/ (image.mk kernel-build.mk kernel.mk): Build bzImage for x86 builds - allow ext2 images even if initramfs used, they are needed for creating boot images
[09:21] <[mbm]> groz: don't forget about the bzimage ticket
[09:22] <groz> i wont, i'l add some commentary and close it shortly
[09:22] <groz> but
[09:22] <groz> i want your feedback on the way i kludged it in
[09:22] <groz> very simple setup that may be useful in other spots on other builds too
[09:23] <groz> i did NOT propogate the bzImage files into the bin directory
[09:23] <groz> just made sure they get built
[09:24] <groz> it looked a little messy to do the rest, and i know you are working on that stuff now
[09:24] <groz> we'll just trip on each other
[09:29] <[mbm]> looks sane enough
[09:34] <CIA-17> groz * r4580 /branches/buildroot-ng/openwrt/target/linux/x86-2.4/config: Add ext2 as a compiled in on x86-2.4 so it's available for initrd on netboot and ext2 bootable images.
[09:36] <CIA-17> groz * r4581 /packages/utils/e2fsprogs/Makefile: Add resize2fs to the e2fsprogs ipkg
[09:38] <CIA-17> groz * r4582 /packages/utils/lilo/ (7 files): Add lilo package for use in making bootable images for x86
[09:43] <CIA-17> groz * r4583 /packages/utils/lilo/README: Add a readme to the lilo package explaining how to make a bootable usb stick
[09:44] <groz> there we go, start with a basic openwrt build, end up with an ext3 root running off of your usb stick
[09:45] <groz> currently at 'works for me' status, sure to need a few more tweaks to get more generalized
[09:46] <groz> mbm, in the new kmod stuff, AUTOLOAD seems to have no effect
[09:46] <groz> is this something you know anything about ?
[09:47] <[mbm]> it does, but only when used from the package/kernel
[09:47] <groz> well the packages i have set up
[09:47] <groz> dont seem to be generating anything in the modules.d directory
[09:47] <groz> akin to how the old style did
[09:47] <groz> just wondering if this is 'known broken' or 'not yet implemented', or 'i broke it' ?
[09:48] <[mbm]> right, really think we need to move that macro out of the kernel package and into something like kernel.mk
[09:48] <[mbm]> if you look at the package/kernel/Makefile you'll see how it works
[09:48] <groz> example, when i had the network drivers in the old style
[09:48] <groz> i got modules.d entries for them
[09:48] <[mbm]> ...
[09:48] <groz> now with the new one, i dont, and haven't really looked at why
[09:48] <[mbm]> I'll wait for you to catch up to what I just said :P
[09:49] <groz> i'm reading, i see , we wer typing at the same time
[09:49] <groz> ok, so this isn't something i broke, it's another 'needs some thought / fixing' thing
[09:50] <[mbm]> right, and it's been pointed out in forum posts as well
[09:50] <[mbm]> moving the functions to one of the include files should fix it
[09:50] <groz> hehe, i'm not the biggest reader of forums
[09:50] <[mbm]> but I haven't had time to dig into it
[09:50] <groz> my time better spent getting things working
[09:51] <[mbm]> I usually read the forums while waiting for the compiles
[09:51] <groz> yah, but some ass put ccache in, not much waiting now
[09:51] <groz> i haven't started messing with distcc yet
[09:52] <groz> but that's gonna make it even worse, never a chance to sit back and enjoy a relaxing coffee
[09:52] <groz> unless i delete the dl directory
[09:53] <[mbm]> yeah, that guy who added ccache really is an asshole; I used to be able to take really long coffee breaks
[09:53] <groz> LOL
[09:53] <groz> i thought i saw a hint of distcc at one time too
[09:54] <groz> but was wondering , to use that, does it magically migrate the correct compilers, or, do i have to move the tools over to all the boxes ?
[09:54] <[mbm]> possibly, but there isn't much point if everything hits cache
[09:54] <groz> true dat
[09:54] <[mbm]> you'd need a cross compiler on each box on your distcc network
[09:54] <groz> here's what my devious mind was considering
[09:54] <[mbm]> a network of wrts?
[09:55] <db90h> holy shit, distcc..that's awesme
[09:55] <groz> create a script that makes a minimal root fs, just enough to host the distcc
[09:55] <db90h> i never heard of distcc before, u linux guys sure have a lot of tricks up your sleeves
[09:55] <groz> then, u use that rootfs, with the colinux kernel i'm gonna have in before
[09:55] <groz> to long
[09:55] <groz> then i can propogate my builds out onto all my neighbors windows boxes
[09:55] <[mbm]> :)
[09:55] <groz> by just quietly installing a colinux service they dont know about
[09:55] <groz> over tyhier wide open wifi networks
[09:56] <[mbm]> I suspect that it'd only speed up package compiles since those are the only things we do in parallel
[09:56] <groz> but you are correct, with ccache working fine
[09:56] <groz> it's only really an issue if you do something like clean it all, and dump cache
[09:57] <groz> question , i haven't looked closely, does the -j parameter migrate down to the kernel build ?
[09:57] <[mbm]> nope, in fact it breaks it
[09:57] <groz> so the kernel makefil will run parallel processes during kernel build ?
[09:57] <groz> hmmm
[09:57] <[mbm]> you're supposed to set the number of jobs in the advanced menu
[09:57] <groz> i used to do make -j all the time building kernels
[09:57] <groz> yes, i do set that in the advanced
[09:58] <[mbm]> and that only gets applied to the package directory
[09:58] <groz> and have not really paid attention, to see if it prpogates down to the kernel makefile
[09:58] <[mbm]> (and only the packages directory, not any subdir)
[09:58] <groz> if the kernel is building serially with th rest
[09:58] <groz> it should be ok to do parrallel on it, if it's the only thing building
[09:58] <[mbm]> I was going to make it yell at you if you tried to do make -j directly
[09:58] Action: groz turns sound off
[09:59] <[mbm]> but I can't get it to parse MAKEFLAGS correctly
[09:59] <groz> oh, dont you love make
[10:00] <groz> i remember hearing you making noises about your love of make yesterday
[10:00] <[mbm]> it's fun when you can get it to do something it was never meant to do
[10:00] <[mbm]> but the trouble is, that's just about everything
[10:00] <groz> ok, now, you were considering recursive issues
[10:00] <groz> i got one for you
[10:00] <groz> we create the images last, after paackages
[10:00] <groz> but consider this idea for 'yet another package'
[10:00] <groz> i got a stick, bootable with lilo
[10:01] <groz> so now i create a new image, which ultimately gets used as initrd on the stick
[10:01] <groz> so after making the image
[10:01] <groz> i want to go back to packages, now create an ipk that includes the kernel and initrd files
[10:01] <groz> for updating kernel+initrd with simply ipkg install
[10:01] <groz> this can get terribly recursive
[10:02] <groz> with the current setup
[10:02] <[mbm]> well, I certainly wouldn't try to build all of that on the same pass
[10:02] <Kaloz> we are getting outside of normal usage here
[10:02] <Kaloz> :)
[10:02] <[mbm]> maybe a menu toggle to determine
[10:03] <groz> well, another idea maybe
[10:03] <groz> i can toss those things into the same directory as the package
[10:03] <[mbm]> still not thrilled that the x86 stuff is going in a totally different direction than the rest
[10:03] <groz> then create a package that wgets them
[10:03] <groz> how you mean totally different direction ?
[10:04] <[mbm]> the mechanisms you're using are different than what is being done elsewhere and the resulting scripts aren't portable to other platforms
[10:05] <groz> what i've been doing the last couple days, is what's needed to get the darn thing up and going, booting from local media
[10:06] <groz> once it's up, it's basically the same as anything else
[10:08] <groz> i've now got the point where my via board is 'just an openwrt router' that boots from a common memory stick
[10:08] <groz> and can be handled as 'ipkg install' from here on out
[10:09] <[mbm]> well, the broadcom platforms will never be an 'ipkg install' for an upgrade
[10:09] <groz> why not, i've been doing it for a year now
[10:09] <[mbm]> just a mess with the kernel outside of the root filesystem
[10:09] <groz> and i was _planning_ on creating scripts to do that
[10:10] <groz> it's not hard actually, you toss your trx into your repository directory
[10:10] <[mbm]> I'm thinking a nondestructive upgrade ;)
[10:10] <groz> then you have a package that includes a script to wget the trx, create a root on tmpfs, pivot onto it
[10:10] <groz> and then mtd write
[10:11] <groz> well, you wont do a kernel non destructive on those
[10:11] <groz> true
[10:11] <groz> that's the nature of the flash beast
[10:11] <groz> unless the new one is EXACTLY the same size as the old
[10:11] <[mbm]> well, there's ways around that but it takes up more flash space
[10:11] <[mbm]> although I still have a few ideas
[10:11] <groz> but i thought it's kinda nice to have a non destructive upgrade path on the x86
[10:12] <[mbm]> well, for the x86 it's just 'ipkg upgrade' and let it updead individual packages
[10:12] <[mbm]> er .. can't type .. update
[10:12] <groz> yes, and can do the same with a kernel
[10:12] <[mbm]> right, with a postinst script that runs lilo
[10:13] <groz> just put a new one on, and adivse <insert boot loader here> name of the new one
[10:13] <groz> yah, in this case, i used lilo
[10:13] <[mbm]> yep, actually if you were using grub you'd never have to change it
[10:13] <groz> wont be long, somebody will fix up grub, or uboot, or what have you
[10:13] <[mbm]> I'm a big fan of grub, even if it is overkill
[10:13] <groz> i was fighting grub to get it to install on 'just a file', and same issue as lilo, it WANTS to have an actual block device to install
[10:14] <[mbm]> you can fix that
[10:14] <groz> i though extlinux would be the holy grail, but, it never got the mapping right on my usb sticks, never once got it to successfuly boot the stick
[10:14] <[mbm]> it probes the devices and writes out a map
[10:14] <[mbm]> go and change that map
[10:15] Action: [mbm] ran into the same problems trying to get a laptop to boot with grub
[10:15] <groz> yah, i just went back to lilo, because it's something i've used a lot like this, and i got tired of fussing, reading manuals, etc, just went and repeated what i've done before, cuz i need to get this one box up and running
[10:15] <groz> it's always been flawless with lilo and usb sticks
[10:15] <[mbm]> I have a usb stick here with grub that boots an encrypted filesystem with ubuntu on it
[10:15] <groz> as long as you configure lilo for lba
[10:16] <[mbm]> so far the stick works on any computer that can boot usb
[10:16] <groz> yes, but, can you create that without putting the stick into the computer
[10:16] <groz> ie can you create it in an image
[10:16] <[mbm]> probably
[10:16] <groz> then send it across the net, and dd it onto a remote stick
[10:16] <groz> and have it come up
[10:17] <[mbm]> the two tricks are using the mbr utility to write out an mbr that remaps the drives correctly, and playing with grub's map file so you can get it to use non hda devices
[10:17] <groz> everyting i found about installing it, there was an underlying assumption, the media was physically attached at th epiont of install
[10:18] <groz> ultimately i need to create images that i can just write onto a flash stick
[10:18] <[mbm]> right
[10:18] <groz> using rawrite on a windows box if necessary
[10:18] <[mbm]> I'll give it a shot tomorrow
[10:18] <groz> ie i want to be able to send the image to somebody over the net
[10:18] <groz> and if they have only windows, still be able to write the stick
[10:18] <groz> plug it into a box, and up it comes
[10:18] <groz> i consider that the 'holy grail'
[10:19] <[mbm]> my test will be creating a grub image that boots into something simple like memtest86
[10:19] <groz> i'll fuss more with grub when i have a little more time to play with it
[10:19] <[mbm]> that you can just dd onto a stick
[10:19] <groz> yah, once the mechanism to get it on, and have it load something is there
[10:19] <groz> it's trivial
[10:19] <groz> but, will grub work on non partitioned media too ?
[10:19] <groz> or does it rely on paritioned media ?
[10:20] <[mbm]> I still think that non partitioned was an odd choice
[10:20] <groz> its not
[10:20] <groz> here's why
[10:20] <[mbm]> lvm would have been more fun
[10:20] <[mbm]> yes you've explained why several times now, it doesn't change the fact I don't agree with it
[10:20] <groz> you can resize it on the fly, easily, without having to fuss with partition tables, which imply understanding the mapping
[10:20] <[mbm]> have you ever played with lvm?
[10:20] <groz> and the mapping changes from machine to machine
[10:21] <groz> no, i haven't
[10:21] <[mbm]> you should.
[10:21] <groz> hehe, i may be able to now, i may actually be doing some target devices that are bigger boxes
[10:21] <[mbm]> I have a /dev/vg/root .. it doesn't matter how my drives are connected, it's always the same name
[10:21] <groz> more than 4 meg flash, 16 meg ram
[10:22] <[mbm]> and, if I add more drives to the system, I can pool them and make /dev/vg/root even larger than any physical volume
[10:22] <groz> ok, now have great fun, and do it in hotplug as usb sticks come and go
[10:23] <[mbm]> which means that for your x86 box if I ever run out of space, I'd just toss in another stick and it would expand or migrate the root filesystem
[10:23] <[mbm]> (although if you expand it to include both sticks and you unplug one, naturally it crashes)
[10:23] <groz> yah, but one demo i have in mind for a client, is to set the via up with raid 5 on 3 sticks, then, hotswap sticks on the fly
[10:24] <groz> pull one out, drop a fresh blank one in
[10:24] <groz> easy way to do it, with a trivial hardware setup, they will 'get it'
[10:24] <[mbm]> yeah, if you had raid you could do some fun stuff with parity to avoid data loss when a drive is removed
[10:24] <[mbm]> lvm really doesn't deal with those issues
[10:25] <groz> ofc not
[10:25] <groz> lvm can sit on top of raid
[10:25] <[mbm]> lvm is mostly about pooling block devices into larger block devices
[10:25] <groz> let the raid layer deal with those issues
[10:25] <[mbm]> right.
[10:25] <groz> you pop in 3 more drives, make em a raid 5, then join em to the lvm group
[10:25] <groz> to add redundant store
[10:26] <groz> iin the case in pariticular that i'm planning on deploying this
[10:26] <groz> extreme harsh environment, data collection box
[10:26] <groz> i want to raid the flash setup on it
[10:26] <groz> cuz, it's a VERY expensive helicopter ride to visit the box
[10:27] <groz> so i want redundancy, on solid state
[10:27] <groz> no moving parts
[10:27] <[mbm]> oh, I should point out one major caveat with lvm .. grub absolutely hates booting from an lvm volume (you have to do some painful and annoying stuff to patch grub to even attempt it)
[10:27] <groz> speed is not an issue, it's logging data from serial inputs
[10:27] <groz> but it's in an extremely remote location
[10:29] <groz> heh, well, like i said, when i got some more time, i'll re-visit grub, for now tho, lilo works, gets me to the point where i've got an 'openwrt via box'
[10:29] <[mbm]> :)
[10:29] <groz> next, the routerboard 220 i have on the desk here
[10:29] <groz> it's cf, mapped as /dev/hda
[10:29] <Kaloz> 230 you mean
[10:30] <groz> no, 220
[10:30] <Kaloz> is there a 220? o.O
[10:30] <groz> same board, some bits missing
[10:30] <Kaloz> ah
[10:30] <Kaloz> i see
[10:30] <groz> actually, i have a 230 you are right
[10:30] <groz> but client shipped product on the 220
[10:31] <groz> if i remember correctly, only one pcmcia,a nd the pci slots missing too
[10:32] <groz> mbm, got another dumb question tho, for the defaults on ipkg.conf, is the plan to set up a ach heirarchy ?
[10:32] <groz> arch
[10:32] <groz> or, is th eplan to not host packages at all ?
[10:33] <[mbm]> we tried the 'not hosting packages' approach before, it failed misterably
[10:35] <groz> i may be able to co-erce a client to provide a high bandwidth box
[10:35] <groz> for hosting
[10:35] <groz> depends on how badly it's gonna get hit
[10:35] <Kaloz> bw or traffic isn't an issue
[10:36] <Kaloz> we just didn't want to host kamikaze stuff
[10:36] <groz> ok
[10:37] <Kaloz> groz: arrakis has no bw or traffic limit (well the bw cannot be more then 100Mbits/s, as I pay for that only :)
[10:38] <groz> ok, hehe
[10:38] <groz> well i dont know the setup there, so, dont know what the deal is
[10:38] <groz> but if bw or traffic is an issue
[10:38] <groz> i can possibly try set something up to divert
[10:38] <groz> but if it's not an issue then just forget i said anything
[10:39] <Kaloz> it was just a "political" decision :)
[10:53] Action: groz pleased with my new setup on this via, i got a 'make all packages for it' build running now
[10:54] <groz> wonder how many are gonna puke
[11:02] <Bartman007> speaking of puking packages, should I submit a bug report for the ipset issue? (discussed it briefly with mbm yesterday)
[11:03] <[mbm]> there's actually a few packages which don't compile right now
[11:03] <[mbm]> hostap and kismet also come to mind
[11:04] <[mbm]> I'm constantly doing rebuilds of the entire package tree looking for broken packages
[11:05] <Bartman007> i had ntp-client break a few days ago, but looks like it was just a glitch, haven't been able to duplicate it
[11:06] <[mbm]> I have about a dozen patches that I haven't commited yet for various packages .. testing to make sure that everything works first
[11:07] <[mbm]> ... hrm .. this is annoying ..
[11:07] <[mbm]> my shiney new dvd burner has a firmware upgrade, but can only be upgraded from windows
[11:08] <Bartman007> there are linux utils for some manufactures
[11:08] <Bartman007> what brand is it?
[11:08] <[mbm]> it's a plextor 755SA
[11:08] <[mbm]> I haven't found any info on it yet
[11:08] <[mbm]> even a dos util would be helpful
[11:08] <Bartman007> ah, I haven't run across any either (probably becauase I don't have any plextors)
[11:09] <[mbm]> heh.. plextor is a good brand when you want an EXACT copy of a disc :)
[11:09] <Bartman007> I'll stick with my NECs :-)
[11:10] <[mbm]> it burns everything including subchannels
[11:10] <[mbm]> plus, it's one of the few that make serial ata
[11:10] <Bartman007> a serial ata dvd drive that actually works?
[11:11] <[mbm]> yep.
[11:11] <Bartman007> tried booting from it yet?
[11:11] <[mbm]> let me finish running memtest and then I'll stick in a ubuntu cd and let you know
[11:15] <Bartman007> I found something that works at least for IDE drives.
[11:16] <Bartman007> http://crashrecovery.org/oss-dvd/DL/px716.php
[11:18] <[mbm]> hmm booted the ubuntu cd fine
[11:19] <[mbm]> the only issue I've had with it so far is that gnome seems to check the media status too fast and reports 'no disc', but it works fine if I manually mount the drive
[11:22] <[mbm]> hmm interesting
[11:23] <Bartman007> hmm, i should get some sleep, gotta be up in 5 hours.
[11:23] <Bartman007> tomorrow I'll have to edit my pl2303 driver header for one of my serial cables and get my 7001 going.
[11:24] <[mbm]> hmm think I'll let the memtest burn in a little more before I try upgrading the drive's firmware
[11:26] <[mbm]> http://qpxtool.sourceforge.net/faq.html#fwupdate :)
[11:27] <Bartman007> heh, cool
[11:27] <Bartman007> so the program I found doesn't work with sata
[11:42] <[mbm]> Data transfer complete: 2031616 bytes (1F0 blocks). Updating...
[11:42] <[mbm]> FW update complete!
[11:42] <[mbm]> ;)
[11:43] <Kaloz> hmz
[11:43] <Kaloz> more then 2MB
[11:43] <Kaloz> i would check what's inside :P
[11:47] <[mbm]> not much in terms of strings
[11:47] <[mbm]> although there does seem to be a table of cd brands
[11:48] <[mbm]> MAXELL
[11:48] <[mbm]> SONY
[11:48] <[mbm]> CMC MAG
[11:48] <[mbm]> RITEK
[11:48] <[mbm]> ...
[15:55] <[florian]> I am back
[15:57] <[florian]> had some holidays
[18:48] <Bartman007> [mbm]: dvd firmware generally contains speed settings for various bands/types of media as some don't perform up to what they say they are rated for, and others (like many TY discs) can perform past what they are rated for
[19:07] <[florian]> no one here ?
[19:10] <nbd> i'm here
[19:10] <[florian]> ah ok
[19:35] <[florian]> I have just made a small utility to choose the system services : http://pastebin.ca/136408
[19:36] <[florian]> tell me if you think it is worth integrating it
[19:38] <nbd> i think we shouldn't hardcode protected services in the script
[19:38] <nbd> it would probably be better to have a convention that forces all non-essential services to start at 50 or something like that
[19:38] <nbd> but it looks ok to me otherwise
[19:38] <nbd> we should wait for feedback from the other devs
[19:39] <[florian]> sure
[19:39] <[florian]> it's just a proof of concept actually
[20:08] <[florian]> uml is not x86-specific right ?
[20:09] <groz> in theorty no, but theory and reality dont always blend well
[20:11] <CIA-17> nbd * r4584 /branches/buildroot-ng/openwrt/include/kernel.mk: fix KERNELNAME
[20:19] <[florian]> ok, then I will do a quick check on my ppc machine :)
[20:20] <groz> but you are probably right, it shouldn't build as an x86 derivative, should probably become a tree of it's own
[20:20] <groz> the _real_ reason i did it that way the first time, so it wouldn't build another toolchain
[20:21] <nbd> iirc uml is x86 specific at the moment
[20:21] <nbd> and there was a long discussion on lkml on whether it should be moved into arch/i386
[20:21] <groz> do you mean 'our build of it' or 'uml in general' ?
[20:21] <nbd> uml in general
[20:21] <groz> ahhh, ok
[20:22] <groz> i do know there are also some issues with it on x64
[20:24] <[florian]> ok then no need to have a try on ppc :)
[20:25] <[florian]> I'd better reinstall macosx and do some toolchain portability
[20:29] <Bartman007> groz: some issues is an understatement based on my limited dealings with it (a while back)
[20:29] <groz> uh huh
[20:35] <murb> groz: ia64 or x86_64?
[20:36] <groz> x86_64
[20:37] <murb> I've still not got my new x86_64 toy :(
[20:37] <murb> I hope it arrives before my pile of wgt634us
[20:37] <db90h> is ia64 still alive? ;p
[20:37] <murb> db90h: yes
[20:38] <db90h> what a miserable failure that was.. and we all saw its failure coming i think, at least i predicted it
[20:38] <db90h> too big a change to the instruction set.. sure, it's more optimal, but you ahve to maintain efficient backwards compatibility, that's the #1 rule
[20:38] <nbd> yeah, too expensive, horribly complex
[20:38] <dragorn> db90h: if I recall they sacrificed integer speed for floating point
[20:39] <murb> although it does make alpha look like a complete success.
[20:40] <db90h> the instruction set was designed to be generated by an optimizing C compiler.. to code it by hand would have been inpractical
[20:40] <Bartman007> murb: well, it was alpha's bastard child....
[20:40] <db90h> ...at least, from what i know of it.. i didn't spend much time researching it
[20:41] <db90h> if i had some money a few years ago i would have invested in AMD, cuz it seemed so obvious to me that AMD would win in the 64-bit switch
[20:42] <groz> there's a difference between 'gaining market share' and 'making a profit'
[20:42] <nbd> did intel ever buy any significant technology from amd before the 64 bit stuff?
[20:42] <db90h> of course, nothing quite as safe as saying how much money one would have made of investments one didn't make
[20:42] <db90h> nbd: i don't know
[20:42] <db90h> i am not sure all their licensing agreements
[20:44] <db90h> groz: true that ;).. AMD is so broke compared to Intel still today.. they have lost shitloads of money in the recent past
[20:44] <db90h> AND == huge debt
[20:44] <Kaloz> [20:42:32] < nbd> did intel ever buy any significant technology from amd before the 64 bit stuff?
[20:44] <Kaloz> nbd: they just "RE"d it
[20:44] <nbd> they did?
[20:44] <nbd> i thought they had an agreement on it
[20:44] <Kaloz> yeah
[20:45] <Kaloz> nope.. they would never agree to officially get something :P
[20:45] <nbd> well, that explains why they're not doing any effort to actually market it properly :)
[20:45] <Kaloz> from amd i mean
[20:45] <Kaloz> well, their em64t stinks anyway
[20:46] <Kaloz> basically the main problem is that for amd, amd64 is the netive environment, and it's "emulating" ia32
[20:46] <db90h> i hear their virtualization isn't as good as AMD's as well
[20:46] <Kaloz> em64t itself means "emulated 64bit technology"
[20:46] <Kaloz> the cpu is still an ia32, and em64t is an extension
[20:47] <Kaloz> this is true for p4, no idea if they made core 2 different
[20:47] <db90h> gotta love seeing a corporate giant fall on its face
[20:47] <Kaloz> but according to the tests, core 2 is faster at 32bit.. but all of the tests are mainly about gaming and stuff
[20:47] <Kaloz> not some linux-related tests
[20:48] <Kaloz> playing with the idea to get one and check it, but honestly i've always burnt myself when i've touched intel's x86 stuff
[20:48] <Kaloz> i love xscale, thoe
[20:48] <Kaloz> :)
[21:54] <BrainSlayer2> yep
[21:54] <BrainSlayer2> i fixed the serial problem
[21:55] <BrainSlayer2> you can find the fix in my svn
[21:55] <BrainSlayer2> just download the driver. you have 2 misstakes in yours. additionally i restructured some parts in it which is not important for you
[21:56] <[florian]> what do you mean by not important ?
[22:00] <BrainSlayer2> some code design changes
[22:00] <BrainSlayer2> just to make it looking better
[22:00] <[florian]> I have to fix the bootloader detection, because most devices outside france are using a CFE, but we have RedBoot here with Liveboxes
[23:22] <CIA-17> nbd * r4585 /branches/whiterussian/openwrt/package/base-files/default/etc/init.d/S05nvram: remove sdram_config fixup - not necessary for linksys and breaks whr-g54s
[00:00] --- Fri Aug 18 2006
[01:42] <groz> i'd like to set up so that the init script can check an env variable, and decide wether or not to pivot onto the stick
[01:43] <groz> then have 2 lilo options, one for 'ramdisk only' and one for 'from the stick'
[01:43] <groz> and the only difference, a kernel append of some type ?
[01:43] <groz> ok, guess you aren't here, off to find docs
[01:44] <CIA-17> mbm * r4573 /branches/buildroot-ng/openwrt/ (Makefile include/package.mk): Show error messages when collecting the package info
[01:44] <[mbm]> groz: yes, lilo is able to pass arguments to the kernel
[01:45] <groz> yes, but what i mean
[01:45] <groz> do you know an arguement off the top of your head
[01:45] <groz> to set an environement variable
[01:45] <[mbm]> after the kernel has booted you can't change the kernel commandline
[01:45] <groz> then what i wanna do
[01:45] <groz> 2 lilo stanzas
[01:45] <groz> one sets, one doesn't
[01:45] <groz> then my boot script will use that env variable
[01:45] <[mbm]> all unhandled kernel arguments are treated as global variables and show up in the environment
[01:45] <groz> to decide wether or not to pivot onto th estick
[01:45] <groz> ashhh, okl, that'll work
[01:46] <groz> kewl
[01:46] <[mbm]> so if you add foo=1 to the kernel arguments, you'll have a $foo set in userspace
[01:46] <groz> so if i add nopivot=1
[01:46] <groz> then i can check for that just before the pivot
[01:46] <groz> and if it's there, dont pivot
[01:46] <groz> and run from ram
[01:46] <groz> otherwise pivot onto the stick
[01:46] <groz> and then have a lilo menu on the serial console
[01:46] <[mbm]> should work
[01:47] <groz> the menu works, and i'm doing it now with 2 initrd files
[01:47] <groz> but seems a waste
[01:47] <[mbm]> right
[01:48] <groz> i was looking at stuff again last nite, saw that ticket about bzImage
[01:48] <groz> here's a thought
[01:48] <groz> if we add one more dynamic param on that command line
[01:48] <groz> then it can be set per arch
[01:48] <groz> and for x86 it will be bzImage
[01:48] <groz> for others, it can be blank
[01:48] <groz> or something else as required
[01:48] <groz> cuz the x86 builds do need it
[01:49] <groz> to get netboot and such type useable images
[01:49] <groz> i was going to do that here yet today
[01:49] <groz> unless you have a better idea or method ?
[01:49] <groz> just add a $KERNELNAME to the end of it
[01:50] <groz> default, define it as blank
[01:50] <groz> being called, back shortly
[01:52] <CIA-17> mbm * r4574 /packages/net/mini_httpd/Makefile: fix numerous typos in Makefile
[01:53] <[mbm]> am I the only one that sees all the errors in the packages?
[01:55] <CIA-17> mbm * r4575 /packages/net/openntpd/Makefile: correct .built rule
[02:00] <groz> no, but i'm not building much of them yet
[02:00] <groz> i tried a 'build all of them' it failed, turned em all off again
[02:00] <groz> will get back to that, when i got my hardware all running the way i want it
[02:02] <CIA-17> mbm * r4576 /packages/libs/libjpeg/Makefile: description mistakenly removed in [4455]
[02:02] <[mbm]> sad thing is that I did all of this two weeks ago
[02:12] <CIA-17> mbm * r4577 /branches/buildroot-ng/openwrt/include/package.mk: fix accidental tab
[02:33] <CIA-17> mbm * r4578 /branches/buildroot-ng/openwrt/include/package.mk: tidy up output
[02:46] <[mbm]> nbd: around?
[04:53] <groz> mbm, i got sidetracked to go for dinner, but, back, and, that works slick with the lilo options
[04:53] <groz> so now, it's set up with a lilo menu, and, uses the same kernel/init on each of them
[04:53] <groz> just doesn't pivot if you choose the ramdisk boot
[05:22] <[mbm]> much better
[05:22] <groz> just gonna clean up a little crap in here now
[05:23] <groz> another thing i did, i added a bit to kernel.mk and kernel-build.mk so that we end up with bzImage on the command line for x86 builds
[05:23] <groz> but not on all the others
[05:23] <groz> a little more findstring crap
[05:25] <groz> oh, another thing
[05:25] <groz> base-files/default/S10boot
[05:26] <groz> it sets eth0 promiscuous
[05:26] <groz> i know th ehistorical reason for that on wrt
[05:26] <groz> but
[05:26] <groz> does that still really belong in the 'default' ?
[05:26] <groz> i'm thinking that line can come out in default
[05:26] <groz> and possibly go in an S11boot in arch specific
[09:20] <CIA-17> groz * r4579 /branches/buildroot-ng/openwrt/include/ (image.mk kernel-build.mk kernel.mk): Build bzImage for x86 builds - allow ext2 images even if initramfs used, they are needed for creating boot images
[09:21] <[mbm]> groz: don't forget about the bzimage ticket
[09:22] <groz> i wont, i'l add some commentary and close it shortly
[09:22] <groz> but
[09:22] <groz> i want your feedback on the way i kludged it in
[09:22] <groz> very simple setup that may be useful in other spots on other builds too
[09:23] <groz> i did NOT propogate the bzImage files into the bin directory
[09:23] <groz> just made sure they get built
[09:24] <groz> it looked a little messy to do the rest, and i know you are working on that stuff now
[09:24] <groz> we'll just trip on each other
[09:29] <[mbm]> looks sane enough
[09:34] <CIA-17> groz * r4580 /branches/buildroot-ng/openwrt/target/linux/x86-2.4/config: Add ext2 as a compiled in on x86-2.4 so it's available for initrd on netboot and ext2 bootable images.
[09:36] <CIA-17> groz * r4581 /packages/utils/e2fsprogs/Makefile: Add resize2fs to the e2fsprogs ipkg
[09:38] <CIA-17> groz * r4582 /packages/utils/lilo/ (7 files): Add lilo package for use in making bootable images for x86
[09:43] <CIA-17> groz * r4583 /packages/utils/lilo/README: Add a readme to the lilo package explaining how to make a bootable usb stick
[09:44] <groz> there we go, start with a basic openwrt build, end up with an ext3 root running off of your usb stick
[09:45] <groz> currently at 'works for me' status, sure to need a few more tweaks to get more generalized
[09:46] <groz> mbm, in the new kmod stuff, AUTOLOAD seems to have no effect
[09:46] <groz> is this something you know anything about ?
[09:47] <[mbm]> it does, but only when used from the package/kernel
[09:47] <groz> well the packages i have set up
[09:47] <groz> dont seem to be generating anything in the modules.d directory
[09:47] <groz> akin to how the old style did
[09:47] <groz> just wondering if this is 'known broken' or 'not yet implemented', or 'i broke it' ?
[09:48] <[mbm]> right, really think we need to move that macro out of the kernel package and into something like kernel.mk
[09:48] <[mbm]> if you look at the package/kernel/Makefile you'll see how it works
[09:48] <groz> example, when i had the network drivers in the old style
[09:48] <groz> i got modules.d entries for them
[09:48] <[mbm]> ...
[09:48] <groz> now with the new one, i dont, and haven't really looked at why
[09:48] <[mbm]> I'll wait for you to catch up to what I just said :P
[09:49] <groz> i'm reading, i see , we wer typing at the same time
[09:49] <groz> ok, so this isn't something i broke, it's another 'needs some thought / fixing' thing
[09:50] <[mbm]> right, and it's been pointed out in forum posts as well
[09:50] <[mbm]> moving the functions to one of the include files should fix it
[09:50] <groz> hehe, i'm not the biggest reader of forums
[09:50] <[mbm]> but I haven't had time to dig into it
[09:50] <groz> my time better spent getting things working
[09:51] <[mbm]> I usually read the forums while waiting for the compiles
[09:51] <groz> yah, but some ass put ccache in, not much waiting now
[09:51] <groz> i haven't started messing with distcc yet
[09:52] <groz> but that's gonna make it even worse, never a chance to sit back and enjoy a relaxing coffee
[09:52] <groz> unless i delete the dl directory
[09:53] <[mbm]> yeah, that guy who added ccache really is an asshole; I used to be able to take really long coffee breaks
[09:53] <groz> LOL
[09:53] <groz> i thought i saw a hint of distcc at one time too
[09:54] <groz> but was wondering , to use that, does it magically migrate the correct compilers, or, do i have to move the tools over to all the boxes ?
[09:54] <[mbm]> possibly, but there isn't much point if everything hits cache
[09:54] <groz> true dat
[09:54] <[mbm]> you'd need a cross compiler on each box on your distcc network
[09:54] <groz> here's what my devious mind was considering
[09:54] <[mbm]> a network of wrts?
[09:55] <db90h> holy shit, distcc..that's awesme
[09:55] <groz> create a script that makes a minimal root fs, just enough to host the distcc
[09:55] <db90h> i never heard of distcc before, u linux guys sure have a lot of tricks up your sleeves
[09:55] <groz> then, u use that rootfs, with the colinux kernel i'm gonna have in before
[09:55] <groz> to long
[09:55] <groz> then i can propogate my builds out onto all my neighbors windows boxes
[09:55] <[mbm]> :)
[09:55] <groz> by just quietly installing a colinux service they dont know about
[09:55] <groz> over tyhier wide open wifi networks
[09:56] <[mbm]> I suspect that it'd only speed up package compiles since those are the only things we do in parallel
[09:56] <groz> but you are correct, with ccache working fine
[09:56] <groz> it's only really an issue if you do something like clean it all, and dump cache
[09:57] <groz> question , i haven't looked closely, does the -j parameter migrate down to the kernel build ?
[09:57] <[mbm]> nope, in fact it breaks it
[09:57] <groz> so the kernel makefil will run parallel processes during kernel build ?
[09:57] <groz> hmmm
[09:57] <[mbm]> you're supposed to set the number of jobs in the advanced menu
[09:57] <groz> i used to do make -j all the time building kernels
[09:57] <groz> yes, i do set that in the advanced
[09:58] <[mbm]> and that only gets applied to the package directory
[09:58] <groz> and have not really paid attention, to see if it prpogates down to the kernel makefile
[09:58] <[mbm]> (and only the packages directory, not any subdir)
[09:58] <groz> if the kernel is building serially with th rest
[09:58] <groz> it should be ok to do parrallel on it, if it's the only thing building
[09:58] <[mbm]> I was going to make it yell at you if you tried to do make -j directly
[09:58] Action: groz turns sound off
[09:59] <[mbm]> but I can't get it to parse MAKEFLAGS correctly
[09:59] <groz> oh, dont you love make
[10:00] <groz> i remember hearing you making noises about your love of make yesterday
[10:00] <[mbm]> it's fun when you can get it to do something it was never meant to do
[10:00] <[mbm]> but the trouble is, that's just about everything
[10:00] <groz> ok, now, you were considering recursive issues
[10:00] <groz> i got one for you
[10:00] <groz> we create the images last, after paackages
[10:00] <groz> but consider this idea for 'yet another package'
[10:00] <groz> i got a stick, bootable with lilo
[10:01] <groz> so now i create a new image, which ultimately gets used as initrd on the stick
[10:01] <groz> so after making the image
[10:01] <groz> i want to go back to packages, now create an ipk that includes the kernel and initrd files
[10:01] <groz> for updating kernel+initrd with simply ipkg install
[10:01] <groz> this can get terribly recursive
[10:02] <groz> with the current setup
[10:02] <[mbm]> well, I certainly wouldn't try to build all of that on the same pass
[10:02] <Kaloz> we are getting outside of normal usage here
[10:02] <Kaloz> :)
[10:02] <[mbm]> maybe a menu toggle to determine
[10:03] <groz> well, another idea maybe
[10:03] <groz> i can toss those things into the same directory as the package
[10:03] <[mbm]> still not thrilled that the x86 stuff is going in a totally different direction than the rest
[10:03] <groz> then create a package that wgets them
[10:03] <groz> how you mean totally different direction ?
[10:04] <[mbm]> the mechanisms you're using are different than what is being done elsewhere and the resulting scripts aren't portable to other platforms
[10:05] <groz> what i've been doing the last couple days, is what's needed to get the darn thing up and going, booting from local media
[10:06] <groz> once it's up, it's basically the same as anything else
[10:08] <groz> i've now got the point where my via board is 'just an openwrt router' that boots from a common memory stick
[10:08] <groz> and can be handled as 'ipkg install' from here on out
[10:09] <[mbm]> well, the broadcom platforms will never be an 'ipkg install' for an upgrade
[10:09] <groz> why not, i've been doing it for a year now
[10:09] <[mbm]> just a mess with the kernel outside of the root filesystem
[10:09] <groz> and i was _planning_ on creating scripts to do that
[10:10] <groz> it's not hard actually, you toss your trx into your repository directory
[10:10] <[mbm]> I'm thinking a nondestructive upgrade ;)
[10:10] <groz> then you have a package that includes a script to wget the trx, create a root on tmpfs, pivot onto it
[10:10] <groz> and then mtd write
[10:11] <groz> well, you wont do a kernel non destructive on those
[10:11] <groz> true
[10:11] <groz> that's the nature of the flash beast
[10:11] <groz> unless the new one is EXACTLY the same size as the old
[10:11] <[mbm]> well, there's ways around that but it takes up more flash space
[10:11] <[mbm]> although I still have a few ideas
[10:11] <groz> but i thought it's kinda nice to have a non destructive upgrade path on the x86
[10:12] <[mbm]> well, for the x86 it's just 'ipkg upgrade' and let it updead individual packages
[10:12] <[mbm]> er .. can't type .. update
[10:12] <groz> yes, and can do the same with a kernel
[10:12] <[mbm]> right, with a postinst script that runs lilo
[10:13] <groz> just put a new one on, and adivse <insert boot loader here> name of the new one
[10:13] <groz> yah, in this case, i used lilo
[10:13] <[mbm]> yep, actually if you were using grub you'd never have to change it
[10:13] <groz> wont be long, somebody will fix up grub, or uboot, or what have you
[10:13] <[mbm]> I'm a big fan of grub, even if it is overkill
[10:13] <groz> i was fighting grub to get it to install on 'just a file', and same issue as lilo, it WANTS to have an actual block device to install
[10:14] <[mbm]> you can fix that
[10:14] <groz> i though extlinux would be the holy grail, but, it never got the mapping right on my usb sticks, never once got it to successfuly boot the stick
[10:14] <[mbm]> it probes the devices and writes out a map
[10:14] <[mbm]> go and change that map
[10:15] Action: [mbm] ran into the same problems trying to get a laptop to boot with grub
[10:15] <groz> yah, i just went back to lilo, because it's something i've used a lot like this, and i got tired of fussing, reading manuals, etc, just went and repeated what i've done before, cuz i need to get this one box up and running
[10:15] <groz> it's always been flawless with lilo and usb sticks
[10:15] <[mbm]> I have a usb stick here with grub that boots an encrypted filesystem with ubuntu on it
[10:15] <groz> as long as you configure lilo for lba
[10:16] <[mbm]> so far the stick works on any computer that can boot usb
[10:16] <groz> yes, but, can you create that without putting the stick into the computer
[10:16] <groz> ie can you create it in an image
[10:16] <[mbm]> probably
[10:16] <groz> then send it across the net, and dd it onto a remote stick
[10:16] <groz> and have it come up
[10:17] <[mbm]> the two tricks are using the mbr utility to write out an mbr that remaps the drives correctly, and playing with grub's map file so you can get it to use non hda devices
[10:17] <groz> everyting i found about installing it, there was an underlying assumption, the media was physically attached at th epiont of install
[10:18] <groz> ultimately i need to create images that i can just write onto a flash stick
[10:18] <[mbm]> right
[10:18] <groz> using rawrite on a windows box if necessary
[10:18] <[mbm]> I'll give it a shot tomorrow
[10:18] <groz> ie i want to be able to send the image to somebody over the net
[10:18] <groz> and if they have only windows, still be able to write the stick
[10:18] <groz> plug it into a box, and up it comes
[10:18] <groz> i consider that the 'holy grail'
[10:19] <[mbm]> my test will be creating a grub image that boots into something simple like memtest86
[10:19] <groz> i'll fuss more with grub when i have a little more time to play with it
[10:19] <[mbm]> that you can just dd onto a stick
[10:19] <groz> yah, once the mechanism to get it on, and have it load something is there
[10:19] <groz> it's trivial
[10:19] <groz> but, will grub work on non partitioned media too ?
[10:19] <groz> or does it rely on paritioned media ?
[10:20] <[mbm]> I still think that non partitioned was an odd choice
[10:20] <groz> its not
[10:20] <groz> here's why
[10:20] <[mbm]> lvm would have been more fun
[10:20] <[mbm]> yes you've explained why several times now, it doesn't change the fact I don't agree with it
[10:20] <groz> you can resize it on the fly, easily, without having to fuss with partition tables, which imply understanding the mapping
[10:20] <[mbm]> have you ever played with lvm?
[10:20] <groz> and the mapping changes from machine to machine
[10:21] <groz> no, i haven't
[10:21] <[mbm]> you should.
[10:21] <groz> hehe, i may be able to now, i may actually be doing some target devices that are bigger boxes
[10:21] <[mbm]> I have a /dev/vg/root .. it doesn't matter how my drives are connected, it's always the same name
[10:21] <groz> more than 4 meg flash, 16 meg ram
[10:22] <[mbm]> and, if I add more drives to the system, I can pool them and make /dev/vg/root even larger than any physical volume
[10:22] <groz> ok, now have great fun, and do it in hotplug as usb sticks come and go
[10:23] <[mbm]> which means that for your x86 box if I ever run out of space, I'd just toss in another stick and it would expand or migrate the root filesystem
[10:23] <[mbm]> (although if you expand it to include both sticks and you unplug one, naturally it crashes)
[10:23] <groz> yah, but one demo i have in mind for a client, is to set the via up with raid 5 on 3 sticks, then, hotswap sticks on the fly
[10:24] <groz> pull one out, drop a fresh blank one in
[10:24] <groz> easy way to do it, with a trivial hardware setup, they will 'get it'
[10:24] <[mbm]> yeah, if you had raid you could do some fun stuff with parity to avoid data loss when a drive is removed
[10:24] <[mbm]> lvm really doesn't deal with those issues
[10:25] <groz> ofc not
[10:25] <groz> lvm can sit on top of raid
[10:25] <[mbm]> lvm is mostly about pooling block devices into larger block devices
[10:25] <groz> let the raid layer deal with those issues
[10:25] <[mbm]> right.
[10:25] <groz> you pop in 3 more drives, make em a raid 5, then join em to the lvm group
[10:25] <groz> to add redundant store
[10:26] <groz> iin the case in pariticular that i'm planning on deploying this
[10:26] <groz> extreme harsh environment, data collection box
[10:26] <groz> i want to raid the flash setup on it
[10:26] <groz> cuz, it's a VERY expensive helicopter ride to visit the box
[10:27] <groz> so i want redundancy, on solid state
[10:27] <groz> no moving parts
[10:27] <[mbm]> oh, I should point out one major caveat with lvm .. grub absolutely hates booting from an lvm volume (you have to do some painful and annoying stuff to patch grub to even attempt it)
[10:27] <groz> speed is not an issue, it's logging data from serial inputs
[10:27] <groz> but it's in an extremely remote location
[10:29] <groz> heh, well, like i said, when i got some more time, i'll re-visit grub, for now tho, lilo works, gets me to the point where i've got an 'openwrt via box'
[10:29] <[mbm]> :)
[10:29] <groz> next, the routerboard 220 i have on the desk here
[10:29] <groz> it's cf, mapped as /dev/hda
[10:29] <Kaloz> 230 you mean
[10:30] <groz> no, 220
[10:30] <Kaloz> is there a 220? o.O
[10:30] <groz> same board, some bits missing
[10:30] <Kaloz> ah
[10:30] <Kaloz> i see
[10:30] <groz> actually, i have a 230 you are right
[10:30] <groz> but client shipped product on the 220
[10:31] <groz> if i remember correctly, only one pcmcia,a nd the pci slots missing too
[10:32] <groz> mbm, got another dumb question tho, for the defaults on ipkg.conf, is the plan to set up a ach heirarchy ?
[10:32] <groz> arch
[10:32] <groz> or, is th eplan to not host packages at all ?
[10:33] <[mbm]> we tried the 'not hosting packages' approach before, it failed misterably
[10:35] <groz> i may be able to co-erce a client to provide a high bandwidth box
[10:35] <groz> for hosting
[10:35] <groz> depends on how badly it's gonna get hit
[10:35] <Kaloz> bw or traffic isn't an issue
[10:36] <Kaloz> we just didn't want to host kamikaze stuff
[10:36] <groz> ok
[10:37] <Kaloz> groz: arrakis has no bw or traffic limit (well the bw cannot be more then 100Mbits/s, as I pay for that only :)
[10:38] <groz> ok, hehe
[10:38] <groz> well i dont know the setup there, so, dont know what the deal is
[10:38] <groz> but if bw or traffic is an issue
[10:38] <groz> i can possibly try set something up to divert
[10:38] <groz> but if it's not an issue then just forget i said anything
[10:39] <Kaloz> it was just a "political" decision :)
[10:53] Action: groz pleased with my new setup on this via, i got a 'make all packages for it' build running now
[10:54] <groz> wonder how many are gonna puke
[11:02] <Bartman007> speaking of puking packages, should I submit a bug report for the ipset issue? (discussed it briefly with mbm yesterday)
[11:03] <[mbm]> there's actually a few packages which don't compile right now
[11:03] <[mbm]> hostap and kismet also come to mind
[11:04] <[mbm]> I'm constantly doing rebuilds of the entire package tree looking for broken packages
[11:05] <Bartman007> i had ntp-client break a few days ago, but looks like it was just a glitch, haven't been able to duplicate it
[11:06] <[mbm]> I have about a dozen patches that I haven't commited yet for various packages .. testing to make sure that everything works first
[11:07] <[mbm]> ... hrm .. this is annoying ..
[11:07] <[mbm]> my shiney new dvd burner has a firmware upgrade, but can only be upgraded from windows
[11:08] <Bartman007> there are linux utils for some manufactures
[11:08] <Bartman007> what brand is it?
[11:08] <[mbm]> it's a plextor 755SA
[11:08] <[mbm]> I haven't found any info on it yet
[11:08] <[mbm]> even a dos util would be helpful
[11:08] <Bartman007> ah, I haven't run across any either (probably becauase I don't have any plextors)
[11:09] <[mbm]> heh.. plextor is a good brand when you want an EXACT copy of a disc :)
[11:09] <Bartman007> I'll stick with my NECs :-)
[11:10] <[mbm]> it burns everything including subchannels
[11:10] <[mbm]> plus, it's one of the few that make serial ata
[11:10] <Bartman007> a serial ata dvd drive that actually works?
[11:11] <[mbm]> yep.
[11:11] <Bartman007> tried booting from it yet?
[11:11] <[mbm]> let me finish running memtest and then I'll stick in a ubuntu cd and let you know
[11:15] <Bartman007> I found something that works at least for IDE drives.
[11:16] <Bartman007> http://crashrecovery.org/oss-dvd/DL/px716.php
[11:18] <[mbm]> hmm booted the ubuntu cd fine
[11:19] <[mbm]> the only issue I've had with it so far is that gnome seems to check the media status too fast and reports 'no disc', but it works fine if I manually mount the drive
[11:22] <[mbm]> hmm interesting
[11:23] <Bartman007> hmm, i should get some sleep, gotta be up in 5 hours.
[11:23] <Bartman007> tomorrow I'll have to edit my pl2303 driver header for one of my serial cables and get my 7001 going.
[11:24] <[mbm]> hmm think I'll let the memtest burn in a little more before I try upgrading the drive's firmware
[11:26] <[mbm]> http://qpxtool.sourceforge.net/faq.html#fwupdate :)
[11:27] <Bartman007> heh, cool
[11:27] <Bartman007> so the program I found doesn't work with sata
[11:42] <[mbm]> Data transfer complete: 2031616 bytes (1F0 blocks). Updating...
[11:42] <[mbm]> FW update complete!
[11:42] <[mbm]> ;)
[11:43] <Kaloz> hmz
[11:43] <Kaloz> more then 2MB
[11:43] <Kaloz> i would check what's inside :P
[11:47] <[mbm]> not much in terms of strings
[11:47] <[mbm]> although there does seem to be a table of cd brands
[11:48] <[mbm]> MAXELL
[11:48] <[mbm]> SONY
[11:48] <[mbm]> CMC MAG
[11:48] <[mbm]> RITEK
[11:48] <[mbm]> ...
[15:55] <[florian]> I am back
[15:57] <[florian]> had some holidays
[18:48] <Bartman007> [mbm]: dvd firmware generally contains speed settings for various bands/types of media as some don't perform up to what they say they are rated for, and others (like many TY discs) can perform past what they are rated for
[19:07] <[florian]> no one here ?
[19:10] <nbd> i'm here
[19:10] <[florian]> ah ok
[19:35] <[florian]> I have just made a small utility to choose the system services : http://pastebin.ca/136408
[19:36] <[florian]> tell me if you think it is worth integrating it
[19:38] <nbd> i think we shouldn't hardcode protected services in the script
[19:38] <nbd> it would probably be better to have a convention that forces all non-essential services to start at 50 or something like that
[19:38] <nbd> but it looks ok to me otherwise
[19:38] <nbd> we should wait for feedback from the other devs
[19:39] <[florian]> sure
[19:39] <[florian]> it's just a proof of concept actually
[20:08] <[florian]> uml is not x86-specific right ?
[20:09] <groz> in theorty no, but theory and reality dont always blend well
[20:11] <CIA-17> nbd * r4584 /branches/buildroot-ng/openwrt/include/kernel.mk: fix KERNELNAME
[20:19] <[florian]> ok, then I will do a quick check on my ppc machine :)
[20:20] <groz> but you are probably right, it shouldn't build as an x86 derivative, should probably become a tree of it's own
[20:20] <groz> the _real_ reason i did it that way the first time, so it wouldn't build another toolchain
[20:21] <nbd> iirc uml is x86 specific at the moment
[20:21] <nbd> and there was a long discussion on lkml on whether it should be moved into arch/i386
[20:21] <groz> do you mean 'our build of it' or 'uml in general' ?
[20:21] <nbd> uml in general
[20:21] <groz> ahhh, ok
[20:22] <groz> i do know there are also some issues with it on x64
[20:24] <[florian]> ok then no need to have a try on ppc :)
[20:25] <[florian]> I'd better reinstall macosx and do some toolchain portability
[20:29] <Bartman007> groz: some issues is an understatement based on my limited dealings with it (a while back)
[20:29] <groz> uh huh
[20:35] <murb> groz: ia64 or x86_64?
[20:36] <groz> x86_64
[20:37] <murb> I've still not got my new x86_64 toy :(
[20:37] <murb> I hope it arrives before my pile of wgt634us
[20:37] <db90h> is ia64 still alive? ;p
[20:37] <murb> db90h: yes
[20:38] <db90h> what a miserable failure that was.. and we all saw its failure coming i think, at least i predicted it
[20:38] <db90h> too big a change to the instruction set.. sure, it's more optimal, but you ahve to maintain efficient backwards compatibility, that's the #1 rule
[20:38] <nbd> yeah, too expensive, horribly complex
[20:38] <dragorn> db90h: if I recall they sacrificed integer speed for floating point
[20:39] <murb> although it does make alpha look like a complete success.
[20:40] <db90h> the instruction set was designed to be generated by an optimizing C compiler.. to code it by hand would have been inpractical
[20:40] <Bartman007> murb: well, it was alpha's bastard child....
[20:40] <db90h> ...at least, from what i know of it.. i didn't spend much time researching it
[20:41] <db90h> if i had some money a few years ago i would have invested in AMD, cuz it seemed so obvious to me that AMD would win in the 64-bit switch
[20:42] <groz> there's a difference between 'gaining market share' and 'making a profit'
[20:42] <nbd> did intel ever buy any significant technology from amd before the 64 bit stuff?
[20:42] <db90h> of course, nothing quite as safe as saying how much money one would have made of investments one didn't make
[20:42] <db90h> nbd: i don't know
[20:42] <db90h> i am not sure all their licensing agreements
[20:44] <db90h> groz: true that ;).. AMD is so broke compared to Intel still today.. they have lost shitloads of money in the recent past
[20:44] <db90h> AND == huge debt
[20:44] <Kaloz> [20:42:32] < nbd> did intel ever buy any significant technology from amd before the 64 bit stuff?
[20:44] <Kaloz> nbd: they just "RE"d it
[20:44] <nbd> they did?
[20:44] <nbd> i thought they had an agreement on it
[20:44] <Kaloz> yeah
[20:45] <Kaloz> nope.. they would never agree to officially get something :P
[20:45] <nbd> well, that explains why they're not doing any effort to actually market it properly :)
[20:45] <Kaloz> from amd i mean
[20:45] <Kaloz> well, their em64t stinks anyway
[20:46] <Kaloz> basically the main problem is that for amd, amd64 is the netive environment, and it's "emulating" ia32
[20:46] <db90h> i hear their virtualization isn't as good as AMD's as well
[20:46] <Kaloz> em64t itself means "emulated 64bit technology"
[20:46] <Kaloz> the cpu is still an ia32, and em64t is an extension
[20:47] <Kaloz> this is true for p4, no idea if they made core 2 different
[20:47] <db90h> gotta love seeing a corporate giant fall on its face
[20:47] <Kaloz> but according to the tests, core 2 is faster at 32bit.. but all of the tests are mainly about gaming and stuff
[20:47] <Kaloz> not some linux-related tests
[20:48] <Kaloz> playing with the idea to get one and check it, but honestly i've always burnt myself when i've touched intel's x86 stuff
[20:48] <Kaloz> i love xscale, thoe
[20:48] <Kaloz> :)
[21:54] <BrainSlayer2> yep
[21:54] <BrainSlayer2> i fixed the serial problem
[21:55] <BrainSlayer2> you can find the fix in my svn
[21:55] <BrainSlayer2> just download the driver. you have 2 misstakes in yours. additionally i restructured some parts in it which is not important for you
[21:56] <[florian]> what do you mean by not important ?
[22:00] <BrainSlayer2> some code design changes
[22:00] <BrainSlayer2> just to make it looking better
[22:00] <[florian]> I have to fix the bootloader detection, because most devices outside france are using a CFE, but we have RedBoot here with Liveboxes
[23:22] <CIA-17> nbd * r4585 /branches/whiterussian/openwrt/package/base-files/default/etc/init.d/S05nvram: remove sdram_config fixup - not necessary for linksys and breaks whr-g54s
[00:00] --- Fri Aug 18 2006