is this a bug ?

is this a bug ?

[Ashwin Chaugule]

 Hi,
      Im using 2.4.19-rmk7-pxa1, on a pxa255. Recently I mounted jffs2 
as rootfs. While doing this the conventional way, I found that
it was being mounted readonly. Since I'm using M28W640 (ST flash) which 
needs to be unlocked upon every reboot, I thought the readonly
was because of this locking thing. So, I integrated the flash_unlock 
code into the mtd subsystem, but I still got the readonly mount.
After digging into init/do_mounts.c , I found  root_mountflags was by 
default readonly, and is sent to mount_block_root("/dev/root", 
root_mountflags);  only to be later reassigned somewhere in fs/super.c ! 
(s->s_flags = flags;)

The following addition to do_mounts.c , did the trick.

+ root_mountflags &= ~MS_RDONLY;
   mount_block_root("/dev/root", root_mountflags);

Now jffs2 mounts nice and clean, with readwrite !

I know you guys have dropped support for 2.4.x, but just for 
clarification, might even help several others struggling to get jffs2 
working as rootfs :)

Cheers,
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys Ltd.
[Embedded Division]

Re: is this a bug ?

[Thomas Gleixner]

On Sat, 2005-08-20 at 05:44 +0530, Ashwin Chaugule wrote:

> The following addition to do_mounts.c , did the trick.
> 
> + root_mountflags &= ~MS_RDONLY;
>    mount_block_root("/dev/root", root_mountflags);

Uurg. RTFM !

There are at least two sane ways to do that without touching the kernel
code.

- Documentation/kernel-parameters.txt (hint: rootflags)
- man mount (hint: remount)

tglx

Re: is this a bug ?

[Ashwin Chaugule]

Thomas Gleixner wrote:

>Uurg. RTFM !
>
>There are at least two sane ways to do that without touching the kernel
>code.
>
>- Documentation/kernel-parameters.txt (hint: rootflags)
>  
>
In 2.6.12-2 my cmdline is ..

CONFIG_CMDLINE="root=/dev/mtdblock1 rootfstype=jffs2 init=/bin/sh console=ttyS0,38400 mem=32M"


Jffs2 mounts just fine. No rootflags changes anywhere !



Cheers,
Ashwin

Re: is this a bug ?

[Thomas Gleixner]

On Sat, 2005-08-20 at 07:06 +0530, Ashwin Chaugule wrote:

> >
> In 2.6.12-2 my cmdline is ..

>From your previous mail

>     Im using 2.4.19-rmk7-pxa1, on a pxa255. .....
> 
> After digging into init/do_mounts.c , I found  root_mountflags was by 
> default readonly,

So what ? You were asking a question about 2.4.19 and you got an answer
related to that. It's coded that way in the ancient, broken and obsolete
2.4.19... kernel and there are two ways to solve that without hacking
the kernel code.

Where is the bug ?

tglx

Re: is this a bug ?

[ashwinc]

> So what ? You were asking a question about 2.4.19 and you got an answer
> related to that. It's coded that way in the ancient, broken and obsolete
> 2.4.19...

Couldnt agree more. But the deadlines prohibit us from upgrading it right
now. In fact I  have already fired up the board with 2.6.12-2 as stated
earlier, but theres still a while till I get everything we have running on
it.

>
> Where is the bug ?

Well, the fact that it works without any changes in 2.6.x, and that I had
to change it in 2.4. Basically, it seemed strange that rootflags is just
passed in from do_mount, remains unchanged, and later reassigned to
sb->flags in super.c.... seemed strange thats all. BTW I still need to
find out whats done differently in 2.6.x. I'm not implying this is a jffs2
bug anywhere, I just posted this to see if anyone else observed this,
since there are several others still using 2.4.19. Also, I didnt know of
the cmdline way of doing this without hacking into the source. Call me a
rookie if you want.

Well, now I know :)

Cheers,
Ashwin






**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Aftek Infosys Limited 
is 'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying 
or dissemination of the information contained in the E-MAIL in any manner 
whatsoever is strictly prohibited.
***************************************************************************
http://www.aftek.com/