Jack Holden wrote:
Dan
wrote:
Jack Holden wrote:
I am running FC5 with the 2.6.15-1.2054
kernel and mkinitrd-5.0.32. When I try to create a new initrd,
mkinitrd fails with the error:
/sbin/mkinitrd: line 975: initrd-2.6.15-1.2054_FC5.TEST.img
Permission denied
I've tried using different file names with the same result. I've also
tried when logged in as root from the initial login (boot level 3) as
well as via su from both the cli and xterm. Same thing. I've also
tried building the initrd in the /boot and /root directories.
I believe that this is the version of mkinitrd that was included with
the installation. I have updated everything via yum update, but I
can't run the 2.6.16-2080 kernel yet (problem with dmraid). I have the
source packages for 2.6.15-2054 and 2.6.16-2080 installed. I have
successfully created initrd's before with this system, but I can't
remember if it was before or after yum update. (I think it was after
because it was an attempt to fix the dmraid problem with 2.6.16-2080.)
Can anyone suggest a fix or something to look at? I've looked at
mkinitrd and didn't see anything alarming about line 975. I appreciate
any advice.
Thanks,
Jack Holden
Perhaps an SELinux issue. I don't know how to use it so check the vast
numbers of posts on this list about fixing those issues. Look in your
logs for avc denied messages.
-Dan
The suggestions I've gotten so far:
1 - Is /boot mounted as read only?
I hate to admit this, but I don't set my systems up with separate
partitions. Everything is mounted under / (except SWAP). The file
system is mounted as read + write, and I've tried making the initrd in
/root and /boot with the same results.
2 - Could it be an SELinux problem?
It's possible. I'm not much of an SELinux expert. However, I disabled
SELinux during the initial installation, and I think it's still
disabled. I checked the config file in /etc/selinux and it still
appears to be disabled.
Is anyone else having this problem? TIA.
Thanks,
Jack Holden
Turns out this was a bone-head problem. I started digging around in
the mkinitrd script and realized that the script isn't path aware.
Target files like ./initrd.img are not created in the directory from
which you run the script. The script ends up in the /sys directory by
the time it finishes putting the image file together. Line 975 runs
gzip on the image (which is in /tmp). The script will fail if the
target file doesn't point it away from /sys. So, targets like
/boot/initrd.img or /root/initrd.img will work, but ones like
initrd.img or ./initrd.img will fail.
Thanks to everyone who suggested things to look at. I hope this is
helpful to someone else down the road.
Jack Holden
|
