UUID vs / dev / sdX no FSTAB

Question

Eu tenho um sistema Linux no qual forçamos o / dev / devname para executar o sistema.

proc            /proc            proc    defaults        0       0
/dev/sda1       /                ext3    barrier=1,errors=remount-ro 0       1
/dev/sda5       /opt             ext3    barrier=1,defaults        0       22 
/dev/sda2       /opt/vortex/dvss ext3    barrier=1,defaults 0   3
/dev/sda6       none             swap    sw              0       0
/dev/scd0       /media/cdrom0    udf,iso9660 user,noauto     0       0

Temos este sistema funcionando sem problemas até a data. Mas, muitas vezes, em algumas máquinas instaladas, vemos que o sistema não é capaz de inicializar corretamente e repentino em "resgate Grub"

Quando eu monto o dispositivo como secundário e executo o E2Fsck, vejo que o sistema pode ser restaurado.

Agora, estamos tentando resolver essa falha. [ Corrigindo a falha de inicialização do sistema devido ao erro do GRUB

Em ordem, notei em alguns fóruns que eles dizem para inicializar com o SET UUID no FSTAB

quais são as vantagens que teríamos se fosse definido através do UUID.

Existe a possibilidade de reduzir meu ERRO GRUB

    

Answer 1

De man fstab :

Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL= or UUID=, e.g., 'LABEL=Boot' or 'UUID=3e6be9de-8139-11d1-9106- a43f08d823a6'. This will make the system more robust: adding or removing a SCSI [or SATA] disk changes the disk device name but not the filesystem volume label.

Quanto ao motivo pelo qual o GRUB falha ao inicializar às vezes, duvido que a configuração do UUID altere qualquer coisa (como parece pode falhar mesmo com UUID dado algumas configurações estranhas do BIOS ), mas vale a pena tentar, no entanto.

    

Answer 2

Os UUIDs resolveram meu problema, que era o mesmo que o seu problema.

O seguinte trecho do Arch Wiki é muito útil:

If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like /dev/sda and /dev/sdb switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.

Por questão, sua máquina pode decidir trocar arbitrariamente suas sda e sdc às vezes. Se isso acontecer, sua inicialização falhará.