Bugzilla – Bug 115936
Update (from beta2) to RC1 didn't boot
Last modified: 2005-09-09 13:33:27 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
Created attachment 49254 [details] Yast logfiles
Let's assign it to Jiri who seems to deal with such kind of problems.
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...
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.
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...
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
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.
AFAIK Michael didn't ran YaST again, but he should know for sure ;)
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...
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 :(
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.
I see, thanks.
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.