[00:54] <groz> mbm, you areound still ?
[00:55] <[mbm]> ?
[00:55] <groz> what is your opinion, x86 board booting from a usb stick
[00:55] <groz> best choice of fs for that stick
[00:55] <groz> considering most of them already have wear levelling inside
[00:55] <groz> and emulate a 512 byte sector device
[00:56] <groz> they are 'meant' for using with fat32
[00:56] <groz> debating if there's any benefit to going with anything other than an ext variant on it
[00:56] <[mbm]> an ext3 will probably work fine
[00:56] <groz> it does work fine
[00:56] <groz> my question is, for 'default' openwrt setup
[00:56] <groz> is there any benefit to actually doing other than ext ?
[00:57] <[mbm]> should be something with journaling
[00:57] <groz> i'm getting this all working fine now on my via board, booting from usb stick
[00:57] <groz> and wondering if I should just leave it using ext3, or, to commit back
[00:57] <groz> do something fancier ?
[00:58] <groz> and i have another trick i'm wondering about, it means making initfs somewhat larger
[00:58] <groz> but, if we put resize2fs into the initrramfs
[00:58] <groz> we can dd a very small image onto any arbitrary stick
[00:58] <groz> plug it in a device
[00:58] <groz> when it boots first time, it can resize the fs on that device, up to the full size of the device
[00:59] <[mbm]> we should probably add something like the usb script from the howto to our package list so you can build an image to boot off the usb
[00:59] <groz> here's what i'm contemplating for my own use, i've used this kind of a method before
[00:59] <groz> i generate a small ext image, complete with lilo etc
[00:59] <groz> then in the initrd, prior to mounting the stick
[01:00] <groz> resize it up if it's not already sized up to the full size of the stick
[01:00] <groz> so the first time it boots, it does that
[01:00] <[mbm]> hmm not sure that I'd trust it to do that
[01:00] <groz> with 2.6, that can be handled neatly inside the initramfs
[01:00] <groz> it works quite well, if you do it like this
[01:00] <[mbm]> wouldn't want someone sticking in a stick that already was partitioned and having it nuke data
[01:00] <groz> in initramfs, prior to actually doing anything on the media
[01:00] <groz> you check it
[01:01] <groz> well considering it boots off the stick you just put in
[01:01] <groz> you dd this image onto the stick
[01:01] <groz> before you start
[01:01] <groz> it allows one small image to go onto any arbitrary size stick
[01:01] <groz> but end up using the whole stick
[01:02] <groz> this is not something that happens to sticks arbitrarily when they get stuck in, it's only a boot time thing
[01:02] <groz> kinda like firstboot on a wrt
[01:02] <[mbm]> wouldn't it be better to boot the initial size of the stick and then run some command from within openwrt if you wanted to change it?
[01:03] <groz> you cant resize it after you pivot onto it
[01:03] <groz> it's gotta be done before you pivot on
[01:03] <[mbm]> actually you can
[01:03] <groz> hmm, i was not able to make that work before, but, i was always using 2.4
[01:03] <groz> i actually had to do it within the initrd to make it work
[01:03] <[mbm]> look up the ext2 online resize (also works with ext3)
[01:03] <groz> then after resizing, pivot on
[01:04] <groz> if it's something that can be done after its running from it
[01:04] <groz> then 'no big deal'
[01:05] <groz> hmm, reading it now
[01:35] <groz> ok, one last q mbm, process of making the ext image bootable with ext2linux requires it be mounted, so either I put sudo commands in makefiles, or a separate script to run after the fact with root privs, I'm thinking separate script so the requirement for root privs on that step doesn't break the whole env
[01:35] <groz> what you think ?
[01:36] <groz> I'd rather not put something in the master makefile set that's going to prompt for a pw, or force folks to have root privs to run the make
[01:40] <[mbm]> huh? why wo you need sudo?
[01:40] <groz> mount bin/openwrt-xxxx.img
[01:41] <groz> to be able to run extlinux against it
[01:41] <groz> which is gonna rewrite it's boot sectors
[01:41] <groz> unless you jump thru some other hoops to set the system up to allow that mount
[01:41] <groz> either way, it's gotta be mounted, or extlinux doesn't work
[01:42] <groz> unless thats been updated recently, which i haven't checked in the last couple months
[15:40] <dbcch> has anyone started work on an ncurses based configurator for the new package config format in kamikaze?
[18:19] <common> Kaloz: which open source ixp driver?
[21:19] <groz> Building an x-86 2.4 variant, strip is trashing all the modules
[21:19] <groz> is this a known thing ?
[21:22] <[mbm]> hmm it shouldn't be stripping the modules
[21:22] <groz> it is
[21:22] <groz> and they end up trashed
[21:22] <groz> ok, i'll dig into it
[21:23] <[mbm]> you just said it is .. I'm just saying that that's your bug
[21:23] <groz> lol, but i haven't touched the setup on 2.4 yet except to just configure it from 2.6 to 2.4, and run make
[21:24] Action: [mbm] is walking through multiple levels of recursion trying to fix .kernel.mk
[21:24] <groz> I got horribly frustrated with extlinux last nite, finally gave up
[21:25] <groz> and built a setup where it actually puts lilo onto the ext2 file system
[21:25] <groz> and voila, that boots like magic on the usb stick
[21:25] <groz> i guess extlinux isn't really aware of lba etc
[21:25] <[mbm]> :)
[21:25] <[mbm]> btw on some systems you have to screw with the mbr to get usb boots working
[21:25] <groz> what i've done, is because of the loop mounts etc
[21:26] <groz> is isolated it into a script on it's own
[21:26] <groz> which needs privs to run, to take the ext image, and create a bootable variant of that one
[21:26] <groz> yah, but, here's what i do, and it's magic
[21:26] <groz> i'm not partiitioning the stick
[21:26] <groz> just one big raw filesystem on it
[21:26] Action: [mbm] usually uses grub on usb sticks .. more work
[21:27] <[mbm]> ah
[21:27] <groz> no mbr, no partition table
[21:27] <groz> and its magic
[21:27] <[mbm]> spiffy
[21:27] <groz> then,
[21:27] <groz> you can resize the file system
[21:27] <groz> up to full size of the stick, and not worry about partitions
[21:27] <groz> so you mount /dev/sda
[21:27] <groz> not /dev/sda1
[21:27] <groz> got a couple gremlins still left in that devfs stuff
[21:28] <groz> i suspect one of them is causing my other problem
[21:28] <[mbm]> well, that does mean that I'd have to dedicate a stick to usb booting
[21:28] <groz> when running in the initramfs
[21:28] <groz> pivot_root complains and pukes
[21:28] <[mbm]> since I wouldn't be able to partition it for anything else
[21:28] <groz> well, the way i'm using them, i put the stick into a via epia board
[21:28] <groz> and then it gets boxed up on the shelf
[21:28] <groz> that's it's 'hard drive'
[21:28] <groz> to become a router
[21:29] <groz> it's got 2 on board eithernets, and a 'no fans' processor
[21:29] <[mbm]> right, I'm just saying that if you actually did use partitioning then it's much more flexable for multipurpose usb sticks
[21:29] Action: [mbm] goes to grab some food
[21:29] <groz> uh huh, but it's also less useful for 'dedicated routers'
[21:29] <groz> so, 6 of one, half a dozen of the other
[21:30] <groz> you can always dd this file system into the partition of a partitioned stick
[21:30] <groz> should still work
[21:32] <murb> groz: have you looked at dmsetup / kpartx ?
[21:32] <groz> hang on phone
[21:39] <common> [mbm]: you know anything about openwrt xscale roadmap/plans?
[21:39] <common> or something
[21:42] <common> Kaloz said he'd be going for a free driver instead of intels access library, but from what i can say, there is no alternative to intels code
[21:56] <[mbm]> hmm .. lvm on usb sticks would be fun, you'd get a consistant /dev/vg/whatever naming scheme and you'd be able to add more space by just plugging in more usb drives
[21:56] <groz> the other thing i'm battling right now
[21:56] <groz> i create a 2.6 x86 kernel with initramfs
[21:57] <groz> basically vanilla
[21:57] <groz> then I feed that into the via box via netboot
[21:57] <groz> it comes up just fine, and it's running from the initramfs
[21:57] <groz> i mount the usb stick
[21:57] <groz> it reads writes fine
[21:57] <groz> but when i try pivot onto it, getting device or resource busy message
[21:57] <groz> and it's not doing the pivot
[21:58] <[mbm]> what part of the pivot was giving you a device busy?
[21:58] <[mbm]> that should only happen if you try to unmount something like /dev
[21:59] <[mbm]> and the pivot scripts should be using move and bind instead of unmount
[21:59] <groz> well i'm just doint it at the terminal prompt right now
[21:59] <groz> not running any scripts
[22:00] <[mbm]> oh .. the firstboot script has a nice pivot function
[22:00] <groz> just rebooting it to get a fresh start and try again
[22:01] <groz> root@OpenWrt:/# mount /dev/sda /mnt
[22:01] <groz> root@OpenWrt:/# mkdir old
[22:01] <groz> root@OpenWrt:/# pivot_root /mnt /old
[22:01] <groz> pivot_root: pivot_root: Device or resource busy
[22:01] <groz> root@OpenWrt:/#
[22:01] <groz> that's strait out of the console
[22:01] <[mbm]> wrong syntax
[22:01] <groz> first thing after a boot
[22:01] <[mbm]> pivot_root /mnt /mnt/old
[22:01] <groz> ahhhh
[22:01] <groz> ok, so i'm being brain dead this morning
[22:01] <[mbm]> the pivot function I wrote in the firstboot scripts uses your syntax
[22:02] <[mbm]> (also handles the annoying stuff like moving /dev and /proc)
[22:02] <groz> the thing i'm wondering
[22:02] <groz> output from mount doesn't show any root mounts
[22:03] <groz> and its still in initramfs
[22:03] <[mbm]> right
[22:03] <groz> is the initramfs special, and, there is no root mount yet ?
[22:03] <groz> do i have to let the init in there end
[22:03] <groz> and actually run something else ?
[22:03] <[mbm]> the current 2.6.x stuff uses what's called an 'early init'
[22:03] <groz> yes, i see that
[22:04] <groz> and then, it just runs busybox init there
[22:04] <groz> and i'm wondering if maybe the pivot at that point
[22:04] <groz> is not actually valid
[22:04] <[mbm]> you're supposed to compile klibc and some crazy stuff but it basically means you're on an init running out of tmpfs
[22:04] <groz> right
[22:04] <[mbm]> so it doesn't show in mount like you've said
[22:04] <groz> and i'm wondering if that'll stop it from pivoting too
[22:04] <[mbm]> doubt it
[22:05] <common> [mbm]: any reason you ignore me?
[22:05] <groz> root@OpenWrt:/# pivot_root /mnt /mnt/old
[22:05] <groz> pivot_root: pivot_root: Invalid argument
[22:05] <groz> root@OpenWrt:/#
[22:05] <[mbm]> common: I really don't have anything to say on the subject
[22:05] <common> k
[22:05] <groz> ok, i'm gonna go get some coffee, and look at this again
[22:06] <common> you have an idea why ipkg is broken on xscale, maybe saw the error before https://dev.openwrt.org/ticket/689
[22:06] <[mbm]> groz: lmao, check out the latest forum post - http://forum.openwrt.org/viewtopic.php?pid=32091#p32091
[22:07] <[mbm]> common: no idea but there are multiple ipkg bugs right now
[22:07] Action: [mbm] hasn't even started to look at the ipkg system
[22:08] <[mbm]> got to fix buildroot first
[22:08] <groz> here's what i found with ipkg
[22:08] <groz> it's a busybox module now with the new busybox
[22:08] <groz> that one calls wget
[22:08] <groz> and it uses a parameter that the busybox wget doesn't understand
[22:08] <common> yes, i fixed that
[22:08] <groz> go figger
[22:08] <groz> so, i cheated for now
[22:08] <groz> i just grabbed the old script form
[22:08] <groz> and threw that in
[22:08] <groz> from wr
[22:08] <groz> it works
[22:08] <common> problem is different, look at the bug report
[22:09] <groz> and until i get a few other things actually running correctly here
[22:09] <groz> i dont have time to go look at ipkg issues
[22:09] <common> k
[22:09] <[mbm]> gah, and another post about usb .. same bug
[22:10] <groz> ok, i'll post a quick workaround for that one, not clean, but gets you past that bug
[22:10] <groz> just mknod /dev/sda b 8 1
[22:10] <groz> and then you can mount it
[22:10] <groz> or rather b 8 0
[22:10] <groz> and read/write it
[22:11] <[mbm]> hmm damn, I didn't close the dupe fast enough
[22:11] <groz> i got yanked away yesterday, didn't get thru all that devfs patch stuff before i had to leave
[22:11] <[mbm]> yeah I suspect that'll fix it but I haven't had time to test otherwise I'd post
[22:15] <rugolini> im using openwrt as openrt( only OpenRouter hehe), and it works really good, im using kamikaze version in a x86 envioronment, i need to upgrade some locations with this system, normaly im just writing a compact flash, but do you guys think is it possible for me to upgrade another linux with kamikaze firmware ? and how do you guys are planing to upgrade kamikaze ?
[22:15] <[mbm]> kamikaze is obsolete, it's buildroot-ng now
[22:15] <rugolini> cause i need to do this at my work and i want to help openwrt
[22:16] <rugolini> hmmmm
[22:16] <[mbm]> if you scroll above you'll see the discussion about booting buildroot-ng on x86
[22:17] <rugolini> i just got in the channel
[22:17] <groz> think he arrived after that
[22:17] <[mbm]> oh, well it's in openwrt.org/logs if you want to read it
[22:17] <rugolini> yeah, ok.....
[22:18] <mtoledo> openwrt-devel.log.20060531 <-- latest log.
[22:18] <[mbm]> hmm is that damned bot being lazy again
[22:18] <mtoledo> http://openwrt.org/logs/openwrt-devel.log.20060815 <-- this one.
[22:18] <groz> mbm, will a 2.6 kernel do an initramfs AND an initrd ?
[22:19] <[mbm]> groz: think the initrd stuff is depreciated (also wouldn't really make sense to do both)
[22:19] <groz> well, if initramfs exits
[22:19] <groz> i still need a rootfs
[22:20] <[mbm]> not really
[22:20] <groz> I haven't co-erced it to pivot onto the usb
[22:20] <groz> i guess i could feed it a rootdir=/dev/sda
[22:20] <groz> then let the initramfs exit
[22:21] <[mbm]> well, that is a problem, but initramfs+initrd isn't a solution to that
[22:21] <groz> so, init could check for a file system on the usb stick
[22:21] <groz> if it's there
[22:21] <groz> exit
[22:21] <groz> if inot, do what it does now
[22:21] <[mbm]> did you try the pivot from the firstboot script?
[22:21] <groz> not yet, going to look at it soon as my coffee is ready
[22:21] <mtoledo> groz, the purpose of usb is hot swapping?
[22:22] <groz> no, the purpose for what i'm doing right now
[22:22] <groz> i'm netbooting the box, and, getting the proper file system onto the usb with dd
[22:22] <groz> then, i want to boot from it
[22:23] <groz> but the initramfs needs to load the usb modules first
[22:23] <groz> so the thing becomes visible
[22:23] <groz> it's just easier to test boot scripts by netbooting it
[22:23] <groz> until they are all 'right'
[22:24] <mtoledo> for sure...
[22:25] <mtoledo> [mbm], I met a guy in HITEC, he had a Mesh solution for wrt boards, while speaking with him he said the creator of openwrt worked for him. Is that true/you?
[22:26] Action: [mbm] doesn't work for HITEC
[22:26] <mtoledo> HITEC is an event
[22:26] <groz> that wouldn't be mbm, and, i dont work for him, he works for me
[22:27] <[mbm]> meet groz, the other founder of openwrt ;)
[22:27] <groz> or rather, he's a customer of mine
[22:27] <mtoledo> groz, see how salesman's discurse works?
[22:28] <groz> well, it's a two way street, i have done numerous things for him, some on contract, others with other arrangements
[22:28] <groz> but in the end, he's got a pretty slick solution
[22:29] <mtoledo> looked very good, a bit expensive I think, around 800bucks.
[22:29] <groz> expensive is relative, theres a lot of work went into his product
[22:29] <groz> you can buy a similar solution from cisco for about 8000 bucks
[22:29] <mtoledo> yeah he was proundly speaking about his bankhours...
[23:06] <[mbm]> ugh. I hate make.
[23:07] <groz> make comes from the same folks that wrote sendmail, i'm sure of it
[23:07] <[mbm]> heh
[23:08] <[mbm]> we have a few lovely catch-22's in our build system that I'm trying to resolve
[23:08] <groz> you work on th ebuilds, i'm working on making them actually boot and become useful
[23:08] <groz> but some of this 2.6 stuff is new territory for me
[23:09] <groz> altho, i'm beginning to wonder about some of this
[23:09] <[mbm]> basically the past month has been me patching holes in the build system
[23:09] <groz> it's becoming obvious to me, the linux mainstream devs dont want embedded folks playing in 2.6
[23:09] <[mbm]> everything is supposed to work automatically so that nobody cares how
[23:09] <[mbm]> groz: heh, you think?
[23:09] <groz> and i'm wondering if i'd be better off just sticking to 2.4
[23:09] <groz> it 'just works'
[23:09] Action: [mbm] pointed that out the other day
[23:10] <groz> yah, and i'm re-inforcing it
[23:10] <[mbm]> well, at some point someone has to make 2.6 work
[23:10] <groz> but i'm starting to get a feel for how this is gonna come together
[23:10] <groz> still no joy pivoting inside the initfs
[23:11] <groz> but i'm considering something like this
[23:11] <groz> init starts by getting the modules in (which it was intended for)
[23:11] <groz> then a test to see if the media is actually useable
[23:11] <groz> if so, exit, and let normal boot continue, using media as root
[23:11] <groz> else, exec busybox init
[23:11] <[mbm]> well, if you want to solve my problems I'll be more than happy to take a look at initrd/initramfs
[23:11] <groz> and run from ramfs
[23:12] <groz> yah, but that's a wide open invite, your problems probably have something to do with other aspects of life
[23:12] <groz> which i dont want to bother with
[23:12] <[mbm]> basically there's only one spot in the build that knows which kernel version is expected
[23:13] <groz> right, as it should be
[23:13] <[mbm]> so you have a target/linux/brcm-2.4 that's supposed to write out a .kernel.mk
[23:13] <[mbm]> which contains the version string
[23:13] <[mbm]> and that file gets included all over the place when building packages
[23:13] <[mbm]> but what happens when you change the .config and you bypass a few steps of the compile
[23:13] <groz> something else in that same area of 'things', i've been considering making .modules-done dependant on the main config file from make menuconfig
[23:14] <[mbm]> like say I run menuconfig, change to brcm-2.6 and run "make package/foo-compile"
[23:14] <groz> so if you change the configs, it'll rerun the modules build
[23:14] <[mbm]> I've just bypassed rebuilding .kernel.mk
[23:14] <[mbm]> and now it's still trying to build the foo package as 2.4
[23:15] <groz> rite, similar to what i've been doing
[23:15] <groz> i run make menuconfig, change some module stuff
[23:15] <groz> then if i dont force it to redo modules
[23:15] <groz> i end up without the new ones in my initramfs
[23:16] <[mbm]> right .. all of that crap is supposed to happen automatically
[23:16] <groz> well, 2 things i was thinking
[23:16] <[mbm]> and it's become my job to make it work tht way
[23:16] <groz> .modules-done depends on .config
[23:16] <groz> so, if you run make menuconfig
[23:16] <groz> it'll re-evaluate the modules
[23:17] <groz> may not do anything, but, at least run that makefile and check
[23:17] <groz> then if the entire root tree is dependant on .modules-done and .linux-compile
[23:17] <groz> again, few extra iterations thru make at times
[23:17] <groz> but never out of sync
[23:18] <[mbm]> well, the kernel issue needs to be sorted out first
[23:18] <groz> yes, that's an issue, but, how about this
[23:18] <[mbm]> what's really annoying is that it isn't an implicit target
[23:19] <[mbm]> there's nowhere where it says 'build .kenrel.mk'
[23:19] <groz> could we make a .version
[23:19] <groz> containing that number, and only update it
[23:19] <[mbm]> it's just trigged by an include
[23:19] <groz> when you change kernel version
[23:19] <[mbm]> groz: I did that for the packages already ;(
[23:19] <groz> now you have a top level thing on which to depend
[23:19] <[mbm]> er :)
[23:20] <groz> I'm thinking thru this init stuff, what do you think of this
[23:20] <groz> currently, initramfs takes a generic init
[23:20] <groz> in the root
[23:20] <groz> needs to be there, it's the fallback
[23:20] <[mbm]> right, if you don't have usb
[23:20] <groz> but, how about if that one includes or spawns init.board
[23:20] <[mbm]> ?
[23:21] <groz> and then we can have a board specific init
[23:21] <groz> so, the generic init calls that one first
[23:21] <[mbm]> for?
[23:21] <groz> it can no-op
[23:21] <groz> and you end up with what we have now
[23:21] <groz> but it can also do things like loading some modules, and exit
[23:21] <[mbm]> wait...
[23:21] <groz> to allow normal boot process then to process command line params
[23:21] <[mbm]> you're getting ahead of me
[23:21] <groz> and actually use the media as the root
[23:21] <[mbm]> why do we need an init.board?
[23:22] <groz> cuz it'll be different depending on arch
[23:22] <groz> ie different on x86 vs mips or whatever
[23:22] <[mbm]> isn't that a job for the /etc/init.d/whatever scripts to handle?
[23:22] <groz> well, from my reading on initramfs
[23:22] <groz> it's expected to exit
[23:22] <[mbm]> we're not doing that
[23:22] <[mbm]> initramfs is your filesystem
[23:22] <groz> and then normal media handling comes in
[23:23] <groz> yes, but i'm trying to get onto the usb file system, and i cant seem to pivot from within initramfs
[23:23] <groz> and i'm thinking this may be bacause it's not gone that far in the process yet
[23:23] <groz> there is no /
[23:23] <[mbm]> fix the problem, don't try to find rube goldberg ways around it
[23:24] <groz> well i'll know shortly, but, i believe the fix is to have init exit, allow normal boot to finish,
[23:24] <[mbm]> that's ugly
[23:24] <[mbm]> since you can't have initramfs change which root it mounts
[23:25] <groz> well, it would become then a kernel command line
[23:25] <groz> cuz aftrer initramfs exits
[23:25] <groz> it'll proceed with the --rootdir= option
[23:25] <groz> and the purpose of initramfs, is to allow setup to make rootdir available
[23:26] <[mbm]> I know that, I'm just saying what if the initramfs decides it doesn't like the root on the kernel commandline?
[23:26] <groz> then do exactly what happens now
[23:26] <groz> and run completely from initramfs
[23:27] <[mbm]> while that works, wouldn't it be more fun if initramfs could have multiple fallbacks?
[23:27] <[mbm]> try usb, try nfs ...
[23:27] <groz> yes, here's the concept i've worked with before
[23:27] <groz> in the openwrt root file system we put a marker of some type
[23:27] <groz> so, then
[23:27] <groz> mount /dev/hda1
[23:27] <groz> look for marker
[23:27] <groz> if good, go
[23:27] <groz> if not
[23:27] <[mbm]> I suppose we really should identify our goals instead of continuously redefining them
[23:28] <groz> mount /dev/hda
[23:28] <groz> etc
[23:28] <groz> hehe, well, short term, my goal, netboot with initramfs
[23:28] <groz> and end up pivoted or otherwise onto the usb key
[23:28] <groz> then put that same kernel onto the usb key
[23:28] <groz> so it can boot directly from it
[23:28] <[mbm]> well, the first part of that should already be working
[23:28] <groz> no, first part is not working, i cant make pivot work
[23:29] <groz> and i've tried the firstboot functions too
[23:29] <[mbm]> that's not the first part
[23:29] <[mbm]> that's the second part ;)
[23:29] <groz> oh, netboot with initramfs
[23:29] <groz> yes, works fine
[23:29] <groz> and running busybox init at that point
[23:29] <groz> fully functional router
[23:29] <[mbm]> right
[23:29] <groz> that is good
[23:29] <groz> next step, take netboot out
[23:29] <groz> and, i did that like this
[23:29] <groz> dd the file system onto the key
[23:29] <groz> boot it
[23:29] <groz> same result, fully functional from initramfs
[23:30] <[mbm]> ok
[23:30] <groz> and i can mount th eusb
[23:30] <groz> read/write it fine
[23:30] <groz> what i cant seem to make work
[23:30] <groz> is pivot onto it
[23:30] <[mbm]> right
[23:30] <groz> so here's what i'm trying next
[23:30] <groz> init inside ramfs just loads usb modules
[23:30] <[mbm]> but rather than try to find ways to avoid the pivot, we should really just identify why pivot failed
[23:30] <groz> and makes the stick available
[23:30] <groz> then exits
[23:31] <groz> and the lilo command line on the stick
[23:31] <groz> has the stick as the root
[23:31] <groz> then, if that works
[23:31] <groz> i'll know it's _something_ about the initramfs env
[23:31] <[mbm]> that will work, I'm just not thrilled over that solution
[23:32] <groz> it has the added benefit
[23:32] <groz> of freeing up the initramfs space
[23:32] <[mbm]> so does a umount /old
[23:33] <groz> root@OpenWrt:/# pivot_root /mnt /mnt/old
[23:33] <groz> pivot_root: pivot_root: Invalid argument
[23:33] <groz> now that i've got the syntax right i get that
[23:33] <groz> and, the pivot function in firstboot
[23:33] <groz> same
[23:33] <[mbm]> you have a /mnt and /mnt/old?
[23:33] <groz> yes
[23:33] <[mbm]> anything in dmesg?
[23:34] <groz> nope
[23:34] <[mbm]> hrm
[23:34] <groz> and i discovered something else
[23:34] <groz> plugging in the key
[23:34] <groz> does create /dev/disc
[23:34] <groz> and that is mountable
[23:34] <groz> no need now to mknod the sda
[23:34] <[mbm]> ah, so when it failed to get the "scsi/host0/bus0/..." it just created them under /dev
[23:35] <groz> yes
[23:35] <[mbm]> that's nasty
[23:35] <[mbm]> means if I plugged in two sticks they'd clobber eachother
[23:35] <groz> lets see, hang on
[23:35] <[mbm]> they can't both be /dev/disc
[23:36] <groz> i guess it's possible that the pivot failureis actually coming from the scsi issues with devfs
[23:37] <groz> maybe i'll set this aside here for now, and go back to hunting that one down
[00:00] --- Wed Aug 16 2006
[00:55] <[mbm]> ?
[00:55] <groz> what is your opinion, x86 board booting from a usb stick
[00:55] <groz> best choice of fs for that stick
[00:55] <groz> considering most of them already have wear levelling inside
[00:55] <groz> and emulate a 512 byte sector device
[00:56] <groz> they are 'meant' for using with fat32
[00:56] <groz> debating if there's any benefit to going with anything other than an ext variant on it
[00:56] <[mbm]> an ext3 will probably work fine
[00:56] <groz> it does work fine
[00:56] <groz> my question is, for 'default' openwrt setup
[00:56] <groz> is there any benefit to actually doing other than ext ?
[00:57] <[mbm]> should be something with journaling
[00:57] <groz> i'm getting this all working fine now on my via board, booting from usb stick
[00:57] <groz> and wondering if I should just leave it using ext3, or, to commit back
[00:57] <groz> do something fancier ?
[00:58] <groz> and i have another trick i'm wondering about, it means making initfs somewhat larger
[00:58] <groz> but, if we put resize2fs into the initrramfs
[00:58] <groz> we can dd a very small image onto any arbitrary stick
[00:58] <groz> plug it in a device
[00:58] <groz> when it boots first time, it can resize the fs on that device, up to the full size of the device
[00:59] <[mbm]> we should probably add something like the usb script from the howto to our package list so you can build an image to boot off the usb
[00:59] <groz> here's what i'm contemplating for my own use, i've used this kind of a method before
[00:59] <groz> i generate a small ext image, complete with lilo etc
[00:59] <groz> then in the initrd, prior to mounting the stick
[01:00] <groz> resize it up if it's not already sized up to the full size of the stick
[01:00] <groz> so the first time it boots, it does that
[01:00] <[mbm]> hmm not sure that I'd trust it to do that
[01:00] <groz> with 2.6, that can be handled neatly inside the initramfs
[01:00] <groz> it works quite well, if you do it like this
[01:00] <[mbm]> wouldn't want someone sticking in a stick that already was partitioned and having it nuke data
[01:00] <groz> in initramfs, prior to actually doing anything on the media
[01:00] <groz> you check it
[01:01] <groz> well considering it boots off the stick you just put in
[01:01] <groz> you dd this image onto the stick
[01:01] <groz> before you start
[01:01] <groz> it allows one small image to go onto any arbitrary size stick
[01:01] <groz> but end up using the whole stick
[01:02] <groz> this is not something that happens to sticks arbitrarily when they get stuck in, it's only a boot time thing
[01:02] <groz> kinda like firstboot on a wrt
[01:02] <[mbm]> wouldn't it be better to boot the initial size of the stick and then run some command from within openwrt if you wanted to change it?
[01:03] <groz> you cant resize it after you pivot onto it
[01:03] <groz> it's gotta be done before you pivot on
[01:03] <[mbm]> actually you can
[01:03] <groz> hmm, i was not able to make that work before, but, i was always using 2.4
[01:03] <groz> i actually had to do it within the initrd to make it work
[01:03] <[mbm]> look up the ext2 online resize (also works with ext3)
[01:03] <groz> then after resizing, pivot on
[01:04] <groz> if it's something that can be done after its running from it
[01:04] <groz> then 'no big deal'
[01:05] <groz> hmm, reading it now
[01:35] <groz> ok, one last q mbm, process of making the ext image bootable with ext2linux requires it be mounted, so either I put sudo commands in makefiles, or a separate script to run after the fact with root privs, I'm thinking separate script so the requirement for root privs on that step doesn't break the whole env
[01:35] <groz> what you think ?
[01:36] <groz> I'd rather not put something in the master makefile set that's going to prompt for a pw, or force folks to have root privs to run the make
[01:40] <[mbm]> huh? why wo you need sudo?
[01:40] <groz> mount bin/openwrt-xxxx.img
[01:41] <groz> to be able to run extlinux against it
[01:41] <groz> which is gonna rewrite it's boot sectors
[01:41] <groz> unless you jump thru some other hoops to set the system up to allow that mount
[01:41] <groz> either way, it's gotta be mounted, or extlinux doesn't work
[01:42] <groz> unless thats been updated recently, which i haven't checked in the last couple months
[15:40] <dbcch> has anyone started work on an ncurses based configurator for the new package config format in kamikaze?
[18:19] <common> Kaloz: which open source ixp driver?
[21:19] <groz> Building an x-86 2.4 variant, strip is trashing all the modules
[21:19] <groz> is this a known thing ?
[21:22] <[mbm]> hmm it shouldn't be stripping the modules
[21:22] <groz> it is
[21:22] <groz> and they end up trashed
[21:22] <groz> ok, i'll dig into it
[21:23] <[mbm]> you just said it is .. I'm just saying that that's your bug
[21:23] <groz> lol, but i haven't touched the setup on 2.4 yet except to just configure it from 2.6 to 2.4, and run make
[21:24] Action: [mbm] is walking through multiple levels of recursion trying to fix .kernel.mk
[21:24] <groz> I got horribly frustrated with extlinux last nite, finally gave up
[21:25] <groz> and built a setup where it actually puts lilo onto the ext2 file system
[21:25] <groz> and voila, that boots like magic on the usb stick
[21:25] <groz> i guess extlinux isn't really aware of lba etc
[21:25] <[mbm]> :)
[21:25] <[mbm]> btw on some systems you have to screw with the mbr to get usb boots working
[21:25] <groz> what i've done, is because of the loop mounts etc
[21:26] <groz> is isolated it into a script on it's own
[21:26] <groz> which needs privs to run, to take the ext image, and create a bootable variant of that one
[21:26] <groz> yah, but, here's what i do, and it's magic
[21:26] <groz> i'm not partiitioning the stick
[21:26] <groz> just one big raw filesystem on it
[21:26] Action: [mbm] usually uses grub on usb sticks .. more work
[21:27] <[mbm]> ah
[21:27] <groz> no mbr, no partition table
[21:27] <groz> and its magic
[21:27] <[mbm]> spiffy
[21:27] <groz> then,
[21:27] <groz> you can resize the file system
[21:27] <groz> up to full size of the stick, and not worry about partitions
[21:27] <groz> so you mount /dev/sda
[21:27] <groz> not /dev/sda1
[21:27] <groz> got a couple gremlins still left in that devfs stuff
[21:28] <groz> i suspect one of them is causing my other problem
[21:28] <[mbm]> well, that does mean that I'd have to dedicate a stick to usb booting
[21:28] <groz> when running in the initramfs
[21:28] <groz> pivot_root complains and pukes
[21:28] <[mbm]> since I wouldn't be able to partition it for anything else
[21:28] <groz> well, the way i'm using them, i put the stick into a via epia board
[21:28] <groz> and then it gets boxed up on the shelf
[21:28] <groz> that's it's 'hard drive'
[21:28] <groz> to become a router
[21:29] <groz> it's got 2 on board eithernets, and a 'no fans' processor
[21:29] <[mbm]> right, I'm just saying that if you actually did use partitioning then it's much more flexable for multipurpose usb sticks
[21:29] Action: [mbm] goes to grab some food
[21:29] <groz> uh huh, but it's also less useful for 'dedicated routers'
[21:29] <groz> so, 6 of one, half a dozen of the other
[21:30] <groz> you can always dd this file system into the partition of a partitioned stick
[21:30] <groz> should still work
[21:32] <murb> groz: have you looked at dmsetup / kpartx ?
[21:32] <groz> hang on phone
[21:39] <common> [mbm]: you know anything about openwrt xscale roadmap/plans?
[21:39] <common> or something
[21:42] <common> Kaloz said he'd be going for a free driver instead of intels access library, but from what i can say, there is no alternative to intels code
[21:56] <[mbm]> hmm .. lvm on usb sticks would be fun, you'd get a consistant /dev/vg/whatever naming scheme and you'd be able to add more space by just plugging in more usb drives
[21:56] <groz> the other thing i'm battling right now
[21:56] <groz> i create a 2.6 x86 kernel with initramfs
[21:57] <groz> basically vanilla
[21:57] <groz> then I feed that into the via box via netboot
[21:57] <groz> it comes up just fine, and it's running from the initramfs
[21:57] <groz> i mount the usb stick
[21:57] <groz> it reads writes fine
[21:57] <groz> but when i try pivot onto it, getting device or resource busy message
[21:57] <groz> and it's not doing the pivot
[21:58] <[mbm]> what part of the pivot was giving you a device busy?
[21:58] <[mbm]> that should only happen if you try to unmount something like /dev
[21:59] <[mbm]> and the pivot scripts should be using move and bind instead of unmount
[21:59] <groz> well i'm just doint it at the terminal prompt right now
[21:59] <groz> not running any scripts
[22:00] <[mbm]> oh .. the firstboot script has a nice pivot function
[22:00] <groz> just rebooting it to get a fresh start and try again
[22:01] <groz> root@OpenWrt:/# mount /dev/sda /mnt
[22:01] <groz> root@OpenWrt:/# mkdir old
[22:01] <groz> root@OpenWrt:/# pivot_root /mnt /old
[22:01] <groz> pivot_root: pivot_root: Device or resource busy
[22:01] <groz> root@OpenWrt:/#
[22:01] <groz> that's strait out of the console
[22:01] <[mbm]> wrong syntax
[22:01] <groz> first thing after a boot
[22:01] <[mbm]> pivot_root /mnt /mnt/old
[22:01] <groz> ahhhh
[22:01] <groz> ok, so i'm being brain dead this morning
[22:01] <[mbm]> the pivot function I wrote in the firstboot scripts uses your syntax
[22:02] <[mbm]> (also handles the annoying stuff like moving /dev and /proc)
[22:02] <groz> the thing i'm wondering
[22:02] <groz> output from mount doesn't show any root mounts
[22:03] <groz> and its still in initramfs
[22:03] <[mbm]> right
[22:03] <groz> is the initramfs special, and, there is no root mount yet ?
[22:03] <groz> do i have to let the init in there end
[22:03] <groz> and actually run something else ?
[22:03] <[mbm]> the current 2.6.x stuff uses what's called an 'early init'
[22:03] <groz> yes, i see that
[22:04] <groz> and then, it just runs busybox init there
[22:04] <groz> and i'm wondering if maybe the pivot at that point
[22:04] <groz> is not actually valid
[22:04] <[mbm]> you're supposed to compile klibc and some crazy stuff but it basically means you're on an init running out of tmpfs
[22:04] <groz> right
[22:04] <[mbm]> so it doesn't show in mount like you've said
[22:04] <groz> and i'm wondering if that'll stop it from pivoting too
[22:04] <[mbm]> doubt it
[22:05] <common> [mbm]: any reason you ignore me?
[22:05] <groz> root@OpenWrt:/# pivot_root /mnt /mnt/old
[22:05] <groz> pivot_root: pivot_root: Invalid argument
[22:05] <groz> root@OpenWrt:/#
[22:05] <[mbm]> common: I really don't have anything to say on the subject
[22:05] <common> k
[22:05] <groz> ok, i'm gonna go get some coffee, and look at this again
[22:06] <common> you have an idea why ipkg is broken on xscale, maybe saw the error before https://dev.openwrt.org/ticket/689
[22:06] <[mbm]> groz: lmao, check out the latest forum post - http://forum.openwrt.org/viewtopic.php?pid=32091#p32091
[22:07] <[mbm]> common: no idea but there are multiple ipkg bugs right now
[22:07] Action: [mbm] hasn't even started to look at the ipkg system
[22:08] <[mbm]> got to fix buildroot first
[22:08] <groz> here's what i found with ipkg
[22:08] <groz> it's a busybox module now with the new busybox
[22:08] <groz> that one calls wget
[22:08] <groz> and it uses a parameter that the busybox wget doesn't understand
[22:08] <common> yes, i fixed that
[22:08] <groz> go figger
[22:08] <groz> so, i cheated for now
[22:08] <groz> i just grabbed the old script form
[22:08] <groz> and threw that in
[22:08] <groz> from wr
[22:08] <groz> it works
[22:08] <common> problem is different, look at the bug report
[22:09] <groz> and until i get a few other things actually running correctly here
[22:09] <groz> i dont have time to go look at ipkg issues
[22:09] <common> k
[22:09] <[mbm]> gah, and another post about usb .. same bug
[22:10] <groz> ok, i'll post a quick workaround for that one, not clean, but gets you past that bug
[22:10] <groz> just mknod /dev/sda b 8 1
[22:10] <groz> and then you can mount it
[22:10] <groz> or rather b 8 0
[22:10] <groz> and read/write it
[22:11] <[mbm]> hmm damn, I didn't close the dupe fast enough
[22:11] <groz> i got yanked away yesterday, didn't get thru all that devfs patch stuff before i had to leave
[22:11] <[mbm]> yeah I suspect that'll fix it but I haven't had time to test otherwise I'd post
[22:15] <rugolini> im using openwrt as openrt( only OpenRouter hehe), and it works really good, im using kamikaze version in a x86 envioronment, i need to upgrade some locations with this system, normaly im just writing a compact flash, but do you guys think is it possible for me to upgrade another linux with kamikaze firmware ? and how do you guys are planing to upgrade kamikaze ?
[22:15] <[mbm]> kamikaze is obsolete, it's buildroot-ng now
[22:15] <rugolini> cause i need to do this at my work and i want to help openwrt
[22:16] <rugolini> hmmmm
[22:16] <[mbm]> if you scroll above you'll see the discussion about booting buildroot-ng on x86
[22:17] <rugolini> i just got in the channel
[22:17] <groz> think he arrived after that
[22:17] <[mbm]> oh, well it's in openwrt.org/logs if you want to read it
[22:17] <rugolini> yeah, ok.....
[22:18] <mtoledo> openwrt-devel.log.20060531 <-- latest log.
[22:18] <[mbm]> hmm is that damned bot being lazy again
[22:18] <mtoledo> http://openwrt.org/logs/openwrt-devel.log.20060815 <-- this one.
[22:18] <groz> mbm, will a 2.6 kernel do an initramfs AND an initrd ?
[22:19] <[mbm]> groz: think the initrd stuff is depreciated (also wouldn't really make sense to do both)
[22:19] <groz> well, if initramfs exits
[22:19] <groz> i still need a rootfs
[22:20] <[mbm]> not really
[22:20] <groz> I haven't co-erced it to pivot onto the usb
[22:20] <groz> i guess i could feed it a rootdir=/dev/sda
[22:20] <groz> then let the initramfs exit
[22:21] <[mbm]> well, that is a problem, but initramfs+initrd isn't a solution to that
[22:21] <groz> so, init could check for a file system on the usb stick
[22:21] <groz> if it's there
[22:21] <groz> exit
[22:21] <groz> if inot, do what it does now
[22:21] <[mbm]> did you try the pivot from the firstboot script?
[22:21] <groz> not yet, going to look at it soon as my coffee is ready
[22:21] <mtoledo> groz, the purpose of usb is hot swapping?
[22:22] <groz> no, the purpose for what i'm doing right now
[22:22] <groz> i'm netbooting the box, and, getting the proper file system onto the usb with dd
[22:22] <groz> then, i want to boot from it
[22:23] <groz> but the initramfs needs to load the usb modules first
[22:23] <groz> so the thing becomes visible
[22:23] <groz> it's just easier to test boot scripts by netbooting it
[22:23] <groz> until they are all 'right'
[22:24] <mtoledo> for sure...
[22:25] <mtoledo> [mbm], I met a guy in HITEC, he had a Mesh solution for wrt boards, while speaking with him he said the creator of openwrt worked for him. Is that true/you?
[22:26] Action: [mbm] doesn't work for HITEC
[22:26] <mtoledo> HITEC is an event
[22:26] <groz> that wouldn't be mbm, and, i dont work for him, he works for me
[22:27] <[mbm]> meet groz, the other founder of openwrt ;)
[22:27] <groz> or rather, he's a customer of mine
[22:27] <mtoledo> groz, see how salesman's discurse works?
[22:28] <groz> well, it's a two way street, i have done numerous things for him, some on contract, others with other arrangements
[22:28] <groz> but in the end, he's got a pretty slick solution
[22:29] <mtoledo> looked very good, a bit expensive I think, around 800bucks.
[22:29] <groz> expensive is relative, theres a lot of work went into his product
[22:29] <groz> you can buy a similar solution from cisco for about 8000 bucks
[22:29] <mtoledo> yeah he was proundly speaking about his bankhours...
[23:06] <[mbm]> ugh. I hate make.
[23:07] <groz> make comes from the same folks that wrote sendmail, i'm sure of it
[23:07] <[mbm]> heh
[23:08] <[mbm]> we have a few lovely catch-22's in our build system that I'm trying to resolve
[23:08] <groz> you work on th ebuilds, i'm working on making them actually boot and become useful
[23:08] <groz> but some of this 2.6 stuff is new territory for me
[23:09] <groz> altho, i'm beginning to wonder about some of this
[23:09] <[mbm]> basically the past month has been me patching holes in the build system
[23:09] <groz> it's becoming obvious to me, the linux mainstream devs dont want embedded folks playing in 2.6
[23:09] <[mbm]> everything is supposed to work automatically so that nobody cares how
[23:09] <[mbm]> groz: heh, you think?
[23:09] <groz> and i'm wondering if i'd be better off just sticking to 2.4
[23:09] <groz> it 'just works'
[23:09] Action: [mbm] pointed that out the other day
[23:10] <groz> yah, and i'm re-inforcing it
[23:10] <[mbm]> well, at some point someone has to make 2.6 work
[23:10] <groz> but i'm starting to get a feel for how this is gonna come together
[23:10] <groz> still no joy pivoting inside the initfs
[23:11] <groz> but i'm considering something like this
[23:11] <groz> init starts by getting the modules in (which it was intended for)
[23:11] <groz> then a test to see if the media is actually useable
[23:11] <groz> if so, exit, and let normal boot continue, using media as root
[23:11] <groz> else, exec busybox init
[23:11] <[mbm]> well, if you want to solve my problems I'll be more than happy to take a look at initrd/initramfs
[23:11] <groz> and run from ramfs
[23:12] <groz> yah, but that's a wide open invite, your problems probably have something to do with other aspects of life
[23:12] <groz> which i dont want to bother with
[23:12] <[mbm]> basically there's only one spot in the build that knows which kernel version is expected
[23:13] <groz> right, as it should be
[23:13] <[mbm]> so you have a target/linux/brcm-2.4 that's supposed to write out a .kernel.mk
[23:13] <[mbm]> which contains the version string
[23:13] <[mbm]> and that file gets included all over the place when building packages
[23:13] <[mbm]> but what happens when you change the .config and you bypass a few steps of the compile
[23:13] <groz> something else in that same area of 'things', i've been considering making .modules-done dependant on the main config file from make menuconfig
[23:14] <[mbm]> like say I run menuconfig, change to brcm-2.6 and run "make package/foo-compile"
[23:14] <groz> so if you change the configs, it'll rerun the modules build
[23:14] <[mbm]> I've just bypassed rebuilding .kernel.mk
[23:14] <[mbm]> and now it's still trying to build the foo package as 2.4
[23:15] <groz> rite, similar to what i've been doing
[23:15] <groz> i run make menuconfig, change some module stuff
[23:15] <groz> then if i dont force it to redo modules
[23:15] <groz> i end up without the new ones in my initramfs
[23:16] <[mbm]> right .. all of that crap is supposed to happen automatically
[23:16] <groz> well, 2 things i was thinking
[23:16] <[mbm]> and it's become my job to make it work tht way
[23:16] <groz> .modules-done depends on .config
[23:16] <groz> so, if you run make menuconfig
[23:16] <groz> it'll re-evaluate the modules
[23:17] <groz> may not do anything, but, at least run that makefile and check
[23:17] <groz> then if the entire root tree is dependant on .modules-done and .linux-compile
[23:17] <groz> again, few extra iterations thru make at times
[23:17] <groz> but never out of sync
[23:18] <[mbm]> well, the kernel issue needs to be sorted out first
[23:18] <groz> yes, that's an issue, but, how about this
[23:18] <[mbm]> what's really annoying is that it isn't an implicit target
[23:19] <[mbm]> there's nowhere where it says 'build .kenrel.mk'
[23:19] <groz> could we make a .version
[23:19] <groz> containing that number, and only update it
[23:19] <[mbm]> it's just trigged by an include
[23:19] <groz> when you change kernel version
[23:19] <[mbm]> groz: I did that for the packages already ;(
[23:19] <groz> now you have a top level thing on which to depend
[23:19] <[mbm]> er :)
[23:20] <groz> I'm thinking thru this init stuff, what do you think of this
[23:20] <groz> currently, initramfs takes a generic init
[23:20] <groz> in the root
[23:20] <groz> needs to be there, it's the fallback
[23:20] <[mbm]> right, if you don't have usb
[23:20] <groz> but, how about if that one includes or spawns init.board
[23:20] <[mbm]> ?
[23:21] <groz> and then we can have a board specific init
[23:21] <groz> so, the generic init calls that one first
[23:21] <[mbm]> for?
[23:21] <groz> it can no-op
[23:21] <groz> and you end up with what we have now
[23:21] <groz> but it can also do things like loading some modules, and exit
[23:21] <[mbm]> wait...
[23:21] <groz> to allow normal boot process then to process command line params
[23:21] <[mbm]> you're getting ahead of me
[23:21] <groz> and actually use the media as the root
[23:21] <[mbm]> why do we need an init.board?
[23:22] <groz> cuz it'll be different depending on arch
[23:22] <groz> ie different on x86 vs mips or whatever
[23:22] <[mbm]> isn't that a job for the /etc/init.d/whatever scripts to handle?
[23:22] <groz> well, from my reading on initramfs
[23:22] <groz> it's expected to exit
[23:22] <[mbm]> we're not doing that
[23:22] <[mbm]> initramfs is your filesystem
[23:22] <groz> and then normal media handling comes in
[23:23] <groz> yes, but i'm trying to get onto the usb file system, and i cant seem to pivot from within initramfs
[23:23] <groz> and i'm thinking this may be bacause it's not gone that far in the process yet
[23:23] <groz> there is no /
[23:23] <[mbm]> fix the problem, don't try to find rube goldberg ways around it
[23:24] <groz> well i'll know shortly, but, i believe the fix is to have init exit, allow normal boot to finish,
[23:24] <[mbm]> that's ugly
[23:24] <[mbm]> since you can't have initramfs change which root it mounts
[23:25] <groz> well, it would become then a kernel command line
[23:25] <groz> cuz aftrer initramfs exits
[23:25] <groz> it'll proceed with the --rootdir= option
[23:25] <groz> and the purpose of initramfs, is to allow setup to make rootdir available
[23:26] <[mbm]> I know that, I'm just saying what if the initramfs decides it doesn't like the root on the kernel commandline?
[23:26] <groz> then do exactly what happens now
[23:26] <groz> and run completely from initramfs
[23:27] <[mbm]> while that works, wouldn't it be more fun if initramfs could have multiple fallbacks?
[23:27] <[mbm]> try usb, try nfs ...
[23:27] <groz> yes, here's the concept i've worked with before
[23:27] <groz> in the openwrt root file system we put a marker of some type
[23:27] <groz> so, then
[23:27] <groz> mount /dev/hda1
[23:27] <groz> look for marker
[23:27] <groz> if good, go
[23:27] <groz> if not
[23:27] <[mbm]> I suppose we really should identify our goals instead of continuously redefining them
[23:28] <groz> mount /dev/hda
[23:28] <groz> etc
[23:28] <groz> hehe, well, short term, my goal, netboot with initramfs
[23:28] <groz> and end up pivoted or otherwise onto the usb key
[23:28] <groz> then put that same kernel onto the usb key
[23:28] <groz> so it can boot directly from it
[23:28] <[mbm]> well, the first part of that should already be working
[23:28] <groz> no, first part is not working, i cant make pivot work
[23:29] <groz> and i've tried the firstboot functions too
[23:29] <[mbm]> that's not the first part
[23:29] <[mbm]> that's the second part ;)
[23:29] <groz> oh, netboot with initramfs
[23:29] <groz> yes, works fine
[23:29] <groz> and running busybox init at that point
[23:29] <groz> fully functional router
[23:29] <[mbm]> right
[23:29] <groz> that is good
[23:29] <groz> next step, take netboot out
[23:29] <groz> and, i did that like this
[23:29] <groz> dd the file system onto the key
[23:29] <groz> boot it
[23:29] <groz> same result, fully functional from initramfs
[23:30] <[mbm]> ok
[23:30] <groz> and i can mount th eusb
[23:30] <groz> read/write it fine
[23:30] <groz> what i cant seem to make work
[23:30] <groz> is pivot onto it
[23:30] <[mbm]> right
[23:30] <groz> so here's what i'm trying next
[23:30] <groz> init inside ramfs just loads usb modules
[23:30] <[mbm]> but rather than try to find ways to avoid the pivot, we should really just identify why pivot failed
[23:30] <groz> and makes the stick available
[23:30] <groz> then exits
[23:31] <groz> and the lilo command line on the stick
[23:31] <groz> has the stick as the root
[23:31] <groz> then, if that works
[23:31] <groz> i'll know it's _something_ about the initramfs env
[23:31] <[mbm]> that will work, I'm just not thrilled over that solution
[23:32] <groz> it has the added benefit
[23:32] <groz> of freeing up the initramfs space
[23:32] <[mbm]> so does a umount /old
[23:33] <groz> root@OpenWrt:/# pivot_root /mnt /mnt/old
[23:33] <groz> pivot_root: pivot_root: Invalid argument
[23:33] <groz> now that i've got the syntax right i get that
[23:33] <groz> and, the pivot function in firstboot
[23:33] <groz> same
[23:33] <[mbm]> you have a /mnt and /mnt/old?
[23:33] <groz> yes
[23:33] <[mbm]> anything in dmesg?
[23:34] <groz> nope
[23:34] <[mbm]> hrm
[23:34] <groz> and i discovered something else
[23:34] <groz> plugging in the key
[23:34] <groz> does create /dev/disc
[23:34] <groz> and that is mountable
[23:34] <groz> no need now to mknod the sda
[23:34] <[mbm]> ah, so when it failed to get the "scsi/host0/bus0/..." it just created them under /dev
[23:35] <groz> yes
[23:35] <[mbm]> that's nasty
[23:35] <[mbm]> means if I plugged in two sticks they'd clobber eachother
[23:35] <groz> lets see, hang on
[23:35] <[mbm]> they can't both be /dev/disc
[23:36] <groz> i guess it's possible that the pivot failureis actually coming from the scsi issues with devfs
[23:37] <groz> maybe i'll set this aside here for now, and go back to hunting that one down
[00:00] --- Wed Aug 16 2006