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

blkid gets it info from where?



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 - The professional email service


Reply to: