> On 06-08-22 11:45 +0100, Nick Bane wrote:
>> L3 news.
>>
>> I have a balloon3 with 196MB RAM using CF wifi running Debian Etch on a usb 
>> memmory stick (2GB ext3 with an Etch chroot partition of about 600MB) 
> 
Hmm. Thats a nuissance. I'll downgrade it to ext2 as a precaution then.

> Just one thing. ext3 on a CF card can be fatal to the card in less
> than 10 boots. This might well be true for USB sticks too. The problem
> is that every write to the device goes through the journal which is
> 32MB or so at the end of the device. That bit of flash can get worn
> out very quickly indeed, depending on exactly what (if anything) the
> controller does to avoid problems of block overuse. (They sometimes
> only do this for the beginning of the device where the FAT cluster
> tables go). It may be that the controllers have got smarter than they
> were 2 yrs ago, but you can't easily tell...
> 
>> I put the etch debootstrap tgz on the balloonboard feed in case anyone 
>> wanted a handy image.
> 
> Excellent. Where on the feed. I can't see it in last nights rsync of 
> balloonboard.org::balloon Do you mean it's somewhere on husaberg?
> 
Its cunningly hidden in an obscure directory called Debian :-)

>> Problems log:
>> - I was getting loads of unexpected yaffs errors but I am unclear what is 
>> producing them - udev on running udevstart seemed to create a lot of output 
>> about i/o errors on mtdblock0 - what is it trying to do?? If it is test 
>> mounting a vfat partition or something then that might account for it. Now 
>> the problems have .. err .. gone away. Perplexing.
> 
> I don't think udev does anything for mtd devices beyond ensuring that
> the /dev files appear. 
> 
The really odd thing is that the problem went away, then had a brief burst 
of mayhem and has now continued to boot normally many times. Of course I 
blame the fpga state machine and of couse DB blames my flakey code. Time 
will tell.
>> - The ext3 module seemed to loose its marbles on modprobe due to unresolved 
>> names and so the ext3 partition reverts to ext2. This is fixed by building 
>> ext3 into the kernel.
> 
> As explained above you'd probably be better off unfixing it and sticking with
> ext2.
> 
> Wookey