http://bugzilla.suse.com/show_bug.cgi?id=1090524 http://bugzilla.suse.com/show_bug.cgi?id=1090524#c1 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmacvicar@suse.com Flags| |needinfo?(dmacvicar@suse.co | |m) --- Comment #1 from Michael Chang --- Probably the update-bootloader was complaining /dev/disk/by-id/scsi-SATA_Samsung_SSD_840S1AXNSAF418336R did not present on your system. Could you please check that ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1090524 http://bugzilla.suse.com/show_bug.cgi?id=1090524#c3 Josef Möllers changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josef.moellers@suse.com Assignee|mchang@suse.com |snwint@suse.com Flags|needinfo?(dmacvicar@suse.co | |m), | |needinfo?(mchang@suse.com) | --- Comment #3 from Josef Möllers --- Sorry for the somewhat long delay ... I discussed this with Rich Paredes and Josef Reidinger and both said not to delete the file as it would be used by yast2-bootloader. As the information in that file appears to be stale, I'm assigning this to the maintainer of yast2-bootloader to discuss how this issue should be resolved properly. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1090524 http://bugzilla.suse.com/show_bug.cgi?id=1090524#c5 Josef Reidinger changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(dmacvicar@suse.co | |m) --- Comment #5 from Josef Reidinger --- OK, let me structure a bit answer: 1) to know why this non-existing device ended up in default/grub_installdevice I need y2logs from installation time ( not sure if it is not already rotated away ). 2) regarding existence of default/grub_installdevice . We using it and it is useful to track where installation puts its stage1. If it use generic_mbr and if we control boot flag or user do not want it for us. This file is really important when there is a multiboot and user expect not so aggressive behavior he configured during installation. Why we need to store it? Because when grub2 is upgraded, it can also upgrade stage1 ( not happen often ) and in such case we need to know where we want to install that new upgraded stage1. And of course to show current settings in yast2-bootloader. What we can possible discuss is to skip this file for trivial simple cases like single disk and install to MBR. And expect all related parts already know about such decision. 3) this file is used only when grub2 needs stage1 location so non-EFI x86_64 and ppc. For other architectures we do not have it. So I hope I explain why we need this file. To debug this issue with I need y2logs. Cannot do much more without it. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1090524 http://bugzilla.suse.com/show_bug.cgi?id=1090524#c7 --- Comment #7 from Josef Reidinger --- duncan - ping. Without logs I worry I cannot say what write yast2-bootloader itself and what is written by something else. -- You are receiving this mail because: You are on the CC list for the bug.