> 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. I see it as an opportunity to understand the x86 boot process in more detail, so I am not scared :-)
> 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 It calls rootconf, of which there are two: one in usr/src/uts/common/fs/vfs.c:4103 and another in usr/src/uts/common/os/swapgeneric.c:123. I am sure my panic message comes from vfs.c, but I am curious about where the rootconf in swapgeneric.c is used (if at all). > > 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. I guess the ufs module is not failing to load, as this would cause the panic in line 4116, instead of the one I am getting (in line 4137). So it seems to succeed through the modload and fail after that. The cmdk driver is present in the boot-archive (I just lofiadm -a and mounted it and it is in /kernel/drv). The filesystem is also not corrupted, as I can mount it from my working Solaris 10 and Express installations. One issue might be the bootpath value I am using. From my bootenv.rc: setprop bootpath '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:g' This should correspond to my /dev/dsk/c0d0s6 hard disk slice. I don't understand why though it is referenced as if there were no /devices, that is, as if /[EMAIL PROTECTED],0 resided at the root. Just copied from a working bootenv.rc and changed the slice accordingly and ran bootadm update-archive -R /mnt. One curiosity: when mounting the boot archive to look inside it, I assumed it was UFS but mount refused it. Then I tried with -F hsfs and it worked. So the boot archive is a CD-like file system? > > 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). This will probably work, because I haven't yet changed the code. The problem is in the environment I am setting up not in the code I built. For example, I haven't setup a proper /devices structure, which I probably should and I was already warned that some /dev entries are required even before devfsadm is able to run for the boot to succeed, let alone some /etc files that may be required and I don't know about. So these details are in fact what I need to tame. > 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. I have tried setting moddebug/W 00000001 and :c on every module load to see which one fails. I have no conclusion, but it looks as if ufs loading triggers the panic. I will do this a few more times to make sure. > 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. In fact, I am trying the other way around. I am starting from nothing (in fact, from an OpenSolaris source build proto area, cp -r to an empty slice) and seeing how far I go with just that. Of course that didn't work. Then I created some /dev and /devices entries from the Belenix scripts Moinak Ghosh sent me. The boot archive is built from the same sources and the bootenv.rc file I stole from an existing installation and modified accordingly. With this, if one day it finally works, I may be able to write a check list of the minimal x86 dboot installation to boot directly from sources. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
