Bug 863409

I forgot to add that my best guess is that the Yast bootloader is broken, and the system updated a kernel, and the bootloader wasn't written.  Perhaps?  Something vaguely like that?  So perhaps if I re-install by hand in the rescue chroot things will work again?

Please attach YaST log files showing the re-install of the boot loader and the last update (how to get complete logs see http://en.opensuse.org/openSUSE:Report_a_YaST_bug).

Hi.  Thanks for the fast response.  I'm in the rescue chroot now, and the yast log seems to indicate that there should be an "install bootloader" option.  I don't see that in Yast.  All I see is:

 - a progress menu on selectig the bootloader screen (using curses yast)

 - a screen with title "bootloader settings" and a single section "bootloader installation" that has a "type" box and a "secure boot" box.  At the bottom of the screen are "help", "cancel" and "ok" buttons.  The "type" is "grub2-efi" and I can go into another screen for "boot loader options", but I never see an "install" button.

Anyway, I a copying various log files to USB and will post them here:

  - y2log seems to be the log file.

  - y2log_bootloader is dated 6 Feb which would probably be the last update I applied.

  - ylog-kRUsMf.tar.gz was created by save_y2logs

Created attachment 578237 [details]
y2log (latest log)

Created attachment 578239 [details]
all yast logs

Created attachment 578297 [details]
bootloader log from last week (last patch applied?)

Could someone give me an idea of whether or not this is likely to be looked at soon?

I don't know whether to try fixing and/or reinstalling something, or whether I should keep it around for more tests.

Thanks!

I had another look at the output from efibootmgr -v and decided it was missing anything related to grub.  So I ran efibootmgr -c with what seemed like the correct parameters, and that added a new entry visible from the BIOS (before, in the BIOS, there were no boot options listed).

However, it still fails to boot.

Is it helpful running "update-bootloader --reinit" ?

if i boot into rescue mode (from a cd) and then start chroot following instructions at http://johnlange.wordpress.com/2009/09/22/suse-broken-dont-fear-the-chroot/ (but mounting correctly for /boot/efi) then i get (retyping, so possible typos):

> update-bootloader --reinit
Perl-Bootloader 2014-02-17 13:46:43 <3> Core::RunCommand.1642: Error: Command '/usr/bin/grub2-install --target=x86_64-efi > /var/log/Yast2/y2log_bootloader 2>&1' failed with code 256 and output: Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.
[...]

> modprobe efivars
Fatal: Could not load /lib/modules/3.11.6-4-default/modules.dep: No such file or directory

> ls /lib/modules
3.11.10-7-desktop 3.11.6-4-desktop

> cd /lib/modules

> ln -s [desktop to default]

> cd /

> modprobe efivars

> update-bootloader --reinint
[same error as before]

> cd /lib/modules

> rm [soft link]

Note that I did mount --bind proc, sys and dev for the chroot.

Hope that helps; thanks for the reply.

Hi Andrew,

modprobe efivars in chrooted / won't work as long as the running kernel from rescue system mismatches with the chrooted one.

Try modprobe efivars before chroot ?

AWESOME!

ok, so that worked fine.  no errors and now i can boot the machine.

so i am happy, but it seems like there is still some kind of bug?  how did it get like that?  is there any more info you need from me?

thanks!!

(In reply to comment #1)
> I forgot to add that my best guess is that the Yast bootloader is broken, and
> the system updated a kernel, and the bootloader wasn't written.  Perhaps? 

It wouldn't be the case because it's perl bootloader, not yast2 which writes bootloader during package update. The update-bootloader is the utility by means of perl bootloader modules to update and install bootloader in command line and invoked during rpm package's scrip-lets (eg %post). 

But it looked fine here (update-bootloader --reinit).

> Something vaguely like that?  So perhaps if I re-install by hand in the rescue
> chroot things will work again?

While YaST2 bootloader did have some odd problems because it renews the bootloader config and reluctant to reinstall. In legacy bios this is a problem because bootloader location is changeable, but in UEFI it's a hard to say ... (well, probably distributor means same thing as location in legacy bios but it'
s not obvious anyway ..)

Actually force to reinstall bootloader in yast2 bootloader regardless what settings were done is not good implementation either. Most settings in yast2 bootloader doesn't require reinstall bootloader to be effective and as we know the fact that reinstall bootloader in UEFI would require to rewriting the nvram and would potential trigger some firmware/kernel bug if too frequently.

Hi, I don't know if this is any help, but I ran into this issue again and can describe in detail when it happens.

The issue above was with an ASUS 1015-DS03 (a "netbook-like" computer that comes with Ubuntu pre-installed).  I spilt coke on that and it died, so I bought a replacement, which is an ASUS 1015-DS02.  I am unsure why the newer(?) model has a smaller number (02 v 03) but it appears identical, except for the lid (matte instead of glossy).

So anyway, with the new ASUS 1015-DS02, I did a new install of openSuse 13.1 from the DVD (64 bit).  As far as I remember the only options I changed were language (US to UK), date/time, and deselecting the separate user partition.  The install went fine and the computer booted into KDE as expected.

I then updated all software.  First, yast updates and a reboot.  Then a complete update for hundreds of packages, including kernel.  Rebooting after that, I hit this problem.  And the steps above fix it.

So it seems that something in the updates (presumably the kernel) is messing up the UEFI bios thing.

The kernel is now 3.11.10-7.1

Hi andrew,

Please test latest factory or tumbleweed and reopen if the update problem still exist.

Thanks.