...
> OBP behaves for SPARC like the BIOS for x86, right? more or less.. it's more like BIOS + GRUB all in firmware. > > I am trying to figure out what happens now in the > boot as main calls vfs_mountroot > (usr/src/uts/common/os/main.c:440), which calls > rootconf (usr/src/uts/common/fs/vfs.c:805), which > calls VFS_MOUNTROOT(usr/src/uts/common/fs/vfs.c:4132) > which fails and spits the "cannot mount root path %s" > (usr/src/uts/common/fs/vfs.c:4137), where the %s > printed on my console is exactly the value of the > bootpath property I had set in > /boot/solaris/bootenv.rc and in the boot archive > (through a bootadm boot-archive -v -r /mnt): > '/[EMAIL PROTECTED],0/...'. It's been very difficult to figure it > out, as I don't have the slightest idea where the > rootvfs gets initialised to its vfs_ops. The vfssw > global variable seems to be uninitialised as of its > declaration (usr/src/uts/common/fs/vfs.c:3601) and I > found no code that initialises it afterwards. I > suppose this is past the boot archive file system > reading, so I suppose at this stage it might be > reading the real disk... Any hints here? sigh.. this is a painful place to be. I've had to debug my way out of here several times. Kernel boot fails at mount root due to any number of previous errors. The message when it fails is not helpful. There's also not a silver bullet to finding the problem. The vfs_mountroot() is really just calling the various mountroot functions in usr/src/uts/common/fs to see which succeeds - you're probably should be getting ufs_mountroot() when it works successfully Possibilities - the driver (or ufs) module for your root device either doesn't exist yet, is missing from the boot archive or failed to load. The filesystem it's trying to mount might be badly corrupted. Other things could be broken too. The suggestion I would have is to debug this in the following way. Install a new, stock version of a known good working solaris base onto the box. Then add your modified kernel (built from the same source base) to the environment using cap-I Install. (see other pages on OpenSolaris.org for details on that). You can then use kmdb (boot with -k -d flags) to step through and compare a working boot with a failing boot and see what goes wrong. Also, if possible, try to minimize your changes to small steps at a time, so that when something goes wrong, you know what you changed. That makes it easier to find problems. Good luck. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
