Bug 526308 - Anaconda kickstart upgrade fails to upgrade the partition that the CD image resides on
Summary: Anaconda kickstart upgrade fails to upgrade the partition that the CD image r...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-29 18:43 UTC by Ali Corbin
Modified: 2009-09-30 17:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-30 14:22:43 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.