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

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 2.6.14.5 . 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-2.6.14.5 (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 2.6.14.5.
> >
> > Anyhow.. I'm stumped, can't see why it won't go ok with 2.6.15.4, 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.

HTH

-- 
Paul E Condon           
pecondon@mesanetworks.net



Reply to: