# /: Not a XFS mount point. Why?

## Perfect Gentleman

I have root on M.2 SSD with XFS. Everything works except

```
~ $ sudo xfs_info /dev/sdd1

/: cannot find mount point.
```

```
 ~ $ sudo xfs_scrub /

EXPERIMENTAL xfs_scrub program in use! Use at your own risk!

/: Not a XFS mount point.
```

but

```
~ $ mount | grep -i sdd1

/dev/sdd1 on / type xfs (rw,noatime,attr2,inode64,noquota)

```

```
 ~ $ grep -i root /etc/mtab 

/dev/root / xfs rw,noatime,attr2,inode64,noquota 0 0

```

```
 ~ $ cat /etc/fstab

PARTUUID=d6740b16-a968-42f4-a774-2412c35a96aa           /                       xfs     rw,noatime,attr2,inode64,allocsize=1048576k,logbsize=256k,noquota                                       0 0
```

My config - http://dpaste.com/017VSMCLast edited by Perfect Gentleman on Thu Jul 04, 2019 1:38 pm; edited 2 times in total

----------

## mike155

What happens if you run the failing commands without sudo (directly as root)?

----------

## Perfect Gentleman

the same.

```
 ~ $ sudo xfs_info /dev/sda1

meta-data=/dev/sda1              isize=512    agcount=32, agsize=7325939 blks

         =                       sectsz=512   attr=2, projid32bit=1

         =                       crc=1        finobt=1, sparse=1, rmapbt=0

         =                       reflink=0

data     =                       bsize=1024   blocks=234430023, imaxpct=25

         =                       sunit=0      swidth=0 blks

naming   =version 2              bsize=4096   ascii-ci=0, ftype=1

log      =internal log           bsize=1024   blocks=131072, version=2

         =                       sectsz=512   sunit=0 blks, lazy-count=1

realtime =none                   extsz=4096   blocks=0, rtextents=0

 ~ $ sudo xfs_info /dev/sdd1

/: cannot find mount point.
```

sda is SATA-SSD.

----------

## Perfect Gentleman

anyone? help.

----------

## mike155

What happens if you specify the mount-point instead of the block-device?

```
xfs_info /
```

 *man xfs_info wrote:*   

> 
> 
> ```
> xfs_info [ -t mtab ] [ mount-point | block-device | file-image ]
> ```
> ...

 

----------

## Perfect Gentleman

```
~ $ sudo xfs_info /

/: cannot find mount point.
```

----------

## Jaglover

Probably an XFS bug, despite being a mature filesystem it may have difficulties with SSD. I had some issue in past with XFS being directly on HDD, without partitioning. Don't remember what it was, something minor, but still a failure.

In any case, there are better filesystems for flash storage, I use F2FS for root filesystem myself.

----------

## Perfect Gentleman

I used F2FS before that, but it became corrupted after power outage.

The problem is that it is okay with non-root SATA-SSD, and it is okay from live-usb Fredora. But it is not okay from my system.

----------

## Jaglover

XFS gets corrupted, too. Higher the performance of filesystem more likely the corruption in case of power loss. It depends on how much data is buffered and not written to the drive when power goes off. This is why UPS was invented.

----------

## Perfect Gentleman

I've never had problems with XFS v5. Next kernel upgrade I'll try to define 'rootfstype' and 'rootflags' in bootparams and check it out again.

----------

## Jaglover

 *Perfect Gentleman wrote:*   

> I've never had problems with XFS v5. Next kernel upgrade I'll try to define 'rootfstype' and 'rootflags' in bootparams and check it out again.

 

This is nonsense argument. Some drive drunk every day and won't get caught. Probably have version 5 alcohol in their blood?

----------

## Perfect Gentleman

okay.

I used F2FS twice. Every time it died eventually after power outage. I use XFS third time and it is always okay.

Anyway it's not what this topic was created for.

I want to know what it is wrong with my system or maybe it is a bug in XFS or xfsprogs.

----------

## axl

You said that particular partition is your rootfs. Is it also the boot partition that contains grub?

If the answer is yes, then most likely that partition was made with -mcrc=0, which turns off the scrubbing. And as far as I know and remember, if crc=1, then it can't be used for grub, because grub doesn't understand partitions with crc=1 (yet).

Still, it is weird that xfs_info doesn't work on it. That should have worked regardless of crc=1 or 0.

----------

## mike155

 *Quote:*   

> I want to know what it is wrong with my system or maybe it is a bug in XFS or xfsprogs.

 

Run

```
cat /usr/sbin/xfs_info
```

It's a short shell script! It calls other programs like "findmnt" from util-linux. It's likely that your machine and xfs_info are fine, but that the output of one of the called programs has changed. 

Run the xfs_info in debug mode and/or run the called programs manually (with the arguments used in the script). Compare the output for /dev/sda1 and /dev/sdd1. It should be possible to find the culprit  :Smile: 

----------

## Perfect Gentleman

 *Quote:*   

> Is it also the boot partition that contains grub?

 

No, I use EFISTUB.

```
sdd                                                                            

└─sdd1 xfs    PX-G256M6e   681c1a22-4084-41c7-9c09-42a978436e34  202.8G    15% /

sde                                                                            

└─sde1 vfat                EC01-5458                               7.4G     0% /boot
```

```
 ~ $ cat /usr/sbin/xfs_info

#!/bin/sh -f

# SPDX-License-Identifier: GPL-2.0

#

# Copyright (c) 2000-2001 Silicon Graphics, Inc.  All Rights Reserved.

#

OPTS=""

USAGE="Usage: xfs_info [-V] [-t mtab] [mountpoint|device|file]"

# Try to find a loop device associated with a file.  We only want to return

# one loopdev (multiple loop devices can attach to a single file) so we grab

# the last line and return it if it's actually a block device.

try_find_loop_dev_for_file() {

        local x="$(losetup -O NAME -j "$1" 2> /dev/null | tail -n 1)"

        test -b "$x" && echo "$x"

}

while getopts "t:V" c

do

        case $c in

        t)      OPTS="-t $OPTARG" ;;

        V)      xfs_spaceman -p xfs_info -V

                status=$?

                exit $status

                ;;

        *)      echo $USAGE 1>&2

                exit 2

                ;;

        esac

done

set -- extra "$@"

shift $OPTIND

case $# in

        1)

                arg="$1"

                # See if we can map the arg to a loop device

                loopdev="$(try_find_loop_dev_for_file "${arg}")"

                test -n "${loopdev}" && arg="${loopdev}"

                # If we find a mountpoint for the device, do a live query;

                # otherwise try reading the fs with xfs_db.

                if mountpt="$(findmnt -f -n -o TARGET "${arg}" 2> /dev/null)"; then

                        xfs_spaceman -p xfs_info -c "info" $OPTS "${mountpt}"

                        status=$?

                else

                        xfs_db -p xfs_info -c "info" $OPTS "${arg}"

                        status=$?

                fi

                ;;

        *)      echo $USAGE 1>&2

                exit 2

                ;;

esac

exit $status

```

```
~ $ findmnt 

TARGET                       SOURCE      FSTYPE     OPTIONS

/                            /dev/sdd1   xfs        rw,noatime,attr2,inode64,noquota

```

----------

## Perfect Gentleman

```
~ $ findmnt -f -n -o TARGET /dev/sdd1

/

```

```
~ $ findmnt -f -n -o TARGET /dev/sda1

/home/MZ7WD240HAFV
```

It seems 'findmnt' works fine.

----------

## mike155

 *Quote:*   

> It seems 'findmnt' works fine.

 

I agree!  :Smile: 

Please post the output of

```
bash -x /usr/sbin/xfs_info /dev/sda1
```

 and of 

```
bash -x /usr/sbin/xfs_info /dev/sdd1
```

It will tell us how the "real" program (xfs_db or xfs_spaceman) is called

----------

## Perfect Gentleman

```
 ~ $ bash -x /usr/sbin/xfs_info /dev/sda1

+ OPTS=

+ USAGE='Usage: xfs_info [-V] [-t mtab] [mountpoint|device|file]'

+ getopts t:V c

+ set -- extra /dev/sda1

+ shift 1

+ case $# in

+ arg=/dev/sda1

++ try_find_loop_dev_for_file /dev/sda1

+++ losetup -O NAME -j /dev/sda1

+++ tail -n 1

++ local x=

++ test -b ''

+ loopdev=

+ test -n ''

++ findmnt -f -n -o TARGET /dev/sda1

+ mountpt=/home/MZ7WD240HAFV

+ xfs_spaceman -p xfs_info -c info /home/MZ7WD240HAFV

meta-data=/dev/sda1              isize=512    agcount=32, agsize=7325939 blks

         =                       sectsz=512   attr=2, projid32bit=1

         =                       crc=1        finobt=1, sparse=1, rmapbt=0

         =                       reflink=0

data     =                       bsize=1024   blocks=234430023, imaxpct=25

         =                       sunit=0      swidth=0 blks

naming   =version 2              bsize=4096   ascii-ci=0, ftype=1

log      =internal log           bsize=1024   blocks=131072, version=2

         =                       sectsz=512   sunit=0 blks, lazy-count=1

realtime =none                   extsz=4096   blocks=0, rtextents=0

+ status=0

+ exit 0

```

