Bug 49114 - /etc/issue not updated during upgrade 7.1->7.2beta
/etc/issue not updated during upgrade 7.1->7.2beta
Product: Red Hat Linux
Classification: Retired
Component: redhat-release (Show other bugs)
ia64 Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-07-13 18:17 EDT by Ben Levenson
Modified: 2014-03-16 22:21 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-21 12:13:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ben Levenson 2001-07-13 18:17:58 EDT
Description of Problem:

build qa0713.1

/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-13 22:25:25 EDT
Is there an /etc/issue.rpmnew?
Comment 2 Michael Fulbright 2001-07-16 11:25:57 EDT
Putting bug in NEEDINFO state.
Comment 3 Glen Foster 2001-07-16 14:53:09 EDT
This defect considered MUST-FIX for Fairfax gold-release.
Comment 4 Ben Levenson 2001-07-16 18:52:03 EDT
* /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 11:59:11 EDT
Looks like an initscripts issue.
Comment 6 Bill Nottingham 2001-07-17 12:02:49 EDT
Woohoo, a real, live, redhat-release bug.

Still thinking how to fix this.
Comment 7 Pekka Savola 2001-07-21 11:54:37 EDT
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 12:13:17 EDT
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 14:39:30 EDT
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.