Description of problem: We need to do unattended upgrades of our OS. We cannot ask our clients to fiddle with CDs or USB sticks in the middle of the night. Nor can we depend on them having internet connectivity. The way we've done this in the past is to distribute new boot CDs that contain the new rpms and copy them to the hard drive ahead of time. We also install a kickstart file that points to this CD image. Then, at the proper time, we force a reboot that will perform the upgrade. Our current version of anaconda will attempt to do the upgrade without mounting the partition (in our case /var) that holds the CD image. Thus everything that should have been installed in /var ends up in / instead. Version-Release number of selected component (if applicable): anaconda-11.1.2.168-1.el5 How reproducible: Every time. Steps to Reproduce: 1. Copy a boot image to some partition on the system. 2. Create a kickstart file that contains 'upgrade' and 'harddrive --partition= --dir=' that points to this image. 3. Create a grub entry that points at this kickstart file, and make it the default. 4. Reboot. Actual results: The files on the partition that holds the image are not upgraded. In our case, the upgrade fails, because there isn't enough room on the root partition to hold both its files and /var's files as well. Expected results: All partitions should be upgraded. Additional info:
partitions holding the install (or in this case, upgrade) media are marked as protected and may not be mounted read-write. This is a protective measure. It prevents anything from happening to the ISO images while anaconda has them in use. On installs, it's of obvious importance - without marking them protected, the user or autopart could choose to format the partition and therefore erase the installation media. On upgrades, it's a little less obvious. However, keep in mind that package scripts can do basically anything they want. This could include destructive behavior that destroys the installation media. Examples of this could be renaming or even deleting the directory containing the ISO images, removing the contents of that directory, etc. anaconda cannot anticipate all possibilities that the package scripts or the user could be doing, so it must mark the partition as protected.
(In reply to comment #1) > partitions holding the install (or in this case, upgrade) media are marked as > protected and may not be mounted read-write. This is a protective measure. It > prevents anything from happening to the ISO images while anaconda has them in > use. On installs, it's of obvious importance - without marking them protected, > the user or autopart could choose to format the partition and therefore erase > the installation media. > > On upgrades, it's a little less obvious. However, keep in mind that package > scripts can do basically anything they want. This could include destructive > behavior that destroys the installation media. Examples of this could be > renaming or even deleting the directory containing the ISO images, removing the > contents of that directory, etc. anaconda cannot anticipate all possibilities > that the package scripts or the user could be doing, so it must mark the > partition as protected. What then is the proper procedure for doing an unattended upgrade?
You could put your ISO images on an external USB disk. You could put them on an NFS server. Both of these are expressable in kickstart.