Ubuntu (Studio) 22.04 LTS

After a restart, my GRUB seems to have been replaced with some other one that defaults to Ubuntu installation process.

GRUB was written on the original installation of this Ubuntu Studio.

This happened after a simple reboot of the machine. No further OS installs have been performed so I cant think of a reason the GRUB would be compromised.

However, I did happen to accidentally kick the makeshift table that the machine sits on, during the previous boot.

There is a selection on the current (wrong) GRUB that says "Boot from next volume" which when selected boots up Windows 10 just fine. And this Win 10 operates just fine.

Ive never had to recover a GRUB and my Linux skills are weak.

Thanks for your time.

Im trying to figure out how to post a photo of my screen..

The correct grub lists Windows 10, two different Ubuntus and a Kubuntu.


Well anyway, the five options in the current grub are:

•Try or Install Ubuntu Studio
I attempted this to try to write a new grub on a different partition, but the install process goes on indefinately listing a bunch of errors along the way.

•Ubuntu Studio (safe graphics)
Same results as above.

•OEM install (for manufacturers)

•Boot from next volume
This option successfully loads Windows 10 everytime.

•UEFI Firmware Settings

The process list (not sure the correct name) while attempting to boot Ubuntu says, so far (6 minutes in):

Starting Set console scheme...
Finished Terminate Plymouth Boot Screen [OK]
Failed to start Snap Daemon [Failed]
Failed to start Snap Daemon [Failed]
Failed to start Snap Daemon [Failed]


I can hear the hard drive working hard

Hi,

Do you know which partitions hold your Ubuntu system??

B

Hi,

Try this first..

When booting, repeatedly press the 'esc' key.
If you are dropped to a Grub menu, press 'c' to obtain the Grub command prompt.

When at the Grub prompt, enter the following.
Drives count from 0, partitions from 1. If you don't know which partition is which, then just repeat the command, starting from 1 and work upwards.
i.e. (hd0,1)/ then (hd0,2)/ and so on.

Here, this produces a directory listing of the third partition of the first (detected) hard drive (assuming that a valid filesystem exists).
Look for the output that indicates a Linux system top level directory structure ('bin', 'boot', 'dev', 'etc' and so on.)

Assuming that (hd0,3) is the required partition. Now enter this:
The system **should** boot properly now. It will boot via the system's local 'grub.cfg'.

**IF** the system boots properly now, then open a terminal and run:
This update will overwrite the existing 'grub.cfg' file with a new one. You may or may not have other OS's detected. This is easy to correct if you need this. Just ask here.

Can you post here exactly what you find please.

B.
EDIT: The commands that are entered at the Grub prompt are transient. If the machine is rebooted **without** fixing the boot problem (reinstall Grub etc.) then these steps will need to be repeated.

Hi,

I forgot to add..

If it turns out that there is a problem with your Ubuntu installation, then just repeat the manual Grub boot from one of the other system partitions..
This should allow you to boot the one of the other Ubuntu's.

B.

Hi, thanks for your time.
Im just getting back to the desk.

I do remember my partitions (the one of query being /dev/sda10)

So I will try it with (hd0,10)/ ...correct?

I'll get started with your instructions in just a sec

Hi,

Try a Grub directory listing of (hd0,10)/ and see what it shows..

I've got a suggestion regarding your multiboot environment which might help a little in the future.. Of course I'll wait until the current crisis is sorted..

B.

IM IN!!! Now talking to you from within the needed OS!

Second attempt, though, because when I rebooted after the first try, the grub problem came back the same. I believe that was my error, mistaking what I thought was my console processes completed.

So here I am in the second attempt, but have not yet rebooted to confirm remedy.

Here's the console's spitout:



[sudo] password for studioworker:
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-52-lowlatency
Found initrd image: /boot/initrd.img-5.15.0-52-lowlatency
Found linux image: /boot/vmlinuz-5.15.0-52-lowlatency
Found initrd image: /boot/initrd.img-5.15.0-52-lowlatency
Found linux image: /boot/vmlinuz-5.13.0-28-lowlatency
Found initrd image: /boot/initrd.img-5.13.0-28-lowlatency
Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi
Found Ubuntu 20.04.3 LTS (20.04) on /dev/sda11
Found Ubuntu 20.04.4 LTS (20.04) on /dev/sda7
Adding boot menu entry for UEFI Firmware Settings
done

Patiently on standby for further instruction.

Thanks so much for your time thus far

Im going to reboot to verify remedy. brb

Hi,

Glad to hear that you are making progress..

A couple of points to mention, as you appear to be using a standard multibooting setup.

For Ubuntu's (and derivatives) there is an initial 'grub.cfg' within the ESP partition. The full path from a running system is '/boot/efi/EFI/ubuntu/grub.cfg'. This 'grub.cfg' points to the target installations local 'grub.cfg' (at '/boot/grub/grub.cfg'). The partition is identified by its filesystem UUID.
It **is** possible for this UUID to be pointing at the wrong filesystem.. The local 'grub.cfg' here then points somewhere else. All good fun where one systems Grub installation is used to start a kernel on a different filesystem.

More later..

B.

Not remedied. Running the commands again

SHUUUUX Maybe its sda11...not 10 �� brb!