SUMMARY:
- CONFIG_IO_STRICT_DEVMEM is culprit (not CONFIG_STRICT_DEVMEM)
- iomem=relaxed allows Dell DUP Kits to correctly report and update some
firmware that previously failed.
- some Dell DUP Kits work fine in locked-down environment, others fail. some
fail with error reports, others silently claim to work and fail fully.
- Dell should hopefully fix the DUP kit components to error check and
work-around restrictions.
On 07/12/2018 02:40 PM, Stephen Dowdy wrote:
Update: adding 'iomem=relaxed' to the kernel bootparams allows 'biosie' (from
the BIOS*.BIN DUPkit) to update the BIOS.
Subject line changed to reflect the accurate kernel knob
(CONFIG_IO_STRICT_DEVMEM)
Ref: https://outflux.net/blog/archives/2016/09/28/security-things-in-linux-v4-5/
Ref:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90a545e981267e917b9d698ce07affd69787db87
Okay, this (iomem=relaxed) also fixed the issue i've been having with the BCM NetExtreme
(5720) firmware update DUP kits failing to report the "installed/running"
version and actually REALLY updating the firmware:
~# ral-superinv
[System Board]
Hostname : XXXXXXXX
Manufacturer : Dell Inc.
Model : PowerEdge T640
Memory : 196608 MB
Serial Number : XXXXXXXX
BIOS Version : 1.3.7 (!=1.4.8)
BMC/iDRAC Version : 3.21 {iDRAC9}
[Network]
Broadcom Adv. Dual 10GBASE-T Ethernet (BCM957416)@18:00.0 : 20.08.04.04
Broadcom Adv. Dual 10GBASE-T Ethernet (BCM957416)@18:00.1 : 20.08.04.04
--> Broadcom NetXtreme Gigabit Ethernet (BCM95720)@b1:00.0 : 20.6.52
--> Broadcom NetXtreme Gigabit Ethernet (BCM95720)@b1:00.1 : 20.6.52
[RAID/PERC] :
PERC H740P Adapter = 50.3.0-1022
We try to run the Broadcom NetXtreme updater (Network_Firmware_R4HKW_LN_20.8.4.BIN) to
get from 20.6 to 20.8, but Dell's DUP Kit can't inventory the "Installed
version". It runs and CLAIMS it updated and wants to reboot, but on reboot, the
firmware's still 20.6 :
.../local/DellUpdates/NETW# ../dup_run_debian 14GEN_Broadcom_NetXtreme -q
/bin/sh appears to be dash, setting it to use BASH, because Dell's sh
scripts are non-POSIX and break systems
Collecting inventory...
....
Running validation...
NetXtreme BCM5720 Gigabit Ethernet PCIe (enp177s0f0)
The version of this Update Package is newer than the currently installed version.
Software application name: NetXtreme BCM5720 Gigabit Ethernet PCIe
(enp177s0f0)
Package version: 20.8.4
--> Installed version:
...
Executing update...
WARNING: DO NOT STOP THIS PROCESS OR INSTALL OTHER PRODUCTS WHILE UPDATE IS
IN PROGRESS.
THESE ACTIONS MAY CAUSE YOUR SYSTEM TO BECOME UNSTABLE!
....
The system should be restarted for the update to take effect.
ERROR: Network_Firmware_R4HKW_LN_20.8.4.BIN execution MAY have failed, or
you answered NO to reboot, sorry (return_code=2)
(my wrapper script reports return error codes, so this was not a reported error
from the DUP kit, but i believe DELL uses 'returncode=2' to indicate user chose
to NOT reboot after update, but i'm not going to blindly trust that given that
many DUPs behave differently)
Clearly, there's some failure to do error checks and report in this particular
DUP kit.
BUT, The equivalent 20.8 Broadcom NetXtreme-E Updater
(Network_Firmware_3VXHM_LN64_20.08.04.04.BIN) works *flawlessly* under the same
conditions. (that's why my BCM957416's are updated to 20.08).
So, *something* can be done on Dell's side to make these DUP kits actually work
under these conditions.
I verified that booting with 'iomem=relaxed' allows the
'Network_Firmware_R4HKW_LN_20.8.4.BIN' to actually correctly query the
installed version, *AND* update the firmware properly. (but there's a security
side-effect of running this way)
thanks,
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - [email protected] - http://www.ral.ucar.edu/~sdowdy/
_______________________________________________
Linux-PowerEdge mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
