Bug 567266 - Software Update corrupts grub.conf when there is a new kernel and fails to backup grub.conf. Menu entries for Fedora booting different partition configurations get deleted. Amusingly default=1 is the 2nd menu item booting the OLD Kernel and NOT the NEW.
Software Update corrupts grub.conf when there is a new kernel and fails to ba...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
12
All Linux
low Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-22 08:38 EST by Tim Clutten
Modified: 2014-01-21 18:13 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 17:30:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Clutten 2010-02-22 08:38:55 EST
Description of problem:
default=0 incorrectly set to default=1 and other critical multi-boot 
menu entries deleted when there is a F12 kernel update.

On Fedora 12 (perhaps on Red Hat too)
System->Administration->Software Update 
(gpk-update-viewer software update of grub )
N.B.
  Once you know which component is corrupting /boot/grub/grub.conf
  please assign this bug report to the component owner.
 
When the update includes a new Kernel
and the old kernel is the first entry in grub.conf ( /boot/grub/menu.lst )
and default=0 refers to the first entry correctly; the update gets
it wrong with the newest 
kernel placed at the top of the grub.conf file as the first option
but default=0 is changed to default=1 which MAKES NO DIFFERENCE.
The OLD kernel is still booted!

MORE SERIOUSLY

Second problem multiboot entries for other Fedora linux systems 
ON TOTALLY DIFFERENT PARTITIONS, DROP OFF THE MIDDLE OF THE MENU SO 
THEY ARE DELETED, THIS IS A CRITICAL PROBLEM BECAUSE A BACKUP OF 
/boot/grub/grub.conf may not have been made by the user!

PLEASE GENERATE A BACKUP AND TELL THE USER WHERE IT IS IN 
# THE COMMENT LINE OF grub.conf 

Win7 and Vista multiboot entries are not touched which is correct.

Version-Release number of selected component (if applicable):
Fedora 12 dated 22 Feb 2010 fully patched (unknown component so please
assign this to component owner)

How reproducible:
Use this grub.conf file note that the kernel load line is wrapped on this
editor in grub.conf it is one long line.  This grub.conf works with 
nvidia 8800 graphics card hence the different arguments on the end but that
does not affect the test.
- - -- - - -- -- -- - - 
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/mapper/vg_ux-r
#          initrd /initrd-[generic-]version.img
#
# NVIDIA notes:
#
#
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
password --md5 $abcdABCD1234efghEFGHfakeExample
title Fedora (2.6.31.12-174.2.22.fc12.x86_64)
	password --md5 $abcdABCD1234efghEFGHfakeExample
	root (hd0,0)
	kernel /vmlinuz-2.6.31.12-174.2.22.fc12.x86_64 ro root=/dev/mapper/vg_ux-r  LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk rhgb quiet rdblacklist=nouveau vga=0×318
	initrd /initramfs-2.6.31.12-174.2.22.fc12.x86_64.img
title Fedora (2.6.31.12-174.2.19.fc12.x86_64)
	password --md5 $abcdABCD1234efghEFGHfakeExample
	root (hd0,0)
	kernel /vmlinuz-2.6.31.12-174.2.19.fc12.x86_64 ro root=/dev/mapper/vg_ux-r  LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk rhgb quiet rdblacklist=nouveau vga=0×318
	initrd /initramfs-2.6.31.12-174.2.19.fc12.x86_64.img
title Fedora (2.6.31.12-174.2.3.fc12.x86_64)
	password --md5 $abcdABCD1234efghEFGHfakeExample
	root (hd0,0)
	kernel /vmlinuz-2.6.31.12-174.2.3.fc12.x86_64 ro root=/dev/mapper/vg_ux-r  LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk rhgb quiet rdblacklist=nouveau vga=0×318
	initrd /initramfs-2.6.31.12-174.2.3.fc12.x86_64.img
# <-= AHHHHHHH MY OTHER FEDORA ENTRY WENT MISSING HERE!!!!!!!!!!!!!!
title Win7
	password --md5 $abcdABCD1234efghEFGHfakeExample
	rootnoverify (hd1,0)
	chainloader +1
title Vista2 to (hd2,0)
	password --md5 $abcdABCD1234efghEFGHfakeExample
	rootnoverify (hd2,0)
	chainloader +1

- - - - -- - - - -- - - - -- 
Start with this grub.conf this is my one - the password is NOT the same so
you must generate one yourself by hand by using grub-md5-crypt and past the
hashed seeded and mangled md5 value into your /boot/grub/grub.conf

Steps to Reproduce:
1. Start with this grub.conf or similar, this is my one - the hashed seeded password is NOT the same so you must generate one yourself by hand by using grub-md5-crypt and past the hashed md5 value into your /boot/grub/grub.conf every place it says $abcdABCD1234efghEFGHfakeExample - REMEMBER THE PASSWORD
keep it short because grub password is notoriously insecure anyway.
2. Next time there is a new kernel do Update Software and observe the results.
3. Assign bug report to the guilty party.
  
Actual results:

default=1
#first entry is the new kernel but the SECOND entry is the default 
# OOPS it is the second entry that boots NOT the first.
# You lose all your old Fedora menu entries off the end. BAD UGLY!
# Some were my alternative boots on DIFFERENT PARTITIONS.
# Vista or Win7 entries stay untouched. GOOD.

Expected results:
# default=0 is the FIRST ENTRY
default=0
# no missing menu items for things booting off different partitions
# or different versions of mounted /home or /var or (/) these do not go missing
# off the end

Additional info:  HIGH PRIORITY - AFFECTING RED HAT ALSO?
Comment 1 Bug Zapper 2010-11-03 17:35:47 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Bug Zapper 2010-12-03 17:30:30 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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