next step

next step

[Rodrigo Moya]

Hi all!

After my problems compiling, I've successfully compiled all the MTD files,
and now I boot my system from the zip drive and I can even 'fdisk
/dev/nftla'.

So, now I have to put the system in the zip drive into the DOC. What steps
do I need? I've been thinking about:

fdisk /dev/nftla -> and create a unique partition for linux
dd if=/dev/sda4 of=/dev/nftla1
/sbin/lilo -> should I use the patched LILO I suppose?

But I'd like to have your opinion before doing so. Is there any other thing
I must do?

Another thing: it is impossible for me to subscribe to the mailing list
with my new email address. I always get a response like the following:

>>>>>>>>>>>>>>>>>>>>>>>>>>
The original message was received at Wed, 3 May 2000 06:14:40 -0700
from 57222.rad.tsai.es [194.224.57.222]

   ----- The following addresses had permanent fatal errors -----
<majordomo@infradead.org>

   ----- Transcript of session follows -----
.. while talking to imladris.infradead.org.:
>>> RCPT To:<majordomo@infradead.org>
<<< 550-above.net has multiple open relays and has blocked the ORBS tester.
<<< 550 mail from 208.184.88.8 rejected: administrative prohibition
550 <majordomo@infradead.org>... User unknown
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

The same happens when sending mail directly to David. I don't know if it's
my fault or not, any idea?

Cheers


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: next step

[David Woodhouse]

rmoya@tsai.es said:
>  After my problems compiling, I've successfully compiled all the MTD
> files, and now I boot my system from the zip drive and I can even
> 'fdisk /dev/nftla'.

Excellent.

> So, now I have to put the system in the zip drive into the DOC. What
> steps do I need? I've been thinking about:

> fdisk /dev/nftla -> and create a unique partition for linux 

yes. 

> dd if=/dev/sda4 of=/dev/nftla1 

It's probably best to use dump/restore rather than dd. 

> /sbin/lilo -> should I use the patched LILO I suppose?

I assume so - I haven't tried it. I'm working on fixing Grub instead.


> Another thing: it is impossible for me to subscribe to the mailing
> list with my new email address. I always get a response like the
> following:

<<< 550-above.net has multiple open relays and has blocked the ORBS tester.
<<< 550 mail from 208.184.88.8 rejected: administrative prohibition

See http://www.orbs.org/ and possibly change your ISP. You can send mail 
directly to me by using the address David.Woodhouse@mvhi.com, which will 
only warn about the blacklisting, not bounce the messages.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: next step

[Rodrigo Moya]

Hi!

I've run fdisk on the DOC. I create the partition, and when I press 'w' to
write changes to disk, it says:

Calling ioctl() to re-read partition table.
No Virtual Unit Chains available for folding. Failing request
Cannot make free space.
NFTL_writeblock(): Cannot find block to write to
end_request: I/O error, dev 5d:00 (nftl), sector 1
 nftla:<5>ll_rw_block: device 5d:00: only 512-char blocks implemented
(1024)
 unable to read partition table
 nftla:<5>ll_rw_block: device 5d:00: only 512-char blocks implemented
(1024)
 unable to read partition table
Syncing disks.
..

I forgot to mention that there was (yes there was because I guess I've
dropped it) a DOS system on the DOC.

I'm using the patched lilo

What's wrong?


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

next step

[Dvir Oren]

Rodrigo Moya writes ("next step"):

> fdisk /dev/nftla -> and create a unique partition for linux
 
Note that in my experience you sometimes (always?) have to boot after
changing the partition table, as the re-read does not always work.
 
Also, David once told me that fdisking /dev/nftla when nftl.o is loaded
(which will always be true if you are using a kernel with the MTD drivers
build-in) might not work.  This is to be checked with David.
 
> dd if=/dev/sda4 of=/dev/nftla1
 
That will probably work, though it's not a clean way of doing it.  Perhaps
a tarred and gzipped file would be better.  You might even want to run a
regular distribution setup - if you have the space for it.
 
> /sbin/lilo -> should I use the patched LILO I suppose?
 
You do need the patched LILO with the patched boot.b file.  I don't if you
can get the patched LILO from David's tree, but it was posted by me on this
list - so you should be able to get it.  Note that there are two patched 
LILOs, one to work with M-Systems' drivers, one that will work with both
M-Systems' and MTD's drivers.

-- 
Dvir Oren               <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: next step

[David Woodhouse]

dvir@lucidvon.com said:
>  Also, David once told me that fdisking /dev/nftla when nftl.o is
> loaded (which will always be true if you are using a kernel with the
> MTD drivers build-in) might not work.  This is to be checked with
> David.
>  

Any access to /dev/nftla (including fdisk) _requires_ the nftl.o module to 
be loaded. But you shouldn't have any of it mounted if you're 
repartitioning it, as with any other block device.

What I pointed out to you was that you shouldn't have nftl.o loaded when you
use nftl_format to completely reinitialise the NFTL on the flash - because
nftl.o will cache some information off the (original) nftl format, and will
get utterly confused when you you change it all.

NFTL is like a filesystem, which resides on the actual flash (/dev/mtd0). 

When you load the nftl.o module, it's like mounting that filesystem. 

Unlike a normal filesystem, NFTL provides a block device (on top of which
you will generally put another, normal, filesystem), and the nftl.o module
'mounts' the NFTL from the flash as soon as it's loaded. 

So when you use nftl_format or anything else to access the flash directly,
you will utterly confuse the NFTL code if it's still present - because it's
always 'mounted'. It's just like writing directly to a block device while 
it's mounted. Hence, you have to remove the NFTL support before writing 
directly to the flash. Unless you're only updating the firmware, which 
doesn't affect the area in which the NFTL is stored on the flash.




--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org