root=/dev/sda1 fails but root=0x0801 works...

root=/dev/sda1 fails but root=0x0801 works...

[John Z. Bohach]

This is probably a question with an obvious answer, but I haven't found it
elsewhere, so I hope its okay if I ask here...

As the subject says, if I have my kernel command line with
'...root=/dev/sda1...' then I get

VFS: Cannot open root device "sda1" or unknown-block(0,0)

however, everything else being the same, if I have
'...root=0x0801...', then it works fine.  Note that 

SCSI device sda: 2001888 512-byte hdwr sectors (1025 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
 sda: sda1
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0

preceeds this in the console both for the failed case and the succeeding case
(as I already have the rootdelay=10 param. on the command line as well).

I've narrowed this down to another CONFIG_* option, but I can't find which
one in tractable time...

Does anybody know which CONFIG_* option might contribute to text string
root=/dev/sda1 failing while its root=0x0801 cousin works?  I've already tried the
CONFIG_KALLSYMS one, but no luck.  Would this possibly have to do with
CONFIG_NLS=m (et al),  as I have those as modules, and if so, is this intentional?

Thanks,
John


-- 
     ###  Any similarity between my views and the truth is completely ###
     ###  coincidental, except that they are endorsed by NO ONE       ###

Re: root=/dev/sda1 fails but root=0x0801 works...

[Phillip Susi]

John Z. Bohach wrote:
> This is probably a question with an obvious answer, but I haven't found it
> elsewhere, so I hope its okay if I ask here...
>
> As the subject says, if I have my kernel command line with
> '...root=/dev/sda1...' then I get
>
> VFS: Cannot open root device "sda1" or unknown-block(0,0)
>
> however, everything else being the same, if I have
> '...root=0x0801...', then it works fine.  Note that 
>
> SCSI device sda: 2001888 512-byte hdwr sectors (1025 MB)
> sda: Write Protect is off
> sda: assuming drive cache: write through
>  sda: sda1
> Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
>
> preceeds this in the console both for the failed case and the succeeding case
> (as I already have the rootdelay=10 param. on the command line as well).
>
> I've narrowed this down to another CONFIG_* option, but I can't find which
> one in tractable time...
>
> Does anybody know which CONFIG_* option might contribute to text string
> root=/dev/sda1 failing while its root=0x0801 cousin works?  I've already tried the
> CONFIG_KALLSYMS one, but no luck.  Would this possibly have to do with
> CONFIG_NLS=m (et al),  as I have those as modules, and if so, is this intentional?
>
> Thanks,
> John
>   

This is expected behavior.  The kernel doesn't have a /dev at the time 
it mounts the root fs so it has no idea what /dev/sda1 is.  Typically 
lilo will translate /dev/sda1 to 0x0801 automatically for you and pass 
that to the kernel for this reason. 

These days most distributions are using an initrd which the kernel 
mounts as the root fs, and that sets up a minimal /dev and does some 
hardware detection.  In that scenario, you can use free form /dev 
strings, assuming that they actually exist by the time the initrd's 
startup scripts finish running. 

Re: root=/dev/sda1 fails but root=0x0801 works...

[Al Viro]

On Tue, Feb 14, 2006 at 10:42:44AM -0500, Phillip Susi wrote:

> This is expected behavior.  The kernel doesn't have a /dev at the time 
> it mounts the root fs so it has no idea what /dev/sda1 is.

Incorrect.  Read init/do_mounts.c::name_to_dev_t().

Re: root=/dev/sda1 fails but root=0x0801 works...

[John Z. Bohach]

On Tuesday 14 February 2006 08:24, Al Viro wrote:
> On Tue, Feb 14, 2006 at 10:42:44AM -0500, Phillip Susi wrote:
> > This is expected behavior.  The kernel doesn't have a /dev at the time
> > it mounts the root fs so it has no idea what /dev/sda1 is.
>
> Incorrect.  Read init/do_mounts.c::name_to_dev_t().

Thanks for the info...Philip, you are correct, but for the wrong reason.  Al,
you hit it right on the head...

It is intentional behavior, but the reason is that
for name_to_dev_t() to work, CONFIG_SYSFS must be enabled...so there's
my connection to the CONFIG_* option that I suspected...

Thanks again...

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
     ###  Any similarity between my views and the truth is completely ###
     ###  coincidental, except that they are endorsed by NO ONE       ###

Re: root=/dev/sda1 fails but root=0x0801 works...

[Phillip Susi]

John Z. Bohach wrote:
> Thanks for the info...Philip, you are correct, but for the wrong reason.  Al,
> you hit it right on the head...
>
> It is intentional behavior, but the reason is that
> for name_to_dev_t() to work, CONFIG_SYSFS must be enabled...so there's
> my connection to the CONFIG_* option that I suspected...
>
> Thanks again...
>   

I see, I wonder when that got added.  Does there happen to be a way to 
turn that off, but keep sysfs?  Since I use an initramfs ( ubuntu ) 
there is no need for the kernel to contain such code.  I wonder what 
other bits of code could be removed when you use an initramfs?

Re: root=/dev/sda1 fails but root=0x0801 works...

[Andrew Morton]

Al Viro <viro@ftp.linux.org.uk> wrote:
>
> Read init/do_mounts.c::name_to_dev_t().
>

I tried to do that a while ago, when I was trying to use it for
name_to_dev_t()ing in swsusp somewhere.


>From my notes at the time:

  a) It barfs if /sys is already mounted.

  b) Fix that, mkdir and mount barf because it needs set_fs(KERNEL_DS)

  c) Fix that, it barfs because name_to_dev_t is just broken.  It is
     accessing the wrong pathnames in /sys.

