[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MDLUG] Re: RAM upgrade == Kernel Panic---cramfs problem

On Wed, Jun 12, 2002 at 10:07:40PM -0400, Joe Landman wrote:
| On Wed, 2002-06-12 at 21:13, Tom Allison wrote:
| > devfs: v1.10 (20020120) Richard Gooch
| > devfs: boot_options: 0x0
| No matter what else is a problem, the above is also very much a problem.
| Just say no to devfs.

I've been using devfs for months.  I really like it.  It makes it much
easier to identify problems with "missing" devices.  (I can't read my
cd, but /dev/cdrom is there.  It doesn't matter if the inode is on

Besides, you can have devfs compiled (the pre-packaged kernels do) and
not enabled.  When I boot I get these relevant lines :

    devfs: boot_options: 0x1
    Mounted devfs on /dev

If that second line is missing, then devfs isn't even being used on
Tom's system.

| It mucks with device things in ways that cause
| exactly the sort of problem you have.

I did find the root= semantics to be unintuitive.  I use the old
/dev/hda1 notation for the root=.  After boot (after devfsd is
started) it doesn't matter which I use.  It's just a name, nothing
more nothing less.

| When you get this "VFS: Unable to mount root fs on ..." error, this
| generally means that the kernel was told root (the /) is on /dev/hdaX
| when in fact, it is on /dev/hdaY (Y != X).

Either that or you're missing a critical driver, or you don't have a
root= parameter (happened to me once due to a typo).  (or maybe some
new condition I haven't seen before)

| Note how devfs can contribute to this, as root may really be on
| /dev/ide/bus/0/part/1 or whatever sillyness it forces.

The name is (largely) irrelevant.  The major:minor modes are the same.
(however, I found that I was unable to use
root=/dev/ide/host0/bus0/target0/lun0/part1, but can (and do) use


> SELECT * FROM users WHERE clue > 0
0 rows returned


Attachment: pgpDS1JtrGdUo.pgp
Description: PGP signature

Reply to: