Boot Problems With Linux Lite

[mdiemer]

I recently installed Kubuntu on a HDD that has Linux lite 4 on it. I have been very impressed with Kubuntu and have been using it the past week or so. Today I tried booting Linux Lite, and it would not boot. It almost does; I see the little circle going around, and then I get a bash shell. Nothing after that.

I tried the Boot Repair Disc to solve this, but unfortunately that resulted in Kubuntu also not being able to boot. I then installed Kubuntu again. I did the default option, to carve the existing Kubuntu partition in order to make room for the new install. It boots fine. I can also now boot into the first Kubuntu install from that grub. However, Linux Lite still won't boot.

So, now I have two KB installs, which both work. I would like to get back to having my first KB install, and get rid of, or drastically shrink, the new KB install, since I don't need it. Except, maybe I do, in order to boot into the new KB?

What would be the best way to proceed? M y goal is to have both KB and LL on the drive, and working (obviously).

Thanks,

Mike

[GreyGeek]

The "almost does" is probably one of two possibilities: the easiest one is that you tried to do something in your home account as root and the ~/.Xauthority file got owned by root, which prevents you from using it and prevents the display from being created. If it is owned by root:root change it back to yourname:yourname. The second possible problem is that your video driver is misbehaving for some reason. If ~/.Xauthority is owned by you then the video driver is probably the problem. Reinstall it.

More than likely your second installtion of Kubuntu overwrote Linux Lite. Just a guess. Did you carve out a third partition to install it on?

[jlittle]

A possible cause is UEFI vs BIOS mode, are you aware of that issue? If the Linux Lite install uses BIOS mode, aka "Legacy mode", and you booted the Kubuntu install medium in UEFI mode, you'd get this problem. If booted in UEFI mode, you can't run BIOS executables and vice versa. Though UEFI usually goes with GPT partitioned drives, and BIOS with MBR, one can use BIOS with GPT.

When one boots from an install medium, it's not always obvious which mode is used; it depends upon the motherboard. With some there are two boot choices (with unobvious names), and some there's a setting.

[jlittle]

I tried the Boot Repair Disc...

Last time I looked, it didn't know about UEFI.

[Qqmike]

It lists UEFI in this capability list:
https://sourceforge.net/p/boot-repair/home/Home/
but I am thus far unable to locate any tutorial or screen shots using it.

[mdiemer]

Apologies for forgetting to give you my computer specs. Here they are:

Gateway GT5656
AMD Athlon 64 X2 6000+
6150SE motherboard
Nvidia 8400GS video card
Seagate HDD 500GB

GreyGeek: When I installed the second Kubuntu, I chose the default option, which was supposed to leave Linux Lite intact. The Before and After showed LL on partition 1, the old KB on 5, and the new KB on 6 (both are subsets of partition 2, however). As for video driver, I am not sure if I have LL on Xorg or Nvidia. I usually leave things alone until there's a problem, then I switch it to Nvidia. I do however have both KB's on Nvidia as this works better with KDE on this computer. Not sure about the root thing.

jlittle: this mobo is bios only.

[mdiemer]

If I do sudo grub-install while on the original Kubuntu install (the one I want), will that cause grub to be owned? So that it will be the first entry in grub? That would at least be a step in the right direction. I am hesitating to do it because my previous attempts met with disaster (although that involved the Boot Repair Disc). Seems like that should work. What do folks think?

[Qqmike]

If I do sudo grub-install while on the original Kubuntu install ...

In theory, you should be OK doing that. Gosh, it's been too long since I used GRUB2 (I've been using the GRUB2-UEFI stuff instead). As I recall, after grub-install, you need to generate a new GRUB boot menu. Here's a clip from my GRUB2 how-to (from Section 3):

Key commands: sudo grub-mkconfig and sudo grub-install
Use these two commands to "freshen up" your GRUB 2 installation.
grub-mkconfig: builds a new boot menu configuration file boot/grub/grub.cfg.
grub-install: builds a complete, fresh GRUB 2 installation, including /boot/grub/grub.cfg.

grub-mkconfig (See the comment at the very beginning of this how-to regarding grub-install.)
grub-mkconfig ) [Don't worry about that comment]

grub-mkconfig will generate a new boot menu /boot/grub/grub.cfg. To do so, it uses /etc/default/grub and the scripts in /etc/grub.d. You should run this command after editing the default file or the scripts:
sudo grub-mkconfig -o /boot/grub/grub.cfg
or
sudo grub-mkconfig --output= /boot/grub/grub.cfg
See Post #2 (to this post): Notes about some of the new GRUB 2 commands
You should also run grub-mkconfig after running grub-install.

sudo grub-install [INSTALL_ DEVICE]
installs or re-installs GRUB 2 to INSTALL_DEVICE.

See SECTION 4: grub-install: A key command
For now, here's some highlights.

sudo grub-install /dev/sda
installs GRUB 2 to the Master Boot Record of drive sda. And
sudo grub-install /dev/sda1
installs GRUB 2 to the boot sector of the partition sda1.
In doing so, grub-install does a complete job of setting up everything.
Here's what it does: It builds the directory /boot/grub (if it doesn't already exit), copies GRUB 2 files to it from the "master" image directory /usr/lib/grub/i386-pc, probes your drives and devices and partition table, makes a new device.map, builds and installs boot.img (to MBR) and core.img, and builds /boot/grub/grub.cfg. -->>> But it does not run grub-mkconfig; so you should do so after running grub-install to build a new grub.cfg file.

> Man page: (8)GRUB-INSTALL - Install GRUB on your drive.
http://grub.enbug.org/FranklinPiat/grub-install.manpage

Troubleshooting
-- After running grub-mkconfig, make sure that the line set default=(hdx,y) in grub.cfg is correct (i.e., that the order of the menuentries did not change the default OS position).
-- sudo grub-install --recheck [INSTALL_DEVICE]
=> If you get an error running sudo grub-install, try it again with sudo grub-install --recheck [INSTALL_DEVICE].

For you, you have one hard drive sda, so you'd install GRUB to the Master Boot Record (MBR) of sda:
sudo grub-install /dev/sda
and then do:
sudo grub-mkconfig -o /boot/grub/grub.cfg

(Note the spaces: space after grub-install; space after mkconfig; space after -o (lower case letter "oh").)

GRUB 2 A Guide for Users
https://www.kubuntuforums.net/showth...l=1#post193705

[mdiemer]

Thanks for that great info, Qqmike. I will try that soon, but first I need more clarification. I usually run the <sudo grub-istall> command, and then <sudo update-grub>. I have never run the <sudo grub-mkconfig -o /boot/grub/grub.cfg> command. What is the difference between that <sudo update-grub>?

[Qqmike]

At one time, perhaps circa 2009, the two commands were competing for mainstream attention; from my how-to:

update-grub VERSUS grub-mkconfig
The command update-grub generates a new grub.cfg file and replaces the existing grub.cfg with the newly generated grub.cfg (by default).
But, you must specify the output file when using grub-mkconfig:
sudo grub-mkconfig
prints its output to the screen (default = stdout).
To print to the grub.cfg, use
sudo grub-mkconfig -o /boot/grub/grub.cfg
or
sudo grub-mkconfig --output=/boot/grub/grub.cfg

But I think you are right -- you can simply use sudo update-grub (which is what we use in the newer UEFI systems). The mkconfig requires arguments, and may be outdated (although I am sure it would also work--and it would be good when you do wish to control where the new grub.cfg gets written to, like maybe when using a separate dedicated GRUB partition).

So, yes, go ahead and use your update-grub command.

[mdiemer]

The problem solved itself. I just booted up and saw there were some updates. Four of them concerned grub. I went ahead and did them, and now my original KB 18 is the default boot. So that problem is solved.

Now, I need to jettison the other KB 18. Can I just delete its partition, and then resize the other KB? Or would doing so somehow mess up the new grub?

Another question I have always wondered about: where exactly is grub on the hard drive? If I knew, I could safely use the partitioner without worrying about removing needed features like grub.

Thanks, and thanks to the KB team for the update which solved the grub problem. A donation will be headed your way for this fantastic operating system.

Addendum: more good news. I fooled around in the bash that I get when I try to boot Linux Lite, and discovered there were errors in the file system. I ran <fsck /dev/sda1> as advised, and it corrected them. Linux Lite now boots. So now all I have to do is get rid of the extra KB install,and I will be home free.

[Qqmike]

Now, I need to jettison the other KB 18. Can I just delete its partition, and then resize the other KB? Or would doing so somehow mess up the new grub?

Yes, you can delete that partition and re-size the other one. That should not mess up GRUB in any way whatsoever.

where exactly is grub on the hard drive?

From my old original GRUB how-to:

A sector of a hard drive or flash drive is 512 bytes (one byte = 8 bits). Think of a byte as the space required to store a character--a number, a letter, or a symbol. The first sector, 512 bytes, of a hard drive is reserved for the Master Boot Record (MBR). The MBR is divided as follows: 446 bytes are used for the bootloader's Initial Program Loader (IPL), which is the basic “starter” code for the bootloader; then 64 bytes are set aside for the partition table (4 primary partitions, each getting 16 bytes); and finally a 2-byte signature code (hexadecimal 55 AA = end of MBR).

When GRUB is installed, it installs its Stage_1 code into the MBR (into the 446 bytes for the IPL). It also installs its Stage_1.5 code in 16 sectors following the MBR but preceding the start of the first partition. Finally, Stage_2 of GRUB is located in the Kubuntu/Linux root partition, along with the GRUB boot menu, /boot/grub/menu.lst. In Kubuntu, you can see the GRUB files by opening (in Dolphin or Konqueror) /boot. There you can open the grub directory and you'll see the GRUB files. (The kernel and initrd files are located in the /boot directory.) The original GRUB files provided with you Kubuntu OS can be found in the “image” directory: /usr/lib/grub/i386-pc.

https://www.kubuntuforums.net/showth...ethods-Toolkit

If I knew, I could safely use the partitioner without worrying about removing needed features like grub.

You can normally do any partitioning work you'd like to do without messing up GRUB2. (Now, if it is GRUB2 for UEFI, then you should NOT ever mess with the special partition called the ESP: EFI System Partition, which is usually sda1 but can be any designated partition--not to worry though, because you will always know what partition your ESP is.)

For the older, non-UEFI GRUB (legacy), you do not ever want to mess with your MBR--the first 512 bytes of your hard drive. It is not a partition. It is simply a reserved sector of the hard drive. How would you mess it up? Well, it should never occur! But some people (like myself) may wish to play around with utilities like the dd command, which will write zeroes or anything you want to that MBR-reserved area, and thus wipe it out. But who would do that? Only people who are goofing around, experimenting, perhaps to see if they can restore the MBR.

Also, if you shrink a partition, it is common sense: don't ever shrink it smaller than the data on the partition! If your OS/data is using 50 GB of a partition, naturally you don't want to shrink that partition to 40 GB (because, of course, then you might destroy GRUB and a bunch of other stuff as well).

To do partitioning work, I always use GParted Live CD/USB, fwiw. It is safe, tested, and easy to use. You can burn it to a CD, or make a live USB flash drive with it.
https://gparted.org/livecd.php

[Qqmike]

GParted Live CD/USB has a how-to manual:
https://gparted.org/display-doc.php%...ed-live-manual
And that manual would also be useful if you are using the KDE partitioner that comes with Kubuntu (some details and menus would differ, of course, but the concepts and the steps involved in doing partitioning would be about the same).

The problem solved itself. I just booted up and saw there were some updates. Four of them concerned grub.

Yes. Upon getting those GRUB updates, your system ran grub-install and update-grub and freshened up your GRUB files and GRUB installation. You can also, still, do that yourself with those two commands, as we discussed above.

[Qqmike]

Btw, back to Post #12 ... If you do delete a partition containing an instance of Kubuntu, you then might want to boot into your remaining "good" Kubuntu partition and regenerate the GRUB grub.cfg file, the boot menu, IOW. To do so, use the sudo update-grub. That way, the boot menu you are using will be current and not contain a reference to a killed Kubuntu partition, if that makes sense.

[mdiemer]

Thank you for that very detailed feedback, Mike. I now feel confident to delete the new KB install and resize the "good" KB install. Also for all the work you have done on educating folks about grub. I knew some of that info about the MBR being at the start of the partition, but had forgotten it. But your refresher was just what I needed.

Incidentally, it looks like this whole thing started because Linux Lite had some errors in its file system, which prevented it from booting from Kubuntu's grub loader. Which caused me to use the Boot Repair Disc, which in this case made things worse. I should have done more research. The key was to work with the bash which was provided when LL refused to boot. When I figured out how to do that, it booted fine. This whole thing could have been prevented if I had had more patience!