Bug 49114 - /etc/issue not updated during upgrade 7.1->7.2beta
Summary: /etc/issue not updated during upgrade 7.1->7.2beta
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-release
Version: 7.3
Hardware: ia64
OS: Linux
medium
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-13 22:17 UTC by Ben Levenson
Modified: 2014-03-17 02:21 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-07-21 16:13:21 UTC
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.