Bug 7955 - rootfstype used with linuxrc of different fs type fails to start
Summary: rootfstype used with linuxrc of different fs type fails to start
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: fs_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-06 18:42 UTC by Ken
Modified: 2008-09-23 08:52 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.12
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Ken 2007-02-06 18:42:53 UTC
Most recent kernel where this bug did *NOT* occur:
Distribution:
Mandriva Corporate 3.0
Hardware Environment:
x86
Software Environment:
Mandriva Corp 30
Problem Description:

Steps to reproduce:
(1) Create initial ram disk image file using one filesystem (say, for eg. ext2)
(2) Create linuxrc file that redirects /dev/root to other filesystem (say ext3)
         ...
         echo Mounting /proc filesystem
         mount -t proc /proc /proc
         echo Creating device files
         mkdevices /dev
         echo Mounting sysfs
         mount -t sysfs none /sys
         echo Creating root device
         echo 0x0306 > /proc/sys/kernel/real-root-dev
         mkrootdev /dev/root
         umount /sys
         umount /proc
(3) Set bootloader append line to include "root=3:6 rootfstype=ext3"
   where 3:6 is the real root filesystem
(4) Boot with the above initrd image and append line.
Result:
VFS: Cannot open root device "ram" or unknown_block(1,0)

My expectation was that initrd would be mounted ext2 followed by execution of
linuxrc nash script followed by mounting device "3:6" using ext3 type.  However,
the initrd was detected and loaded as ext2 but then gave error listed above.

The 'rootfstype' option seems to confuse the initial RAM disk load which had
previously loaded the "ext2" RAM disk image.  The following patch to
init/do_mounts.c allows the initrd image to remain ext2 while the real file
system type obeys 'rootfstype' append line option.

 void __init mount_block_root(char *name, int flags)
 {
+static char const default_fs[] = "ext2\000\000";
        char *fs_names = __getname();
        char *p;
        char b[BDEVNAME_SIZE];

-       get_fs_names(fs_names);
+        if (   strstr(name, ".old") )
+            memcpy(fs_names, default_fs, sizeof(default_fs));
+        else
+           get_fs_names(fs_names);
 retry:
        for (p = fs_names; *p; p += strlen(p)+1) {
                int err = do_mount_root(name, p, flags, root_mount_data);
Comment 1 Anonymous Emailer 2007-02-06 20:05:49 UTC
Reply-To: akpm@linux-foundation.org

On Tue, 6 Feb 2007 18:52:13 -0800 bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7955
> 
>            Summary: rootfstype used with linuxrc of different fs type fails
>                     to start
>     Kernel Version: 2.6.12
>             Status: NEW
>           Severity: normal
>              Owner: fs_other@kernel-bugs.osdl.org
>          Submitter: ken.cole@bownetworks.com
> 
> 
> Most recent kernel where this bug did *NOT* occur:
> Distribution:
> Mandriva Corporate 3.0
> Hardware Environment:
> x86
> Software Environment:
> Mandriva Corp 30
> Problem Description:
> 
> Steps to reproduce:
> (1) Create initial ram disk image file using one filesystem (say, for eg. ext2)
> (2) Create linuxrc file that redirects /dev/root to other filesystem (say ext3)
>          ...
>          echo Mounting /proc filesystem
>          mount -t proc /proc /proc
>          echo Creating device files
>          mkdevices /dev
>          echo Mounting sysfs
>          mount -t sysfs none /sys
>          echo Creating root device
>          echo 0x0306 > /proc/sys/kernel/real-root-dev
>          mkrootdev /dev/root
>          umount /sys
>          umount /proc
> (3) Set bootloader append line to include "root=3:6 rootfstype=ext3"
>    where 3:6 is the real root filesystem
> (4) Boot with the above initrd image and append line.
> Result:
> VFS: Cannot open root device "ram" or unknown_block(1,0)
> 
> My expectation was that initrd would be mounted ext2 followed by execution of
> linuxrc nash script followed by mounting device "3:6" using ext3 type.  However,
> the initrd was detected and loaded as ext2 but then gave error listed above.
> 
> The 'rootfstype' option seems to confuse the initial RAM disk load which had
> previously loaded the "ext2" RAM disk image.  The following patch to
> init/do_mounts.c allows the initrd image to remain ext2 while the real file
> system type obeys 'rootfstype' append line option.
> 
>  void __init mount_block_root(char *name, int flags)
>  {
> +static char const default_fs[] = "ext2\000\000";
>         char *fs_names = __getname();
>         char *p;
>         char b[BDEVNAME_SIZE];
> 
> -       get_fs_names(fs_names);
> +        if (   strstr(name, ".old") )
> +            memcpy(fs_names, default_fs, sizeof(default_fs));
> +        else
> +           get_fs_names(fs_names);
>  retry:
>         for (p = fs_names; *p; p += strlen(p)+1) {
>                 int err = do_mount_root(name, p, flags, root_mount_data);
> 

We'd of course prefer to not hardcode the fstype like this.  Perhaps someone
else has time to look into this, or to suggest a solution?

Comment 2 Ken 2007-02-07 12:24:15 UTC
I understand your concern about hard-coding and having time to figure a better
approach.  A slightly better hard-coding (not tested) would be to use default
filesystem type "auto" because I understand that that choice checks filesystem
magic for selecting filesystem for the mount command.

If "auto\000\000" is also not acceptable then I would have to dig deeper to
propose another approach.  Any guidance as to a minimal requirement for
acceptance into the kernel would be appreciated (i.e. is auto acceptable?). 
Also, I am not yet familiar with the "tmpfs" technique for initrd images and I
would want that to work too for any proposed solution.
Comment 3 Natalie Protasevich 2007-05-23 16:51:18 UTC
Ken,
You can start with autofs approach and if it works - just submit it (and get
full code review :) And if your solution won't be optimal - there will be debate
and good suggestions during this process.

--Natalie
Comment 4 Natalie Protasevich 2008-02-14 21:24:14 UTC
Ken, any updates from you on this issue?
Thanks.

Note You need to log in before you can comment on or make changes to this bug.