Description of problem: After installing RHEL6.6 on ANY x86_64 system in beaker the menu.list soft link is broken. The system boots with [root@intel-chiefriver-04 ~]# ls -l /boot/grub/ total 278 -rw-r--r--. 1 root root 63 Dec 15 06:20 device.map -rw-r--r--. 1 root root 13396 Dec 15 06:20 e2fs_stage1_5 -rw-r--r--. 1 root root 12636 Dec 15 06:20 fat_stage1_5 -rw-r--r--. 1 root root 11780 Dec 15 06:20 ffs_stage1_5 -rw-------. 1 root root 922 Dec 15 06:20 grub.conf -rw-------. 1 root root 917 Dec 15 06:20 grub.conf.orig -rw-r--r--. 1 root root 11772 Dec 15 06:20 iso9660_stage1_5 -rw-r--r--. 1 root root 13284 Dec 15 06:20 jfs_stage1_5 -rw-------. 1 root root 922 Dec 15 06:20 menu.lst lrwxrwxrwx. 1 root root 11 Dec 15 06:20 menu.lst.orig -> ./grub.conf -rw-r--r--. 1 root root 11972 Dec 15 06:20 minix_stage1_5 -rw-r--r--. 1 root root 14428 Dec 15 06:20 reiserfs_stage1_5 -rw-r--r--. 1 root root 1341 May 6 2010 splash.xpm.gz -rw-r--r--. 1 root root 512 Dec 15 06:20 stage1 -rw-r--r--. 1 root root 126116 Dec 15 06:20 stage2 -rw-r--r--. 1 root root 12040 Dec 15 06:20 ufs2_stage1_5 -rw-r--r--. 1 root root 11380 Dec 15 06:20 vstafs_stage1_5 -rw-r--r--. 1 root root 13980 Dec 15 06:20 xfs_stage1_5 Version-Release number of selected component (if applicable): 0.18 (and in 0.19 AFAICT) How reproducible: 100% Steps to Reproduce: 1. install RHEL6 targets 2. ls -l /boot/grub Actual results: menu.lst is now a file. menu.list.orig is now a soft link to grub.conf. Expected results: menu.lst should be a soft link to grub.conf and menu.list.orig should not exist Additional info: caused by https://bugzilla.redhat.com/show_bug.cgi?id=1108498
Internal test scripts are failing. This needs to be fixed ASAP. menu.lst is a well documented file in grub. P.
This chunk of code in the kickstart # set --port for GRUB (0.9) for file in /boot/grub/grub.conf /boot/efi/EFI/redhat/grub.conf /boot/grub/menu.lst ; do if [ -e "$file" ] ; then sed --in-place=.orig -e 's/^\(serial.*\)--unit=\S\+\(.*\)$/\1--port=0x03f8\2/' "$file" fi done causes the error to occur. sed should not operate on a soft link, and instead should operate on the file link'd to (in this case grub.conf). For general purposes, however, I suppose a file test could be done on /boot/grub/menu.lst... In any case this is badly broken. P.
Change the sed line to sed --follow-symlinks --in-place=.orig -e 's/^\(serial.*\)--unit=\S\+\(.*\)$/\1--port=0x03f8\2/' menu.lst and things should work. P.
As you can see in BZ#1108498, the original patch didn't include "menu.lst". I think it was added for completeness to support non-RHEL distros, which don't have "grub.conf". How about this? We don't have to sed grub.conf twice if menu.lst is symlink. - if [ -e "$file" ] ; then + if [ -f "$file" ] ; then
Replying to myself, > - if [ -e "$file" ] ; then > + if [ -f "$file" ] ; then It doesn't work.. The following works for me with RHEL5.11/RHEL6.6/RHEL7.0: + if [ -f "$file" ] && [ ! -L "$file" ] ; then
(In reply to Prarit Bhargava from comment #0) > Actual results: > > menu.lst is now a file. menu.list.orig is now a soft link to grub.conf. What are the actual consequences to this? Does this break anything? I mean, I agree that the current behaviour of breaking the symlink is wrong and we will fix it ASAP as per Jun'ichi's comment 5 (thanks Jun'ichi!). I am just wondering, what actual observable problems does this cause? Because we did not hit any during testing for Beaker 19.0.
The snippet is only triggered when the grubport= ksmeta variable is set. So it only affects about 15% of the x86_64 systems in our Beaker installation. As a workaround you can try using ks_meta="!grubport" in your <recipe/>. This will unset any grubport= value inherited from the system install options, so the snippet won't appear in your kickstart. I think the only consequence is that GRUB output will not be written to the serial console.
(In reply to Dan Callaghan from comment #6) > (In reply to Prarit Bhargava from comment #0) > > Actual results: > > > > menu.lst is now a file. menu.list.orig is now a soft link to grub.conf. > > What are the actual consequences to this? Does this break anything? > > I mean, I agree that the current behaviour of breaking the symlink is wrong > and we will fix it ASAP as per Jun'ichi's comment 5 (thanks Jun'ichi!). I am > just wondering, what actual observable problems does this cause? Because we > did not hit any during testing for Beaker 19.0. menu.lst which is a _documented_ link in grub no longer works. ie) edits to menu.lst (which should point to grub.conf) no longer work. Tests fail. This is very very very bad. This is akin to breaking grub. P.
(In reply to Dan Callaghan from comment #7) > The snippet is only triggered when the grubport= ksmeta variable is set. So > it only affects about 15% of the x86_64 systems in our Beaker installation. So 15% of the systems in beaker are unusable with RHEL6 installs because edits to menu.lst fail. That's not acceptable. P. > > As a workaround you can try using ks_meta="!grubport" in your <recipe/>. > This will unset any grubport= value inherited from the system install > options, so the snippet won't appear in your kickstart. I think the only > consequence is that GRUB output will not be written to the serial console.
http://gerrit.beaker-project.org/3880
(In reply to Jun'ichi NOMURA from comment #5) > > - if [ -e "$file" ] ; then > > + if [ -f "$file" ] ; then > > It doesn't work.. Out of curiosity, where did you see this not work? I just tried test -f on RHEL3,5,6,7 and it behaves as you would expect (returns false for a symlink to a file).
(In reply to Dan Callaghan from comment #11) > Out of curiosity, where did you see this not work? I just tried test -f on > RHEL3,5,6,7 and it behaves as you would expect (returns false for a symlink > to a file). For example, on RHEL6, # rpm -q bash coreutils bash-4.1.2-29.el6.x86_64 coreutils-8.4-37.el6.x86_64 # ls -l /boot/grub/menu.lst lrwxrwxrwx. 1 root root 11 Apr 19 2012 /boot/grub/menu.lst -> ./grub.conf # file=/boot/grub/menu.lst # [ -f $file ]; echo $? 0 # [ -f $file ] && [ ! -L $file ]; echo $? 1 Also in test(1) man page, there is: Except for -h and -L, all FILE-related tests dereference symbolic links.
(In reply to Jun'ichi NOMURA from comment #12) Ah I see. I was testing with a symlink to a directory by mistake.
Beaker 19.2 has been released.