You can read lots of posts about this issue but there is not much information about why this is the case or how grub determines the root= device name.  Some even suggest modifying grub.cfg manually which is a disaster as the next kernel update will cause grub to revert back to the device name.

For most people this won't be an issue but those using template system, automated deployments and working in embedded may run into this issue with custom embedded and created minimal kernels/environments.

By default, grub will WANT or TRY to use the UUID as the root device, UNLESS in /etc/default/grub you enable the feature of GRUB_DISABLE_LINUX_UUID=true (usually it is not there at all or it is just commented out).

Then there is /etc/grub.d which scripts are called when you run update grub.  The one we really care about is the 10_linux file.

It doesn't matter if your fstab is updated to use UUID, this script doesn't care about fstab or the current root filesystem.

What it does is look for entries in /dev/disk/by-uuid and if it finds a UUID for the root device it will assign it like normal eg. root=UUID=theUUIDhere

/dev/disk/by-uuid is really just a series of UUIDs in that directory that are symlinked to their actual device name, this is how the grub 10_linux script associates the UUID to the root device and sets up the root=UUID. 

However, if it does not find a UUID entry in /dev/disk/by-uuid then it falls back to using the actual raw device name whether it be /dev/md2 or /dev/sda1 or /dev/vda1 etc...

linux, grub, uuid, dev, sda, solutionyou, posts, determines, modifying, cfg, manually, kernel, update, revert, template, automated, deployments, embedded, custom, minimal, kernels, environments, default, etc, enable, feature, grub_disable_linux_uuid, commented, scripts, _linux, doesn, fstab, updated, filesystem, entries, disk, assign, eg, theuuidhere, uuids, directory, symlinked, associates, entry, md, vda,

Latest Articles