rpms/rear
5
0
Fork 0
Code Issues Pull Requests Releases Activity

Apply upstream PR 2580

Browse Source 
Load the nvram module in the rescue environment in order to be able to
set the boot order.

Resolves: rhbz2096916
This commit is contained in:
Pavel Cahyna 2022-07-29 13:18:55 +02:00
parent 31591dbc82
commit 044171c06b
2 changed files with 131 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

130
rear-bz2096916.patch Normal file
View File

@ -0,0 +1,130 @@
commit b06d059108db9b0c46cba29cc174f60e129164f1
Author: Johannes Meixner <jsmeix@suse.com>
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 <jsmeix@suse.de> 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

1
rear.spec
View File

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