Boot failure "No OS detected" message. GRUB problem?

Hi all. For many months, my mother used her Samsung 870 EVO SSD with Ubuntu Mate 24.04.1 LTS (only) installed on it. It worked fine, until one day it stopped booting up, the black screen displaying the message “No Operating System detected”.

I’m sure that her hardware is still good enough to run Ubuntu Mate, as I’m able to use a secondary NVME SSD (just connected to a USB2 port) on it, with no problem at all. The problem Samsung internally-mounted SSD above is probably less than 2 years old and has hardly been used. Using my NVME SSD, I got the assessment "Disc OK" for the problem Samsung but reports 5 bad sectors. Are these perhaps a problem on an SSD? Preventing it from booting up? I did a png screenshot of it and I hope that my upload of it below here, can be opened:

Having encountered similar-looking “GRUB” problems from time to time in the past, I tried fixing the problem with an old boot repair disk USB key I had (perhaps unwisely, as it dated from 2014). It worked in the past, but this time it didn’t. In July 2024, I followed Ubuntu guides to get the latest version at the time. I believe that this boot repair key uses Linux Mint (LM logo is displayed); I updated it, as per its recommendation.
Using this latter boot repair key, the boot info report says that Ubuntu 24.04.1 LTS is indeed STILL present on sda5 (BTW Through my secondary NIMH SSD, I can see that all my mother’s files are still intact on the problem SSD)

I’m very wary about removing the “Grub2 files” and then having to try to install another bootloader (especially when I have no idea how to do this!). Here’s the PNG screenshot upload, hoping it can be opened:

Boot repair remove GRUB

I’d be very grateful for any advice you have how a NOVICE like me, can solve this problem (ideally with less effort involved than reinstalling UbuntuMate and all my Mum’s files)! Including if I’ve been perhaps barking up the wrong tree! :sweat_smile:

I saved the boot info report as a text file, but the forum system will not allow me to upload it. So I’m pasting it below here:

boot-info-4ppa2081 [20250102_0110]

============================== Boot Info Summary ===============================

=> Syslinux MBR (4.04-4.07) is installed in the MBR of /dev/sda.
=> Grub2 (v2.00) is installed in the MBR of /dev/sdg and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (,msdos1)/boot/grub. It also embeds following components:

modules
---------------------------------------------------------------------------
fshelp ext2 part_msdos biosdisk
---------------------------------------------------------------------------

sda1: __________________________________________________________________________

File system:       vfat
Boot sector type:  FAT32
Boot sector info:  No errors found in the Boot Parameter Block.
Operating System:  
Boot files:        

sda2: __________________________________________________________________________

File system:       Extended Partition
Boot sector type:  -
Boot sector info: 

sda5: __________________________________________________________________________

File system:       ext4
Boot sector type:  -
Boot sector info: 
Operating System:  Ubuntu 24.04.1 LTS
Boot files:        /boot/grub/grub.cfg /etc/fstab /etc/default/grub 
                   /boot/grub/i386-pc/core.img

sdg1: __________________________________________________________________________

File system:       ntfs
Boot sector type:  Windows 2000/XP: NTFS
Boot sector info:  No errors found in the Boot Parameter Block.
Operating System:  
Boot files:        

sdb: ___________________________________________________________________________

File system:       iso9660
Boot sector type:  Unknown
Boot sector info: 
Mounting failed:   mount: /mnt/BootInfo/FD/sdb: /dev/sdb already mounted or mount point busy.

================================ 1 OS detected =================================

OS#1 (linux): Ubuntu 24.04.1 LTS on sda5

================================ Host/Hardware =================================

CPU architecture: 64-bit
Video: 82915G/GV/910GL Integrated Graphics Controller from Intel Corporation
Live-session OS is Linuxmint 64-bit (Linux Mint 21.2, victoria, x86_64)

===================================== UEFI =====================================

BIOS/UEFI firmware: A03 from Dell Inc.
This live-session is in Legacy/BIOS/CSM mode (not in EFI mode).

============================= Drive/Partition Info =============================

Disks info: ____________________________________________________________________

sda : notGPT, no-BIOSboot, has-noESP, not-usb, not-mmc, has-os, no-wind, 2048 sectors * 512 bytes
sdg : notGPT, no-BIOSboot, has-noESP, usb-disk, not-mmc, no-os, no-wind, 2048 sectors * 512 bytes

Partitions info (1/3): _________________________________________________________

sda1 : no-os, 64, nopakmgr, no-docgrub, nogrub, nogrubinstall, no-grubenv, noupdategrub, not-far
sda5 : is-os, 64, apt-get, grub-pc , grub2, grub-install, grubenv-ng, update-grub, end-after-100GB
sdg1 : no-os, 64, nopakmgr, no-docgrub, nogrub, nogrubinstall, no-grubenv, noupdategrub, end-after-100GB

Partitions info (2/3): _________________________________________________________

sda1 : isnotESP, part-has-no-fstab, no-nt, no-winload, no-recov-nor-hid, no-bmgr, notwinboot, vfat
sda5 : isnotESP, fstab-without-efi, no-nt, no-winload, no-recov-nor-hid, no-bmgr, notwinboot, ext4
sdg1 : isnotESP, part-has-no-fstab, no-nt, no-winload, no-recov-nor-hid, no-bmgr, notwinboot, ntfs

Partitions info (3/3): _________________________________________________________

sda1 : not–sepboot, no—boot, part-has-no-fstab, not-sep-usr, no—usr, part-has-no-fstab, no–grub.d, sda
sda5 : not–sepboot, with-boot, fstab-without-boot, not-sep-usr, with–usr, fstab-without-usr, std-grub.d, sda
sdg1 : not–sepboot, no—boot, part-has-no-fstab, not-sep-usr, no—usr, part-has-no-fstab, no–grub.d, sdg

fdisk -l (filtered): ___________________________________________________________

Disk sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk identifier: 0x422df5ef
Boot Start End Sectors Size Id Type
sda1 2048 1050623 1048576 512M b W95 FAT32
sda2 1052670 976771071 975718402 465.3G 5 Extended
sda5 * 1052672 976771071 975718400 465.3G 83 Linux
Disk sdb: 7.5 GiB, 8053063680 bytes, 15728640 sectors
Disk identifier: 0x14eb2669
Boot Start End Sectors Size Id Type
sdb1 * 0 5138431 5138432 2.5G 0 Empty
sdb2 572 9067 8496 4.1M ef EFI (FAT-12/16/32)
sdb3 5140480 15728639 10588160 5G 83 Linux
Disk sdg: 114.61 GiB, 123060879360 bytes, 240353280 sectors
Disk identifier: 0x162ec9ef
Boot Start End Sectors Size Id Type
sdg1 * 2048 240351231 240349184 114.6G 83 Linux

parted -lm (filtered): _________________________________________________________

sda:500GB:scsi:512:512:msdos:ATA Samsung SSD 870:;
1:1049kB:538MB:537MB:fat32::;
2:539MB:500GB:500GB:::;
5:539MB:500GB:500GB:ext4::boot;
sdb:8053MB:scsi:512:512:msdos:General UDisk:;
2:293kB:4643kB:4350kB:::esp;
3:2632MB:8053MB:5421MB:ext4::;
sdg:123GB:scsi:512:512:msdos:SanDisk Ultra USB 3.0:;
1:1049kB:123GB:123GB:ntfs::boot;

Free space >10MiB: ______________________________________________________________

sdb: 4.43MiB:2510MiB:2506MiB

blkid (filtered): ______________________________________________________________

NAME FSTYPE UUID PARTUUID LABEL PARTLABEL
sda
├─sda1 vfat 3B26-7C17 422df5ef-01
├─sda2 422df5ef-02
└─sda5 ext4 b0750895-bf20-4e21-897d-cc0e64bb3a25 422df5ef-05
sdb iso9660 2023-12-23-05-05-55-00 Boot-Repair-Disk 64bit
├─sdb1 iso9660 2023-12-23-05-05-55-00 14eb2669-01 Boot-Repair-Disk 64bit
├─sdb2 vfat 8D6C-A9F8 14eb2669-02 ESP
└─sdb3 ext4 2af65e8e-754c-4ecf-8d77-6875dd72c70e 14eb2669-03 writable
sdc
sdd
sde
sdf
sdg
└─sdg1 ntfs CE2840C32840AC71 162ec9ef-01 usb

Mount points (filtered): _______________________________________________________

                                                         Avail Use% Mounted on

/dev/sda1 511M 0% /mnt/boot-sav/sda1
/dev/sda5 380.7G 12% /mnt/boot-sav/sda5
/dev/sdb1 0 100% /cdrom
/dev/sdg1 113.8G 1% /media/mint/usb

Mount options (filtered): ______________________________________________________

/dev/sda1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
/dev/sda5 ext4 rw,relatime
/dev/sdb1 iso9660 ro,noatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8
/dev/sdg1 fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096

====================== sda5/boot/grub/grub.cfg (filtered) ======================

Ubuntu b0750895-bf20-4e21-897d-cc0e64bb3a25

END /etc/grub.d/30_os-prober

UEFI Firmware Settings uefi-firmware

END /etc/grub.d/30_uefi-firmware

========================== sda5/etc/fstab (filtered) ===========================

/ was on /dev/sda5 during installation

UUID=b0750895-bf20-4e21-897d-cc0e64bb3a25 / ext4 errors=remount-ro 0 1

/boot/efi was on /dev/sda1 during installation

/swapfile none swap sw 0 0

======================= sda5/etc/default/grub (filtered) =======================

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash”
GRUB_CMDLINE_LINUX=“”

==================== sda5: Location of files loaded by Grub ====================

       GiB - GB             File                                 Fragment(s)

331.181144714 = 355.603046400 boot/grub/grub.cfg 1
460.661121368 = 494.631112704 boot/grub/i386-pc/core.img 1
28.751949310 = 30.872170496 boot/vmlinuz 2
330.859024048 = 355.257171968 boot/vmlinuz-6.5.0-44-generic 2
28.751949310 = 30.872170496 boot/vmlinuz-6.8.0-45-generic 2
330.859024048 = 355.257171968 boot/vmlinuz.old 2
31.626850128 = 33.959071744 boot/initrd.img 3
126.751960754 = 136.098881536 boot/initrd.img-6.5.0-44-generic 8
31.626850128 = 33.959071744 boot/initrd.img-6.8.0-45-generic 3
126.751960754 = 136.098881536 boot/initrd.img.old 8

===================== sda5: ls -l /etc/grub.d/ (filtered) ======================

-rwxr-xr-x 1 root root 18133 Apr 4 2024 10_linux
-rwxr-xr-x 1 root root 43202 Oct 2 2023 10_linux_zfs
-rwxr-xr-x 1 root root 14513 Apr 4 2024 20_linux_xen
-rwxr-xr-x 1 root root 786 Oct 2 2023 25_bli
-rwxr-xr-x 1 root root 13120 Oct 2 2023 30_os-prober
-rwxr-xr-x 1 root root 1174 Oct 2 2023 30_uefi-firmware
-rwxr-xr-x 1 root root 722 Feb 26 2023 35_fwupd
-rwxr-xr-x 1 root root 214 Jul 31 2020 40_custom
-rwxr-xr-x 1 root root 215 Apr 15 2022 41_custom

======================== Unknown MBRs/Boot Sectors/etc =========================

Unknown BootLoader on sdb

Suggested repair: ______________________________________________________________

The default repair of the Boot-Repair utility would purge (in order to reset grubenv) and reinstall the grub2 of
sda5 into the MBR of sda.
Grub-efi would not be selected by default because no ESP detected.
Additional repair would be performed: unhide-bootmenu-10s

Final advice in case of suggested repair: ______________________________________

Please do not forget to make your BIOS boot on sda (ATA Samsung SSD 870) disk!

The boot files of [sda5 (end>100GB)] are far from the start of the disk. Your BIOS may not detect them. You may want to retry after creating a /boot partition (EXT4, >200MB, start of the disk). This can be performed via tools such as gParted. Then select this partition via the [Separate /boot partition:] option of [Boot-Repair]. (BootPartition - Community Help Wiki)

Many thanks in advance for any help! :grinning:

From the output you posted of boot repair, it appears you are using an old DVD/USB of MInt with boot repair. I don’t see how removing Grub files is going to fix the problem, well it won’t.

An unusual setup. Your first partition on the Ubuntu drive, sda1 is a vfat partition which is usually present on an EFI install. There are no files on that partition so it is useless. You have syslinux code in the MBR of sda, the Ubuntu drive which is not standard and would not happen with a normal install. Generally happens when people are trying to the bootloader . sda is an msdos drive and has an Extended partition and Ubuntu is installed in a logical partition with that extended, Ubuntu being on sda5.

You have grub code in the mbr of sdg and sdf1 shows as a Linux partition and an ntfs partition in part of the boot repair output. Can’t really tell you where it is because it isn’t numbered like the new boot repair files.

sdb looks like your Mint flash drive with boot repair. Near the bottom of the boot repair output you will see: /boot/efi was on /dev/sda1 during installation
That is in the /etc/fstab file and tells us this was an EFI install and someone deleted the EFI partition. Get a new boot repair and use the 2nd option explained on that page and reinstall Grub in Legacy mode.

Boot-Repair - Community Help Wiki

You can do an EFI install on an msdos drive but it is not recommended.

1 Like

Thanks very much indeed yancek for all your time and effort in giving me your very detailed reply :grinning:

As a complete IT dummy, I don’t understand all of it yet (things like EFI !!). But I’ll try some reading, to get my head around it all!

I’m most perplexed why the installation isn’t standard setup. When I install an Ubuntu OS, I simply follow the instructions and do whatever I’m told is “recommended” !

And I’m most alarmed too, regarding the deleting of the EFI partition you referred to. Nobody but myself and my elderly mother uses her computer (including the problem SSD I’m posting about)…and neither of us have the faintest idea what an EFI partition is, still less how to delete it!! I’ve been trying my best to understand EFI and implications. My mother’s old computer has BIOS and not EFI (as I understand it anyway)

I’ve looked at your Community Boot Repair link, thanks very much. I remember now, following those instructions just last July 2024 in order to create the Mint boot repair USB drive, using Unetbootin. Does that really make it too old now to do the job? When you say “get a new boot repair”, how can I do this so that it differs from what I have already?

I’d be most grateful if you have time to reply!

PS I have several HDDs at home (1000 kms away), all with various boot problems…so I’m VERY keen to learn how to deal with them!! :sweat_smile:

The EFI partition was not deleted as it still shows in boot repair but the files generally seen there (which are necessary for an EFI boot) are not shown. Either boot repair was unable to see them, which would be unusual or they were deleted.

The image in your initial post shows a 500GB Samsung drive and the first partition in blue shows a 537MB FAT partition. FAT32 or vfat is a windows filesystem and is not used on Linux/Ubuntu except for storing EFI files so there would be no other reason for it to be there.

Near the top of the boot repair output you will see that Syslinux MBR (4.04-4.07) is installed in the MBR of /dev/sda. Ubuntu systems have been using Grub2 since 2009 so I don’t know where Syslinux came from.

As I indicated in my previous post, Near the bottom of the boot repair output you will see: /boot/efi was on /dev/sda1 during installation. That means that at some point, Ubuntu was installed in EFI mode.

In your boot repair output, I see “The default repair of the Boot-Repair utility would purge (in order to reset grubenv) and reinstall the grub2 of sda5 into the MBR of sda”. That should fix the boot problem and overwrite the syslinux currently in the MBR of that drive.

In your initial post, you mention using a Mint boot repair disk from 2014. That is too old, too many changes since then. What did you use to generate the boot repair you posted? Is that more current?

The link below gives some information on Ubuntu and UEFI although it is a bit dated it should be useful.

https://help.ubuntu.com/community/UEFI

1 Like

Thanks very much again yancek for your very detailed and prompt reply…it will undoubtedly be very helpful when I can eventually understand all the technical stuff! :grinning: :sweat_smile:

To clear up a big misunderstanding (my original post was perhaps unclear, sorry): my Mint boot repair USB key dates from July 2024, when I followed (to the letter!) all the instructions in the community guide (the same one that you posted to me in your penultimate post):

https://help.ubuntu.com/community/Boot-Repair

I then downloaded the ISO from Sourceforge and burned it to the USB key. The Mint interface looks totally normal to me…

I now STRONGLY suspect that everything went wrong (the things you’ve pointed out) with the EFI partition, Syslinux MBR apparently replacing Grub2 etc, since I used an old Boot Repair key, dating from 2014, to TRY to repair the boot problem on an earlier occasion [I did this in great desperation (and in a great hurry!), when my mother’s (almost new) SDD suddenly decided to stop booting up, on the very day when I had to travel home (1000kms away!)].

If you were an IT dummy, what would you do with all this mess I’ve created?! Would I save a lot of time do you think by just doing a fresh installation on the problem SSD? Or if I followed the instructions for Option 2 in the above community boot repair page (as you advised in your first post), would this mess probably be cleared up automatically?

I’ll try to understand the reading you’ve recommended, thanks very much :grinning:. I’m hoping in the meantime that you can help me a little more on these 2 points below you made:

I hope this question doesn’t frustrate you: is Ubuntu installed in EFI mode the normal way today? Even on older computers that use BIOS?

I’m confused why this FAT partition appears here. I bought the SSD brand new and it never had Windows installed on it. Same story for all my HDDs back home, from what I can remember. Are you saying that it’s NORMAL for a FAT partition to be on an Ubuntu installation in order to store EFI files?

Many thanks in advance for any further help you can give me :grinning:

Not that it matters to the help topic, but oftentimes manufacturers will preformat drives to help users save time or, in this case, waste your time. :laughing:

2 Likes

@greenewbie

Have you tried

sudo update-grub

I mean I know it’s usually recommended (actually required) for after editing the /etc/default/grub file. But it also checks via os prober and clean up the boot load menu.
Just scrolled up and noticed your using Mate… huh might work still (according to google it does the same in Mate as my regular Ubuntu desktop) Just a stab in the dark.
per @eeickmeyer
" Not that it matters to the help topic, but oftentimes manufacturers will preformat drives to help users save time or, in this case, waste your time. :laughing: "

Yepp they do, aka no good deed goes unpunished as they say. Which is why really it’s not a bad Idea to run

sudo wipefs -a /dev/sd# ( <<the installation disk) 
just force a wipe on the drive PRIOR to installing the desired OS
in your case MATE. with the partition tables gone the installer has to partition format etc
the drive just like it had nothing done to it.

(and folks wonder why I go by “trust but verify” been in your shoes way to many times)

1 Like

Consistently in booting is important.
Very old systems before 2012 were BIOS only now CSM or legacy. CSM - UEFI Compatibility Support Module (CSM), which emulates a BIOS mode, only available with secure boot off.
New systems starting about 2020 are UEFI only.

Issue then is from 2012 to 2020 systems were configured with UEFI, but could boot in old BIOS mode so major corporate users could have older & newer systems in same boot mode.

If hardware is UEFI, best to always boot in UEFI mode. When you boot USB flash drive or live installer always choose UEFI. But once installer, a setting in UEFI sets default boot mode. Some newer uEFI will see a boot entry and know if UEFI or BIOS and boot in that mode.

Boot-Repair will put a syslinux boot loader in MBR if it sees BIOS Windows as syslinux uses boot flag like Windows and it can be used to boot old BIOS Windows. Grub does not use boot flag. And in UEFI mode there is not any boot info in MBR, as boot files are in ESP - efi system partition.

How you boot live installer UEFI or BIOS is how it installs, or repairs. So best with newer UEFI systems to be sure to always boot in UEFI mode. If system is before 2012, it probably will not even have an UEFI mode, only a few BIOS systems in 2011 may have had UEFI hardware. Microsoft required vendors to install WIndows 8 in UEFI boot mode with gpt partitioning in 2012, so hardware became UEFI.

