Announcement

Collapse
No announcement yet.

Grub update stopped 32 bits systems from booting

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [SOLVED] Grub update stopped 32 bits systems from booting

    Since the last updates on some grub packages, with the grub installed by Kubuntu I cannot boot 32 bits systems on my pc. No changes were made on the operating systems but now they won't boot, instead I get this error messages when I try to boot:

    Code:
    error: kernel doesn't support 64-bit CPUs.
    error:you need to load the kernel first.
    Press any key to continue...
    The error happens with an Android x86 32 bits distro and other distros based on it like PhoenixOS.

    I believe this log extract maybe contains the offending packages:
    Code:
    2020-03-20 00:46:11 upgrade grub-pc:amd64 2.04-1ubuntu12.1 2.04-1ubuntu12.22020-03-20 00:46:11 status half-configured grub-pc:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:11 status unpacked grub-pc:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:12 status half-installed grub-pc:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:12 status unpacked grub-pc:amd64 2.04-1ubuntu12.2
    2020-03-20 00:46:13 upgrade grub2-common:amd64 2.04-1ubuntu12.1 2.04-1ubuntu12.2
    2020-03-20 00:46:13 status half-configured grub2-common:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:13 status unpacked grub2-common:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:13 status half-installed grub2-common:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:14 status triggers-pending install-info:amd64 6.6.0.dfsg.1-2ubuntu2
    2020-03-20 00:46:15 status unpacked grub2-common:amd64 2.04-1ubuntu12.2
    2020-03-20 00:46:15 upgrade grub-pc-bin:amd64 2.04-1ubuntu12.1 2.04-1ubuntu12.2
    2020-03-20 00:46:15 status half-configured grub-pc-bin:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:15 status unpacked grub-pc-bin:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:15 status half-installed grub-pc-bin:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:17 status unpacked grub-pc-bin:amd64 2.04-1ubuntu12.2
    2020-03-20 00:46:18 upgrade grub-efi-amd64-signed:amd64 1.128.1+2.04-1ubuntu12.1 1.128.2+2.04-1ubuntu12.2
    2020-03-20 00:46:18 status half-configured grub-efi-amd64-signed:amd64 1.128.1+2.04-1ubuntu12.1
    2020-03-20 00:46:18 status unpacked grub-efi-amd64-signed:amd64 1.128.1+2.04-1ubuntu12.1
    2020-03-20 00:46:18 status half-installed grub-efi-amd64-signed:amd64 1.128.1+2.04-1ubuntu12.1
    2020-03-20 00:46:18 status unpacked grub-efi-amd64-signed:amd64 1.128.2+2.04-1ubuntu12.2
    2020-03-20 00:46:19 upgrade grub-efi-amd64-bin:amd64 2.04-1ubuntu12.1 2.04-1ubuntu12.2
    2020-03-20 00:46:19 status half-configured grub-efi-amd64-bin:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:19 status unpacked grub-efi-amd64-bin:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:19 status half-installed grub-efi-amd64-bin:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:20 status unpacked grub-efi-amd64-bin:amd64 2.04-1ubuntu12.2
    2020-03-20 00:46:21 upgrade grub-common:amd64 2.04-1ubuntu12.1 2.04-1ubuntu12.2
    2020-03-20 00:46:21 status half-configured grub-common:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:21 status unpacked grub-common:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:21 status half-installed grub-common:amd64 2.04-1ubuntu12.1
    2020-03-20 00:46:24 status unpacked grub-common:amd64 2.04-1ubuntu12.2
    Using the grub generated by another Linux distro that I have installed it loads without any issues.
    How can I solve this?

    My pc specs:
    Code:
    System:    Host: pemartins-X55U Kernel: 5.3.0-42-generic x86_64 bits: 64            Desktop: KDE Plasma 5.16.5 Distro: Ubuntu 19.10 (Eoan Ermine) 
    Machine:   Type: Laptop System: ASUSTeK product: X55U v: 1.0 serial: <filter> 
      Mobo: ASUSTeK model: X55U v: 1.0 serial: <filter> UEFI: American Megatrends v: X55U.423 
      date: 08/06/2013 
    CPU:       Topology: Dual Core model: AMD E2-1800 APU with Radeon HD Graphics bits: 64 type: MCP 
      L2 cache: 512 KiB 
      Speed: 1205 MHz min/max: 850/1700 MHz Core speeds (MHz): 1: 852 2: 850 
    Graphics:  Device-1: AMD Wrestler [Radeon HD 7340] driver: radeon v: kernel 
      Display: x11 server: X.Org 1.20.5 driver: radeon FAILED: ati 
      unloaded: fbdev,modesetting,vesa resolution: 1366x768~60Hz 
      OpenGL: renderer: AMD PALM (DRM 2.50.0 / 5.3.0-42-generic LLVM 9.0.1) 
      v: 3.3 Mesa 20.0.2 - kisak-mesa PPA 
    Audio:     Device-1: AMD Wrestler HDMI Audio driver: snd_hda_intel 
      Device-2: AMD FCH Azalia driver: snd_hda_intel 
      Sound Server: ALSA v: k5.3.0-42-generic 
    Network:   Device-1: Ralink RT5390 Wireless 802.11n 1T/1R PCIe driver: rt2800pci 
      IF: wlp1s0 state: up mac: <filter> 
      Device-2: Qualcomm Atheros AR8161 Gigabit Ethernet driver: alx 
      IF: enp2s0 state: down mac: <filter> 
    Drives:    Local Storage: total: 465.76 GiB used: 114.05 GiB (24.5%) 
      ID-1: /dev/sda vendor: Seagate model: ST500LM012 HN-M500MBB size: 465.76 GiB 
    Partition: ID-1: / size: 172.91 GiB used: 113.99 GiB (65.9%) fs: ext4 dev: /dev/sda8 
      ID-2: swap-1 size: 3.59 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda6 
    Sensors:   System Temperatures: cpu: 53.6 C mobo: N/A gpu: radeon temp: 53 C 
      Fan Speeds (RPM): cpu: 2600 
    Info:      Processes: 193 Uptime: 22m Memory: 3.44 GiB used: 1.54 GiB (44.9%) 
      Client: Unknown Client: systemd inxi: 3.0.36
    Partition table:
    Code:
    $ sudo sfdisk -l /dev/sda
    
    Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: gpt
    Disk identifier: <filter>
    
    Device         Start       End   Sectors   Size Type
    /dev/sda1       2048    616447    614400   300M EFI System
    /dev/sda2     616448   1845247   1228800   600M Windows recovery environment
    /dev/sda3    1845248   2107391    262144   128M Microsoft reserved
    /dev/sda4    2107392 271038463 268931072 128,2G Microsoft basic data
    /dev/sda5  271038464 493877247 222838784 106,3G Linux root (x86)
    /dev/sda6  944437248 951959551   7522304   3,6G Linux swap
    /dev/sda7  951959552 952676351    716800   350M Windows recovery environment
    /dev/sda8  493877248 801077247 307200000 146,5G Linux filesystem
    /dev/sda9  952676352 976773119  24096768  11,5G Windows recovery environment
    /dev/sda10 903477248 944437247  40960000  19,5G Linux filesystem
    /dev/sda11 801077248 903477247 102400000  48,8G Linux filesystem
    EDIT: solution here:
    https://www.kubuntuforums.net/showth...l=1#post439774
    Last edited by pemartins; Aug 13, 2020, 05:12 PM. Reason: Post solution

    #2
    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?
    Last edited by pemartins; Apr 02, 2020, 02:43 AM.

    Comment


      #3
      How are you performing your system updates/upgrades?
      Using Kubuntu Linux since March 23, 2007
      "It is a capital mistake to theorize before one has data." - Sherlock Holmes

      Comment


        #4
        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.

        Comment


          #5
          @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.

          Comment


            #6
            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)

            Comment


              #7
              @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.

              Comment


                #8
                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

                Comment


                  #9
                  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.

                  Comment


                    #10
                    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.
                    Regards, John Little

                    Comment


                      #11
                      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.

                      Comment


                        #12
                        Try rEFInd?

                        Comment


                          #13
                          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
                          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                          Comment


                            #14
                            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.

                            Comment


                              #15
                              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?

                              Comment

                              Working...
                              X