OS boots to grub

[bubba]

I installed kubuntu and it worked well for several days. I installed Jellyfin media center and it also worked well. I didn't install anything else and now, today upon a reboot I end up at a grub prompt. I tried reading through journalctl but I don't know enough to be able to do anything about what I read. Any help is really appreciated.

[Snowhog]

Welcome to KFN.

Are you presented with the Grub Menu when you turn on your PC?

[bubba]

Snowhog, No, I have a grub menu. I have a SSD partitioned and have three other Linux OS installed on the other partitions. Every one of them has worked correctly for months and after installing Kubuntu everything still worked correctly. Now at the grub menu I can select any of them and they all boot except Kubuntu. One other thing to mention, the other three OS's all share the same /HOME folder on a separate 1TB hdd, Kubuntu's ?HOME folder is on Kubuntu's partition. I hope the added information can help.

[Snowhog]

So from the Grub Menu, select Advanced options for Ubuntu and press Enter. On the next screen, choose the first (recovery mode) kernel and press Enter. You will eventually be presented with a Recovery Menu (filesystem state: read-only).

Down arrow to root and press Enter. You'll be prompted to Press Enter for maintenance (or press Control-D to continue): Press Enter and you'll be logged in as root.

Type df -hT --exclude-type=tmpfs --exclude-type=devtmpfs and press Enter.

Note how much of the space for the root partition has been used (Use%). If it is 95% or more, you have a space available problem that needs to be dealt with.

To restart from this prompt, type: shutdown now -r and press Enter.

[bubba]

@Snowdog: Doing as you suggested didn't return what was expected. If this link works it shows my screen: https://i.postimg.cc/PxPZfnN1/kubuntu.jpg

df returns "no file systems processed
executing df -h returns "/dev/sda5 69G 17G used 49G available 26% used mounted on /

Does this help at all?

[claydoh]

have three other Linux OS installed on the other partitions

can select any of them and they all boot except Kubuntu.

As you have multiple OS installed, each one actually has its own grub boot loader. Which one you get depends on which one is set as the first boot device in your bios.
You can change this settings, or use your bios boor menu hot key when booting to select a different one.

But it will, be a lot easier to make sure to update Grub in each other Linux installation so the other boot loaders will see the newly installed Kubuntu, and add it to their menus.

[bubba]

@claydoh Thanks for your suggestion, I will execute "update-grub" from within a terminal while in each OS

[bubba]

@claydoh, using the grub menu I booted each OS, then while within each I executed "update-grub". Once I did this for every OS I rebooted once more and selected Kubuntu from the grub menu. Nothing has changed. I'm dropped to a terminal with the message that I execute 'journal -xb" or reboot.

[claydoh]

so, have you tried changing the boot order in your bios to a different option? Each OS has a completely different boot loader/grub, and maybe the one you are using is broken, and a different one is fine.

[Snowhog]

@Snowdog: Doing as you suggested didn't return what was expected. If this link works it shows my screen: https://i.postimg.cc/PxPZfnN1/kubuntu.jpg

df returns "no file systems processed
executing df -h returns "/dev/sda5 69G 17G used 49G available 26% used mounted on /

Does this help at all?

The image is helpful. The command I had you type isn't what you typed. That's why you got the "no file systems processed" message.

Commands are case sensitive. Spaces matter.

What you typed:
df -ht-exclude-type-tmpfs --exclude-type=devtmpfs
What I said to type:
df -hT --exclude-type=tmpfs --exclude-type=devtmpfs

Your root partition isn't near being full, so we've ruled that possibility out. Try claydoh's suggestion (post #9).

[bubba]

The bios for my older HP desktop maybe doesn't have the options that are being suggested in changing the BOOT Order. I took a pictures of the bios screens, they can be seen here: https://postimg.cc/gallery/zGND4xP. Or I just don't understand what's being suggested.

[bubba]

Without any other options I will re-install kubuntu. Any suggestion in the re-installation that may help prevent this experience again?

[claydoh]

The only thing I can see from your screenshot is your computer may be booting both EFI and in Bios (legacy) mode, you never did mention if you tried botting any of the other drives shown in the boot menu.
if you nuke and pave, you probably need to make sure you are booting in EFI mode for each OS - you may be able to disable legacy in the Bios, but as Ubuntu isos can boot in both modes, it may be safest to boot the USB stick using the boot menu hotkey, instead of letting it boot automatically (and thus probably in Bios mode)


In Legacy mode, which uses the old MBR, installing a new os overwrites the existing boot loader - and there can only be one.
In EFI, each OS has its own separate boot loader, stored in an EFI partition, and multi booting with this is usually a much simpler process.

[jlittle]

...using the grub menu I booted each OS, then while within each I executed "update-grub".

This means each install is fighting for control of the boot, and the winner is the last one to update. If they all work and all give access to the other installs always, that works, but it's fragile. IME that always screwed up sooner or later.

If you can choose one of the installs to be designated to be the one in control of the boot, perhaps because you expect it to be the longest lived, then I suggest you do that, and stop the others from interfering.

This can be done simply by uninstalling grub from the other installs, but you might worry what happens if the designated control install fails. An alternative is in the non-controlling installs to install the package grub-efi-amd64-bin, which does not automatically update, but still can if you run update-grub manually.

For a new install, to stop it from messing with the boot, it's awkward but you can run ubiquity with the -b option in a konsole.

In the long run, if you're the type of user who likes to try out multiple installs, I think you would suit well:

1. Manually maintaining grub.cfg; it can be drastically simplified and not need attention at all unless you make a new install.
2. Using btrfs, where one can have several installs in the same file system, neatly separated into different subvolumes. This eliminates the need for shuffling partitions about, and estimating sizes, as the spare space is pooled; IME a huge time-saver. One can easily move installs from other partitions into a btrfs subvolume by copying everything and adjusting grub.cfg and the /etc/fstab in that install. Note that this requires a bit of 1. here because the grub os prober does know how to look into a btrfs to find installs (there's been at least talk of this). But if you use /boot/grub/custom.cfg the manual maintenance is minimized.

[Qqmike]

There is also the rEFInd boot manager
https://www.rodsbooks.com/refind/

There are also ways of clearly identifying various 'ubuntu's, then using efibootmgr to manage them ...