Bug 443511 - mkinitrd uses bash3-specific syntax
mkinitrd uses bash3-specific syntax
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mkinitrd (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Brian Lane
Depends On:
  Show dependency treegraph
Reported: 2008-04-21 18:02 EDT by Alan Porter
Modified: 2011-07-27 14:01 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-07-27 14:01:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Porter 2008-04-21 18:02:41 EDT
Description of problem:

Starting with RHEL 4.5, the mkinitrd script uses the [[ $x =~ $pattern ]]
notation to look for a module.  This notation works fine in bash 3.0, but not in
bash 2.0.

This might just be a problem that is specific to our company, but I thought I
should bring it up to see if it needs fixing upstream.

Our RHEL-based systems are being upgraded from RHEL 3.4 to 4.5.  The first
package to be installed is the new kernel.  As part of the kernel's %post
scriptlet, we run mkinitrd.  However, at the time that mkinitrd is run, bash 2.0
is still installed on the system, and bash 3.0 is not yet installed.  Since the
"=~" notation is new in bash 3.0, mkinitrd fails.

If the mkinitrd script used (the somewhat slower) pipes and grep to do this
module check, there would be no dependency on later versions of bash.

Version-Release number of selected component (if applicable):

RHEL 4.3 - mkinitrd- [ok, bash 2.0 compatible]
RHEL 4.4 - mkinitrd- [uses =~, requires bash 3.0]
RHEL 4.5 - mkinitrd- [uses =~, requires bash 3.0]

How reproducible:

Every time, but not on a standard RHEL system... it's on a RHEL-based system
used for telecom equipment.  The upgrade process is not RHEL, but is developed
in-house.  I thought I would share this feedback in case you felt it was
important to keep mkinitrd compatible with the lowest common denominator of
shells that it might be running on.

Note You need to log in before you can comment on or make changes to this bug.