**** BEGIN LOGGING AT Fri Jul 13 02:59:57 2007 Jul 13 11:45:17 Hello Jul 13 14:45:03 Hi, can someone tell me if "slugosle" has different fs handeling than debian? Jul 13 14:45:58 I recently did fsch.ext3 under debian and now some files cannot be accessed by slugosle Jul 13 14:46:52 when i do ls the responce is sth like 'cannot stat' Jul 13 14:47:51 when I do fsck.ext3 under slugosle then I have the same problem under debian (on laptop) Jul 13 14:48:22 any ideas ? Jul 13 16:06:49 pepesz76: There shouldn't be a problem with that. Are you mounting it as ext3 under both? Jul 13 17:41:07 joshin: both are mounted in the same way Jul 13 17:41:30 but I noticed something else Jul 13 17:42:26 the problem also appears on the slug itself depending which fsck is used Jul 13 17:43:40 looks like /initrd/sbin/fsck.ext3 Jul 13 17:44:03 and /sbin/fsck.ext3 are conflicting Jul 13 17:44:34 one makes the problem to the other Jul 13 17:45:35 I'm pretty sure that the fsck built by default on slugos is the busybox version. You can track down e2fsprogs from the distribution package repository. Jul 13 17:46:20 I have seen some minor weird things with the busybox fsck. Jul 13 17:52:22 it is possible, however looks like the "proper" one is the one which comes with slugosle build Jul 13 17:53:11 so to be able to see all files I have to use the one from the /initrd/.... Jul 13 17:53:56 which makes the disk incompatibile with other systems :( Jul 13 17:54:21 It happens only to files with special characters Jul 13 19:29:52 pepesz76: google about for this problem; it sounds to me like a locale-related issue. Can you compare the two fsck.ext3's -- are they the same file? Did you install any ipkg's that might include updated fsck utils? Jul 13 19:29:59 What SlugOS release is this? Jul 13 19:35:15 e2fsck 1.38 (30-Jun-2005) Jul 13 19:35:15 Using EXT2FS Library version 1.38, 30-Jun-2005 Jul 13 19:35:45 initrd/sbin/fsck.ext3 -V Jul 13 19:36:12 and from /sbin/fsck.ext3 : Jul 13 19:36:51 e2fsck 1.40-WIP (14-Nov-2006) Jul 13 19:36:51 Using EXT2FS Library version 1.40-WIP, 14-Nov-2006 Jul 13 19:38:19 my laptop uses 1.39 and it's behaving like 1.40 Jul 13 19:39:35 I also was thinking about locales issues, however those two: /initrd/.... and /sbin/... are on the same machine. Jul 13 19:40:09 I tried to google for it but w/o success Jul 13 19:45:00 The "turnup -i disk" operation copies the flash to the external disk. So you have either done an ipgk upgrade or an ipkg install to put a newer fsck on the external device. Since the kernel and its modules remain at the orignal level, it's really not a suprise that the OS doesn't like the newer fsck. Jul 13 19:45:25 Is this SlugOS 3.10 or 2.7? Jul 13 19:47:03 4.3 or 4.4 Jul 13 19:47:31 Ah, ok. Moving target then. Jul 13 19:48:41 compiled in march kernel 2.6.20 Jul 13 19:48:45 How did you get the external device fsck.ext3 utility? Was that an ipkg upgrade (which would be a serious problem with the feeds), or was it an ipkg install of something? Jul 13 19:49:38 i guess it came from feeds Jul 13 19:49:47 I did bootstrap Jul 13 19:50:23 ?? Jul 13 19:50:34 Is that debian thing? Jul 13 19:50:52 yes Jul 13 19:51:11 So are you using debian, or slugosle then? Jul 13 19:51:11 it is slugosle Jul 13 19:51:26 and then bootstraped Jul 13 19:51:39 Bootstrapped from what? Jul 13 19:52:17 * mwester is confused Jul 13 19:52:46 ok, from beginning Jul 13 19:53:11 I compiled slugosle and flashed it Jul 13 19:53:59 then followed the nslu2-linux I bootstraped to external disk Jul 13 19:54:09 http://www.nslu2-linux.org/wiki/SlugOS/BootstrapLE Jul 13 19:54:25 that's the procedure Jul 13 19:54:32 Did you read the notice in red on that wiki page? Jul 13 19:54:55 that procedure is obsolete, and no longer works. Jul 13 19:55:05 saing that it is old procedre ?? Jul 13 19:55:07 yes Jul 13 19:55:36 it doesn't say that doesn't work Jul 13 19:56:46 and I belive I was the first with version 4 (besides developers), so I even wrote howto in mailing list Jul 13 19:57:05 Sigh. Ok, no, it doesn't say that in exactly those words. But it doesn't work anymore, as you've just discovered. Jul 13 19:57:10 at that time there was no note ... :) Jul 13 19:57:29 You have clearly ended up with a rootfs that has utilities that are newer than the utilities in the flash filesystem. Jul 13 19:58:02 It is probably true that the ext3 utils in the SlugOS head should be upgraded, perhaps that would make this procedure work once again. Jul 13 19:58:16 the reason I prefer slugosle is that it can work even w/o disk what is important 4 me as I have 3 of those and I wanted to have the same systemon all of them Jul 13 19:58:32 Regardless, if you want SlugOS, there is a different process, and if you want Debian, there is another process - this wiki page is neither of those. Jul 13 19:59:07 Then you'll have to work out the problems with the mis-match in utilities, if you want to create the special configuration. Jul 13 19:59:37 I think that the ext3 utilities should be upgraded in the flash, but there might be a reason that hasn't happened yet. Jul 13 19:59:38 Well beside that problem I described it works like the charm :) Jul 13 20:00:38 BTW, I do agree that the Debian for the NSLU2 has a major shortcoming in that it cannot boot from flash alone. Jul 13 20:02:15 what kind of utility mismatch you're talking about? Jul 13 20:02:27 the way the kernel accessing the disk ? Jul 13 20:02:52 or the structure of disk itself Jul 13 20:04:29 because fsck mismatch will not cause problems with access by two different linux distributions, isn't is ? Jul 13 20:04:46 that the two fsck utilities are different versions, and behave differently. Clearly one is doing something to the disk that the other does not. If it is not locale-related, or a build-time option that is incompatible, then something must have changed between the two version. Jul 13 20:04:55 corect me if I'm wrong, I'm still learning Jul 13 20:05:17 fsck is *supposed* to complain if it sees a version flag in the filessytem that is newer than the fsck version. Jul 13 20:05:49 nothing like that happened Jul 13 20:06:27 Right. But still, you have confirmed that fsck'ing with one causes problems, while fsck'ing with the other does not, right? Jul 13 20:06:57 no Jul 13 20:07:00 both ways Jul 13 20:07:15 The one in the flash (built along with the kernel and modules) works correctly, the external one from Debian results in a filesystem that the kernel cannot properly read. Jul 13 20:07:21 letme make it clear Jul 13 20:07:41 yes Jul 13 20:07:52 your last sentence is OK Jul 13 20:09:05 but if i will make fsck with the Debian thing and then I will connect that disk to debian machine then everything is ok Jul 13 20:09:23 debian machine = laptop Jul 13 20:10:12 so it is not like the /sbin/fsck is broken or so Jul 13 20:11:51 Well, something is broken, IMO. Either it should work on all the systems, or something should complain that the disk format is too new, or too old, or something. Jul 13 20:12:20 probably you're right :) Jul 13 20:13:26 Can you write this up as a bug and email to the mailing list? It would be important to have a simple example of how to create the problem (i.e. what special characters in the filename trigger it, etc), so that the developers can take a look at it. Jul 13 20:14:30 I will try to deal with it, beginning of the next week, I do not have phisical access to that slug Jul 13 20:14:33 I can check at least if the ext3 utilities in OE are up-to-date. Jul 13 20:14:49 ok, will be great Jul 13 20:14:54 But that won't help solve the problem, as I don't have a Debian system to test with. Jul 13 20:15:14 No problem, I will fight with it :) Jul 13 20:15:23 Thank's for help \ Jul 13 20:15:53 Can you tell me what'sthe proper procedure to have slugosle ?? Jul 13 20:18:02 Is there a "correct bootstrap" procedure ? Jul 13 20:23:13 For slugosle, just do the "turnup -i disk" thing, and then use ipkg to install the software you need. Jul 13 20:27:48 and how do I install things like apache, php... things which are not in http://ipkg.nslu2-linux.org/feeds/slugosle/cross/ Jul 13 20:31:48 I will try to find the reason for my problem, I will report the bug but I will keep the system running since it is very stable and since I do not exchange second disk too often I can survive with it glitch. I will post the results from my small investigation. Thanks again for your time and help **** ENDING LOGGING AT Sat Jul 14 02:59:56 2007