Bug 49114

Summary:	/etc/issue not updated during upgrade 7.1->7.2beta
Product:	[Retired] Red Hat Linux	Reporter:	Ben Levenson <benl>
Component:	redhat-release	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	low	Docs Contact:
Priority:	medium
Version:	7.3	CC:	pekkas, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	ia64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-07-21 16:13:21 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:

Description Ben Levenson 2001-07-13 22:17:58 UTC

Description of Problem:

build qa0713.1
anaconda-7.1.91-4.200107110300.ia64.rpm

/etc/issue still reads:

  Red Hat Linux release 7.1 (Seawolf)
  Kernel 2.4.3-12smp on an ia64

redhat-release and /proc/version indicate that the system is
running the proper kernel and release.

Comment 1 Bill Nottingham 2001-07-14 02:25:25 UTC

Is there an /etc/issue.rpmnew?

Comment 2 Michael Fulbright 2001-07-16 15:25:57 UTC

Putting bug in NEEDINFO state.

Comment 3 Glen Foster 2001-07-16 18:53:09 UTC

This defect considered MUST-FIX for Fairfax gold-release.

Comment 4 Ben Levenson 2001-07-16 22:52:03 UTC

* /etc/issue and /etc/issue.rpmnew are both present.
* /etc/issue contains the pre-upgrade kernel/release info
* here are the contents of /etc/issue.rpmnew:

   Red Hat Linux release 7.1.92 (Fairfax)
   Kernel \r on an \m

Comment 5 Michael Fulbright 2001-07-17 15:59:11 UTC

Looks like an initscripts issue.

Comment 6 Bill Nottingham 2001-07-17 16:02:49 UTC

Woohoo, a real, live, redhat-release bug.

Still thinking how to fix this.

Comment 7 Pekka Savola 2001-07-21 15:54:37 UTC

Happened to me too.

Wouldn't removing noreplace be sufficient?  Is (normally dynamically) created
/etc/issue* considered fair game for removing?

Comment 8 Bill Nottingham 2001-07-21 16:13:17 UTC

Hm, maybe. But if they change it, there's no need to replace it.
So, what you'd want is:

%config  (first time it's installed)
%config(noreplace)  all subsequent times

Of course, you can't implement this this way, since you never know at what
point will be the first time they install it.

Comment 9 Bill Nottingham 2001-07-23 18:39:30 UTC

Actually, you *can* implement it that way - fun with triggers!
Will be fixed in the next beta release.