|
Bugzilla – Full Text Bug Listing |
| Summary: | Check the process for boot loader restoration | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Markus Elfring <Markus.Elfring> |
| Component: | YaST2 | Assignee: | Josef Reidinger <jreidinger> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Critical | ||
| Priority: | P3 - Medium | CC: | forgotten_nqeDWc8OMK, jreidinger, jsuchome, mvidner |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 11.0 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Protocol from the installation system of the openSUSE 11.0 DVD | ||
|
Description
Markus Elfring
2008-07-13 18:22:29 UTC
root@Knoppix:~# mkdir /mnt/B && mount /dev/sda2 /mnt/B && grub-install --root-directory=/mnt/B /dev/sda2 You shouldn't call /sbin/grub-install. Please call /usr/sbin/grub-install instead! Due to a bug in xfs_freeze, the following command might produce a segmentation fault when /mnt/B/boot/grub is not in an XFS filesystem. This error is harmless and can be ignored. xfs_freeze: specified file ["/mnt/B/boot/grub"] is not on an XFS filesystem Installation finished. No error reported. This is the contents of the device map /mnt/B/boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. (fd0) /dev/fd0 (hd0) /dev/sda (hd1) /dev/sdb I am curious if the annoying boot hiccup was resolved by this command ... Now I can boot into the Ncurses (text) interface of GNU GRUB 0.97. I hope that the GParted tool will be improved so that no boot loader files will be damaged because of a partition adjustment. I am still interested to reactivate the eye-candy graphical boot theme. When will the YaST rescue system on the installation CD/DVD be able to completely restore the customised GRUB settings? (It appears strange to me that it could not find the root partition while Knoppix 5.3.1 could handle it.) Could you attach YaST logs please? Created attachment 229247 [details] Protocol from the installation system of the openSUSE 11.0 DVD I'm sorry that I did not know about the root shell on console 2 from the DVD installation system before. http://en.opensuse.org/Bugs/YaST#I_get_a_red_text_pop-up_telling_me_.22An_error_occurred_during_installation.22._Is_there_still_any_way_to_salvage_log_files.3F I performed another try to restore the "gfxboot" stuff. 1. I have selected the option "Repair Installed System" from the main boot menu where I have started the action "Restore GRUB" from the expert tools section. 2. I have got the notice "The root partition could not be found. [...] rescan [...]" in a dialogue box. 3. I switched to the second terminal. / #> vgchange -a y && mkdir /mnt/H && mount /dev/system/home /mnt/H 6 logical volume(s) in volume group "system" now active 4. I clicked on the link "Install new boot loader" again. I was surprised that a boot menu list was presented this time. But it contained only two entries. I clicked on the menu entry "Read and Merge existing boot loader configuration" that appeared after a click on a button at the bottom of the screen. The list did not change. 5. I clicked the button "Finish". I have got the notice "An error occurred during boot loader installation. [...]" in a dialogue box after a waiting pause. 6. text console: / #> cp /var/log/YaST2/y2log /mnt/H/elfring/Projekte/YaST/DVD-y2log3.txt (In reply to comment #0 from Markus Elfring) > Unfortunately, I have got the display "GRUB " after reboot. It seems that the > boot loader does not like the adjusted disk layout. I would like to add that an explanation for my observation can be found in the position handling: The GRUB MBR (being the GRand Unified Boot Loader's "stage1" Sector) A Disk Editor View and Comments on the Code (as seen in Memory during Execution) http://mirror.href.com/thestarman/asm/mbr/GRUB.htm I hope that it will become easier to move boot partitions. The problem is calling perl-Bootloader via Bootloader_API it finish with (from logs): 2008-07-22 08:43:07 <1> linux(3369) [wfm] Y2StdioFunction.cc(evaluateCall):137 Evaluating remote call to 'Bootloader_API::setMountPoints' 2008-07-22 08:43:07 <3> linux(3369) [liby2] Y2ProgramComponent.cc(receiveFromExternal):358 External program returned invalid data. 2008-07-22 08:43:07 <1> linux(3369) [wfm] Y2StdioFunction.cc(evaluateCall):137 Evaluating remote call to 'Bootloader_API::setPartitions' 2008-07-22 08:43:07 <3> linux(3369) [liby2] Y2ProgramComponent.cc(receiveFromExternal):350 External program /usr/lib/YaST2/servers/scr died unexpectedly 2008-07-22 08:43:07 <1> linux(3369) [wfm] Y2StdioFunction.cc(evaluateCall):137 Evaluating remote call to 'Bootloader_API::setMDArrays' 2008-07-22 08:43:07 <3> linux(3369) [liby2] Y2ProgramComponent.cc(sendToExternal):417 External program /usr/lib/YaST2/servers/scr died unexpectedly 2008-07-22 08:43:07 <3> linux(3369) [liby2] Y2ProgramComponent.cc(receiveFromExternal):350 External program /usr/lib/YaST2/servers/scr died unexpectedly 2008-07-22 08:43:07 <1> linux(3369) [YCP] bootloader/routines/lib_iface.ycp:226 Calling getMetaData 2008-07-22 08:43:07 <1> linux(3369) [wfm] Y2StdioFunction.cc(evaluateCall):137 Evaluating remote call to 'Bootloader_API::getMetaData' 2008-07-22 08:43:07 <3> linux(3369) [liby2] Y2ProgramComponent.cc(sendToExternal):417 External program /usr/lib/YaST2/servers/scr died unexpectedly 2008-07-22 08:43:07 <3> linux(3369) [liby2] Y2ProgramComponent.cc(receiveFromExternal):350 External program /usr/lib/YaST2/servers/scr died unexpectedly 2008-07-22 08:43:07 <1> linux(3369) [YCP] bootloader/routines/lib_iface.ycp:228 Returned from getMetaData 2008-07-22 08:43:07 <3> linux(3369) [YCP] bootloader/routines/lib_iface.ycp:231 Reading meta data failed I am sorry but there is no any additional info why calling perl died :( Martin do you have any hints please? How should I provide more details about the software failure to reactivate the openSUSE graphical boot style? Are there any open issues for the support of logical volume management? It is easy let need info to mvidner please ;-) Martin please see my comment #6 Could you please attach what version of perl-Bootloader you have? In one version is compilation error. (rpm -q perl-Bootloader) My current openSUSE system has got the package "perl-Bootloader-0.4.32.21-0.1". Which version is used on the installation CD/DVD from which I tried the "gfxboot"/GRUB reactivation? If you use DVD, then it cannot be broken perl-Bootloader, because it is never released on DVD. (it lives only one weekend until fix) I am afraid the underlying cause is only reported to the system console, so to see it you have to reproduce the bug. See also bug 310216 for a posibly related problem, and tips how to diagnose it (including the non-public comments; Jozo consider making them public please). Can you successfully reactivate GRUB from the installation DVD after the (relative) position for the stage2 code was changed because the beginning of the boot partition was moved for a resize on your (LVM2) test system? Jirka could you verify if partitions on LVM2 are mounted by yast2-repair please? Markus, while you were trying to manually mount root partition, could you also try to mount /usr before proceeding with boot loader repairs? It looks like the repair system doesn't check if /usr lies on separate partition and does not mount it; the result may cause errors just like the one shown in comment 6. My LVM configuration is the following. Sonne:~ # lvdisplay --- Logical volume --- LV Name /dev/system/home VG Name system LV UUID B4Ydh9-pTHb-8dhH-BtqW-ikQ9-KDCj-zsuadA LV Write Access read/write LV Status available # open 1 LV Size 50.00 GB Current LE 12800 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 --- Logical volume --- LV Name /dev/system/root VG Name system LV UUID JFMK6w-vQrE-7jbE-M1tv-uy5T-9woS-WdGA9g LV Write Access read/write LV Status available # open 1 LV Size 10.00 GB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1 --- Logical volume --- LV Name /dev/system/swap VG Name system LV UUID Fvwhe9-fDqI-QZJb-L8bN-be89-KhpB-R9kuId LV Write Access read/write LV Status available # open 1 LV Size 52.00 MB Current LE 13 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2 --- Logical volume --- LV Name /dev/system/var VG Name system LV UUID f2nyMr-8NwV-bcDy-GkkC-ETUN-BbTL-GWoB4t LV Write Access read/write LV Status available # open 1 LV Size 10.00 GB Current LE 2560 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:3 --- Logical volume --- LV Name /dev/system/opt VG Name system LV UUID onn3CB-A26H-zuJd-3Qho-LgFo-MI6O-T1zGQ3 LV Write Access read/write LV Status available # open 1 LV Size 4.00 GB Current LE 1024 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:4 --- Logical volume --- LV Name /dev/system/usr VG Name system LV UUID CyaJjw-aezt-FYlH-Qf33-EoC7-BD5X-gaVkIb LV Write Access read/write LV Status available # open 1 LV Size 25.00 GB Current LE 6400 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:5 Can you check on your own test system which required directories were not mounted for the GRUB repair? According to the log file, /dev/system/root was mounted (I assume in that second attempt, when you got past the "no root found"). /dev/system/usr was not mounted. Could you please go to the point before opening bootloader repair part and try to mount /dev/system/usr manually? The "second attempt" was only possible after I activated my LVM configuration manually. When will this step be performed automatically? Are you also looking for directories besides "usr"? Which mount points should be available for the repair? (I would like to collect the desired questions before I will start my installation DVD again.) (In reply to comment #18 from Markus Elfring) > The "second attempt" was only possible after I activated my LVM configuration > manually. I know. > When will this step be performed automatically? After the fix of bug 402654. > Are you also looking for directories besides "usr"? > Which mount points should be available for the repair? Currently, repair mounts only / and that seems to be problem, because the libraries are located under /usr, that's probably why the bootloader repair failed. I'm asking you for a test so we can confirm this theory. The following command worked in the console after the root partition could not be found by the repair system from the DVD. / #> ll /usr/lib* [Usual directory listing ...] Would you like to reproduce my error situation in your own test environment? (In reply to comment #20 from Markus Elfring) > The following command worked in the console after the root partition could not > be found by the repair system from the DVD. > / #> ll /usr/lib* > [Usual directory listing ...] Hm, the question is if this is the same /usr as the one on your LVM partition. Try this: boot repair dvd, start LVM manualy, just like youv've done before, let YaST mount /dev/system/root and see (on console) where is it mounted. I assume it will be /mnt. Than mount your /dev/system/usr to /mnt/usr. > Would you like to reproduce my error situation in your own test environment? Well, I'm not sure if I have time for building such environment. I do not want to make assumptions about the involved mount points. I imagine that additional mounts would not be needed to replace the working GRUB setup by the openSUSE version on my boot partition. Which scripts and programs are mainly responsible for the openSUSE-GRUB restore? (In reply to comment #22 from Markus Elfring) > I do not want to make assumptions about the involved mount points. I imagine > that additional mounts would not be needed to replace the working GRUB setup by > the openSUSE version on my boot partition. I do not ask you to make any assumptions. Try to do exactly what you did before, after the bootloader configuration screen is opened, switch to console and tell me what does the 'mount' command says. Hm, now I found that everything should actually be correctly mounted under /mnt (see "OSRFstab.ycp:2375 Mount all return" line in y2log). Jozef, any idea? OK, I tried to build LVM group, tested and I can see that once the LVM group is activated (bug #402654), all its volumes are mounted. (In reply to comment #24 from Jiří Suchomel) I can answer this better now. While the root partition was not found: rootfs on / type rootfs (rw) tmpfs on / type tmpfs (rw,size=0k,nr_inodes=0) tmpfs on / type tmpfs (rw,size=0k,nr_inodes=0) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) /dev/loop0 on /mounts/mp_0000 type squashfs (ro) /dev/loop1 on /mounts/mp_0001 type squashfs (ro) /dev/loop2 on /mounts/mp_0002 type squashfs (ro) /dev/loop3 on /mounts/mp_0003 type squashfs (ro) /dev/loop1 on /usr/bin/gdb type squashfs (ro) devpts on /dev/pts type devpts (rw,mode=600) /dev/mapper/system-home on /mnt/H type ext3 (rw) While the tab "Section Management" from the dialogue "Boot Loader Settings" was displayed after my manual LVM activation: rootfs on / type rootfs (rw) tmpfs on / type tmpfs (rw,size=0k,nr_inodes=0) tmpfs on / type tmpfs (rw,size=0k,nr_inodes=0) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) /dev/loop0 on /mounts/mp_0000 type squashfs (ro) /dev/loop1 on /mounts/mp_0001 type squashfs (ro) /dev/loop2 on /mounts/mp_0002 type squashfs (ro) /dev/loop3 on /mounts/mp_0003 type squashfs (ro) /dev/loop1 on /usr/bin/gdb type squashfs (ro) devpts on /dev/pts type devpts (rw,mode=600) /dev/mapper/system-home on /mnt/H type ext3 (rw) /dev/mapper/system-root on /mnt type ext3 (rw) /dev/sda2 on /mnt/boot type ext3 (rw) /dev/mapper/system-var on /mnt/var type ext3 (rw) /dev/mapper/system-usr on /mnt/usr type ext3 (rw) /dev/mapper/system-home on /mnt/home type ext3 (rw) /dev/mapper/system-opt on /mnt/opt type ext3 (rw) /dev/sda1 on /mnt/windows/C type ntfs (rw) /dev/sdb1 on /mnt/windows/D type ntfs (rw) /dev/sda6 on /mnt/windows/E type ntfs (rw) I imagine that write access to the boot partition would be sufficient for my use case to install an openSUSE-GRUB update. Why are additional mounts needed? (In reply to comment #27 from Markus Elfring) > Why are additional mounts needed? I think mounting is correct. See comments 25 and 26 (In reply to comment #25 from Jiří Suchomel) Can the source file "OSRFstab.ycp" be viewed in a public version repository? You have it on your system under /usr/share/YaST2/modules. The line I cited basically confirms what you are showing in comment 27. In other words (I wrote it in previous comments already): after the LVM is initialized, the mounting is IMO done correctly, so the problem is probably elsewhere. My requests for mounting /usr manually are irrelevant now. Can you imagine to perform a GRUB update without additional mounts? Yesterday the openSUSE 11.1 update could restore the graphical boot menu on my system. Now the marching penguins are back. http://lists.opensuse.org/opensuse/2006-12/msg04458.html Which source files were adjusted for this change? By the way: Some comment lines that contained the key word "splashimage" were deleted from my configuration file "/boot/grub/menu.lst". http://www.makeuseof.com/tag/how-to-create-a-custom-splashimage-for-grub/ http://wiki.debian.org/Grub/SplashImage Markus, do you have still problem with restoring bootloader in Repiar mode? Your comment #33 is iteresting but for different problem could be different bug report ;-) Please verify if you have still problem with restore bootloader in 11.1 (In reply to comment #34) > Markus, do you have still problem with restoring bootloader in Repiar mode? I do not know because my issue with the boot menu was repaired somehow by the usual update to 11.1 from the installation DVD. > Your comment #33 is iteresting but for different problem could be > different bug report ;-) I used the "splashimage" setting for the display of an eye-candy background image as a workaround. Now I like the display of the winter from the penguin theme. I guess that a separate report for a potentially unsupported key word in the configuration might not be appropriate for my current situation. (In reply to comment #34) > Please verify if you have still problem with restore bootloader in 11.1 Would you like to try the repair mode again after the beginning of the boot partition was moved on one of your test systems? to comment #36: - I did several tests but I am sure that you have other partitionig of disk and I want just verify if you have still problem with repair mode. - OK let it be I will try it again myself and I also try simulate your partitioning of disk but I hope that it is still actual Does the openSUSE GRUB implementation also store the location of its stage2 file (in sectors) at the address "7C44" of the boot record ("stage1")?
Can YaST or the repair tool from the installation system adjust such position values after partition movements?
*** Bug 303842 has been marked as a duplicate of this bug. *** I find, that problem is in not mounting target system if not package check is selected. Simple fix is mount target system...better fix is reconsider all mount and unmount stuff, as now it is really error-prone. I add simple fix. More complex fix need more considering. released as yast2-repair 2.18.1 I am curious on your further considerations. Will this bug report still be tracked until the issue will be completely fixed? (In reply to comment #43) > I am curious on your further considerations. > Will this bug report still be tracked until the issue will be completely fixed? Please use separate bug reports for all problems, as it is easy to track it (and it improve speed, because some bugs can be for another people). Thanks |