```
 ~ $ bash -x /usr/sbin/xfs_info /dev/sdd1

+ OPTS=

+ USAGE='Usage: xfs_info [-V] [-t mtab] [mountpoint|device|file]'

+ getopts t:V c

+ set -- extra /dev/sdd1

+ shift 1

+ case $# in

+ arg=/dev/sdd1

++ try_find_loop_dev_for_file /dev/sdd1

+++ losetup -O NAME -j /dev/sdd1

+++ tail -n 1

++ local x=

++ test -b ''

+ loopdev=

+ test -n ''

++ findmnt -f -n -o TARGET /dev/sdd1

+ mountpt=/

+ xfs_spaceman -p xfs_info -c info /

/: cannot find mount point.+ status=1

+ exit 1

```

----------

## axl

I noticed you have partuuid in fstab. I hope you have device-mapper and whatever required for every system part to read that, but let's just assume that is wrong and test how would things work if you had /dev/sdd1 in fstab instead of partuuid. I have no other idea, based on what I seed. Maybe the output from blkid to check the partuuid.

----------

## axl

and I think i'm right. according to your post to me about efistubs, your partuuid should be 681c1a22-4084-41c7-9c09-42a978436e34, but according to another post (the fstab one), it should be d6740b16-a968-42f4-a774-2412c35a96aa. 

let me refrase that. according to your post to me, the correct partuuid is 681c1a22-4084-41c7-9c09-42a978436e34, but instead in fstab it is (wrong) d6740b16-a968-42f4-a774-2412c35a96aa. 

Am 99% sure this is correct. let us know how it goes.

----------

## axl

I'm guessing, you tar-ed the old gentoo when you bought the ssd, and didn't change in fstab the new partuuid after you un-tar-ed the old distro onto the new drive. 

You mentioned an M2. I'm guessing that's new. And every other little piece falls into place.  :Smile: 

----------

## Perfect Gentleman

PARTUUID is right.

```
/dev/sdd1: LABEL="PX-G256M6e" UUID="681c1a22-4084-41c7-9c09-42a978436e34" TYPE="xfs" PARTLABEL="PX-G256M6e" PARTUUID="d6740b16-a968-42f4-a774-2412c35a96aa"
```

----------

## Perfect Gentleman

 *axl wrote:*   

> I'm guessing, you tar-ed the old gentoo when you bought the ssd, and didn't change in fstab the new partuuid after you un-tar-ed the old distro onto the new drive. 

 

No, it's new install, rather fresh, end of April.

----------

## axl

 *Perfect Gentleman wrote:*   

> PARTUUID is right.
> 
> ```
> /dev/sdd1: LABEL="PX-G256M6e" UUID="681c1a22-4084-41c7-9c09-42a978436e34" TYPE="xfs" PARTLABEL="PX-G256M6e" PARTUUID="d6740b16-a968-42f4-a774-2412c35a96aa"
> ```
> ...

 

No it's not. PARTUUID != UUID. if fstab says PARTUUID... then use that, not the UUID. Its' right there.

----------

## Perfect Gentleman

I don't get it. I know that PARTUUID != UUID. And I use PARTUUID for root device.

```
PARTUUID=d6740b16-a968-42f4-a774-2412c35a96aa           /                       xfs     rw,noatime,attr2,inode64,allocsize=1048576k,logbsize=256k,noquota                                       0 0
```

Or you want me to use UUID instead of PARTUUID, don't you?

----------

## axl

 *Perfect Gentleman wrote:*   

> 
> 
> ```
> sdd                                                                            
> 
> ...

 

I got confused by this. But why not try /dev/sdd1 instead of partuuid. which was my initial suggestion.

----------

## mike155

Thanks for the "bash -x" output. So the "real" program calls are:

```
xfs_spaceman -p xfs_info -c info /home/MZ7WD240HAFV

xfs_spaceman -p xfs_info -c info /
```

I looked at the strace log of xfs_spaceman on my machine. The program reads '/proc/self/mounts'. Please post the ouput of:

```
cat /proc/self/mounts | egrep -v "^(cgroup|cgroup2|tmpfs|devpts|pstore|sysfs|proc|mqueue|debugfs|bpf|devtmpfs|fusectl) " | grep -v nfs
```

----------

## Perfect Gentleman

 *axl wrote:*   

>  *Perfect Gentleman wrote:*   
> 
> ```
> sdd                                                                            
> 
> ...

 

It's output of 'lsblk -f'. I'll try /dev/sdd1.

```
~ $ cat /proc/self/mounts | egrep -v "^(cgroup|cgroup2|tmpfs|devpts|pstore|sysfs|proc|mqueue|debugfs|bpf|devtmpfs|fusectl) " | grep -v nfs

/dev/root / xfs rw,noatime,attr2,inode64,noquota 0 0

shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0

cgroup_root /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755 0 0

openrc /sys/fs/cgroup/openrc cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/rc/sh/cgroup-release-agent.sh,name=openrc 0 0

none /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0

/dev/sde1 /boot vfat rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,utf8,errors=remount-ro 0 0

/dev/sda1 /home/MZ7WD240HAFV xfs rw,noatime,attr2,inode64,allocsize=1048576k,logbsize=256k,noquota 0 0

```

----------

## Perfect Gentleman

/dev/sdd1 didn't help.

----------

## mike155

Which version of sys-fs/xfsprogs is installed on your machine?

I started to look at the source code - and I want to make sure that I look at the right version...

----------

## axl

I had a long day. do not listen to me. i'm too tired to give out advice, but the next thing I would look at is initramfs file. none of my systems have /dev/root. i checked. maybe that's the problem. again, don't listen to me, i've run out of ideas. 

what is /etc/mtab? should be a link to /proc/self/mounts

what is /dev/root? I _GUESS_ it should be a link to /dev/sdd1. 

but how do you get /dev/root ?! has to be some kernel or genkernel thing. I don't have it.

----------

## Perfect Gentleman

 *mike155 wrote:*   

> Which version of sys-fs/xfsprogs is installed on your machine?

 

5.1.0-rc0. I tried 5.0.0 and 4.20.; it's all the same.

 *Quote:*   

> but how do you get /dev/root ?!

 

```
CONFIG_CMDLINE_BOOL=y

CONFIG_CMDLINE="root=/dev/sdd1 rw rootfstype=xfs rootflags=attr2,inode64,allocsize=1048576k,logbsize=256k,noquota nfs.nfs4_disable_idmapping=0 nfsd.nfs4_disable_idmapping=0 libata.force=3:3.0G"
```

I think it's bug when EFISTUB is used, because I have Microserver with grub; xfs on /root which is also is /boot. Everything is okay.

----------

## frostschutz

does it work if you bind it elsewhere?

```

mkdir /mnt/root

mount --bind / /mnt/root

xfs_info /mnt/root

```

----------

## Perfect Gentleman

```
 ~ $ sudo mkdir /mnt/root

 ~ $ sudo mount --bind / /mnt/root

 ~ $ xfs_info /mnt/root

/mnt/root: cannot find mount point.
```

----------

## frostschutz

OK, I can reproduce your issue now.

1. create a LV with XFS filesystem

2. find out which dm-XXX name that LV is ( ls -l /dev/VG/LV )

```

# ls -l /dev/SSD/root

lrwxrwxrwx 1 root root 8 Jul 14 08:07 /dev/SSD/test -> ../dm-76

# ls -l /dev/dm-76

brw-rw---- 1 root disk 253, 76 Jul 14 08:07 /dev/dm-76

```

3. give the device an odd, non-standard name instead

```

# cp -a /dev/dm-76 /dev/foobarbaz

```

4. mount it using the nonstandard name

```

# mount /dev/foobarbaz /mnt/foobarbaz

```

5. verify it shows up as non-standard name in /proc/mounts

```

# grep foobar /proc/mounts

/dev/foobarbaz /mnt/foobarbaz xfs ro,relatime,attr2,inode64,noquota 0 0

```

6. test xfs_info with the device existing vs. not existing vs. existing as a symlink only

```

# xfs_info /mnt/foobarbaz

meta-data=/dev/foobarbaz

[...]

# rm /dev/foobarbaz

# xfs_info /mnt/foobarbaz

/mnt/foobarbaz: cannot find mount point.

# ln -s /dev/dm-76 /dev/foobarbaz

# xfs_info /mnt/foobarbaz

meta-data=/dev/foobarbaz

[...]

```

