XFS doesn't auto mount on boot when /etc/fstab entry has fs type set to auto

XFS doesn't auto mount on boot when /etc/fstab entry has fs type set to auto

[Vaibhaw Pandey]

Hi,

Needed guidance.

I am trying to move my EC2 machine deployment code to start creating
XFS volumes as opposed to ext4 volumes like it used to. An issue I
have run into is that the XFS volume doesn't get mounted automatically
on reboot with the /etc/fstab entry which used to work fine for ext4.
A manual mount later works perfectly.

Version:
$ uname -a
Linux ip-172-31-39-239 4.4.44-39.55.amzn1.x86_64 #1 SMP Mon Jan 30
18:15:53 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
sudo cat /etc/fstab
#
LABEL=/     /           ext4    defaults,noatime  1   1
tmpfs       /dev/shm    tmpfs   defaults        0   0
devpts      /dev/pts    devpts  gid=5,mode=620  0   0
sysfs       /sys        sysfs   defaults        0   0
proc        /proc       proc    defaults        0   0
/dev/sdb /redis_data auto noatime,noexec,nodiratime 0 0
$ df -T /redis_data/
Filesystem     Type 1K-blocks  Used Available Use% Mounted on
/dev/xvdb      xfs    5232640 32940   5199700   1% /redis_data

However if I change the /etc/fstab directive to:

/dev/sdb /redis_data xfs noatime,noexec,nodiratime 0 0

the auto mount starts working fine. Now this isn't a major problem
since the functionality ultimately works. But I would certainly like
to have the flexibility to avoid hard coding the fs type in the code
that generates these fstab entries.

Any pointers or help is much appreciated. :)

Thanks,
Vaibhaw

Re: XFS doesn't auto mount on boot when /etc/fstab entry has fs type set to auto

[Carlos Maiolino]

Hi,

> LABEL=/     /           ext4    defaults,noatime  1   1
> tmpfs       /dev/shm    tmpfs   defaults        0   0
> devpts      /dev/pts    devpts  gid=5,mode=620  0   0
> sysfs       /sys        sysfs   defaults        0   0
> proc        /proc       proc    defaults        0   0
> /dev/sdb /redis_data auto noatime,noexec,nodiratime 0 0
> $ df -T /redis_data/
> Filesystem     Type 1K-blocks  Used Available Use% Mounted on
> /dev/xvdb      xfs    5232640 32940   5199700   1% /redis_data
> 
> However if I change the /etc/fstab directive to:
> 
> /dev/sdb /redis_data xfs noatime,noexec,nodiratime 0 0
> 
> the auto mount starts working fine. Now this isn't a major problem
> since the functionality ultimately works. But I would certainly like
> to have the flexibility to avoid hard coding the fs type in the code
> that generates these fstab entries.
> 

I believe this is not a question for us, but for whatever software you are using
to mount your partitions, systemd, unit, init, whatever. It also might be a
problem with `mount` command, but if you say you can mount it normally after the
system is live, it looks not to be the case.

XFS doesn't control who and how it reads the entries in fstab.

As stated in `mount` manpage:

"If no -t option is given, or if the auto type is specified, mount will try  to
guess  the  desired  type.   Mount  uses  the  blkid  library for guessing the
filesystem type; if that does not turn up anything that looks familiar,  mount
will  try  to  read  the  file  /etc/filesystems,  or, if that
does not exist, /proc/filesystems.  All of the filesystem types listed there 
will be  tried, except  for  those  that  are labeled "nodev" (e.g. devpts, proc
and nfs). If /etc/filesystems  ends  in  a  line  with  a  single  *,   mount
will   read /proc/filesystems  afterwards.   While  trying,  all  filesystem
types will be mounted with the mount option silent."


Anyway, if you have the logs from your system when it tries to mount the
partition maybe it give us some clue of what is happening.

Cheers
 
> Any pointers or help is much appreciated. :)
> 
> Thanks,
> Vaibhaw
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos

Re: XFS doesn't auto mount on boot when /etc/fstab entry has fs type set to auto

[Vaibhaw Pandey]

Carlos,

Thanks a lot for replying. :)

I should have read the mount man page more carefully: By adding "xfs"
to /etc/filesystems, the /etc/fstab entry even with an auto started
working fine.

blkid always had an entry for the volume in question but that didn't
make a difference in this case:
$ sudo blkid
/dev/xvda1: LABEL="/" UUID="ebbf1f1c-fb71-40aa-93a3-056b455e5127" TYPE="ext4"
/dev/xvdb: UUID="bf4be26c-1c1c-40fc-b5cf-b9048dcc61b6" TYPE="xfs"


