xfs /home cannot be mounted on boot

[AleksanderAdamowski]

Binary package hint: initscripts

I had a Feisty installation with /home on an xfs filesystem.

Today I've changed the APT repositories to Gutsy, and dist-upgraded.

After rebooting, I've discovered that /home is not mounted and I cannot mount it because lots of processes (including init) are using the /home directory so the mount point is busy.

I've removed the "quiet" and "splash" options from /boot/grub/menu.lst and rebooted to see what was going on during bootup. When the /home filesystem is about to be mounted, I can see the following messages:

 * Mounting local filesystems....
mount: /dev/hda6 already mounted or /home busy

Earlier on the console, the XFS filesystems passes through filesystem checking successfully:

 * Checking file systems...
fsck 1.40.2 (12-Jul-2007)
/sbin/fsck.xfs: XFS file system.
Replaying journal..
Reiserfs journal ...etc.etc (I have a reisefs partition over there, too).
...
Filesystem is clean.
...

[Stephen Irons (stephen-irons)]

I have /home on a clean ext3 partition with the same problem (changed /etc/apt/source.list to Gutsy, did a dist-upgrade and now /home does not mount).

I can delete /home so it does not seem to be locked at that level.

I can create a new partition, but cannot mount /dev/sda4 there either: it gives the same error
   * sudo mkdir /newhome
   * sudo mount -t ext3 /dev/sda4 /newhome

   * mount: /dev/sda4 already mounted or /newhome busy

[AleksanderAdamowski (aadamowski)]

Actually I was wrong with the usage - I was testing whether /home is in use with "fuser -m /home". I've added the "-m" argument out of habit. Actually, /home seems to be unused - plain "fuser /home" shows no accessing processes. So the cause seems to be different.

The symptoms are:

# fuser /home
# mount /dev/hda6 /home/
mount: /dev/hda6 already mounted or /home/ busy
# mount -v -t xfs /dev/hda6 /home/
mount: /dev/hda6 already mounted or /home/ busy
# hexdump -C /dev/hda6 | head
00000000 58 46 53 42 00 00 10 00 00 00 00 00 01 96 52 e0 |XFSB..........R.|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 c9 e3 cb ee 47 e0 11 d7 9f 33 ed 99 1e fa c2 d0 |....G....3......|
00000030 00 00 00 00 00 d0 00 04 00 00 00 00 00 00 00 80 |................|
00000040 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 |................|
00000050 00 00 00 10 00 10 00 00 00 00 00 1a 00 00 00 00 |................|
00000060 00 00 0c b2 20 94 02 00 01 00 00 10 00 00 00 00 |.... ...........|
00000070 00 00 00 00 00 00 00 00 0c 09 08 04 14 00 00 19 |................|
00000080 00 00 00 00 00 05 c7 80 00 00 00 00 00 01 de a2 |................|
00000090 00 00 00 00 00 32 0f 26 00 00 00 00 00 00 00 00 |.....2.&........|

A sidenote to Stephen: On POSIX systems (including Linux) you actually _can_ delete files and directories that are in use, since they are identified by their inode numbers.

So if your /home directory is used by some processes, you can still rmdir or "rm -rf" it and it will disappear. You can mkdir a new /home, and it will be a different one, and the processess holding the old one will still see the old one. Its space will be reclaimed in the filesystem when the last process to use it will close its handle. You can test a filesystem object's usage using the "fuser" command.

But to be used as a mount point, a directory cannot be in use.

[jetthe (jonas-dalom)]

I'm experiencing the same thing.
/ on sda1, /home (ext3) on sda7 (which resides on the extended partition sda2)

My fstab is in order, I've tried using both UUID and device.

The only thing I can find in /var/log that relates to this is (probably):

[ 43.436407] Adding 4554388k swap on /dev/sda5. Priority:-1 extents:1 across:4554388k
[ 43.725791] EXT3 FS on sda1, internal journal
[ 44.402622] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
[ 44.402631] device-mapper: ioctl: error adding target to table
(the last two rows repeats ~20 times)

[Stephen Irons (stephen-irons)]

I get this error if I use kernel 2.6.22-14-generic and -386.

The problem goes away if I reboot with 2.6.20-16-generic and -386 from Feisty, or 2.6.20-16-realtime.

[AleksanderAdamowski (aadamowski)]

I can see those errors in kern.log too:

Oct 17 15:25:18 tuxia kernel: [ 32.064000] EXT3 FS on hda1, internal journal
Oct 17 15:25:18 tuxia kernel: [ 33.036000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.036000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.040000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.040000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.040000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.040000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.044000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.044000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.044000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.048000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.288000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.288000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.368000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.368000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.376000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.376000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.380000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.380000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.380000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.380000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.384000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.384000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.384000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.384000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.388000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.388000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.388000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kernel: [ 33.388000] device-mapper: ioctl: error adding target to table
Oct 17 15:25:18 tuxia kernel: [ 33.392000] device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
Oct 17 15:25:18 tuxia kern...

[Scott James Remnant (Canonical) (canonical-scott)]

apt-get remove evms

[goto (gotolaunchpad)]

4YI I got the mounting working by using:

mount -t xfs /dev/mapper/1ATA-*snip*p1 /mnt

HAND

[Roberto Maurizzi (r-maurizzi)]

This bug is *NOT* a duplicate of bug #115616

The fact that the reporter sees evms errors in /var/log/messages does NOT mean he can mount XFS volumes by removing it.

I confirm that:

- I don't have EVMS installed
- I can not mount any xfs volume either by "old device" (dev/sdax) or UUID. I only get the "already mounted or busy" error
- I can mount the partitions using /dev/mapper/sdax

So basically, I'd say we're without "standard" XFS support with gutsy

[Roberto Maurizzi (r-maurizzi)]

I found out I was wrong: maybe I have too many computers... I did remove EVMS, but from the wrong computer :-P

I *confirm* that you cannot mount some additional partitions (I'd say regardless of which filesystem they use, not only XFS) if you have evms installed and active.

So, to be able to mount those partition again by device or by UUID or label, you can simply remove EVMS (that is, simply if you don't use it). If you can't, use the /dev/mapper/ devices managed by EVMS. This has to do with bug #115616 (that explain that new device locking policies blocks concurrent access to a device from EVMS and other processes) but I think in this bug this relation wasn't explained very well.

I hope this clarification will be helpful for someone, sorry for the mistake!

Ciao,
RobM