Autoyast: Error reporting in pre-install scripts

After the opener on Retaining/reusing existing partitions and the followup on Partitioning that works on both real hardware and inside virtual machines, this post looks at error reporting in pre-install scripts.

So far we examined two use cases where we basically implemented functionality in pre-install scripts that AutoYast itself is missing. Such functionality is usually implemented under certain circumstances. For example, in the previous post we hinted at a suitable drive being completely absent because you forgot to add it to the VM. This is, of course, quite an unrealistic example but it serves to demonstrate another aspect of pre-install scripts which so far may or may not have been on your mind: error handling and reporting.

Usually when you implement a Bash script to achieve something you hopefully do check return codes and catch and report errors to the user in some way. There is the well-known convention of exiting with a return code of 0 if everything went fine and with different return codes otherwise. Of course, this does not free you from also writing a hopefully meaningful error message for the user to stderr.

Now not only do Autoyast scripts not run interactively, they actually usually run completely hidden, without any chance to ask the user questions (this is not 100% true but I’ll not elaborate on this here) and at first look also without the ability to give feedback. Not true! Let me point your attention to four XML tags allowed in a <script> block that you might have overseen:

  • With <notification>Currently doing foobar...</notification> Yast will display the message as long as the script is running. This is especially useful if the script takes some time to complete or if there is more than one script to be executed, so the user knows which one is currently running.
  • With <feedback config:type="boolean">true</feedback> Yast will watch both stdout and stderr for any output. If at the end of the script execution there was any output to either of the two, it is shown inside a dialog box to the user.
  • With <feedback_type>error</feedback_type> you can influence the way the dialog box behaves in terms of if and when the dialog automatically closes. Other possible values include message and warning. If left off or set to error the dialog will not disappear automatically at all.
  • Specify <debug config:type="boolean>false</debug> if you don’t want to see every single line of your pre-install script logged in the dialog box — by default this is enabled. (You could of course set +x but then at least that line gets logged…)

So now you know that if an error occurs, you can simply echo it to stderr as in other Bash scripts!

One final note: if you enable <feedback>, make sure that you add >/dev/null and 2>/dev/null statements for commands where the output is not actually an error. For example, if you call vgdisplay myvg to check if the LVM volume group already exists, you would see the error message if it doesn’t in the script dialog box popping up, which is probably not what you want.