(resolved) Re: blkid gets it info from where?

[whollygoat@letterboxes.org]

For the sake of anyone who may have been looking for an
answer to this besides myself, I'd like to report two things

1) removing and recreating /etc/blkid.tab and /etc/blkid.tab.old
   seems to have fixed things.  The boot process is not
   interrupted by fsck errors;

2) while researching something unrelated to this problem, I 
   came across something that leads me to believe that the 
   reason there are incorrect associations between an ext2
   file system label and two raid drives is the design of the ext
   file system.  If I understood the article correctly, ext2
   somehow associates a label with any devices the filesystem
   is connected to.  My guess would be that the LVM partition
   containing the ext3 fs is located on raid stripes on the 
   drives that show up in blkid.tab.

I could be wrong in point two, but things are back to working,
so I guess it doesn't really matter.

On Wed, 14 Jan 2009 19:36:28 -0800, whollygoat@letterboxes.org said:
> I've a file server that is dropping to a maintenance prompt 
> at boot because fsck.ext3 is unable to check a device.  But, 
> it shouldn't be looking at that device anyway.  
> 
> ----------- begin log excerpt -----------
> Checking file systems ....fsck 1.40-WIP (14-Nov-2006)
> fsck.ext3: Device or resource busy while trying to open /dev/hdk1
> Filesystem mounted or opened exclusively by another program?
> ----------- end log excerpt -----------
> 
> hdk1, along with hde1, hdg1, hdi1, hdm1 and hdo1
> are component devices in a raid5 array (hdo1 is a spare) partition
> type da (non-fs data).  
> 
> I tried:
> 
>   $ ls -lFR /dev/disk | grep hdk
> 
> which turned up a symbolic link under /dev/disk/by-label named 
> XprtHome pointing to hdk1.  That should not be there.  The label
> is a valid ext3 partition label, but it was given to an LVM
> logical volume on top of the raid5 array that hdk1 is part of.
> 
> I noticed that the time stamp of the link was boot time, so I've 
> tried to find what puts it there:
> 
>   for i in /boot /etc /lib /usr /initrd
>   do
>     grep -R XprtHome $i
>   done
> 
> whick led me to /etc/blkid.tab.  There are 3 entries there
> sporting the ext3 label XprtHome.  One is correct referencing
> the logical volume holding the e3 partition, one is the hdk one
> and another is for hdm1, another raid component device.
> 
> blkid.tab also has a boot time timestamp, so I guess it must be
> getting its information from somewhere else, but I can't figure 
> out where.
> 
>   blkid -c /dev/null 
> 
> gave the same crap.  
> 
> Tried renaming blkid.tab and blkid.tab.old by tagging "_DISABLED" 
> to the end and rerunning blkid, but that returned the same false 
> entries.  Even tried rebooting with only the disabled version of 
> the files.  Two new files were created with the same bad entries, 
> though fsck.ext3 did not interrupt the boot process.
> 
> It's funny, given that blkid.tab shows entries for both hdk1 and hdm1 
> that only hdk1 is listed under /dev/disk/by-label.
> 
> I've looked in /etc/udev, but nothing there seems obvious (in fact, it 
> all seems rather obscure:)
> 
> bug #463787 looks like it might be related, but I didn't understand
> much of the nitty gritty.  (I'm using e2fsprogs
> 1.39+1.40-WIP-2006.11.14+dfsg-2etch1
> which is the most recent for etch)
> 
> Any suggestions?
> 
> wg
-- 
  
  whollygoat@letterboxes.org

-- 
http://www.fastmail.fm - A fast, anti-spam email service.