Description of problem: [Satellite] leapp will fail if system boots on legacy bios with foreman-bootloaders-redhat installed. The bug seems to reside in grubby, feel free to move to this component. Workaround is to remove grub2-efi* packages using `rpm -e --nodeps`. Version-Release number of selected component (if applicable): leapp-upgrade-el7toel8-deps-0.17.0-10.el7_9 How reproducible: Likely always, not tested. Steps to Reproduce: 1. Use a RHEL 7.9 Sat server booting on legacy bios 2. Install foreman-bootloaders-redhat 3. leapp upgrade Actual results: No RHEL-Upgrade-Initramfs entry. Expected results: Maybe an inhibitor. Additional info: leapp uses grubby to add the "RHEL-Upgrade-Initramfs" entry: 2023-05-12 14:27:56.728 DEBUG PID: 115103 leapp.workflow.InterimPreparation.add_upgrade_boot_entry: External command has finished: ['/usr/sbin/grubby', '--add-kernel', '/boot/vmlinuz-upgrade.x86_64', '--initrd', '/boot/initramfs-upgrade.x86_64.img', '--title', 'RHEL-Upgrade-Initramfs', '--copy-default', '--make-default', '--args', ' enforcing=0 rd.plymouth=0 plymouth.enable=0'] this system is configured like an hybrid boot system, the standard grubenv being a symlink to its efi counterpart. $ readlink boot/grub2/grubenv ../efi/EFI/redhat/grubenv this is caused by these packages (Sat env only): $ grep installed-rpms foreman-bootloaders-redhat-202005201200-1.el7sat.noarch Tue May 16 08:27:08 2023 foreman-bootloaders-redhat-tftpboot-202005201200-1.el7sat.noarch Tue May 16 08:27:08 2023 they have deps against grub2-efi* # repoquery -R foreman-bootloaders-redhat | grep grub2-efi grub2-efi-ia32-modules grub2-efi-x64-modules efibootmgr is not installed, confirming the machine seems used only in legacy mode (confirmed by the customer). in such a case grubby updates /boot/efi/EFI/redhat/grub.cfg, hence the "RHEL-Upgrade-Initramfs" boot entry is not visible for such a system that boots in legacy mode (as per "vmware recommendation"). $ grep ^menuentry boot/grub2/grub.cfg menuentry 'Red Hat Enterprise Linux Server (3.10.0-1160.90.1.el7.x86_64) 7.9 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1062.12.1.el7.x86_64-advanced-efcc83d5-4b14-4eea-8edb-298d25ebacbe' { menuentry 'Red Hat Enterprise Linux Server (3.10.0-1160.71.1.el7.x86_64) 7.9 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1062.12.1.el7.x86_64-advanced-efcc83d5-4b14-4eea-8edb-298d25ebacbe' { menuentry 'Red Hat Enterprise Linux Server (0-rescue-43810f3c0bdf473cb20cc1b0fb32d1d1) 7.7 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-43810f3c0bdf473cb20cc1b0fb32d1d1-advanced-efcc83d5-4b14-4eea-8edb-298d25ebacbe' { $ grep ^menuentry boot/efi/EFI/redhat/grub.cfg menuentry 'RHEL-Upgrade-Initramfs' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1062.12.1.el7.x86_64-advanced-efcc83d5-4b14-4eea-8edb-298d25ebacbe' { menuentry 'Red Hat Enterprise Linux Server (3.10.0-1160.90.1.el7.x86_64) 7.9 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1062.12.1.el7.x86_64-advanced-efcc83d5-4b14-4eea-8edb-298d25ebacbe' { menuentry 'Red Hat Enterprise Linux Server (3.10.0-1160.71.1.el7.x86_64) 7.9 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1062.12.1.el7.x86_64-advanced-efcc83d5-4b14-4eea-8edb-298d25ebacbe' { menuentry 'Red Hat Enterprise Linux Server (0-rescue-43810f3c0bdf473cb20cc1b0fb32d1d1) 7.7 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-43810f3c0bdf473cb20cc1b0fb32d1d1-advanced-efcc83d5-4b14-4eea-8edb-298d25ebacbe' {
Hey, Lukáš from Satellite here. The package in question is a metapackage that have a dependency on grub2 and shim and a post script that copies Red Hat signed Shim and Grub2 (for SecureBoot) into TFTP/HTTP directories for network boot provisioning. This package can be indeed installed on BIOS systems as well where it does not make sense to install EFI bootloaders, but the point is a BIOS Satellite Capsule needs to be able to provision both BIOS and EFI systems. I don’t exactly understand what is the problem and why LEAP fails, however, I can confirm that these packages can be safely uninstalled assuming that user is informed about this during upgrade procedure and it is documented somewhere that Satellite users need to re-run Satellite Installer again in order to ensure these are installed back after the upgrade. Hopefully this helps, cheers.
Where does /boot/efi/EFI/redhat/grub.cfg come from on that system? My legacy-boot EL7 systems don't have that file and when it is absent, grubby should find the right config. https://github.com/rhboot/grubby/blob/c01b0d5bb182bde35b464d14996acf354a3ada2e/grubby.c#L253-L294 says: static const char *configFiles[] = { "/etc/grub2-efi.cfg", "/etc/grub2.cfg", "/boot/grub2/grub.cfg", "/boot/grub2-efi/grub.cfg", NULL }; /etc/grub2-efi.cfg is a symlink to /boot/efi/EFI/redhat/grub.cfg, but that doesn't exist on my machines, so next it tries /etc/grub2.cfg which in turn is a symlink to /boot/grub2/grub.cfg, which exists and is the right config to be edited. Nothing of that is related to the `foreman-bootloaders-redhat` package, which indeed *does* pull in more Grub packages, but only to use their contents to generate bootable images for other systems. The system the package is installed on is not altered at all.
As I said, I didn't test on my end. I understand foreman-bootloaders-redhat has just triggered grub2-efi pkgs, but that should not be a problem. AFAICS, symlink is correct for a bios system, and there is no grub2-efi symlink. $ ll etc/grub*.cfg lrwxrwxrwx. 1 yank yank 22 May 11 22:56 etc/grub2.cfg -> ../boot/grub2/grub.cfg Why grubby updated only the EFI grub.cfg (and grubenv) will remain a mystery. Relevant sosreport from the case (too big to be attached) ends with "2023-05-16-avqnhnj".
> Why grubby updated only the EFI grub.cfg (and grubenv) will remain a mystery. It updated the EFI grub.cfg because /etc/grub2-efi.cfg points to an *existing* file (/boot/efi/EFI/redhat/grub.cfg), which should not be the case on a legacy-boot system. You gotta find out what/who created /boot/efi/EFI/redhat/grub.cfg on that system. According the the anaconda logs on that system, only "grub2-mkconfig -o /boot/grub2/grub.cfg" was executed by anaconda.
Evgeni is totally right that /boot/efi/EFI/redhat/grub.cfg should not exist on a BIOS system. A fresh install of 7.9 on BIOS looks like this: [root@kvm-08-guest32 ~]# ls -l /boot/efi/EFI/redhat/ total 0 [root@kvm-08-guest32 ~]# ls -l /boot/grub2/ total 32 -rw-r--r--. 1 root root 164 Jun 7 09:28 device.map drwxr-xr-x. 2 root root 25 Jun 7 09:28 fonts -rw-r--r--. 1 root root 4382 Jun 7 09:29 grub.cfg -rw-r--r--. 1 root root 1024 Jun 7 09:29 grubenv drwxr-xr-x. 2 root root 8192 Jun 7 09:28 i386-pc drwxr-xr-x. 2 root root 4096 Jun 7 09:28 locale [root@kvm-08-guest32 ~]# ls -l /etc/grub2.cfg lrwxrwxrwx. 1 root root 22 Jun 7 09:25 /etc/grub2.cfg -> ../boot/grub2/grub.cfg Installing just these packages: grub2-efi-ia32-modules & grub2-efi-x64-modules does not change that. If, however, additional grub-efi packages also got installed, then that will create a [broken] link /etc/grub2-efi.cfg -> ../boot/efi/EFI/redhat/grub.cfg although not the actual grub.cfg file in that dir. I am suspicious of the comment in the Description > this system is configured like an hybrid boot system, the standard grubenv being a symlink to its efi counterpart. > $ readlink boot/grub2/grubenv > ../efi/EFI/redhat/grubenv On a BIOS system, there should be nothing in /boot/efi/EFI/redhat. What else is in there? Also as Evgeni pointed out, if /etc/grub2-efi.cfg is there, then that will be the one that gets updated, as per his comment#4
> It updated the EFI grub.cfg because /etc/grub2-efi.cfg points to an *existing* file (/boot/efi/EFI/redhat/grub.cfg), which should not be the case on a legacy-boot system. such a symlink does not exist on their os, as per the sosreport we have only the /etc/grub2.cfg one, or it has been removed at some point. @mlewando your suspicion about the grubenv file is correct, it's _only_ boot/grub2/grubenv.rpmnew that is a symlink to its efi counterpart: lrwxrwxrwx. 1 0 0 25 May 16 08:29 grubenv.rpmnew -> ../efi/EFI/redhat/grubenv from the latest sosreport we have in /boot (omitting mods): /boot: total 237152 dr-xr-xr-x. 6 0 0 4096 May 16 09:00 . dr-xr-xr-x. 29 0 0 4096 May 12 15:36 .. -rw-r--r--. 1 0 0 172 Jun 15 2022 .vmlinuz-3.10.0-1160.71.1.el7.x86_64.hmac -rw-r--r--. 1 0 0 172 Mar 17 19:58 .vmlinuz-3.10.0-1160.90.1.el7.x86_64.hmac -rw-------. 1 0 0 3622036 Jun 15 2022 System.map-3.10.0-1160.71.1.el7.x86_64 -rw-------. 1 0 0 3623956 Mar 17 19:58 System.map-3.10.0-1160.90.1.el7.x86_64 -rw-r--r--. 1 0 0 153619 Jun 15 2022 config-3.10.0-1160.71.1.el7.x86_64 -rw-r--r--. 1 0 0 153619 Mar 17 19:58 config-3.10.0-1160.90.1.el7.x86_64 drwxr-xr-x. 3 0 0 4096 Apr 27 2018 efi drwxr-xr-x. 2 0 0 4096 May 15 2019 extlinux drwx------. 5 0 0 4096 May 16 08:29 grub2 -rw-------. 1 0 0 50456478 Jun 9 2017 initramfs-0-rescue-43810f3c0bdf473cb20cc1b0fb32d1d1.img -rw-------. 1 0 0 21946103 May 9 09:33 initramfs-3.10.0-1160.71.1.el7.x86_64.img -rw-------. 1 0 0 13418481 Aug 31 2022 initramfs-3.10.0-1160.71.1.el7.x86_64kdump.img -rw-------. 1 0 0 22003025 May 9 09:34 initramfs-3.10.0-1160.90.1.el7.x86_64.img -rw-------. 1 0 0 13454835 May 9 09:48 initramfs-3.10.0-1160.90.1.el7.x86_64kdump.img -rw-------. 1 0 0 82826104 May 16 09:00 initramfs-upgrade.x86_64.img -rw-r--r--. 1 0 0 614150 Jun 9 2017 initrd-plymouth.img drwx------. 2 0 0 16384 Jun 9 2017 lost+found -rw-r--r--. 1 0 0 320652 Jun 15 2022 symvers-3.10.0-1160.71.1.el7.x86_64.gz -rw-r--r--. 1 0 0 320760 Mar 17 19:58 symvers-3.10.0-1160.90.1.el7.x86_64.gz -rwxr-xr-x. 1 0 0 5391264 Jun 9 2017 vmlinuz-0-rescue-43810f3c0bdf473cb20cc1b0fb32d1d1 -rwxr-xr-x. 1 0 0 6777688 Jun 15 2022 vmlinuz-3.10.0-1160.71.1.el7.x86_64 -rwxr-xr-x. 1 0 0 7052120 Mar 17 19:58 vmlinuz-3.10.0-1160.90.1.el7.x86_64 -rwxr-xr-x. 1 0 0 10636656 May 16 08:59 vmlinuz-upgrade.x86_64 /boot/efi: total 12 drwxr-xr-x. 3 0 0 4096 Apr 27 2018 . dr-xr-xr-x. 6 0 0 4096 May 16 09:00 .. drwxr-xr-x. 4 0 0 4096 May 7 2018 EFI /boot/efi/EFI: total 16 drwxr-xr-x. 4 0 0 4096 May 7 2018 . drwxr-xr-x. 3 0 0 4096 Apr 27 2018 .. drwxr-xr-x. 2 0 0 4096 May 9 09:32 BOOT drwx------. 3 0 0 4096 May 16 09:01 redhat /boot/efi/EFI/BOOT: total 2276 drwxr-xr-x. 2 0 0 4096 May 9 09:32 . drwxr-xr-x. 4 0 0 4096 May 7 2018 .. -rwx------. 1 0 0 1009976 Apr 18 04:18 BOOTIA32.EFI -rwx------. 1 0 0 951296 Apr 18 04:18 BOOTX64.EFI -rwx------. 1 0 0 262152 Apr 18 04:18 fbia32.efi -rwx------. 1 0 0 88344 Apr 18 04:18 fbx64.efi /boot/efi/EFI/redhat: total 7720 drwx------. 3 0 0 4096 May 16 09:01 . drwxr-xr-x. 4 0 0 4096 May 7 2018 .. -rwx------. 1 0 0 182 Apr 18 04:18 BOOT.CSV -rwx------. 1 0 0 184 Apr 18 04:18 BOOTIA32.CSV -rwx------. 1 0 0 182 Apr 18 04:18 BOOTX64.CSV drwx------. 2 0 0 4096 May 16 08:29 fonts -rw-r--r--. 1 0 0 6720 May 16 09:01 grub.cfg -rw-r--r--. 1 0 0 1024 May 12 14:27 grubenv -rwx------. 1 0 0 1203704 Nov 17 08:22 grubx64.efi -rwx------. 1 0 0 927736 Apr 18 04:18 mmia32.efi -rwx------. 1 0 0 851320 Apr 18 04:18 mmx64.efi -rwx------. 1 0 0 951296 Apr 18 04:18 shim.efi -rwx------. 1 0 0 1012808 Apr 18 04:18 shimia32-redhat.efi -rwx------. 1 0 0 1009976 Apr 18 04:18 shimia32.efi -rwx------. 1 0 0 944552 Apr 18 04:18 shimx64-redhat.efi -rwx------. 1 0 0 951296 Apr 18 04:18 shimx64.efi /boot/grub2: total 76 drwx------. 5 0 0 4096 May 16 08:29 . dr-xr-xr-x. 6 0 0 4096 May 16 09:00 .. -rw-r--r--. 1 0 0 104 Jun 9 2017 device.map drwxr-xr-x. 2 0 0 4096 Jun 9 2017 fonts -rw-r--r--. 1 0 0 5670 May 12 08:56 grub.cfg -rw-r--r--. 1 0 0 4646 Jun 13 2017 grub.cfg.1497318133.rpmsave -rw-r--r--. 1 0 0 6582 Jul 20 2017 grub.cfg.1524790877.rpmsave -rw-r--r--. 1 0 0 6564 May 17 2018 grub.cfg.1541130623.rpmsave -rw-r--r--. 1 0 0 6582 Jun 20 2019 grub.cfg.1568591466.rpmsave -rw-r--r--. 1 0 0 1024 May 16 09:01 grubenv lrwxrwxrwx. 1 0 0 25 May 16 08:29 grubenv.rpmnew -> ../efi/EFI/redhat/grubenv drwxr-xr-x. 2 0 0 12288 May 12 15:31 i386-pc drwxr-xr-x. 2 0 0 4096 May 12 15:31 locale
Another customer having this issue. They also installed grub2-efi-x64 that provides /etc/grub2-efi.cfg, explaining the grubby behaviour. It is visible from the grubby's strace but not from the sosreport, idk why... # yum whatprovides '/etc/grub2-efi.cfg' | tail | grep -v ^$ 1:grub2-efi-x64-2.02-0.87.el7_9.11.x86_64 : GRUB for EFI systems. Repo : rhel-7-server-rpms Matched from: Filename : /etc/grub2-efi.cfg $ grep grub2-efi-x64-2.02 0050-soscleaner-1855931622518663.tar.gz/soscleaner-1855931622518663/installed-rpms grub2-efi-x64-2.02-0.87.el7_9.11.x86_64 Tue Mar 7 17:37:26 2023 $ ls -l 0050-soscleaner-1855931622518663.tar.gz/soscleaner-1855931622518663/etc/grub* lrwxrwxrwx. 1 yank yank 22 Jun 27 17:14 0050-soscleaner-1855931622518663.tar.gz/soscleaner-1855931622518663/etc/grub2.cfg -> ../boot/grub2/grub.cfg 0050-soscleaner-1855931622518663.tar.gz/soscleaner-1855931622518663/etc/grub.d: total 72 -rw-rw-rw-. 1 yank yank 8702 Jun 27 17:16 00_header -rw-rw-rw-. 1 yank yank 1043 Jun 27 17:16 00_tuned -rw-rw-rw-. 1 yank yank 242 Jun 27 17:16 01_users -rw-rw-rw-. 1 yank yank 10781 Jun 27 17:16 10_linux -rw-rw-rw-. 1 yank yank 10275 Jun 27 17:16 20_linux_xen -rw-rw-rw-. 1 yank yank 2559 Jun 27 17:16 20_ppc_terminfo -rw-rw-rw-. 1 yank yank 11169 Jun 27 17:16 30_os-prober -rw-rw-rw-. 1 yank yank 214 Jun 27 17:16 40_custom -rw-rw-rw-. 1 yank yank 216 Jun 27 17:16 41_custom -rw-rw-rw-. 1 yank yank 483 Jun 27 17:16 README And from the strace we have 45304 14:03:53.769006 open("/etc/grub2-efi.cfg", O_RDONLY) = 3</boot/efi/EFI/redhat/grub.cfg> <0.000014>
/etc/grub2-efi.cfg in grub2-efi-x64 is a symlink to /boot/efi/EFI/redhat/grub.cfg, which on a legacy-boot system should not exist! If it doesn't exist, open() fails, and grubby continues with the next cfg (/etc/grub2.cfg) in its list. So, why does this customer have a /boot/efi/EFI/redhat/grub.cfg on a legacy-boot system?
[Q] So, why does this customer have a /boot/efi/EFI/redhat/grub.cfg on a legacy-boot system? Because it has been generated by grubby while adding the new entry (grubby being called by Leapp). And grubby did this because they apparently have a /etc/grub2-efi.cfg symlink that takes precedence over the legacy one. Some grub2-efi pkgs are triggered by dependency, due to the presence of foreman-bootloaders-redhat* pkgs (satellite server, to setup a PXE boot env). $ repoquery -R foreman-bootloaders-redhat | grep grub2-efi grub2-efi-ia32-modules grub2-efi-x64-modules AFAICS, nothing requires grub2-efi-x64 $ repoquery --whatrequires grub2-efi-x64; echo $? 0 Hence I consider this was a manual install which should not happen on a legacy system, explaining the grubby behaviour.
(In reply to Christophe Besson from comment #16) > [Q] So, why does this customer have a /boot/efi/EFI/redhat/grub.cfg on a > legacy-boot system? > > Because it has been generated by grubby while adding the new entry (grubby > being called by Leapp). No, grubby will not create a file that was not there before. > And grubby did this because they apparently have a /etc/grub2-efi.cfg > symlink that takes precedence over the legacy one. It doesn't. https://github.com/rhboot/grubby/blob/c01b0d5bb182bde35b464d14996acf354a3ada2e/grubby.c#L253-L294 It loops over the list of possible configs and does a access(configFiles[i], R_OK)) on them. access(2) reads: access() checks whether the calling process can access the file pathname. If pathname is a symbolic link, it is dereferenced. The mode specifies the accessibility check(s) to be performed, and is either the value F_OK, or a mask consisting of the bitwise OR of one or more of R_OK, W_OK, and X_OK. F_OK tests for the existence of the file. R_OK, W_OK, and X_OK test whether the file exists and grants read, write, and execute permissions, respectively. On a normal legacy boot system, access("/etc/grub2-efi.cfg") will derefence the link to /boot/efi/EFI/redhat/grub.cfg and given that files does not exist the call will fail. [root@centos7 ~]# rpm -qa |grep grub grub2-common-2.02-0.87.0.2.el7.centos.11.noarch grub2-tools-2.02-0.87.0.2.el7.centos.11.x86_64 grub2-pc-modules-2.02-0.87.0.2.el7.centos.11.noarch grub2-2.02-0.87.0.2.el7.centos.11.x86_64 grub2-efi-x64-modules-2.02-0.87.0.2.el7.centos.11.noarch grubby-8.28-26.el7.x86_64 grub2-tools-minimal-2.02-0.87.0.2.el7.centos.11.x86_64 grub2-tools-extra-2.02-0.87.0.2.el7.centos.11.x86_64 grub2-pc-2.02-0.87.0.2.el7.centos.11.x86_64 grub2-efi-x64-2.02-0.87.0.2.el7.centos.11.x86_64 grub2-efi-ia32-modules-2.02-0.87.0.2.el7.centos.11.noarch [root@centos7 ~]# ls -alh /etc/grub2-efi.cfg /boot/efi/EFI/centos/grub.cfg ls: cannot access /boot/efi/EFI/centos/grub.cfg: No such file or directory lrwxrwxrwx. 1 root root 31 Jun 29 10:44 /etc/grub2-efi.cfg -> ../boot/efi/EFI/centos/grub.cfg [root@centos7 ~]# grubby --add-kernel /boot/vmlinuz-3.10.0-1127.el7.x86_64 --title test [root@centos7 ~]# ls -alh /etc/grub2-efi.cfg /boot/efi/EFI/centos/grub.cfg ls: cannot access /boot/efi/EFI/centos/grub.cfg: No such file or directory lrwxrwxrwx. 1 root root 31 Jun 29 10:44 /etc/grub2-efi.cfg -> ../boot/efi/EFI/centos/grub.cfg [root@centos7 ~]# grep test /etc/grub2.cfg menuentry 'test' --class gnu-linux --class gnu --class os {
The symlink /etc/grub2-efi.cfg -> ../boot/efi/EFI/redhat/grub.cfg gets created when grub2-efi packages are installed, but it's a broken link since the grub.cfg doesn't actually exist in that directory. Running grubby in that state creates the new entry in /boot/grub2/grub.cfg, and it's possible to boot it. A person or process needs to run grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg (or just move/copy the config of course) to get it there. At that point, running grubby will generate the entry in the wrong config file. But from comment#14 where is the symlink? I see the result of the strace later, but not the symlink... > $ ls -l 0050-soscleaner-1855931622518663.tar.gz/soscleaner-1855931622518663/etc/grub* > lrwxrwxrwx. 1 yank yank 22 Jun 27 17:14 0050-soscleaner-1855931622518663.tar.gz/soscleaner-1855931622518663/etc/grub2.cfg -> ../boot/grub2/grub.cfg > > 0050-soscleaner-1855931622518663.tar.gz/soscleaner-1855931622518663/etc/grub.d: > total 72 > -rw-rw-rw-. 1 yank yank 8702 Jun 27 17:16 00_header > -rw-rw-rw-. 1 yank yank 1043 Jun 27 17:16 00_tuned > -rw-rw-rw-. 1 yank yank 242 Jun 27 17:16 01_users > -rw-rw-rw-. 1 yank yank 10781 Jun 27 17:16 10_linux > -rw-rw-rw-. 1 yank yank 10275 Jun 27 17:16 20_linux_xen > -rw-rw-rw-. 1 yank yank 2559 Jun 27 17:16 20_ppc_terminfo > -rw-rw-rw-. 1 yank yank 11169 Jun 27 17:16 30_os-prober > -rw-rw-rw-. 1 yank yank 214 Jun 27 17:16 40_custom > -rw-rw-rw-. 1 yank yank 216 Jun 27 17:16 41_custom > -rw-rw-rw-. 1 yank yank 483 Jun 27 17:16 README
Yes, that's what I said, I don't know why I can't see the symlink from the sosreport whereas I can see it in the strace. I guess the sosreport takes only a subset of /etc and it does not include grub2-efi.cfg is the OS is not EFI. If it's the case, that does not help in debugging. >> On a normal legacy boot system, access("/etc/grub2-efi.cfg") will derefence the link to /boot/efi/EFI/redhat/grub.cfg and given that files does not exist the call will fail. Ok, that confirms both customers intervene manually, leading to this situation. To my part there is no reason to reopen this bug.