Stephen Smalley wrote:
On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote:
So I'm still stumbling along in the dark trying to get livecd-creator to build me a nice new F10 image inside an F10 host. I've actually got an image that built and runs, but not without its issues.
my kickstart file has: auth --enableshadow --enablemd5 rootpw redhat
As Bill said, the handling of rootpw is non-intuitive from a historical kickstart perspective. I once suggested changing the kickstarts in livecd-tools to explicitly have rootpw lines (and then nuke the pw in %post), such that they would be generic fully automated kickstarts. People disagreed. (though what you observed is a bug that can be fixed without heeding my suggestion)
- When booting I get 3 messages that say:
inode_doinit_with_dentry: no dentry for dev=dm-0 ino=8345 The 3 inodes in question correspond to /etc/udev /etc/udev/rules.d /etc/udev/rules.d/50-udev-default.rules
Happens when SELinux is setting up pre-existing inodes upon initial policy load and it cannot find a dentry for the inode and thus cannot invoke the ->getxattr method on it. Likely harmless. When/if the files are subsequently looked up, the inodes should get set up at that time upon the d_instantiate/d_splice_alias.
I've seen these messages forever, though didn't realize till now that they were an selinux related issue. If they are truly harmless, can someone remove the code that spits out the message please?
FYI- note that what is going on with that file is that it is being modified by the initramfs before policy is loaded-
see do_live_from_base_loop in /usr/lib/livecd-creator/mayflower, i.e. stuff like this-
echo "KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", ATTRS{media}=="cdrom", PROGRAM="/lib/udev/vol_id -l %N", RESULT=="$CDLABEL", SYMLINK+="live"" >> /sysroot/etc/udev/rules.d/50-udev*
no clues where this is coming from. I don't see it when I booted my host system....
Anyway, at this point I want clues/help/suggestions on how to create my hacked up /selinux inside the chroot.
Out of curiosity, if someone feels like answering- are there any plans for selinux to support chroots in the sense of policy and even enabled/disabled being completely different between the host and the chroot? Seems like "chroot /mnt/sysimage rpm <some rpm commoand>" ought to 'just work(tm)'. But maybe I'm expecting too much functionality from a default fedora system.
-dmc