**** BEGIN LOGGING AT Mon Jun 27 23:59:56 2005 Jun 28 00:03:23 morning Jun 28 01:33:02 test Jun 28 01:34:07 test2 Jun 28 01:34:48 foomatic Jun 28 01:36:17 foomatic2 Jun 28 01:38:00 gernika_x, I think I got this supy setup right, i see messages indicating it should be passing along information to www.loglibrary.com . however http://loglibrary.com/show_page/latest/177 gives me some error messages. **** BEGIN LOGGING AT Tue Jun 28 10:26:28 2005 Jun 28 10:27:04 <[g2]> mr_claus, 6 months ago I tested on the desktop with ext3 Jun 28 10:27:12 <[g2]> that mostly worked Jun 28 10:27:22 jbowler: the user connect an usb-hub to slot1 and use 4 disks at that hub, how you can say which disk is the first one, whats happening if the hub will be changed by another product, which disk will be the first one then? Jun 28 10:27:47 <[g2]> jbowler, the device order is important and I think there's a race in there when multiple storage devices are in there Jun 28 10:28:17 You are both repeatedly making the same statements but I haven't seen a scenario or a solution, other than my own. Jun 28 10:28:45 [g2]: i used a modified linuxrc to check the label of FAT filesystems, but a hidden file is fs-independent Jun 28 10:29:03 jbowler: the user connect an usb-hub to slot1 and use 4 disks at that hub, how you can say which disk is the first one, whats happening if the hub will be changed by another product, which disk will be the first one then? Jun 28 10:29:10 thats the scenario Jun 28 10:29:10 If the rootfs isn't on sda? then the system falls back to flash. At this point the user will have to swap the disks round until the desired one gets to be sda?. There is, presumably, a deterministic way of doing this. Jun 28 10:29:45 jbowler: do you think it's userfriendly if there is a need to change the disks? Jun 28 10:30:07 <[g2]> jbowler, here's the old entries Jun 28 10:30:11 <[g2]> # (sda1 is next) Jun 28 10:30:11 <[g2]> #UUID=ef801990-b6dc-451b-86de-6b874f7b9317 /mnt/test ext3 noatime,ro 0 0 Jun 28 10:30:28 That's a question, not a scenario - I don't know the answer - I don't know the behaviour with the current system and I don't know the behaviour with your proposed solution - I don't actually even know what the proposed solution is, it seems to involve ext3 disk labels and always using udev. Jun 28 10:31:07 <[g2]> I think that can be UUID=ef801990-b6dc-451b-86de-6b874f7b9317 / ext3 noatime,ro 0 0 Jun 28 10:31:26 <[g2]> then the boot it tied to a disk label and not a device Jun 28 10:31:49 <[g2]> I'll test later with my swap partition Jun 28 10:32:00 mr_claus: the 'userfriendly' question is irrelevant, it's a question of how difficult the full solution to the scenario is. Jun 28 10:32:41 [g2]: ok, why doesn't that work at present? Jun 28 10:33:10 <[g2]> jbowler, it very may work at present, I just haven't verified it Jun 28 10:33:34 <[g2]> I know it didn't work for reiserfs3 last I tried Jun 28 10:33:50 [g2], mr_claus: you are talking at cross-purposes. [g2] just suggested using the disk label in place of the device name, mr_claus, you semed to be suggesting doing a whole load of stuff in /boot/disk. Jun 28 10:33:53 <[g2]> but the kernel has changed a bunch in 8 months Jun 28 10:33:55 jbowler: ok, what i see is that it could be a problem with changing disks, i gave two prosposals how that could be solved Jun 28 10:34:31 <[g2]> jbowler, UUID isn't implemented for fat/vfat iirc Jun 28 10:34:35 mr_claus: what about [g2]'s suggestion? Jun 28 10:34:58 [g2]: it doesn't matter, fat/vfat rootfs isn't an option. Jun 28 10:35:26 <[g2]> I think he was loop mounting from a file on vfat Jun 28 10:35:37 jbowler: i think the goal is the same, it should be possible to change disks with keeping my system running Jun 28 10:35:41 * [g2] could be all confused though Jun 28 10:36:14 [g2]: that wasn't stated in the scenario. Jun 28 10:36:36 <[g2]> I don't think one can hot-swap the rootfs disk Jun 28 10:36:47 Correct Jun 28 10:36:48 <[g2]> sucessfully :) Jun 28 10:37:02 I had a search order before, but it was complexity with little gain. Jun 28 10:37:12 <[g2]> agreed Jun 28 10:37:44 The more reliable the identification of the rootfs device the better, but so far as I can see it needs to work in /etc/fstab with the mount -o remount code in /etc/init.d/checkroot.sh Jun 28 10:38:18 So I guess there are three (four) proposals: Jun 28 10:38:26 jbowler: do you think it would be a problem to use udev? i cannot see disadvantages with udev Jun 28 10:38:29 1) jbowler: ignore it, the user has to get it right. Jun 28 10:38:45 2) [g2]: use the UUID if available (change turnup to find it?) Jun 28 10:39:13 3) mr_claus: search through the possible devices and use udev - I'm very unclear about this. Jun 28 10:40:19 1. is not userfriendly (only my opinion), 2. is restricted to ext3, 3. is restricted to udev Jun 28 10:40:21 Well, I quite like (2) if it works. As for (1) I don't much want to disable use of /dev/sd[b-z]?, and I don't think it will be a problem. Jun 28 10:40:42 perhaps there is another solution which is better, but at the moment i cannot find one Jun 28 10:40:44 (3) I don't understand the full consequences... Jun 28 10:41:55 there are two things, 1. while booting the right devices has to be fetched and mounted and 2. all other devices should be at the right place after the boot process Jun 28 10:42:11 to bring all other devices at the right place udev could be used Jun 28 10:42:21 So I say the way forward is to come up with a set of changes which work and can be evaluated. (Use monotone and produce mods for the org.openembedded.nslu2-linux.testing branch). Jun 28 10:43:54 Ah, nslu2-linux.org is back up. Jun 28 10:43:56 no problem with that but if there is no way to use udev as default then the solution would not be working Jun 28 10:45:59 That's a separate issue. I don't know what OE intend long term but udev strikes me as the correct destination for OpenSlug Jun 28 10:46:36 Since devfs now seems to be out - but there may be code/memory size issues. Jun 28 10:46:59 Still, udev might be the default with the option of using a static /dev to reduce overhead. Jun 28 10:47:40 a fallback should always possible but then there is no devicenaming support Jun 28 10:47:59 monotone: here's a page with a description of what I believe to be the problem (within monotone) with using branches effectively: http://www.nslu2-linux.org/wiki/Monotone/ProblemsWithBranches Jun 28 10:48:04 and i think devicenaming is a big advantage Jun 28 10:50:08 jbowler: i will take a look but i think i would need permissions to anything with monotone but that is another thing Jun 28 10:50:19 * mr_claus is very hungry now Jun 28 10:50:29 * mr_claus is away: dinner :)))) Jun 28 10:51:18 mr_claus: you just need to commit to that testing branch then, if you can serve your database, we can pull the changes. Jun 28 10:53:05 site's back (in case ppl didn't know) Jun 28 10:54:23 bbl Jun 28 11:04:32 <[g2]> Tiersten, hey Jun 28 11:04:46 <[g2]> I've got a hw qustion for you as usual :) Jun 28 11:04:51 <[g2]> I've got a hw question for you as usual :) Jun 28 13:02:33 foo Jun 28 16:11:47 ooh... there's been a long discussion Jun 28 16:11:53 And I wasn't here :( Jun 28 16:17:56 drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.11 Jun 28 16:17:59 Neat-o Jun 28 16:21:05 NAiL: congrats Jun 28 16:21:41 It's not the ka6sox one, I didn't have time to pick it up today Jun 28 16:21:45 wrt the long discussion. I think it's a non-issue. Do you swap your IDE drives inside your desktop computer and still expect windows to boot? No. Jun 28 16:22:09 No, but they're not "easily" removable either ;-) Jun 28 16:22:18 So if someone who is experienced enough to run OpenSlug goes and swaps around their external rootfs, then caveat emptor. Jun 28 16:22:28 yeah Jun 28 16:22:49 but, if someone comes up with a solution, then that's fine too. But it shouldn't be spoken about as if it's a huge problem. Jun 28 16:23:44 It wouldn't be hard to set up a "solution" actually. But it's not my top priority at the moment. Jun 28 16:24:30 udev would work nicely. Together with UUID or Labels, it'd be "foolproof". But right now, I'm more interested in testing out my brand new micro RC car :-P Jun 28 16:26:38 It's got problems climbing my mousemat, though Jun 28 16:27:41 I'm interested in doing a solution, eventually. But there are a lot of other stuff that I'd like to see to first. I want to add some packages to the feed, when I get 'em working as they should. Jun 28 16:27:58 (And fix a few that is kinda b0rked atm) Jun 28 16:28:06 that's what I mean - it's almost a thoeretical problem, and therefore I suspect no-one will spend the effort to solve it. Jun 28 16:28:26 there's too many other interesting problems to solve first :-) Jun 28 16:29:07 I find the problem intriguing. Kind of. But I've got *practical* problems to solve first. The disk-swap issue is purely an excercise in problem-solving ;-) Jun 28 16:29:31 Hmm.. I kinda feel like I'm somehow repeating myself Jun 28 16:29:46 oh well... It's a non-problem so far. Jun 28 16:30:02 yep. if mr_claus wants to solve it, then more power to him :-) Jun 28 16:30:29 we like people who solve stuff Jun 28 16:30:31 :D **** BEGIN LOGGING AT Tue Jun 28 16:39:15 2005 Jun 28 18:55:39 Looks like the next release of monotone (0.20) fixes the problems we have been having. Jun 28 18:56:48 <[g2]-away> that's good news :) Jun 28 19:03:39 In my test case (see http://www.nslu2-linux.org/wiki/Monotone/ProblemsWithBranches) the latest version drops the unwanted branches: Jun 28 19:03:50 monotone: warning: Dropping branch certs for unwanted branch org.bar.dev Jun 28 19:07:02 Yep, all the problems I had are fixed. Jun 28 19:32:09 excellent! **** ENDING LOGGING AT Tue Jun 28 23:59:56 2005