fc5 seek errors - nash mount (built-in)

[Peter Jones]

On Wed, 2006-03-29 at 18:47 -0500, James Olson wrote:

> > Are you seeing these errors after booting, or just during the boot
> > process?  If it's the former, they should be pretty harmless, though
> > ugly.
> The errors show up whenever you use nash's internal mount command.

Yes, I'm just wondering if there's any place else you see them.

> I did my test on my custom 2.6.16-rc4-mm1 kernel, in which I compiled
> my silicon image 680 raid card driver as a module, and moved it out of
> the /lib/modules/... tree so that I can # insmod siimage.ko at will
> after booting.  (You can't rmmod it at will, once inserted, that
> driver is marked [permanant] in lsmod (have to reboot to get rid of
> it).  That way, I can avoid the seek errors in the initrd.  Another
> way to avoid them is the kernel command line parameter hde=noprobe,
> however, dmraid will not work after that because /sys/block/hde is not
> created.

Well, you can also just ignore the errors.  They don't mean anything
anyway in this scenario.  It's absolutely bogus.

>   I agree with you that it would be nice if the kernel initialization
> of the hard disk driver caused only the creation of /sys/block/hde,
> and didn't mention anything about partitions.  However, that does not
> generate an annoying repetative error like a normal partition scan
> would.

We read the partition, and we get errors because the partition doesn't
exist.  The kernel shouldn't be creating partition devices that don't
make any sense.

>   Why would the internal nash mount command be scanning if not using a
> volume label or when using a filesystem type of proc or ext3?

Just like /bin/mount, nash's mount uses libblkid for identifying
devices.  The first time you do any mount, it unconditionally populates
the cache of what filesystems are available, including their UUIDs and
labels.

We could make it not do it if you specify device name, although I'm not
really sure that's correct either, and I'd probably rewriting that code
later this month anyway to try specific drives first based on hardware
UUIDs.  So fixing this should fall out of that.

-- 
  Peter