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 _______________________________________________ Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
