Re: New kernel unable to mount/see a whole HD
On Mon, Jan 02, 2006 at 09:53:38AM -0600, Michael Martinell wrote:
> On Mon, January 2, 2006 9:39 am, J.F. Gratton wrote:
> > (I must first start by apologizing if you've seen this post twice in
> > 12hrs.. I've had problems here with my smtp; not sure it went well)
> > Hello,
> > I've been unable to access any partition on /dev/hda since I've compiled
> > my own kernel 220.127.116.11 . I'm currently running 2.6.12-10.
> > I want to get rid of initrd and compile my own kernels (I've done it for
> > a long time, it's just that since Deb 3.0 rX I have been a bit lazy and
> > let the OS install new ones when new ones were available).
> > Now, on /dev/hda I have all my "foreign" OS partitions (ntfs and vfat
> > filesystems, as well as UFS -for solaris).
> > For the life of me, I can't see any pertinent changes between my two
> > kernel configs (provided in attachments) that might give the slightest
> > clue as to why kernel-2.6.12 (dpkg-provided) will mount /dev/hda* and
> > why kernel-18.104.22.168 (user-compiled) won't.
> > The console won't spew any error messages concerning the missing vfat
> > partitions. If I manually try to mount them (say.. mount -t
> > vfat /dev/hdb6 /mnt/temp-mountpoint), I get a "/dev/hda6 : device busy".
> > So I guess it "knows" that /dev/hdb6 exists, right ?
> > It's not a question of filesystems not being included in modules/kernel;
> > there are vfat partitions on /dev/hdb and those are being seen and
> > mounted. I insist on the fact that *everything* works just fine with
> > 2.6.12 but not with 22.214.171.124.
> > Anyhow.. I'm stumped, can't see why it won't go ok with 126.96.36.199, if
> > anyone can help me out with the files attached, just go ahead, please :)
> > Regards, and best wishes for 2k6 !
> > -- Jeff
> This may seem a bit obvious, but did you try to copy config-currentkernel that
> relates to your old install (from /boot), rename it to .config and put it into
> your source path for the new kernel. That should give you the exact same
> config that you are currently using. Then you could just run the configure
> program (make menuconfig) for the kernel to select or unselect any other
> features. Then save the new .config file. In this way you can verify that
> your previously known good config is the one you are using. I have complied
> lots of kernel's, however have only had problems when I try to create a
> .config from scratch.
As an infrequent builder of special kernels, I have found it useful to insert
another step into the above procedure. Before I make my changes to .config, I
do a trial run of compiling. That is to say, I compile, as best I can, the same
kernel as is given in the Debian distribution. If I can't do this, I know I am
doing something wrong, independent of any changes I hope to make. At this stage
I catch dumb mistakes that I frequently make when working from memory.
Paul E Condon