From 044171c06b312252d7b73a204d77e929c1530513 Mon Sep 17 00:00:00 2001 From: Pavel Cahyna Date: Fri, 29 Jul 2022 13:18:55 +0200 Subject: [PATCH] Apply upstream PR 2580 Load the nvram module in the rescue environment in order to be able to set the boot order. Resolves: rhbz2096916 --- rear-bz2096916.patch | 130 +++++++++++++++++++++++++++++++++++++++++++ rear.spec | 1 + 2 files changed, 131 insertions(+) create mode 100644 rear-bz2096916.patch diff --git a/rear-bz2096916.patch b/rear-bz2096916.patch new file mode 100644 index 0000000..6a8a62f --- /dev/null +++ b/rear-bz2096916.patch @@ -0,0 +1,130 @@ +commit b06d059108db9b0c46cba29cc174f60e129164f1 +Author: Johannes Meixner +Date: Tue Mar 9 14:40:59 2021 +0100 + + Merge pull request #2580 from rear/jsmeix-load-nvram-module + + In etc/scripts/system-setup.d/41-load-special-modules.sh + load the nvram kernel module if possible to make /dev/nvram appear + because /dev/nvram should be there when installing GRUB, + see https://github.com/rear/rear/issues/2554 + and include the nvram kernel module in the recovery system + because nvram could be a module in particular on POWER architecture + see https://github.com/rear/rear/issues/2554#issuecomment-764720180 + +diff --git a/usr/share/rear/build/GNU/Linux/400_copy_modules.sh b/usr/share/rear/build/GNU/Linux/400_copy_modules.sh +index d8d733d2..a0ca9084 100644 +--- a/usr/share/rear/build/GNU/Linux/400_copy_modules.sh ++++ b/usr/share/rear/build/GNU/Linux/400_copy_modules.sh +@@ -116,8 +116,12 @@ for dummy in "once" ; do + # As a way out of this dilemma we add the below listed modules no longer via conf/GNU/Linux.conf + # but here after the user config files were sourced so that now the user can specify + # MODULES=( 'moduleX' 'moduleY' ) in etc/rear/local.conf to get additional kernel modules +- # included in the recovery system in addition to the ones via an empty MODULES=() setting: +- MODULES+=( vfat ++ # included in the recovery system in addition to the ones via an empty MODULES=() setting. ++ # nvram could be a module in particular on POWER architecture, ++ # cf. https://github.com/rear/rear/issues/2554#issuecomment-764720180 ++ # and https://github.com/rear/rear/pull/2580#issuecomment-791344794 ++ MODULES+=( nvram ++ vfat + nls_iso8859_1 nls_utf8 nls_cp437 + af_packet + unix +diff --git a/usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh b/usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh +index 4c2698f3..0cb3ee41 100644 +--- a/usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh ++++ b/usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh +@@ -104,9 +104,39 @@ fi + # Do not update nvram when system is running in PowerNV mode (BareMetal). + # grub2-install will fail if not run with the --no-nvram option on a PowerNV system, + # see https://github.com/rear/rear/pull/1742 +-grub2_install_option="" ++grub2_no_nvram_option="" + if [[ $(awk '/platform/ {print $NF}' < /proc/cpuinfo) == PowerNV ]] ; then +- grub2_install_option="--no-nvram" ++ grub2_no_nvram_option="--no-nvram" ++fi ++# Also do not update nvram when no character device node /dev/nvram exists. ++# On POWER architecture the nvram kernel driver could be also built as a kernel module ++# that gets loaded via etc/scripts/system-setup.d/41-load-special-modules.sh ++# but whether or not the nvram kernel driver will then create /dev/nvram ++# depends on whether or not the hardware platform supports nvram. ++# I asked on a SUSE internal mailing list ++# and got the following reply (excerpts): ++# ---------------------------------------------------------------- ++# > I would like to know when /dev/nvram exists and when not. ++# > I assume /dev/nvram gets created as other device nodes ++# > by the kernel (probably together with udev). ++# > I would like to know under what conditions /dev/nvram ++# > gets created and when it is not created. ++# > It seems on PPC /dev/nvram usually exist but sometimes not. ++# In case of powerpc, it gets created by nvram driver ++# (nvram_module_init) whenever the powerpc platform driver ++# has ppc_md.nvram_size greater than zero in it's machine ++# description structure. ++# How exactly ppc_md.nvram_size gets gets populated by platform ++# code depends on the platform, e.g. on most modern systems ++# it gets populated from 'nvram' device tree node ++# (and only if such node has #bytes > 0). ++# ---------------------------------------------------------------- ++# So /dev/nvram may not exist regardless that the nvram kernel driver is there ++# and then grub2-install must be called with the '--no-nvram' option ++# because otherwise installing the bootloader fails ++# cf. https://github.com/rear/rear/issues/2554 ++if ! test -c /dev/nvram ; then ++ grub2_no_nvram_option="--no-nvram" + fi + + # When GRUB2_INSTALL_DEVICES is specified by the user +@@ -134,7 +164,7 @@ if test "$GRUB2_INSTALL_DEVICES" ; then + else + LogPrint "Installing GRUB2 on $grub2_install_device (specified in GRUB2_INSTALL_DEVICES)" + fi +- if ! chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_install_option $grub2_install_device" ; then ++ if ! chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_no_nvram_option $grub2_install_device" ; then + LogPrintError "Failed to install GRUB2 on $grub2_install_device" + grub2_install_failed="yes" + fi +@@ -170,7 +200,7 @@ for part in $part_list ; do + LogPrint "Found PPC PReP boot partition $part - installing GRUB2 there" + # Erase the first 512 bytes of the PPC PReP boot partition: + dd if=/dev/zero of=$part +- if chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_install_option $part" ; then ++ if chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_no_nvram_option $part" ; then + # In contrast to the above behaviour when GRUB2_INSTALL_DEVICES is specified + # consider it here as a successful bootloader installation when GRUB2 + # got installed on at least one PPC PReP boot partition: +diff --git a/usr/share/rear/skel/default/etc/scripts/system-setup.d/41-load-special-modules.sh b/usr/share/rear/skel/default/etc/scripts/system-setup.d/41-load-special-modules.sh +index 9b0b3b8a..2e1d1912 100644 +--- a/usr/share/rear/skel/default/etc/scripts/system-setup.d/41-load-special-modules.sh ++++ b/usr/share/rear/skel/default/etc/scripts/system-setup.d/41-load-special-modules.sh +@@ -1,6 +1,24 @@ +-# some things are special ++# Special cases of kernel module loading. + +-# XEN PV does not autoload some modules +-if [ -d /proc/xen ] ; then +- modprobe xenblk ++# XEN PV does not autoload some modules: ++test -d /proc/xen && modprobe xenblk ++ ++# On POWER architecture the nvram kernel driver may be no longer built into the kernel ++# but nowadays it could be also built as a kernel module that needs to be loaded ++# cf. https://github.com/rear/rear/issues/2554#issuecomment-764720180 ++# because normally grub2-install gets called without the '--no-nvram' option ++# e.g. see finalize/Linux-ppc64le/620_install_grub2.sh ++# which is how grub2-install should be called when the hardware supports nvram. ++# Nothing to do when the character device node /dev/nvram exists ++# because then the nvram kernel driver is already there: ++if ! test -c /dev/nvram ; then ++ # Nothing can be done when there is no nvram kernel module. ++ # Suppress the possible 'modprobe -n nvram' error message like ++ # "modprobe: FATAL: Module nvram not found in directory /lib/modules/..." ++ # to avoid a possible "FATAL" false alarm message that would appear ++ # on the user's terminal during recovery system startup ++ # cf. https://github.com/rear/rear/pull/2537#issuecomment-741825046 ++ # but when there is a nvram kernel module show possible 'modprobe nvram' ++ # (error) messages on the user's terminal during recovery system startup: ++ modprobe -n nvram 2>/dev/null && modprobe nvram + fi diff --git a/rear.spec b/rear.spec index 65d66d4..e59d415 100644 --- a/rear.spec +++ b/rear.spec @@ -33,6 +33,7 @@ Patch42: rear-bz2083272.patch Patch43: rear-bz2111049.patch Patch44: rear-bz2104005.patch Patch45: rear-bz2097437.patch +Patch46: rear-bz2096916.patch # rear contains only bash scripts plus documentation so that on first glance it could be "BuildArch: noarch" # but actually it is not "noarch" because it only works on those architectures that are explicitly supported.