> Anyway, if you have the logs from your system when it tries to mount the
> partition maybe it give us some clue of what is happening.

It was the complete lack of logs in dmesg or /var/log/messages about a
failure to mount is what confused me on why this was failing. A
successful mount logs but an unsuccessful one doesn't. I think I will
ask a mount expert for help on this.

Thanks again,
Vaibhaw

On Wed, Feb 15, 2017 at 5:57 PM, Carlos Maiolino <cmaiolino@redhat.com> wrote:
> Hi,
>
>> LABEL=/     /           ext4    defaults,noatime  1   1
>> tmpfs       /dev/shm    tmpfs   defaults        0   0
>> devpts      /dev/pts    devpts  gid=5,mode=620  0   0
>> sysfs       /sys        sysfs   defaults        0   0
>> proc        /proc       proc    defaults        0   0
>> /dev/sdb /redis_data auto noatime,noexec,nodiratime 0 0
>> $ df -T /redis_data/
>> Filesystem     Type 1K-blocks  Used Available Use% Mounted on
>> /dev/xvdb      xfs    5232640 32940   5199700   1% /redis_data
>>
>> However if I change the /etc/fstab directive to:
>>
>> /dev/sdb /redis_data xfs noatime,noexec,nodiratime 0 0
>>
>> the auto mount starts working fine. Now this isn't a major problem
>> since the functionality ultimately works. But I would certainly like
>> to have the flexibility to avoid hard coding the fs type in the code
>> that generates these fstab entries.
>>
>
> I believe this is not a question for us, but for whatever software you are using
> to mount your partitions, systemd, unit, init, whatever. It also might be a
> problem with `mount` command, but if you say you can mount it normally after the
> system is live, it looks not to be the case.
>
> XFS doesn't control who and how it reads the entries in fstab.
>
> As stated in `mount` manpage:
>
> "If no -t option is given, or if the auto type is specified, mount will try  to
> guess  the  desired  type.   Mount  uses  the  blkid  library for guessing the
> filesystem type; if that does not turn up anything that looks familiar,  mount
> will  try  to  read  the  file  /etc/filesystems,  or, if that
> does not exist, /proc/filesystems.  All of the filesystem types listed there
> will be  tried, except  for  those  that  are labeled "nodev" (e.g. devpts, proc
> and nfs). If /etc/filesystems  ends  in  a  line  with  a  single  *,   mount
> will   read /proc/filesystems  afterwards.   While  trying,  all  filesystem
> types will be mounted with the mount option silent."
>
>
> Anyway, if you have the logs from your system when it tries to mount the
> partition maybe it give us some clue of what is happening.
>
> Cheers
>
>> Any pointers or help is much appreciated. :)
>>
>> Thanks,
>> Vaibhaw
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Carlos



-- 
Member of Technical Staff | ScaleGrid.io | @_vaibhaw | LinkedIn | Google+
Read my latest blog post: I Get To Know the Redis Database: Iterating Over Keys

Re: XFS doesn't auto mount on boot when /etc/fstab entry has fs type set to auto

[Vaibhaw Pandey]

Sorry to chime in again but I was wondering if it makes sense to just
add "xfs" to /etc/filesystems during installation of the package
itself? It is visible in the /proc/filesystems once it is installed
anyways. I have posed this question to the xfs@oss.sgi.com mailing
list as well.

On Thu, Feb 16, 2017 at 8:37 AM, Vaibhaw Pandey <vaibhaw@scalegrid.io> wrote:
> Carlos,
>
> Thanks a lot for replying. :)
>
> I should have read the mount man page more carefully: By adding "xfs"
> to /etc/filesystems, the /etc/fstab entry even with an auto started
> working fine.
>
> blkid always had an entry for the volume in question but that didn't
> make a difference in this case:
> $ sudo blkid
> /dev/xvda1: LABEL="/" UUID="ebbf1f1c-fb71-40aa-93a3-056b455e5127" TYPE="ext4"
> /dev/xvdb: UUID="bf4be26c-1c1c-40fc-b5cf-b9048dcc61b6" TYPE="xfs"
>
>
>> Anyway, if you have the logs from your system when it tries to mount the
>> partition maybe it give us some clue of what is happening.
>
> It was the complete lack of logs in dmesg or /var/log/messages about a
> failure to mount is what confused me on why this was failing. A
> successful mount logs but an unsuccessful one doesn't. I think I will
> ask a mount expert for help on this.
>
> Thanks again,
> Vaibhaw
>
> On Wed, Feb 15, 2017 at 5:57 PM, Carlos Maiolino <cmaiolino@redhat.com> wrote:
>> Hi,
>>
>>> LABEL=/     /           ext4    defaults,noatime  1   1
>>> tmpfs       /dev/shm    tmpfs   defaults        0   0
>>> devpts      /dev/pts    devpts  gid=5,mode=620  0   0
>>> sysfs       /sys        sysfs   defaults        0   0
>>> proc        /proc       proc    defaults        0   0
>>> /dev/sdb /redis_data auto noatime,noexec,nodiratime 0 0
>>> $ df -T /redis_data/
>>> Filesystem     Type 1K-blocks  Used Available Use% Mounted on
>>> /dev/xvdb      xfs    5232640 32940   5199700   1% /redis_data
>>>
>>> However if I change the /etc/fstab directive to:
>>>
>>> /dev/sdb /redis_data xfs noatime,noexec,nodiratime 0 0
>>>
>>> the auto mount starts working fine. Now this isn't a major problem
>>> since the functionality ultimately works. But I would certainly like
>>> to have the flexibility to avoid hard coding the fs type in the code
>>> that generates these fstab entries.
>>>
>>
>> I believe this is not a question for us, but for whatever software you are using
>> to mount your partitions, systemd, unit, init, whatever. It also might be a
>> problem with `mount` command, but if you say you can mount it normally after the
>> system is live, it looks not to be the case.
>>
>> XFS doesn't control who and how it reads the entries in fstab.
>>
>> As stated in `mount` manpage:
>>
>> "If no -t option is given, or if the auto type is specified, mount will try  to
>> guess  the  desired  type.   Mount  uses  the  blkid  library for guessing the
>> filesystem type; if that does not turn up anything that looks familiar,  mount
>> will  try  to  read  the  file  /etc/filesystems,  or, if that
>> does not exist, /proc/filesystems.  All of the filesystem types listed there
>> will be  tried, except  for  those  that  are labeled "nodev" (e.g. devpts, proc
>> and nfs). If /etc/filesystems  ends  in  a  line  with  a  single  *,   mount
>> will   read /proc/filesystems  afterwards.   While  trying,  all  filesystem
>> types will be mounted with the mount option silent."
>>
>>
>> Anyway, if you have the logs from your system when it tries to mount the
>> partition maybe it give us some clue of what is happening.
>>
>> Cheers
>>
>>> Any pointers or help is much appreciated. :)
>>>
>>> Thanks,
>>> Vaibhaw
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Carlos
>
>
>
> --
> Member of Technical Staff | ScaleGrid.io | @_vaibhaw | LinkedIn | Google+
> Read my latest blog post: I Get To Know the Redis Database: Iterating Over Keys



-- 
Member of Technical Staff | ScaleGrid.io | @_vaibhaw | LinkedIn | Google+
Read my latest blog post: I Get To Know the Redis Database: Iterating Over Keys

Re: XFS doesn't auto mount on boot when /etc/fstab entry has fs type set to auto

[Carlos Maiolino]

Hi,

On Thu, Feb 16, 2017 at 12:42:43PM +0530, Vaibhaw Pandey wrote:
> Sorry to chime in again but I was wondering if it makes sense to just
> add "xfs" to /etc/filesystems during installation of the package
> itself? It is visible in the /proc/filesystems once it is installed
> anyways. I have posed this question to the xfs@oss.sgi.com mailing
> list as well.
>
Just FYI, xfs@oss.sgi.org is no more, we have moved to vger, so, no one will
actually reply you there, always use linux-xfs@vger.kernel.org

Regarding your question, that is still a question not for XFS, /etc/filesystems
file doesn't belong to any xfs package, so we can't touch it, setting
/etc/filesystems is responsibility for another software, which, I *think* is
distro dependent.
 
Maybe it don't take too long by now, once many distros started to use XFS as
their default FS, but that might be a good idea to open a bug against the distro
you are using.

> On Thu, Feb 16, 2017 at 8:37 AM, Vaibhaw Pandey <vaibhaw@scalegrid.io> wrote:
> > Carlos,
> >
> > Thanks a lot for replying. :)
> >
> > I should have read the mount man page more carefully: By adding "xfs"
> > to /etc/filesystems, the /etc/fstab entry even with an auto started
> > working fine.
> >

Particularly I have never thought about adding something there because I always
use 'xfs' in fstab.

> > blkid always had an entry for the volume in question but that didn't
> > make a difference in this case:
> > $ sudo blkid
> > /dev/xvda1: LABEL="/" UUID="ebbf1f1c-fb71-40aa-93a3-056b455e5127" TYPE="ext4"
> > /dev/xvdb: UUID="bf4be26c-1c1c-40fc-b5cf-b9048dcc61b6" TYPE="xfs"
> >
> >
> >> Anyway, if you have the logs from your system when it tries to mount the
> >> partition maybe it give us some clue of what is happening.
> >
> > It was the complete lack of logs in dmesg or /var/log/messages about a
> > failure to mount is what confused me on why this was failing.

These logs won't appear in dmesg, this is the kernel log, what you should look
for is for `mount` logs. You are using systemd I suspect, if I am correct, you
will see such logs using `journalctl` command.

> > successful mount logs but an unsuccessful one doesn't. I think I will
> > ask a mount expert for help on this.
> >

Hope it have helped,

Cheers
-- 
Carlos

Re: XFS doesn't auto mount on boot when /etc/fstab entry has fs type set to auto

[Vaibhaw Pandey]

Thanks Carlos! :)

I will check with the Amazon Linux guys. There flavour of GNU/Linux
seems to be based off RHEL but they have woefully inadequate
documentation about everything. They seem to be using upstart as the
startup daemon but the logs are nowhere to be found. Will talk to them
about both adding XFS to /etc/filesysems and where do they logs from
system boot time end up.

Thanks again,
Vaibhaw

On Thu, Feb 16, 2017 at 2:27 PM, Carlos Maiolino <cmaiolino@redhat.com> wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 12:42:43PM +0530, Vaibhaw Pandey wrote:
>> Sorry to chime in again but I was wondering if it makes sense to just
>> add "xfs" to /etc/filesystems during installation of the package
>> itself? It is visible in the /proc/filesystems once it is installed
>> anyways. I have posed this question to the xfs@oss.sgi.com mailing
>> list as well.
>>
> Just FYI, xfs@oss.sgi.org is no more, we have moved to vger, so, no one will
> actually reply you there, always use linux-xfs@vger.kernel.org
>
> Regarding your question, that is still a question not for XFS, /etc/filesystems
> file doesn't belong to any xfs package, so we can't touch it, setting
> /etc/filesystems is responsibility for another software, which, I *think* is
> distro dependent.
>
> Maybe it don't take too long by now, once many distros started to use XFS as
> their default FS, but that might be a good idea to open a bug against the distro
> you are using.
>
>> On Thu, Feb 16, 2017 at 8:37 AM, Vaibhaw Pandey <vaibhaw@scalegrid.io> wrote:
>> > Carlos,
>> >
>> > Thanks a lot for replying. :)
>> >
>> > I should have read the mount man page more carefully: By adding "xfs"
>> > to /etc/filesystems, the /etc/fstab entry even with an auto started
>> > working fine.
>> >
>
> Particularly I have never thought about adding something there because I always
> use 'xfs' in fstab.
>
>> > blkid always had an entry for the volume in question but that didn't
>> > make a difference in this case:
>> > $ sudo blkid
>> > /dev/xvda1: LABEL="/" UUID="ebbf1f1c-fb71-40aa-93a3-056b455e5127" TYPE="ext4"
>> > /dev/xvdb: UUID="bf4be26c-1c1c-40fc-b5cf-b9048dcc61b6" TYPE="xfs"
>> >
>> >
>> >> Anyway, if you have the logs from your system when it tries to mount the
>> >> partition maybe it give us some clue of what is happening.
>> >
>> > It was the complete lack of logs in dmesg or /var/log/messages about a
>> > failure to mount is what confused me on why this was failing.
>
> These logs won't appear in dmesg, this is the kernel log, what you should look
> for is for `mount` logs. You are using systemd I suspect, if I am correct, you
> will see such logs using `journalctl` command.
>
>> > successful mount logs but an unsuccessful one doesn't. I think I will
>> > ask a mount expert for help on this.
>> >
>
> Hope it have helped,
>
> Cheers
> --
> Carlos



-- 
Member of Technical Staff | ScaleGrid.io | @_vaibhaw | LinkedIn | Google+
Read my latest blog post: I Get To Know the Redis Database: Iterating Over Keys