https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c2 --- Comment #2 from Neil Rickert 2012-06-05 21:12:31 UTC --- It might not be a live image problem. I did an install from DVD today, and had a similar problem. Here's my history. Note that all installs were from a USB, with the iso image written to the USB as recommended in opensuse documentation. Computer 1: Install from DVD image; grub2 worked installing on "/boot" which is "/dev/sda1". I asked it to not set the active flag. Computer 1: Install from live KDE image: grub2 install failed, with complaint about not installing on MBR. I reverted to grub1. Computer 2: Install from live KDE image: grub2 install failed, as in line above. Computer 2: Install from DVD image: grub2 install failed, as in line above. The install was attempted to "/boot" which is "/dev/sda5" on that computer. I had asked it to install the boot record on both sda5 and sda4 (extended partition). And I had asked it to not set the active flag. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c4 Neil Rickert changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|nrickert@ameritech.net | --- Comment #4 from Neil Rickert 2012-06-06 05:24:38 UTC --- Created an attachment (id=493755) --> (http://bugzilla.novell.com/attachment.cgi?id=493755) A ".tgz" tarball of the YaST2 subdirectory of /var/log. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c6 --- Comment #6 from Michael Chang 2012-06-06 06:22:26 UTC --- Neil, In general you shouldn't check "Boot from /boot" when /boot is logical partition, as the generic mbr boot code couldn't bootstrap it directly. In this case installer would propose the extended partition on which boot record would be loaded and executed by master boot record via setting it as active partition. So in general "set active flag" has to check as well .. Without active flag (point to extended partition) it sounds promising to me that the setup would fail .. I'd like to know in advance that what's the purpose you override the proposed settings (it is not true intelligent to get all things to work, it offers flexibility but may be not supported scenario ..) Thanks. :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c8 --- Comment #8 from Michael Chang 2012-06-11 03:28:16 UTC --- Neil, Thanks for elaborated explain for your case. I think I knew your purpose and I agree with your principles. :) The purpose we suggest extended partition is that we generally assume users would walk through the installation without any interrupt and default to openSUSE. Your setup depends on Windows to chainload sda5 is fine, but have to adjust the default settings to fit the needs. I think the real problem is that chain-loading /dev/sda5 was not work, even though boot record seems written to it. I will try if I could reproduce it. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c9 --- Comment #9 from Neil Rickert 2012-06-21 15:57:41 UTC --- Here's some experience with Beta2. I installed 4 times. On the first and 4th install, grub2 installed without a problem. On the 2nd and 3rd install, it failed (but backup to grub1 worked) All were on the same computer. The reinstalls were due to plymouth/yast interlocks (see bug 768185). For all installs: "/" is /dev/sda8 "/boot" is /dev/sda5 "/home" and swap are encrypted partitions (probably not relevant). I configured booting from "/boot". The suggested configuration was to boot from the extended partition, but I disabled that and changed to "/boot". I turned of setting the active flag. First install - I installed KDE, Gnome, LXDE, XFCE and some other stuff. The grub2 install went perfectly. 2nd install - I installed only KDE. The grub2 install failed, with a message that it's a bad idea to install on a partition. There was also an error message about a missing file, though that went past a bit too fast for me to be sure what file. 3rd install - I installed KDE, Gnome, LXDE, XFCE, but less other stuff than in the first install. Grub2 install failed similar to the 2nd install, except that I did not notice a message about a missing file. 4th install - same software as 3rd install, and additionally "rcs", "aria2", "dar", "gcal" and "fspot". The grub2 install went perfectly. It's a bit hard to believe that the slight change in selected software made the difference, so there could be some random timing events that affect what happens. I have a saved tarball of "/var/log/YaST2" from the second install, in case that might be useful. Let me know if you want it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c11 --- Comment #11 from Michael Chang 2012-06-22 05:05:07 UTC --- (In reply to comment #9)

2nd install - I installed only KDE. The grub2 install failed, with a message that it's a bad idea to install on a partition.

That warning is fine IMHO, because upstream not recommend installing to partition.

There was also an error message about a missing file, though that went past a bit too fast for me to be sure what file.

