http://bugzilla.novell.com/show_bug.cgi?id=513004 User juhliarik@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=513004#c1 Jozef Uhliarik <juhliarik@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org --- Comment #1 from Jozef Uhliarik <juhliarik@novell.com> 2009-06-15 03:41:46 MDT --- I read your story and it is really interesting problem. What I didn't see there are yast logs from your playing with yast2-bootloader. I am not able decide what really happened. Please attach yast logs from machine where you tried to install xen kernel. Next it seems (from you description) that yast2-bootloader didn't update boot settings: change boot flag or content of MBR. I don't know your previous settings of booting and I am not able decide what was necessary to change after your changes (change boot partition from sda2 to sda8) Finally if you start yast2-bootloader and after that change partitionig of disk by hand yast2-bootloader still works with old partitioning of disk. It would be the cause of your problem but it is only hypotesis without yast logs... Please attach yast logs and I will write you more details. Maybe it is not bug of yast2-bootloader but please attach yast logs. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=513004 User suse@tlinx.org added comment http://bugzilla.novell.com/show_bug.cgi?id=513004#c3 L. A. Walsh <suse@tlinx.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|NORESPONSE | --- Comment #3 from L. A. Walsh <suse@tlinx.org> 2009-09-19 17:43:06 MDT --- The reason I didn't respond, was I didn't think I had the logs you wanted. Yast seems to overwrite logs on each invocation, and I already had tried other options running yast to get it to work. So how could I return the logs you wanted? However, FYI, this bug is related to bug#512695 (https://bugzilla.novell.com/show_bug.cgi?id=512695) -- they were different manifestations of the same underlying problem -- grub wasn't booting (and wasn't being updated to boot) from the correct Partition -- and Yast2 didn't see any problem, as it only saw the new partition and all looked fine -- but grub ignored anything Yast2 did, as it was fixated on the old partition). Note -- if lilo was used and was called to update the new boot parms, none of this happens. As I note in the other bug, grub has other problems, which, instead of "disqualifying grub' as being incompatible and inferior to previous functionality, instead, disqualifies other working systems (like yast2 from working on the real boot partition, and "xfs" not being officially supported...)... If grub is too hard to fix, or the maintainers can't fix these problems, then suse should go back to lilo as it *works* -- and move to elilo for the new boot spec (which my machines (I think) support, but was told would require full reformats due to incompatibility). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=513004 User suse@tlinx.org added comment http://bugzilla.novell.com/show_bug.cgi?id=513004#c5 --- Comment #5 from L. A. Walsh <suse@tlinx.org> 2009-10-09 13:41:42 PDT --- Something may be screwy with my email.... I don't recall seeing your response come in...(weird...) ... was just skimming over old bugs and found your comment. Ok...I understand, doesn't support everything. Nothing does. This caught me by surprise and had no warning of potential problem, thus I thought a bug should be filed. yast2 read its settings from my "new" 1GB /boot partition -- not the older 64MB /boot partition (kernels used to be smaller ya know). But grub which handled the boot was still reading it's menu and boot info off of the older /64MB partition. This wouldn't happen with 'lilo'. It reads from the current mounted file system. The problem -- or the requirement to solve this, is to make sure that grub is booting from the current representation of the active system -- as yast2-bootloader sees it. Lilo does that automatically. The problem is Grub isn't using the information that is present and being modified by yast2-bootloader in the currently running system. So *REALLY*, this is a problem (yet ANOTHER problem) in Grub -- it's not working off of the current system state. Now maybe yast2-bootloader can ensure that 'grub' is re-initialized to to be working with the currently active 'Boot' partition, and that would be an acceptable workaround. But the problem is that grub is just 'out of sync' with the system that is currently running (as yast2-bootloader sees it). There are multiple problems with grub -- why anyone jumped to it from a stable product like lilo I've little clue -- other than it seems new and shiny and full of new features -- that don't work on most current PC's reliably and don't even work reliably with journaled file systems. Notably 'xfs' was labeled as not being supported because grub was unreliable with it -- but it has been shown that the same problem that happens with 'xfs' *can* happen with any journaled file system -- it's just a matter of timing and luck that it doesn't happen often. That's a BAD bug. That it happens often with XFS is a good thing -- as it points at the bug in the first place, that otherwise would remain hidden as a randomly occuring event on other journaled-filesystems with no easy means of figuring out what happened. Anyway -- found the logs you were interested in. Will attach them, though I think I have to submit this comment first then attach -- last time I tried submit, my comment went away -- and I had to go back pages to find it, then when I tried to submit the comment I got a warning about colliding updates to the bug....so ...comment first, then upload the tar file. It's only 2.4M compressed with lzma (tar caf YaST2.tlz YaST2, in /var/log). Note -- due to a tar bug, you have to explicitly say --lzma on uncompress -- it doesn't autodetect type from extension on decompress as it does on compress, so: "tar xaf YaST2.tlz --lzma" (will create and extract into a dir named YaST2). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=513004 http://bugzilla.novell.com/show_bug.cgi?id=513004#c7 Jozef Uhliarik <juhliarik@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |WONTFIX --- Comment #7 from Jozef Uhliarik <juhliarik@novell.com> 2010-02-09 13:37:26 UTC --- sorry for delay but I also working on other projects. The bad news is that YaST logs are not useful because there is long time running system and YaST logs are overwritten by other yast actions. (log rotation) I read again your description of bug. IMHO we try to solve a lot of problems and we still open new problems. It is not good idea because there is not any result. I try to return back to your description of problem and I see there 3 basic problems: 1. change /boot partition 2. using device names mount by label 3. wrong reading of bootloader settings after your changes 1. change /boot partition ========================= Usually it is good idea if there is not enough space but problem is with installation of new kernel. It is still uses old configuration from /etc/sysconfig/bootloader. There are options like: XEN_KERNEL_APPEND, FAILSAFE_APPEND, DEFAULT_APPEND which still includes old settings. These options are used for installation or update kernel. Next problem is /etc/grub.conf which includes settings for installation of GRUB if you change /boot partition you have to also update this file because it still point on your old /boot partition. 2. using device names mount by label ==================================== openSUSE 11.2 includes some fixes for working with persistent device names but there is still some bugs see bug#533782 but the idea is use persistent device names (mount-by) for each partition. User can define type of persistent device name for each partition or disk in yast2-storage during installation. yast2-bootloader check settings for each partition and use defined persistent name from option "mount-by" if it is not defined there is also global mount-by option. I read disk settings from yast2-storage. It means if you want to skip using persistent device names or use preferred persistent device names you have to change it in yast2-storage. I am not sure if it is good idea to change these settings on installed system. 3. wrong reading of bootloader settings after your changes ========================================================== I skip details. Simple yast2-bootloader read your NEW settings because it is located on your new /boot partition old is not mounted. But GRUB stage1 located in MBR still points to your old /boot partition and it is cause why you saw old boot menu after reboot. As I wrote before you have to upadte also /etc/grub.conf after your change with /boot partition. Finally: -------- We also had discussion about XFS and lilo. IMHO we had troubles with XFS and GRUB configuration because XFS can use the first 512B of partition and it leads to broken GRUB stage1 in some cases. There is recommended install GRUB stage1 to MBR. LILO is not supported or better configuration of LILO is not supported any more. I decide to accept only problem with using persistent device names for partition - problem number 2. I will try to solve it in bug#533782. Your other problems are result of your changes with /boot partition. I know it is really hard to know what everything should be updated if you change your /boot partition. I close bug like WONTFIX but your problem with persistent device names is not lost. It will be fixed with bug#533782. It is similar bug. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.