Bug 115936 - Update (from beta2) to RC1 didn't boot
Summary: Update (from beta2) to RC1 didn't boot
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: YaST2 (show other bugs)
Version: RC 1
Hardware: Other All
: P5 - None : Blocker
Target Milestone: ---
Assignee: Jiri Srain
QA Contact: Klaus Kämpf
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-08 18:07 UTC by Michael Matz
Modified: 2005-09-09 13:33 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Yast logfiles (321.80 KB, application/x-tgz)
2005-09-08 18:08 UTC, Michael Matz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Matz 2005-09-08 18:07:30 UTC
I was updating from beta2 to RC1, and during updating Yast already told     
me that an "Error occurred during installation of GRUB", in a dialog box     
with that title but no other textual content, and just an Ok button.    
Then it gave me the option to return to the grub configartion which I did,   
but nothing strange was there (installation into MBR was chosen, like   
expected).  So I Okayed that too, the error came again, I was ignoring it,   
and when I wanted to boot into the updated system I just got an "No operating   
system found".  I had to get to the rescue system and made the following  
observations:  
  
1) when just running "grub" it immediately returned to the shell with return 
   code 1: 
% grub 
% echo $? 
1 
   This means I couldn't use grub for anything, it wasn't accepting any 
   commands, and as shown didn't open the shell.  It turned out that this 
   was because /boot/grub/device.map existed, but was empty (!).  So 
   someone (yast? grub itself?) destroyed it while updating.  I removed 
   it and went on. 
 
2) grub wasn't accepting the commands in /etc/grub.conf, because 
   it mentioned "/dev/sda" in various places, instead of 
   "hd0" as it should have: 
% cat /etc/grub.conf 
root (/dev/sda,1) 
install --stage2=/boot/grub/stage2 /boot/grub/stage1 
(/dev/sda,1) /boot/grub/stage2 0x8000 (/dev/sda,1)/boot/grub/menu.lst 
install --stage2=/boot/grub/stage2 /boot/grub/stage1 
(/dev/sda) /boot/grub/stage2 0x8000 (/dev/sda,1)/boot/grub/menu.lst 
quit 
 
   That it contains two commands is a bit strange, but so be it. 
   So I fixed also that (replaced /dev/sda with hd0), and I was able to 
   reinstall grub via "grub < /etc/grub.conf".  Then I booted, but 
   it still wasn't solved, because: 
 
3) grub started, but didn't find the message file or the kernel, 
   because also /boot/grub/menu.lst contained /dev/sda in places where 
   it needs to use hd0 (I spare us the inline of that file here). 
   So I fixed that too, and _then_ could finally boot into my system. 
 
I will attach the Yast2 logs I gathered during the update.  At the end of 
y2log (where it deals with the bootloader) there are some strange outputs, 
like: 
 
2005-09-08 20:31:14 <2> linux(10149) [agent-ini] 
IniParser.cc(UpdateIfModif):835 Data file '/etc/sysconfig/bootloader' was 
changed externaly! 
2005-09-08 20:31:15 <3> linux(10149) [bash] ShellCommand.cc(shellcommand):78 
249 blocks 
2005-09-08 20:31:15 <3> linux(10149) [bash] ShellCommand.cc(shellcommand):78 
rm:  missing operand 
2005-09-08 20:31:15 <3> linux(10149) [bash] ShellCommand.cc(shellcommand):78 
Try `rm --help' for more information. 
2005-09-08 20:31:15 <3> linux(10149) [bash] ShellCommand.cc(shellcommand):78 
rm: missing operand 
2005-09-08 20:31:15 <3> linux(10149) [bash] ShellCommand.cc(shellcommand):78 
Try `rm --help' for more information. 
2005-09-08 20:31:15 <3> linux(10149) [bash] ShellCommand.cc(shellcommand):78 
311 blocks 
2005-09-08 20:31:15 <1> linux(10149) 
[scr] ../../libscr/src/include/scr/Y2AgentC 
omponent.h(evaluate):108 Evaluating an expression, not SCR builtin
Comment 1 Michael Matz 2005-09-08 18:08:54 UTC
Created attachment 49254 [details]
Yast logfiles
Comment 2 Michael Matz 2005-09-08 18:09:59 UTC
Let's assign it to Jiri who seems to deal with such kind of problems. 
Comment 3 Jiri Srain 2005-09-09 07:30:57 UTC
2) and 3) are direct results of 1) 
 
Ad 1) The device map has not been transfered correctly from the 
perl-Bootloader library to YaST. Unfortunatelly, I can't get from the logs 
why. Do you - by chance - have the original device map backed-up? I feel it 
could be caused by something void inside the file... 
Comment 4 Jiri Srain 2005-09-09 08:06:15 UTC
I forgot that the originel device.map file is kept 
as /boot/grub/device.map.old (unless you ran YaST again after the unsuccessful  
update). So hope it won't be problem to get it. 
Comment 5 Jiri Srain 2005-09-09 11:28:58 UTC
I tested the update Beta4->RC1 (I don't have any older image in Prague). The 
update was done without any problem, the device map was read correctly. 
 
So, I have no clue what could have caused this problem... 
Comment 6 Christoph Thiel 2005-09-09 12:36:45 UTC
Jiri, unfortunately device.map.old is empty on Michas box. I just checked it to
keep things moving...:

-rw-------  1 root root      0 2005-09-08 20:31 device.map.old
Comment 7 Jiri Srain 2005-09-09 12:39:54 UTC
I am logged there in, but thanks anyway. 
 
It may have two reasons: 
1. device.map was empty before update (bug is INVALID) 
2. Michael ran YaST again (we dont' know anything) 
 
I talked to AJ, I will workaround this bug (if empty device map is read from 
disk, it is automatically proposed). This is safe not to break anything. 
Comment 8 Christoph Thiel 2005-09-09 12:42:08 UTC
AFAIK Michael didn't ran YaST again, but he should know for sure ;)
Comment 9 Jiri Srain 2005-09-09 12:45:00 UTC
Then the bug could be marked as invalid. But as YaST reconstructs during 
update a lot of configuration options anyway, I find it good idea to check for 
empty device map. Another issue is that we don't know how the device map got 
empty... 
Comment 10 Michael Matz 2005-09-09 12:55:25 UTC
I did not run Yast again, after fixing.  When I first logged in to the rescue 
system to fix grub, the device.map.old was already empty.  It was the first 
I looked into because I hoped that it would contain a saved copy of the 
old working one.  But it didn't.  I also looked at the timestamps of that 
file, in order to see, if it was even touched by the install process, and 
indeed it was: 
-rw-r--r--  1 root root 30 2005-09-08 20:47 /boot/grub/device.map 
-rw-------  1 root root  0 2005-09-08 20:31 /boot/grub/device.map.old 
 
20:31 was about the time I installed the machine.  So Yast did write 
and empty device.map.old.  I of course don't know anymore if the 
original device.map _before_ update was empty.  And that also can't 
be reconstructed anymore :( 
Comment 11 Jiri Srain 2005-09-09 13:23:43 UTC
It was because when you got the fail during upadte, you tried it once more. 
So, "mv device.map device.map.old" was done twice. I forgot abuot it, sorry. 
 
The workaroudn I will submit in a moment will make sure that there won't be 
ampty map written during update. 
Comment 12 Michael Matz 2005-09-09 13:28:26 UTC
I see, thanks. 
Comment 13 Jiri Srain 2005-09-09 13:33:27 UTC
Workaround submitted. As I can't learn what was in original device.map, this 
is the only fix I'm able to provide, therefore closing as FIXED.