Re: New kernel unable to mount/see a whole HD
On Mon, Jan 02, 2006 at 05:49:46PM -0500, J.F. Gratton wrote:
> On Tue, 2006-01-03 at 06:32 +1100, Andrew Vaughan wrote:
>
> > > > > On Mon, January 2, 2006 9:39 am, J.F. Gratton wrote:
>
> > > Well I tried your (Michael and Paul's) ways (which, btw used to be the
> > [...]
> > >
> > > A bit of info I did not have -because I did not think of it- before:
> > > cfdisk /dev/hda shows the drive and partitions. It just won't mount
> > > them !! mount -t vfat /dev/hdaX will get me a "device busy". It _is_
> > > annoying.
> > >
> > > The only real differences between the distro-provided kernel and the one
> > > I want to build is basically I want some amd64 specific tweaks, I want
> > > to get rid of the initrd and prevent compiling of many useless modules;
> > > nothing really esoteric per se.
> > >
> > > I _am_ stumped...
> > >
> > > -- Jeff
> >
> > Hi Jeff
> >
> > Your original dmesg-2.6.14.5 showed the following error repeated 20+ times
> > [ 16.627169] device-mapper: dm-linear: Device lookup failed
> > [ 16.627195] device-mapper: error adding target to table
> >
> > I'm not sure what it means, but thats where I'd start.
> >
> > HTH
> > Andrew
>
>
> ... how could I have missed those errors ??
>
> Thanks Andrew.
> Unfortunately.. those are not related. I've checked around. Those are
> generated when /etc/rcS.d/S27evms (Enterprise Volume Manager). I can't
> see why it runs, I'll look at sometime else.
>
> Back to the original problem then.. why are my /dev/hda* partitions not
> mounted and tagged as "busy" if I try to mount them manually ?
>
> Thanks again Andrew,
>
> -- Jeff
>
>
One big difference is that 2.6.14 does not provide devfs but 2.6.12
does. If you have stuff dependent on devfs, it probably won't work
under 2.6.14. My guess is that your problems are elsewhere, however.
Your successes all involved initrd's, and you apparently have evms
installed. 2.6 kernels only allow a single owner for block devices,
so either evms gets them or the kernel gets them. The other is
blocked. If you boot without the ramdisk, the kernel gets there
first. If you use the ramdisk, and have things appropriately set,
evms will get there first. I just found this out the hard way. See
the discussion of the bd-claim patch at
http://evms.sourceforge.net/install/kernel.html for more, including
various options for letting evms and the kernel live in peace.
The behavior you describe makes it sound as if your system (in
particular, fstab and your boot loader) are set to use evms devices.
In that case, the initrd is the preferred method (say the evms docs),
but there are 2 other alternatives that don't require it.
Ross
Reply to: