Description of problem: When %post scripts are about to be run (especially if they chroot'd), they won't see /mnt/source (even with the patch for bug #191819 applied). Version-Release number of selected component (if applicable): How reproducible: Run an install with the ks.cfg file containing "mount" in the "%post" section. Steps to Reproduce: 1. Build a DVD install disque with a ks.cfg file, and put "mount" (with no arguments) and "ls -l /mnt/source" into the "%post" section. 2. Do an install. 3. From the logs, you'll be able to see that the DVD media was mounted, but the directory it was mounted on isn't visible. Actual results: The directory /mnt/source isn't accessible from the chroot'd environment. Expected results: The DVD media should be mounted in such a way that both chroot'd and not %post-scripts can see it. A symlink from /mnt/source to /mnt/sysimage/mnt/source might be required so that non-chroot'd scripts can run symmetrically. This is a short-hand, but isn't strictly necessary. Additional info:
I ran the following two script fragments with some success: %pre mount | awk '/ on \/mnt\/source type iso9660/ { print $1}' > /tmp/dvd_device %post --nochroot # this is set up via the %pre script... though it's always /tmp/cdrom # for the block device from what I can tell. dvd="`cat /tmp/dvd_device`" # this should be done by the PostInstall method for us in Anaconda. mkdir /mnt/sysimage/mnt/source umount /mnt/source rmdir /mnt/source mount -t iso9660 -o ro $dvd /mnt/sysimage/mnt/source ln -s /mnt/sysimage/mnt/source /mnt/source So this should be viable when done directly by Anaconda.
Doing this breaks expectations of people -- /mnt/source isn't going to exist on the real system. Also, it's not going to work with non-CD install methods.
I'm not sure I get this... Lots of things happen during the install portion, including your modprobe.conf file living in /tmp. Everyone already has the explicit understanding that the install environment is different. What "real system" are you talking about? And if the filesystem is linked as /mnt/source pointing to /mnt/sysimage/mnt/source then previous scripts that expected it on /mnt/source (in the non-chrooted scripts) will continue to see it there. This will also work with NFS .iso mounts.
Though his example was flawed, his idea I think is reasonable, and that is wherever the media came from make its mount available in the chroot environment. Symlinks of course wouldn't work, but bind mounts would.
Philip, please keep comments related to this bugzilla in the bugzilla and not in personal emails. If you want your comments to be heard, I suggest you repost them here or on an appropriate email list.
Umm... that's w(In reply to comment #5) > Philip, please keep comments related to this bugzilla in the bugzilla and not in > personal emails. If you want your comments to be heard, I suggest you repost > them here or on an appropriate email list. That's what I did in comment #3, which was never answered.
Created attachment 130239 [details] Proposed fix (doesn't detect failure) As John suggested.
On second thoughts, there might be a cleaner place to put this that only involved .iso images (i.e. CD, DVD, or NFS mounted .iso images). Suggestions?
How did this get closed and marked won't fix without any annotation or commentary?
This was closed in 2006 by someone who is no longer working on anaconda, and I have no idea what the reason was. Are you still seeing the same behavior on the current release of Fedora? If so, update your patch and we can discuss things again.