Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Grub update stopped 32 bits systems from booting

  1. Back To Top    #1
    Contributing Member
    Join Date
    Aug 2017
    Posts
    73
    Threads
    20
    Local Date
    May 29th 2020
    Local Time
    11:23 AM

    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
    Last edited by pemartins; Apr 11th 2020 at 09:38 AM.

  2. Back To Top    #2
    Contributing Member
    Join Date
    Aug 2017
    Posts
    73
    Threads
    20
    Local Date
    May 29th 2020
    Local Time
    11:23 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:
    ++  if (!(lh->xloadflags & LINUX_XLF_KERNEL_64))
    ++    {
    ++      grub_error (GRUB_ERR_BAD_OS, N_("kernel doesn't support 64-bit CPUs"));
    ++      goto fail;
    ++    }
    ++#endif
    Could it be related?
    Last edited by pemartins; Apr 2nd 2020 at 08:43 AM.

  3. Back To Top    #3
    Ascendant Snowhog's Avatar
    Join Date
    Mar 2007
    Location
    Columbia Heights, MN
    Posts
    20,595
    Threads
    1012
    Local Date
    May 29th 2020
    Local Time
    05:23 AM
    How are you performing your system updates/upgrades?
    "It is a capital mistake to theorize before one has data." - Sherlock Holmes
    Using Kubuntu Linux since March 23, 2007
    Twin Cities Bicycling Club - "And miles to go before I sleep."

  4. Back To Top    #4
    Insert Pithy Nothingness here claydoh's Avatar
    Join Date
    Sep 2005
    Location
    Savannah GA
    Posts
    8,222
    Threads
    228
    Local Date
    May 29th 2020
    Local Time
    06:23 AM
    Homepage: Go to claydoh's homepage
    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.

  5. Back To Top    #5
    Contributing Member
    Join Date
    Aug 2017
    Posts
    73
    Threads
    20
    Local Date
    May 29th 2020
    Local Time
    11:23 AM
    @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.

  6. Back To Top    #6
    Insert Pithy Nothingness here claydoh's Avatar
    Join Date
    Sep 2005
    Location
    Savannah GA
    Posts
    8,222
    Threads
    228
    Local Date
    May 29th 2020
    Local Time
    06:23 AM
    Homepage: Go to claydoh's homepage
    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)

  7. Back To Top    #7
    Contributing Member
    Join Date
    Aug 2017
    Posts
    73
    Threads
    20
    Local Date
    May 29th 2020
    Local Time
    11:23 AM
    @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.

  8. Back To Top    #8
    Insert Pithy Nothingness here claydoh's Avatar
    Join Date
    Sep 2005
    Location
    Savannah GA
    Posts
    8,222
    Threads
    228
    Local Date
    May 29th 2020
    Local Time
    06:23 AM
    Homepage: Go to claydoh's homepage
    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

  9. Back To Top    #9
    Contributing Member
    Join Date
    Aug 2017
    Posts
    73
    Threads
    20
    Local Date
    May 29th 2020
    Local Time
    11:23 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.

  10. Back To Top    #10
    Kubuntu as a Second Language
    Join Date
    Apr 2008
    Location
    Auckland, New Zealand
    Posts
    1,884
    Threads
    68
    Local Date
    May 29th 2020
    Local Time
    10:23 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.
    Regards, John Little

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •