Got a worrisome grub error

Today I got a grub error, which basically read: no such device <UUID>. When I rebooted the error was gone and mint booted as normal.

Do I need to worry?

I dont think it is an error in grub… grub is just reporting it.
Sounds like the boot could not find some disk partition.
If it disappeared on reboot , there is not much you can do.,
except maybe look at dmesg

Did you move any partitions?
You might try update-grub.

That’s the strange thing: I didn’t do anything to my system.

I just launched my computer and got this error on boot. I didn’t change any partitions or something along those lines.

Could there be a possibility of bad sectors?

You can run the SMART software to check. It will not do any harm.
Nothing in dmesg or /var/log/messages ?
Try a memtest.


Where can I get a boot image that includes memtest 86?

If it’s included in Linux Mint, how do I get to it on boot? (I have no other OS installed, so it just moves on).

SMART had no errors.

No problems (other than the usual, because of my broken BIOS) in the logs.

It should be in SystemRescueCD, and maybe in Clonezilla or Knoppix.
It appears in a multiboot grub menu, but I think a single install of Mint would skip the grub menu.

1 Like

The error returned, this time it persisted with two other reboots. Strange thing is, once the system boots, everything functions ok.

Perhaps this is a related issue, but from time to time I have artifacts with the clock in the bottom right of the bottom panel. Is this a known issue with the clock, a driver issue, or indicative of a hardware failure? I’ve been having this issue with Linux Mint since I installed it (before the strange grub issue happened). The issue goes away (for a time) when I hover my mouse over the garbled display of the number. It happens only to the last number of the time.

Memory turned out ok.

Next up, the SATA cable. Anybody know what SATA cable I should get? Here are my results from hdparm:

ATA device, with non-removable media
	Model Number:       KINGSTON RBU-SNS8151S396GG              
	Serial Number:      50026B726A002404    
	Firmware Revision:  S9FM02.6
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
	Supported: 10 9 8 7 6 5 
	Likely used: 10
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	CHS current addressable sectors:    16514064
	LBA    user addressable sectors:   187557552
	LBA48  user addressable sectors:   187557552
	Logical  Sector size:                   512 bytes
	Physical Sector size:                   512 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:       91580 MBytes
	device size with M = 1000*1000:       96029 MBytes (96 GB)
	cache/buffer size  = unknown
	Form Factor: unknown (0x0007]
	Nominal Media Rotation Rate: Solid State Device
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Advanced power management level: 254
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	Advanced Power Management feature set
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Gen3 signaling speed (6.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Phy event counters
	   *	Device automatic Partial to Slumber transitions
	   *	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
	    	Device Sleep (DEVSLP)
	   *	Data Set Management TRIM supported (limit 8 blocks)
	Master password revision code = 65534
	not	enabled
	not	locked
	not	expired: security count
		supported: enhanced erase
Device Sleep:
	DEVSLP Exit Timeout (DETO): 20 ms (default)
	Minimum DEVSLP Assertion Time (MDAT): 10 ms (default)
Checksum: correct

One more thought: might it be an issue with my UEFI firmware? If that belongs to the possibilities, how do I check the firmware’s integrity?

Is your power supply stable?
I dont know how to check it.

Ok. I think I know what’s at issue.

My BIOS is buggy.

Today I faced the same situation. Across multiple reboots, grub gave this error. So, I fired up the boot menu and KDE neon, and PCLinuxOS showed up, both of which had been removed. Then I stuck in a bootable USB stick… and lo and behold, Linux Mint appeared and booted nicely.

I had forgotten all about the EFI partition on my HDD (my /dev/sdb) and that one was causing the strange grub problems. Each time the BIOS decided to boot from the EFI partition on my HDD and that installation of grub wanted to boot from my HDD, of which the partitions had already been wiped and of course de UUIDs had changed over there, so no wonder it could not find the partitions. It never booted from the correct drive (my SSD) in the first place!

The reason I don’t think my SSD or SATA cable are at issue is, once my system boots, everything is rock solid.

You are saying the BIOS changed the default boot disk, behind your back?
Are you sure you did not somehow accidentally change it?

You seem to have grub installed on both disks. That is OK… I do that, but I have a separate linux controlling each grub.
What do you have? If you have 2 grubs , but only one linux, there will be issues keeping grub.cfg correct.
So I am saying, you may have a grub muddle rather than a
faulty BIOS. That would be easier to fix.

You are doing well tracking it down to this stage.


Well, I deleted the install of grub on /dev/hdb and all of a sudden my problems evaporated.

1 Like

Grub can be incredibly confusing if things get untidy.
You should mark this as solved

I wrote this recently, in another topic

Managing multiboot is not straightforward.
The survival recipe is

  -    make sure you know which linux controls grub
  -   if the non grub controlling linux updates a kernel, go to the controlling linux and do
    update-grub there
  -   never do grub-install from the non controlling linux… you will make it the controlling linux.
  -   make sure os-prober is enabled in the controlling linux

If you follow that managing multiboot is
a breeze

You probably know those points, but it helps to keep them in mind

Hi Neville (@nevj ),

A bit more about grub.
My main Linux is Mint but I also have MX on the desktop, so it is dual boot.

So Mint controls grub and is the default Linux that is booted. So the other day, I booted MX and noticed there were a few updates to be applied, so I performed the update. On the next boot, MX seem to control grub and now it was the default Linux. I did not notice any options on the update screen about grub.
I wanted Mint as default so I booted Mint, at the terminal I did these commands;
sudo install-grub
sudo update-grub

On the next boot, Mint grub came back up and was the default system to be booted.
Do you think this was the correct procedure?



Hi Howard,
Yes, that is the way to set which distro controls grub.
Basically, the dustro that last installed grub is the one that controls it.

It puzzles me why your MX update took over grub control?
It is normal for an update, if it involves kernel, to do
at the end of the install.
That is harmless, all it does is write a grub.cfg file in your MX
Unless you do a grub-install in MX, that grub.cfg file will never be used… Mint willl contain the real active grub.cfg file.
What you must do, after uodating MX, is go into Mint, and do the real update-grub there.

So, what happened in your case?
Maybe you thought MX was taking over when you saw it
doing that update-grub. I dont know?

Anyway, you did the right thing. Better to be sure.


Maybe your MX update actually installed a new version of grub. That may have led it to do a grub-install, and, of course that would have led to an MX takeover.

I must watch closely next time some distro gets a new grub version.


Hi Neville,

Yes, it surprised me a bit to see MX take over grub.
The next time I perform an update in MX, I will try to remember to save the update log.



Well, it seems the issue has returned with a vengeance.

This morning I wanted to start my computer. It announced with pride it could not find an OS. Then I checked the BIOS. It could not find the SSD at all.

So, I booted a Linux Mint live USB. In there the SSD was not found as well. So, I went and got myself a new SSD. For shits and giggles I tried to reboot. Apparently the computer panicked and was afraid of surgery, because now the SSD (the original one) booted up again.

Strange thing is: once the SSD boots, there’s not a problem in the world. No bad sectors, no sudden crashes of Mint, no nothing.

Is the conclusion that the problem may be my BIOS a correct one?

I guess I simply have to never reboot again and leave this computer on forever, then there won’t be a problem.

Hi Xander,
That is annoying
When you fitted the new SSD you disturbed the sata and power cables…so maybe cables or connector sockets.
Otherwise it looks like BIOS, yes… but why would a bios have an intermittant fault?