Bug 12031 - Upgrading to M4RC creates duplicate grub entry of other O/S
Summary: Upgrading to M4RC creates duplicate grub entry of other O/S
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal minor
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard: 4RC
Keywords:
Depends on:
Blocks: 11979
  Show dependency treegraph
 
Reported: 2013-12-18 07:56 CET by Dick Gevers
Modified: 2014-01-15 17:22 CET (History)
0 users

See Also:
Source RPM: drakxtools
CVE:
Status comment:


Attachments

Description Dick Gevers 2013-12-18 07:56:34 CET
Description of problem:

* Install M3.1. This creates entries for linux, linux-nonfb, failsafe and a "shortcut" to an existing O/S's grub on different partition (current Cauldron actually).

* Upgrade using Mageia-4-beta2-x86_64-DVD.iso to M4B2 and new entries are created for the higher version kernel, but another, second entry is created in the grub menu.lst for current Cauldron.

As a result, the boot menu looks like this afterwards:

<old kernel>
<old kernel-nonfb>
<old kernel-failsafe>
<Cauldron>
<new kernel>
<new kernel-nonfb>
<new kernel-failsafe>
<Cauldron>

Could we please avoid the double shortcut to Cauldron's grub menu ?

Reproducible: 

Steps to Reproduce:
Dick Gevers 2013-12-18 07:56:51 CET

Whiteboard: (none) => 4beta2

Manuel Hiebel 2013-12-22 20:15:04 CET

Component: Installer => RPM Packages
Source RPM: Mageia-4-beta2-x86_64-DVD.iso => drakxtools

Manuel Hiebel 2013-12-22 20:45:40 CET

Assignee: bugsquad => thierry.vignaud

Dick Gevers 2014-01-07 05:54:25 CET

Blocks: (none) => 11979
Summary: Upgrading to M4B2 creates duplicate grub entry of other O/S => Upgrading to M4RC creates duplicate grub entry of other O/S
Whiteboard: 4beta2 => 4RC

Comment 1 Dick Gevers 2014-01-15 17:22:37 CET
During the earlier install to test upgrade I had changed the name of (installed)
"Mageia (Cauldron)" into "Cauldron" and a 2nd entry appeared on upgrade.

Today in another upgrade test I had left the name unchanged - obviously picked up from /etc/*release and there appears no extra entry for it.

So I'll close the bug as 'invalid' (although it is somewhat valid, but anyway :)

Status: NEW => RESOLVED
Resolution: (none) => INVALID


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