Ask Your Question

Trenin's profile - activity

2013-12-11 20:20:13 -0500 received badge  Famous Question (source)
2013-12-03 04:58:34 -0500 received badge  Famous Question (source)
2013-10-24 07:12:04 -0500 commented question FC18/19 cannot eject installation CD

The bug is an anaconda bug, and supposedly fixed in the current release (fc20) so I will try this out when it is stable. As for the boot order, it was floppy->cd->hd, so I switched it to cd->floppy->hd with no change. I am using a VirtualBox VM (hence the floppy).

2013-10-23 03:39:11 -0500 received badge  Notable Question (source)
2013-10-18 10:42:40 -0500 commented question FC18/19 cannot eject installation CD

The installation is on a server. I would like to avoid running back to the lab just to eject the cd. While that works, it is not ideal for our customers. In the past, they did not have to physically eject the cd because kickstart did it for them at the end of the install.

2013-10-18 10:40:50 -0500 commented question FC18/19 cannot eject installation CD

I don't think we are talking about the same thing. I am referring to the kickstart "reboot" directive found at --eject is documented as a valid flag for this directive. I think you are referring to the Linux "eject" and "reboot" commands.

2013-10-18 05:15:09 -0500 received badge  Notable Question (source)
2013-10-17 14:53:27 -0500 received badge  Popular Question (source)
2013-10-16 12:50:03 -0500 asked a question FC18/19 cannot eject installation CD


I have a custom fedora 18 installation CD which I've created to install fedora 18 with some additional packages with kickstart. The ks.cfg file contains the following line:

# Reboot after the installation and eject the CD
reboot --eject

However, after the reboot, the CD is not ejected and I am presented with the installation menu. At this point, I have to manually remove the CD and then reboot again. If I time it appropriately, I can remove the CD before it fully boots, but this is not ideal.

I want to eject the CD so that it doesn't try to install again.

All the bugs I saw for this look to be in FC 11 or earlier and all seem to be solved.

Does anyone know what logs I should check to debug this problem?


EDIT: I have tried this with fedora 19 and the same problem exists. The CD will not eject.

2013-10-16 12:25:59 -0500 answered a question fc18 custom install CD issues


I needed to make a change to the isolinux.cfg file to point to the cdrom for stage2. This mounted the disc properly so that the packages could then be seen!

append initrd=initrd.img inst.stage2=cdrom:CDLABEL=product ks=cdrom:/dev/cdrom:/ks.cfg biosdevname=0
2013-10-16 12:24:54 -0500 commented question fc18 custom install CD issues

Fixed! I had to make the following change to the isolinux.cfg file. append initrd=initrd.img inst.stage2=cdrom:CDLABEL=product ks=cdrom:/dev/cdrom:/ks.cfg biosdevname=0

2013-10-16 02:42:19 -0500 received badge  Popular Question (source)
2013-10-15 07:05:14 -0500 received badge  Notable Question (source)
2013-10-12 22:17:16 -0500 commented question fc18 custom install CD issues

There is no part referring to repos. It wasn't required in Fedora 16, so I don't have it now. Simply saying 'CDROM' was enough for it to install from the DVD in Fedora 16, but no longer. Now, when I did try faking it out for fedora 18, I had 'repo --name=all --baseurl=/run/initramfs/live' and it recognized the repo on the CD and installed the custom packages, but only if the network was enabled. If I disabled the network, it failed with the above error even though all the required packages were on the DVD.

2013-10-11 13:24:13 -0500 asked a question fc18 custom install CD issues


I am trying to create an installation CD for Fedora 18 containing some base fedora packages plus a few of our own packages. It is a fairly minimal installation, so it doesn't include a lot of extras.

We've been able to do this quite easily with fedora 16 and earlier, but we are having quite a lot of trouble with fedora 18.