I think it needs a bit of help.

Re: root=/dev/sda1 fails but root=0x0801 works...

[Al Viro]

On Tue, Feb 14, 2006 at 10:59:50PM -0800, Andrew Morton wrote:
> Al Viro <viro@ftp.linux.org.uk> wrote:
> >
> > Read init/do_mounts.c::name_to_dev_t().
> >
> 
> I tried to do that a while ago, when I was trying to use it for
> name_to_dev_t()ing in swsusp somewhere.
> 
> 
> >From my notes at the time:
> 
>   a) It barfs if /sys is already mounted.

It's called from late boot code.
 
>   b) Fix that, mkdir and mount barf because it needs set_fs(KERNEL_DS)

It's called from late boot code, running as kernel thread.

>   c) Fix that, it barfs because name_to_dev_t is just broken.  It is
>      accessing the wrong pathnames in /sys.

Details, please.

Re: root=/dev/sda1 fails but root=0x0801 works...

[Andrew Morton]

Al Viro <viro@ftp.linux.org.uk> wrote:
>
> On Tue, Feb 14, 2006 at 10:59:50PM -0800, Andrew Morton wrote:
> > Al Viro <viro@ftp.linux.org.uk> wrote:
> > >
> > > Read init/do_mounts.c::name_to_dev_t().
> > >
> > 
> > I tried to do that a while ago, when I was trying to use it for
> > name_to_dev_t()ing in swsusp somewhere.
> > 
> > 
> > >From my notes at the time:
> > 
> >   a) It barfs if /sys is already mounted.
> 
> It's called from late boot code.
>  
> >   b) Fix that, mkdir and mount barf because it needs set_fs(KERNEL_DS)
> 
> It's called from late boot code, running as kernel thread.

Well.  I was trying to use it for something else...


> >   c) Fix that, it barfs because name_to_dev_t is just broken.  It is
> >      accessing the wrong pathnames in /sys.
> 
> Details, please.

I just don't remember, sorry.  From inspection it _looks_ OK.  But I do
remember getting -ENOENT, looking at the pathnames and deciding that it was
miles off.

swsusp has a habit of leaving a trailing \n at the end of resume_file, but
it was more than that.

And I threw away the patch which exercised this.  Oh well.

(Wonders whether software_resume()'s call to name_to_dev_t() can work and
if so, whether all that stuff as well as name_to_dev_t() can become __init).

Re: root=/dev/sda1 fails but root=0x0801 works...

[Al Viro]

On Tue, Feb 14, 2006 at 11:32:56PM -0800, Andrew Morton wrote:
> > 
> > Details, please.
> 
> I just don't remember, sorry.  From inspection it _looks_ OK.  But I do
> remember getting -ENOENT, looking at the pathnames and deciding that it was
> miles off.
> 
> swsusp has a habit of leaving a trailing \n at the end of resume_file, but
> it was more than that.
> 
> And I threw away the patch which exercised this.  Oh well.
> 
> (Wonders whether software_resume()'s call to name_to_dev_t() can work and
> if so, whether all that stuff as well as name_to_dev_t() can become __init).

Well...  FWIC, it should go into kinit and disappear from the kernel proper,
along with all its callers.  Now that hpa had created kernel+klibc+kinit
tree, we might finally get there...