Centos 7 - fstab não monta algumas partições, mas o mount / dev / sd * faz

Question

Eu tenho uma máquina virtual com o Centos 7, na qual eu quero montar algumas partições ext4. Os discos físicos são, na verdade, discos rígidos fornecidos pelo vSphere. Todos os discos estão localizados no mesmo NAS - então os três trabalhos (a, c, d) são virtualmente idênticos aos problemáticos (e, f, g)

conteúdo do 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

O problema é que o fstab não está montando as três últimas partições (que devem ser montadas sob /apps/var/progress /apps/var/standard e /apps/var/custom respectivamente) consistentemente após as reinicializações. Ele monta um deles de vez em quando (é totalmente aleatório se qualquer um destes três é montado, e é sempre apenas um ou nenhum que está sendo montado). As outras partições estão sendo montadas consistentemente sem nenhum problema.

A opção mount -a não está fazendo nada, no entanto $ mount / dev / sde1 (ou dev / sdf1 ou dev / sdg1) funciona como um encanto. Da mesma forma, a montagem usando o comando $ mount / apps / var / progress funciona sem problemas também.

Por enquanto eu apenas usei o cron para montar estas três partições após cada reinicialização, mas no longo prazo eu gostaria de saber a causa raiz desse comportamento estranho.

Eu tentei substituir os UUID's por / dev / sd *, tentei colocar aspas.

mount sempre mostra que as partições estão montadas nos catálogos corretos, no entanto, umount informa que a partição não está montada no momento.

Notei que as três partições problemáticas tinham sistemas de arquivos ext3 anteriormente, e foram de alguma forma convertidos em ext4. Além disso, para essas três partições, o blkid mostra o PARTUIDE além do UUID (acho que eles foram usados anteriormente com o centos 6)

    

Answer 1

Em resumo da discussão nos comentários:

Seu problema era essencialmente que você usava links simbólicos em seus caminhos de ponto de montagem e na inicialização o sistema não era capaz de segui-los corretamente para reconhecer o resultado como "montagens aninhadas". Portanto, o systemd não montou seus sistemas de arquivos em uma ordem sequencial adequada para lidar com essa dependência.

• Você tem um ponto de montagem /apps_home

• Você tem um link simbólico /apps --> /apps_home/apps

• E você também tentou montar volumes em /apps/var/progress /apps/var/custom e /apps/var/custom

O problema é que os pontos de montagem /apps/var/[custom|progress|standard] não existem até que /apps_home seja montado.

Solução :

Deixe o symlink, mas monte seus sistemas de arquivos nos caminhos reais do diretório do destino do symlink: isto é, converta suas entradas do fstab para:

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 gerará os arquivos necessários da unidade de montagem e systemd.mount adicionará implicitamente as dependências corretas:

If a mount unit is beneath another mount unit in the file system hierarchy, both a requirement dependency and an ordering dependency between both units are created automatically.

Alternativa: remova as entradas do / etc / fstab e crie seus próprios arquivos da unidade de montagem e configure manualmente as dependências de requisitos e pedidos para garantir que /apps/var/progress     /apps/var/custom e /apps/var/custom não são montados antes de /apps_home .

    

Answer 2

mount always shows that the partitions are mounted on right catalogues, however umount reports that the partition is not mounted at the moment.

A partir da discussão nos comentários, acredito que seu sistema apresenta esse comportamento devido a /etc/mtab ser um arquivo regular em vez de um link simbólico que é destinado a /proc/self/mount . Eu sugiro que você restaure o link simbólico, conforme documentado nesta solução da Red Hat :

In Red Hat Enterprise Linux 7, /etc/mtab is no longer a flat file, it is instead a symlink to /proc/self/mounts. If a service for some reason uses the sed command to access or modify /etc/mtab, it is possible that it will remove the symlink, and create a flat file. This in turns causes the server not to fully boot normally it drops to emergency mode, df output shows everything mounted, but if /proc/mounts is checked there will be nothing but / is mounted.