[SOLVED] Older desktop boots directly to Win10 after successful Kubuntu install

[Frank616]

Same issue as another poster here that did not come back for an answer. "I'll be bock"!

Fresh 18.04 install on a new Samsung EVO 500 GB system disk. In boot, the sda system disk is skipped over, but the mechanical sdb with Win10 is seen, and it boots from that.

Machine is an older Lenovo ThinkCentre TW 4524 Core i5. It has 3 drives with sda1 being the boot drive (EVO 500 GB that I just installed), an older Hitachi mechanical drive with Windows 10 only, and a 2TB WD mechanical data drive.

Machine works fine with the previous Kubuntu 14.04 install on a 250 GB Samsung EVO SSD mounted in a removable drive bay. WILL NOT boot to the newly installed 500 GB drive with Kubuntu 18.04 freshly installed. Skips right by it in the boot process.

The BIOS boot sequence is set to Auto, which means that it will boot either legacy or UEFI depending on what it finds in the boot order. I don't remember whether the 14.04 system disk is UEFI or Legacy, but it works. I'm using it now to post this.

Machine boots from the USB stick in UEFI mode, which is what I used to install 18.04 with. Also boots from the Win10 disk, which is an old Win7 install that I got the free upgrade on. It is on the original disk that this machine was originally built with.

In an effort to troubleshoot, I took the Win10 disk out of the boot order altogether using the BIOS options. Now the BIOS complains that there is no boot device.

Bad 18.04 install? I dunno. I can't even get into 18.04 to run update-grub.

Suggestions?

[jlittle]

Fast boot? Windows 10 power off may not be a shutdown. I think you have to turn off fast boot in windows, then shut it down, before the machine will let you boot into something else. After shutting windows down properly, turn off fast boot in the UEFI settings.

Regards, John Little

[Frank616]

John: I'll have a look at that, but I suspect not. As mentioned, it works fine with 14.04. I am thinking that my 18.04 install may be faulty. It should be recognized as a boot device.

Thanks.

Frank.

[SpecialEd]

Have you tried opening a console and entering:

sudo os-prober
sudo update-grub

[Frank616]

I guess I am not understanding something. If the 18.04 disk won't boot -- even to a console -- how would I do that?

The issue is that the new 18.04 disk is not seen by the BIOS as having a bootable image, and is therefore skipped during the BIOS boot process.

Anyway, I'm re downloading the iso image, and will create a new USB flash drive, and try installing again. It may be just a failed install.

Frank.

[SpecialEd]

I guess I am not understanding something. If the 18.04 disk won't boot -- even to a console -- how would I do that?

The issue is that the new 18.04 disk is not seen by the BIOS as having a bootable image, and is therefore skipped during the BIOS boot process.

Anyway, I'm re downloading the iso image, and will create a new USB flash drive, and try installing again. It may be just a failed install.

Frank.

Opps, I got it backwards, Windows booting as opposed to Linux booting. Disregard!

[GreyGeek]

During boot up if you hit F11 (or F12?) a boot menu will come up. Can you see that sda1 from that boot menu? If so, and you select it, does it boot then?
Also, does the SSD have the boot flag set on it?

[Frank616]

Greygeek and others:

OK, now I've got a mess... :-(

This is an older machine that had Win7 on it when I got it. I installed an SSD and installed Kubuntu 14.04. It worked. I upgraded to Win10. It continued to work. However, I have no idea where grub put the boot loader, whether on the Win10 disk, or the SSD.

I replaced the working SSD with 14.04 on it, and successfully ran the machine again. I downloaded the 18.04 iso, and used 14.04's Startup Disk Creator app to create a bootable flash drive. That too worked. However, the flash drive will ONLY boot in UEFI mode, so that is what I used to install 18.04 to a new 500 GB totally blank and unformatted SSD. This install goes most of the way through, but at the end I get a message: "The 'grub-efi-amd64-signed' package failed to install into /target/. Without the GRUB boot loader, the installed system will not boot."

And, sure enough, it will NOT boot no matter what I do. I took the Win10 disk out of the boot order in the BIOS. I even disconnected the Win10 disk. No change.

So, I think I am messed up as to which disk the machine wants to boot from, and whether it wants to do it in UEFI or in Legacy.

Where to I start?

Let me boot from gparted and see if the boot flag is set on the new SSD. Both SSD's are mounted in removable drive caddies, so I have to pull one to have a look at the other. Give me a few minutes...

Frank.

[Frank616]

Greygeek:

OK, the NEW SSD is indeed formatted for UEFI boot, and the flag is set. See attached picture. The second picture is a screenshot from the 14.04 SSD, which is formatted Legacy, it would appear.

BIOS on the machine is set to Auto, which says it will boot from either. However, that is not happening.

Man, what I had to do to even get GParted to boot! I have a 4K monitor on this machine connected HDMI. I finally figured out that I had to boot it in safe mode to get it to work... (after connecting an older VGA monitor, and trying that in both digital and analog outputs...)

Anyway, back to you.

[Qqmike]

I just came in on this, only quickly skimmed the posts, not sure what a "solution" will be, but in my opinion Frank616, it is not good practice to mix things: looks like you have UEFI booting mixed with Legacy/MBR booting; and GPT mixed with MBR. Rod Smith is the expert on "exotic" booting configurations, and I'm gonna guess he would adamantly advise against this kind of mix up. Just a sample of such issues and his thinking (on his extensive site):

https://www.rodsbooks.com/gdisk/bios.html
http://www.rodsbooks.com/efi-bootloa...-bad-ugly.html

I realize this post is not helpful, but it's getting late here. In the other thread that you mentioned about similar problem, I posted some ideas including what can be done from live Kubuntu USBs/DVDs, like making a rEFInd CD (Rod Smith is the author of that) ... but, that would mainly be useful for UEFI booting only. You can also re-install GRUB from a live USB/DVD (links are given in that other thread), or make a Boot repair CD (in a live session) and use that. Of course, this all assumes you can boot your BIOS/firmware to the live USB/DVD, which I notice you did boot the gparted. As I say, this is not helping much.

Btw, this message:

"The 'grub-efi-amd64-signed' package failed to install into /target/. Without the GRUB boot loader, the installed system will not boot."

That usually means that the installation can not see the ESP you intend to use for GRUB in a UEFI installation. I see an ESP, sda1, on your first attached screen shot, for example.

[claydoh]

"The 'grub-efi-amd64-signed' package failed to install into /target/. Without the GRUB boot loader, the installed system will not boot."

I think this happens if there is no internet connection available and/or enabling updates during the install, though the package is on the disk, I think. (Or if there is no efi partition when setting things up) manually

https://bugs.launchpad.net/ubuntu/+s...d/+bug/1780897
https://bugs.launchpad.net/ubuntu/+s...2/+bug/1778848
https://bugs.launchpad.net/ubuntu/+s...r/+bug/1767508
among many others

Are you using the 18.04, or the 18.04.1 iso? It is here, just in case the fixes have made it to the new iso:
http://cdimage.ubuntu.com/kubuntu/re...ktop-amd64.iso

[Frank616]

Qqmike:

Sadly, it is the installer that insists on doing it UEFI from the flash drive. It won't allow me to legacy boot it. I get an error: gfxboot.c32: not a COM32R image. It WILL boot in UEFI mode, but of course, that is why the new disk gets installed as UEFI bootable. My 14.04 install is NOT UEFI.

I seemed to be getting around the issue by abandoning the flash drive for installation and going back to a good old DVD. THAT I can boot in legacy mode. However, I have spent the past 4 hours trying to get it to complete. The installer complains about a bad DVD exactly 75% into the file copying stage. I burned another DVD with copy verification enabled to make sure it was a good burn, same thing. I used a different DVD drive to install from (same external HP burner I created the DVD with), same thing.

