Bugzilla – Bug 1218104
Grub boot error with Xen - "null src bitmap in grub_video_create_scaled."
Last modified: 2024-02-01 06:43:34 UTC
openSUSE Leap 15.5, with Xen hypervisor does not boot, gives error: "error: ../../grub-core/video/bitmap_scale.c:42:null src bitmap in grub_video_create_scaled." I have removed all the obvious things e.g. splash with a grub cmd command line options only containing: "preempt=full mitigations=auto" The ordinary kernel boots without any problems. It also boots with "splash=silent quiet" i.e. video output on the display. It was a new install a time ago of 15.4 (did not work there either. I hoped it would go away in 15.5) and was later upgraded to now 15.5. It is an efi boot (uefi bios) from sdb1 /dev/sdb1 2048 1435647 1433600 700M ef EFI (FAT-12/16/32) Virtualization is enabled in BIOS. The computer has booted openSUSE with Xen in earlier openSUSE version, e.g. from 13.X, 42.X. And run VM guests. I also have done diff -r of /boot/grub2 with another box with same configuration that works. No significant diffs. The only "historic" diff is that that the working Xen computer was upgraded starting from 13.X to now 15.5, e.g. NO new install of 15.X. Both use btrfs, have the same boot part sizes/layout, but the problem Xen box has boot part as "msdos" and the upgraded one "gpt" ... The hardware of the boxes differ however... I have searched the web and noticed some others having similar problems, but found no solutions yet. Does anyone have any idea? Why does ordinary 15.5 without Xen boot and not with Xen? Where might the "missing" bitmap be mentioned in error:?
I am on it!
(In reply to Jaan Haabma from comment #0) [snip] > Why does ordinary 15.5 without Xen boot and not with Xen? The error is consistently set but not immediately presented to the user. It can potentially be overridden by subsequent code if it decides to disregard the 'grub_error' return by a function by resetting it to restore a healthy state. This behavior might vary well depending on the execution path of the code. > Where might the "missing" bitmap be mentioned in error:? The error turned out to be a false alarm regarding a missing background image. However, since we utilized colors instead of images for the background, it had no impact, and we can safely disregard it In /boot/grub2/themes/openSUSE/theme.txt: > desktop-color: "#0D202F" I am working on the patch and will provide test package later.
Hi Jaan, Here is the repo url for the test package of grub2, could you please help to verify it ? https://download.opensuse.org/repositories/home:/michael-chang:/bsc:/1218104/standard/ If you have secure boot enabled, either you have to disable it, or you have to enroll my home project's key to entrust it. The public key is packaged under /usr/share/efi/x86_64/grub.der and you can enroll it to the MOK (Machine Owner Key) via mokutil. mokutil --import /usr/share/efi/x86_64/grub.der FWIW, here is the patch: https://build.opensuse.org/package/view_file/home:michael-chang:bsc:1218104/grub2/0001-gfxmenu-Resolve-false-grub_errno-disrupting-boot-pro.patch?expand=1 Thanks.
Hi Michael, Thank You for the patch! It seems to require a newer libc than included in Leap 15.5 which I am using, i.e. 2.33 (to be for Leap 15.6 ?) instead of the default 2.31 (Leap 15.5). Do you have an updated binary x86_64 libc (2.33) that I can download ? Or do you recommend me to build a new one from the GLIBC source ? Or can you rebuild the patch with libc 2.31? tigerlily opensuse/1218104# zypper install -D ./grub2-2.12~rc1-23.1.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides 'libc.so.6(GLIBC_2.33)(64bit)' needed by the to be installed grub2-2.12~rc1-23.1.x86_64 Solution 1: do not install grub2-2.12~rc1-23.1.x86_64 Solution 2: break grub2-2.12~rc1-23.1.x86_64 by ignoring some of its dependencies Best regards, Jaan
(In reply to Jaan Haabma from comment #4) > Hi Michael, > > Thank You for the patch! > > It seems to require a newer libc than included in Leap 15.5 which I am > using, i.e. 2.33 (to be for Leap 15.6 ?) instead of the default 2.31 (Leap > 15.5). > Do you have an updated binary x86_64 libc (2.33) that I can download ? > Or do you recommend me to build a new one from the GLIBC source ? > Or can you rebuild the patch with libc 2.31? > > tigerlily opensuse/1218104# zypper install -D > ./grub2-2.12~rc1-23.1.x86_64.rpm > Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: nothing provides 'libc.so.6(GLIBC_2.33)(64bit)' needed by the to be > installed grub2-2.12~rc1-23.1.x86_64 > Solution 1: do not install grub2-2.12~rc1-23.1.x86_64 > Solution 2: break grub2-2.12~rc1-23.1.x86_64 by ignoring some of its > dependencies Sorry for the trouble. I was mistakenly providing openSUSE Tumbleweed repository for you. Now I have enabled the build for Leap 15.5 and you can download the packages from: https://download.opensuse.org/repositories/home:/michael-chang:/bsc:/1218104/15.5/ Again thanks a lot for your patience.
Hi Michael, Thank you for the updated patch! Sorry to bother you again ... but ran into a new problem. This patch seems to require a new "grub2-i386-pc" package. This probably might not be needed since I run a 64bit box, but an old one is however installed as default. See below. tigerlily opensuse/1218104.2# zypper install -D ./grub2-2.12~rc1-lp155.23.1.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides 'grub2-i386-pc = 2.12~rc1-lp155.23.1' needed by the to be installed grub2-2.12~rc1-lp155.23.1.x86_64 Solution 1: do not install grub2-2.12~rc1-lp155.23.1.x86_64 Solution 2: break grub2-2.12~rc1-lp155.23.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c/d/?] (c): tigerlily opensuse/1218104.2# zypper info grub2-i386-pc Loading repository data... Reading installed packages... Information for package grub2-i386-pc: -------------------------------------- Repository : Update repository with updates from SUSE Linux Enterprise 15 Name : grub2-i386-pc Version : 2.06-150500.29.11.1 Arch : noarch Vendor : SUSE LLC <https://www.suse.com/> Installed Size : 2.3 MiB Installed : Yes (automatically) Status : up-to-date Source package : grub2-2.06-150500.29.11.1.src Upstream URL : http://www.gnu.org/software/grub/ Summary : Bootloader with support for Linux, Multiboot and more . . . Best regards, Jaan
It seems you didn't specify local grub2 packages required by grub2-*.rpm downloaded from the same remote repository, something looks like this would work (not tested): > zypper install -D ./grub2-2.12~rc1-lp155.23.1.x86_64.rpm ./grub2-i386-pc-2.12~rc1-lp155.23.1.x86_64.rpm ./grub2-x86_64-efi-2.12~rc1-lp155.23.1.x86_64.rpm Instead of local rpm installation, a better alternative would be adding the test project as remote repository so that `zypper dup ...' can help to resolve the dependency. > zypper ar --repo https://download.opensuse.org/repositories/home:/michael-chang:/bsc:/1218104/15.5/home:michael-chang:bsc:1218104.repo > zypper ref > zypper dup --from home_michael-chang_bsc_1218104 --allow-vendor-change After testing you can follow a similar sequence to remove the repository and run `zypper dup ..' again to go back. > zypper rr home_michael-chang_bsc_1218104 --allow-vendor-change > zypper dup --allow-vendor-change
Hi Michael, Thank You for the zypper hints! I tried the repo solution - it needed 8 rpms ... Unfortunately the patch does not help. Still does not boot with Xen. Now it seems to exit earlier than before. It prints : Linux Xen ... and then exits back to grub menu without any message. Before the patch I think, if remembering correctly, it printed: Linux Xen ... Loading initial ramdisk ... and then printed the error message before going back to grub boot menu. How to proceed? Best regards, Jaan
(In reply to Jaan Haabma from comment #8) > Hi Michael, > > Thank You for the zypper hints! > > I tried the repo solution - it needed 8 rpms ... > > Unfortunately the patch does not help. Still does not boot with Xen. > Now it seems to exit earlier than before. It prints : > Linux Xen ... > and then exits back to grub menu without any message. > > Before the patch I think, if remembering correctly, it printed: > Linux Xen ... > Loading initial ramdisk ... > and then printed the error message before going back to grub boot menu. > > How to proceed? There seemed to be some misunderstanding here. If the firmware is uefi as you described in Description then you shouldn't see "Loading initial ramdisk ..." from the grub output because xen hypervisor is loaded by uefi chainloader (aka LoadImage()), the message is like: "Loading Xen 4.17.3_02-150500.3.18 with Linux 5.14.21-150500.55.39-default ...". After the hypervisor is running, it is responsible for loading the dom0 kernel and initial ramdisk by it's own config from the same efi partition, a file named like /boot/efi/EFI/opensuse/xen-4.17.3_02-150500.3.18.cfg so you should also have a look on that file. To gather the debug output, you can type 'ESC' to enter grub command shell, enable chainloader debug output and manually run the chainloader command to start xen hypervisor. grub> set debug=chain grub> chainloader /efi/opensuse/xen-4.17.3_02-150500 config.1 grub> boot The config.1 can be replaced with failsafe.3 to see if that makes a difference, it will use the failsafe.3 section in the /boot/efi/EFI/opensuse/xen-*.cfg. My speculation is that the patch worked to eliminate the error message, but unfortunately running into new issue which could be xen hypervisor related in the wake of uefi chainload.
Another question: Did your system prior to leap 15.5 set up as legacy bios boot? The message: Linux Xen ... Loading initial ramdisk .. ... would show up in legacy bios boot for the xen server because multiboot protocol is used by grub to load xen hypervisor, dom0 kernels and initial ramdisks so grub would print the information of them altogether.
Hi Michael, Thank you for your Debug boot hints, I will try them as soon as possible, but unfortunately can not do this today since the box is in other use ... Yes, before my fresh install of Leap 15.X (e.g. 13.X, 42.X) it booted with legacy BIOS boot. At that old times, I thought UEFI was not mature enough ... So I changed this to UEFI before fresh installing Leap 15.X. I also made the FS btrfs (used to be ext3 also of maturity reasons ...). I hoped that the latest 15.5 upgrade now would had fixed the Xen problem - have seen the same error message on Google, but no solution ... This was probably a bad idea. But I have UEFI and btrfs Leap 15.X running on other boxes for several years so I thought it now was a safe thing to do ... So reverting back to legacy BIOS boot might also be a solution to test later ? The Leap install ha one FS name diff in /boot (which I do not understand but probably does not matter). The Xen error box have /boot/efi/efi/... The upgraded (working) Xen box have /boot/efi/EFI/...
(In reply to Jaan Haabma from comment #11) > Hi Michael, > > Thank you for your Debug boot hints, I will try them as soon as possible, > but unfortunately can not do this today since the box is in other use ... > > Yes, before my fresh install of Leap 15.X (e.g. 13.X, 42.X) it booted with > legacy BIOS boot. At that old times, I thought UEFI was not mature enough ... > So I changed this to UEFI before fresh installing Leap 15.X. I also made the > FS btrfs (used to be ext3 also of maturity reasons ...). I hoped that the > latest 15.5 upgrade now would had fixed the Xen problem - have seen the same > error message on Google, but no solution ... This was probably a bad idea. > But I have UEFI and btrfs Leap 15.X running on other boxes for several years > so I thought it now was a safe thing to do ... Several factors can lead to failure, and it's not solely dependent on the age of the computer. Older hardware may deteriorate due to less usage, and tests are often conducted on modern, widely-used systems. > > So reverting back to legacy BIOS boot might also be a solution to test later > ? I'd recommend to continue with legacy bios test to establish a common ground of verifying the issue for $subject in relation to software regression. > > The Leap install ha one FS name diff in /boot (which I do not understand but > probably does not matter). > The Xen error box have /boot/efi/efi/... > The upgraded (working) Xen box have /boot/efi/EFI/... The vfat* file-system are not case sensitive, so it should be fine ... Thanks.
Hi Michael, So sorry for the too long no reply from me! I had too many other urgent stuff to take care of ... In the mean time, I also made a big mistake to install the latest kernel-default update - now un-installed. It does not boot or does not get any ethernet (no ip). This is probably due to a new bug related to an external usb ethernet adapter and the ax88179 driver. But this seems already been reported by others. br0 E: ID_MODEL_FROM_DATABASE=DUB-1312 Gigabit Ethernet Adapter E: DRIVER=ax88179_178a Loading the chainloader manually with grub2 as suggested unfortunately does not work. There is no efi mounted in /boot/efi which is empty, i.e. /boot/efi/efi/opensuse/* is not available. There is no /efi either. If I do: grub2> chainloader /boot/grub2/xen-4.17.3_02-150500.3.18.cfg config.1 it reads the config file, but ends with error: error: ../../grub-core/loader/efi/chainloader.c:862: cannot load image I checked on the other working Xen box. In grub it has no /boot/efi either, so this is probably not the problem. Both boxes have same image files in /boot. The working box when booted has a /boot/efi/EFI/opensuse/ The non working box when booted has a /boot/efi/efi/opensuse/ Any hints what to to next? Best regards, Jaan
(In reply to Jaan Haabma from comment #13) > Hi Michael, > > So sorry for the too long no reply from me! > > I had too many other urgent stuff to take care of ... > > In the mean time, I also made a big mistake to install the latest > kernel-default update - now un-installed. It does not boot or does not get > any ethernet (no ip). This is probably due to a new bug related to an > external usb ethernet adapter and the ax88179 driver. But this seems already > been reported by others. > br0 E: ID_MODEL_FROM_DATABASE=DUB-1312 Gigabit Ethernet Adapter > E: DRIVER=ax88179_178a > > Loading the chainloader manually with grub2 as suggested unfortunately does > not work. > > There is no efi mounted in /boot/efi which is empty, i.e. > /boot/efi/efi/opensuse/* is not available. There is no /efi either. What is the command output ? efibootmgr -v lsblk -f And the content of /etc/fstab ... If esp not mounted generally depicted that the system is initially installed with respect to legacy_bios boot, but strangely it could work for efi boot with the absent of /boot/efi ... > > If I do: > grub2> chainloader /boot/grub2/xen-4.17.3_02-150500.3.18.cfg config.1 > it reads the config file, but ends with error: > error: ../../grub-core/loader/efi/chainloader.c:862: cannot load image No. The chainloader cannot be used to read xen config. It just won't work. > > I checked on the other working Xen box. > In grub it has no /boot/efi either, so this is probably not the problem. > Both boxes have same image files in /boot. > The working box when booted has a /boot/efi/EFI/opensuse/ > The non working box when booted has a /boot/efi/efi/opensuse/ > > Any hints what to to next? The efi boot seemed to have been broken in some way that makes it worse and complicated to say much right now. Thanks.