Centos 7 - fstab does not mount some partitions, but mount /dev/sd* does
i have a Virtual Machine with Centos 7, on which i want to mount some ext4 partitions. Physical disks are actually hard disks provided by vSphere. All disks are located on the same NAS - so the three working ones (a,c,d) are virtually identical to the problematic ones (e,f,g)
content of fstab:
UUID=b6ebbca4-71d0-4d2e-bc1a-e465e5190698 /boot ext4 defaults 1 2
UUID=2c3ab9f5-60a6-4a79-ada3-84737eef7748 / ext4 defaults 1 1
UUID=e130758c-5108-44de-bbd8-7e003c9072bc swap swap defaults 0 0
UUID=decbbdb6-8362-41ef-aa72-83066c172913 /home ext4 defaults 1 2
UUID=5717b613-a9f4-43c9-95d2-cfbbb891bd19 /apps_home ext4 defaults 1 2
UUID=e24df090-2dda-404c-8944-a28bd37d6c5e /apps/var/progress ext4 defaults 1 2
UUID=5f254c77-a91d-4255-8315-9325ddb7a9d8 /apps/var/standard ext4 defaults 1 2
UUID=746c70c1-002a-4249-a06f-df393a99252c /apps/var/custom ext4 defaults 1 2
lsblk -o '+UUID,FSTYPE' output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID FSTYPE
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1G 0 part /boot b6ebbca4-71d0-4d2e-bc1a-e465e5190698 ext4
└─sda2 8:2 0 49G 0 part / 2c3ab9f5-60a6-4a79-ada3-84737eef7748 ext4
sdb 8:16 0 40G 0 disk
└─sdb1 8:17 0 40G 0 part [SWAP] e130758c-5108-44de-bbd8-7e003c9072bc swap
sdc 8:32 0 50G 0 disk
└─sdc1 8:33 0 50G 0 part /home decbbdb6-8362-41ef-aa72-83066c172913 ext4
sdd 8:48 0 600G 0 disk
└─sdd1 8:49 0 600G 0 part /apps_home 5717b613-a9f4-43c9-95d2-cfbbb891bd19 ext4
sde 8:64 0 250G 0 disk
└─sde1 8:65 0 250G 0 part /apps/var/progress e24df090-2dda-404c-8944-a28bd37d6c5e ext4
sdf 8:80 0 1T 0 disk
└─sdf1 8:81 0 1024G 0 part /apps/var/standard 5f254c77-a91d-4255-8315-9325ddb7a9d8 ext4
sdg 8:96 0 2T 0 disk
└─sdg1 8:97 0 2T 0 part /apps/var/custom 746c70c1-002a-4249-a06f-df393a99252c ext4
sr0 11:0 1 1024M 0 rom
The issue is that fstab is not mounting the three last partitions (that are supposed to be mounted under /apps/var/progress /apps/var/standard and /apps/var/custom respectively) consistently after reboots. It does mount one of them from time to time (it is totally random if any of these three is mounted, and it is always only one or none that is being mounted). The other partitions are being mounted consistently without any issues.
The mount -a option is not doing anything, however $mount /dev/sde1 (or dev/sdf1 or dev/sdg1) work like a charm. Similarly, mounting by using the command $mount /apps/var/progress works without any issues as too.
For now i just used cron to mount these three partitions after every reboot but in the long run i would like to know the root cause for this strange behaviour.
I tried replacing the UUID's with /dev/sd* names, i tried putting quotation marks.
mount always shows that the partitions are mounted on right catalogues, however umount reports that the partition is not mounted at the moment.
I noticed that the three problematic partitions had ext3 filesystems previously, and were somehow converted into ext4. Also, for these three partitions blkid shows the PARTUUID in addition to UUID (i think they were previously used with centos 6)
В итоге из обсуждения в комментариях:
Ваша проблема заключалась, по сути, в том, что вы использовали символические ссылки в пути к своим точкам монтирования, и при загрузке система не смогла правильно следовать за ними, чтобы распознать результат как "вложенные крепления". Поэтому systemd не смонтировал ваши файловые системы в правильном последовательном порядке, чтобы справиться с этой зависимостью.
У вас есть точка монтирования
/ apps_homeУ вас есть символическая ссылка
/ apps -> / apps_home / appsИ вы также пытаетесь подключить тома к
/ apps / var / progress/ apps / var / customи/ apps / var / custom
Проблема в том, что точки монтирования / apps / var / [custom | progress | standard] не существует, пока не будет смонтирован / apps_home .
Решение :
Оставьте символическую ссылку, но смонтируйте свои файловые системы на фактических путях к каталогам целевой символической ссылки: т.е. преобразуйте записи fstab в:
UUID=5717b613-a9f4-43c9-95d2-cfbbb891bd19 /apps_home ext4 defaults 1 2
UUID=e24df090-2dda-404c-8944-a28bd37d6c5e /apps_home/apps/var/progress ext4 defaults 1 2
UUID=5f254c77-a91d-4255-8315-9325ddb7a9d8 /apps_home/apps/var/standard ext4 defaults 1 2
UUID=746c70c1-002a-4249-a06f-df393a99252c /apps_home/apps/var/custom ext4 defaults 1 2
systemd-fstab-generato сгенерирует необходимые файлы модуля монтирования и systemd.mount неявно добавят правильные зависимости:
Если модуль монтирования находится ниже другого модуля монтирования в иерархии файловой системы, то и зависимость требований, и зависимость порядка между ними единицы создаются автоматически.
Альтернатива: удалите записи из / etc / fstab и создайте свои собственные файлы модулей монтирования и вручную настройте требования и зависимости порядка, чтобы убедиться, что / apps / var / progress
/ apps / var / custom и / apps / var / custom не монтируются до / apps_home .
mount всегда показывает, что разделы смонтированы в правильных каталогах, однако umount сообщает, что раздел в настоящий момент не смонтирован.
Из обсуждения в комментариях я считаю, что ваша система демонстрирует такое поведение из-за того, что / etc / mtab является обычным файлом, а не символическим ссылка на / proc / self / mount . Я предлагаю вам восстановить символическую ссылку, как описано в этом решении Red Hat :
В Red Hat Enterprise Linux 7
/ etc / mtabбольше не является плоским файлом, это вместо этого является символической ссылкой на/ proc / self / mounts. Если служба по какой-то причине использует командуsedдля доступа или изменения/ etc / mtab, возможно, она удалит символическую ссылку и создаст плоский файл. Это, в свою очередь, приводит к тому, что сервер не загружается полностью, он переходит в аварийный режим, выводdfпоказывает, что все подключено, но если проверено/ proc / mounts, не будет ничего, кроме] /смонтирован.