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)
3) 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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
