Bug 140695
| Summary: | Beta 2 doesn't support upgrade | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | John Summerfield <debian> |
| Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED NOTABUG | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | jturner, nobody+pnasrat |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-11-24 15:04:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Red Hat has never supported upgrading from one beta to another. There's simply too many things which can go wrong, as ABIs change and packages come and go in the release. That having been said, RHN does support the notion of running 'up2date' in order to move from one package set to another, and that includes between betas as well as between releases. That's the recommended way to do what you're speaking of. Please reconsider this for future releases of Anaconda. I don't know how I stand with RHN, but I don't have the bandwidth to use it for this anyway. I'm unconvinced with the explanation of why Ananconda can't do it, especially when you say that RHN can. Supporting this would also give you valuable feedback, especially when it fails in unexpected ways. Having anaconda do it and having RHN do it are two, very dissimilar operations. RHN is running on a live system and therefore can throw errors, refuse to install packages which will result in conflicts, prompt the user if they really want to do X (blow away a config, overwrite some system setting, etc.) Anaconda is a program to lay down packages and configure a machine. During a beta cycle, it's not uncommon for us to toss out a new version of a package to see if it has legs, then decide in the next spin that it's not going to work out and pull it, thus leaving the machine in a state where it has a newer package, but we really want it to go back to having the old package. Similar problems can occur when we break ABI or completely change the config file format for a particular package. So, there's a much higher chance that an anaconda upgrade from one beta to another isn't going to come back post-upgrade. That's just the nature of the beast when you're dealing with beta software. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Epiphany/1.3.8 Description of problem: I wanted to upgrade DT beta 1 to DT beta2 to test that feature and as a convenient way to upgrade to the more recent packages. Version-Release number of selected component (if applicable): beta2 How reproducible: Always Steps to Reproduce: 1. Install beta1 DT 2. Boot Beta2 DT 3. Progress to where the install or upgrade choices should be Actual Results: I found dialogue to choose disk partitioning. Expected Results: Dialog to choose whether to upgrade or install Additional info: I'm testing/evaluating this software in a location where significant downloads are viable. For this reason I hoped to be able to upgrade to beta 2. Similarly, many years ago it was valid to upgrade a release of RHL to the same release. I wished to do this to rectify deficiencies in the RHEL Beta2 AS install, but as I cannot upgrade beta1 to beta2 I don't propose to try that.