Red Hat Bugzilla – Bug 447273
mkinitrd has some bash and system compatibility issues
Last modified: 2009-05-06 11:00:22 EDT
Description of problem:
Lastest version of mkinitrd has some compatibility problems with older
distributions like RHEL 5.1 and CentOS 5.1.
Version-Release number of selected component (if applicable):
6.0.52 (or clone from git.fedoraproject.org)
Steps to Reproduce:
1. Install mkinitrd-6.0.52 under RHEL 5.1/CentOS 5.1.
2. Run /sbin/mkinitrd
usage: mkinitrd [--version] [--help] [-v] [-f] [--preload <module>]
[--force-scsi-probe | --omit-scsi-modules]
[--image-version] [--force-raid-probe | --omit-raid-modules]
[--with=<module>] [--force-lvm-probe | --omit-lvm-modules]
[--builtin=<module>] [--omit-dmraid] [--net-dev=<interface>]
[--fstab=<fstab>] [--nocompress] <initrd-image> <kernel-version>
(ex: mkinitrd /boot/initrd-2.2.5-15.img 2.2.5-15)
/sbin/mkinitrd: line 80: .: /etc/sysconfig/mkinitrd: is a directory
/sbin/mkinitrd: line 558: syntax error in conditional expression: unexpected
/sbin/mkinitrd: line 558: syntax error near `^(d'
/sbin/mkinitrd: line 558: ` if [[ "$device" =~ ^(dm-|mapper/) ]]; then'
Created attachment 305915 [details]
Patch to fix these issues
Oops, the "Actual results" and "Expected results" should be exchanged. My mistake.
Created attachment 305917 [details]
Created attachment 308991 [details]
fix all =~ syntax instances
Yes, this is for the =~ syntax .. but your patch doesn't do all of them. This
attachment is a fix for all lines that have a =~ which don't quote both
Is this same issue present in rawhide or a maintained Fedora release? We cannot collect RHEL or CentOS bugs under the "Fedora" product.
The suggested patches look safe and a good idea. We should include this patch.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
Newer verisons of mkinitrd aren't really intended to run on older RHEL releases. As we're moving towards dracut in the future, this is even more going to be the case (as we'll be depending on new kernel + udev bits)