3

I have Linux system in which we force /dev/devname for running the system.

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

We have this system running without issues till date. But, often in some installed machine we see that the system is not able to boot properly and sudden goes into "Grub rescue"

When i mount the device as secondary and run E2Fsck i see that the system can be restored.

Now, we are trying to address this failure. [Fixing System boot failure due to GRUB Error

In order, I noticed in some forums they say to SET UUID based boot up in FSTAB

what are all the advantages that we would have if it is set through UUID.

Is there a possibility that it would reduce my GRUB ERROR

3

From 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.

As for the reason why GRUB fails to boot sometimes, I doubt that setting the UUID would change anything (as it seems it can fail even with UUID given some odd BIOS settings), but it's worth trying, though.

3

UUIDs solved my problem, which was the same as your problem.

The following excerpt from the Arch Wiki is very helpful:

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.

Point being, your machine may decide to arbitrarily swap your sda and sdc sometimes. If that happens, your boot will fail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.