Bug 526308

Summary: Anaconda kickstart upgrade fails to upgrade the partition that the CD image resides on
Product: Red Hat Enterprise Linux 5 Reporter: Ali Corbin <ali_corbin>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact: Release Test Team <release-test-team>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: ddumas
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-30 14:22:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Ali Corbin 2009-09-29 18:43:09 UTC
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:

Comment 1 Chris Lumens 2009-09-30 14:22:43 UTC
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.

Comment 2 Ali Corbin 2009-09-30 16:08:06 UTC
(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?

Comment 3 Chris Lumens 2009-09-30 17:11:58 UTC
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.