Bug 866258 - GRUB2: randomly freezing while edit kernel-params
GRUB2: randomly freezing while edit kernel-params
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-14 17:58 EDT by Harald Reindl
Modified: 2013-08-01 05:02 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1365735 (view as bug list)
Environment:
Last Closed: 2013-08-01 05:02:29 EDT
Type: Bug
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 Harald Reindl 2012-10-14 17:58:20 EDT
GRUB2 is freezing randomly on my machines if i try to edit kernel-params before boot, i never saw a boot-load freezing randomly machines before F17

so why F18/Rawhide has grub2-2.00-9.fc18 and F17 stays on grub2-2.0-0.38.beta6.fc17?

as explained in https://bugzilla.redhat.com/show_bug.cgi?id=866257 this should NOT be a problem for 99% of the userbase because as long they do not make grub2-mkconfig/grub2-install they still stay on the old one
Comment 1 Mads Kiilerich 2012-10-14 18:06:01 EDT
Nobody else has reported any issue like that.

Please confirm that you successfully have run grub2-install and grub2-mkconfig with your current grub version.

Please attach a photo showing exactly where it is freezing.
Comment 2 Harald Reindl 2012-10-14 18:11:57 EDT
because only few people changing kernel-params at boot as i do also not regulary
for me it freezed while try to debug https://bugzilla.redhat.com/show_bug.cgi?id=843826 several times, also this problem seems to be a grub-related race-condifition

yes, i can confirm that grub2 in the beta6 version is installed on all 4 RAID1-boot-devcies, otherwise i would not see the beta6 version on top of the grub-menu

no - i can not show you a photo for several reasons:
* this is a server, i refuse to reboot it just-for-fun
* it doe snot freeze always
* you do not see anything on a photo

what do you imagine will a foto show you after the machine is freezed while you are mvong with the cursor keys in the kernel-line until it no longer accepts any keystroke before you hard powoff the machine?
Comment 3 Mads Kiilerich 2012-10-14 18:37:20 EDT
There has been other beta6 packages that didn't have the patches the current packages have. Please confirm that you successfully have run grub2-install and grub2-mkconfig with your current grub version.

So far you have provided zero information - except for claiming that what works for everybody else doesn't work for you. A photo would give a starting point.
Comment 4 Harald Reindl 2012-10-14 18:45:50 EDT
again: i can confirm you that EVERYTIME yum updates the grub2 package i do 

grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda
grub2-install /dev/sdb
grub2-install /dev/sdc
grub2-install /dev/sdd

as i said it happens RANDOMLY, otherwise i would not have been able to boot my machine with 3.5.x kernels and write a bugreport that "nomodeset" would skip the race-condition - BUT i needed THREE attempts to edit the command-line

EVERYBODY else does 
a) not edit the command-line as i do also NOt regulary
b) as it happens randoly it means nothing
c) everybody may not have as long kernel-lines as i have
d) it doe snot matter at all - there is a FINAl release
   there is a reson why upstream made a final release
   there is NO reason leave F17 on a BETA
e) there is no singel reason to stay with any package on a beta 
   after a final release from upstream came out

what is so complicated to update grub2?
it doe sNOt affect anybody as long he doe snot manually instal it in the MBR, before this happens the apckage is lying around and nothing is changed
_____________

to see what i mean with "long kernel line"
an yes the rd_MD_UUID were or are needed to prevent staring the boot-RAID1 randomly degraded

root=UUID=b935b5db-0051-4f7f-83ac-6a6651fe0988 ro rd_MD_UUID=b7475879:c95d9a47:c5043c02:0c5ae720 rd_MD_UUID=1d691642:baed26df:1d197496:4fb00ff8 rd_MD_UUID=ea253255:cb915401:f32794ad:ce0fe396 rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=de_DE.UTF-8 elevator=cfq selinux=0 ipv6.disable=1 scsi_mod.scan=sync biosdevname=0 clocksource=hpet noisapnp noresume printk.time=0 nmi_watchdog=0 pcie_aspm=force i915.i915_enable_rc6=1 i915.semaphores=1 i915.i915_enable_fbc=1 intel_iommu=igfx_off consoleblank=0 acpi_osi=Linux SYSFONT=latarcyrheb-sun16 KEYTABLE=de-latin1-nodeadkeys
Comment 5 Mads Kiilerich 2012-10-14 18:52:48 EDT
Thank you for providing some of the information a photo would have provided.

