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.
2 Likes
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
Standards:
Supported: 10 9 8 7 6 5
Likely used: 10
Configuration:
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
Capabilities:
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
Commands/features:
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
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* IDLE_IMMEDIATE with UNLOAD
* WRITE_UNCORRECTABLE_EXT command
* Segmented DOWNLOAD_MICROCODE
* 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)
* DOWNLOAD MICROCODE DMA command
* DEVICE CONFIGURATION SET/IDENTIFY DMA commands
* Data Set Management TRIM supported (limit 8 blocks)
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
2min for SECURITY ERASE UNIT. 60min for ENHANCED SECURITY ERASE UNIT.
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.
2 Likes
Well, I deleted the install of grub on /dev/hdb and all of a sudden my problems evaporated.
1 Like
Congratulations.
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
Regards
Neville
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?
Thanks,
Howard
2 Likes
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.
but
It puzzles me why your MX update took over grub control?
It is normal for an update, if it involves kernel, to do
update-grub
at the end of the install.
That is harmless, all it does is write a grub.cfg file in your MX
filesystem.
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.
Regards
Neville
Afterthought.
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.
3 Likes
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.
Thanks,
Howard
3 Likes
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?
Regards
Neville
2 Likes