So that makes me think you have an initramfs, or a static /dev on your rootfs, where /dev/root actually exists, points to some other device, and gets mounted with that device name as a reference in /proc/mounts.

Then you boot, udev replaces initramfs and static /dev, and that strange device name no longer exists and hence, xfs_info which trusts the device names given by /proc/mounts fails to locate the correct device.

You can restore functionality by symlinking the missing device node (make sure it's the correct device and not something else).

And you can avoid the issue by getting rid of the non-standard device name where ever it might hide itself in your installation. You have to find out where it is (if you don't use initramfs,  check out /mnt/root/dev after the bind-mount. otherwise check out the initramfs /dev.). Stick to the standard /dev names for everything. Aliases are great but bad if they stop existing later on in the boot process.

Good luck.

----------

## Perfect Gentleman

 *Quote:*   

> OK, I can reproduce your issue now. 

 

Thanx for helping.

 *Quote:*   

> So that makes me think you have an initramfs,

 

I don't have it.

```
 ~ $ ls /boot/

config-5.2.0-gentoo  System.map-5.2.0-gentoo  vmlinuz-5.2.0-gentoo

```

```
~ $ grep -i initr /boot/config-5.2.0-gentoo 

# CONFIG_BLK_DEV_INITRD is not set
```

 *Quote:*   

>  or a static /dev on your rootfs, where /dev/root actually exists

 

```
~ $ ls /dev/root

ls: cannot access '/dev/root': No such file or directory
```

 *Quote:*   

> And you can avoid the issue by getting rid of the non-standard device name where ever it might hide itself in your installation. You have to find out where it is (if you don't use initramfs, check out /mnt/root/dev after the bind-mount. otherwise check out the initramfs /dev.). Stick to the standard /dev names for everything. Aliases are great but bad if they stop existing later on in the boot process.
> 
> 

 

What do you mean by that? I didn't choose non-standard device names. How can I prove it?

----------

## axl

I found a system where I could reproduce. It has the /dev/root as root. 

well, a simple hack would be to just do a link. 

I think in your case was:

ln -s /dev/sdd1 /dev/root

then xfs_info will start working. 

I'm still confused how /dev/root appeared in the first place, but i'm ready to let that go.

----------

## Perfect Gentleman

@axl, thanx. That hack works.

But I don't get why my system has no /dev/root.

----------

## axl

 *Perfect Gentleman wrote:*   

> @axl, thanx. That hack works.
> 
> But I don't get why my system has no /dev/root.

 

Well, assuming it is an openrc setup, you can set "rc_dev_root_symlink="YES"" in /etc/conf.d/udev-trigger and it will be created. Don't know about systemd. 

But I think I figured it out. So, as it turns out, on the one system where /dev/root issue showed up, is a systemd enabled, no initramfs, kernel directly mounts /root at boot. and what happens is: kernel does the mount for / when /dev wasn't mounted yet. Therefor the first entry in /proc/self/mounts is an entry for /dev/root. Then again, nothing in systemd takes care to create that link. So header of /proc/self/mounts looks something like this (root first):

```
/dev/root / xfs rw,noatime,nodiratime,attr2,inode64,noquota 0 0

devtmpfs /dev devtmpfs rw,relatime,size=12304776k,nr_inodes=3076194,mode=755 0 0

sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0

proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0

tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0

```

On other systems that do have an initramfs file, the init inside the initramfs does take care to mount /proc /dev first, and the rootfs is mounted by the init, AFTER /dev was mounted, and therefor when root is mounted is mounted with it's real device name instead of the generic /dev/root. so header of /proc/self/mounts looks something like this (dev first):

```
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0

udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=3856804,mode=755 0 0

devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0

sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0

/dev/nvme0n1 / xfs rw,noatime,nodiratime,attr2,inode64,noquota 0 0
```

so. to solve this, you could use an initramfs file. or googling 61-dev-root-link.rules you could add an udev rule to create /dev/root.

----------

## Perfect Gentleman

 *Quote:*   

> Well, assuming it is an openrc setup, you can set "rc_dev_root_symlink="YES"" in /etc/conf.d/udev-trigger and it will be created. 

 

Thanx, that helped.

----------

## frostschutz

 *Perfect Gentleman wrote:*   

> 
> 
>  *Quote:*    or a static /dev on your rootfs, where /dev/root actually exists 
> 
> ```
> ...

 

normally that'd check the udev /dev not the rootfs /dev

```

mkdir /mnt/root

mount --bind / /mnt/root

ls -l /mnt/root/dev/{,root}

```

----------