Yes. It should be. That's the real reason to the failure (missing device.map or grub2-mkconfig). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c13 --- Comment #13 from Michael Chang 2012-06-22 15:42:35 UTC --- Thanks, if you have the log, please attach it, same with in comment#3) The mkinitrd would call update_bootloader script and in turn routes to perl-bootloader and the loader specific perl modules to update the config files (since you have a new initrd created then it has to be add in bootloader menu). Indeed perl bootloader is stubborn if some files are missing but to me that's probably an early assertion of failure (if it continues then the ramification is unpredicted and we lose the fist scene to debug). I expect maybe something wrong in grub2's perl-bootloader per your description, but really no good idea so far. :( I'll continue the work next Tuesday, Monday I may not be available because I'm in travel. Wish you nice weekend too. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c15 --- Comment #15 from Michael Chang 2012-06-27 08:47:48 UTC --- This time I found the failure from your provided log. ========== Bootloader.ycp:698 Calling bootloader executable bootloader/routines/lib_iface.ycp:279 Updating bootloader configuration Y2SystemFunction.cc(useRemote):129 'updateBootloader': switched to remote Y2StdioFunction.cc(evaluateCall):137 Evaluating remote call to 'Bootloader_API::updateBootloader' bootloader/routines/lib_iface.ycp:281 return value from updateBootloader: true bootloader/grub/misc.ycp:365 Updating disk system area, activate partition: false, install generic boot code in MBR: false bootloader/grub/misc.ycp:373 Doing MBR backup: MBR Disk: /dev/sda, loader devices: ["/dev/sda5"] bootloader/routines/lilolike.ycp:317 Partitions building /dev/sda5: $[] bootloader/grub/misc.ycp:156 Bootloader partition type is logical bootloader/grub/misc.ycp:163 Using extended partition 4 instead bootloader/grub/misc.ycp:174 Partition for activating: $["dev":"/dev/sda4", "mbr":"/dev/sda", "num":4] bootloader/grub/misc.ycp:378 Creating backup of boot sectors of ["/dev/sda", "/dev/sda5"] bootloader/routines/i386.ycp:101 Data: 142 208 bf 00 bootloader/routines/i386.ycp:105 MBR of /dev/sda contains ThinkPad sequence: false bootloader/routines/lib_iface.ycp:310 Initializing bootloader Y2SystemFunction.cc(useRemote):129 'initializeBootloader': switched to remote Y2StdioFunction.cc(evaluateCall):137 Evaluating remote call to 'Bootloader_API::initializeBootloader' PushButton.cc(setFunctionKey):204 Guessing button role YOKButton for YPushButton "OK" at 0x7f8ad8d7e908 from function key F10 bootloader/routines/lib_iface.ycp:245 Error occurred while initializing bootloader BootGRUB2.ycp:114 GRUB return value: false -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c17 --- Comment #17 from Michael Chang 2012-06-27 12:48:36 UTC --- Created an attachment (id=496581) --> (http://bugzilla.novell.com/attachment.cgi?id=496581) bzr log -p r4033 upstream commit rev4033 seems to introduce drastic simplify on how to retrieve blocklist. It doesn't rely on grub2's fs(in your case ext2) module provided r/w function and hostdisk (which emulates biosdisk interface on host) as the underlying means, but directly call os native ioctl thus common for all fs. I would like to give it a try because your problem seems to be timing issue caused by disk cache coherence or something like that. The change by rev4033 seems to completely eliminate that possibility as I could see the code is much more cleaner (that is no dirty grub_util_biosdisk_flush somewhere and MAX_TRIES like to workaround some issue) The grub2 in devel project has upgraded grub2 and included above commit already. I'll try to give you the dud and let you know how to test it. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c19 --- Comment #19 from Michael Chang 2012-06-27 13:40:02 UTC --- Please download above file and place it somewhere as <url> then use openSUSE12.2 beta2 disk with below options insecure=1 dud=<url> More detailed you could refer to http://en.opensuse.org/SDB:Linuxrc#p_driverupdate The driver update disk is a *patch* to the installation media. If succeed you could see grub2 version in boot menu becomes 2.00beta6. Let me know once you have any problem .. thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c21 --- Comment #21 from Michael Chang 2012-06-28 04:51:25 UTC --- (In reply to comment #20)