2 Likes

I would re-install

Undoubtedly

Two caveats:-

  • Do you have a backup of your mum’s personal data?
  • Can you ascertain if this PC is UEFI compatible? (Boot into the BIOS/UEFI settings via the dedicated key (e.g. F2 or similar) and look for Secure Boot or UEFI/Legacy switch)
1 Like

parted -lm (filtered): _________________________________________________________
sda:500GB:scsi:512:512:msdos:ATA Samsung SSD 870:

The output above is from your boot repair output and shows your drive is msdos which is generally used to do a legacy install. As has been pointed out, you have an EFI partition with no files in it and that partition is used to hold EFI boot files. Ubuntu and Linux installers will create that vfat/efi partition if the installer is booted in EFI mode and the partition does not exist already.

my Mint boot repair USB key dates from July 2024, when I followed (to the letter!) all the instructions in the community guide

The above is from your earlier post and is probably the reason syslinux is in the MBR as explained in the post above by oldfred. I would suggest you reinstall after first making a backup of all your personal data. If you want to do an EFI install, first convert the partition table to GPT rather than msdos (use gparted on the Ubuntu installer) and then make sure your BIOS selection is set to boot in UEFI mode as the mode you boot in is the mode in which it is installed. Basically, use the suggestions above in the posts by oldfred and tea-for-one.

1 Like

Thanks very much eeickmeyer for your completely clear reply to my question, I understood immediately!
That’s one thing cleared up in my head, just a few more thousand to go now! :sweat_smile:

That’s very clear, useful info, thanks very much sgt-mike ! :grinning:

That command looks very promising, a great tip I’m sure, for this and future problems! I’ll give it a whirl!! :grinning:

Thanks very much tea-for-one for your clear answers! :grinning:

Yes of course, some IT things I’ve learned veryi well (often the hard way!) :grinning:

No, I’m quite sure the tower is BIOS only, (it dates from approx 2010, so I guess this will confirm it!). PS Even though I’ve upgraded it, as much as I can (the problem SSD made a big difference to its performance), we realise that it’s coming to the end of its useful life now!

I’ve never had a machine yet that uses UEFI, they’ve all been BIOS. In the BIOS menu, in the section “boot devices” I’ve always simply put USB key at the top (ie No 1 priority) in order to install an OS on the machine from the USB installation key. I hope I’ve been doing the right thing after all these years?!!

@greenewbie
I found myself in a similar situation last night after posting on my Win10/Ubuntu Desktop machine. The Mother board from MSI support gen 4 and 5 Intel processor, and has the UEFI as well as the legacy boot options. Which I install in UEFI mode every time I stick a OS on it.
So mine has Win 10 on one drive (SSD) and Ubuntu desktop on a NvME drive.
So usually when I change from one OS to the other I hit F11 for selection of which OS to boot.
Sounds great right?
Well at some point the Mainboard decided to change the default selection for UEFI to UEFI + Legacy (this part is important as it backs up Oldfred’s statement) as it also has early AI for the gaming aspect.
I did not see that it had been changed, so I’m assuming it’s still like I set it. well I bounced back and forth between Windows and Ubuntu as normal. Then suddenly it corrupted the Ubuntu drive grub boot loader etc etc… well the Ubuntu drive really had nothing I couldn’t just reinstall faster than recovering the system. Which I could have done. So yes sometimes we all wind up where your at.

1 Like

Many thanks again to everybody who has gone to great effort to try to help me here. Many of the technicalities in some of these posts are unfortunately well beyond my level at the moment, to be honest (Think of me as a blind man, trying to grope his way through a massive labyrinth!! :sweat_smile:). But I must emphasise that I’m very grateful for all your time you guys have given me :grinning:

So I’ll do a fresh install on the problem SSD, as you’ve recommended, on my Mum’s old tower that uses BIOS. My understanding therefore is that EFI or UEFI files are not relevant for this machine.

Before reinstalling, I plan to follow the tip from sgt-mike :sweat_smile:

I’ll let you know how I get on!! :grinning:

1 Like