When we create a network installation DVD, everything seems to work fine. We point the repos to our local repositories which are hosting all of the fedora rpms and our custom rpms. The only issue is that the kickstart directive "reboot --eject" seems to be ignored. The DVD is not ejected, so on the next boot, the installation starts all over unless we manually remove the DVD.

The bigger issue is for the self contained DVD. Our isolinux.cfg file is as follows:

kernel vmlinuz
append initrd=initrd.img root=live:CDLABEL=product ks=cdrom:/dev/cdrom:/ks.cfg biosdevname=0

The kickstart file is as follows:

selinux --disabled
auth --enableshadow --passalgo=sha512
# Use CDROM installation media
lang en_CA.UTF-8
# Run the Setup Agent on first boot
#firstboot --enable
keyboard --vckeymap=us --xlayouts='us'
# Network information
network --device=p2p1 --bootproto=dhcp --onboot=on --activate
# Root password
rootpw  --iscrypted <encrypted password>
# System timezone
timezone US/Eastern --isUtc
# System bootloader configuration
bootloader --location=mbr --boot-drive=sda
# Partition clearing information
# Eject the disk after boot
reboot --eject
xconfig --startxonboot
# Packages
%packages --excludedocs --nobase

The installation seems to start, but it is very slow, and our custom packages are not picked up. It turns out that it is ignoring the installation disc and using the online yum repositories instead defined in /etc/anaconda.repos.d!

If I disable the network to try to force it to use the disc, then it complains about not having a valid installation source. If I click on that and verify, verification seems to say it is valid, but the main page still says there is an invalid installation source. I see the following messages in /tmp/packaging.log:

DEBUG packaging: getting release version from tree at file:///mnt/install/source (18)
DEBUG packaging: retrieving treefinfo from file:///mnt/install/source (proxies: {} ; sslverify: True)    
INFO packaging: Error downloading treeinfo: [Errno 14] Could not open/read file:///mnt/install/source/treeinfo
ERR packaging: base repo (cdrom/file:///mnt/install/source) not valid -- removing it

I have verified that /mnt/install/source is in fact empty, but I don't understand why it is looking there. The files are on the DVD in the Packages directory, and a repo was created, so there is a valid repodata directory as well on the DVD.

I have tried adding a manual repo to /run/initramfs/live in the ks.cfg (since that location seems to have a copy of the DVD), and while that seems to work when the online repos are working (i.e. custom packages are recognized), if I disable online repos ... (more)

2013-10-09 08:03:46 -0500 received badge  Popular Question (source)
2013-10-04 11:28:43 -0500 answered a question Resolving file conflicts FC18

Fixed by ensuring the permissions on the directories were the same.

2013-10-04 10:02:48 -0500 received badge  Editor (source)
2013-10-04 09:56:58 -0500 asked a question Resolving file conflicts FC18


I am working on a project that started in fc12. We are now upgrading our servers to fc18 and have an installation problem.

We have two packages, both of which have the following lines in their spec files:

install -d -m 0755 ${RPM_BUILD_ROOT}%{apphome}/conf

Both packages store files in this directory as follows:

Package 1:
install -m 0600 conf/pkg1.cnf ${RPM_BUILD_ROOT}%{apphome}/conf

Package 2:
install -m 0600 conf/pkg2.cnf ${RPM_BUILD_ROOT}%{apphome}/conf

Similarily, both have portions in the %files sections:

Package 1:
%dir %{apphome}/conf

Package 2:
%dir %{apphome}/conf

When I attempt to install these with a fresh install using anaconda, I get errors of the following form in /tmp/packaging.log:

ERR packaging: file /apphome/conf conflicts between attempted installs of pkg1.i386 and pkg2.i386.

How can I resolve this?

Here is what I tried so far: - remove the "%dir" lines from one of the packages - no effect - same errors - remove the "install -d" lines from one of the packages - buildrpm fails when trying to store files in the directory

Is it a permission problem? Do I simply need to make sure both packages are creating the directory with the same permissions?

FIXED I was able to resolve by making sure the permissions on the directories were the same in both packages.