I'm not entirely clear on the steps.

Do I need to setup a local server for the url? No.

Or can I store the file in a different disk partition, Yes.

and use something like dud=disk:/dev/sda1/filename Use dud=disk:/filename, for example use "dud=disk:/bug-765198_new-grub2.dud" Linuxrc would try every disk and partition in turn to locate the file in specified path.

If succeed, you could switch to console 1 via Ctrl/ALT + F1 and see the message Reading driver update: disk:/bug-765198_new-grub2.dud Loading file:/mounts/mp_0000/bug-765198_new-grub2.dud (7122kB) - 100% Driver Update: Update with grub2/grub2-efi support beta2 Driver Update added: Update with grub2/grub2-efi support beta 2

I'm assuming that this is entered on the boot options line.

Yes. And don't forget insecure=1 as the dud is not signed.

Do I then need to do a new install, or is an update install (update booting) sufficient)?

It's up to you, whatever steps you tool to reproduce your problem.

If either works, then I would probably test both - a reinstall on my faster system and an update install on an older slower system.

Go ahead. :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c23 --- Comment #23 from Michael Chang 2012-06-28 08:02:53 UTC --- Neil, You could test now, I met some problem but now it looks like not related with grub2 change. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c25 --- Comment #25 from Neil Rickert 2012-06-28 21:31:44 UTC --- Running the installer for updating did not give me an option to update/reinstall the booting. I guess you have to do that manually with a repair boot, and that probably uses the installed grub software so it is doubtful that I would be testing your update. I gave up on that plan. I really don't want to do another full install on that machine, as it takes several hours to complete. I hope the full install on the faster machine is sufficient feedback for you. I will do a fresh install when the release candidates become available. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c27 --- Comment #27 from Neil Rickert 2012-06-29 14:50:49 UTC --- Yes, I will check again in RC. In the meantime, I installed beta2 an another system. Grub2 installed without a problem. I did run into a different problem. On startup, grub complained "Cannot display this video mode", and there was no visible boot menu. The system did boot into 12.2 Beta2, though, even if blind. I had to change "GRUB_TERMINAL=gfxterm" to "GRUB_TERMINAL=console" to get around the problem. If I might offer a suggestion: How about adding a commented "GRUB_TERMINAL=console" line, with some addition comments guiding people on how to deal with this situation. Incidentally, the monitor is 1440x900, and that's what grub2 seems to not like. However, I had previously installed M3 and grub2 did not have any problems with this system for M3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c29 --- Comment #29 from Michael Chang 2012-07-02 08:23:54 UTC --- (In reply to comment #28)

Btw . I'm planning to make some change to it and hopefully that we could get thing done right this time.

OH . please see my last comment in bnc#757683. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c31 --- Comment #31 from Neil Rickert 2012-07-05 17:23:15 UTC --- Okay. Yes, I am certainly planning to install RC1 when it is available. I'll report back on how it works out with grub2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=765198 https://bugzilla.novell.com/show_bug.cgi?id=765198#c33 --- Comment #33 from Michael Chang 2012-07-19 07:25:12 UTC --- (In reply to comment #32)

RC1 installed in three systems. The grub2 install was without incident in all of those systems. The 1440x900 problem (from comment 27) did not show up.

Thanks. Good to know.

One thing I noticed that I did not expect - running "mkinitrd" apparently causes grub2 to be reinstalled in the boot sector. I would have expected that only "grub.cfg" would be updated.

You're right. I tried to fix that, but unfortunately lead to a disaster which renders system unbootable after updating grub2 package. Then I reverted the changes. The fix has to be thoroughly reviewed, now the process is dumb, like what we did in old days using lilo, but at lease it ensures full resistance to potential file relocation, afaics, update-bootloader has to be extend with a new interface that would just do config updating and tools like mkinitrd could use it instead of update-bootloader --refersh, which also reinstalls to bootsector. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.