I'm getting pretty tired of this. Very frustrating evening.

Tomorrow I'll go get another DVD burner / drive and install it in this machine and see if that resolves it.

The downloaded iso image checked out with the hash sum, so it has to be good.

If all else fails, I'm going to try to install 16.04 and do an 'in place' upgrade.

[claydoh]

Also, the iso should be able to boot in either mode, has been for a while, actually. My older HP desktop's and my old Dell laptop boot menus will show the USB stick under both the EFI Boot section, and the Bios Boot section they have, and either one works for me. Make sure you use a good usb stick tool such as etcher.io, rosa image writer, or Rufus in Windows. Unebootin and the old USB Creator in Ubuntu are not so good these days, if that is what you are using.

[Qqmike]

the iso should be able to boot in either mode,

I think so, too. In my how-to about building a new PC and installing Kubuntu, I wrote this:

Configure UEFI (BIOS)

Turn on the PC, at the POST press the key (F2) to enter UEFI(-BIOS).
CSM (compatibility support module): set to Auto (default).
Disable Secure Boot: Change to “Other O/S”, which disables Secure Boot for the ASUS UEFI. Disable Fast Boot.

However, for you, you have Windows, so you should not turn off secure boot.

And then this:

Install the Kubuntu OS in UEFI mode
--> Must be 64-bit Kubuntu OS for UEFI. I am using Kubuntu 14.04, 64-bit.

Important: You must make certain you are installing Kubuntu in UEFI mode.

I used a Live DVD Kubuntu installer.
Install the DVD in the optical drive, reboot the PC, enter UEFI(-BIOS) by pressing F2.
Under Advanced, find the ASUS boot menu, and the "boot override" menu under that.
The bootable devices will be listed.
Choose the one that corresponds to the Kubuntu UEFI choice.
Look for UEFI / FAT) or some reference to UEFI.
My Live Kubuntu DVD installer showed up twice in UEFI BIOS (under Boot Override) as a "normal" DVD writer, and also as:
UEFI (FAT) TSSTcorp CDDVDW SH-224DB (1028 MB) (= my Samsung DVD player).
Found out you may have to re-boot a time or two for this to appear correctly, so I think.
Select that option from the boot override menu.
The PC will re-boot, and you will see a text mode screen with a grub-like menu. Select install O/S. If, instead, you see the full graphical setup menu, the installer is probably in legacy BIOS mode so reboot, enter the UEFI setup, navigate to boot override and try again.

So for you, you would look for your DVD listed without any mention of any UEFI or EFI. That then would be your legacy choice, your non-UEFI choice. In fact, some people have problems because they can't install Kubuntu in UEFI mode! They keep choosing the normal-looking, older legacy mode-description of their DVD! EDIT: Or ... their computer--their Firmware-BIOS--keeps defaulting to the legacy choice automatically. We've seen that happen here at the forum.

(Ref.: on that how-to: https://www.kubuntuforums.net/showth...l=1#post368216 )

[Frank616]

SOLVED

There is a bug in the 18.04 installer that is specific to older machines installing 18.04 on a machine with Win10 upgraded from Win7. See message 8 in the following thread:

https://ubuntuforums.org/showthread....llation+failed

Win7 was originally on this machine, and it booted in legacy mode. Therefore the Win10 in place upgrade is installed in legacy mode as well. Therefore, Kubuntu 18.04 has to install in legacy mode. It just simply WOULD NOT on my machine.

While there are a dozen esoteric solutions involving disk partitioning, GPT disks, and a whole lot of other stuff, I found an easy way: Install 16.04, which deals with the legacy Win10 install with NO PROBLEM. Then do an 'in place' upgrade to 18.04. Slow, and one has to update the 16.04 install to 16.04.5 first, but everything is automatic after that. And, after all, that is what computers are for: let the machine do the dam*ed drudgery, not me!

THAT worked!!