Please also provide some of the other information a photo would have provided:

Are you using console, graphical or theme mode?

How big is the edit window?


Do you have any evidence that the issue should have been solved in the final 2.0 version?
Comment 6 Harald Reindl 2012-10-14 18:58:44 EDT
* console (no bg-images, no graphical crap)
* 1920x1080

i have no evidence but there must be a reason that the machine freezes sometimes while moving in long kernel-lines after using E to edit the kernel-params and it is not uncommon that small fixes are made between beta6 and final fixing it
Comment 7 Mads Kiilerich 2012-10-14 19:48:19 EDT
I was not asking what the screen resolution was - especially not if you are using console mode. How big is the edit window? That might be essential for reproducing the problem.

If you know for sure that you are using console mode then you must be using a customized /etc/default/grub. Please attach it and grub.cfg.


It is possible that the issue has been fixed in the month between beta6 and 2.0 ... or in the 3 months that has passed since 2.0.

Please test whether the problem really has been resolved in 2.0. If so then it is up to the packager to decide whether the fix should be backported, the package updated, or if the most safe solution is to workaround it by using a f18 rpm.
Comment 8 Harald Reindl 2012-10-14 19:55:55 EDT
[root@srv-rhsoft:/var/log]$ cat /etc/default/grub
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
# GRUB_TERMINAL="serial console"
# GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600"
GRUB_CMDLINE_LINUX="rd_MD_UUID=b7475879:c95d9a47:c5043c02:0c5ae720 rd_MD_UUID=1d691642:baed26df:1d197496:4fb00ff8 rd_MD_UUID=ea253255:cb915401:f32794ad:ce0fe396 rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=de_DE.UTF-8 elevator=cfq selinux=0 ipv6.disable=1 scsi_mod.scan=sync biosdevname=0 clocksource=hpet noisapnp noresume printk.time=0 nmi_watchdog=0 pcie_aspm=force i915.i915_enable_rc6=1 i915.semaphores=1 i915.i915_enable_fbc=1 intel_iommu=igfx_off consoleblank=0 acpi_osi=Linux SYSFONT=latarcyrheb-sun16 KEYTABLE=de-latin1-nodeadkeys"
GRUB_DISABLE_RECOVERY="true"

_________________________________________________________________


[root@srv-rhsoft:/var/log]$ cat /boot/grub2/grub.cfg 
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default="0"

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/b7475879c95d9a47c5043c020c5ae720'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='mduuid/b7475879c95d9a47c5043c020c5ae720'  b935b5db-0051-4f7f-83ac-6a6651fe0988
else
  search --no-floppy --fs-uuid --set=root b935b5db-0051-4f7f-83ac-6a6651fe0988
fi
    font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=de_DE
  insmod gettext
