Announcement

**pemartins** · Apr 02, 2020, 02:18 AM

Any help would be welcome, I already tried everything I could and found on the internet without success. Installed and removed stuff but still no luck, it's like 32 bits operating systems are blocked by the Ubuntu Grub.
In example I tried installing all the Grub related packages on the distro whose boot works just fine in Kubuntu but still the same error message appears and blocks the boot:
error: kernel doesn't support 64-bit CPUs.

Edit: I just found here the following:

Code:

[COLOR=#333333][FONT=&amp]++  if (!(lh->xloadflags & LINUX_XLF_KERNEL_64))
++    {
++      grub_error (GRUB_ERR_BAD_OS, N_("kernel doesn't support 64-bit CPUs"));
++      goto fail;
++    }
++#endif[/FONT][/COLOR]

Could it be related?

**Snowhog** · Apr 02, 2020, 07:56 AM

How are you performing your system updates/upgrades?

**claydoh** · Apr 02, 2020, 09:47 AM

Does your android-x86 OS install its own grub? Phoenix OS seems to do so, at least from the iso image version. If so, have you tried manually selecting it via your computer's appropriate key when powering on (probably the escape key)? Your laptop seems to use UEFI, so this should be the case
How did you install these OSs?
Did you know that Phoenix has 64 bit versions, if that helps? So does the Android-x86 project.
Have you asked around on any of these Os's forums?

It has been a couple of years since I used any Android_x86 installs, I always had to tweak grub to make it boot for me no matter what 'distro' I used, even if I used the Windows based installer for those that had one.

**pemartins** · Apr 02, 2020, 03:29 PM

@Snowhog I update the system on the command line with sudo apt full-upgrade.

@claydoh I installed PhoenixOS from a iso on a usb stick. I usually do not create a grub entry for it because it is unnecessary, I use the one Kubuntu generates so no point in having it just to add more stuff. And then I manually add an entry for it in /etc/grub.d/40_custom and update the grub. Or edit the grub using Grub Customizer.

But the problem is not PhoenixOS or Android x86, it has always booted before that recent grub update and still works with the boot of another Linux distro. The problem is the Grub update on Kubuntu that breaks something.

My laptop does not have sse 4.1 and 4.2 instructions, which are needed for PhoenixOS 64 bits versions to work. Only the 32 bits versions work so I have to use those.

**claydoh** · Apr 02, 2020, 03:53 PM

Allowing it to have its own grub will prevent this from happening, imo. Plus the Kubuntu grub should pick up the android grub, and iirc will point to it (chainloading?), instead of you needing to create/recreate one whenever there is a grub update on Kubuntu.
This also gives you a secondary way to boot to Android if/when something breaks like this. On UEFI, each OS uses its own boot loader, while an OS's grub menu has the possibility of booting a number of OSs.

I am not 100% sure, as it was at least two years back, but when I was running Remix OS ( a sort of precursor to Phoenix) and other similar builds on an old 10" 2-in-1 mini-pc/tablet, I believe I ended up using the uefi menu to boot them, because using Kubuntu's (or any other distros) grub very often would not boot these. That system was an oddball - it had a 32-bit UEFI which alone required some decent hoops initially to get working on on an otherwise 64 bit system. (32 bit *buntus do not have uefi support and this did not have any legacy bios option)

**pemartins** · Apr 02, 2020, 05:20 PM

@claydoh I do not need to create manually a boot entry for PhoenixOS or Android x86 or RemixOS when there is a grub update on Kubuntu, once I create it on /etc/grub.d/40_custom or on Grub Customizer ir stays there forever, it sticks with the updates. That's what makes it so easy to install Android-based OSs, most of the time when I want to try (i.e.) a Remix version I simply copy the Remix files inside the Remix iso to an ext4 partition and add an entry for it to the grub and update the grub.
Actually last month I had on this laptop two versions of PhoenixOS, two versions of RemixOS and one version of Android x86, all booting without any issue at all using the Kubuntu grub. And all of them are 32 bits operating systems and only one of them was installed via usb stick (the one I still have installed).

But like I mentioned it is not much an issue of the operating systems or how they were installed, if it was working before and stopped working after an update the issue is the update. And all still is working fine with the grub created by another Linux OS I have installed on this laptop (MX Linux, Debian based).

How can I roll back to the previous versions of the grub files that were updated? If it starts working again, this way we can be sure the update was the problem.

**claydoh** · Apr 02, 2020, 06:01 PM

I have no idea. You would need to compare the changes between them before and after. And then there will be whatever differences are between the actual bootloader executables built and configured, in the update I think.
As far as I can tell grub (the boot loader itself) itself has not been updated, but I can't 100% verify, as my un-updated 19.10 vm is frozen

**pemartins** · Apr 12, 2020, 05:52 AM

I have a system backup which may be previous to that supposedly flawed update. Which folders should I restore in order to 'remove' the grub updates?
And maybe do a "sudo grub-install" after.

**jlittle** · Apr 12, 2020, 04:05 PM

It may not be the updates to the software itself that has caused your trouble, rather the post-update script has overwritten part of the boot sequence. Reversing the updates may not undo that.

Your problem is a bit like the EFI/BIOS incompatibility. I've not seen, or read about, the error message you get, but grub-pc (the grub that does a BIOS/MBR boot) is 32 bit and grub-efi is 64 bit. The incompatibility is that once booted in EFI mode the computer can't run BIOS images (the BIOS isn't there) and so can't do a "chainload" to another bootloader, which is the way some OS's are booted.

If you can you could download the "Super Grub2 Disk" iso. It's only 20 MB and is aimed at this type of problem.

**pemartins** · Apr 13, 2020, 06:35 AM

Thank you very much for the info about Super Grub2 Disk, it's really one of those must-have tools.

I used it and was able to boot through Kubuntu's grub (I double checked and it was the boot in Kubuntu's partition) using the entry to the 32 bits Android-x86 based OS, the one that displays the error mentioned on this thread. It booted as usual.

But how can I use Super Grub2 Disk to fix the issue? I can boot through it but I could not figure out a way to fix the 32 bits OS issue.

**Don B. Cilly** · Apr 13, 2020, 08:38 AM

Try rEFInd?

**Qqmike** · Apr 13, 2020, 10:41 AM

I second the vote for rEFInd to get booted on a regular basis. To fix things, what about Boot Repair?

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

**pemartins** · Apr 15, 2020, 04:20 AM

That did not go well for me... Boot Repair just added a ton of junk to the boot list, stuff that I removed from the pc years ago; and the repair did not fix anything, unfortunately.

And rEFInd I could not understand its function, I found it to be a... loader of loaders? Each option it displays is nothing but a link to boot lists that already existed in the pc.

**Don B. Cilly** · Apr 15, 2020, 05:20 AM

Well, no, rEFInd is its own boot manager. It doesn't need grub or other boot loaders.
Of course it will display the same boot options. They are what it finds on the PC.

But does it boot your OSs, or does... what?

Announcement

Grub update stopped 32 bits systems from booting

[SOLVED] Grub update stopped 32 bits systems from booting

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment