Hey folks (mostly R&D),
This section of code in /bin/config_system is flawed, line 1178. I'll open a TAC case as well.
vi +1178 /bin/config_system:
if [[ $is_maintenance_pw_not_mandatory == $TRUE ]]; then
#is_maintenance_pw_not_mandatory is a flag for cloud usage. If 'true' then ignore maintenance validation
log "is_maintenance_pw_not_mandatory flag detetected. Passing validation for maintenance password."
else
is_default_maintenance_pw=$(dbget grub2pwd:changeme)
if [ $is_default_maintenance_pw -eq 1 ] && [ -z "$maintenance_hash" ]; then
ERROR_MSG="$MSG1 maintenance_hash";
return 1;
fi
fi
The "else" clause is the problematic section, with the 'dbget' command. For a net-new R81.20 install, on open server (PHY or VM) the Anaconda installer forces a maintenance password to be set. Ergo, "grub2pwd:changeme" in /config/active will not exist, and will return either a null value or an empty value. The return code ($?) will be "1", not "0". Since the return value is either null or blank, the "-eq 1" in the test section will fail for being a textual comparison, not a numerical comparison. This results in an error from bash: "-eq 1: Unary operator expected".
This one tiny error caused my whole R81.20 install with config_system to fail today. On the second install, I edited that section to have it work. I did follow the instruction to collect the current maintenance hash and add it to the FTW config file, since it's now required, but that wasn't relevant since the "-z" test wasn't the problem.
If you want to check the return code of dbget, that's not how you do it. A better way to force the numerical comparison is to use the (( .. )) test method. This ensures non-numerical values are unmatched safely, giving you a chance to recover in an 'else' clause.
My edit was a quick-and-simple one; just enough to pass the test and move along:
dbget grub2pwd:changeme
is_default_maintenance_pw=$?
These values weren't used anywhere else in the script, and the maintenance password hash was already set, so nothing was really affected either way.
I did notice for CloudGuard installs that "grub2pwd:changeme" did exist in /config/active by default, and with the default CONFD value of "1" as expected, which caused the test to pass as written. Looks like some missed a Cloud-vs-NotCloud scenario.
I hope this helps the next poor soul doing a net-new open server install.