fi
#terminal_output gfxterm
set timeout=2
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (3.6.1-1.fc17.x86_64)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-b935b5db-0051-4f7f-83ac-6a6651fe0988' {
        savedefault
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod part_msdos
        insmod part_msdos
        insmod part_msdos
        insmod diskfilter
        insmod mdraid1x
        insmod ext2
        set root='mduuid/1d691642baed26df1d1974964fb00ff8'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='mduuid/1d691642baed26df1d1974964fb00ff8'  1de836e4-e97c-43ee-b65c-400b0c29d3aa
        else
          search --no-floppy --fs-uuid --set=root 1de836e4-e97c-43ee-b65c-400b0c29d3aa
        fi
        echo 'Linux 3.4.4-3.fc17.x86_64 wird geladen …'
        linux   /vmlinuz-3.6.1-1.fc17.x86_64 root=UUID=b935b5db-0051-4f7f-83ac-6a6651fe0988 ro rd_MD_UUID=b7475879:c95d9a47:c5043c02:0c5ae720 rd_MD_UUID=1d691642:baed26df:1d197496:4fb00ff8 rd_MD_UUID=ea253255:cb915401:f32794ad:ce0fe396 rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=de_DE.UTF-8 elevator=cfq selinux=0 ipv6.disable=1 scsi_mod.scan=sync biosdevname=0 clocksource=hpet noisapnp noresume printk.time=0 nmi_watchdog=0 pcie_aspm=force i915.i915_enable_rc6=1 i915.semaphores=1 i915.i915_enable_fbc=1 intel_iommu=igfx_off consoleblank=0 acpi_osi=Linux SYSFONT=latarcyrheb-sun16 KEYTABLE=de-latin1-nodeadkeys
        echo 'Initiale Ramdisk wird geladen …'
        initrd /initramfs-3.6.1-1.fc17.x86_64.img
}
submenu 'Erweiterte Optionen für Fedora' $menuentry_id_option 'gnulinux-advanced-b935b5db-0051-4f7f-83ac-6a6651fe0988' {
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_ppc_terminfo ###
### END /etc/grub.d/20_ppc_terminfo ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
Comment 9 Harald Reindl 2012-10-14 19:57:58 EDT
> Please test whether the problem really has been resolved in 2.0

AGAIN: 
i can and will not test around with GRUB bugs
there is a FINAL-RELEASE, F17 was shipped with a BETA release and so it HAS TO BE updated and not leave with a beta-version

it is really not understandable that it is no single problem for Fedora ship alpha/beta-quality in GA-releases but not update to final-versions
Comment 10 Mads Kiilerich 2012-10-14 20:13:47 EDT
So you edit your grub.cfg manually to disable gfxterm? A detail you haven't revealed before. There are no other manual changes?

F17 is stable. Upgrading critical components to "final" might make f17 less stable - especially if we don't know whether the upgrade will fix any problems.

You demand a risky upgrade for everyone, even without knowing whether it would solve your problem and you don't want to test it? In that case I suggest you stop using Fedora.
Comment 11 Harald Reindl 2012-10-15 02:50:48 EDT
> So you edit your grub.cfg manually to disable gfxterm? 
> A detail you haven't revealed before

because it is NOT relevant
the freezes in GRUB happened long before and this is complete different topic

> There are no other manual changes?

the same i did 10 years with GRUB1
* no graphical / background crap
* the same kernel-params

> F17 is stable. Upgrading critical components to "final" might 
> make f17 less stable

are you seriously?

> you don't want to test it?

WITH WHAT - THERE IS NO FUCKING BUILD FOR F17

> You demand a risky upgrade for everyone

bullshit - grub2 final oes not install itself magically in the MBR
i bet 90% of all users even do not have the beta6 installed and have their GRUB-version since first switched with F16 if they do not alwys fresh installs



with
Comment 12 Harald Reindl 2012-10-15 05:16:15 EDT
additionally the beta6 behaves completly wrong with passwords

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.*****************

in F16 it requested the password correctly only if you press "E"
in F17 currently if you do not touch anything and the default kernel is selected automatically to boot directly before the system starts i need to enter username nad password
Comment 13 Mads Kiilerich 2012-10-15 05:33:39 EDT
You seem to consider yourself more clever than the packagers, so I assume you are able to build your own rpms.

But the f18 rpms should work just fine on f17.
Comment 14 Harald Reindl 2012-10-15 05:45:11 EDT
grub2 in Fedora is currently broken
"--unrestricted" is not added by "grub2-mkconfig"

this means on remote-systems if you do not edit "grub.cfg" manually that you have lost the game and the machine doe snot boot

I ASSUME a as you say "crtitical package" should not have such bugs over months
Comment 15 Bert DeKnuydt 2012-10-15 06:29:19 EDT
I've got 'random freezes' in grub2 while editing too, on several occasions, on 
several (64bit) machines.

I was never able to reproduce reliably, but I did have the impression that it needed time, i.e., you type 'e', edit a bit, and wait (seconds, minutes), then resume editing and ... hang.

I am willing to test whatever you want, but without a proper way to reproduce, how to test?
Comment 16 Mads Kiilerich 2012-10-15 06:59:04 EDT
Yes, randomness everything hard ... even more so for the packager and developer.

But if several testers longer see any freezes after upgrading to 2.00 (for instance the f18 packages) then it is a strong indication that the problem has been solved there.
Comment 17 Fedora End Of Life 2013-07-03 22:39:55 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 '17'.

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 17'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 17 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, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

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.
Comment 18 Fedora End Of Life 2013-08-01 05:02:37 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.